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