Как создать эффективную команду 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 специалисты, просто пока не знают об этом :)
Итог
Я не рассказал о множестве моментов: на какие хард и софт скиллы мы смотрим при поиске кандидатов, как выстроен процесс подбора, кто такой куратор и зачем он нужен, какие еще роли есть внутри команды, какие проблемы возникают на старте у команд и как мы их решаем, какие инструменты мы используем, как бизнес реагирует на подобные команды и многое другое.
На тему управления командой джунов я планирую выпустить цикл статей, а если вам понравится идея - проведу серию вебинаров, на которых подробнее расскажу о методологии и отвечу на ваши вопросы. Буду рад вашим комментариям.
А почему в причинах не упомянули самое очевидное: что джуниоры стоят намного дешевле?
Если в команде нет тимлида, то кто продумывает архитектуру решения, кто следит за качеством кода (соответствии стандартам кодирования и best practices, критериям поддерживаемости и безопасности)?
попав в боевые условия, всего за 2,5 недели ребята сделали практически невозможное: создали работающий прототип сложного E-commerce продукта, а в последствии получили заветное трудоустройство в крупных IT-компаниях
«Наговнокодили» (потому что ещё не умеют правильно писать сложные приложения) и ушли в закат? Команда сеньоров за 2,5 недели успеет только высокоуровнево спроектировать систему и реализовать базовую часть. Или же это действительно кривой и небезопасный прототип «на выброс», который дешевле переписать с нуля, чем как-то нормально поддерживать?
Добрый день.
1. А почему в причинах не упомянули самое очевидное: что джуниоры стоят намного дешевле?
Это, конечно, положительный фактор. Но не это самый главный. Да и очевидный. У нас нет первостепенной цели сэкономить. У нас есть цель сделать классную команду.
2. Если в команде нет тимлида, то кто продумывает архитектуру решения, кто следит за качеством кода (соответствии стандартам кодирования и best practices, критериям поддерживаемости и безопасности)?
Продумывает архитектуру – команда. Следит за качеством кода – сеньор разработчик. Именно поэтому перед презентацией проекта идет технический фитбек, где находятся и решаются подобные проблемы. Понятно, что в самом начале, решение команды – отстой. Но наша цель: научить их производить качественный код. Поэтому мы и делаем так, чтобы с самого начала ребята делали это самостоятельно, а не просто выполняли то, что придумает архитектор.
Хотелось бы увидеть портфолио проектов выполненных по этой методологии. Если нет - значит все это действительно бред, как подсказывает опыт.
Сейчас во многих крупных компаниях берут даже стажОРов. Вместе они возможно и сила, но это только если сами по себе проекты не требующие особой компетенции. А Это ооооочень тонкий лед))) Со стороны, если позволите это выглядит как, страшное дело доверять свои инвестиции под аутсорс, в которой под капотом дети. Для MVP еще можно, чтобы к инвестору не с пустыми руками.В целом я думаю, что большинство небольших веб студий за счет этого и выживает, когда не может себе позволить хотябы одного более менее зрелого спеца в команду, потому что дорого. В любом случае, успехов вам и здорово, что делитесь такими откровениями.
Полностью согласен про оооочень тонкий лед. Но наша система подходит не всем. Более того, она видоизменяется в зависимости от условий и целей. Из статьи это не совсем понятно, но поскольку это вводная статья, я решил ее не перегружать. Ситуация следующая: в Zero 2 Hero есть своя специфика. Мы делаем прототип в максимально короткие сроки( максимум за 4 недели). И важно понимать, что прототип - это не MVP. Он не будет долго жить, но зато его можно сделать быстро и дешево. Прототип нужен только для того, чтобы проверить гипотезу, и если она верна, то можно отправляться к инвесторам и создавать полноценный и качественный продукт. Прототип прост в реализации: не нужно думать об архитектуре, отказоустойчивости, расширяемости и поддержке. Поэтому с данной задачей может справиться джуниор-команда (под руководством сеньор специалиста).
Подобную схему мы также запустили и в другой продуктовой компании (не аутсорс). Изначально у нас были только сеньор команды, но хороших сеньоров найти очень сложно. Поэтому мы решили параллельно растить своих сеньоров. Главная задача, которая стояла передо мной: как взять молодых специалистов и быстро дорастить их до сеньоров. При этом важно, чтобы junior команда как можно раньше начала приносить пользу бизнесу, чтобы этот "образовательный" проект не сильно тянул компанию вниз. Так и родилась данная методология. Именно junior разработчики непосредственно решают сложные задачи. А наши и без того занятые сеньор разработчики выступают в роли кураторов - посредников между бизнесом и разработкой. Не тратя много времени, сеньоры помогают командам доводить их решения до приемлемого качества. Таким образом, бизнес всегда получает результат приемлемого качества. Сеньоры не участвуют внутри процесса реализации фичи, экономя свое время, но контролируют качество фичей на выходе. Они дают полезный фидбек командам, который помогает ребятам расти. Получается, образование происходит на реальных задачах, продвигая бизнес вперед и позволяя дешево растить будущих спецов внутри.
Важно понимать, что это статья посвящена тому, как растить джуниоров внутри компании, а не про то, как выполнить бизнес-задачи с помощью дешевой рабочей силы.
если снять лапшу, то вы даёте заказчику говнокод и ничему не учите детей. люди в теме над таким только посмеются
Все так раскритиковали эту методику на счёт джунов. Всем нужны сразу сеньоры. Тогда позвольте спросить, сеньорами сразу рождаются или как? Джунам тоже нужно как то набираться опыта.
Я согласна с автором статьи: многие специалисты действительно хороши (сеньоры или мидлы по уму), но им просто не дают раскрыться и показать себя (ибо на них «джун» висит, как клеймо).