Как создать эффективную команду junior-разработчиков с нуля в кратчайшие сроки
Уже более пяти лет я запускаю команды начинающих ИТ-специалистов. Проработав множество подходов, я выработал уникальную технологию, которая дает поразительный результат: уже через месяц junior-команда начинает успешно выполнять бизнес-задачи.
Кроме того, команда работает инициативно, автономно и эффективно. И сегодня я хотел бы поделиться своим подходом с вами.
Почему именно junior специалисты?
Причин множество:
- Junior-разработчиков много: они живут в условиях мощной конкуренции за “место под солнцем”, поэтому готовы сделать практически невозможное, чтобы проявить себя.
- Джуны редко бывают избалованными: это сгусток потенциальной энергии и огромного желания, который, если направить в нужное русло, может свернуть горы.
- Джуниоры не только быстро обучаются, но и оперативно адаптируются к новым изменениям, способны нестандартно мыслить и предлагать оригинальные бизнес-решения;
- Начинающие специалисты быстро сплачиваются в команду, объединяя свою энергию в одну мощную волну.
Эти причины вкупе с энергией, большими амбициями и чувством нераскрытого потенциала позволяют ребятам достигать лучших результатов в кратчайшие сроки.
Недооцененные в IT-сообществе, Junior-разработчики - это действительно очень мощный ресурс, который стоит того, чтобы использовать его для решения сложнейших бизнес-задач.
Теория на практике: первые реальные результаты
За свой управленческий опыт я старательно оттачивал мастерство в работе с junior-командами, находил множество хитростей, которые давали положительный результат. Со временем все эти хитрости сложились в единую методологию.
Впервые я применил свою методику построения junior-команд в IT-проекте Zero2Hero. Идея проекта заключается в найме, формировании и запуске команд junior-разработчиков для создания прототипов IT-продуктов. Под каждый проект мы собираем команду с нуля.
Проект подтвердил, что выработанный способ управления командами реально работает: попав в боевые условия, всего за 2,5 недели ребята сделали практически невозможное: создали работающий прототип сложного E-commerce продукта, а в последствии получили заветное трудоустройство в крупных IT-компаниях.
Концепт
В концепте методологии я расскажу вам о трех важнейших аспектах:
- команде и ролях внутри нее;
- задачах и оценке результата;
- результатах применения метода.
Команда
Я ищу не конкретных людей, я формирую команду. Более того, я строю такую команду, которая в будущем способна стать одной из сильнейших в сообществе. В понятие “сильная команда” я не вкладываю идею коллектива, который состоит из сверхлюдей без слабых сторон.
Сильная команда — это такая команда, в которой слабые стороны одного участника перекрываются сильными сторонами другого.
Чтобы научить ребят работать в коллективе и чувствовать себя частью единого целого я ставлю задачу не каждому участнику в отдельности, а едино на всю команду.
В одной команде участвуют люди разных специальностей. Это программисты, QA, DevOps и т.д. Главная цель: команда должна содержать все необходимые квалификации для выполнения поставленной задачи.
Роли
Поскольку команда состоит из равноправных участников junior уровня, в ней нет тим лидов в классическом смысле. Но при этом должен быть кто-то, кто отвечает за финальный результат. Такую роль в команде мы называем Feature Owner. Этот тот, кто принимает задачу от бизнеса и формирует решение.
Feature owner:
- декомпозирует общую задачу на подзадачи и распределяет их по всем участникам команды;
- координирует работу всей команды;
- имеет финальное слово в различных спорах и принятиях решении;
- формулирует вопросы к менеджеру проекта в процессе разработки;
- отвечает за целостность решения;
- презентует финальный результат.
Получается, именно feature owner ответственен за достижение бизнес цели.
Секрет эффективности нашей модели в том, что все участники команды рано или поздно бывают feature owner: для каждой новой задачи роль feature owner передается от одного участника к другому. Это дает 3 положительных эффекта:
- Ребята знают обе стороны медали. Они понимают, что и как происходит как на месте разработчика, так и ответственного за результат. Ребята на своем опыте понимают, с какими сложностями сталкиваются тим лиды. Именно поэтому у нас нет болезней, вроде “начальник — дурак” и “подчиненные — бездари”.
- В один момент времени может быть (практически всегда) несколько feature owners, которые отвечают за разные задачи. Все вопросы по управлению ресурсами и “повисшими” задачами решаются внутри команды. При этом каждая задача находится в чьем-то фокусе внимания.
- В упрощенной форме и с правом на ошибку ребята получают навыки управления. Это помогает развить в команде автономность и проактивность.
Задачи
1. Мы построили такую систему, в которой бизнесу не нужно досконально расписывать задачу, поскольку команда может самостоятельно принимать решения. Более того, постановка задачи идет в виде диалога: мы ставим задачу в удобной для себя форме, команда задает вопросы и в конце митинга пересказывает задачу в комфортном виде. Так мы оцениваем, произошла ли передача задачи от бизнеса к разработке, и правильно ли мы поняли друг друга.
2. Мы не разделяем задачи на “сеньор” и “джуниор” уровни. Благодаря такому подходу, команда всегда решает самые важные бизнес-задачи, которые способствуют быстрому продвижению компании.
3. Мы учим команды самостоятельно принимать решения. Для этого мы полностью погружаем их в бизнес-процессы компании. Как только команда сможет взять на себя инициативу, мы переходим на управление с помощью целей, а не конкретных задач.
4. Мы работаем по принципу: сначала практика, потом теория. Команда сначала самостоятельно выполняет задачу, набивает шишки, а после получает обратную связь. Так ребята лучше усваивают информацию, поскольку накладывают ее на только что приобретенный опыт.
5. Команда регулярно сообщает менеджеру проекта промежуточные результаты. Это важно, поскольку у менеджера может потеряться понимание происходящего. Также, по промежуточным результатам менеджер может определить, что команда где-то “закопалась” и вовремя подсказать выход из этой ситуации.
Такая же модель передачи статусов происходит внутри команды между feature owner и всеми остальными. Обмен результатами очень эффективен, поскольку позволяет поддерживать осведомленность в асинхронном режиме. Это крайне важно для удаленной команды.
6. Поскольку во время выполнения задания команда постоянно принимает различные решения, то часто финальный результат выглядит не так, как предполагалось в начале. Поэтому каждую сделанную задачу команда презентует менеджеру проекта.
7. Чтобы оценить результат, мы построили несколько контуров обратной связи:
- Технический фидбек: даем команде перед презентацией финального результата. С его помощью мы помогаем команде определить проблемы в архитектуре, найти более легковесное решение, переиспользовать уже существующий код или узнать о подходах в решении подобной задачи в других командах.
Бизнес-фидбек: даем после презентации финального результата. С его помощью мы помогаем ребятам найти различные ошибки, связанные с незнанием бизнес тонкостей, процессов, плана развития проекта.
- Пользовательский фидбек: самый важный контур обратной связи. Позволяет понять, приняли ли пользователи наше решение, и следовательно, достигла ли компания своей цели.
Обратная связь на разных уровнях вместе с правилом “сначала практика, потом теория” позволяет нам всем лучше понять бизнес и принимать оптимальные решения.
Результат
Итого, мы получаем автономную, проактивную команду, которая может:
- принять задачу в любой форме;
- самостоятельно преобразовать ее на технический язык;
- под каждую задачу организовать внутреннюю работу команды наиболее эффективным образом;
- двигаться к достижению цели, принимая решения и сообщая промежуточные результаты;
Команда не просто делает то, что ей сказали, а может самостоятельно найти и защитить решение бизнес задачи. Ей не надо все разжевывать, просто укажи цель и не мешай. Для своей работы команда не нуждается в постоянном контакте с менеджером проекта.
Подобно космическому кораблю, команда имеет в запасе всего несколько минут для связи с “Землей” (читай менеджером проекта), после чего будет работать в автономном режиме, пока не завершит полный виток. Такой подход дает потрясающие результаты, при этом сильно разгружает менеджера, который, таким образом, может сосредоточиться на стратегическом планировании и на внешнем общении с другими проектами.
Методология глазами джуниоров
Казалось бы, ребята уровня junior, новенькие в компании, и на них сразу сваливается такая ответственность. По логике, они должны растеряться и запаниковать. Но этого не происходит, поскольку все участники команды одного уровня, приходят в компанию в один день и еще на берегу узнают “правила игры”.
Кроме того, перед всеми стоит общая цель - в кратчайшие сроки нарастить нужные умения junior-специалистов, с помощью которых они смогут решать сложнейшие бизнес-задачи. Мы чередуем самостоятельную работу команды с сессиями подробной обратной связи. Команда имеет возможность показать себя и почерпнуть опыт старших коллег. Таким образом, ребята быстро втягиваются в рабочий процесс и начинают выдавать отличный результат уже в первый месяц работы.
Да, они еще не работают как профессиональная и слаженная команда, но ведь чтобы начать играть в футбол, не обязательно учить правила и целый год тратить на тренировки. Достаточно просто взять мяч, найти сверстников похожего уровня и договориться о правилах игры. Только когда ты втянулся в процесс и влюбился в футбол, ты сможешь стать профессиональным игроком.
Почему это работает?
Наша система подходит не всем. Мы изначально ищем ребят, которым нравится наш подход. Мы показываем, что можно сразу получить первый коллективный результат и это не так сложно, как кажется на первый взгляд. После первых результатов у ребят появляется энтузиазм, загораются глаза, и они начинают верить в себя.
Это тот самый момент, когда они готовы вкладывать усилия, чтобы стать профессиональной командой, способной решать задачи мирового уровня. Они жаждут этого и готовы пройти этот путь. И мы им поможем, поскольку наша цель – вырастить первоклассные Senior команды.
P.S. Ребята - уже Senior специалисты, просто пока не знают об этом :)
Итог
Я не рассказал о множестве моментов: на какие хард и софт скиллы мы смотрим при поиске кандидатов, как выстроен процесс подбора, кто такой куратор и зачем он нужен, какие еще роли есть внутри команды, какие проблемы возникают на старте у команд и как мы их решаем, какие инструменты мы используем, как бизнес реагирует на подобные команды и многое другое.
На тему управления командой джунов я планирую выпустить цикл статей, а если вам понравится идея - проведу серию вебинаров, на которых подробнее расскажу о методологии и отвечу на ваши вопросы. Буду рад вашим комментариям.