Уже довольно давно мне не дает покоя роль тимлида в команде разработки. Я пытаюсь понять цели, задачи и смысл этой роли. Мне интересно, какую ценность добавляет в команду эта роль и как эту ценность можно измерить. Больше всего вопросов к этой роли возникает при рассмотрении команд разработки в контексте гибких подходов. К примеру, скрамгайд эту роль отрицает полностью, нету в скраме работы для тимлида. Но скрамгайд еще много о чем не говорит, там и про тестировщика ничего не сказано. Разбираясь в этой истории, я не стану ограничиваться одним только скрамом.
Принципы и ценности, лежащие в основе любых гибких практик, требуют от команды кроссфункциональности и самоорганизации. Кроссфункциональность сама по себе не отрицает специализацию, и не требует, чтобы все в команде были в равной степени программистами, тестировщиками, аналитиками, DBA и бог весть кем еще. Возможно, и тимлиду в этой картине место тоже найдется?
Давайте немного порассуждаем на эту тему. Итак, зачем же команде, работающей в рамках гибких подходов, может быть нужен тимлид?
Поиски ответа на этот вопрос я начну со сбора задач, которые выполняли тимлиды, в тех командах, с которыми я работал за свою долгую карьеру в различных компаниях. Список выходит довольно длинный:
- Проектирование сложных технических решений
- Управление архитектурой
- Распределение задач внутри команды
- Ревью кода (тимлид как эксклюзивный ревьювер)
- Планирование работ, выполняемых командой
- Проектирование рабочего процесса команды и управление им
- Проведение регулярных и ситуативных собраний
- Уточнение требований
- Декомпозиция задач
- Оценка задач
- Определение стандартов написание кода и контроль их соблюдения
- Взаимодействие с внешними службами и другими командами
- Наставничество и обучение
- Участие в подборе новых сотрудников
- Проведение приемки результатов работы команды у заказчика
- Поставка результата в боевую среду эксплуатации
- Отчетность по работе команды
- Мотивация участников команды
Почти два десятка пунктов! И, наверняка, я еще что-нибудь забыл. От тимлида ожидают исполнения значительной части этого списка в различных сочетаниях. Здесь видны задачи из нескольких областей: архитектура, разработка и менеджмент. При этом в большинстве случаев от тимлида еще ожидают самостоятельного написания кода. Кажется, это уже слишком.
Давайте внимательно посмотрим на задачи из этого списка, при этом постараемся не забыть, что мы хотим иметь кроссфункциональную, самоорганизованную команду мотивированных профессионалов (кажется так об этом написано в манифесте).
Помогает ли нам в строительстве команды замыкание ответственности за архитектуру на одном человеке? Что мы получим в этом случае? В плане архитектурных решений команде будет нечего обсуждать и не о чем договариваться, все будет «как папа скажет». Примерно такая же история и со стандартами кода. Ценность их для отдельного разработчика Васи существенно понижается, если эти стандарты не выработаны им совместно с другими членами команды, а внесены тимлидом Петей. Тут можно возразить, что Петя должен согласовать с командой свое видение стандартов, но в большинстве случаев это согласование носит довольно формальный характер. Тимлид практически всегда имеет рычаг для продавливания своего мнения как по архитектуре, так и по стандартам кода. Примерно так же работает замыкание ревью на тимлида. Даже если предположить, что между лидом и остальными членами команды существенный разрыв в компетенциях, то не стоит замыкать ревью на лида, если конечная цель поднятие планки экспертизы в команде. Люди должны учиться, в том числе, и на своих ошибках. Знания в команде лучше всего распространяются перекрестным опылением, а не в режиме «одно окно». Компетентные сотрудники в хорошей команде должны делиться знаниями, но обладание высокой экспертизой не ставит носителя знания автоматически в привилегированное положение. Кажется, что в контексте архитектуры и разработки выделение отдельного человека в особую роль не добавляет измеримой ценности команде.
Теперь посмотрим на менеджерский функционал. Что у нас тут? Истории по управлению рабочим процессом, планированию, управлению содержанием и требованиями, а также по управлению людьми и взаимодействию с «внешним миром». Полезно ли вынесение этих активностей в отдельную роль? Кажется, да. Почему так? Потому что, с одной стороны, это разгружает остальную команду, освобождая время на написание кода и проектирование, с другой стороны – не всем программистам нравится много коммуницировать с заказчиками, коллегами из смежных подразделений и других команд и прочими людьми, участвующими в производстве. Миф о программисте-интроверте не всегда миф. На первый взгляд кажется, что тут ценность роли тимлида очевидна и безусловна. Но что получается в итоге? При благоприятном раскладе у нас получится крепкое, управляемое подразделение с сильным лидером. Самоорганизация? Нет, не слышали! Нужно договориться со службой эксплуатации? Наш тимлид Петя на больничном, а мы там никого не знаем… Командная ответственность? Это Петя задачки так нарезал, с него спрашивайте… В худшем случае мы получим детский сад с тимлидом-воспитателем.
Гибкие подходы предлагают дать команде как можно больше самостоятельности. Дать возможность принимать решения и совершать ошибки. Дать возможность людям стать командой и, изменяя себя, изменять окружающий мир. В этой парадигме люди запросто чувствуют фальшь, когда полномочия якобы передают команде, а по факту отдельному человеку. Команда сама должна решать, как именно будет выполнена работа. Это не должно быть решением лида и тем более не должно быть его ответственностью. Необходимо научить людей принимать совместные решения, даже в тех областях где принимать такие решения совсем не хочется. Команда должна уметь выстраивать интерфейсы взаимодействия с внешним миром, и это не должно быть прерогативой одного человека. Это не выйдет сделать быстро. Но на длинной дистанции это даст выигрыш в качестве и снижение хрупкости.
Совместный выбор и совместная ответственность должны иметь высший приоритет, если мы хотим получить именно самоорганизованную команду. Пускай Петя валидирует сложные архитектурные решения, если он сверхкомпетентен, но это должен быть выбор команды и у команды должно быть право в любой момент сказать Пете: «у нас как-то слишком много споров с тобой по архитектуре в последнее время, давай попробуем на пару недель передать эту историю Васе…». Тимлид не должен быть канализацией ответственности.
Я не луддит и не призываю немедленно разжаловать всех тимлидов. На определенном этапе развития команды сильный тимлид может быть полезен и как технический эксперт. и как организатор-модератор. Но при этом по мере развития команды, необходимо планомерно и аккуратно сужать полномочия лида и растворять его роль в команде. Команду нужно целенаправленно учить быть самоуправляемой. В хорошей команде должен быть лидер (а лучше несколько), но настоящему лидерству не нужны подпорки в виде должностей и ролей. Лидеры в команде должны подтверждать свой статус на практике, а не получать его по разнорядке.
Чтобы быть до конца объективным, стоит упомянуть еще один важный аспект. Позиция лида для многих разработчиков – это вполне понятная и осязаемая, формальная ступень карьерного роста. Если эта позиция устраняется, то возникает вопрос с карьерным ориентированием топовых разработчиков. Я понимаю, что ценности команды и неформальное лидерство могут быть факторами лояльности, но при этом вопрос «что можно предложить людям, ориентированным на вертикальный карьерный рост» для меня пока открыт.
Не понятно, автор за красных, или за белых, то есть, нужен тимлид, или нет? Из собственного опыта: начальству всегда нужен конкретный человек, с которого можно спросить за качество, сроки, бюджет и т.п., так и появляется тимлид.