Как из разработчиков вырастить фулстеков и продакт-менеджеров

«Сдай/Сними» — это стартап внутри Циан, который автоматизирует сдачу и поиск жилья для долгосрочной аренды в России. В нашей команде всего 8 разработчиков. При этом нам регулярно нужно тестировать много гипотез, искать подходящую нишу и экспериментировать с дизайном сервиса.

Поэтому мы стали перекраивать привычный рабочий процесс так, чтобы всё успевать, но при этом не мешать развитию и творчеству разработчиков.

Вовлекли команду в процессы

Раньше за гипотезы в команде отвечал продакт. Он уходил в тёмную комнату, придумывал идеи, а потом приносил их команде. Со временем стало понятно, что такой подход работает плохо:

1. Команда не была вовлечена в разработку гипотез. Никто не задавал каверзных вопросов, не предлагал улучшений и новых идей.
2. Рано или поздно у одного человека банально заканчиваются идеи и гипотезы.

Тогда мы постепенно стали привлекать к разработке гипотез всех членов команды. Как это происходило:

Шаг 1. Погрузились в продукт. Мы явно обозначили цели на ближайшие 3–6 месяцев, рассказали, откуда эти цели вообще взялись. Поэтому все понимали, что и зачем делают.

Шаг 2. Регулярно отслеживали цели. На демо и ретроспективах мы оценивали результаты по метрикам и делали выводы. Чтобы все видели, где находится и куда движется команда.

Первые два шага уже давали плоды. Команда стала внимательнее относиться к новым идеям, анализировать их и сопоставлять с нашими целями, а не просто выполнять задания. Если кто-то видел в проекте недостатки, то говорил об этом и предлагал свои решения.

Шаг 3. Создали общий канал для обмена идеями. Чтобы все могли в свободной форме предлагать идеи и обсуждать продукт, мы завели дополнительный канал в Slack «Сдай-сними-поговори». Теперь, если кто-то придумал новое решение, нашёл сервис, похожий на нас, или просто интересную статью, он закидывает это в канал и обсуждает с другими участниками. Получается непрекращающийся брейншторм. Сначала канал был только для команды «Сдай/Сними», но когда о нём узнали в Циан, туда стали проситься люди из других команд.

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

Попробовали разные методологии и адаптировали их под свой формат

Мы работаем по Agile, но подстраиваем его под себя. Формально у нас есть недельные спринты, но мы их редко соблюдаем. Процессы так часто меняются, что их постоянно нужно адаптировать под текущие задачи. Недавно мы перешли к смешанной методологии, которая больше напоминает Kanban.

Раньше команда делала больше 10 проектов одновременно. Все кросс-стековые, поэтому разделить их между участниками не получалось и каждый мог работать сразу над четырьмя. Это часто приводило к хаосу и рассинхрону в команде. Поэтому мы установили лимиты по work in progress. Теперь в работе может быть не больше трёх проектов, и пока хотя бы один не закончили, новые не берём (под проектом мы понимаем какую-то фичу).

Сначала мы каждую неделю проводили классические Agile-ретроспективы и обсуждали итоги спринта. Но потом поняли, что такой формат нам не подходит: разработчики были заняты своим проектом и не хотели выносить проблемы на общее обсуждение. Поэтому мы перешли на проектные ретроспективы. Теперь после запуска очередного проекта мы собираемся с ответственными разработчиками и всеми, кто работал над проектом. На встречах обсуждаем проблемы, формируем action points, выбираем ответственных по ним и делимся итогами со всей командой.

Под каждый проект мы собираем мини-команду.

Сначала выбираем ответственного разработчика — он управляет проектом, сообщает о проблемах техлиду и продакту, решает их. Это могут быть как небольшие задачи вроде перевода тасков по статусам в Jira, так и решение проблем с новыми техническими требованиями. А ещё он синхронизирует действия всех участников своей мини-команды.

Состав команды зависит от задач проекта. Например, есть исключительно бэкендовые или фронтендовые проекты, а есть фичи, для которых одновременно нужны бэкенд- и фронтенд-разработчики.

Из-за того что у нас часто, почти стихийно появляются новые идеи, мы не составляем окончательный список проектов на будущий квартал и не проводим классические встречи для их оценки. Разработчики и менеджеры скидывают идеи в общий канал, а потом вместе решают, что лучше подходит для достижения важных метрик. Но при этом непонятно, сколько времени и денег мы потратим на реализацию.

Поэтому сейчас эксперты от каждого стека регулярно собираются на встречах, где продакт описывает им концепты планируемых фич. Эксперты берут по одному проекту, дают предварительную оценку и собирают её с остальных участников. В результате бэклог идей пополняется полезными данными:

• мы понимаем, какие стеки нужны для реализации проектов;
• получаем примерную оценку затрат от других стеков;
• строим предварительную архитектуру проекта.

На основе этих данных можно эффективнее распределять ресурсы команды. Например, мы знаем, что на следующей неделе на три дня свободны мобильные разработчики. Смотрим в бэклог, находим фичи, которые помогут с нашими метриками, и оставляем те, которые можно сделать за три дня.

Стали поощрять развитие

У разработчиков «Сдай/Сними» есть перспективы как для горизонтального, так и для вертикального роста. Задачи всегда разные: можно повышать уровень технических навыков или углубиться в управление командой и стать тимлидом.

Сейчас три разработчика дошли до карьерного потолка на своих должностях. Двое из них теперь претендуют на роль тимлида, а третий выбрал путь эксперта — ему интереснее решать более сложные технические задачи, чем управлять командой.

Мы редко работаем над гипотезами больше двух-трёх недель. Обычно делаем небольшие фичи или дробим их так, чтобы максимально быстро запустить, проверить и, если нужно, переделать. С одной стороны, это придаёт нам гибкости, а с другой — мешает. Людей мало, а проектов, которые завязаны на одном специалисте, — много. Чтобы разработка не останавливалась, раньше приходилось точно согласовывать график работы и распутывать цепочки проектов.

Однажды наш Python-разработчик застрял на небольшой задаче по C#, а свободных шарпистов не было. Тогда, чтобы не ждать 2–3 дня, он сам узнал, как её решить, и написал код на C#. Постепенно этот разработчик стал брать больше задач на C#. Потом у него случилась похожая ситуация с мобильной разработкой. Конечно, по меркам программистов, которые пишут на этих стеках, задачи были лёгкие, но зато такая мелочь больше не тормозила разработку.

Потом мобильным разработчикам надоело застревать на бэкенде, закрывать задачи моками и ждать, пока появится подходящий API. Ведь даже если моки сработают, на бэкенде могут написать рабочие методы немного по-другому и проект развалится. Поэтому ребята стали плавно погружаться в бэкенд.

Сейчас из восьми человек в команде только двое не пробовали другие стеки, а питонист, с которого всё началось, уже пишет на C#, JavaScript и даже делает фичи под iOS. У других разработчиков есть основной стек и один дополнительный. Теперь ребята могут решать небольшие задачи на других языках, а проекты больше не завязаны на одном специалисте.

Собрали две самостоятельные команды по проверке гипотез

Так как продакт часто занят на стратегических проектах, которые длятся около месяца, у него не остаётся времени на быстрые эксперименты. А тестировать небольшие фичи вроде нового дизайна кнопки, нового баннера или заголовков нужно постоянно.

Mini growth team

У нас уже был middle-разработчик на C# с менеджерскими скиллами. Ему нравилось организовывать процессы и собирать обратную связь, поэтому он быстро влился в продукт и сразу начал предлагать идеи. В какой-то момент он сам стал проводить ретровстречи и даже запустил регулярный процесс по оценке здоровья участников.

Тогда же первый разработчик в команде вырос до fullstack. Поэтому мы решили собрать growth-команду, которая на костылях тестирует по несколько гипотез в неделю и отвечает за соответствующие метрики. В команду вошли product-лид (который middle C#), fullstack-разработчик и аналитик с исследователем на part time.

Product-лид решает целый ряд задач:

• настраивает процессы;
• организует брейнштормы;
• устанавливает приоритеты гипотез;
• отвечает за метрики;
• отслеживает эффективность команды.

Аналитик тратит по 8 часов в неделю на брейнштормы, приоритизацию и анализ гипотез, а исследователь доносит пользовательский фидбэк.

Перед началом спринта product-лид говорит, на какой метрике нужно сфокусироваться, а команда на брейншторме предлагает гипотезы. Потом каждый защищает идеи перед остальной командой и те, что прошли критику, приоритизируются по трём параметрам:

1) по вере в успех;

2) по влиянию на цели стартапа — например, баннер может хорошо работать, но лишь для 0,1% аудитории;

3) по сложности.

После этого гипотезы уходят к fullstack-разработчику, который их запускает.

Сейчас команда проверяет по четыре гипотезы в неделю, и на каждую у неё уходит менее 8 часов разработки.

Возможно, product-лид когда-нибудь окончательно уйдёт из C# в продукт. В growth team он получает реальный опыт, а не просто читает статьи и книги. Так что в будущем ничто не мешает ему стать продактом в нашей команде.

В начале квартала мы ставим цели, а потом встречаемся каждую неделю: обсуждаем точки роста команды и что product-лиду как руководителю нужно прокачать. Например, если гипотез на приоритизацию выносится меньше, чем хотелось бы, он придумывает, как выдавать больше. Иногда обсуждаем темы, с которыми он ещё не сталкивался, но которые хотел бы попробовать, — например аналитику.

Вообще, внутри команды люди часто погружаются в смежные направления, если сами этого хотят. Например, исследователь пользовательского опыта захотел уйти в аналитику, поэтому нынешний аналитик помогает ему разобраться в Google Analytics и с выгрузкой данных через SQL.

Команда по масштабированию сервиса

Когда growth team встала на рельсы и заработала самостоятельно, мы решили сформировать ещё одну команду.

Чтобы масштабировать сервис, нужно часто экспериментировать с оффером — пробовать разные тексты, визуалы и механики. Сейчас у пользователей баннерная слепота, они автоматически жмут skip, когда видят рекламу, поэтому продавать в интернете становится сложнее. Новые механики продаж выходят за рамки компетенций growth-команды, а выпуск и проверка гипотез по каждой занимают примерно неделю.

Когда один из наших разработчиков достиг уровня сеньора, ему хотелось расти до тимлида. Но в команде из восьми человек всем не получится стать тимлидами.

Поэтому пригласили его руководить командой по разработке офферов. Его задачей было организовать процессы так, чтобы команда запустила и проверила все N гипотез в указанный период времени. Таким образом разработчик прокачивал менеджерские скиллы, а мы наладили проверку гипотез по продающим механикам.

Помимо тимлида в команду вошли дизайнер, копирайтер и frontend-разработчик. Как и growth team, они выстраивают процессы без product-менеджера и решают полный цикл задач:

• брейнштормят идеи офферов;
• разрабатывают дизайн;
• проводят коллективное дизайн-ревью;
• запускают офферы;
• проводят аналитику после запуска.

Разработчик прокачивает скиллы тимлида: учится организовывать команду, релизить проекты в срок и настраивать процессы. Ему нравятся задачи, он сработался с командой и выдаёт хороший результат.

Бонус: что почитать, если хотите перейти из разработки в продукт или менеджмент

Одно из главных качеств продакта — насмотренность. Поэтому полезно смотреть и анализировать как можно больше кейсов. Когда я только собирался в профессию, выбор источников был очень скудный и приходилось собирать знания по крупицам. Сейчас в интернете полно материалов на русском языке.

Блоги — один из лучших источников кейсов и обучалок для продакта. Они помогают всегда оставаться в теме последних событий маркетинга и бизнеса, потому что информация там часто обновляется.

• В GoPractice не только дают теорию продакт-менеджмента и разбирают кейсы, но даже предлагают симулятор, чтобы погрузиться в управление продуктом.
• У Epic Growth есть целые сериалы по развитию IT-продуктов и канал с бесплатным контентом.
• Иван Замесин и Илья Красинский, практикующие эксперты и менторы, в своих блогах щедро делятся опытом и отвечают на вопросы о продуктовом менеджменте.
• На ресурсе Growth.Design детально разбираются user flow из разных продуктов и даются ссылки на научные статьи.
• На YouTube-канале «Академии Яндекса» есть плейлист «Школа менеджмента».

Из книг вы получите фундаментальные знания, которые помогут понять, как и почему работают процессы.

• Lean Startup — базовая теория по управлению стартапом. Советую начинать с неё.
• «Спросите маму: как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?» — как и зачем проводить пользовательские исследования.
• «Когда кофе и капуста конкуренты» — книга о пользовательских исследованиях и подходе Jobs To Be Done.

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