Project Manager, Product Manger и Team Lead — роли в команде разработки. Роли часто совмещающиеся. Полагаю, многие видели «начальника разработки», который и разработчиков нанимает, и отпуска подписывает, и code review делает, и самую ответственную часть проекта лично программирует. Как любят говорить владельцы бизнеса — «Нам нужен играющий тренер». Как любят шутить сами разработчики — «если взять хорошего программиста и повысить его до руководителя разработки, то вы потеряете хорошего программиста и получите неизвестно какого руководителя разработки. Скорее всего — плохого».
Как я уже писал, роль тим лида — это совсем не руководство разработчиками. Для руководства нужны совсем другие умения. Тимлид — это не прораб. Это генералист, синхронизирующий работу команды и компенсирующий недостатки человеческой природы с помощью костылей и велосипедов хитрой организации рабочих процессов. Более того, если в команде есть сильный проджект, то тим лиду даже нет необходимости саму знать, что и как организовывать. Проджект ему и про ежедневный стендап подскажет, и про автобилд, и с интервью по рискам поможет, и на эпической битве «табы против пробелов во внутреннем стандарте кодирования» подстрахует.
Из-за того, что исполняющие роль тим лида и проджекта должны много общаться друг с другом, эти роли нередко объединяют в одном человеке, «главном по разработке». Но у такого подхода есть и серьезные недостатки, потому что компетенции у этих ролей очень разные. Трудно найти человека, который одновременно будет хорошим менеджером, психологом, разработчиком и исследователем-генералистом. Некоторые компании сейчас экспериментирую с интересной моделью: роль тим лида отделяется от руководящих полномочий и передается наиболее подходящему в данный момент участнику команды. Так же как роль «ответственный за деплой» или «ответственный за ручное тестирование». При таком раскладе менеджер может «пробовать» в этой роли разных бойцов и смотреть, у кого лучше получается решать задачи. Эксперимент смелый и таких компаний пока очень мало, но я с интересом слежу за результатами и очень надеюсь, что подход себя оправдает.
Что бы вы ни выбрали: назначать тим лида как руководителя группы разработчиков, делать это почетной, но не руководящей работой в команде или же нанимать бойца со стороны, вам нужно будет выбрать того, кто сможет хорошо справиться с этой работой. Что тим лид должен делать, я уже писал. Как такого найти? Косвенным признаком является любовь к организации процессов. Если человек долго и со вкусом рассказывает про continuous integration, code review, тестирование и стандарты кодирования — то есть шанс, что он будет неплохим Team Lead. Или просто рассказывать любит. Таких ребят имеет смысл искать на профильных конференциях и смотреть вышедшие на рынок проекты, к организации выхода которых они приложили руку. Тут есть тонкий момент — вариант «пилил 10 лет внутреннюю СУВД для МВТК крупного международного венчурного фонда» не всегда является показателем. Многие внутренние проекты «пилятся вечно», так и не доходя до релиза. Сложность, все дела.
Многие компании «повышают» до тим лида лучшего разработчика в команде. А дальше см. шутку выше. Звучит дико, но умение хорошо разрабатывать программы слабо коррелирует с умением читать чужой код, организовывать процессы, выбирать лучший вариант по результатам экспериментов, искать риски и изучать новые технологии. Более того, умение хорошо программировать нужно постоянно поддерживать, желательно по 8 часов в день. А тим лид 8 часов в день применяет совсем другой набор умений. Я видел много ситуаций, когда самый сильный программист в команде, став тим лидом и перестав программировать полный рабочий день, за несколько лет становился фантазером-«космонавтом», приносящим компании только проблемы на ровном месте. Старые навыки он терял, новых у него не было. Лучший, на мой взгляд вариант — это когда тим лид поддерживает навыки разработчика на сторонних проектах, применяя там все новые и экспериментальные технологии, которые он изучает, чтобы иметь широкий кругозор. Об этом рекомендуется спрашивать на собеседованиях.
Если компания не готова терять хорошего разработчика в надежде получить годного тим лида, но к экспериментам с переходящей ролью тоже не готова, то остается рынок труда и собеседования. Этот же путь предстоит, если команда собирается под проект с нуля. Собеседование разработчика само по себе штука нетривиальная. Собеседование тимлида — нетривиально вдвойне. Как понять, что перед вами не космонавт-теоретик? Не ковбой-одиночка, решивший попробовать свои силы в чтении чужого кода? Универсального решения нет, но есть хорошо зарекомендовавший себя метод — спрашивать про процессы. Не «расскажите нам про виртуальный деструктор», а «расскажите, как вы организовывали code review в команде и с какими сложностями столкнулись». Не «перечислите паттерны проектирования по GOF» а «разработчик, отвечающий за релизы, заболел и лежит в больнице. Нужно срочно собрать брендированную версию. Ваши действия?». При этом смотреть лучше всего не на ответ, а на подход: о чем кандидат будет говорить в первую очередь, какие вопросы и в каком порядке задавать.
Также неплохо будет поспрашивать про основные сложности в разработке: проблему сложности, технический долг, кошелек Миллера (так его лучше не называть, термин мало распространен). Понимание таких вещей способно компенсировать недостаток опыта, а вот обратное верно не всегда. Ну и конечно, на помощь вам придет испытательный срок. Потому что самый лучший способ оценить разработчика — это дать ему писать код. А самый лучший способ оценить тим лида — дать ему этот код читать и помогать организовывать процессы.