Основные книги по современному операционному менеджменту
Вот базовая книга по управлению работами: Steve Tendon, «The Book of TameFlow», 2022:
Книга использует подход, оценивающий связь денежного потока и потока работ, то есть экономический (распределение редких ресурсов, в данном случае ресурсов, которые способны выполнить работу) подход к выбору порядка выполнения работ. Где будет больше денег, тот порядок и выбираем. Книга приводит множество интересного материала:
- Объясняет, что бесполезно заниматься улучшениями, если только вы не точно знаете, где именно эти улучшения надо делать. Место улучшений нужно вычислить, иначе это просто бесполезные траты времени и ресурсов!
- Объясняет, почему канбан-доска может быть не только полезна, но и вредна (если вы не знаете, что это такое, в книге расскажут. Если знаете, то будете удивлены).
- Рассказывает, как правильно порезать работу на части: что должно попасть обязательно в одну работу, а что нужно разложить по разным работам.
- Рассказывает, как операционному менеджеру выжить в условиях множества продуктов, множества проектов, множества команд.
- Рассказывает, как и где использовать данные управленческого финансового учёта в принятии решений по управлению работами, а также говорит, какие практики управленческого учёта потребуются.
Основные идеи, которые лежат в основе менеджерских решений в части операционного управления — это идеи по управлению самыми разными типами потоков (не только потоков работ) из практик:
- сomputer operating systems
- control engineering
- data communications networks
- finance and economics
- information theory
- maneuver warfare
- manufacturing
- operations research
- probability and statistics
- queueing theory
Идеи изо всех этих практик были собраны и относительно популярно (без зубодробительных формул) изложены в книге Donald Reinertsen «The Principles of Product Development Flow», 2011 (по сути — это книга «теории» операционного менеджмента, в то время как предыдущая книга больше была посвящена нормативной практике):
В этой книге в том числе очень чётко объясняется про использование принципов управления потоком при разработке/development, а не при производстве/manufacturing. Легко увидеть «пробку» на пути каких-нибудь заготовок на заводе, это будет «затор» в виде груды заготовок перед каким-нибудь станком, или затоваренного продукцией или сырьём склада. А как увидеть «затор» в разработке, где «станки» — это компьютеры? В разработке:
- Есть циклы (пробы гипотез), их число заранее неизвестно.
- Есть тупики (отброшенные гипотезы), их число заранее неизвестно.
- Иногда требуется время на размышление, а поскольку это не физическая работа, нормировать её невозможно, это время нельзя точно оценить.
- Собрать результаты размышлений вместе — это совсем не похоже на то, как собирается конструкция из точно изготовленных деталей! Время на такую сборку плохо поддаётся оценке.
- Модели/описания систем легко изменить по сравнению с самими системами/воплощениями систем. В описаниях легко исправить ошибку, но легко её и внести (а найти ошибку одинаково трудно и в описании, и в воплощении).
- Хорошо известные способы оптимизации проектов и процессов (например, «маленькая партия для обработки») плохо работают: какая такая «маленькая партия для размышления», как её выделить из всех размышлений?
У нас нет места в курсе «Системный менеджмент» для описания того, что вы вычитаете в этих двух книгах, но для того, чтобы хоть как-то понимать, каким образом прекратить «пожары» и «авралы» вокруг вас, вам нужно знакомство с этим материалом.
Мы не даём много дополнительной литературы, ибо она сегодня общеизвестна (например, книги Элияху Голдратта и его коллег по теории ограничений, или книги Давида Андерсона десятилетней давности по канбану в разработке). На все эти книги есть ссылки в предложенных нами двух книгах.
Тут ещё много нюансов, но в нашем обзорном курсе вряд ли мы сможем рассказать о них всех. Например, использование визуальных средств для управления работами: скажем, Trello очень нравится менеджерам старой закалки, потому что у них редко бывает 200-300 кейсов/issues на контроле, и красивые раскладки карточек на бумаге радуют глаз. У программистов легко в небольшом очень проекте получаются 6000 кейсов/issues, и они ещё привязаны к системе версионирования, и тут нужна нормальная табличная работа в программах, которые не будут нравиться менеджерам старой закалки. В некоторых фирмах вместо issue tracker используют протоколы, которые не выживают больше одного приноса на совещание (максимум двух приносов), поэтому всегда проблемы с «забытыми задачами». Некоторым особо ценным сотрудникам разрешают нарушать принцип «не записано в issue tracker, значит, работа не сделана» — и не увольняют их за нарушение производственной дисциплины, ведущей к конфигурационным коллизиям, потом удивляются, что никак не удаётся потушить авралы и пожары (но это же пункт 2 в нашей истории — наладить контроль конфигурации).
В принципе, весь этот материал пригоден и для управления собственными работами. Поэтому в курсе «Собранность» довольно много отсылок к TameFlow именно для операционного менеджмента личных работ, но вам не помешает также и знакомство с идеями Product Development Flow, их тоже вполне можно применить к менеджменту личных работ. В курсе «Собранность» тоже подчёркивается важность моделирования (ничего не держать в голове! Мозгу не верим! Всё записывать!), весь операционный менеджмент держится на хорошо налаженном моделировании работ и рабочих продуктов, то есть на хорошо налаженном операционном учёте. В основе практик time management (так иногда называют операционный учёт для личности), или практик личной продуктивности (есть и такое название) лежат модификации довольно древней практики GTD[1], где главное ровно вот это: всё записывать, ничего не помнить, голова должна быть свободна от планов — все планы нужно выгрузить из головы в экзокортекс, но иметь привычку регулярно (несколько раз в день!) заглядывать в списки дел и заниматься стратегированием и планированием. Из современной литературы по управлению собственными работами можно посоветовать книги Максима Дорофеева[2].