Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

Паттерны управления рисками

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

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

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

Однако есть и хорошие новости, которые заключаются в том, что существуют предложенные разными авторами наборы паттернов, проверенных опытом реакций менеджера на возникновение определённых рисков. Естественно, эти паттерны не могут подойти в 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'


Posted by Vitalii Tsybulnyk on Saturday, August 29, 2009 5:18 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Add comment




  Country flag

b i u quote
Loading