Системная инженерия и менеджмент продукта

У руководителя проекта есть три боли:

- нет уверенности, что заказчик заказал то, что ему на самом деле нужно (неполное или неправильное техническое задание);
- нет уверенности, что техническое решение сможет встроиться в эксплуатационную среду заказчика и даст плановый экономический эффект (технико-экономическое обоснование проекта неполное или неверное);
- нет понимания, к чему приведет предлагаемое инженерами изменение (да, они уверяют, что это ни на что не повлияет, слышал такое много раз).

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

На практикуме «Системная инженерия и менеджмент продукта» Вячеслав Мизгулин учит применять отработанный им за несколько лет применения инструментальный подход к решению основных проблем руководителя проекта.
С помощью архитектурного языка ArchiMate и системного подхода Школы системного менеджмента вы по шагам пройдете по каждой ступеньке этого подхода и впервые увидите важные аспекты вашего проекта, на которые раньше не обращали внимания.
Ключевые диаграммы выглядят очень просто, это обычные матрицы:

Но они заставляют очень серьезно подумать над тем что, как и зачем вы делаете.
Подробнее о методе матриц в системной инженерии Вячеслав пишет в своей книге:
https://ridero.ru/books/sistemnyi_inzhener/

Этот курс объединяет практичное использование современного системного подхода и максимальное применение ваших знаний проекта и предметной области.

Я сейчас делаю с помощью него ответственный коммерческий проект и заказчик доволен.

Модель жизненного цикла магазина торговой сети

При рассказе об орг.возможностях (capabilities, TOGAF capability based planning) всегда встает вопрос рассказать про конкретный пример жизненного цикла, без упрощенных "колбасок" и V-диаграмм. Сделал пример, по которому можно разбираться:

Модель жизненного цикла магазина торговой сети 
(в PDF, высокое разрешение кликни сюда)

Упрощенный и обобщенный жизненный цикл магазина розничной торговли

Для чего используются модели жизненного цикла?

1. Планирование программы проектов (переход из AS IS в TO BE)
2. Определение целей и содержания отдельных проектов
3. Технологическое планирование предприятия (какое ИТ и другое технологическое решений подойдет и почему)
4. Управление человеческим капиталом (какие компетенции есть и будут нужны для реализации стратегии)

PDCA и онтологика

Когда говоришь “PDCA”, все кивают головами, всем все понятно, только почему-то почти ни у кого этот цикл не работает, а значит, почти никто его не понимает, просто не признается себе в этом. Проблем в его применении несколько, и все они приводят к практической невозможности перехода на проектное управление в российской компании, а решение этих проблем дает гипотезу, объясняющую широкое распространение неправильного понимания Agile в России.

Особенности мышления в сравнении с деятельностью

Работаем мы с индивидами (4Д объектами), а планируем в концептах (в абстрактных объектах). Другими словами, мы думаем “молоток”, видим любую штуку, подходящую под этот концепт, хватаем ее и колотим куда надо. Индивиды реальны, концепты в голове. Т.е., мы всегда концептуализируем деятельность, потому что деятельность происходит в реальном мире, а планирование происходит в голове. Какой-то однородный кусок реального мира называется доменом - домен строительства, домен управления финансами, домен домохозяйства. В доменах происходит разделение труда, есть специализации.

Цикл PDCA подразумевает, что вам нужно концептуализировать:

- Свою деятельность, моделирование вашего кусочка предметного домена.
- Деятельность других людей в вашей команде, моделирование целикового предметного домена.
- Деятельность вашего заказчика (Сюрприз! Потому что если у вас нет концептов деятельности заказчика, то как вы проверите качество вашей работы на уровне планов? Так и происходит проверка качества с помощью фактической передачи результата работ заказчику в отсутствии моделей деятельности). Моделирование домена заказчика.
- Деятельность по изменению деятельности. Организационное моделирование.

Т.е. за кажущейся простотой аббревиатуры стоят 4 навыка только планирования. А ведь эти планы еще надо прочесть, понять и исполнить, не говоря уже о том, что проконтролировать. Тем, кому кажется, что я переусложняю, предлагаю еще раз честно ответить на вопрос “а у вас PDCA работает”?

План нужен для одной вещи - для предсказания состояния реального мира, домена. Мы строим план из точки прошлого и затем видим факт, который можем сравнить с планом. Если расхождение между планом и фактом для нас приемлемое, то план (предсказание модели) был хорошим, если расхождение было значительным и мы делали что-то неправильное, то план был плохим*. Чем меньше у нас знаний о домене (т.е. чем хуже концептуализация домена), тем слабее ваша предсказательная сила, тем меньше и хуже вы можете планировать, тем больше вам надо договариваться по поводу фактов, доказывать, что результат работ и есть то, что хотели сделать.

https://en.wikipedia.org/wiki/Cynefin_framework объясняет различие между уровнями концептуализации домена. Если модели, позволяющие качественно планировать, доступны почти всем, совместная деятельность простая, например, все водят автомобиль в городе. А если деятельность часто меняющаяся, сложная, либо команда не может договориться по поводу моделей планирования (обращаю внимание на этот момент), то концептуализация хаотическая. Всяческие канбан доски как раз позволяют сделать общую для команды концептуализацию проекта.

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

Что такое прагматика?

“Лучше ударить кривой палкой, чем потратить полжизни на ее исправление”.

История из жизни. Менеджер и инженер обсуждают сроки реализации задачи.
- Когда закончишь?
- Не знаю, надо подумать.
- Мне ответ нужен прямо сейчас, надо идти на совещание, там будет принято решение делать это вообще или нет.
- Не могу я сейчас ответить, это же считать надо. Я сейчас скажу, а потом с меня же эти сроки и спросят.
- Т.е., не дашь сейчас сроки?
- Не дам, и не проси.
- Хорошо, к следующему году сделаешь?
- К следующему точно сделаю.
- К сентябрю?
- Да, к сентябрю смогу.
- За 3 недели?
- Думает несколько секунд, кивает головой.
- За неделю?
Резко мотает головой, перекрещивает руки, говоря всем видом, что “вот, я же говорил”!
- Другими словами, твоя оценка сроков от 2 до 3 недель?
- Да, где-то в этих пределах.
- Спасибо, этого достаточно.

Основной принцип моделирования и планирования. 

“Нет моделей точных, есть модели более полезные для чего-то или менее полезные для чего-то”. Не обязательно иметь посчитанные с высокой степенью точности и достоверности прогнозы, чтобы принять решение, надо каждый раз думать, в какой части спектра мышления вы хотите принимать решение по поводу ситуации. Другой принцип: “Все знания вероятностны, но это неточно”. Мы ничего не знаем с абсолютной точностью, мы всегда должны думать в терминах вероятностей и менять свои модели в цикле PDCA постепенно сдвигая их при получении свидетельств об их точности-неточности, а не отказываться от них сразу и полностью после какой-то ошибки планирования, как это часто бывает. “А, этот ваш проектный менеджмент не работает, мы один раз пробовали, ничего не дало”.

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

Сравните, например, с тем, что пишет Nick Lavingia в статье “How to create world-class project management organization?” Шаг 1 “Создайте общий язык”, другими словами, узнайте и согласуйте между собой концепты домена. На всякий случай о том, кто такой автор.

Другими словами, помимо того, что надо уметь строить 4 вида моделей (Plan-Do-Check-Act), надо уметь еще и делать по модели (Plan-Do-Check-Act), уметь контролировать (Plan-Do-Check-Act) факт того, что люди действуют в соответствии с моделью, а там могут быть отклонения в действиях, отклонения в результатах (ошибки в навыках, ошибки в знаниях, ошибки в правилах). И метод “5 почему” имеет свои особенности исполнения в отношении каждого из вариантов использования, так, “5 почему” может касаться исследования того, что работа проводилась не в соответствии с утвержденными моделями, а может в отношении того, что модели разрабатываются неправильно. И перескакивать между этими линейками вопросов нельзя, хотя и случается при каждом удобном случае, когда начинают расспрашивать про модели, а завершают расспросы доменом.

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

Еще раз, основная мысль, в виде истории, которую рассказал биржевой трейдер: “Если ты можешь предсказывать с точностью 51%, иди на ФОРЕКС, станешь миллионером”. Не всегда нужна точная модель, иногда нужно уметь строить прогноз чуть-чуть лучше других, этого будет достаточно. Будьте прагматиками.

Это именно то, о чем говорит PMBOK, когда пишет, что команда проекта должна адаптировать предлагаемые практики к требованиям конкретного проекта.

Как пример, разберу карту процессов Риты Малкахи в аспекте.

Какие есть модели в управлении проектами?

Устав
Матрица анализа стейхолдеров
Реестр стейкхолдеров
Список и атрибуты операций
Требования к ресурсам
План управления изменениями
План управления коммуникациями
Базис по стоимости
План управления стоимостью
План управления человеческими ресурсами
Матрица прослеживаемости требований
Список контрольных точек
Сетевая модель расписания
Матрица вероятности и рисков
План улучшения процессов
План управления проектом
Расписание
Описание содержания
План управления качеством
Спецификация требований
План управления рисками
Роли и ответственность команды
План управления расписанием
План управления содержанием
План управления стейкхолдерами
Словарь ИСР
ИСР
Журнал изменений
Запрос на изменения
Журнал решений
Журнал проблем
Аудит качества
Реестр команды
Оценка эффективности члена команды
Оценка эффективности команды
Отчет по статусу проекта члена команды
Операционное соглашение команды
Отчет по статусу от подрядчика
Отчет по освоенному объему
Акт сдачи-приемки
Отчет о ходе проекта
Анализ рисков
Анализ отклонений
Закрытие проекта
Накопленный опыт
Анализ закупок
Закрытие контракта

Модели нужны нам для предсказаний. Что же они предсказывают? 

Устав - даты начала и завершения, какие ресурсы будут выделены на проект и кто какую ответственность несет. Можно еще предсказать карьеры участников в случае успеха либо неудачи.
Матрица анализа стейхолдеров - на какие темы надо будет много общаться в проекте
Реестр стейкхолдеров - с кем надо будет много общаться на проекте и на какие темы, какая будет динамика и особенности этого общения
Список и атрибуты операций - что понадобится для выполнения работ проекта, что важное в этих работах, а что нет
Требования к ресурсам - как и где искать людей для выполнения проекта, как будет устроен маркетинг вакансий и найм
План управления изменениями - с какой скоростью будут реализовываться изменения, сколько денег на это будет тратиться, насколько фактический результат будет соответствовать формальному описанию
План управления коммуникациями - кто будет активно включен в работу над проектом, кто будет находится в неведении, где будут циркулировать слухи, где будут возникать непонимания
Базис по стоимости - сколько потратят денег на проект, насколько сложным будет согласование бюджета, какая будет нагрузка на проектную команду перед бюджетным циклом
План управления стоимостью - какие будут перерасходы и нецелевое использование бюджета, сколько будет нарушений в части стоимости, в каких областях эти нарушения будут возникать
План управления человеческими ресурсами - какая будет культура в проекте, сильно ли повлияет человеческий фактор, где будут очаги недовольства и как будет циркулировать информация между группами влияния
Матрица прослеживаемости требований - какие требования будут реализованы качественно, а какие нет, кто из стейкхолдеров будет больше удовлетворен проектом, кто будет менее доволен и будет мешать проекту
Список контрольных точек - где возникнут неожиданные проблемы в проекте
Сетевая модель расписания - какие будут сроки окончания и бюджет проекта по мере появления новой информации о скорости выполнения работ (отчетов по ходу работ)
Матрица вероятности и рисков - соответствие текущих знаний команды домена проекта задаче, объем дополнительных работ и необходимости контроля в проекте по ряду задач
План улучшения процессов - что будет часто повторяться и на что будут потрачены основные деньги и усилия, где будет больше внимания операционного руководства проектом
План управления проектом - на что будет направлено внимание руководства, за что будут спрашивать и за что платить деньги и награждать
Расписание - когда будут начинаться и завершаться работы, кто чем когда будет занят
Описание содержания - что будет сделано в проекте, сколько это будет стоить и сколько времени займет, кто из людей потребуется, где были сделаны аналогичные проекты и где есть подобная экспертиза
План управления качеством - что мы передадим заказчику, зачем ему нужен такой результат, как он его будет использовать, на чем построен его бизнес
Спецификация требований - как будет вести себя изделие
План управления рисками - где возникнут проблемы, что станет их причиной, что мы будем делать, чтобы этого не случилось
Роли и ответственность команды - кто чем будет заниматься, где возникнут проблемы с исполнением и почему
План управления расписанием - как часто и насколько мы сможем менять сроки исполнения работ, количество авралов, сверхурочных, ошибок
План управления содержанием - насколько сложно и долго будет урезать и наращивать содержание проекта, кто будет принимать такие решения и кто на них сможет влиять
План управления стейкхолдерами - успешность влияния команды управления на проект, возможные конфликты и предмет конфликтов, способы решения конфликтов
Словарь ИСР - успешность коммуникации в команде, количество неправильно сделанной работы
ИСР - распределение полномочий, ответственности, объем работ проекта, нагрузка на команду управления и другое руководство
Журнал изменений - количество проблем с исполнением, качество работы команды и подрядчиков ,качество планирования и проектирования
Запрос на изменения - степень зрелости команды планирования, проработанность предметной области, квалификацию исполнителей
Журнал решений - потенциальные проблемы с долгосрочными следствиями принятых решений, возможность успешного расследования инцидентов и разбора действий руководства
Журнал проблем - открытость коммуникаций в проекте, доверие, командный дух, стремление к результату, квалификация команды
Аудит качества - умение работать со спецификациями, экспертиза в измерениях и организации рабочего процесса
Реестр команды - культура команды, динамика общения внутри команды, потенциальные конфликты, зоны ответственности и полномочия людей
Оценка эффективности члена команды - отношения между членами команды, эффективность и результативность внутри команды, срывы сроков и возможность решения проблем
Оценка эффективности команды - отношения между членами команды, эффективность и результативность команды, срывы сроков и возможность решения проблем, удовлетворенность команды и заказчика результатами проекта
Отчет по статусу проекта члена команды - когда будет выполнена работа, насколько хорошо он оценивает сроки и трудоемкость задач, достаточность квалификации работника для назначенных задач, способность решать проблемы, взаимоотношения в команде
Операционное соглашение команды - как будет вести себя команда, как будут решаться проблемы
Отчет по статусу от подрядчика - когда будет выполнена работа, насколько хорошо он оценивает трудоемкость и решает проблемы, будут ли выполнены контрактные обязательства
Отчет по освоенному объему - во сколько обойдется проект, сколько на нем можно будет заработать
Акт сдачи-приемки - вероятность успешного выполнения работы, вероятность возникновения проблем с результатом, вероятность юридических разбирательств, вероятность получения повторного контракта
Отчет о ходе проекта - возможные управляющие действия со стороны руководства, карьерные последствия для членов команды, изменения в проекте по срокам-бюджетам-содержанию
Анализ рисков - квалификацию команды в домене проекта, успешность завершения проекта, работы по устранению риска
Анализ отклонений - необходимость переработок, переноса сроков, изменения содержания, перебросок ресурсов между задачами
Закрытие проекта - объем работ, доступность ресурсов, вероятность получения прибыли, премий, наград
Накопленный опыт - количество ошибок в подобных проектах, сроки и стоимость исполнения таких проектов, вероятность получения бизнеса по таким проектам
Анализ закупок - точность бюджетов по аналогичным закупкам, содержание будущих договоров на поставку и отношения с подрядчиками и поставщиками
Закрытие контракта - удовлетворенность сторон договора, вероятность возникновения проблем по предмету договора, сроки и бюджеты аналогичных договоров

Именно прогнозы и модели, по которым формируются эти прогнозы и являются основным содержанием бесед по методике Тулгана “Все начальники делают это”. И на тренинге по онтологике как раз и учат методикам правильного общения в команде. А т.к. руководители проектов 90% времени общаются с другими, в этом заключается их работа, то надо уметь это делать лучше других. Этому учат здесь: 

http://system-school.ru/ontologics