Нельзя "назначить исполнителя на проблему". Пока предмет, результат, конфигурация и правило готовности работы не понятны - назначать на неё человека нет смысла: держаться нужно не за процедуру и не за роль, а за рабочий продукт. Он и работы по смене его состояний - якорь и точка сборки усилий команды в любой сложной и непонятной ситуации.

Мог написать этот пост про моду на Agile-доски и discovery-upstream/development-downstream в программной инженерии - тема сама напросилась, когда я разделял операционный поток проектного департамента на потоки. Но это увело бы в сторону от главного: от того, на чём команда держится, когда неясно, что делать.

Важно, что произошло за неделю: я разделил цифровую модель операционного потока на "Анализ и Подготовка", "Разработка и Поставка" и "Управление". Оказалось, что подходы к анализу и синтезу решений, которые в IT называют discovery/upstream и development/downstream, гораздо ближе к тому, что происходит на земле грешной - а не только в полированной отчётности заказчика (чем выше - тем больше полировки и меньше связи с физикой). В том числе и в нашей строительной отрасли: многое из того, что научились делать проджект-менеджеры программистов, теперь делают и главные инженеры проектов в разработке проектной документации.

Проблему в такой ситуации нужно вести не как проект и не как процесс, а как кейс - по методу case management: "необходимо прибыть из точки А в точку Б, способов много, работы разные, а закончиться должны одинаково - прибытием в точку Б".

Что уже понятно как эффект: разделение на "Анализ и Подготовка" и "Разработка и Поставка" позволяет разделить время аналитики от времени разработки предельно чисто - как "Ожидание" от "Касание/В работе". А значит можно замерить Flow Efficiency именно на участке самого дорогого ресурса - инженерного блока, то есть разработчиков рабочих продуктов проектной документации. Это даёт прозрачно внятную модель в контур управленческих решений: видно, где снижать время ожидания и где проявляется системное Ограничение выпуска рабочих продуктов.

В PRINCE2, кстати, в названиях работ и проектов рекомендуют писать их результат - тот же принцип, что и в кейс-менеджменте, где кейс называют по предмету дела. Название кейса должно содержать предмет/рабочий продукт с желаемым состоянием (точка Б), либо содержание проблемы с обратным знаком.

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

А что в вашей команде остаётся общей точкой сборки, когда непонятно, что делать - продукт, процедура или роль?

#ЦифроваяТрансформация #УправлениеПроектами #ГИП