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

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

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

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

Сегодня я приведу набор паттернов уменьшения рисков, предложенный Алистэром Коуберном в [1]:

1. Знания: Рассеивание тумана (Clear the Fog)
Если вы не знаете риски и трудности проекта достаточно хорошо для того, чтобы разработать хороший план - попытайтесь выпустить хоть что-то, это даст вам понять в чём реальные трудности.
Частные случаи: "Ранние и регулярные выпуски", "Прототип", "Микрокосм".

2. Знания: Ранние и регулярные выпуски (Early and Regular Delivery)
Вы не знаете какие проблемы вам встретятся в процессе разработки - выпустите что-то как можно раньше и выясните то, чего не знаете. Выпускайте регулярно совершенствуясь каждый раз.

3. Знания: Прототип (Prototype)
Вы не знаете как некотрые архитектурные решения себя поведут - разработайте отдельный испытательный прототип и понаблюдайте как он на самом деле работает.

4. Знания: Микрокосм (Microcosm)
Вам нужно разработать реальный план, но вы никогда не занимались проектами такого рода - запустите 8-12 недельный "пилотный" этап и соберите данные о продуктивности и т.п. для вашего плана.

5. Командная работа: Целостное многообразие (Holistic Diversity)
Разработка некоторого модуля требует разных умений, а люди имеют узкую специализацию - создайте команду из людей с разными умениями.

6. Продуктивность: Золотой рывок (Gold Rush)
У вас нет времени ждать утверждённых требований - начните разработку немедленно, корректируйте её по последним требованиям еженедельно.

7. Владение: Один ответственный на продукт (Owner per Deliverable)
Иногда над чем-то работает много людей, иногда никто - убедитесь что у каждого продукта (выпуска) есть ровно один ответственный.
Частные случаи: "Владельцы функциональности и компонент", "Одна команда на задачу"

8. Владение: Ответственные за функциональность и компоненты (Function Owners / Component Owners)
Если вы организовываете команду по компонентам, то страдает функциональность, и наоборот - убедитесь что за каждую функциональность и каждую компоненту кто-то отвечает.

9. Помехи: Кто-то всегда движется к цели (Someone Always Makes Progress)
Помехи постоянно прерывают работу команды - убедитесь что кто-то движется к цели что бы не случилось.
Частные случаи: "Одна команда на задачу", "Жертва", "Ежедневная забота"

10. Помехи: Одна команда на задачу (Team per Task)
От команды требуется серьёзное отвлечение от основной задачи - пусть этим займётся часть команды, а основная команда продолжает идти к цели.

11. Помехи: Жертва (Sacrifice One Person)
От команды требуется небольшое отвлечение от основной задачи - поручите это одному человеку.

12. Обучение: Ежедневная забота (Day Care)
Ваши експерты тратят всё свое время на обучение новичков - выделите одного эксперта курировать всех новичков, остальные разрабатывают систему.

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

Источники

1. Alistair Cockburn 'Project risk reduction patterns'