👋 Как я знакомлюсь с кандидатами: продолжение про собесы ⚡️

Вы попросили рассказать подробнее, как я стараюсь понять кандидатов во время собеседований. Давайте разберем поэтапно!

1️⃣ Как человек думает и принимает решения
Идеальный способ — дать кандидату задачу по system design. Это позволяет увидеть, как он структурирует проблему, выделяет важные аспекты и предлагает решения.
Но что делать, если человек уже прошел множество этапов (и с технарями в том числе) и вы — последний этап интервью? Задавать новую задачу вроде бы не очень корректно. В таком случае я прошу кандидата рассказать о его самом запоминающемся проекте, где он выступал в роли проектировщика.
Например:

— Расскажи о своем решение, где был проектировщиком, которое запомнилось больше всего? Чем гордишься в этом решении?

Когда человек отвечает, уточняете детали:
— Как ты пришел к такому решению?
— Что бы ты сделал иначе, если бы можно было?
Такой подход не только показывает, как человек мыслит, но и позволяет понять, чем он действительно гордится.

2️⃣ Сработаемся ли мы?
Для меня здесь главное — совпадение ценностей. Я убеждена, что если ваши базовые ценности с кандидатом совпадают, работать вместе будет проще.
Как я это выясняю?

— Что для тебя самое важное в работе?
— Как выбираешь между одинаковыми офферами?
— Что ты ищешь в компании?

Чем опытнее специалист, тем меньше уточнений ему нужно.
Например: "Я хочу релоцироваться на Кипр, потому что переезд к морю важен для здоровья ребенка."
И это хороший ответ, он показывает, что действительно человеку важно, демонстрирует его открытость перед вами. Да, несомненно значимо, чтобы кроме здоровья ребенка, его волновал продукт/качество кода (и я не говорю, что это не еще одна базовая ценность), но как астматик, я его понимаю!
Эти ответы дают не только понимание ценностей, но и возможность продолжить диалог: уточнить детали, обсудить мотивацию и подход человека.

3️⃣ Что кандидат может привнести в команду?
Этот вопрос напрямую зависит от ваших потребностей. Сначала важно понять, чего не хватает именно вашей команде. Какие задачи и роли должны быть закрыты сейчас? Какие — через полгода или год?
Тут важны не только навыки, но и характер кандидата. Ведь новый человек должен дополнять и усиливать вашу команду, а не отрабатывать 40 часов в неделю.
Если у вас есть starmap, то понять, чего не хватает вашей команде проще!

4️⃣ Проверяем способность быть "разумной оппозицией"
Это один из самых интересных этапов. Здесь я смотрю, как человек реагирует на альтернативные точки зрения и умеет ли аргументировать свою позицию.
Пример вопроса:

— Если бы ты проектировал систему в финтех-домене, какую архитектуру выбрал бы: сервисную, микросервисную или монолит? Почему?
Допустим, человек выбирает микросервисы. Тогда я уточняю:
— А если я как заказчик настаиваю на монолите и аргументирую это так-то и так-то?

Важно наблюдать, как человек строит дискуссию:
— Спокойно ли он объясняет свою позицию?
— Готов ли рассмотреть альтернативу?
— Не уходит ли в защиту или молчание?
Некоторые люди быстро сдаются: "Ну, вы же заказчик, значит, будет так, как вы скажете". ❗️Это тревожный сигнал: такие кандидаты вряд ли будут отстаивать свою точку зрения даже в случае критической ошибки.
При этом я против стресс-интервью. Здесь задача не в том, чтобы "поймать" человека, а в том, чтобы увидеть, как он ведет себя в дискуссии и насколько конструктивен в аргументации.

💬Собеседование — это не тест и не брошюра. Это поиск человека, который сможет стать частью вашей команды. Поэтому важно задавать не шаблонные вопросы, а те, которые вы сами понимаете и считаете важными. И никогда не скачивайте методички (УМОЛЯЮ): "Как проверить, что кандидат — ..."
Спросите себя: что именно вы хотите узнать у кандидата? Что важно для вашей команды?

Чем меньше формализма и больше осознанности в ваших вопросах, тем больше шансов найти своего человека.

❓Какие вопросы помогают вам раскрывать кандидатов?

#project_management #toolkit

📚 Документация: продукт, проект или просто боль?

Существует несколько подходов к ведению документации, и чаще всего их приходится комбинировать. Но главное — понимать: документация не высечена в камне, она меняется вместе с продуктом. Почему же так сложно выстроить грамотную систему работы с ней? Давайте разберемся!

🔹 Продуктовый подход: фиксируем суть
Этот вариант документации описывает сам продукт, его ценность и ключевые особенности:
— Для кого он создается?
— Какие у него основные функции?
— Какие есть конкурентные преимущества?
По сути, это основа, которая важна на старте, но и дальше должна обновляться. Мы же не говорим, что код нельзя менять? Почему тогда документация должна оставаться статичной?

🔹 Проектный подход: все в одном месте (но на время существования места)
Документирование вокруг конкретных проектов удобно, когда нужно зафиксировать, как происходят изменения. Например:
— Добавляется новая система лояльности к уже существующей.
— Расширяется платежная система, добавляется новый способ оплаты.
➕ Плюс: все изменения зафиксированы в одном месте.
➖ Минус: когда проект завершен, информацию трудно поддерживать, так как она только про проект, а код и продукт - шире, а значит уже через несколько месяцев все написанное становится сложно искать и учитывать в будущем, так как не понятно, как оно встроено в настоящее.

Можно ли сочетать продуктовый и проектный подход? Да, например, создавая кросс-документацию:
✔️В базе знаний остаются продуктовые страницы где поддерживается описание работы продукта в текущий момент.
✔️ Внутри — ссылки на проекты с изменениями, где описано, как они повлияли на систему.
Но здесь важно задать структуру заранее, иначе очень быстро получится каша.

🔹 Документация пост-фактум: инциденты, разборы, ошибки
Почему-то многие считают, что документация — это только про запланированное. Но часто ценные знания появляются после проблем:
📌 Инцидент случился? Фиксируем, что пошло не так и как этого избежать.
📌 Провели пост-мортем? Добавляем информацию в базу знаний, а не оставляем в разрозненных отчетах.
📌 Обнаружили ошибку в логике продукта? Обновляем документацию, а не просто исправляем код.
Без этого документация превращается в музей устаревших артефактов, а ошибки повторяются снова и снова.

🔹 Документация для R&D и исследовательских задач
А вот еще одна проблема — считать, что документация нужна только тому, что уходит в прод. Но ведь исследования, тестирования и проработки концепций тоже требуют фиксации:
📌 Разбираетесь, какие данные можно передавать в API? Запишите.
📌 Исследуете, как новая система интегрируется с вашей? Сделайте описание.
📌 Проверяете, как реагирует сервис на нестандартные запросы? Это тоже часть документации!
Когда подобные вещи фиксируются не в голове и не в разрозненных тасках в Jira, а в удобном формате, они превращаются в ценный источник информации для всей команды.

🔹 Кто отвечает за документацию?
Есть ощущение, что компании осознали:
✔️ Нужны DevOps-инженеры для инфраструктуры.
✔️ Нужны архитекторы, чтобы проектировать систему.
✔️ Нужны админы, чтобы все работало.
Но когда речь заходит про документацию — вдруг оказывается, что ей никто не должен заниматься системно. 🤷‍♀️

В итоге:
— Вся документация хранится в голове у «того самого Васи».
— База знаний — это просто свалка документов без структуры.
— Новый человек тратит месяцы, чтобы разобраться, что вообще происходит.

Кто должен заниматься документацией?
📌 Knowledge-менеджеры — это такие же важные люди, как и архитекторы, если вы строите продукт = база знаний.
📌 Технические писатели — если компания осознает важность удобной и актуальной документации, и готова тратить время на ее поддержку и актуализацию.

📌 Итог: документируете или просто пишете заметки?
Если у вас нет структуры и процессов работы с документацией, то это не база знаний, а просто записи “на память”.

🚀 Подумайте:
✔️ Как у вас сейчас ведется документация?
✔️ Кто отвечает за базу знаний?
✔️ Можно ли по ней легко найти нужную информацию?

А может, у вас все еще действует принцип «спроси у Васи»? 😏

#architecture #project_management

💸 Почему баллы, а не рубли? Разбираем секреты программ лояльности!

Недавно ко мне пришли за консультацией по вопросу реализации программ лояльности. И основной вопрос звучал так:

Почему компании используют баллы в программах лояльности, а не валюту (рубли, например)? Ведь рубли понятнее и привычнее. Почему не дают пользователям рубли, которые можно потратить, только определенным способом?

Давайте разбираться в начислении лояльности и что за этим скрыто бизнесово:
🔹 Двойная конвертация — это гибкость и выгода
Вот как это работает:
💵 Рубли в баллы: потратили 100 рублей — получили 10 баллов.
💱 Баллы в рубли: накопили 100 баллов — получили 500 рублей скидки.
Эти курсы можно легко настроить под стратегию компании.
Хотите простимулировать определенных клиентов?
Добавьте уровни лояльности, где измените курсы конвертаций по уровням: — на первом уровне 100 рублей = 10 баллов;
— на втором 100 рублей = 15 баллов;
— и так далее....

🔹 Баллы = фантики, а не деньги
Баллы не считаются реальными деньгами. Это значит:
1️⃣ Компания не обязана получать банковскую лицензию для хранения этих «средств». А это очень большая экономия и СИЛЬНО МЕНЬШЕ ПРОБЛЕМ!
2️⃣ Баллы можно «протухать» (устанавливать срок действия), чтобы стимулировать клиентов использовать их быстрее.

🔹 Финансовая безопасность
Когда клиент получает баллы, а не рубли, компания избегает необходимости следить за реальными средствами на счетах пользователей. Это снижает риски и упрощает учет.

🔹 Персонализация и мотивация клиентов
С помощью системы уровней и изменяемых курсов компания может мотивировать пользователей тратить больше. И тут не обязательно играть с курсами получения баллов, но и просто "докинуть" клиенту "фантиков" 🎉, например в честь Дня рождения клиента или Компании!

🔹 Кэшбек - просто, но не очень выгодно! (особенно, если вы маленький мерчант)
Кэшбек — это удобно и понятно: клиенту возвращаются рублики на карту после покупки. Просто, приятно, и главное — клиенты любят это. Но вот нюанс: полученные деньги клиент может потратить где угодно, а не обязательно у вас.
Для крупных сетей магазинов с активными покупателями это работает отлично. Например: возврат 10% кэшбеком становится аналогом скидки, которая "зарабатывается" только через покупку, помогая привлекать и удерживать клиентов.
Но если вы маленький магазин или ваши клиенты совершают покупки раз в год, как в случае со спортивным инвентарем, важно проверить, выгодно ли такое решение с точки зрения экономики. Иногда кэшбек может не окупиться.

🔹 Купоны: проще, но будьте осторожны!
Если вам нужно раздать условные «500 рублей» 🎟 на покупку, правильнее сделать это в формате купона со сроком действия. Купон = скидка, а не деньги, и это юридически безопаснее.
НО❗️ Однако важно помнить, что купоны — это фрод, поэтому: привязывайте купоны сразу к личному кабинету клиента или создайте нормальную систему защиты от мошенничества, иначе рискуете разориться.

💡 Итог:
— Баллы дают больше гибкости и свободы для настройки программы лояльности.
— Курс обмена и уровни можно легко адаптировать для разных сегментов клиентов.
— Лояльность на «фантиках» безопаснее и выгоднее, чем работа с реальными деньгами.

💬Так что это пост про базовые вещи из системы лояльности со стороны финтех взгляда. Если есть вопросы по лояльности или хотите поделиться интересным схемами лояльности - welcome в комменты!

‼️PS где-то тут «красной нитью» проходит мысль, что поста могло бы не быть, если бы был справочник, но для этого нужно понимать подход, а это мы будем обсуждать только завтра на круглом столе! Информация про круглый стол ➡️ тут

#architecture #fintech