Управление ожиданиями, управление стейкхолдерами, управление коммуникациями - это все набор практик, который влияет на восприятие успешности проекта. За ними стоит единая онтология, а эта цепочка текстов задает стартовую точку для того, чтобы выстраивать логику успешного взаимодействия со стейкхолдерами.
Контрольная точка, далее КТ - событие, наступление или пропуск которого сдвигает оценку вероятности успеха системы или проекта для конкретного стейкхолдера.
Прохождение контрольной точки производится по процедуре прохождения чек-листа.
Чек-листы используются для сверки целевой и обеспечивающей системы против определения системы. Для этого и нужна вся команда при их прогоне, а не просто аналитик, который к каждому пункту прикрепит выгрузку из PLM.
Поэтому все пункты чек-листа делятся на:
1) Дисциплинарные. Проверка причинного вывода по основным дисциплинам. Должны быть предоставлены свидетельства, которые по микротеории дисциплины сдвигают оценку вероятности успешности проекта. Например "Архитектурные требования выделены и запланирована их проверка", "Скорость при посадке больше 200 узлов".
2) Технологические. Проверка готовности технологий к использованию. Должны быть предоставлены свидетельства того, что технология способна реализовать практику жизненного цикла. Например, "производственная линия выпускает продукцию по спецификациям с выходом годных 99.5% на пиковом времени такта в течение минимум трех производственных смен".
3) Архитектурные. Проверка правильности реализации архитектуры. Должны быть предоставлены свидетельства того, что архитектура системы соответствует определению архитектуры. Например, "команда согласна, что продукт реализован в соответствии с замыслом".
4) Надежности человека. Проверка минимум на skills based/rules based/knowledge based ошибки в ходе работ. Например, "аудит безопасности не выявил критических нарушений в технике безопасности на производственной линии, процесс обеспечения безопасности постоянно улучшается.
Пост про успешность системы http://sdu2020.blogspot.com/2018/06/blog-post_6.html
Пост про успешность проектов, программ и портфелей http://sdu2020.blogspot.com/2018/06/blog-post_7.html
Пост про онтологию мышления о рисках
http://sdu2020.blogspot.com/2018/08/blog-post_29.html
Пост про уровни абстракции
https://ailev.livejournal.com/1442975.html
Страница метода РИМ-3 https://rim-iii.postach.io
Контрольные точки при управлении проектами. Применение и проектирование https://www.litres.ru/uriy-shoydin/kontrolnye-tochki-pri-upravlenii-proektami-primeneni-35232320/
Важное следствие из предыдущих постов - стейкхолдер должен признавать событие фактом. Для этого в онтологии стейкхолдера должны быть понятия, концепты, в которых описывается факт. Это и есть эффект “стейкхолдерской оптики”, если стейкхолдер не может выделить объект на фоне, он не может признать факт. Типичный пример, с которыми часто сталкиваются при переходе на канбан - пока менеджер не узнает про существование очередей, стоимости задержки задачи, связи эффективности работы ресурса и времени выполнения задачи, он не может понять насколько его стиль управления неэффективен и не верит замерам эффективности во время операционных аудитов. Более яркий пример - если человек не верит в существование бактерий и иммунитета, вы не сможете убедить его делать прививки, он просто не признает факта того, что он заболел из-за отсутствия иммунитета. Поэтому то, что является контрольной точкой для одного не будет контрольной точкой для другого, т.к. доказательная сила фактов зависит от онтологии, в которой мыслит и действует конкретный стейкхолдер.
Факты могут относится к М0, предметной области конкретного проекта либо задачи, либо к М1 для контрольных точек из методологий (гейты, готовность рабочих продуктов метода) либо состояний подальф для данного класса проекта (ключевой технологический партнер выбран, где технологический партнер подальфа команды).
Методически КТ из М0 приходят из PBS/WBS и из диаграмм системного контекста, подробно я опишу эту практику в следующих постах.
При этом возникает проблема контроля и управления проекта, т.к. стейкхолдеров много, фактов, которые влияют на оценку ими вероятности успеха проекта, тоже много, и их надо группировать. Первый очевидный способ группировки - это разделение по системным уровням, как минимум КТ организационного контекста, КТ контекста использования, КТ системного контекста, а при необходимости и КТ по специальностям. Далее эти контрольные точки можно сгруппировать в более крупные блоки, фактически делая небольшие контрольные точки пунктами чек-листа более крупной и значимой контрольной точки.
Например, как это делает МинОбороны США:
https://docs.google.com/document/d/1iQlq8MKudedfjrOsXJWG5YtY3dRCrixmSWvnXCZbjq0/edit?usp=sharing
Группировка обычно делается по структуре PBS/WBS, например, отслеживается не смена состояний системных элементов, а смена состояний подсистем. Учитывая, что системных разбиений может быть множество, в зависимости от дисциплин, которые задействованы в проекте, в проекте может быть множество планов по контрольным точкам - инженерный, маркетинговый и продажный, финансово-экономический и другие. Прожекторная модель позволит вам показывать только те КТ, которые значимы для данного стейкхолдера и сдвигают его оценку успешности проекта.
В примере чек-листов МинОбороны США можно четко увидеть использование подальф “платформа” для альфы “Система” и подальфы “релиз” для альфы “Определение системы”.
Прохождение контрольной точки производится по процедуре прохождения чек-листа.
Чек-листы используются для сверки целевой и обеспечивающей системы против определения системы. Для этого и нужна вся команда при их прогоне, а не просто аналитик, который к каждому пункту прикрепит выгрузку из PLM.
Поэтому все пункты чек-листа делятся на:
1) Дисциплинарные. Проверка причинного вывода по основным дисциплинам. Должны быть предоставлены свидетельства, которые по микротеории дисциплины сдвигают оценку вероятности успешности проекта. Например "Архитектурные требования выделены и запланирована их проверка", "Скорость при посадке больше 200 узлов".
2) Технологические. Проверка готовности технологий к использованию. Должны быть предоставлены свидетельства того, что технология способна реализовать практику жизненного цикла. Например, "производственная линия выпускает продукцию по спецификациям с выходом годных 99.5% на пиковом времени такта в течение минимум трех производственных смен".
3) Архитектурные. Проверка правильности реализации архитектуры. Должны быть предоставлены свидетельства того, что архитектура системы соответствует определению архитектуры. Например, "команда согласна, что продукт реализован в соответствии с замыслом".
4) Надежности человека. Проверка минимум на skills based/rules based/knowledge based ошибки в ходе работ. Например, "аудит безопасности не выявил критических нарушений в технике безопасности на производственной линии, процесс обеспечения безопасности постоянно улучшается.
Пост про успешность системы http://sdu2020.blogspot.com/2018/06/blog-post_6.html
Пост про успешность проектов, программ и портфелей http://sdu2020.blogspot.com/2018/06/blog-post_7.html
Пост про онтологию мышления о рисках
http://sdu2020.blogspot.com/2018/08/blog-post_29.html
Пост про уровни абстракции
https://ailev.livejournal.com/1442975.html
Страница метода РИМ-3 https://rim-iii.postach.io
Контрольные точки при управлении проектами. Применение и проектирование https://www.litres.ru/uriy-shoydin/kontrolnye-tochki-pri-upravlenii-proektami-primeneni-35232320/
Важное следствие из предыдущих постов - стейкхолдер должен признавать событие фактом. Для этого в онтологии стейкхолдера должны быть понятия, концепты, в которых описывается факт. Это и есть эффект “стейкхолдерской оптики”, если стейкхолдер не может выделить объект на фоне, он не может признать факт. Типичный пример, с которыми часто сталкиваются при переходе на канбан - пока менеджер не узнает про существование очередей, стоимости задержки задачи, связи эффективности работы ресурса и времени выполнения задачи, он не может понять насколько его стиль управления неэффективен и не верит замерам эффективности во время операционных аудитов. Более яркий пример - если человек не верит в существование бактерий и иммунитета, вы не сможете убедить его делать прививки, он просто не признает факта того, что он заболел из-за отсутствия иммунитета. Поэтому то, что является контрольной точкой для одного не будет контрольной точкой для другого, т.к. доказательная сила фактов зависит от онтологии, в которой мыслит и действует конкретный стейкхолдер.
Факты могут относится к М0, предметной области конкретного проекта либо задачи, либо к М1 для контрольных точек из методологий (гейты, готовность рабочих продуктов метода) либо состояний подальф для данного класса проекта (ключевой технологический партнер выбран, где технологический партнер подальфа команды).
Методически КТ из М0 приходят из PBS/WBS и из диаграмм системного контекста, подробно я опишу эту практику в следующих постах.
При этом возникает проблема контроля и управления проекта, т.к. стейкхолдеров много, фактов, которые влияют на оценку ими вероятности успеха проекта, тоже много, и их надо группировать. Первый очевидный способ группировки - это разделение по системным уровням, как минимум КТ организационного контекста, КТ контекста использования, КТ системного контекста, а при необходимости и КТ по специальностям. Далее эти контрольные точки можно сгруппировать в более крупные блоки, фактически делая небольшие контрольные точки пунктами чек-листа более крупной и значимой контрольной точки.
Например, как это делает МинОбороны США:
https://docs.google.com/document/d/1iQlq8MKudedfjrOsXJWG5YtY3dRCrixmSWvnXCZbjq0/edit?usp=sharing
Группировка обычно делается по структуре PBS/WBS, например, отслеживается не смена состояний системных элементов, а смена состояний подсистем. Учитывая, что системных разбиений может быть множество, в зависимости от дисциплин, которые задействованы в проекте, в проекте может быть множество планов по контрольным точкам - инженерный, маркетинговый и продажный, финансово-экономический и другие. Прожекторная модель позволит вам показывать только те КТ, которые значимы для данного стейкхолдера и сдвигают его оценку успешности проекта.
В примере чек-листов МинОбороны США можно четко увидеть использование подальф “платформа” для альфы “Система” и подальфы “релиз” для альфы “Определение системы”.
Комментариев нет:
Отправить комментарий