Знакома ли вам ситуация: тимлид распределяет задачи, всё делает сам, а на свой профессиональный рост и поддержку компетенций вечно не хватает времени? Без него в команде ничего не решается, и поэтому он становится «узким горлышком» в процессе. Отпуск откладывается, ведь без незаменимого лидера всё рухнет. Так происходит годами, и ничего не меняется.
В этой статье я поделюсь алгоритмом, который я использовала в собственной практике, как тимлиду выбраться из рутины и сделать команду автономной.
В 2023 году меня пригласили в крупную ритейл-компанию провести Agile-трансформацию. Нужно было уменьшить time-to-market (T2M) и адаптировать команды к меняющимся бизнес-целям. В работу я получила пять доменов, в каждом — в среднем по пять сервисных и пять продуктовых команд.
Почти во всех командах тимлида назначило руководство. Чаще всего ими становились опытные архитекторы или разработчики. Многие из них были не очень довольны таким назначением, ведь к старым обязанностям добавились еще и новые. Им приходилось выстраивать процессы в команде, взаимодействовать с подрядчиками, командами и лидами из других доменов. Кроме того, добавились новые инструменты для трекинга задач и сбора метрик.
В итоге лиды стали посвящать девяносто процентов своего времени текучке и уже не успевали заниматься развитием команды и себя. Они жаловались на выгорание, постоянное напряжение и работу по выходным. Кто-то даже отказался от отпуска, чтобы работа не стояла, и команда быстрее закрывала важные задачи. Во время интервью многие лиды сказали, что не хотели бы играть эту роль в команде, а некоторые время от времени думали об увольнении.
После аудита я применила такой алгоритм действий:
1. Провести STATIK-воркшоп
![](https://habrastorage.org/getpro/habr/upload_files/c18/7fd/9b0/c187fd9b0698793f889de55558806d97.png)
Этот подход позволяет быстро запустить канбан-систему на основе знаний о процессе, полученных во время проведения воркшопа, а также помогает в командообразовании. Некоторые команды были созданы недавно, и STATIK помог участникам познакомиться. В результате команды создали канбан-системы, учитывая все нюансы процесса, с которым они работают, записали описание команды (что команда делает и чего не делает), определили правила, по которым они будут работать, и согласовали эти правила с заинтересованными сторонами и подрядчиками.
2. Договориться о правилах приоритезации
![](https://habrastorage.org/getpro/habr/upload_files/534/065/27e/53406527e8dfa177c9c567b6a7a82084.png)
Мы использовали классы обслуживания как основной метод приоритезации.
3. Прописать DoD и DoR (Definition of Done и Definition of Ready)
На STATIK-воркшопе мы определили для каждой команды точки взятия обязательств и точки готовности к внедрению функционала. Также описали DoD и DoR и согласовали их с заинтересованными сторонами. В некоторых случаях мы проработали DoD и DoR для нескольких переходов между статусами процесса.
4. Установить основные каденции
![](https://habrastorage.org/getpro/habr/upload_files/a94/d9e/25d/a94d9e25dd9f9c73e1a04c1137c01a98.png)
Мы выбрали три обязательные канбан-каденции (канбан-летучка, пополнение потока и обзор потока). Также добавили регулярное выравнивание бэклога с заинтересованными сторонами. Для каждой встречи прописали план, тайминг, цели и ожидаемый результат.
5. Убедиться, что все участники процесса в курсе введённых правил
В каждой команде мы определили заинтересованные стороны и нанесли их на карту заинтересованности и влияния. Затем провели серию встреч с ключевыми заказчиками и участниками процесса, чтобы согласовать новые правила и адаптировать их для совместной работы.
6. Провести Star map
![](https://habrastorage.org/getpro/habr/upload_files/c14/493/13e/c1449313e956920799e2b5e7f45789d8.png)
Провели проверку состояния компетенций каждой команды и выявили узкие места, где нужны поддержка и развитие. Выработали план для развития самых необходимых и недостающих компетенций.
7. Провести мастер-классы по использованию систем таск-трекинга и сбора метрик
Чтобы каждый участник команды понимал, как инструменты для сбора метрик работают и как их настраивать, мы проводили мастер-классы. Каждый участник сам попробовал настроить и получить необходимый отчёт или выгрузку данных.
В результате этих действий у команд появилось понимание правил приоритезации, и теперь им стало понятнее, какой запрос стоит брать первым в работу. Это сняло с тимлидов нагрузку по назначению задач на исполнителя. Теперь участники команд сами разбирают задачи.
Появились регулярные встречи с заказчиками, на которых уточняются требования и сроки реализации. Командам и бизнесу стали понятны критерии готовности задач к реализации и закрытию, что позволило команде не сомневаться о том, что они берут в работу и будет ли это принято заказчиком.
Стали понятны инструменты визуализации и взаимодействия с заказчиком и смежными командами, за счёт этого повысилось доверие к команде, лидам не приходится вручную заполнять Excel-файлы с данными по задачам каждую неделю.
Команды стали понимать, какие компетенции необходимы, чтобы команда была способна функционировать при возникновении рисков. Появились негласные лидеры, на которых делегируется часть задач тимлидов.
Такой набор действий подойдёт как для продуктовых, так и для сервисных команд. Он может быть применен для разных фреймворков и уже сложившихся процессов в команде. Немаловажный плюс такого подхода в том, что за кратчайшие сроки команда и заказчики могут лучше понять и принять правила работы. Основная цель была достигнута за счёт снижения неопределённости и понимания процесса командой.
После внедрения новых правил я вновь опросила тимлидов, насколько им сейчас комфортно в их роли. На мой вопрос все отвечали, что очень довольны своей ролью и хотят продолжать в ней работать. А те лиды, которые игнорировали отпуск из-за ответственности за команду, смогли наконец-то отдохнуть!
dph
Хм, базовая проблема обозначена вообще в первом абзаце: "тимлида назначило руководство. Чаще всего ими становились опытные архитекторы или разработчики". Но вместо того, чтобы бороться с изначально неверным подходом, зачем-то его стали прикрывать тряпочкой.
Это как лечить запущенный пульпит ударными дозами нурафена. Боль, конечно уйдет. Зубы - тоже.
OPostnikova Автор
Здравствуйте! Спасибо за ваш коментарий!
На самом деле, я в статье не указала, что назначались тимлиды из опытных архитекторов и разработчиков, которые работали в командах уже долгое время и проявляли лидерские качества.
Негатив в работе появился из-за большого количества текучики и менеджерских задач. При этом команды положительно относилась к назначениям тимлидов. Тимлиды сами формулировали проблемы и задачи и мы совместно принимали решение какие инструменты им помогут.
Hokum
Дело не в том, что проявляли лидерские качества или нет. Не исключено, что руководство посмотрело, что человек проявляет эти лидерские качества и спросило, хочешь ли быть лидом, а человек-то и не хотел, но и отказать было неудобно. Или не спрашивали, а просто ставили перед фактом.
Плюс, тимлид - это не карьерный рост для разработчика, это новая карьера. Он фактически становится джуном и его надо обучать и менторить. И этот момент, судя по разным чатикам и постам, руководство пропускает. Считает, раз он опытный линейный сотрудник, то и с обязанностями линейного руководителя справится. А это так не работает.
Не исключено, что более разумным было бы ставить не самого опытного с лидерскими наклонностями, а пусть менее опытного, но проявляющего интерес к организации процессов. Если такой сотрудник будет работать как тимлид в тандеме с опытным сотрудником, который будет закрывать технические вопросы, то результат мог бы быть лучше. Но история не терпит сослагательных наклонений.
Вы молодец, что помогли командам выстроить процессы. Жаль, что компания обратилась за помощью, когда ситуация стала близка к критичной.
dph
Да вообще не стоит пытаться в тимлиды вытаскивать разработчиков. Пусть идут через техлидов в архитекторы и так далее. А на менеджерские позиции лучше брать кого-то или с профильным образованием или с менеджерским опытом. А если разработчик хочет стать менеджером - пусть и начинает с позиции начинающего (с зарплатой тысяч в 50, так как и пользы с него примерно столько же). В противном случае некомпетентность так и будет тотальной на всех уровнях.
Управление людьми, управление процессами, мотивация, лидерство - это все достаточно сложные компетенции и области знаний, которым надо учиться и развивать и достаточно длительное время.
Хотя, будем честными, учат менеджменту довольно фигово.
Hokum
Внутренне, хотелось бы видеть на позиции тимлида кого-то кто практически знаком с разработкой, чтобы он не угробил процесс метриками и улучшениями. И поначалу всё внутри взбунтовалось, как так не разработчик будет лидить!
Но потом осознал, что пока такой руководитель будет как джун под присмотром, он сможет понять как идет разработка наблюдая и задавая вопросы по процессам. Плюс в команде будет техлид, который сможет объяснить и предостеречь от плохих оптимизаций процессов.
В целом, продукт менеджеры вполне себе успешно лидят команды, без опыта разработки. Так что и профессиональный руководитель сможет.
А то что учат хреново, так сложно этому учить. В технических и естественнонаучных областях проще организовать практические занятия в массовом масштабе, а вот для руководителей - это сложнее.
Как вариант, чтобы студенты-руковолителя в качестве практики лидили группы студентов-технарей над каким-то длительными проектами. Возможно, организовывать при ВУЗе такие работы, чтобы задействовать студентов с разных направлений, чтобы в рабочую группу не попадали только студенты из одной учебной группы, кафедры. А были представлены несколько кафедр, факультетов.