Упражнение: TOC в софтостроении

[hedgeov]

Вытащу из комментариев и дополню разборки с применением ТОС к софтостроению.

Имеем в самом общем случае такую цепочку (да, тут совершенно нет стадии написания документации, где она я пока не знаю):

Новая функциональность
         |  
        \|/
      Анализ -> Проектирование -> Кодирование -> Тестирование -> Внедрение
         ^                                                           |
         |   Обнаружение ошибок на этапе эксплуатации            < —-

Полное время обработки новой фичи с момента поступления запроса на имплементацию до выпуска нового релиза:

1. Время наладки: наладки нет>


2. Время обработки: время, нужное ресурсу для имплементации


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


4. Время ожидания тестирования и выпуска билда.

Что видим: видим что если аналитики с разработчиками заняты разгребанием багов, на новые фичи им времени может не хватить.


"Выработка — это скорость, с которой система генерирует доходы посредством продажи.
Запасы — это деньги, вложенные системой в приобретение вещей, которые она намеревается продать.
Операционные расходы — все деньги, которые система затрачивает на то, чтобы превратить запасы в выработку."

Получается что

• Выработка — поставка новых оплаченных фич пользователям.


• Запасы — Вообще складывается ощущение, что запасы в основном это фича-реквесты от пользователей и мозги программистов :) Ну и тулы в том смысле, что это какие-то исследования/новые технологии, которые ты потом будешь продавать (блин, вот не то всё-таки).


• Операционные расходы — зарплата, офис и компьютеры; Кроме того интересно: вот ты фичу выпустил, а в ней бага. Ты потратил деньги на выпуск фичи + на исправление баги (потому что пользователь тебе заплатил только за фичу, а не за исправление баги). Так что это еще и расходы на исправление багов.

В чем тут проблема: у нас выпадает установка и настройка системы новому пользователю, а это какая-то иная цепочка вроде бы как.