Ошибка, которая стоила нам месяца работы, и как мы внедрили процесс, чтобы она больше не повторялась
Жесткий урок о том, почему тимлид не должен быть «бутылочным горлышком» во всех процессах. Разбираю свою ключевую управленческую ошибку.
Ничто так не учит руководителя, как осознание, что его собственная модель управления привела команду к провалу. Не срыв дедлайна по вине разработчика, не баг в продекшене, а именно моя ошибка. Однажды мое стремление все контролировать стоило нам месяца работы и нервов всей команды. Расскажу, как мы превратили этот провал в главный драйвер роста для команды из 20 человек.
В одном из наших проектов в «Х» была критически важная функциональность. Я, как руководитель, решил, что буду лично курировать все ключевые решения:
- Архитектура? «Я просмотрю и одобрю».
- Дизайн-макеты? «Пришлите мне на финальное согласование».
- ПР? «Я сам сделаю ревью критических участков кода».
Я стал тем самым «бутылочным горлышком» (bottleneck). Пока я был в командировках, на совещаниях или просто занимался другими задачами, работа команды простаивала. Они ждали моего кивка, чтобы сдвинуться с места.
Результат: Мы проели весь запас по времени (buffer) еще на середине спринта. Команда, вместо того чтобы работать слаженно, металась между задачами, постоянно переключаясь. Фича, которую оценили в 3 недели, в итоге ушла на 2 месяца. Доверие заказчика было подорвано.
Осознание пришло на ретроспективе, где я попросил команду дать мне честную обратную свянь. Фраза одного из старших разработчиков стала ключевой: «Иван, мы не чувствуем, что это наш проект. Мы просто исполнители твоей воли».
Мы сели вместе и пересобрали процесс с нуля.
1. Внедрили матрицу принятия решений (Decision Matrix)
- Мы четко расписали, какие типы решений и кем принимаются:Команда: Выбор библиотек, код-стайл, внутренняя оценка задач.Тимлид: Архитектурные паттерны, технический долг, финальное ревью сложных фич.Я (руководитель): Приоритизация беклога, коммуникация с заказчиком, стратегические цели.
- Это убрало 80% вопросов ко мне, которые блокировали работу.
2. Внедрили «Владельцев процессов» (Process Owners)
- Для каждого ключевого направления (например, «Качество кода», «Деплой», «Документация») мы назначили ответственного из команды. Этот человек стал конечной инстанцией по своему направлению и имел право вето.
3. Установили новые правила коммуникации
- Ежедневные 15-минутные стендапы без меня. Команда синхронизировалась сама.
- Я подключался только на еженедельном планировании и демо. Это вернуло команде чувство ответственности за общий результат.
Эффект мы ощутили уже в следующем спринте:
- Скорость: Показатель Velocity команды вырос на 40% за счет устранения простоев.
- Автономность: Команда стала самостоятельно принимать 90% операционных решений. Мое вмешательство требовалось только в исключительных случаях.
- Мотивация: По данным следующего опроса вовлеченности, индекс eNPS команды вырос с +25 до +52. Люди снова почувствовали себя хозяевами своей работы.
- Мое время: Я, наконец, смог сфокусироваться на стратегических задачах: масштабировании, переговорах с новыми заказчиками и развитии департамента.
Главный вывод, который я вынес:
Сильный руководитель — не тот, кто все контролирует, а тот, кто выстраивает систему, способную работать эффективно без его постоянного присутствия.
- Доверяй, но проверяй (процессами). Доверие — это не слепая вера, а создание прозрачных правил игры, где у каждого есть зона ответственности и полномочий.
- Ваша задача — делать себя ненужным в операционке. Если команда не может работать без вашего ежедневного вмешательства — это провал системы управления, а не команды.
- Признавать ошибки перед командой — это сильная черта. Это не роняет авторитет, а, наоборот, вызывает уважение и создает атмосферу, где не боятся говорить о проблемах.
А вам приходилось сталкиваться с ситуацией, когда вы или ваш руководитель становились «бутылочным горлышком»? Как из нее выходили? Делитесь опытом в комментариях!