Feature Owner: как мы создаем эффективные команды junior-разработчиков с нуля

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

В этой статье я раскрою основные цели, которые мы поставили для реализации методологии, опишу гипотезы, а также раскрою ключевые особенности роли Feature Owner.

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

Проактивный подход, самостоятельность, умение принимать и отстаивать собственные решения - это те качества, которые мы решили воспитывать в специалистах с первых дней.

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

В один момент времени выстрелило несколько прототипов (да, бывает и такое), и перед нами встала задача срочно нарастить dev ресурсы для превращения прототипов в полноценные продукты. Все проекты находились на стадии бурного роста, поэтому времени на классическое формирование команд не было.

Условия, в которых мы оказались, были следующие:

Все разработчики и тимлиды активно работали на текущих проектах. Поэтому мы не могли выделить специалистов на новые проекты и сформировать под их руководством новые команды.

Новые проекты находились на стадии бурного роста в конкурентной среде. Следовательно, мы нуждались в активной разработке продуктов.

Несмотря на то, что прототипы показали хорошие цифры, успешность проекта надо было еще доказать.

Для решения задачи мы сформулировали несколько гипотез:

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

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

Таким образом, мы решили выделить отдельно роль лидера внутри команды джунов и назвали ее Feature Owner. Feature owner - это участник команды, который ведет фичу от идеи до реализации. Важно, что роль Feature Owner переходящая: каждый участник команды неоднократно побывает в этой роли.

Feature owner принимает задачу от бизнеса и чаще всего приступает к выполнению задачи с большой неопределенностью: на начальных этапах он не понимает, как делать ту или иную фичу, но четко понимает какую цель необходимо достичь.

Кроме того, Feature Owner составляет план, который мы называем Road Map.

Road Map помогает бизнесу и команде ощутить объем задачи и иметь общее представление о предстоящем пути. В будущем Road Map показывает, на каком этапе находится разработка и позволяет оценить, сколько еще времени понадобится команде для завершения задачи.

Таким образом, Feature Owner придумывает и реализует план достижения цели, а не просто движется по заранее заданному пути.

Feature Owner самостоятельно укомплектовывает одну или несколько рабочих групп и распределяет задачи между участниками. Feature Owner понимает, сколько ресурсов ему необходимо на текущем этапе и может высвобождать командные ресурсы для других Feature Owner’ов. Более того, Feature Owner выстраивает процессы наиболее оптимальным образом конкретно под текущую задачу.

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

Feature Owner является связующим звеном всех рабочих групп и обладателем полной информации о текущей фичи: все принятия решений происходят с участием Feature Owner.

Кроме этого, Feature Owner регулярно (раз в день) самостоятельно сообщает бизнесу промежуточные результаты.

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

После реализации фичи, Feature Owner проводит несколько презентаций. Всего их три:

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

На этом этапе Feature Owner получает фидбек от Senior-разработчиков. Так мы передаем наш технический опыт “молодым бойцам”.

Этот этап включает обсуждение фичи с точки зрения пользы для конечного пользователя.

Презентации могут иметь разный вид, в зависимости от объема и сложности задачи. Главная цель презентаций – защита решения во всех областях и получение опыта на всех уровнях. Благодаря этому Feature Owner понимает, как самостоятельно выдавать качественный результат.

1. В один момент может быть несколько Feature Owners. Они самостоятельно решают задачу распределения ресурсов команды. Даже если кому-то сейчас не досталось нужного количества ресурсов, Feature Owner не сидит на месте: часть времени он работает как разработчик на других задачах, а часть времени прорабатывает свой Road Map. Таким образом, ни одна фича не уходит из фокуса.

2. Feature Owner не выгорает, поскольку занимает эту роль непостоянно. Меняясь, ребята переключаются и успевают отдыхать.

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

4. Отказоустойчивая команда. Если участник команды на время “выходит из игры” (по причине болезни или отпуска), команда не проседает в производительности, поскольку у всех есть все необходимые знания и навыки.

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

6. Feature Owner высвобождает ресурсы более опытных разработчиков. Senior-разработчики участвуют в команде не постоянно, а присутствуют только на презентациях и code review финального результата, это оптимальное время для передачи опыта. Иногда сеньоры участвуют в рефакторинге кода или реализации сложных задач, чтобы передать свой опыт не на словах, а делом.

У вас могло сложиться впечатление, что мы высвободили ресурсы тимлидов, переложив все обязанности на Feature Owners. Теперь вместо тимлидов перегружены они. Все же, это не так: как только все ребята побывают “в шкуре” Feature Owner и начинают использовать полученные знания в обычной работе, нагрузка на Feature Owner спадает и распределяется равномерно по всей команде.

Процесс становится легким, эффективным и прозрачным, а вместо постановки конкретных задач Feature Owner указывает цель. Это и есть наш “секретный соус”.