четверг, 18 октября 2018 г.

Как управление по контрольным точкам влияет на восприятие успешности проекта

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

Контрольная точка, далее КТ - событие, наступление или пропуск которого сдвигает оценку вероятности успеха системы или проекта для конкретного стейкхолдера.

Прохождение контрольной точки производится по процедуре прохождения чек-листа.
Чек-листы используются для сверки целевой и обеспечивающей системы против определения системы. Для этого и нужна вся команда при их прогоне, а не просто аналитик, который к каждому пункту прикрепит выгрузку из 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
Пост про онтологию мышления о рисках
Пост про уровни абстракции
Страница метода РИМ-3 https://rim-iii.postach.io
Контрольные точки при управлении проектами. Применение и проектирование https://www.litres.ru/uriy-shoydin/kontrolnye-tochki-pri-upravlenii-proektami-primeneni-35232320/

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

Факты могут относится к М0, предметной области конкретного проекта либо задачи, либо к М1 для контрольных точек из методологий (гейты, готовность рабочих продуктов метода) либо состояний подальф для данного класса проекта (ключевой технологический партнер выбран, где технологический партнер подальфа команды).

Методически КТ из М0 приходят из PBS/WBS и из диаграмм системного контекста, подробно я опишу эту практику в следующих постах.

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

Например, как это делает МинОбороны США:
Группировка обычно делается по структуре PBS/WBS, например, отслеживается не смена состояний системных элементов, а смена состояний подсистем. Учитывая, что системных разбиений может быть множество, в зависимости от дисциплин, которые задействованы в проекте, в проекте может быть множество планов по контрольным точкам - инженерный, маркетинговый и продажный, финансово-экономический и другие. Прожекторная модель позволит вам показывать только те КТ, которые значимы для данного стейкхолдера и сдвигают его оценку успешности проекта.

В примере чек-листов МинОбороны США можно четко увидеть использование подальф “платформа” для альфы “Система” и подальфы “релиз” для альфы “Определение системы”.

среда, 10 октября 2018 г.

Польза от архитектуры предприятия (обновлено 18.10.2018)

Системная инженерия предприятия и архитектура предприятия это сравнительно новая область знания, появилась в начале 90-х годов. Она до сих пор активно развивается и границы дисциплины не определены. Для примера можно сранвить программы российских и иностранных ВУЗов:


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


Среди остальных факторов приведены также большая связность ИТ-ландшафта со стратегией, улучшение процессов управления рисками, стандартизация технологий и более высокий возврат инвестиций в ИТ.


Если обобщить возможные выгоды от архитектуры предприятия, то их можно разбить на две большие группы:
- выгоды на уровне управления ИТ активами;
- выгоды от улучшения коммуникациями.

Примечание Романа Соколова:
Перед тем как оценивать пользу и вообще начинать проекты, хорошо бы уточнить какое определение EA мы используем (и соответственно scope проекта). Есть 3 школы-взглядов на EA -- enterprise IT architecture (EITA), enterprise integration (EI) and enterprise ecological adaptation (EEA).
В первом случае мы работаем над Business-IT Alignment, соответственно одна из главнейших задач там снижение расходов на ИТ, оптимизация и согласование ИТ-портфолио под нужды бизнеса.
Во втором, также известном как Enterprise Coherency, ИТ это всего лишь одна грань, кроме которой необходимо проектировать бизнес (операционную) архитектуру, capability planning, бизнес модели и т.п. и согласовывать все аспекты внутри одного предприятия между собой.
В третьей EA школе мыслей, фокус перемещается с одного конкретного предприятия на планирование межорганизационную кооперацию например правительств или всей цепочки поставщиков-дистрибьюторов, индустрии, глобального рынка -- в общем адаптация к ускоряющимся изменениям окружающей среды вокруг предприятия, которую можно планировать и менять. Здесь же все тренды на virtual/boundaryless/networked enterprise, аутсорсинг и облака, big data & IoT часто не под контролем предприятия, глобализацию, объединение культур и тп.
Вторая и третья школы EA это прямая отсылка к системному мышлению (которых кстати тоже много разных сортов, см. Jackson M.C. 2003), но прежде всего к open and soft systems thinking, холизму, конструктивизму. Очевидно, что польза во всех случаях будет разная, значит и метрики разные. И да, все три типа ЕА школ могут быть реализованы в одном предприятии, потому надо договариваться что мы имеем в виду под EA.

У меня есть пару более свежих статей ( https://aisel.aisnet.org/mcis2014/41 , https://ieeexplore.ieee.org/document/7880427 , https://www.researchgate.net/.../323848486_Achieving... ), в итоге EA ROI хоть с какими то цифрами было исследовано только в 2006 году ( https://pdfs.semanticscholar.org/.../5c1ee60125238185aa59... ), в 2015 Zachman приводит ЕА кейс с цифрами (doi: 10.1080/08874417.2013.11645654 , p.11-12) , и еще пару цифр здесь ( http://www.opengroup.org/cio/CIOCornerArticle11.htm ) -- хотя там автор говорил что EA и не должна иметь ROI и return on assets (ROA) подходит лучше.
Польза от ЕА неявная, это похоже на вопрос как оценить стратегическое планирование или более эффективное принятие решений (в чем помогает EA) или системную инженерию (у Левенчука в книге было пару цифр) или прочие архитектурные практики. А также похоже на проблему оценки knowledge management, т.к. EA is about share of strategic knowledge.

Второй по частоте упоминания гол EA -- борьба со сложностью и снижение затрат на ИТ происходит еще и из-за устранения дубликатов, когда например в компании более сотни бизнес юнитов со своими несогласованными ИТ департаментами, а соответственно и ИТ системами +переиспользование которые вы упомянули.
Раз уж мы говорим про вторую и третью EA школы, то польза там должна быть куда больше чем "выгоды на уровне управления ИТ активами", т.к. ИТ это всего лишь одна грань этих школ. Эти школы еще мало исследованы в научном сообществе (соответственно и их польза). Тем не менее, там речь про agile enterprise и быструю адаптацию к изменениям вокруг, и к трендам как техническим так и организационным, которые я упоминал в комментарии выше.
Lankhorst (один из ключевых разработчиков Архимейта) писал что в Архимейт с самого начала закладывались идеи networked enterprise, поэтому для второй и третьей школы нужны скорее новые вьюпоинты, а не совершенно новые концепты (хотя они и появляются в каждой новой версии языка). Т.е. моделирование ЕА в этих школах надо будет начинать с business network, а не с одного конкретного предприятия. По аналогии со стейкхолдерами, у каждого предприятия в сети будут свои роли. Межорганизационная кооперация также связывается с конкретными орг.процессами участвующих организаций, а также с ИТ сиситемами, стандартами, ограничениями и тп которые поддерживают эти орг.процессы.


Выгоды на уровне управления ИТ активами хорошо описал Гербен Вирда в ролике:



Я раскрою тему улучшения коммуникации при стратегических изменениях. Среднее и крупное предприятие - это система систем, в нем не может быть одного человека, который бы скомандовал и мог скоординировать переход. Все равно придется что-то делегировать и поручать другим людям, у которых свои цели и своя повестка. Во время организационных изменений текущие соглашения по взаимодействию пересматриваются и без централизованного разрешения конфликтов дело не двигается. Без модели архитектуры предприятия разрешение таких конфликтов чаще всего производится первым лицом, у него образуется очередь, которая медленно двигается. Первое лицо становится узким местом процесса трансформации. Модель архитектуры предприятия нужна для того, чтобы первое лицо передало свои ключевые знания по тому, как работает организация, какие взаимосвязи в работе организации критичны и что нужно учитывать. Такая модель позволяет менеджерам предсказывать реакцию первого лица на предложения и лучше готовиться к встречам. Сами встречи протекают быстрее, т.к. первому лицу не надо излагать все аспекты своего видения, все эти важные подробности представлены на модели.
Таким образом, модель архитектуры предприятия не нужна рядовым исполнителям, и в этом ее ключевое отличие от классической триады модель бизнес-процессов + органиграмма + ИТ-ландшафт, она нужна для того, чтобы у топ-менеджмента и ключевых руководителей среднего, которые отвечают за реализацию стратегии предприятия, было общее понимание самого важного, что есть в устройстве организации. В этом плане показательно выступление Мартина Фаулера:



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

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



Итого:
1) Модель архитектуры предприятия нужна для устойчивой трансляции стратегии и видения первого лица до уровня руководителей, которые отвечают за исполнение стратегии.
2) Она задает общий язык и общие объекты внимания команды и говорит, что в организации важно, а что нет.
3) Она указывает на ключевые взаимосвязи и инварианты организации, не опускаясь до до подробностей реализации, которые ведутся в классических инструментах: органиграмма, модели бизнес-процессов и ИТ-ландшафт.
Распределенное лидерство и архитектура предприятия.



пятница, 7 сентября 2018 г.

Конспект ISO/IEC 29110: Systems and Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs)

Польза применения ISO29110
- Согласованный набор проектных требований (техническая часть договора), согласованных с Приобретающей стороной
- Последовательный процесс управления, который обеспечивает прозрачность проекта и своевременные корректирующие действия
- Систематичное определение и воплощение продукта, отвечающего нуждам Приобретающей стороны

Назначение процесса управления проектом
Результат 1. План проекта, описание содержания и обязательства тщательно рассмотрены и приняты как Приобретающей стороной, так и руководителем проекта. Есть оценка задач и необходимых для их выполнения ресурсов.
Результат 2. Идет наблюдение за ходом проекта и его сравнение с планом проекта, результаты наблюдения записываются в отчет о ходе реализации. Если отклонения от планов проекта не позволяют достичь проектных целей, то предпринимаются корректирующие действия. Предпринимается закрытие проекта для получения задокументированной приемки продукта проекта Приобретающей стороной.
Результат 3. Принимаются и обрабатываются запросы на изменения. Команда проекта оценивает влияние от запрошенных изменений системных требований на стоимость, сроки, риски и технические решения.
Результат 4. Проводится защита результатов проекта с участием рабочей группы, приобретающей стороны и поставщиков. Соглашения записываются и их выполнение отслеживается.
Результат 6. Разработана стратегия управления продуктом. Определены элементы, составляющие продукт, для них задан базис. Изменения и выпуск этих элементов контролируются и доводятся до приобретающей стороны и рабочей группы. Контролируется хранение, передача и поставка этих элементов.
Результат 7. Для проекта обеспечивается качество. Рабочие продукты и процессы соответствуют плану проекта и спецификациям системных требований.
Результат 8. Разработан подход к снятию системы с эксплуатации.

Назначение процесса определения и воплощения системы
Результат 1. Выполняются задачи мероприятий текущего плана проекта.
Результат 2. Определены системные требования, они проверены на корректность и тестируемость, одобрены приобретающей стороной, внесены в базис и доведены до всех заинтересованных сторон.
Результат 3. Разработаны и внесены в базис архитектурные решения системы. Они описывают системные элементы, а также внешние и внутренние интерфейсы к ним. Установлена прослеживаемость между требованиями и архитектурными решениями.
Результат 4. Определенные системным дизайном системные элементы произведены или приобретены. Определены и проведены приемочные тесты, чтобы проверить преемственность и последовательность требований и дизайна. Установлена прослеживаемость системных элементов к требованиям и архитектурным решениям.
Результат 5. Системные элементы собраны, интегрированы. Исправлены дефекты сборки, последовательность и прослеживаемость сборки к системной архитектуре установлена и подтверждена.
Результат 6. Системная конфигурация, как она согласована в плане проекта, включая инженерные артефакты, собрана, внесена в базис и сохранена в репозитории проекта. Выявляется потребность в изменениях продукта и запускаются соответствующие изменения.
Результат 7. Исполняются задачи проверки и приемки всех необходимых рабочих продуктов с использованием заранее определенных критериев для достижения согласованности между продуктами на входе и выходе всех мероприятий. Выявляются и исправляются дефекты, записи сохраняются в отчетах о проверке и приемке.
Связь управления жизненного цикла и системной инженерии:

четверг, 6 сентября 2018 г.

Шаблоны успеха в системной инженерии

Конспект
Задачей этой работы было определить шаблоны успешного исопльзования системной инженерии в ИТ-проектах со значительной программной составляющей. Шаблоны выявлялись методом положительных отклонений от принятых способов работы.
Вначале мы определили 30 госпрограмм, каждая из которых была успешна. Из этих 30 мы отобрали 12 для последующего изучения. Мы провели интервью с непосредственными участниками программ, у которых были полномочия положительно влиять на принятые способы работы.
Отчет описывает два больших шаблона успешного поведения. Каждый шаблон в свою очередь состоит из шаблонов поменьше. "Балансирование сети поставок" описывает социальные зависимости между стейкхолдерами предприятия. У этих стейкхолдеров есть различные интересы в конечном результате программы.
Шаблон "Укрощение технической сложности" описывает технические зависимости между элементами системы. Эти элементы все вместе и дают желаемый эффект программы для всего предприятия в целом.
Эти два шаблона как две стороны монеты. Те программы, которые мы исследовали, стали успешными потому что их руководство умело лавировало между этих двух групп зависимостей.

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

Метод положительных отклонений описан Гаванде в его книге Better 2007 by Gawande.

Разработчики AT&L System of Systems Engineering Guide использовали метод положительных отклонений, когда писали свое руководство.

Метод шаблонов (patterns) разрабатывал архитектор Кристофер Александер. Он опубликовал его в книге The Timeless Way of Building, Oxford U. Press 1979.

Шаблон состоит из трех частей:
1) Контекст. Определяет ту большую систему, частью которой является ваша целевая. Она накладывает ограничения на возможные архитектурные решения.
2) Действующие силы. Выражает отношения между элементами в заданном контексте.
3) Решение. Представляет дизайн или конфигурацию элементов, которая успешно использует действующие силы.

Шаблоны предлагают только принципиальные, архитектурные решения. Шаблоны основаны на практиках.

Формат описания шаблона:
Краткое описание.
Контекст.
Проблема.
Рисунок.
Силы.
Решение.
Примеры.
Результат или итоговый контекст.
Ссылки.

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

Понятие успеха в госпрограммах
Стейкхолдеры систем, которые приобретаются в госпрограммах ищут способы получения практической ценности для пользователей систем. Кроме того, они ожидают, что системы будут поставлены в срок и будут отвечать требованиям регулятора, надзирающего за этой системой и смежными системами.
Мы намеренно оставили определение успешности системы на усмотрение тех, кто давал нам интервью.
Мы определяли сложность по 8 критериям:
- окружение миссии
- объем работ
- масштаб работ
- окружение госзакупки
- вовлеченность стейкхолдеров
- отношения между стейкхолдерами
- желаемые результаты
- поведение системы

Мы провели краткие интервью с руководством успешных программ, обработали результаты и обсудили их с руководством программ еще раз. Итогом нашей работы стали 12 шаблонов.
Эти шаблоны не "серебрянные пули" и мы видели, что большинство из них применялись в каждой программе. Эти шаблоны дополняют друг друга и работают совместно.

"Балансирование сети поставок"
Краткое описание. 
Балансирует взаимодействие между стейкхолдерами в сложных программах по разработке и госзакупке.
Контекст.
- Сеть поставок вместо цепи поставок.
- Деньги текут от Конгресса и дотекают до подрядчиков.
- Регулирование и стандарты идут от госорганов.
- Оргвозможность появляется не от одиночной целевой системы, которую вы делаете, а от множества систем, которые находятся под контролем различных организаций.
Проблема.
- Надо иметь сбалансированную стратегию, чтобы удовлетворить правомочные потребности стейкхолдеров.
- Нужно справляться с множественными потребностями в условиях ограниченных ресурсов.
Рисунок.

Силы.
- Противоречивые определения успеха у конкурирующих стейкхолдеров
- Стейкхолдеры используют свои ресурсы и влияние в конкуренции
- Конечные ресурсы проектного офиса
- Текущие практики госзакупок ориентированы на цепочки поставок
Решение.
- Моделировать и отслеивать сеть стейкхолдеров и их взаимодействие в течении всей программы
- Применять ограниченные ресурсы программы крайне аккуратно, чтобы постоянно балансировать потребности стейкхолдеров
- Использовать ресурсы одних стейкхолдеров для удовлетворения потребностей других
- Разруливать контекст госзакупки параллельно с разработкой системы
Результат или итоговый контекст.
- Система привела к появлению оргвозможности у приобретающей стороны в сбалансированной сети поставок
- Создали операционную оргвозможность и изменили контекст предприятия

"Укрощение технической сложности"
Краткое описание.
Упрощает техническое взаимодействие между взаимодействующими системами в цепочке производственной кооперации.
- N-уровневая архитектура является ключевой системной моделью
- Инновации начинаются внутри уровней
- Интеграция обеспечивается стандартными интерфейсами между уровнями
Проблема.
- Проектный офис должен создать новую оргвозможность, встроенную в уже существующие ИТ-системы предприятия
- Не все программы согласны с определением слоев и протоколов интерфейсов между слоями
- Финансирование и руководство программами ориентировано на едининые программы, а не улучшение всего ИТ-ландшафта и системного окружения.
Рисунок.

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

среда, 29 августа 2018 г.

Онтология мышления о рисках

Мир есть совокупность фактов, а не совокупность вещей.
Виттгенштейн
Риском сейчас называют все, что угодно. И с этим надо что-то делать.
Павел Алферов

Представим ось времени и события на этой оси.
События могут иметь причинно-следственную связь, и могут быть независимыми. Есть ли связь между событиями или нет, определяется людьми субъективно. Например, я видел, как пьяный водитель врезался в столб. Потом он вылез из машины и стал обвинять строителей, что они неправильно поставили этот столб. В голове водителя событие установки столба в конкретно этом месте и его авария связаны, хотя для меня никакой связи между ними нет. Иногда люди вообще не признают, что какое-то событие произошло. Например, я видел, как ребенок украл конфетку со стола и потом отрицал, что он это сделал. И мама ребенка и я видели кражу. Поэтому при обсуждении совместных действий нужно различать события и факты. Если представить себе пространство-время как 4Д объект, то событие - это срез 4Д объекта. Событие - это конкретное состояние куска мира в какой-то момент времени. События межсубъектны, разные люди могут их увидеть и почувствовать. Если человек признает, что какое-то событие есть, то событие для данного человека становится фактом. Факты субъективны.
Набор фактов и их связь между собой - это логика данного человека, то, как он видит мир. На картинке событие одно, но разные люди видят разные факты. Договариваться надо по поводу событий, указывать на конкретную часть мира, потому что факты все воспринимают по-разному. Связь фактов между собой тоже субъективна. Мы можем признавать чужие факты и связь между ними, а можем не признавать. Координация людей и организация совместной деятельности подразумевает, что мы признаем факты и связи, которые нам говорят другие. Например, если врач говорит нам, что нужно изменить режим, чтобы меньше болеть, мы можем поверить ему. Если мы верим, то признаем связь между событиями “начать есть меньше сладкого и не курить” и “чувствовать себя лучше”. Но мы можем и не поверить, и тогда координации между врачом и пациентом не получится.

Доверие и признание чужих фактов - это основа совместной работы людей.

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

С помощью концептов мы обобщаем опыт и получаем знания.

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

Для целей этой статьи важно то, что никакой человек не может обладать полной картиной мира, все видят мир по своему.

Чтобы объединить различные точки зрения, нужно указать на событие, и попросить стейкхолдеров предоставить факты по этому событию. Так как событие межсубъектное, и существует независимо от точек зрения стейкхолдеров, то объединение возможно.
Для такого объединения нужно, чтобы оба человека признавали событие Б2. Тогда они могут сказать, чтобы оба факта правдивы. Если вы признаете чужие факты, то можете использовать планы других людей для координации своих действий с их действиями.

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

И тогда ясно, что любое планирование вероятностное, всегда есть диапазон фактов возможных миров.

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

Неопределенность в планировании и обещаниях людей неустранима.

Когда вы планируете и общаетесь по поводу общих действий, то вам нужно держать в голове три мира.
Объективный, или точнее, межсубъектный мир. Мир событий, вещей и 4Д-индивидов, законов природы. Вы можете констатировать, что какое-то событие было. При этом для успешной координации надо, чтобы вы говорили правду. Правда - это то, что событие было или не было.
Социальный мир, мир правил, договоренностей, человеческих законов. Вы должны взаимодействовать по правилам - писанным и неписанным. Люди хотят, чтобы такое взаимодействие было справедливым, т.е., правилам подчинялись все без исключения, и правила применялись последовательно и постоянно.
Мир субъективный, внутренний мир человека. Констатация событий может быть правдивой или нет, а вот факты можно выражать честно либо нечестно. Другими словами, мы не можем проверить правдивость фактов, это “человек так видит”. Но мы можем потребовать, чтобы он выражал факты честно, говорил как думает.
  • Когда мы говорим по поводу объективного мира, мы задаем вопросы либо делаем утверждения.
  • Когда мы обсуждаем социальный мир, то мы запрашиваем либо обещаем.
  • Когда речь идет о субъективном мире, то мы просим либо извиняемся.


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

Например, если нам нужно подготовить план проекта, в котором есть программисты, постановщики задачи, тестировщики, финансисты и продажники, то нам нужно объединить 5 онтологий. Итоговый план проекта должен без особых ошибок отражать точку зрения каждой роли в деятельности, иначе план будет неадекватен и команда перестанет его использовать. И здесь возникает куча проблем.

Планирование задействует микротеорию, см., например, Джоеля Спольски. Другими словами, нельзя распланировать разработку программы одной строчкой “Разработка модуля загрузки 1,5 недели”. Если вы видите такой план, он не адекватен и не будет использоваться. Адекватный план может содержать задачи “Придумать алгоритм загрузки 2 часа”, “Придумать структуру хранения данных 1,5 часа”, “Придумать структуру интерфейса 1 час” и т.п. 

Программист много раз делал подобные задачи и он хорошо понимает, сколько времени она может занять и какие проблемы могут возникнуть. 

Если вы просуммируете получившиеся оценки “снизу”, то она будет отличаться в несколько раз от верхнеуровневой оценки 1,5 недели на разработку модуля. И это отличие может быть как в плюс, так и в минус. Поэтому если вы хотите получить адекватные и проверяемые планы, то надо явно описывать или проговаривать онтологии и микротеории по всем работам. В таком виде достоверность оценок сроков и стоимости можно проверить на качество. 
Но планы зачастую директивны, их выдает начальник, у которого нет в голове всех необходимых микротеорий. У него нет всех необходимых фактов, он не знает обстановку “на земле”. У него недостаточно времени для точного расчета по микротеории и не опыта применения микротеории, который приходит только с практикой. Все это осложняется еще и тем, что знания вероятностны, и отнести данную ситуацию к той или иной микротеории можно только с какой-то степенью уверенности. А применение микротеории за пределами границ ее применимости резко снижает полезность предсказаний.

Поэтому начальники часто дают обещания, которые не могут исполнить. От этого страдает вся команда, потому что в попытках исполнить обещанное начальники часто расходуют ресурсы команды сверх разумного предела. И тогда команда входит в зону неэффективности.

Подводя итог, всегда существует неопределенность:

  • событий
  • фактов
  • микротеорий
  • отнесения ситуаций к классам и выбора подходящей микротеории


И это осложнено ограниченностью вычислительных ресурсов. 

Поэтому когда руководитель входит в уже запущенный проект, у него есть два решения:

Дьюдил проверки направлены на поиск событий, последствия которых нежелательны.
После того, как у руководителя есть события, он уточняет модели планирования и прогнозы.
Дюьдил “приземляет” его модели ближе к межсубъектной реальности, прогнозирование на основании уточненных моделей дает ему больше уверенности в выбранном курсе действий. Современные модели, например, прикладной информационной экономики, и актуарной оценки рисков с денежным выражением неопределенности позволяют руководителям принимать более рациональные решения.
Это нужно для повышения вероятности успеха системы и успеха проекта по ее созданию. Если перефразировать успех системы и успех проекта в терминах этой статьи, то можно сказать, что:

Факты возможных миров влияют на успешность исполнения обещаний и реализацию потребностей.
Риски = факты возможных миров.

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

Другими словами, надо переходить к

Моделеориентированным практикам “управления рисками”:
  • Найти максимальное количество стейкхолдеров.
  • Определить совместно с ними границы целевой системы.
  • Определить модель жизненного цикла и практики жизненного цикла.
  • На основании концептов дисциплин практик выделить объекты деятельности в домене проекта.
  • Для каждого объекта деятельности определить возможные состояния. Эти возможные состояния будут возможными событиями.
  • Попросить стейкхолдеров проинтерпретировать возможные события и составить список фактов возможных миров.
  • Провести дьюдил домена проекта.
  • Отслеживать выявление фактов возможных миров в социальном мире и субъективном мире. Это и есть триггеры риска из классических методов.
  • Предсказывать с помощью микротеорий факты возможных миров на основании триггеров, уточнять прогнозы.

[1] http://b-ok.xyz/book/459938/bdd7d5