Теория ограничений в IT-процессах

Любой бизнес хочет более быстрого развития. Если вы делаете публичный продукт, это позволяет быстрее тестировать гипотезы, привлекать больше трафика и в конечном счете заработать больше денег. Но, как и у плохих танцоров, все время что-то мешает. На эту тему есть Теория ограничений (Theory of Constraints, TOC). Сформулировал ее в своей книге Элияху Голдратт еще в 1984 году. Главный принцип очень прост:

Скорость всей системы определяется её самым узким местом.

Мы ж программист, поэтому возьмем в пример IT-команду: 👨‍💻 Разработчики быстро пишут код 🧪 QA быстро тестирует 🚀 DevOps быстро выкатывает Но все задачи перед релизом должны пройти через одного человека, который делает code review. То есть даже если команда увеличит скорость разработки в 2 раза, релизов больше почти не станет. Потому что ограничение осталось прежним. Согласно товарищу Голдратту нужно повторять в цикле 5 шагов: 1️⃣ Найди ограничение Что прямо сейчас тормозит всю систему? Это человек или процесс, из-за которого дело затормозилось. 2️⃣ Используй его максимально эффективно Убери простои, лишние действия и переключения. 3️⃣ Подстрой систему под него Остальные процессы должны работать с учётом ограничения. То есть сделай так, чтобы ограничение не выглядело таковым, будто всё так и должно быть. 4️⃣ Расширь ограничение Автоматизируй, перераспредели работу, добавь людей или ресурсы, чтобы увеличить пропускную способность. 5️⃣ Повтори Если ограничение исчезло, значит, узким местом стало что-то другое. Если нет, значит не докрутил, повтори. Один из методов TOC, применяемый в производствах, - барабан - буфер - канат: ▪️барабан — производство должно работать по установленному ритму; ▪️буфер — перед ограничением должен находиться некоторый буфер запасов материалов, защищающий ограничение от простоев; ▪️канат — материалы должны подаваться в производство только тогда, когда запасы в буфере достигли определенного минимума. В общем, применяйте в своих производствах, и будет вам счастье. #process