Как выстроить работу команды и отпустить тимлида в отпуск
Знакома ли вам ситуация: тимлид распределяет задачи, всё делает сам, а на свой профессиональный рост и поддержку компетенций вечно не хватает времени? Без него в команде ничего не решается, и поэтому он становится «узким горлышком» в процессе. Отпуск откладывается, ведь без незаменимого лидера всё рухнет. Так происходит годами, и ничего не меняется.
В этой статье я поделюсь алгоритмом, который я использовала в собственной практике, как тимлиду выбраться из рутины и сделать команду автономной.
В 2023 году меня пригласили в крупную ритейл-компанию провести Agile-трансформацию. Нужно было уменьшить time-to-market (T2M) и адаптировать команды к меняющимся бизнес-целям. В работу я получила пять доменов, в каждом — в среднем по пять сервисных и пять продуктовых команд.
Почти во всех командах тимлида назначило руководство. Чаще всего ими становились опытные архитекторы или разработчики. Многие из них были не очень довольны таким назначением, ведь к старым обязанностям добавились еще и новые. Им приходилось выстраивать процессы в команде, взаимодействовать с подрядчиками, командами и лидами из других доменов. Кроме того, добавились новые инструменты для трекинга задач и сбора метрик.
В итоге лиды стали посвящать девяносто процентов своего времени текучке и уже не успевали заниматься развитием команды и себя. Они жаловались на выгорание, постоянное напряжение и работу по выходным. Кто-то даже отказался от отпуска, чтобы работа не стояла, и команда быстрее закрывала важные задачи. Во время интервью многие лиды сказали, что не хотели бы играть эту роль в команде, а некоторые время от времени думали об увольнении.
После аудита я применила такой алгоритм действий:
1. Провести STATIK-воркшоп
Этот подход позволяет быстро запустить канбан-систему на основе знаний о процессе, полученных во время проведения воркшопа, а также помогает в командообразовании. Некоторые команды были созданы недавно, и STATIK помог участникам познакомиться. В результате команды создали канбан-системы, учитывая все нюансы процесса, с которым они работают, записали описание команды (что команда делает и чего не делает), определили правила, по которым они будут работать, и согласовали эти правила с заинтересованными сторонами и подрядчиками.
2. Договориться о правилах приоритезации
Мы использовали классы обслуживания как основной метод приоритезации.
3. Прописать DoD и DoR (Definition of Done и Definition of Ready)
На STATIK-воркшопе мы определили для каждой команды точки взятия обязательств и точки готовности к внедрению функционала. Также описали DoD и DoR и согласовали их с заинтересованными сторонами. В некоторых случаях мы проработали DoD и DoR для нескольких переходов между статусами процесса.
4. Установить основные каденции
Мы выбрали три обязательные канбан-каденции (канбан-летучка, пополнение потока и обзор потока). Также добавили регулярное выравнивание бэклога с заинтересованными сторонами. Для каждой встречи прописали план, тайминг, цели и ожидаемый результат.
5. Убедиться, что все участники процесса в курсе введённых правил
В каждой команде мы определили заинтересованные стороны и нанесли их на карту заинтересованности и влияния. Затем провели серию встреч с ключевыми заказчиками и участниками процесса, чтобы согласовать новые правила и адаптировать их для совместной работы.
6. Провести Star map
Провели проверку состояния компетенций каждой команды и выявили узкие места, где нужны поддержка и развитие. Выработали план для развития самых необходимых и недостающих компетенций.
7. Провести мастер-классы по использованию систем таск-трекинга и сбора метрик
Чтобы каждый участник команды понимал, как инструменты для сбора метрик работают и как их настраивать, мы проводили мастер-классы. Каждый участник сам попробовал настроить и получить необходимый отчёт или выгрузку данных.
В результате этих действий у команд появилось понимание правил приоритезации, и теперь им стало понятнее, какой запрос стоит брать первым в работу. Это сняло с тимлидов нагрузку по назначению задач на исполнителя. Теперь участники команд сами разбирают задачи.
Появились регулярные встречи с заказчиками, на которых уточняются требования и сроки реализации. Командам и бизнесу стали понятны критерии готовности задач к реализации и закрытию, что позволило команде не сомневаться о том, что они берут в работу и будет ли это принято заказчиком.
Стали понятны инструменты визуализации и взаимодействия с заказчиком и смежными командами, за счёт этого повысилось доверие к команде, лидам не приходится вручную заполнять Excel-файлы с данными по задачам каждую неделю.
Команды стали понимать, какие компетенции необходимы, чтобы команда была способна функционировать при возникновении рисков. Появились негласные лидеры, на которых делегируется часть задач тимлидов.
Такой набор действий подойдёт как для продуктовых, так и для сервисных команд. Он может быть применен для разных фреймворков и уже сложившихся процессов в команде. Немаловажный плюс такого подхода в том, что за кратчайшие сроки команда и заказчики могут лучше понять и принять правила работы. Основная цель была достигнута за счёт снижения неопределённости и понимания процесса командой.
После внедрения новых правил я вновь опросила тимлидов, насколько им сейчас комфортно в их роли. На мой вопрос все отвечали, что очень довольны своей ролью и хотят продолжать в ней работать. А те лиды, которые игнорировали отпуск из-за ответственности за команду, смогли наконец-то отдохнуть!
