# Знание технологического стека команды
# Описание
Тимлид может руководить разработчиками как одного профиля, как обычно встречается в функциональной структуре организации, так и разных, как бывает в кроссфункциональных командах. Для того, чтобы управлять командой, тимлиду нужно ориентироваться в технологическом стеке этой команды – языках, фреймворках, инструментах, экосистеме, архитектуре, лучших практиках.
В случае функциональной команды обычно не возникает много вопросов, так как руководителем её часто становится опытный разработчик того же технологического стека. Все обстоит гораздо сложнее для кроссфункциональных команд, где одновременно нужно ориентироваться в iOS, Android, Frontend, Backend, тестировании, базах данных и часто в чем-то ещё.
# Почему ветка важна?
Для тимлида:
- Можешь оценивать качество технических решений
- При необходимости можешь закопаться в работу конкретного сотрудника и оценить качество его работы
- Получаешь возможность спокойно общаться со стейкхолдерами команды без необходимости привлечения кого-то из разработчиков
- Понимаешь обоснованность сроков разработки или опасность технического долга
- Находишь общий язык со всеми разработчиками и не выглядишь для них бесполезной прослойкой
Для команды:
- С технологически грамотным тимлидом проще договориться по вопросам сроков, внедрения новых технологий или закрытия технического долга
- Тимлид, обладающий более широким контекстом в вопросах понимания стратегии бизнеса и продукта, даёт полезный взгляд на архитектурные компромиссы
Для отдельного сотрудника:
- Тимлид может оценить твой уровень не только по внешнему эффекту, но и по сути сделанной работы
# Что будет, если её не делать?
- Тимлид не может оценить оправданность сроков разработки
- В команде могут проявиться конфликты из-за сроков
- Разработчикам придётся идти на неприемлемые компромиссы, из-за чего резко вырастет количество технического долга и упадёт качество проекта
- Тимлид не может оценить долгосрочное влияние принимаемых решений
- Решения принимаются неоптимальные и выстреливают команде в ногу через какое-то время
- Команда будет заниматься не тем, что действительно полезно, а тем, что интересно или весело
- Тимлид не может работать автономно и для ответа на любые технические вопросы привлекает кого-то из команды
- Команда не будет считать его своим лидером
- Стейкхолдерам тимлид будет казаться некомпетентным
- Тимлид не может оценивать качество работы своей команды
- Повышения раздаются несправедливо
# На кого может быть делегирована?
Может быть делегирована на отдельных разработчиков в команде, которые становятся "чемпионами" своей платформы или функции.
# Примеры поведения
# Примеры плохого поведения
- Тимлид не пытается вникнуть в суть принимаемых в его зоне ответственности технических решений
- Тимлид не пытается разобраться в базовых особенностях разработки всех компонентов системы, за которую он отвечает
- При обсуждении любых технических вопросов тимлид не справляется и вызывает кого-то из разработчиков
- Все вопросы, касающиеся архитектуры или планирования незнакомой тимлиду платформы, проходят мимо внимания тимлида
- Тимлид пытается стать экспертом во всех областях, за которые он отвечает
# Примеры хорошего поведения
- Тимлид не стесняется своей некомпетентности и со временем пытается её уменьшить
- Тимлид задаёт простые вопросы, чтобы разобраться в проблеме на незнакомом стеке хотя бы на базовом уровне
- Тимлид регулярно решает простые задачи из разных функциональных областей
- Тимлид одинаково погружён во все технологические области, включая и ту, в которой у него есть собственный background
# Способы прокачки
# Практика
- Составьте карту знаний, которых вам не хватает. В этом может помочь инвентаризация всей системы, за которую вы отвечаете, или открытое обсуждение со всеми разработчиками в команде. Чаще всего они спокойно отвечают на вопрос "Чему я должен научиться, чтобы разобраться в твоей системе?" и могут посоветовать способы эти навыки прокачать.
- Постепенно обучайтесь по этой карте. Ваша задача – не стать экспертом во всех технологиях, а разобраться в них на базовом уровне, понимать плюсы и минусы.
- Берите простые задачи из бэклога команды, которые помогут самостоятельно что-то сделать в каждой из вверенных вам технологических областей. Это поможет попробовать всё на практике, разобраться в инструментах. А как бонус – ещё и доверие команды поднимется.
- Не стесняйтесь задавать очень глупые вопросы на обсуждениях сложных для вас областей. Такие вопросы часто помогают увидеть какие-то фундаментальные просчёты или новые возможности.
- При общении с разработчиками незнакомой вам области выписывайте все незнакомые термины, а после этого пытайтесь в них самостоятельно разобраться.