Вождь разрабчьей стаи
1. Сепаратные тропы альфа-разрабов
Никто, кто не был в крупных фирмах не поверит, однако проблема общения в них часто контузит разработку не вследствие слабости, а вследствие силы команды. Такие фирмы могут позволить себе нанять топовых программистов: с большим опытом и, при этом, способных на творческие решения, с горящим в сердце чистым пламенем воинов исходного кода. Такие альфа-разрабы готовы ломать бетонные стены и броню, любая проблема для них — вдохновляющий вызов.
Кроме шуток, кажется, такая команда это рай для разработки. Дай любую задачу — сделают топовое, уникальное решение и спросят что ещё доработать.
Вас, однако, пусть не вводит в заблуждение этот мнимый оазис разработки. Рай легко оборачивается адом. Альфа-разрабы часто зациклены на себе. Им сложно общаться, потому что у каждого есть окрепшая система убеждений.
Не просто так к этому разделу прилагается картинка из известного мема. Загадка: как по-вашему продолжится путь волков если представить что они — альфа-разрабы на топовом проекте без правильного руководства?
Остановит ли что-то настоящего альфа-волчару? И что будет, если каждый будет с мощными лапищами? Думаю, вы догадываетесь…
Войну не предотвратит и тропа протоптанная первым шерстяным лидером. Каждый будет ломиться сквозь снег в своём направлении.
2. Battle royale driven development
Не удивительно что вышедшие из-под контроля альфа-разрабы устраивают побоище в коде. Митинги они часто воспринимают как бессмысленное убийство времени. У каждого в голове — свой проект. У каждого чешутся руки попробовать сделать «так как надо». То есть, для каждого по-своему.
«Прекращайте» — скажите им — слушать не будут. Сущности в коде без единства в подходах плодятся не просто сверх надобности — прут через все дыры забыв про приличия. Дублирующиеся решения, архитектурные красоты, изыски замешанные на моднейших технологиях. Часть поделок приживается, часть остаётся уделом их создателей. Новые программисты, конечно, тоже альфа-разрабы (фирма-то топовая) — быстро устают разбираться где что принято использовать. Понимают по каким правилам здесь играют, расчехляют креатив-пушки и фигачат каждый своё-что-придётся.
Говорить с альфа разрабами также непросто. Это люди технической веры. Угукнут менеджеру, мол, «понял, принял» — и тихонько продолжат свою священную битву за красоту в коде.
О, и, конечно, самое обидное… Решение каждого в этой бойне — качественное и крепкое. Они ведь действительно хороши, чертяки. Люди с опытом и волей к действию. Если бы не бесконечная битва за Правду (которая у каждого своя) — проект стал бы лучшим в мире. Можно ли что-то с этим сделать?
Политике разнузданного креатива может положить конец лишь одно — разделяемый всей командой авторитет.
3. Вождь-техлид
Всеми альфа-разрабами может командовать технический вождь — разработчик, задающий маршрут которым будет следовать другие разработчики.
Силами своей экспертизы и авторитета технический лид может навести порядок в подходах к разработке. При этом хорошо если он практически не будет участвовать в разработке фичей. Его задача — задавать другим единую тропу развития кодовой базы.
Избегайте сомнений в этом вопросе — команда разработчиков не волшебная коробка в которую насыпаешь крутых разрабов, закидываешь задачи и на выходе получаешь быстрый в расширении, качественный код. Контроль альфа-разрабам нужен не меньше, чем начинающим программистам. В отличие от сомневающихся в своих силах джунов, альфа-разрабы могут много и делают много. Если в их действиях нет единства, вреда от этого может быть больше, чем от скудных изменений робких парнишек ступающих первые шаги в разработке.
Мобилизации сверхусилий перед релизами также можно избежать благодаря контролю подобного человека. Техлид поможет проложить с холодной головой тропу критических фиксов, и также спокойно отследит демонтаж костылей после того, как предрелизная горячка схлынет.
Идеальный техлид должен обладать следующими качествами:
Неоспоримый технический авторитет. Самое важное — качество. Нужно чтобы все альфа-разрабы до одного были согласны: это — лучший технический эксперт в команде.
Да, к счастью, в айти не закон джунглей, здесь Акелле допустимо промахиваться. Но регулярных ошибок альфа-разрабы всё же не простят и организация посыпется. Начнутся игры в подполье с подколками техлида, непроговоренными презрением и обидами на техлида за неграмотные решения.Готовность брать на себя ответственность. Не выбирайте вождя, который не готов брать на себя ответственность и вести за собой команду.
Готовность быть ментором. Хороший техлид 80% времени занимается преподаванием. Он может практически не писать прикладной код на проекте. Техлид как ДНК в клетке, определяет принципы разработки кода. Если техлид не готов терпеливо учить людей — это плохой техлид.
Одно из ключевых мест использования менторского мастерства техлида это качественное ревью кода. Нет ничего лучше обучения на примерах. И нет примера лучше чем практические ситуации в живом коде.Умение говорить. Техлид должен уметь говорить так, чтобы все внимали его словам. Нельзя чтобы его постоянно перебивали, нельзя чтобы он замолкал под давлением обсуждений других альфа-разрабов. Он должен быть ведущим на встречах технической команды.
Именно техлиду проговаривать финальные решения по результатам встреч: твёрдо и веско, и при этом с уважением к команде.Умение слышать. Как было сказано в прошлой статье, нельзя научиться говорить убедительно не научившись слышать. Техлид должен выслушать разные мнения и донести до высказывающих эти мнения людей своё понимание: плюсы и минусы их решений.
Вежливость. Техлид должен уметь благодарить и отмечать достижения. Вожак который лишь приказывает и раздаёт тумаки любим не будет.
4. Как выбрать техлида
Диктатура — не лучший способ управления разработкой. Техлид должен давать простор для действия команды, направляя её советами -, но не навязывая решения лишь своим авторитетом. Выберете слишком жёсткого в продавливании решений техлида — получите вместо порядка на проекте новой уровень битвы всех против всех: с антилидовым подпольем, подколками и затаёнными обидами.
Рухнет, с другой стороны, и та организация, в которой техлид займёт позицию ментора без воли и полномочий влиять на команду. Последнее слово в решении крупных технических вопросов должно быть именно за техлидом.
Свобода творчества, направляемая здравым смыслом техлида, как самого опытного разраба на проекте — лучшая политика.
Победит баланс между творчеством и порядком.
Советы по выбору техлида:
У вас не так много попыток. Техлид — крайне важный для команды человек. Поменять его будет тяжело. Если поменяете — у технической команды будет недоверие к следующему лиду и к вам как к менеджеру проекта.
Выбирайте техлида так, словно от этого зависит жизнь проекта. Подобная постановка вопроса близка к истине.Техлида проще выращивать из старожилов проекта. Экспертиза бывалых чуваков известна команде. Им не нужно доказывать свой авторитет.
Будьте чутки к команде, не допустите ошибку в выборе.Если брать со стороны — вовлекайте команду в выбор. Предложите разрабам составить опросник для кандидата. Каких знаний они ждут от техлида? Пусть сами зададут планку знаний, которую считают достойной.
Отберите вместе с авторитетным альфа-разрабом 20–30 вопросов и устройте кандидату марафон. Если посыпется на вопросах команды — значит потеряет в глазах команды авторитет.Вы очень вряд ли найдёте человека идеально совмещающего все необходимые компетенции на высоком уровне. Вам, как менеджерам, нужно будет оказывать поддержку техлиду по тем скиллам, которые у него не закрыты. Как правило, основные трудности возникают в коммуникативных навыках.
Не жадничайте с компенсационным пакетом для техлида. Высокая техническая экспертиза, умение брать на себя ответственность, способность совмещать уникальный набор умений — человек объединяющий столько разновекторных качеств должен получать достойные деньги.
5. Заключение
Техлиды, на первый взгляд, могут казаться бесполезными людьми. Такое ощущение возникает потому что они не настолько вовлечены в прикладную разработку как остальные программисты. Однако команда сильных и творческих индивидуальностей не будет работать как единое целое без техлида. Для эффективной разработки на любом проекте необходима магистральная тропа развития и тот, кто её задаёт. Нужен один человек, который сумеет донести свою мысль каждому альфа-волчаре и объединить заслуженным авторитетом все мощные лапищи.
