Интересная статья о применении Теории Ограничений в Microsoft (улучшили, ускорили, ухлубили и т. п.)

 Публичный пост

Прибило статью про применение ББК в Microsoft.

ББК- это Барабан-Буфер-Канат, один из управленческих паттернов теории ограничений. Ну чтобы много, быстро и все такое.

В статье описывают (на мой взгляд) плюс/минус распространенную ситуацию:

  1. Небольшой отдел программистов (в статье 3 разработчика, 3 тестировщика). Поддержка и багфикс.
  2. Проё Не справляются с требуемой загрузкой. За квартал приходит 80 заявок, а делают 17.
  3. Но при этом все заё перегружены (постоянно вынуждены отвечать на вопрос "сколько времени займет эта задача", когда в большинстве случаев правильный ответ: "Мы ее вообще никогда не сделаем"; ходят по встречам, где обсуждают то, до чего дойдут руки лишь в следующем десятилетии; отвечают всем в чатах потому что без этого совсем никак)

Очень хорошо описаны процесс улучшений с их обоснованиями.

В итоге вместо полугода стали делать заявку за 2 недели.

Если вдруг не знакомы с Теорией Ограничений, можно посмотреть пару пипец каких старых проверенных временем докладов Дорофеева:

  1. Эффективность неэффективности
  2. Апгрейд канбан: Барабан-буфер-канат
17 комментариев 👇
Maxim Dorofeev , Прокрастинатолог автор 19 января в 12:06

Это, как мне кажется, вообще стандартная ситуация: как только перегружен, нанимай больше людей.

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

В итоге мы все радостно нанимаем людей, чтобы решить проблему, вызванную несистемным наймом людей.

  Развернуть 1 комментарий

@cartmendum, > Если глубже посмотреть в Теорию Ограничений, то можно прийти к выводу, что очень часто все эти перегрузы являются причиной переизбытка людей. А не недостатка.

Пользуясь случаем хочу спросить/поразмышлять. Тема с матричной организационной моделью рабочая, или это фигня/совсем тонкий инструмент? Ну и вводные данные, которые почему в самом конце)))
Стартап, с которым случился успешный успех, не только не умерли, а еще есть планы увеличить персонал примерно раза в 2, и тут проблема в том, что плодятся продуктовые команды, которым всё сложней синхронизироваться

  Развернуть 1 комментарий

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

Что такое Теория Ограничений? Это управленческая концепция с определенным набором принципов и положений:

  1. В каждой системе есть точка (роль, правило, политика, психологическая установка, оборудование) определяющая пропускную способность всей системы в целом - ограничение
  2. Для увеличения результата нужно оптимизировать именно это ограничение и подчинять всю систему этому ограничению
  3. ... (и еще примерно много подобного рода пунктов)

Что такое матричная организация? Это тоже набор принципов и правил, а самое главное предположений и необходимых условий.

Поэтому чтобы понять поможет ли в вашем случае матричная структура надо аккуратно изобразить схему причинно-следственных связей. И показать как те практики и приемы, составляющие основу идеи матричной организации устраняют существующие сложности. А еще было бы здорово убедиться, что они не создают новых сложностей. Опять же при помощи причин и следствий.

Какие приемы из матричной организаций призваны упростить хотя бы задачи синхронизации?

Но... Самое первое но... А кто сказал, что вам нужно новых людей? И в 2 раза? Вы уверены, что оптимально используете текущую команду?

  Развернуть 1 комментарий

Спасибо за ответ! Ну в данный момент команды работают оптимально, но все они sort of продуктовые.
Как я понял в основе всегда одно и тоже, понять корень проблемы, в нашем случае спрогнозировать, потом думать как это можно решить, если есть подходящее решение на рынке - берём его, если нет - чешем репу)))

  Развернуть 1 комментарий

@gare4ka, всегда чешем репу :)

  Развернуть 1 комментарий

@cartmendum, в любой непонятной ситуации — чешем репу! © мызнаемкто.

  Развернуть 1 комментарий

Немного критики:

  1. Не сказали, сколько они наняли людей. Изначально было 6 человек. Если их сейчас 12, то и без оптимизации узкого места они бы смогли увеличить количество обрабатываемых заявок с 17 до 52.
  2. Всегда, когда я читаю такие истории, идея одна и та же: сначала они стреляют себе в ногу, потом приходит Божественный Менеджер, который говорит "не стреляйте себе в ногу", они перестают стрелять, конец. А можно что-то более правдоподобное? Иначе складывается ощущение, что так называемая "теория ограничений" поможет тебе только в том случае, если ты дурачок и делаешь кривые процессы. Но тогда эту теорию надо назвать "теорией здравого смысла", а не "ограничений". Нормально делай - нормально будет. Устраиваешь бесконечные совещания - вместо работы народ начнет совещаться, и для того, чтобы это понять, не нужна какая-то особая методология, достаточно просто посмотреть, чем человек занимается на рабочем месте.
  Развернуть 1 комментарий

@Kroid, Всегда, когда я читаю такие истории, идея одна и та же: сначала они стреляют себе в ногу, потом приходит Божественный Менеджер, который говорит "не стреляйте себе в ногу", они перестают стрелять, конец. А можно что-то более правдоподобное?

На самом деле это такой жанр - статьи об успехах :)
Но... Статья хорошо написана и четко по пунктам они прописали что и в какой последовательности делали. Какой именно пункт кажется неправдоподобным?

То, что причиной многих наших проблем являемся мы сами - ну да... Так и есть... Правда, не всегда то, что мы сами наворотили мы можем сами исправить...

** Устраиваешь бесконечные совещания - вместо работы народ начнет совещаться**
Ну да, часто все кажется таким простым. Но... Если взять компанию, где проходят бесконечные совещания и задаться вопросом: "Кто конкретно, <имя, должность, год рождения> устраивает эти бесконечные совещания?", то окажется, что каждый по отдельности делает хорошее дело. Но вот все вместе мы делаем хуйню...

Один из фундаментальных управленческих парадоксов :)

  Развернуть 1 комментарий

@cartmendum, попробую объяснить через аналогию:

Сделал я сайт, убийцу букинга, который позволяет бронировать отели. Но возникла проблема - если на него заходит больше сотни людей одновременно, то сайт падает.

Можно решить проблему деньгами - купить новые сервера.

Можно решить проблему оптимизированием узких мест. Например, оказалось, что я отдаю список из 20 отелей не одним запросом в базу на всех, а для каждого отеля делаю отдельный запрос.

Итак, я пофиксил запрос, теперь на сайт могут зайти одновременно не 100 человек, а целых 2000.

Но об этом решении не напишешь статью на условный "хабр", потому что меня там засмеют - любой программист, кроме разве что совсем адских говнокодеров, без проблем найдёт и решит такую проблему сам.

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

Все статьи и книги по менеджменту, которые я читал, решают именно простейшие проблемы, в стиле "читатель, запомни: если ты завяжешь шнурки на своих кроссовках, то ты будешь меньше спотыкается". Спасибо тебе книжка, что бы я без тебя делал?)

  Развернуть 1 комментарий

@Kroid, в книге Андерсона "Канбан. Альтернативный путь в Agile" эта информация есть.

  1. Разрабочики оказались узким местом и сделали перераспределение: поменяли одного тестировщика (вместо 3 стало 2) на разработчика (стало 4 вместо 3).

"Это привело к практически линейному увеличению производительности: пропускная способность за квартал повысилась с 45 до 56."
2) После подтверждения эффективности "Отделу были выделены средства, чтобы нанять еще двух сотрудников. В июле 2005 года в команде появились новый разработчик и тестировщик. Результаты оказались существенными".

В целом статья выглядит как пересказ главы из книги, только под соусом ТОС.
Книга в сообществе канбанистов практически хрестоматийная, очень широко известна и так же известен пример XIT из нее.

  Развернуть 1 комментарий

@Kroid, здравый смысл, а также, извините, логика, слишком коммодитизированы, поэтому плохо продаются.

Именные теории от именитых авторов — другое дело! ;)

  Развернуть 1 комментарий

Интересно, спасибо!

Чем дальше в айти, тем больше понимаю, что менеджер/оунер без понимания теории ограничений как курица (или чайка) без головы -- бегает, но не понимает. Отсюда постоянные переработки, ощущение уборки снега в сильный снегопад, растущий в бесконечность бэклог и WIP c постоянными доработками по уже "сделанным" вещам (ну демо показали, считай сделано) и прочий фича-факторинг.

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

  Развернуть 1 комментарий
Denis Kachnov , Управляю работой 19 января в 19:01

Это же "кейс Microsoft XIT" из книги Дэвида Андерсена "Канбан. Альтернативный путь в Agile"!
(оригинал "Kanban: Successful Evolutionary Change for Your Technology Business". издан в 2010 году)

Описан как первый реальный случай создания Канбан-системы для производства ПО.
Интересно, как ТОС-парни приписали его полностью на свой счёт :-) В статье нет ни единого слова "Канбан".

  Развернуть 1 комментарий

@deniskachnov, о, как интересно вышло :)
Но там тоже поди разбери, где Канбан, где ББК ;)

  Развернуть 1 комментарий
Maxim Dorofeev , Прокрастинатолог автор 19 января в 18:25

На сколько я понял это
Общее количество выполненных заявок выросло с 17 до 56 за квартал. Общее отставание было сокращено с 80 заявок в очереди до 10
они достигли тем же составом. Без дополнительного найма.

  Развернуть 1 комментарий

@cartmendum, не совсем, вот цитата:

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

Ну и в целом, если на пальцах прикинуть - до найма они суммарно не больше чем в два раза увеличили "пропускную способность трубы", а количество заявок стали обрабатывать в 3+ раз больше. То есть без найма так бы не вышло.

  Развернуть 1 комментарий

@Kroid, да, точно. Сколько-то людей наняли... Поскромничали, не рассказали, на сколько увеличили пропускную способность тем же составом :)

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб