Плавающие бутылочные горлышки

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

Хотелось бы мне сказать, что это был счастливый конец истории и после этого все зажили счастливо, но это было бы не совсем правдой. Мы и правда добились значительного ускорения поставки и снижения количества багов, но появились новые трудности.

⭐️ Прилетело откуда не ждали

Тестирование перестало захлёбываться от нагрузки, разработка пилит тесты — кажется, что всё прекрасно. Но теперь перестал справляться другой элемент системы. Угадаете, какой?

Требования от бизнеса. Ускорение поставки привело к тому, что мы действительно стали делать больше фич. Поэтому нам потребовалось больше задач со стороны бизнеса, к чему наш продакт оказался не готов. Он привык работать в определённом темпе и уделять нам определённый объём внимания (он работал с несколькими командами), поэтому рост производительности создал ему внезапные проблемы. Он за нас был, конечно, рад — но не от всего сердца.

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

⭐️ Главный вывод о бутылочных горлышках

Но сама ситуация меня немного напрягла. Мы исправили проблемы в одном месте — и сразу же получили новые проблемы в другом. Я вернулся к книге “Цель” и стал читать про бутылочные горлышки.

Герои книги тоже неоднократно сталкивались с такой проблемой. Каждый раз, когда они “расшивали” бутылочное горлышко, в системе неизбежно возникало новое. Это приводит нас к следующему выводу:

➡️ Бутылочное горлышко в системе есть всегда.

Вывод настолько очевиден, что аж бесит. И в этом весь Голдратт — он стремился сделать всё настолько очевидным, чтобы мог понять кто угодно.

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

В нашей ситуации мы “расшили” тестирование — и быстро упёрлись в поставку требований от бизнеса. Но другое решение могло создать и другие бутылочные горлышки. Например, если бы мне дали ещё парочку тестировщиков, то бутылочным горлышком могла бы стать разработка — программисты просто не успевали бы делать задачи с той скоростью, с которой их тестируют.

⭐️ Подводя итог

Из всей этой ситуации я вынес для себя несколько уроков:

➡️ Хочешь ускорить систему — найди бутылочное горлышко и строй процессы вокруг него. ➡️ Бутылочное горлышко в системе есть всегда. ➡️ Если бутылочное горлышко перестало быть бутылочным горлышком, значит, оно переместилось в другое место. ➡️ Любые изменения в системе могут вызвать перемещение текущего бутылочного горлышка в новое место.

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

На этом я заканчиваю небольшой цикл про бутылочные горлышки. Спасибо за ваши лайки, комментарии и вопросы — они были для меня очень ценны. Мне настолько понравилось писать этот цикл, что аж доклад захотелось сделать (но этому препятствует бутылочное горлышко в виде моего времени). // И не забывайте нажать волшебный 💛