Перед рассуждениями объясню понятие платформы системы.
Возьмем кубики Лего https://shop.lego.com/en-US/Themes
В рамках одной темы они полностью совместимы между собой и вы можете собирать из них что угодно, и не беспокоиться, подойдут ли модули один к другому. Это позволяет сосредоточиться на замысле того, что вы строите, и не думать о подгонке строительных блоков. В терминах системной инженерии эта совместимость обеспечивается платформой. Платформа состоит из типовых модулей и типовых интерфейсов между этими модулями. В случае с Лего строительные блоки будут модулями, а посадочные места - интерфейсами.
Для автомобиля платформа и интерфейсы будут уже сложнее, но принцип сохраняется:
Платформа
Интерфейсы
Рассмотрим обеспечивающую систему (предприятие) как черный ящик. Какую потребность (user need) удовлетворяет освоенная практика управления проектами организации (organizational project management)?
Организация с УПО должна иметь заметно более высокую устойчивость к возникновению непредвиденных ситуаций (robustness) и возможность самодостаточного развития (sustainability) по сравнению с организацией без УПО.
Эта потребность ведет за собой (drives) архитектурные требования:
- Достаточность и корректность инвестиций. В рамках ОУП обеспечиваются надлежащие и достаточные (proper) в плане объема, распределения и графика, инвестиции, которые отвечают потребностям в возврате и профиле риска (ROI and risk profile) стейкхолдеров, осуществляющих надзор за общей деятельностью организации (governance stakeholders)
- Ориентированность на рынок при распределении ресурсов между работами. Ресурсы направляются на реализацию тех характеристик выпускаемой продукции и оказываемой этой продукцией клиентских сервисов, которые востребованы целевым рынком (стейкхолдерами системы) с приемлемым уровнем возврата инвестиций и профилем риска работ по реализации этих характеристик
- Точные оценки требуемого времени для завершения работ по созданию продукта и/или системного описания либо части продукта и/или системного описания с приемлемым уровнем риска.
Рассмотрим архитектуру ОУП, неважно, будет ли она реализована в рамках P2M, OPM3, P3M.
Стейкхолдер портфельный менеджер смотрит на обеспечивающую систему (организацию), и видит портфель, который состоит из проектов, программ и работ BAU (business as usual). Его интересуют (stakeholder concerns) маржинальные финансы организации и глобальное распределение работ. Программы, проекты и BAU - это модули портфельного управления, ниже них он не идет, портфель собирается именно из этих блоков, это его системный уровень. Портфельный менеджер отвечает за то, чтобы делались правильные вещи, другими словами, портфельный менеджмент реализует архитектурное требование №1 “Достаточность и корректность инвестиций”.
Стейкхолдер программный менеджер отвечает за весь жизненный цикл продукта/сервиса. Другими словами, за удовлетворение потребностей внешних стейкхолдеров, другими словами, за системные эффекты. Поэтому он рассматривает систему в ее операционном окружении, оно же “использующая система” (using system). Крупные проекты - это как правило программы, тем более учитывая тенденцию проникновения Scrum и two pizza teams в разные области.
Поэтому, программный менеджер смотрит на организацию и видит проекты и требования, из которых и строится его система, это его системный уровень. На уровне программы происходит интеграция сложных систем, ее работа и прекращение работы. Интересы программного менеджера - возможность, система, инфраструктура, внешние стейкхолдеры.
Стейкхолдер проектный менеджер отвечает за то, чтобы дать точную оценку, когда будет готов продукт, за который он отвечает. Все проектные методологии, независимо от того, критический ли это путь, цепь, график сгорания и прочее, отвечают только на этот вопрос. “С текущими ресурсами когда будет готово”? При этом учитывается профиль риска работ. Поэтому менеджер проекта смотрит на организацию, и видит пакеты работ, это его системный уровень. На этом уровне производятся оценки длительности, с помощью самых разных моделей. Его интерес - работа, а точнее даже тот ее аспект, который связан с “проходом” (throughput). Точность оценки, в частности, обеспечивается тем, что обеспечивается стабильная защищенная среда проекта (PRojects IN Controlled Environment, Скрам, PMBOK - все говорят об одном и том же, проекты надо защищать от изменений).
За что отвечает P3O (Portfolio, program, project management office)?
- Связанность системных уровней, единый viewpoint
- Платформа УПО (типовые интерфейсы и модули на каждом системном уровне)
- Поддержание целостности требований стейкхолдеров к технологии УПО
Комментариев нет:
Отправить комментарий