The Book of TameFlow

Этот текст написан как задание в прохождение резидентуры “R10. Системный менеджмент” в МИМ (бывшая ШСМ), раздел 6 “Практика управления работами (операционный менеджмент)”

Прочтена книга Steve Tendon, «The Book of TameFlow», 2022. Опубликовано в блоге эссе с мыслями, пришедшими в голову по ходу прочтения книги (без этого эссе книгу нельзя считать прочитанной).

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

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

Также понравилась метафора, что к работе есть смысл относится как к хирургической операции:

  • не начинаем работу (и операцию тоже) пока нет полной подготовки (Full-Kitting): инструменты и люди готовы к выполнению, не будет задержек, которые мы можем предотвратить на этом этапе. Таким образом подготовка является частью содержательной работы, которая делается еще до самой работы.
  • если случилось так, что из-за других работ, работа задерживается (идет другая операция), то работа не будет начата, пока не будет закончена предыдущая и освободится соответствующий ресурс!
  • если работа (операция) началась, то крайне важно завершить ее максимально без задержек, любые задержки не приемлемы.

По TameFlow различают три возможных ограничения, с каждым работают разными способами

  • Work Flow Constraint - ограничение возникает на какой-то станции, решается через введение техники DBR - барабан-буфер-веревка
  • Work Process Constraint - ограничение возникает из-за того, что какая-то станция медленно работает. Возможно проблемы внутри конкретной станции. тогда надо посмотреть как она внутри работает.
  • Work Execution Constraint - ограничение возникает при выполнении работы, это обычно временное ограничение, но может оказаться, что и не так.

В целом, конечно подход TameFlow не производит впечатления какого-то цельного подхода, такое ощущение, что это больше набор рецептов, впрочем SoTA рецептов. Надо бы, конечно, еще почитать остальные книги рекомендованные

  • Donald G Reinertsen «The Principles of Product Development Flow: Second Generation Lean Product Development» - книга по теории операционного менеджмента
  • Томас Корбет, «Учёт прохода. Управленческий учёт по ТОС» книга концентрирующая на проходе денег

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

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

Как относится к ограничению в работе? Ограничение есть всегда, поэтому он наш бро, особенно когда известен. Иногда ограничение нам не подвластно (емкость рынка, внимание ЛПР), тогда подстраиваемся под то, что есть и более ничего не делаем.

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

Два буфера

  • DBR-буфер - буфер перед станцией-ограничением, как только приходит время станции вытянуть задачу из этого буфера, то это сигнал для остальных станций также возобновить работу.
  • буфер в конце проектов - на работу над проектов выделяется время так, чтобы с 50% вероятность завершить проект, а далее ставится буфер. Таким образом работа завершается чаще .

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

В целом, много практик описано, книга большая, смысла пересказывать всё не вижу.

Что взял для себя?

  • Планирую сделать мероприятие, прежде чем запустить его, надо сделать Full Kitting, это в первую очередь наладить управление конфигурацией и договориться с людьми, кто будет организовывать мероприятие, что они готовы делать. С другой стороны надо сразу наладить управлением задач в рамках этого мероприятия, т.е. настроить экзокортекс, удобный для всех участников
  • Есть еще один проект с ремонтом помещения. Там тоже самое с работой с подрядчиками. Full Kitting сначала, а потом запуск с контролем задач.
  • Личные задачи - отказ от мультитаскинга - взял задачу, надо завершить ее. Брать такие работы (MOVE в терминах TameFlow), чтобы можно было не прерываясь на другие работы завершить их. Деление на слишком маленькие задачи не хорошо - много потерь времени, деление на слишком большие задачи - обязательно будут перерывы и мультитаскинг тоже не хорошо
  • Full Kitting сам по себе может быть большой задачей. В целом, если задача полностью на мне одном, то получается вполне понятный паттерн - сначала делаем Full Kitting одним проходом, а потом саму задачу одним проходом.
  • По трейдингу, там главный ресурс - это деньги и нужно смотреть как используются деньги в стратегиях (методах) торговли и как они освобождаются. В HFT-стратегиях могут прокручиваться большие деньги с малой прибылью, но очень быстро, за счет этого подобные стратегии могут быть интересны. В целом, конечно это не совсем про операционный менеджмент с работами, это про движение денег, но все близко.

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

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

6 лайков

Отличный пост! И отличный результат - все превращается в рутинный набор задач) без интриг и стрессов. Теперь такт сокращения времени на моделирование надо сделать (приготовить инструменты): шаблоны, чек листы, ИИ агента обучить часть моделирования делать (поправлять набросок это быстрее чем документ готовить, в инструкции проверять перед ответом правильное онтологическое использование kinds можно дописать, оно не идеально получается, но сильно интереснее текст становится)

3 лайка