Теория ограничений или как измерить качество?

Я не люблю Теорию ограничений - скука смертная. Если бы не художественное изложение ряда книг - ничего бы не осилил. У меня все еще теплится надежда попробовать эти диаграммы для решения проблем, но пока не могу найти случая и команды для этого. Наверное нужны желающие чтобы можно было это делать совместно - просто впихивать это своим сотрудникам можно их сразу отпугнуть от ТОС и они даже не захотят потом читать про него.

Из ВСЕХ этих книг про ТОС я взял лишь небольшую часть небольшой идеи и пытаюсь применить это в своей работе.

Опишу то малое что я взял и хочу использовать.
В производстве есть 3 показателя, которыми можно описать нашу деятельность

• Выпуск - то что мы выпускаем и продаем, то есть наш доход от продажи продукции
• Операционные расходы - наши затраты на осуществление деятельности, которые нельзя вернуть
• Инвестиции - наши инвестиции в производство, которые мы можем в будущем обналичить и вернуть

В результате все НАША деятельность направлена на достижение простой Цели

• Увеличивать выпуск
• Уменьшать операционные расходы и инвестиции

Теперь что это относится к ИТ.

• Выпуск - это тот продукт что мы разрабатываем. Чтобы его померить не хочется оперировать деньгами, сделаем упрощение и будем измерять его в кол-ве фич, которые мы выпускаем, или Velocity (да, это неправильно. Я знаю. Это упрощение). То есть мы выпускаем фичи - нам за них ПЛАТЯТ. При этом мне сразу хочется здесь выделить из всего Выпуска его часть и назвать его Value. Это те фичи, которые реально нужны заказчика. То есть платит он нам за все фичи, но его реально нужны лишь ЧАСТЬ из них
• Трудозатраты - все трудозатраты, которые списываются на проект. В часах. Легко переводится в деньги.
• Инвестиции - тут сложнее. Нет у меня станков или роботов, которые потом можно будет продать. Можно попробовать переделать это в знания, которые в дальнейшем помогают нам выпускать лучше, и тогда стратегия меняется на их увеличение. НО лучше упростить - инвестиций нет.

То есть вся моя деятельность как менеджера направлена на увеличение выпуска и уменьшение трудозатрат. Это было интуитивно понятно и до ТОС.

Но далее появляется следующее утверждение. Любое улучшение должно быть измерено относительно этих показателей. И мы делаем переход в нашу реальность.

Ко мне приходят аналитики Маша и Катя и говорят что они сильно постарались и перевели процесс поставки требований в Use Cases на User Stories. И теперь этот процесс занимает в 2 раза меньше времени. Я узнаю увеличилась ли скорость разработки, то есть Выпуск. Он не увеличился (предположим).  Я увольняю Машу. Так как Выпуск не увеличился, то для Общей Цели это ничего не дает. Зато теперь я могу снизить трудозатраты. После этого никто никаких "инноваций" мне не предлагает.

Конечно же я считаю что практика User Story полезна. Она должна заставить команду меньше общаться через документы и больше общаться в живую. В результате процесс передачи знаний должен улучшится, снизится время на переработку фич в результате непонимания, и должен увеличится Выпуск.
А снижение трудозатрат аналитиков мы используем чтобы перенести часть работ со Спринта на предспринтовую деятельность. Например, более детальную проработку UI прототипов, что так же должно увеличить Выпуск. Используйте User Stories.

Потому можно утверждать что любая практика, которую вы решите внедрить, должна увеличивать Выпуск. То есть TDD, BDD, CI, Code Review и тп должны "драйвить” разработку вперед. Если новая практики оптимизирует только какую-то ЧАСТЬ процессов и не увеличивает Выпуск, то это Wastes. Можно выкидывать.

Давай поставим новую Jira. Выпуск увеличится? Waste.
Давай перейдем на Jenkins. Waste.
Давай будем описывать в Confluence How-To, которые нам возможно потом помогут. Waste.

Трудозатраты чаще всего мы не можем уменьшить. На практике мы не увольняем людей из команды. Если аналитики стали работать меньше, а вы не можете никак это превратить в Выпуск - Вам это ничего не дает.

Как измерить Качество?

Мы пишем unit-тесты - мы увеличели Качество. Хм, а как проверить?
Фактически Качество так же заложено в вашем Выпуске и Трудозатратах.

Вы используете CI чтобы быстро находить баги и исправлять их. В результате баг исправляется за 2 минуты сейчас, а не за N часов или M дней завтра с использованием поддержки 1, 2 и 3 уровней. Это не стопает разработку, значит “драйвит” Выпуск.

Или качество это увеличение соотношения Value / Выпуск, то есть больше поставки того что бизнесу надо, а не то что написано в ТЗ. НО вам еще нужно постараться превратить это деньги. Если вы не можете превратить это в деньги, то такое качество Вам не нужно. Именно так и происходит в заказной разработке. Платят за фичи в ТЗ, а не за то что процент ПОЛЕЗНЫХ для бизнеса фич будет выше.