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