В последнее время в обсуждении одной модной темы часто натыкаюсь на непонимание (или неприятие?) одного и того же важного момента.
Тема – кардинальное преобразование организации, ведущее к появлению способности быть успешной в конкурентной быстро меняющейся бизнес-среде. Здесь для краткости можно было бы написать «цифровая трансформация», «business agility» и т.п. Но мы же здесь все приличные люди 😊

А момент вот какой.
Все понимают (во всяком случае соглашаются с тем), что в среде с высокой степенью неопределённости/вариативности для обеспечения быстрой работы производственной системы кроме всего прочего нужна организация потока. Вытягивающая система, WIP-лимиты, всё, как написано в книжках про построение быстрого, равномерного потока. Большинство это знает/понимает. Те, кто работает в продуктовых командах так и работают…
Или думают, что работают.
Потому, что когда речь заходит об организации входа в производственную систему (в продуктовую команду), многих устраивает ситуация, в которой у каждой задачи в бэклоге есть установленный срок реализации. «Ну, а как иначе? Ведь бизнес устанавливает дедлайн (в лучшем случае консультируясь с нами, для того, чтобы дедлайн был реалистичным».

Два тезиса, к обсуждению которых обычно приходят такие дискуссии.

1. При условии, что мир недетерминированный (например, в терминах Cynefin) вы не построите равномерный поток, если на все (многие) задачи установлен чёткий срок решения. А значит уровень прогнозируемости будет очень плохим. Т.е никому, включая заказчика лучше не будет.
   Если у вас при увлечении дедлайнами поток таки быстрый и равномерный, то спешу обрадовать: вам не нужен поток. Вы живёте в детерминированном мире, где плюс-минус всё можно чётко рассчитать и распланировать. Все операции отнормированы; задачи могут быть и разнообразными, но по каждой всё чётко и понятно. С ресурсами всё тоже известно заранее. Вариативность? Не слышали. VUCA какая-то… Глупости всё это.
   Что тут можно сказать? Может быть, вам повезло. Но ущипните себя на всякий случай.
2. Дедлайны в заметной доле случаев не являются объективной потребностью. Это зачастую – механизм компенсации. Мы (и ИТ, и бизнес) не умеем управлять по-другому. Установка срока – это инструмент управления. Оказывается, можно без него (не без управления, а без дедлайна).

Последний тезис как-то совсем плохо заходит. Пожалуй, даже хуже чем идея о коллективной ответственности (продуктовой команды): ведь все же знают, что «коллективная ответственность – это безответственность» ©

В общем, то, что трансформация – это действительно серьёзно изменение (сдвиг парадигмы и вот это всё), ощущается даже на уровне разговоров. Разумеется, если разговоры о сути, а не про лозунги. И правдивость известной картинки подтверждается слишком часто.
А как у вас?

ТРЕНАЖЁР

Kanban Flow Metrics: управление потоковым производством на основе данных

Тренажёр про метрики на реальных примерах