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

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

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

Как зародилась методология?

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

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

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

Почему мы решили применить методологию в компании?

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

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

  • Ограниченные ресурсы

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

  • Сжатые сроки и много горящих задач

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

  • Ограниченный бюджет

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

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

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

  • Команда джуниоров способна самостоятельно проходить путь от идеи до результата;

  • Начинающий специалист способен решать сложные задачи (просто не с первого раза).

  • Командная работа обеспечивает быстрый рост специалистов.

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

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

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

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

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

Об основных особенностях нашей системы вы можете прочитать в прошлой статье.

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

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

Что делает Feature Owner?

Формирует путь от цели до ее воплощения

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

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

Road Map помогает бизнесу и команде ощутить объем задачи и иметь общее представление о предстоящем пути. В будущем 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 понимает, как самостоятельно выдавать качественный результат.

Положительные эффекты от внедрения 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 Owner’ов – очень классно!

Финал

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

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

Другие наши статьи:

0
2 комментария
Панда Ву

Красиво пишите про команды джунов. Вот мне интересно, кого вы джунами считаете, бакалавра по информатике с 2 годами стажировочного опыта или выпускника гикбрейнс с творожком в голове? Скорее всего вопрос риторический. Учитывая, что у даже у синьоров процент техдолга по завершению крупных фич около 25%, представляю что творят команды джунов 🙄

Ответить
Развернуть ветку
Bulat Ziganshin

2 года опыта - это 2 раза по 3 месяца? LOL

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда