Портал №1 по управлению цифровыми
и информационными технологиями

Нужен ли хорошей команде тимлид?

Уже довольно давно мне не дает покоя роль тимлида в команде разработки. Я пытаюсь понять цели, задачи и смысл этой роли. Мне интересно, какую ценность добавляет в команду эта роль и как эту ценность можно измерить. Больше всего вопросов к этой роли возникает при рассмотрении команд разработки в контексте гибких подходов. К примеру, скрамгайд эту роль отрицает полностью, нету в скраме работы для тимлида. Но скрамгайд еще много о чем не говорит, там и про тестировщика ничего не сказано. Разбираясь в этой истории, я не стану ограничиваться одним только скрамом.

Принципы и ценности, лежащие в основе любых гибких практик, требуют от команды кроссфункциональности и самоорганизации. Кроссфункциональность сама по себе не отрицает специализацию, и не требует, чтобы все в команде были в равной степени программистами, тестировщиками, аналитиками, DBA и бог весть кем еще. Возможно, и тимлиду в этой картине место тоже найдется?

Давайте немного порассуждаем на эту тему. Итак, зачем же команде, работающей в рамках гибких подходов, может быть нужен тимлид?

Поиски ответа на этот вопрос я начну со сбора задач, которые выполняли тимлиды, в тех командах, с которыми я работал за свою долгую карьеру в различных компаниях. Список выходит довольно длинный:

  1. Проектирование сложных технических решений
  2. Управление архитектурой
  3. Распределение задач внутри команды
  4. Ревью кода (тимлид как эксклюзивный ревьювер)
  5. Планирование работ, выполняемых командой
  6. Проектирование рабочего процесса команды и управление им
  7. Проведение регулярных и ситуативных собраний
  8. Уточнение требований
  9. Декомпозиция задач
  10. Оценка задач
  11. Определение стандартов написание кода и контроль их соблюдения
  12. Взаимодействие с внешними службами и другими командами
  13. Наставничество и обучение
  14. Участие в подборе новых сотрудников
  15. Проведение приемки результатов работы команды у заказчика
  16. Поставка результата в боевую среду эксплуатации
  17. Отчетность по работе команды
  18. Мотивация участников команды

 Почти два десятка пунктов! И, наверняка, я еще что-нибудь забыл. От тимлида ожидают исполнения значительной части этого списка в различных сочетаниях. Здесь видны задачи из нескольких областей: архитектура, разработка и менеджмент. При этом в большинстве случаев от тимлида еще ожидают самостоятельного написания кода. Кажется, это уже слишком.

тимлид

Давайте внимательно посмотрим на задачи из этого списка, при этом постараемся не забыть, что мы хотим иметь кроссфункциональную, самоорганизованную команду мотивированных профессионалов (кажется так об этом написано в манифесте).

Помогает ли нам в строительстве команды замыкание ответственности за архитектуру на одном человеке? Что мы получим в этом случае? В плане архитектурных решений команде будет нечего обсуждать и не о чем договариваться, все будет «как папа скажет». Примерно такая же история и со стандартами кода. Ценность их для отдельного разработчика Васи существенно понижается, если эти стандарты не выработаны им совместно с другими членами команды, а внесены тимлидом Петей. Тут можно возразить, что Петя должен согласовать с командой свое видение стандартов, но в большинстве случаев это согласование носит довольно формальный характер. Тимлид практически всегда имеет рычаг для продавливания своего мнения как по архитектуре, так и по стандартам кода. Примерно так же работает замыкание ревью на тимлида. Даже если предположить, что между лидом и остальными членами команды существенный разрыв в компетенциях, то не стоит замыкать ревью на лида, если конечная цель поднятие планки экспертизы в команде. Люди должны учиться, в том числе, и на своих ошибках. Знания в команде лучше всего распространяются перекрестным опылением, а не в режиме «одно окно». Компетентные сотрудники в хорошей команде должны делиться знаниями, но обладание высокой экспертизой не ставит носителя знания автоматически в привилегированное положение. Кажется, что в контексте архитектуры и разработки выделение отдельного человека в особую роль не добавляет измеримой ценности команде.

Теперь посмотрим на менеджерский функционал. Что у нас тут? Истории по управлению рабочим процессом, планированию, управлению содержанием и требованиями, а также по управлению людьми и взаимодействию с «внешним миром». Полезно ли вынесение этих активностей в отдельную роль? Кажется, да. Почему так? Потому что, с одной стороны, это разгружает остальную команду, освобождая время на написание кода и проектирование, с другой стороны – не всем программистам нравится много коммуницировать с заказчиками, коллегами из смежных подразделений и других команд и прочими людьми, участвующими в производстве. Миф о программисте-интроверте не всегда миф. На первый взгляд кажется, что тут ценность роли тимлида очевидна и безусловна. Но что получается в итоге? При благоприятном раскладе у нас получится крепкое, управляемое подразделение с сильным лидером. Самоорганизация? Нет, не слышали! Нужно договориться со службой эксплуатации? Наш тимлид Петя на больничном, а мы там никого не знаем… Командная ответственность? Это Петя задачки так нарезал, с него спрашивайте… В худшем случае мы получим детский сад с тимлидом-воспитателем.

Гибкие подходы предлагают дать команде как можно больше самостоятельности. Дать возможность принимать решения и совершать ошибки. Дать возможность людям стать командой и, изменяя себя, изменять окружающий мир. В этой парадигме люди запросто чувствуют фальшь, когда полномочия якобы передают команде, а по факту отдельному человеку. Команда сама должна решать, как именно будет выполнена работа. Это не должно быть решением лида и тем более не должно быть его ответственностью. Необходимо научить людей принимать совместные решения, даже в тех областях где принимать такие решения совсем не хочется. Команда должна уметь выстраивать интерфейсы взаимодействия с внешним миром, и это не должно быть прерогативой одного человека. Это не выйдет сделать быстро. Но на длинной дистанции это даст выигрыш в качестве и снижение хрупкости.

Совместный выбор и совместная ответственность должны иметь высший приоритет, если мы хотим получить именно самоорганизованную команду. Пускай Петя валидирует сложные архитектурные решения, если он сверхкомпетентен, но это должен быть выбор команды и у команды должно быть право в любой момент сказать Пете: «у нас как-то слишком много споров с тобой по архитектуре в последнее время, давай попробуем на пару недель передать эту историю Васе…». Тимлид не должен быть канализацией ответственности.

Я не луддит и не призываю немедленно разжаловать всех тимлидов. На определенном этапе развития команды сильный тимлид может быть полезен и как технический эксперт. и как организатор-модератор. Но при этом по мере развития команды, необходимо планомерно и аккуратно сужать полномочия лида и растворять его роль в команде. Команду нужно целенаправленно учить быть самоуправляемой. В хорошей команде должен быть лидер (а лучше несколько), но настоящему лидерству не нужны подпорки в виде должностей и ролей. Лидеры в команде должны подтверждать свой статус на практике, а не получать его по разнорядке.

Чтобы быть до конца объективным, стоит упомянуть еще один важный аспект. Позиция лида для многих разработчиков – это вполне понятная и осязаемая, формальная ступень карьерного роста. Если эта позиция устраняется, то возникает вопрос с карьерным ориентированием топовых разработчиков. Я понимаю, что ценности команды и неформальное лидерство могут быть факторами лояльности, но при этом вопрос «что можно предложить людям, ориентированным на вертикальный карьерный рост» для меня пока открыт.

«Kanban Flow Metrics: управление потоковым производством на основе данных»
Тренажёр про метрики на реальных примерах

Комментариев: 14

  • Леонид

    Не понятно, автор за красных, или за белых, то есть, нужен тимлид, или нет? Из собственного опыта: начальству всегда нужен конкретный человек, с которого можно спросить за качество, сроки, бюджет и т.п., так и появляется тимлид.

    • Павел Капусткин

      Автор за все хорошее, против всего плохого )
      Резюмирую, кратко для понимания – хорошей сильной команде тимлид не нужен.
      И не очень сильной команде он в какой-то момент начнет мешать становиться сильной командой, следовательно, тоже не нужен. А вот начальству нужна “канализация ответственности”. Начальству тимлид нужен. Но это уже совсем другая история про доверие прозрачность и безопасную среду.

      • Леонид

        У вас “другой историей” получается не только потребности начальства, но и создание “хорошей команды” и ее поддержание. По-моему, в этой теории слишком много допущений, чтобы быть похожей на реальную практику.

        • Павел Капусткин

          А “создание хорошей команды” это какой-то специальный навык? Обязательно ли для этого нужна выделенная роль “создателя и поддержателя”? Если самим людям обеспечить поддержку сверху и безопасную среду, они точно сами не справятся?

  • Если команда начинает высказывать тезисы “что-то мы много спорим с Петей по поводу архитектуры, давайте этим займется Вася”, то это неплохой маркер задуматься о смене команды на вменяемую.

    Тимлид – это высшая профессиональная квалификация разработчика программного обеспечения. Это сочетание квалификации, лидерства и навыков, которые позволяют охватить и обеспечить цикл “производства” продукта, решения комплектной целостной задачи.
    Наиболее рациональным использованием такого ресурса будут задачи совершенствования работы продуктовой команды, а также участие в ключевых для продукта и команды активностях: внешние и внутренние взаимоотношения, подбор персонала, вопросы качества кода/разработки, вопросы архитектуры, вопросы эксплуатации и взаимодействия с пользователями.

    Команда может решить, что роль тимлида ей не нужна, но перечисленные выше задачи все равно нужно будет решать, и для всех будет лучше, если это будут не джуниоры на аутсорсе. В нормальной команде всегда есть не один, а несколько лидеров наивысшей компетенции, закрывающих те или иные области ответственности в процессе разработки и эксплуатации продукта.

    Делать тимлида должностью не только не обязательно, но даже и вредно. Это не должность, а профессиональная роль. Прораб 🙂

    • Павел Капусткин

      Если команда вместо того чтобы проектировать “спорит с Петей за архитектуру” и уже на столько устала спорить, что захотела спасти архитектуру от Пети (или наоборот), то вопрос безусловно нужно задавать. Только это не вопрос о замене команды, а вопрос: “как мы до такого состояния дошли”.
      Когда рассуждают о тимлиде как о высшей квалификации разработчика, то как мне кажется, очень часто выдают желаемое за действительное. Действительно, очень хочется, чтобы лидом у нас был супермен, или бэтмен, а лучше оба сразу… Я практически не видел команд, где уровень квалификации лида существенно отличался бы от средней температуры по больнице. Те немногие исключения из этого правила, которые я наблюдал убеждают меня в том, что такой лид может создать управляемую структуру(иногда крутую), но не создаст самоорганизованную команду.
      Еще раз повторюсь, самоорганизованной команде прораб не требуется. Любое лидерство в такой команде должно быть добыто в бою, а не выдано приказом по отделу. И подтверждать свой статус, экспертизу и квалификацию лидеры должны постоянно.

    • > Тимлид — это высшая профессиональная квалификация разработчика программного обеспечения.

      Андрей, не обязательно. В такой трактовке под тимлидом объединяется направление экспертного развития в своей предметной области (как правило, разработке ПО) и направление управления персоналом. А это же два разных направления. Думаю, что имеется ввиду техлид, который вполне может быть высшей квалификацией разработчика.

  • Хорошая, годная заметка. Вопрос непростой, легко перерастающий в холивар, но аргументация позволяет (пока) не скатываться к убеждениям и эмоциональным оценкам.

    От себя добавлю, что полезно помнить о динамике развития команд. Команда в начале своего пути и зрелая команда – две большие разницы. В первом случае без тимлида (или иного разводящего) не обойтись. Зрелые команды искренне удивляются зачем нужны лишние люди.

    Потому вопрос Павла в самом начале заметки мне очень нравится: “какую ценность добавляет в команду эта роль?”.

  • Андрей другой

    Коллеги, а почему “тимлид”? Почему не просто – руководитель? Не, ну понятно, что как в том анекдоте/были можно и “группен фюрер” получить:)(тот же тимлид, только по-немецки).
    Короче – если ввести руководитель, то ответ становится, на мой взгляд, более простым. Нужен ли руководитель? Практически в любом случае, когда речь идет о некоем коллективе, ответ будет утвердительным. Кто должен быть руководителем? – для этого уже кажется целая наука существует. Из моего опыта руководителем должен быть наиболее опытный и квалифицированный специалист, способный принимать управленческие решения по технологии – “МЫ обсудили и Я решил”. Т.е. выслушал мнения всех членов коллектива, задал уточняющие вопросы (почему они так считают, а не иначе) и принял решение, обязательное для исполнения.

  • Петр

    Андрей, мне кажется Вы не поняли, что статья именно про самоорганизующиеся команды, которые работают БЕЗ руководителя по определению. Науку «кто должен быть руководителем» никто не отменял, но это другая наука.

    • Точно. Печаль в том, что очень многие воспринимают науку “начальник решит” как единственно возможную.

    • Андрей другой

      Команда – подразумевает как минимум несколько человек. Несколько человек – как минимум несколько мнений по тому или иному вопросу. Причем, каждое мнение обосновано и предлагаемые разные подходы имеют свои плюсы и минусы. Но реализован может быть только один. Как будет происходить выбор? Как будет реализовываться контроль за тем, что все придерживаются именно выбранного подхода? Так вот, руководитель – это не тот, кто декларирует обязательные для исполнения команды, а тот, кто в описанной ситуации берет на себя ответственность сделать выбор. Мне в свое время ИТ сотрудники одной из компаний жаловались на своего ИТ директора. У них было несколько решений для текущих проблем. У каждого был свой вариант, при этом каждый понимал, что вариант коллег тоже имеет право на существование. Они идут к ИТ директору, чтобы тот принял окончательный вариант и все готовы были его исполнять. Но ИТ директор говорит им – вы там сами между собой решите и тогда приходите ко мне. И вот как им в этой ситуации самоорганизовываться?

  • Андрей другой

    Хочу вот еще аналогию привесит – оркестр. Зачем им нужен дирижер? Каждый из участников – выдающийся музыкант, ноты у всех одинаковые. Казалось бы – играй что написано и проблем нет. Тем не менее.
    Хотя, для мелких коллективов, квартет на пример, обходятся и без дирижера:))

    • Денис

      Такое сравнение тогда нужно дополнить, что все зависит от произведения (проекта) и его стиля (сложности).
      Если IT проект жестко регламентирован или прост, то его нужно просто брать и делать “по инструкции” (играть по нотам в случае с оркестром). Если же требуется импровизация, то дирижёр будет неуместен.


Добавить комментарий для Павел КапусткинОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM