сли посмотреть на российский рынок тимлидских вакансий, то в подавляющем большинстве случаев мы можем увидеть примерно одинаковую картину. Я понимаю, почему она складывается. Иногда я даже не против. Но есть ряд замечаний, которые нанимающая сторона должна понимать.
И швец, и жнец, и на дуде игрец
Классика!
- Тимлид должен быть самым опытным разработчиком, умеющим запрограммировать самые сложные части приложения.
- Тимлид должен быть хорошим менеджером, чтобы хорошо управляться с командой разработчиков, грамотно управляться с процессом производства программного продукта и найти к каждому, от рядового сотрудника, до топ-менеджмента, свой индивидуальный подход.
- Тимлид должен быть мудрейшим рекрутером, чтобы генерить правильные вакансии, проводить лучшие собеседования, придумать класснейшие онбординг процессы.
- Тимлид даже должен быть немножко продактом, чтобы не бездумно исполнять, что скажет менеджмент, а вникать в предметную область, бизнес процессы, анализировать разные подходы к решению проблем и предлагать свои варианты.
Время не бесконечное
Пожалуй, не буду сейчас вдаваться в подробное обсуждение каждого пункта, ибо этот разговор явно не уместится в один пост.
Довольно частая ошибка, которая встречается повсеместно – ложные ожидания по трудозатратам. Если вы нанимаете человека, как полуменеджера / полуразработчика, то не надо ожидать, что он будет выполнять 100% работы разработчика, и еще 100% работы менеджера. Он даже по 50% выполнять это не сможет. В лучшем случае он будет по 40% тем и этим, а оставшиеся 20% он потратит в никуда на переключение между этими двумя ролями.
Зачем же он такой нужен?
Замечательный вопрос. Особенно у тех, кто никогда не сталкивался с ситуацией, когда менеджеры с разработчиками воюют, каждый гнет свою линию и в итоге вся команда и весь проект работают в режиме «лебедь, рак и щука».
Тут-то вам швец-жнец-тимлид и пригодится, чтобы всю эту компанию понять, подружить, направить по единому пути.
Что делать с вакансией?
Тут единого ответа у меня нет. Надо смотреть по ситуации.
Там, где маленькая команда, небольшой проект, то я бы нанимал тимлида по такой вот классической малоприятной схеме. Ибо при небольшой численности коллектива он будет в бОльшей степени разрабом и опытным товарищем, а в меньшей - менеджером (а там много и не надо).
Но есть и другие варианты, где больше команды, сложнее процессы, большее количество проектов – тут вариантов великое множество. Где-то тимлид – почти фултайм менеджер, где-то он внезапно техлид / архитектор, который отдает почти целиком менеджерскую часть другому человеку, а сам принимает функцию главного всея технаря. На таких масштабах роли начинают расслаиваться, бюджеты позволяют нанимать под определенные аспекты разных людей.
Итог
Найм тимлида – сложная и неоднозначная штука. Серебряной пули тут нет. Надо отталкиваться от текущей ситуации с командой, проектом, процессами. Главное – понимать, что существует ограниченный лимит времени + переключение между ролями тоже съедают какую-то его часть.