Интересная статья о применении Теории Ограничений в Microsoft (улучшили, ускорили, ухлубили и т. п.)
Публичный постПрибило статью про применение ББК в Microsoft.
ББК- это Барабан-Буфер-Канат, один из управленческих паттернов теории ограничений. Ну чтобы много, быстро и все такое.
В статье описывают (на мой взгляд) плюс/минус распространенную ситуацию:
- Небольшой отдел программистов (в статье 3 разработчика, 3 тестировщика). Поддержка и багфикс.
ПроёНе справляются с требуемой загрузкой. За квартал приходит 80 заявок, а делают 17.- Но при этом все
заёперегружены (постоянно вынуждены отвечать на вопрос "сколько времени займет эта задача", когда в большинстве случаев правильный ответ: "Мы ее вообще никогда не сделаем"; ходят по встречам, где обсуждают то, до чего дойдут руки лишь в следующем десятилетии; отвечают всем в чатах потому что без этого совсем никак)
Очень хорошо описаны процесс улучшений с их обоснованиями.
В итоге вместо полугода стали делать заявку за 2 недели.
Если вдруг не знакомы с Теорией Ограничений, можно посмотреть пару пипец каких старых проверенных временем докладов Дорофеева:
Это, как мне кажется, вообще стандартная ситуация: как только перегружен, нанимай больше людей.
Если глубже посмотреть в Теорию Ограничений, то можно прийти к выводу, что очень часто все эти перегрузы являются причиной переизбытка людей. А не недостатка.
В итоге мы все радостно нанимаем людей, чтобы решить проблему, вызванную несистемным наймом людей.
😱 Комментарий удален модератором...
Интересно, спасибо!
Чем дальше в айти, тем больше понимаю, что менеджер/оунер без понимания теории ограничений как курица (или чайка) без головы -- бегает, но не понимает. Отсюда постоянные переработки, ощущение уборки снега в сильный снегопад, растущий в бесконечность бэклог и WIP c постоянными доработками по уже "сделанным" вещам (ну демо показали, считай сделано) и прочий фича-факторинг.
Например, в этом кейсе некоторые менеджеры из моего опыта сразу бы перешли к последнему пункту и наняли больше людей.
Это же "кейс Microsoft XIT" из книги Дэвида Андерсена "Канбан. Альтернативный путь в Agile"!
(оригинал "Kanban: Successful Evolutionary Change for Your Technology Business". издан в 2010 году)
Описан как первый реальный случай создания Канбан-системы для производства ПО.
Интересно, как ТОС-парни приписали его полностью на свой счёт :-) В статье нет ни единого слова "Канбан".
На сколько я понял это
Общее количество выполненных заявок выросло с 17 до 56 за квартал. Общее отставание было сокращено с 80 заявок в очереди до 10
они достигли тем же составом. Без дополнительного найма.