6. Скачайте RISKOLOGY (см. http://www.pmo.ru/riskology). Введите параметры своего проекта в главную рабочую таблицу. Там же введите все индивидуальные настройки, какие сможете найти, опираясь на имеющиеся у вас записи о предшествующей деятельности вашей компании. Замените как можно больше общеотраслевых, заложенных в имитаторе, данных относительно главных рисков имеющейся у вас достоверной информацией. Добавьте индивидуально настроенные рабочие таблицы для всех второстепенных рисков, которые вы отслеживаете. Проведите моделирование для получения диаграммы риска для вашего проекта, добиваясь пересечения с вашей нанопроцентной датой.
7. Выразите, используя диаграмму риска, все обязательства по проекту, в явном виде показывая неопределенность, связанную с каждой планируемой датой и бюджетом. Вместо того чтобы объяснять концепцию диаграмм риска любому из не самых сообразительных заказчиков, отнеситесь к ней как к моделированию своего проекта, сделайте 500 прогонов, показывая все возможные результаты и сравнительную вероятность каждого.
8. Разработайте иерархическую структуру работ, показывающую все задачи, которые нужны для выполнения проекта. Оцените усилия для выполнения каждой задачи, используя любую схему, которую обычно применяете для этого. Мы собираемся использовать эти оценки несколько менее привычным способом: будут приниматься во внимание только относительные веса усилий для выполнения задач, а не их абсолютные значения. Эти относительные веса будут нужны как входные данные для вычисления показателей ООФ.
9. В начале проекта утвердите договоренности по определению входных и выходных потоков данных. Вам следует иметь полную определенность относительно всех потоков данных, вплоть до самого низкого уровня, в пределах первых 12-15% календарного времени. Рассматривайте это как важное контрольное событие проекта. Не переходите к следующим задачам, пока не пройдено это событие. Помните, что неудача с этим показателем, определяющим все потоки, может оказаться роковым предупреждением.
10. Полностью разработайте план разбиения процесса разработки на части до начала осуществления проекта. Используйте это как входные данные для процесса создания плана инкрементных поставок.
11. Когда план разбиения процесса разработки на части завершен, вернитесь к иерархической структуре работ, оцените заново веса задач и выразите задачи в процентах от работы, которую предстоит выполнить.
12. Оцените выгоды с той же точностью, что и затраты.
13. Разбейте требования, содержащиеся в спецификации, до элементарного уровня. Перечислите их в порядке приоритета. В качестве двух критериев установления приоритета выбирайте чистую выгоду для пользователя и технические риски.
14. Разработайте план инкрементных поставок, в котором весь продукт разбит на версии (множество версий, по крайней мере столько, чтобы запланировать появление новой версии примерно раз в неделю). Опишите все требования к элементам соответствующих версий, чтобы пункты с более высоким приоритетом шли раньше. Вычислите ООФ для каждой версии и запишите в план. Рассматривайте план инкрементных поставок как главный результат проекта.
15. Разработайте технологию общих приемных испытаний для данного продукта и разделите их на приемные испытания отдельных версий (ПИn), по одному на каждую версию.
16. Построите график ООФ в соответствии с ожидаемыми датами поставки каждой иерсии. По мере прохождения версиями приемочных испытаний (ПИ) проставьте на том же графике реальные результаты.
17. Отслеживайте на протяжении оставшейся части проекта все риски на предмет наступления или исчезновения и выполняйте планы реагирования всякий раз, когда риски наступают. Наблюдайте за ООФ и его исполнением в сравнении с ожидаемым. Рассматривайте отклонения как признак возможного наступления риска.
18. Поддерживайте в действии процесс идентификации рисков на всем протяжении проекта, чтобы справиться с поздно проявляющимися рисками.
Часть V
Так есть или нет?
Как узнать, осуществляется ли на практике управление риском или нет?
Глава 23
Тест на управление риском
Если вы отвечаете за управление риском или стоите на более высокой иерархической ступени, вам нужен объективный способ, чтобы понять, делается ли эта работа. Зачем это? Почему бы просто не предположить, что люди, отвечающие за управление проектами, естественным образом будут привлечены к управлению рисками в этих проектах? Причина в том, что существуют мощные ложно-положительные показатели работы в организации. Они направлены на то, чтобы необоснованно давать ход всему, что называет себя управлением.
Представьте, что вы – руководитель более высокого уровня, чем тот, на котором находится рассматриваемый проект, а управление риском должно происходить на уровне проекта (внутри проекта или на том же уровне). Ложно-положительный показатель действует на уровне таких рассуждений: «Угу, мои люди ведут рискованные проекты, поэтому, конечно, они управляют рисками. В чем же состоит управление, в конце концов, если не в предвидении и поисках путей обхода различных препятствий, которые могли бы погубить проект? Разумеется, мои менеджеры – профессионалы: они не позволят себе обращать фокусироваться на ерунде и игнорировать реальные опасности».
Звучит хорошо. Проблема только в том, что такой ход мыслей игнорирует все расхолаживающие факторы, встроенные или зарытые в корпоративной культуре. Это включает в себя мышление «будет сделано», нежелание разочаровывать, требование сохранять «радужность» радужных сценариев, страх перед выражением неопределенности, необходимость видимости контроля (даже когда на самом деле контроль иллюзорен), соблазн использовать политическое влияние для приукрашивания действительного положения дел и своего рода близорукое мышление, губящее все начинания.
Это – мощные силы. Они могут заставить несомненно думающих людей отказываться от разумного управления и принимать вместо него разумное на вид управление. Есть разница.
Набор объективных тестов для определения того, происходит ли на самом деле управление рисками, может быть полезен не только высшему руководству, но и самим менеджерам рисков.
Когда управление рисками действительно ведется и укореняется в корпоративной культуре, проекты смогут пройти все или большинство следующих проверок:
1. Имеется перечень рисков. В этот перечень включены все главные риски проектов разработки программного обеспечения, а также риски, присущие исключительно данному проекту. Риски эти по природе своей причинные (то, что вызовет ужасные результаты, а не то, что само является ужасным результатом).
2. Имеется действующий процесс идентификации рисков. Идентификация рисков ведется открыто, причем приветствуется участие каждого в этом процессе. Конкретные шаги сделаны для того, чтобы можно было безопасно высказывать вслух неприятные вещи. Можно даже открыть анонимный канал для сообщения плохих новостей. Такая схема успешно работает в компаниях некоторых наших клиентов. (Ее не часто используют, но когда используют, это неоценимо).
3. Везде есть диаграммы неопределенности. Их используют для количественного измерения причинных рисков и для выражения совокупных рисков и ожиданий. Корпоративная культура начинает считать непрофессиональным взятие обязательств без упоминания в явном виде об их неопределенности.