Сегодня хочу немного поговорить о роли TTL в разработке. TTL, Technical Team Lead (далее тимлид) — это предводитель команды разработчиков. Что он делает? Очевидно, ведёт процесс вперед. А точнее:
- пропускает через себя входящие запросы на разработку;
- добавляет к ним примерные концепции реализации;
- снабжает проект информацией о технической стоимости работы (напр. оценкой работы в часах);
- принимает тактические решения по способам реализации той или иной задачи, а в отсутствие отдельного архитектора — и стратегические тоже;
- разбирает с командой сложные и проблемные случаи.
А чего тимлид делать не должен? По моему глубокому убеждению, самое главное чего не должен делать тимлид — он не должен решать задачи за разработчиков.
То есть, конечно можно самому разрабатывать — отдельно и заранее назначенные на себя задачи. Совсем не участвовать в активной разработке непросто, хочется ведь. Хотя при этом нежелательно забирать себе все самое вкусное и оставлять остальным разработчикам сплошной гринд.
Но ни в коем случае не нужно каждый раз, когда возникают проблемы или сложности (а они всегда возникают) решать всё самостоятельно. Бывают такие руководители, которые в силу разных причин при малейшей проблеме занимают позицию «ладно, я сам всё сделаю, иди пока ссылки в другой цвет перекрась».
Но все дело в том, что разработчик (во всяком случае, если он хороший разработчик) должен развиваться. Всегда. Это часть профессии. Именно та часть, из-за которой многие из нас вообще делают вот это вот всё. Чтобы разобраться. Решить задачу. Сложить паззл.
Конечно, развитие отдельно взятого разработчика может быть не важно для развития проекта (в случае субподряда например) в целом. Но это очень важно для разработчика. Поэтому, если каждую проблемную задачу переназначать или забирать себе, разработчику в проекте станет неинтересно. А отсутствие интереса не замедлит отразиться и на отношении к работе.
Что должен делать тимлид в случае проблем — так это поддерживать разработчика. Советовать, изучать код вместе, проговаривать, совещаться и объяснять.
Рабочие совещания тимлид — разработчик вообще довольно полезны. Мне доводилось быть лидом у ребят, которые разбираются в предмете совершенно не хуже меня. Но даже им было нужно регулярно обсуждать суть той или иной задачи, изучать код, приходить вместе к верным архитектурным решениям, или даже просто — получить лишнее подтверждение, что они на верном пути. Как говорится, одна голова — хорошо, а две головы — это уже полицефал.
Самой сложной лично для меня в данной роли всегда была ситуация, когда видно, что разработчик не вывозит. Не конкретную задачу, а не вывозит в принципе. Ты объясняешь, проверяешь, даешь время, проходит неделя, другая:
— Что не так?
— У меня ошибка.
— Какая?
— Вот эта.
— Но она же была неделю назад, мы обсуждали что надо попробовать вот так, попробовал?
— …
И так бывало даже с людьми, называвшими себя senior developer. Но тут ничего не поделаешь, приходится просто прощаться.
Ну и напоследок стоит отметить, что конечно данная роль требует большой ответственности. То есть, с моей точки зрения, ответственно нужно подходить к любой работе, но в данном случае тимлид ответственен за всё техническое, что происходит в проекте. Любой косяк, не успели сделать что обещали, регрессия в продакшне — в конечном итоге за это отвечает тимлид. И ни в коем случае нельзя за пределами команды валить косяки на кого-то из разработчиков.
На этом всё пока, всем тимлидам — понимания, терпения и ответственности!
