Максим Цепков - Менеджмент цифрового мира

Таким образом, к описанному выше списку стоит относиться, скорее, как к списку важных фокусов, которые, как показывает опыт, стоит держать под контролем тем или иным образом. При этом, что важно, каждый из фокусов надо держать отдельно, и потому смешивать их на одной встрече не слишком желательно, даже если состав участников совпадает. Дэвид Андерсон в своей книге показывает, как эти механизмы возникали в его командах по мере эволюционного развития процесса, и как менялась их форма. Делать это в форме отдельных серий встреч – самый простой способ, но вовсе не обязательный. И в любом случае, встречи появляются постепенно, при чем порядок тоже может быть различен. Подробнее об этом узнать в докладе Алексея Пименова на AgileDays-2018 « Канбан! Что новенького?» В отличие от его доклада на AgileDays-2019, на который я ссылался в начале статьи, этот дает обзор новых техник и рассчитан на более глубокий уровень слушателя.

Масштабирование.

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

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

Отметим, что при масштабировании Kanban-системы на компанию в целом или на автономные бизнес-единицы помимо метрик, показывающих прохождение потока задач становятся актуальными метрики, показывающие финансовые результаты деятельности. Естественным желанием является взять готовую систему стандартных финансовых метрик. Засада в том, что не всякая система метрик является совместимой с теорией ограничений, которая лежит в основе Kanban. Это подробно разобрано в книге Томаса Корбета «Учёт прохода. Управленческий учет по теории ограничений» (оригинал «Throughput accounting», есть конспект). И может получиться, что оптимизация потока оценивается метриками и KPI негативно. Эту опасность необходимо представлять, и выбирать метрики правильно.

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

Ячейкой организации в любом случае является автономная самоорганизующаяся Agile-команда, поэтому совместимость способов управления с Agile-культурой является принципиальным требованием. Опыт показывает, что многие подходы менеджмента, основанные на уважении авторитета руководителя, полагаемого безусловным, или следовании за непогрешимым лидером не выдерживают столкновения с Agile-культурой: сотрудники могут просто уйти целой командой. И если руководство привыкло к такому стилю управления, то в Agile нет никакого смысла. С другой стороны, как я говорил в главах «Три вызова цифрового мира» и «Цифровой мир: от физического труда – к умственному» методы регулярного менеджмента в цифровом мире перестают работать, а Agile-методы являются одной из работающих альтернатив, что подробно рассмотрено в главе «Agile – ответ IT на вызовы цифрового мира».

Фреймворки имеют разную сложность и рассчитаны на компании или подразделения разного размера. При этом большинство из них рассчитано на короткие цепочки создания ценности, когда одна кроссфункциональная команда делает продукт, поставляемый потребителям. Как я писал в главе «Место Agile-команд в компании», в условиях неопределенности и быстрого изменения условий работы компании в VUCA-мире короткие цепочки являются естественным способом организации труда, способным быстро реагировать на изменения, в отличие от стабильных условий функционирования, которые ведут к специализации и образованию длинных цепочек из функциональных подразделений.