ТОС расшифровывается, как theory of constraints, теория ограничений. Ограничение системы — это фактор, который ограничивает систему в достижении цели. Ограничение определяет результативность всей системы. Если бы его не было, то цель достигалась бы бесконечно быстро. Например, коммерческая компания зарабатывала бы бесконечно много денег за бесконечно малое время. Ограничение есть всегда.
Один из самых популярных образов, которые используются для объяснения концепции ограничения — цепь. В чём цель цепи? Упростим её до «обеспечить прочность на разрыв». Что определяет прочность цепи? Средняя прочность всех звеньев цепи? Максимальная прочность самого крепкого звена? Степень блеска? Похожесть цепи на цепи ведущих конкурентов? Подробность описания каждого из звеньев цепи? Обеспечение более уважительной и здоровой коммуникации между звеньями?
отлично, опять мной кто-то управляет
надо это как то исправлять
Я бы, наверное, добавил ещё один шаг на 0.5 - "освободить систему" или "перестать на неё воздействовать", чтобы она пришла в своё естественное состояние.
Я лично вижу, что в разработке ПО зачастую есть какие-то метрики, от которых зависит финансовое вознаграждение исполнителей (типа количество фич, "скорость разработки", количество багов на тысячу строк кода и в таком духе) и эти метрики в лучшем случае смазывают картину реальной работы системы до неузнаваемости, а в худшем - полностью формируют её.
Тот же Голдратт писал, что одна из проблем на заводе была с простоем рабочих, потому что в головах рабочих "простой - это минус от зарплаты". Ему повезло - на заводе незаверншёнку можно увидеть в материальном воплощении и через это увидеть ограничение. А как такое провернуть в софтдеве - не понимаю.
Нам нужен Голдратт нашего времени!! Очень интересный вопрос, как считать эффективность нма. Имхо из-за того, что нет стандартизации человеко-часов на разработку(не берём типовые сайты на ВордПресс), начинается выдумывание KPI. Ждём Александру, может у нее есть решение))
5/10