Узкое горлышко: почему команда вечно не успевает

AlexMik

New member
Работал я как-то в продуктовой команде, где все были заняты по 100 процентов, доски были забиты задачами, релизы горели, а на ретроспективах мы дружно кивали друг другу: ресурсов не хватает, надо больше людей. Потом я наткнулся на книгу Элияху Гольдрата «Цель» и на теорию ограничений, и через пару месяцев понял неприятную вещь: мы не были медленной командой, мы были командой, которая очень старательно ускоряла не то место. Хочу поделиться тем, как эта штука работает за десять минут и что я с этим сделал.

Суть теории ограничений проста до обиды. У любой системы, будь то пивной завод, отдел тестирования или вся наша компания, пропускная способность определяется одним самым узким местом. Его называют ограничением или бутылочным горлышком. Всё остальное — это просто декорации. Сколько бы вы ни оптимизировали всё вокруг, поток задач на выходе не изменится, пока не расширится именно это горлышко. Гольдрат предложил пять шагов: найти ограничение, выжать из него максимум, подчинить ему все остальные процессы, расширить его и потом снова начать сначала, потому что горлышко переедет.

Самое коварное открытие для меня было не в этом. Оказалось, что загружать все этапы на сто процентов — это вредно. Если у вас одно место работает на пределе, а остальные ждут, то они не просто ждут, они производят гору незавершёнки. У нас так и было: аналитики выдавали макеты пачками, разработчики брались за всё сразу, а очередь стояла на ревью и выкладке. Каждая отдельная часть команды была эффективной, а система в целом буксовала. Классическая ловушка локальной оптимизации.

Про то, как я искал ограничение, расскажу коротко. Метод очень простой: смотрите, где скапливается очередь и где люди жалуются на ожидание. Не на мнение, а на факты — на статусы задач, на время в колонках, на то, кого все дёргают. У нас таким местом оказался не код и не тесты, а один несчастный человек, который согласовывал интеграции с внешним партнёром. Восемь инженеров, два тестировщика и вся суета мира стояли в очереди к нему. Мы оптимизировали ветки сборки, ускоряли линтеры, купили новую CI-машину, а поток упирался в согласование.

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

Мне теория ограничений не столько дала ответы, сколько отучила от привычки чинить всё подряд. Стало спокойнее жить: видишь гору незавершёнки — не бежишь разгонять всех, а идёшь искать, у кого стопка растёт быстрее. И знаете, что интересно: конфликтов это тоже уменьшило. Раньше каждый отдел доказывал, что именно его надо ускорить, а теперь у нас есть один общий измеритель, и спорить с ним как-то глупо. За полгода мы не наняли ни одного нового человека, но стали выпускать заметно больше, просто потому что перестали мешать самому узкому месту дышать.

И последнее, про честность к себе. Не бывает ситуации, когда ограничений нет — бывает ситуация, когда вы его ещё не нашли. И если сейчас вам кажется, что всё упирается во время, деньги или мотивацию, скорее всего, настоящая причина где-то в очереди, которую никто не считает, потому что она выглядит как нормальная рабочая суета.

А теперь вопрос к вам, форумчане: находили ли вы у себя такое неочевидное горлышко, о котором вся команда годами не догадывалась? Расскажите, где оно пряталось и как вы его вычислили — очень интересно собрать коллекцию живых примеров!
 
Назад
Вверх