Данная статья, является моим опорным конспектом по прочитанной книге Тома ДеМарко, Тимоти Листера «Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения».
В этом опорном конспекте я вынес интересные для меня идеи, сделал акцент на некоторые темы который были освещены в книги, в каких-то аспектах, провел дополнительное изучение.
Кто же такие, авторы данной книги —
Том ДеМарко (родился 20 августа 1940 г.) — известный автор, преподаватель и спикер по темам программной инженерии.
Карьера Тома ДеМарко началась в Bell Telephone Laboratories, где он работал в рамках легендарным проектом ESS-1. В последующие годы он руководил проектами в реальном времени для La CEGOS Informatique во Франции и отвечал за распределенные онлайн-банковские системы, установленной в Швеции, Голландии, Франции и Финляндии. Он читал лекции и консультировал в Северной и Южной Америке, Европе, Африке, Австралии и на Дальнем Востоке.
Имеет степень бакалавра естественных наук Корнельского университета, степень магистра и диплом Колумбийского университета и диплом Парижского университета в Сорбонне. В свободное время он работает техником неотложной медицинской помощи, сертифицированным в своем родном штате.
1986 году — лауреат Премии Жана-Доминика Варнье за «пожизненный вклад в область вычислений».
1999 году — лауреат премии Стивенса за «вклад в методы разработки программного обеспечения».
Автор девяти книг по менеджменту, организационному дизайну и развитию информационных систем.
Тим Листер (родился в 1949 году) — американский инженер-программист и автор, специализирующийся в области проектирования, управления рисками программного обеспечения и человеческих аспектов технологической работы. Тим Листер в соавторстве с Томом ДеМарко разрабатывает теорию, — над не техническими факторами, влияющими на работу команды и отдельных лиц. Эта работа была предметом ретроспективной специальной сессии Международной конференции IEEE.
В данной статье, мы рассмотрим одну из основных работ Тома ДеМарко и Тимоти Листера «Вальсируя с медведями», которая получила награду Software Development Jolt Award, — как лучшая книга.
—
Риски и выгоды всегда ходят рука об руку.
Если мы рискуем по крупному, мы имеем шанс получить большую выгоду. Это касательно всего в бизнесе, — если мы хотим быть успешными, необходимо пойти на взвешенный риск, и тогда, есть шанс на большой выигрыш. Многие мои проекты в бизнесе, были рискованными, но в большинстве случаев они приводили к успеху, результатам которого были точки роста компании.
Обязанность верить только в то, во что у вас есть право верить, называется управлением риском.
Авторы книги вводят понятие — Эскалаторы риска по Шарету
Роберт Н. Шаретт — всемирно признанный специалист в области управления рисками, информационных систем и технологий, системной инженерии, бережливой разработки и управления крупномасштабными программно-интенсивными системами, а также предпринимательства и инноваций в области рисков. С момента основания ITABHI Corp. в 1987 году он работал старшим советником широкого круга компаний из списка Fortune 100, консорциумов высоких технологий и государственных ведомств по вопросам эффективности, воздействия и вознаграждений / рисков их программ и политики в области высоких технологий. По образованию ученый-компьютерщик, Шаретт входил в состав комиссии Национального исследовательского совета по оценке эффективности программы обеспечения безопасности программного обеспечения космического шаттла НАСА. Шаретт много писал на темы управления рисками, управления проектами и программами, инноваций и предпринимательства. Он работает редактором журнала IEEE Spectrum, где ведет блог о факторах риска. Он также регулярно пишет статьи для Business Intelligence Review, правительственного журнала и журнала Cutter
Известный автор и эксперт в области управления рисками Боб Шарет (Bob Charette, — но, думаю правильно Robert N. Charette) предложил полезный новый способ отношения к риску в нынешних условиях. Он предложил представить вашу компанию и ее конкурентов как несколько движущихся вниз эскалаторов. Вам необходимо вскарабкаться вверх по своему эскалатору, уносящему вас вниз. То же самое делают на своих эскалаторах и конкуренты. Чем быстрее движутся ступени, тем быстрее нужно карабкаться каждому, чтобы держаться на одном уровне. Если остановиться хоть на мгновение, немедленно отстанешь. И, разумеется, если остановиться надолго, то вылетишь вниз, будучи не в силах продолжать борьбу с соперниками.
Сейчас наступила эра, когда риск вознаграждается, превращая компании, уклонившиеся от риска, в добычу, которую поделят другие.
Управление рисками — это управление проектами для взрослых.
Мы, специалисты по разработке программного обеспечения, приравниваем зрелость к профессиональной квалификации. У нас даже есть пятиуровневая модель для измерения такой зрелости — Модель зрелости процессов (Capability Maturity Model), или сокращенно СММ.
Модель зрелости процессов (Capability Maturity Model), или сокращенно СММ.
Интерпретация СММ
Беспорядок, кризис — у организации очень мало общих процессов. Успех проектов полностью зависит от усилий и опыта сотрудников. Организация мало делает для создания условий, помогающих все проекты делать успешными.
Стандартное управление проектами — организация внедрила стандартные процессы управления проектами и использует их во всех проектах.
Стандартные процессы организации — в организации достигнуты определенные элементы стандартизации в производственной деятельности организации. Общие технологии, инструментарии, процедуры, способы и прочее.
Управляемая обратная связь — собирается метрика о всех элементах процессов управления проектами и производства. Видеться библиотека метрик и познаний, полученных в завершенных проектах.
Оптимизация, непрерывное совершенствование — организация имеет замкнутый цикл исполнения процессов, измерений и непрерывного улучшения. Непрерывно используете измерения, обратную связь и творчество в целях оптимизации процессов.
Теперь нужна зрелость в ином, более традиционном смысле. Нам нужно повзрослеть, осознать существующие риски, чтобы планировать соответствующие действия. Именно этим и занимается управление рисками.
Риск — определение
1. Возможное в будущем событие, которое приведет к нежелательным результатам.
2. Сам нежелательный результат.
Первое — причина, а второе — результат, но не пытайтесь обманывать себя, рассчитывая справиться с обоими. Управление рисками как дисциплина целиком занята управлением причинными рисками. Это — те риски, которыми вы можете управлять (Однако оправданность управления рисками, в первую очередь, связана с результатами).
Риск — это проблема, которая еще не возникла, а проблема — это риск, который уже материализовался.
Управление рисками — это процесс продумывания корректирующих действий прежде, чем возникнет проблема, пока она еще остается всего лишь абстракцией. Противоположностью управлению рисками является кризисное управление, попытка понять, что делать с проблемой после того, как она появилась.
Было абстракцией, просто возможностью, а теперь уже вовсе не абстракция. Уже случилось. Это и есть момент события риска.
Событие риска — основное понятие в управлении риском. Это — событие, инициирующее меры, которые предполагается принять в отношении риска. Ну, это почти так. Реальное событие риска может быть невидно вам (например, Саддам Хуссейн решил вторгнуться в Кувейт). То, что вы видите, — это индикаторы (симптомы) события риска (скопление войск на границе). У каждого риска, с которым нам нужно справиться, есть какие-то симптомы. Однако некоторые из них более полезны, чем другие. Подробнее об этом будет сказано чуть дальше.
Пять основных составляющих управления риском:
- идентификация риска: первоначальный мозговой штурм по выявлению риска, последующая сортировка и определение какого-либо механизма для обеспечения постоянного действия данного процесса.
- анализ воздействия риска: количественная оценка каждого риска в терминах вероятности его наступления и потенциального ущерба.
- планирование реагирования на риски: что вы собираетесь делать, если и когда данный риск наступит.
- ослабление риска: меры, которые должны быть приняты предварительно, чтобы обеспечить возможность и эффективность проведения запланированных действий, если они потребуются.
- мониторинг и управление рисками: отслеживание рисков, выделенных в качестве объектов управления, выявление материализации рисков.
«Система автоматической обработки багажа ДМА» — узнаваемый символ некомпетентного проекта по разработке программного обеспечения первого признака задержки в начале 1993 года до частичного открытия в 1995 году. В результате неверных сроков времени разработки программного обеспечения и внедрения в новом аэропорту Денвера, открытия аэропорта задержалось на 2 годы, убытки составили несколько миллиардов долларов.
Справочно — Международный аэропорт Денвера (англ. Denver International Airport) — один из крупнейших международных аэропортов в США, расположен в 40 километрах к северо-востоку от центра Денвера. Изначально аэропорт должен был открыться 31 октября 1993 года, однако сроки несколько раз переносились: менялись требования к дизайну и возведению отдельных элементов комплекса. Каждая такая задержка сильно била по бюджету. В итоге 28 февраля 1995 года Международный аэропорт Денвера принял первый рейс.
Обсудим неопределенности в процессе разработки программного обеспечения
Среди наиболее важных источников неопределенности можно назвать:
1. Требования к системе: Что именно должна делать система?
2. Обеспечение стандартов взаимодействия: Как будет система взаимодействовать с людьми-операторами и другими системами того же уровня?
3. Влияние изменяющейся среды: Как во время разработки будут изменяться потребности и цели?
4. Ресурсы: Какие ключевые навыки и знания исполнителей возможно будет (при необходимости) привлечь по мере продвижения работы над проектом?5. Управление: Хватит ли у руководства таланта, чтобы создать эффективные команды, поддерживать боевой дух, обеспечивать низкую текучесть кадров и координировать сложные комплексы взаимосвязанных задач?
6. Сеть поставок: Будут ли другие участники проекта действовать так, как ожидалось?
7. Политика: Каков может быть результат использования политической силы для навязывания ограничений, несовместимых с успехом проекта?
8. Конфликты: Как различные участники проекта найдут компромисс между своими, зачастую несовместимыми, целями?
9. Инновации: Как уникальные для данного проекта технологии и методы влияют на возможный результат?10. Масштаб: Как повлияет на осуществление проекта увеличение масштаба работ, если раньше у разработчика не было соответствующего опыта?
На основании вышесказанного авторы книги делают вывод
Даже самый совершенный процесс разработки не может полностью устранить неопределенность при осуществлении проектов по созданию сложных систем. А где есть неопределенность, там появляется риск. При наличии риска нужны осторожные и продуманные усилия, чтобы с ним справиться. Вместо того, чтобы спрашивать: «Как они справлялись с созданием программного обеспечения?», можно гораздо глубже понять, что произошло при строительстве ДМА, задав вопрос: «Как они справлялись с управлением имевшимися рисками?»
Небольшая ремарка в рассуждения авторы с отсылкой на немецкий источник, — не стоит удивляться, немецкие источники активно работали в СССР над ракетной и ядерной программой, но в СССР, не любят об этом вспоминать, в то время как США, немецкими источниками пользуются открыто, чего стоит фон Браун, со своей ракетной программой. И так, отсылка авторов на немецкий источник.
Ни один план не выдерживает боевого столкновения с противником, — фельдмаршал Гельмут фон Мольтке
Управление рисками — способ разрушить этот мрачный цикл, обеспечив набор выполнимых целей и графиков и породив успешные проекты, которые выглядят и ощущаются как успешные с начала и до конца.
Ограниченная неопределенность может страшить (жутко подойти вплотную к осознанию того, как мало есть вещей, в которых можно быть уверенным), но без нее мы имеем дело с тем, что гораздо хуже — безграничной неопределенностью. Безграничная неопределенность либо отвращает людей от риска, либо приводит к безрассудной отваге. Обе эти крайности катастрофичны.
Авторы утверждают, что — управление рисками обеспечивает самую дешевую защиту от непредвиденных неприятностей.
Неопределенность и необходимые резервы
Когда вы знаете степень неопределенности, вы знаете, какой вам нужен резерв, чтобы обеспечить разумную защиту. Резерв — это то, что тратится на ослабление риска, плюс то, что нужно иметь в запасе для борьбы с неприятностями по мере их поступления.
По определению, резерв для сдерживания риска — это время и деньги, которые могут и не потребоваться. Нужно понимание, чтобы заложить резерв для сдерживания риска в график и бюджет. Но не иметь резерва, который можно развернуть при необходимости, как было в случае ДМА, означает заплатить много больше при материализации рисков.
Как считают авторы, разработка программного обеспечения — рискованный бизнес, поскольку весь процесс окутан неопределенности. Все, что нужно предсказать относительно проекта, будет в какой-то мере неопределенным.
Один из способов расширить перечень рисков — по крайней мере первоначально — состоит в методичном использовании анализа результатов после окончания проектов.
Четыре возможности, которые доступны в отношении риска;
• Вы можете его избежать.
• Вы можете его сдерживать.
• Вы можете его ослабить.
• Вам удастся от него увернуться.
Первые три способа стоят денег: избежание наносит урон в виде упущенной выгоды, сдерживание предполагает резервы на управление рисками; ослабление требует затрат на предварительные меры ради сокращения затрат сдерживания. Только когда вам удается увернуться от риска, это дается бесплатно.
Далее, раскрывается понятие, подверженность риску — это ожидание затрат на сдерживание. Ожидание, в том смысле, в котором используется этот термин здесь — это комплексное понятие, заимствованное из теории вероятностей. Это некоторая комбинация вероятностей того, что риск наступит, и затрат, которые вы понесете в этом случае.
В простейшем случае:
Подверженность риску = затраты * вероятность
Авторы предлагают такой вариант защиты, в случаи наступления риска —
Если посчитать подверженность для всех рисков и создать резерв на управление рисками, равный этой сумме, то такого резерва должно хватить, чтобы покрыть затраты на наступившие риски. В итоге вам может немного не хватить в одних проектах, зато останется часть резерва в других, но в долгосрочном плане ваш резерв будет в целом правильным.
Риски-катастрофы
Это — риски-катастрофы: если они возникнут, то намертво застопорят дело. Они заставят вас либо найти полностью новый подход к продукту, либо аннулировать весь проект.
Управление рисками, основные шаги:
1. Использовать процесс идентификации рисков для составления перечня рисков, которые грозят вашему проекту.
2. Убедиться, что все главные риски проектирования программного обеспечения представлены в вашем перечне.
3. Провести всю указанную предварительную подготовку по каждому из рисков:
• Дать наименование риску и присвоить ему уникальный номер.
• Провести мозговой штурм для выявления показателей наступления события риска (самых ранних признаков наступления риска).
• Оценить влияние риска на стоимость и расписание проекта.
• Оценить вероятность наступления риска.
• Рассчитать подверженность риску по отношению к графику и бюджету.
• Определить заранее, какие меры придется принять, если и когда событие риска наступит.
• Определить, какие меры для ослабления риска следует принять до наступления риска, чтобы обеспечить осуществимость избранных мер реагирования.
• Включить действия по ослаблению риска в общий план проекта.
• Выписать все детали в специальной форме, шаблон которой приведен в Приложении Б.
4. Указать возможные риски-катастрофы как допущения проекта. Разработать схему делегирования управления каждым из таких рисков вышестоящему руководству.
5. Сделать первый подход к оценке расписания, исходя из предположения, что ни один из рисков не материализуется. Другими словами, ваш первый шаг по оценке состоит в определении «даты с вероятностью нанопроцента», то есть самой ранней из дат, к которой вы можете успеть завершить проект.
6. Использовать собственные и отраслевые факторы неопределенности (подробности в главе 13) для построения диаграммы риска с пересечением в точке N.
7. Выразить, используя диаграмму риска, все обязательства по проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом.
8. Отслеживать все риски на предмет наступления или исчезновения и осуществлять планы на случай непредвиденных обстоятельств всякий раз, когда риски наступают.
9. Поддерживать в действии процесс идентификации рисков на всем протяжении проекта, чтобы справиться с поздно проявляющимися рисками.
Совокупные и причинные риски
Совокупными (агрегированными) рисками, поскольку они относятся к проекту в целом;
Причинными (слагающими) рисками — относится к отдельным задач проекта.
Вот список главных рисков:
1. внутренние изъяны календарного планирования
2. раздувание требований (изменение требований)
3. текучесть кадров
4. нарушение спецификаций
5. низкая производительность
Только последний из них действительно связан с исполнением. Остальные четыре практически совсем не зависят от того, насколько усердно вы трудитесь и насколько вы компетентны и опытны в исполнении данной работы.
Три этапа обнаружения рисков обычно проходят одновременно на одном и том же совещании.
Этап 1: Мозговой штурм
мозговой штурм по выявлению катастроф
Мозговой штурм — это групповое творчество. Идея состоит в использовании групповой динамики для отыскания обходных путей преодоления привычного мышления и возникновения новых свежих мыслей.
Некоторые особенности, присущих мозговому штурму в поисках катастроф:
1. Ставьте вопрос в явном виде в терминах ночного кошмара: почему-то это также помогает преодолеть действие неписаных правил, независимо от того, насколько присуще было корпоративной культуре позитивное мышление, ведь по-прежнему считается вполне нормальным вскочить ночью из-за жутких мыслей.
Используйте хрустальный шар: Представьте, что у вас есть доступ к хрустальному шару или способность узнавать чудом заголовки газет следующего года.
3. Опишите противоположные виды на будущее: Попросите людей описать свои самые радужные мечты относительно проекта, а затем обсудите прямо противоположную версию.
4. Спрашивайте о провале, в котором нет виновных: Как может проект потерпеть неудачу без того, чтобы это было чьей-то виной?
5. Спрашивайте о провале, в котором есть конкретные виновники: Спросите людей: «Как бы мог проект провалиться по нашей собственной вине? по вине пользователя? по вине руководства? по вашей вине?»
6. Представьте себе частичную неудачу: Спросите, как мог бы проект преуспеть в целом, по оставить одного конкретного участника неудовлетворенным или разгневанным.
Мозговые штурмы стремительны и яростны, поэтому нужно заранее сделать некоторые приготовления, чтобы не пропустить ни одного предположения. Убедитесь, что обязанность следить за этим возложена не на фасилитатора.
Этап 2: построение сценария
Воображать сценарии, которые могли бы привести к каждому из результатов. Придумывание сценариев может быть совершенно механическим, но вопрос о вине может повиснуть в воздухе, поэтому можно ожидать здесь некоторой напряженности. Здесь тоже нужно заранее продумать механизм улавливания и сохранения всей информации и использовать его, чтобы внезапно усилившаяся напряженность не помогла упустить те моменты, которые требуют самого пристального внимания.
Этап 3: анализ основных причин
Анализ основных причин сложнее, чем кажется. Причина этого не только во влиянии неписаных правил, но и в сложности понятия «основная» (определении того, достаточно ли глубока причина). Этот процесс успешнее осуществляет группа, чем отдельный индивидуум.
Взаимовыгодная альтернатива
Взаимовыгодная спиральная модель процессов WinWin Spiral Process Model — расширение классической спиральной модели жизненного цикла проекта
Она объединяет:
• жизненный цикл, развивающийся по спирали
• систему показателей (конкретнее, СОСОМО II)
• управление рисками
• «теорию W» группового взаимодействия
При взаимовыгодной стратегии любая пара выигрышных условий, между которыми существует конфликт или напряженность, представляет собой риск.
Краткий список мер по управлению рисками, которые нужно осуществлять в период с середины проекта и далее, до самого конца:
1. непрерывный мониторинг показателей наступления рисков в поисках такого риска из списка, который кажется готовым перейти из разряда «всего лишь скверной возможности» в разряд «реальных проблем»
2. продолжение выявления рисков
3. сбор данных для наполнения хранилища рисков (базы данных для определения количественного влияния проблем, наблюдавшихся в прошлом)
4. ежедневное отслеживание показателей завершенности
Инкрементная поставка — это разработка полного или практически полного плана проекта, а затем воплощение этого плана в жизнь подмножествами, где каждое следующее подмножество включает в себя предшествующие. Полная стратегия инкрементной поставки может и должна быть представлена и описана планом инкрементной поставки еще до создания первого подмножества.
В работе над проектом тоже разумно пораньше понести неизбежные потери. Иначе вы теряете контроль над ситуацией, позволяя событиям распоряжаться вами как угодно
Прибыль на инвестиции =(Ценность — Затраты) / Затраты
Затраты = $6235812,55
Выгоды = «Нам это необходимо»
Затраты и выгоды следует определять с одинаковой точностью.
Ценность — это тоже неопределенность.
Первый этап предсказания ценности состоит в количественной оценке и выражении ее в денежном эквиваленте дохода или процентах дополнительной доли рынка.
1. Организации, применяющие передовые практики, нацелены на проведение оценки выгоды, хотя могут менять ее форму от проекта к проекту.
2. Многие из них следуют схеме сокращения финансовых потоков, идущих сверху вниз, исходя из размера ожидаемой выгоды.
У одних компонентов отношение «выгоды/затраты» будет иметь высокий показатель, и это будут кандидаты на более раннюю готовность. Советуем вам составлять план версий, выбирая для более ранних версий компоненты, у которых показатели этого отношения выше. При поставке версии n все или большинство участников могут обнаружить, что среднее значение отношения «выгоды/затраты» еще не готовых частей незначительно.
Выгода неоднородна внутри системы, дает полезный тактический инструмент IT-менеджеру. Системные проекты отличаются проявлением отрицательных последствий, обусловленных изменением масштаба: при удвоении размера системы следует ожидать, что усилия для ее создания возрастут больше, чем вдвое.
Когда ставки высоки, стоит идти даже на серьезные риски. Когда игра не стоит свеч, практически никакой риск не является допустимым.
Что понимают под управлением рисками (уточненное и переработанное)
1. Используйте процесс идентификации рисков для составления перечня рисков, которые грозят вашему проекту
2. Убедитесь, что все главные риски проектирования программного обеспечения представлены в вашем перечне.
3. Проведите всю указанную предварительную подготовку по каждому из рисков:
• Дайте наименование риску и присвойте ему уникальный номер.
• Проведите мозговой штурм для выявления показателей наступления события риска.
• Оцените влияние наступления риска на стоимость и расписание проекта.
• Оцените вероятность наступления риска.
• Рассчитайте подверженность риску в терминах расписания и бюджета.
• Определите заранее, какие меры придется принять, если и когда событие риска наступит.
• Определите, какие меры для ослабления риска следует принять до наступления риска, чтобы обеспечить осуществимость избранных мер реагирования.
• Включите действия по ослаблению риска в общий план проекта.4. Укажите возможные риски-катастрофы как исходные допущения проекта. Разработайте схему делегирования управления каждым из таких рисков вышестоящему руководству.
5. Сделайте первый подход к оценке расписания, исходя из предположения, что ни один из рисков не материализуется. Другими словами, ваш первый шаг по оценке состоит в определении «даты с вероятностью нанопроцента», то есть самой ранней из дат, к которой вы можете успеть завершить проект. Это отличается от принятой в отрасли практики тем, что мы предлагаем использовать нанопроцентную дату как входные данные процесса составления расписания, а не как его результат. Определите N, используя какой-нибудь из инструментов параметрической оценки, если у вас он есть, настроенный на самые оптимистичные сценарии.
7. Выразите, используя диаграмму риска, все обязательства по проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом. Вместо того чтобы объяснять концепцию диаграмм риска любому из не самых сообразительных заказчиков, отнеситесь к ней как к моделированию своего проекта, сделайте 500 прогонов, показывая все возможные результаты и сравнительную вероятность каждого.
8. Разработайте иерархическую структуру работ, показывающую все задачи, которые нужны для выполнения проекта. Оцените усилия для выполнения каждой задачи, используя любую схему, которую обычно применяете для этого. Мы собираемся использовать эти оценки несколько менее привычным способом: будут приниматься во внимание только относительные веса усилий для выполнения задач, а не их абсолютные значения. Эти относительные веса будут нужны как входные данные для вычисления показателей ООФ.
9. В начале проекта утвердите договоренности по определению входных и выходных потоков данных. Вам следует иметь полную определенность относительно всех потоков данных, вплоть до самого низкого уровня, в пределах первых 12-15% календарного времени. Рассматривайте это как важное контрольное событие проекта. Не переходите к следующим задачам, пока не пройдено это событие. Помните, что неудача с этим показателем, определяющим все потоки, может оказаться роковым предупреждением.
10. Полностью разработайте план разбиения процесса разработки на части до начала осуществления проекта. Используйте это как входные данные для процесса создания плана инкрементных поставок.
11. Когда план разбиения процесса разработки на части завершен, вернитесь к иерархической структуре работ, оцените заново веса задач и выразите задачи в процентах от работы, которую предстоит выполнить.
12. Оцените выгоды с той же точностью, что и затраты.
13. Разбейте требования, содержащиеся в спецификации, до элементарного уровня. Перечислите их в порядке приоритета. В качестве двух критериев установления приоритета выбирайте чистую выгоду для пользователя и технические риски.
14. Разработайте план инкрементных поставок, в котором весь продукт разбит на версии (множество версий, по крайней мере столько, чтобы запланировать появление новой версии примерно раз в неделю). Опишите все требования к элементам соответствующих версий, чтобы пункты с более высоким приоритетом шли раньше. Вычислите ООФ для каждой версии и запишите в план. Рассматривайте план инкрементных поставок как главный результат проекта.
15. Разработайте технологию общих приемных испытаний для данного продукта и разделите их на приемные испытания отдельных версий (ПИn), по одному на каждую версию.
16. Построите график ООФ в соответствии с ожидаемыми датами поставки каждой иерархии. По мере прохождения версиями приемочных испытаний (ПИ) проставьте на том же графике реальные результаты.
17. Отслеживайте на протяжении оставшейся части проекта все риски на предмет наступления или исчезновения и выполняйте планы реагирования всякий раз, когда риски наступают. Наблюдайте за ООФ и его исполнением в сравнении с ожидаемым.Рассматривайте отклонения как признак возможного наступления риска.
18. Поддерживайте в действии процесс идентификации рисков на всем протяжении проекта, чтобы справиться с поздно проявляющимися рисками.
Легковерный человек — отец лжецу и мошеннику; он живет в кругу этого своего семейства, и не будет чудом, если он захочет стать таким же, как они. Наши обязанности так тесно переплетены между собой, что кто бы ни попытался соблюдать закон в целом, но нарушить его лишь в одной мелочи, виновен во всем.
Подводим итог: неправильно всегда, везде, для всех и каждого верить, во что бы то ни было, без достаточных фактов.
«Человек может быть еретиком в истине; и если он верит во что-то, только потому, что так сказал его пастор или так решило собрание, не зная иных причин, то даже если его убеждение окажется истинным, все же сама истина, которой он придерживается, становится ересью»
John Milton, Areopagirica. 1643.
«Тот, кто начинает с того, что любит Христианство больше, чем Истину, продолжит тем, что полюбит собственную секту или Церковь больше, чем Христианство, а кончит тем, что полюбит себя больше всего»
Samuel Taylor Coleridge, Aids to Reflection, 1825.