Connect with us

Разработка

Григорий Петров: Где найти тим лида?

Что тим лид должен делать, я уже писал. Как такого найти?

Григорий Петров

Опубликовано

/

     
     

Project Manager, Product Manger и Team Lead – роли в команде разработки. Роли часто совмещающиеся. Полагаю, многие видели “начальника разработки”, который и разработчиков нанимает, и отпуска подписывает, и code review делает, и самую ответственную часть проекта лично программирует. Как любят говорить владельцы бизнеса – “Нам нужен играющий тренер”. Как любят шутить сами разработчики – “если взять хорошего программиста и повысить его до руководителя разработки, то вы потеряете хорошего программиста и получите неизвестно какого руководителя разработки. Скорее всего – плохого”.

Как я уже писал, роль тим лида – это совсем не руководство разработчиками. Для руководства нужны совсем другие умения. Тимлид – это не прораб. Это генералист, синхронизирующий работу команды и компенсирующий недостатки человеческой природы с помощью костылей и велосипедов хитрой организации рабочих процессов. Более того, если в команде есть сильный проджект, то тим лиду даже нет необходимости саму знать, что и как организовывать. Проджект ему и про ежедневный стендап подскажет, и про автобилд, и с интервью по рискам поможет, и на эпической битве “табы против пробелов во внутреннем стандарте кодирования” подстрахует.

Из-за того, что исполняющие роль тим лида и проджекта должны много общаться друг с другом, эти роли нередко объединяют в одном человеке, “главном по разработке”. Но у такого подхода есть и серьезные недостатки, потому что компетенции у этих ролей очень разные. Трудно найти человека, который одновременно будет хорошим менеджером, психологом, разработчиком и исследователем-генералистом. Некоторые компании сейчас экспериментирую с интересной моделью: роль тим лида отделяется от руководящих полномочий и передается наиболее подходящему в данный момент участнику команды. Так же как роль “ответственный за деплой” или “ответственный за ручное тестирование”. При таком раскладе менеджер может “пробовать” в этой роли разных бойцов и смотреть, у кого лучше получается решать задачи. Эксперимент смелый и таких компаний пока очень мало, но я с интересом слежу за результатами и очень надеюсь, что подход себя оправдает.

1457090798198112532

Что бы вы ни выбрали: назначать тим лида как руководителя группы разработчиков, делать это почетной, но не руководящей работой в команде или же нанимать бойца со стороны, вам нужно будет выбрать того, кто сможет хорошо справиться с этой работой. Что тим лид должен делать, я уже писал. Как такого найти? Косвенным признаком является любовь к организации процессов. Если человек долго и со вкусом рассказывает про continuous integration, code review, тестирование и стандарты кодирования – то есть шанс, что он будет неплохим Team Lead. Или просто рассказывать любит. Таких ребят имеет смысл искать на профильных конференциях и смотреть вышедшие на рынок проекты, к организации выхода которых они приложили руку. Тут есть тонкий момент – вариант “пилил 10 лет внутреннюю СУВД для МВТК крупного международного венчурного фонда” не всегда является показателем. Многие внутренние проекты “пилятся вечно”, так и не доходя до релиза. Сложность, все дела.

Многие компании “повышают” до тим лида лучшего разработчика в команде. А дальше см. шутку выше. Звучит дико, но умение хорошо разрабатывать программы слабо коррелирует с умением читать чужой код, организовывать процессы, выбирать лучший вариант по результатам экспериментов, искать риски и изучать новые технологии. Более того, умение хорошо программировать нужно постоянно поддерживать, желательно по 8 часов в день. А тим лид 8 часов в день применяет совсем другой набор умений. Я видел много ситуаций, когда самый сильный программист в команде, став тим лидом и перестав программировать полный рабочий день, за несколько лет становился фантазером-“космонавтом”, приносящим компании только проблемы на ровном месте. Старые навыки он терял, новых у него не было. Лучший, на мой взгляд вариант – это когда тим лид поддерживает навыки разработчика на сторонних проектах, применяя там все новые и экспериментальные технологии, которые он изучает, чтобы иметь широкий кругозор. Об этом рекомендуется спрашивать на собеседованиях.

software-testing-in-practice-19-638

Если компания не готова терять хорошего разработчика в надежде получить годного тим лида, но к экспериментам с переходящей ролью тоже не готова, то остается рынок труда и собеседования. Этот же путь предстоит, если команда собирается под проект с нуля. Собеседование разработчика само по себе штука нетривиальная. Собеседование тимлида – нетривиально вдвойне. Как понять, что перед вами не космонавт-теоретик? Не ковбой-одиночка, решивший попробовать свои силы в чтении чужого кода? Универсального решения нет, но есть хорошо зарекомендовавший себя метод – спрашивать про процессы. Не “расскажите нам про виртуальный деструктор”, а “расскажите, как вы организовывали code review в команде и с какими сложностями столкнулись”. Не “перечислите паттерны проектирования по GOF” а “разработчик, отвечающий за релизы, заболел и лежит в больнице. Нужно срочно собрать брендированную версию. Ваши действия?”. При этом смотреть лучше всего не на ответ, а на подход: о чем кандидат будет говорить в первую очередь, какие вопросы и в каком порядке задавать.

Также неплохо будет поспрашивать про основные сложности в разработке: проблему сложности, технический долг, кошелек Миллера (так его лучше не называть, термин мало распространен). Понимание таких вещей способно компенсировать недостаток опыта, а вот обратное верно не всегда. Ну и конечно, на помощь вам придет испытательный срок. Потому что самый лучший способ оценить разработчика – это дать ему писать код. А самый лучший способ оценить тим лида – дать ему этот код читать и помогать организовывать процессы.

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
 
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.