среда, 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


вторник, 28 августа 2018 г.

Онтология орг.изменения (неактуальная версия)

Текст потерял актуальность на 03 сентября 2018.

Текст в табличном виде в PDF по этой ссылке.

Организация
Русские синонимы
Предприятие, проект, отдел, подразделение, орган (власти, законодательный, регулирующий)
Английские термины
Organization, enterprise, endeavor, department, organizational unit
Определение
Совокупность людей и технических средств, наделенная ответственностью, полномочиями, с взаимоотношениями внутри
ТКП
Правительство РФ, отдел закупок Газпромнефти, ИП Романов
Виды моделей
Устав организации, модель бизнес-процесса

Цепочка производственной кооперации
Русские синонимы
Цепочка/сеть пользы, производственная цепочка, кооперация, расширенное предприятие, партнерство, мегапроект
Английские термины
Value chain/network, cooperation, supply chain
Определение
Действия, с помощью которых компании добавляют пользу либо создают ценность продукта или услуги
ТКП
Открытый софт Apple - AppStore - приложения
Виды моделей
wardley map, value chain, life cycle model

Возможность со стороны цепочки производственной кооперации
Русские синонимы
Рыночная возможность, удачный момент, “тема”
Английские термины
Opportunity, moment, gig
Определение
Требование со стороны участников цепочки производственной кооперации по выполнению действий в цепочке по заданным условиям
ТКП
Тендер на закупку, рыночный спрос на товар или услугу, жесткие контрактные условия 
Виды моделей
Заявка на закупку, отчет по исследованию рынка, отчет о перспективной технологии

Позиция, положение
Русские синонимы
Позиционирование относительно конкурентов, рыночное положение, относительная сила
Английские термины
Position, market situation
Определение
Взаимодействие и реакция организации по отношению к своему окружению в цепочке производственной кооперации
ТКП
Рыночная позиция российских нефтяников по отношению к американским потребителям слабая, позиции ипотечных банков ослабли, дискаунтеры завоевывают российские рынки
Виды моделей
wardley maps, отчеты о технологических и рыночных тенденциях

Стейкхолдеры организации
Русские синонимы
Собственники, бенефициары, владельцы, интересанты, предприниматели, акционеры
Английские термины
Owners, entrepreneurs, founders, shareholders
Определение
Люди, заинтересованные в деятельности организации, с возможностью влиять на их работу
ТКП
Основатель фирмы, акционер с контрольным пакетом, владелец оффшора, на который записана компания
Виды моделей
Устав организации, реестр акционеров, реестр стейкхолдеров

Корпоративное управление
Русские синонимы
Поднадзорность, подконтрольность
Английские термины
Governance
Определение
Комплекс средств и мер по тому, чтобы ресурсы организации использовались в соответствии с требованиями стейкхолдеров организации и архитектурой организации
ТКП
Корпоративное управление Газпромнефти, аудит бизнес-процессов, процедура прохождения контрольной точки (gate review)
Виды моделей
Процедуры корпоративного управления, чек-листы контрольных точек, архитектурные модели

Стратегия организации
Русские синонимы
План развития, конкурентное положение, принципы организации
Английские термины
Strategy, plan, pattern, position, perspective
Определение
Самые главные и определяющие требования к организации, ее внешнее поведение
ТКП
План экспансии в регионе, видение и ценности организации, годовой бюджет организации
Виды моделей
Видение, миссия, стратегический план

Архитектура предприятия
Русские синонимы
Бизнес-модель, ИТ-ландшафт, ландшафт бизнес-процессов
Английские термины
Enterprise architecture
Определение
Самое важное в устройстве организации, что бы это ни было
ТКП
Структура подразделений и разбиение ответственности, схема автоматизации процессов, структура и наполнение базы данных ERP
Виды моделей
Базы данных организации, организационные структуры, схемы взаимодействия подразделений и бизнес-функций

Организационное изменение
Русские синонимы
Шаг развития или совершенствования, оптимизация, автоматизация, диджитализация
Английские термины
Organizational change, automatization, digitalization
Определение
Изменение дисциплины либо рабочих продуктов технологии практики
ТКП
Сокращение численности с совмещением должностей и функций, внедрение ERP, введение дополнительного контура управленческого контроля - согласования, визы, аудиты, одобрения
Виды моделей
Планы проектов, стратегия автоматизации, планы перераспределения обязанностей, шаблоны документов

Организованная деятельность
Русские синонимы
Человеческая деятельность, человеческий труд, организованный труд
Английские термины
Organized activity, organized work
Определение
Деятельность людей, объединенных в одно предприятие, подчиняющихся правилам и нормам этого предприятия и выполняющих заданную им совместную работу в соответствии с экономическими, технологическими, правовыми, организационными и корпоративными требованиями. При этом правила, нормы и требования предприятия предполагают и порождают особые психологические отношения между людьми, которые существуют только на предприятии, - это управленческие отношения людей.
ТКП
Строительство дома, учеба в классе, производство программного продукта
Виды моделей
План производства работ, схема подчиненности, список задач, протокол собрания

Способность организации
Русские синонимы
Возможность, компетенция, квалификация, экспертиза
Английские термины
Capability
Определение
Способность организации выполнять задачи с определенным уровнем качества при определенных условиях
ТКП
Управление ИТ-проектами, видеонаблюдение в сети магазинов, клиентская аналитика
Виды моделей
Описание способности организации по форме, квалификационные требования, SLA

Архитектура способности организации
Русские синонимы
Ключевые компетенции, ноу-хау, пул экспертов
Английские термины
Capability architecture
Определение
Самое важное, что есть в данной организационной способности, что бы это ни было
ТКП
Скоростная оптическая магистраль, известная и привлекательная торговая марка, сверхнадежная и сверхустойчивая конструкция
Виды моделей
Патенты и полезные модели, заделы и опыт, архитектурные описания

Практика
Русские синонимы
Функция, направление, специальность, предметная область
Английские термины
Practice, business function, process
Определение
Приёмы, навыки, обычные способы какой-нибудь работы
ТКП
Терапия, продажа розничных товаров, программирование микроконтроллеров
Виды моделей
Своды знаний, учебники, курсы и тренинги

Жизненный цикл системы
Русские синонимы
Модель стадий, этапы
Английские термины
systems life cycle
Определение
Деятельность всех обеспечивающих систем, ведущих целевую систему от её замысла до вывода из эксплуатации. Обычно эта деятельность разбита на стадии. Стадии могут быть не только последовательными, но и перекрываться во времени друг с другом.
ТКП
Жизненный цикл дома, жизненный цикл ИТ-системы, жизненный цикл самолета
Виды моделей
Модели жизненного цикла - организационный контекст, КонИсп, эксплуатационный контекст, системный контекст

Команда
Русские синонимы
Коллектив, рабочий коллектив, рабочая группа
Английские термины
team, work group, virtual team, distributed team
Определение
Группа людей с взаимно дополняющими навыками, достаточными для того, чтобы выполнить задачу, работу либо проект. Члены команды зависят друг от друга, разделяют ответственность за управление собой и обладают полномочиями, ответственны за эффективность общей работы, работают в направлении общей цели и разделяемой награды. Группа превращается в команду, у нее появляется эмерджентность и характеристики, которых нет у каждого члена команды по отдельности.
ТКП
Команда ЧГК Друзя, футбольная команда, команда программистов Фейсбук
Виды моделей
Terms of reference, устав команды

Начальник
Русские синонимы
Руководитель, заведующий, босс, тимлид, директор
Английские термины
Manager, leader, boss
Определение
Должностное лицо, руководящее, заведующее чем-нибудь
ТКП
Начальник отдела разработки, начальник склада, руководитель проекта
Виды моделей
Органиграмма, должностная инструкция, приказ о назначении

Точка операционного взаимодействия
Русские синонимы
Бизнес-интерфейс, договоренность между отделами, соглашение, порядок работы, порядок взаимодействия
Английские термины
Business interface, operational level agreement
Определение
Описание ответственности различных групп и команд за результативное взаимодействие при выполнении какой-либо практики либо при реализации способности организации
ТКП
Межфункциональные группы и собрания, процедура подачи отчетов за командировочные, взаимодействие отделов при бюджетировании
Виды моделей
Спецификация OLA, процедура взаимодействия отделов, workflow в трекере или ERP

Объект деятельности
Русские синонимы
Объект предметной области
Английские термины
Business object
Определение
Вещь или концепт, который выделяется в практике, элемент онтологии предметной области
ТКП
Пакет работ, критический путь, бюджет проекта
Виды моделей
Определение, описание

Задача
Русские синонимы
Цель, стратегическая задача, КПЭ, проект
Английские термины
Task, objective, goal, KPI
Определение
Действия с предопределенным результатом с ограничениями, за выполнение которых отвечает конкретный человек или команда
ТКП
Отделу продаж реализовать 1320 единиц продукции с целевой маржинальностью до конца месяца
Завершить проект в запланированный срок. Отв. Руководитель проекта
В течении 3 дней после окончания командировки подать авансовый отчет в бухгалтерию
Виды моделей
Список задач, план проекта, база данных трекера, протоколы

Система
Русские синонимы
Продукт, продукция
Английские термины
System, product
Определение
Набор системных элементов и отношений между ними. Всегда имеет воплощение, физичность, можно постучать. У системы есть функция, которую определяют ее стейкхолдеры. “Система в глазах смотрящего”.
ТКП
Вот этот компьютер или телефон, вот эта организация, вот этот человек
Виды моделей
Модели жизненного цикла

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

Ответственность за действие
Русские синонимы
Компетенция, обязанность, вменяемость, надежность
Английские термины
Responsibility
Определение
Необходимость, обязанность отвечать за свои действия и поступки перед начальником
ТКП
Ответственный за исполнение приказа Иванов А.М., врач Петров Д.А., со стороны исполнителя подписал Сидоров М.Ю.
Виды моделей
Приказы, договора, наряды на работы

Роль в деятельности
Русские синонимы
Функционал должности, обязанности, ответственность за направления, бизнес-роль
Английские термины
Business role
Определение
Ответственность за культурно-обусловленное, выученное поведение, необходимое для качественного исполнения практики
ТКП
Врач-терапевт, чиновник МФЦ, руководитель проекта с сертификацией РМР
Виды моделей
Должностная инструкция, свод знаний, учебник, методичка, курс, тренинг

Интерес/озабоченность
Русские синонимы
Тема, область интересов, вопрос
Английские термины
Interest, concern
Определение
Тема, к которой стейкхолдер задает вопросы, которая его интересует
ТКП
Реализуемость конкретного технического решения в данной ситуации, сроки сдачи дома, устойчивость двери к взлому
Виды моделей
Модель целеполагания стейкхолдера

Актер
Русские синонимы
Ответственный, актор, агент, “с кого спрашивать будем”, “кто сидеть будет”
Английские термины
Business actor, agent
Определение
Человек или команда, которые дают обещания и несут по ним ответственность
ТКП
Начальник отдела разработки ПО, я сам, обещающий себе же не есть после 6, папа, обещающий маме забрать ребенка из садика
Виды моделей
Описания обещаний и ответственности, договора, SLA

Обязательства
Русские синонимы
Личная ответственность
Английские термины
Accountability, promise
Определение
Обещание выполнить задачу и предоставить затребованный результат в рамках ограничений, “хороша ложка к обеду”
ТКП
Сдам к вечеру; французский батон, пожалуйста; обычно ты забираешь документы с почты, надо было предупредить
Виды моделей
Договоренности, обещания

Схема взаимодействия
Русские синонимы
трансакция ДЕМО, порядок достижения договоренностей
Английские термины
DEMO transaction
Определение
Общая последовательность действий, по которой актеры дают и принимают исполнение обещаний
ТКП
Мы так и не договорились, их не устроило мое предложение; они акцептовали нашу оферту; перенесите сроки сдачи сайта, если можно, нам нужно внести запрошенные изменения
Виды моделей
Переписка, переговоры

Результат
Русские синонимы
Итог, продукт, выход, выхлоп, исход, достижение 
Английские термины
result, output
Определение
Что получилось по завершении какого-либо действия, задачи или выполнения практики
ТКП
Автомобиль, отчет о ходе проекта, вывод о целесообразности дальнейшей работы
Виды моделей
Отчет о проделанной работе

Условия актуальности
Русские синонимы
В рамках, при условии, до ...
Английские термины
DEMO agendum, restrictions, agenda
Определение
Ограничения по срокам и другим условиям предоставления результата актером. Результат будет востребован и принят, если он предоставлен в соответствии с условиями актуальности, иначе затребовавший результат актер может отменить приемку или запрос.
ТКП
Уже не актуально; что же вы не сказали, что надо было вчера; совещание завтра в 11, до 10 должно быть
Виды моделей
Поставленная задача

четверг, 16 августа 2018 г.

Чек-листы и онтологика

Чек-листы используются для сверки целевой и обеспечивающей системы против определения системы. Для этого и нужна вся команда при их прогоне, а не просто аналитик, который к каждому пункту прикрепит выгрузку из PLM.
Поэтому все пункты чек-листа делятся на:
1) Дисциплинарные. Проверка причинного вывода по основным дисциплинам. Должны быть предоставлены свидетельства, которые по микротеории дисциплины сдвигают оценку вероятности успешности _проекта_. Например "Архитектурные требования выделены и запланирована их проверка", "Скорость при посадке больше 200 узлов".
2) Технологические. Проверка готовности технологий к использованию. Должны быть предоставлены свидетельства того, что технология способна реализовать практику жизненного цикла. Например, "производственная линия выпускает продукцию по спецификациям с выходом годных 99.5% на пиковом времени такта в течение минимум трех производственных смен".
3) Архитектурные. Проверка правильности реализации архитектуры. Должны быть предоставлены свидетельства того, что архитектура системы соответствует определению архитектуры. Например, "команда согласна, что продукт реализован в соответствии с замыслом".
4) Надежности человека. Проверка минимум на skills based/rules based/knowledge based ошибки в ходе работ. Например, "аудит безопасности не выявил критических нарушений в технике безопасности на производственной линии, процесс обеспечения безопасности постоянно улучшается".


Например:
Запуск проекта
  1. Команда запуска проекта сформирована, как минимум из представителей научно-исследовательского отдела, профильных разработчиков по специальностям, проектного офиса, отдела системной инженерии, финансового аналитика, маркетолога.
  2. В команде запуска назначены руководитель программы и главный конструктор/системный инженер, это должны быть разные люди.
  3. Все участники команды запуска получают резервирование 20-40-60-80-100% в системе управления проектными ресурсами на время запуска и обязаны еженедельно списывать зарезервированное рабочее время на задачи проекта. Руководитель программы одобряет и закрывает отчеты команды запуска.
  4. Системный архитектор и инженер по требованиям разрабатывают концепцию эксплуатации и высокоуровневую архитектуру системы и защищают ее перед рабочей группой. Рабочая группа оценивает способность предлагаемых архитектур решить поставленные задачи.
  5. Проводится анализ аналогичных проектов в базе проектов, с упором на интеграцию и платформенную разработку. Из базы проектов берутся шаблоны ИСР системы, работ по интеграции, расписания, установочные документы по аналогичным проектам, оценки трудозатрат и стоимости и закрывающие отчеты по ранее выполненным проектам.
  6. Команда запуска определяет модель жизненного цикла и готовит верхнеуровневую оценку стоимости жизненного цикла системы. Главный конструктор и руководитель программы защищают эту оценку у генерального директора и готовят предварительное технико-экономическое обоснование разработки.
  7. Команда запуска определяет модель жизненного цикла проекта и вносит его в систему управления проектами.
  8. Разрабатываются альтернативные концепции системы, минимум три варианта. Проводится анализ альтернатив, эти концепции сравниваются по возможным техническим характеристикам, стоимости жизненного цикла.
  9. Главный конструктор собирает совещание команды запуска и собирает предположения по физическому и оперативному окружению системы.
  10. Рабочая группа определяет функциональные характеристики системы, которые помогают ей эффективно работать в этом окружении.
  11. Главный конструктор при общении с заказчиком выявляет сложности и препятствия работе системы в месте предполагаемой обстановки, при необходимости выезжает в составе группы обследования объектов и обследует местность. Руководитель программы по результатам обследования обновляет план управления рисками.
  12. Анализ альтернатив оформляется документально и вносится на рассмотрение группе запуска. Группа запуска изучает результаты изучения альтернатив и дает рекомендации по исправлению. После согласования с группой запуска результаты изучения альтернативных концепций системы вносится спонсору проекта и главный конструктор и руководитель программы защищают рекомендованный вариант.
  13. Анализ альтернатив дает информацию для составления расписания программы, оценки ее стоимости. Профильные специалисты проводят предварительную оценку стоимости и сроков реализации элементов системы, передают эти оценки руководителю проекта, который готовит постепенно уточняющееся расписание и бюджет проекта.
  14. Маркетологи проводят сегментацию рынка и определяют потенциальные ниши, в которых можно продавать продукт после первой пробной установки у заказчика. Рассчитывают емкость рыночных сегментов, готовят различные сценарии продаж и продвижения, задают ограничения на предельную себестоимость разработки и единичного экземпляра системы. Берут у группы запуска результаты расчета полной стоимости владения и готовят финальное предложение по анализу рынка. Оформляют результаты анализа рынка документально и защищают его у генерального директора.
  15. Руководитель программы объединяет документы с расчетом стоимости жизненного цикла системы с анализом рынка, проверяет, что анализ рынка учитывает необходимость поддерживать заменяемые элементы системы, уточняет у заказчика текущие методики измерения эффективности системы, и узнает текущие методики оценки эффективности аналогичных систем. Собирает совещание по началу разработки технико-экономического обоснования. Вносит документы по анализу рынка в систему управления проектами, далее при продажах системы будет проводиться сравнение результатов анализа с фактическими продажами.
  16. Руководитель программы и главный конструктор готовят предварительное описание этапов и стадий разработки системы, порядка разработки ее функциональности. Определяют количество экспериментальных и опытных образцов, которые можно построить в рамках программы. Уточняют критические характеристики этих образцов у Заказчика, которые необходимы для приемки и испытания.
  17. Руководитель программы готовит план по управлению рисками с участием представителей Заказчика и поставщиков компонентов системы.
  18. Главный конструктор проверяет результаты анализа рынка и говорит, учитывает ли проведенный анализ появление новых технологий и решений за время разработки программы. Получившиеся результаты руководитель программы учитывает в плане управления программой.
  19. Разработчики ПО разрабатывают показатели надежности программного обеспечения системы.
  20. Системный архитектор определяет режимы работы и системное окружение системы во время производства, функционирования и технической поддержки.
  21. Главный конструктор проводит серию совещаний с производственным подразделением и руководителями отделов разработки, на которых выявляет ограничения по инженерным и производственным мощностям. Руководитель программы учитывает составленный список ограничений по производству и разработке в плане программы.
  22. Главный конструктор уточняет у инженера по требованиям, какими методами он пользуется при подготовке требований к системы и дает рекомендации по изменению процесса сбора и анализа требований.
  23. Инженер по требованиям проводит интервью у разработчиков ПО и собирает требования к тестированию программного обеспечения, передает их руководителю программы, который учитывает их в плане программы.
  24. Главный конструктор и руководитель программы собирают архитектурные описания и документацию по требованиям и проверяют, что они не противоречат друг другу, проработаны на одинаковом уровне и обсуждены в достаточной мере для этой стадии.
  25. Главный конструктор проверяет, что нефункциональные требования зафиксированы.

Разработка концепции и планирование
  1. На базе собранной информации составляется расписание работ, которое отражает техническую сложность рекомендованного решения, объем НИР и ресурсы, необходимые для проведения НИОКР. Формирует запросы на выделение ресурсов, получает предварительные одобрения, закладывает оценку стоимости ресурсов в проектные планы.
  2. Руководитель программы готовит документ с описанием потребности в финансировании и поддерживает его в актуальном состоянии, регулярно обсуждает его с планово-экономическим отделом и главным бухгалтером. В случае серьезных изменений обсуждает его в генеральным директором. Проверяет потребности финансирования и расписание программы, чтобы они не расходились.
  3. Во время анализа альтернатив руководитель программы оценивает различные варианты исполнения работ с участием разных подрядчиков, планирует стоимость командировок команды программы и ее обучения работе с системы. Согласует эти планы по персоналу с начальником отдела кадров и генеральным директором по необходимым компетенциям и планам развития, вносит назначения на проект в личные дела сотрудников. Готовит пояснения по тому, какая квалификация персонала нужна, какие обязанности они будут исполнять и какая у них будет ответственность. Готовит документ “Организационная структура проекта” и согласует его у начальника отдела кадров и генерального директора, доводит его до группы запуска и назначенных сотрудников.
  4. Главный конструктор совместно с руководителем проекта оценивает технические риски, связанные с требуемыми характеристиками системы, готовностью технологий, стоимостью, сроками, имеющимися ресурсами, учитывает их в плане управления рисками.
  5. Руководитель программы оценивает влияние рисков на стоимость и сроки программы и готовит предложение по размеру управленческого резерва, утверждает его размер у генерального директора.
  6. Руководитель программы доводит до команды запуска свое понимание рисков, и их влияние на программу, команда запуска согласна со списком рисков и планами реагирования.
  7. Руководитель программы постоянно сверяет, что стоимость программы соответствует уровню проработки документации по требованиям.
  8. Руководитель программы организует серию совещаний, на котором обсуждается какие разделы программы (программное, аппаратное обеспечение, персонал) находятся под риском удорожания при более детальном планировании работ.
  9. Руководитель программы организует серию совещаний, на которых обсуждает иерархическую структуру работ по всем альтернативным вариантам, и выявляет от чего в наибольшей степени зависит стоимость и риски рекомендованного решения, вносит эти пункты в реестр рисков проекта.
  10. Главный конструктор собирает совещание разработчиков, на котором обсуждается, достаточно ли информации, чтобы начать разработку системы.
  11. В ходе проработки проектных решений инженер по требованиям собирает и анализирует требования стейкхолдеров, трассирует их к потребностям стейкхолдеров, оформляет документацию по требованиям.
  12. Руководитель программы собирает совещание, на котором обсуждается бюджет разработки технического проекта по модульным домам, формирует итоговое предложение по финансированию разработки технического проекта, которое защищает у спонсора программы. Руководитель программы вносит защищенную сумму в план проекта и распределяет ее по бюджетам рабочих групп.
  13. Руководитель программы проверяет, что стоимость разработки, приобретения и тестирования программного обеспечения учтена в общей оценке стоимости программы, а стоимость приобретения программного обеспечения включает приобретение, разработку, поставку, развертывание.
  14. Руководитель программы проверяет, что аспекты обеспечения безопасности и соблюдения законодательства при разработке программного обеспечения учтены.
  15. Руководитель программы и главный конструктор проверяют реестр изменений и процесс управления изменениями и убеждаются, что изменения анализируются с учетом их влияния на весь жизненный цикл системы.
  16. Главный конструктор проверяет, что есть технические планы разработки по системы, датчикам, каналам коммуникации и планы по интеграции комплекса и дает подтверждение руководителю проекта о том, что дальнейшая разработка возможна.
  17. Подготовлены следующие документы: черновик плана по системной инженерии, предварительные расчеты технических характеристик, стоимости и сроков разработки минимум трех альтернативных концепций продукта, расписание работ, иерархическая структура работ предпочитаемого варианта, оценка стоимости и рисков реализации, план финансирования программы и детальный план финансирования этапа разработки технического проекта, анализ рынков сбыта и черновик маркетингового плана.
  18. Все документы, необходимые для проведения оценки концепции продукта заведомо рассылаются всем проверяющим.
  19. Все дополнительные документы, необходимые для проведения оценки концепции продукта, такие как изучение реализуемости, исследования рынка, предварительная стратегия программы были заведомо разосланы всем проверяющим.
  20. Для рекомендуемого технического решения подготавливает документ с техническими и экономическими показателями, по которым оно будет оцениваться. Документ подписывается генеральным директором, главным конструктором и руководителем программы.
  21. Все документы внесены в систему управления проектами и контролируются их версии. Настроены маршруты документооборота, права доступа к папкам проекта, всем участникам присвоены проектные роли в системе управления проектами.
Критерии прохождения контрольной точки "Запуск проекта"
  1. Предлагаемое техническое решение по системы по мнению команды запуска решает все поставленные задачи в рамках установленных ограничений, это мнение оформлено документально и принято генеральным директором.
  2. Архитектуры и требований для системы по мнению команды запуска достаточно для начала разработки.
  3. НИР можно провести в том виде, в котором они запланированы.
  4. Критические аспекты разработки программного обеспечения поняты разработчикам в достаточной мере, чтобы начать работу и уровень риска разработки приемлем.
  5. Технологические риски известны и есть планы по их уменьшению, есть ответственные за эти планы люди.
  6. Руководитель программы и системный инженер согласны с тем, что проект укомплектован персоналом, и продукт можно сделать в срок, решить все критические задачи разработки.
  7. Руководитель программы считает расписание программы реалистичным в рамках бюджета и технических рисков.
  8. Первичные технические характеристики системы зафиксированы в спецификации на поставку и поставлены под контроль конфигурации.
  9. Спецификации на системы соответствуют уровню готовности технологии к использованию, расписанию программы и бюджету.
  10. План программы и спецификация на системы соответствуют условия договора поставки заказчику.
План по системной инженерии содержит следующие разделы:
1. Введение - назначение документа и таблица версий
2. Технические требования к программе
2.1 Контроль архитектуры и интерфейсов
2.2 Сертификация
3. Инженерные ресурсы и управление разработкой и испытаниями
3.1 Расписание разработки и испытаний и оценка рисков расписания
3.2 Инженерные ресурсы и отчетность по стоимости и срокам
3.3 Управление рисками разработки и интеграции
3.4 Техническая организация
3.5 Взаимодействие с внешними техническими организациями
3.6 Технические параметры и характеристики
4. Технические задачи и продукты
4.1 Результаты системной инженерии предыдущей стадии
4.2 Планируемые работы по системной инженерии на следующую стадию
4.3 Процесс разработки и изменения требований
4.4 Защиты проектной документации
4.5 Процесс управления конфигурацией и изменениями
4.6 Варианты конструкции
4.7 Инженерные инструменты