Разработка программного обеспечения на основе рисков

Перевод материалов Mike Griffiths Работа над повышением стоимости бизнеса при игнорировании рисков схожа с обогревом дома, у которого раскрыты все двери и окна: гораздо больше работы, чем требуется, вряд ли успешный финал, ну и, попросту говоря, это не самое умное решение. В сложных проектах всегда есть риски и возможности. В этом можно быть абсолютно уверенным, точно так же, как можно быть уверенным в том, что на море будут приливы и отливы. Стратегия управления рисками во многом зависит от того, занимаемся ли мы этим вопросом и двигаемся успешно или спотыкаемся об него, не достигая своей цели. Гибкие методы включают в себя множество механизмов для успешного управления изменениями, вдруг возникшими в последнюю минуту (например, простое изменение приоритетов в списке задач, короткие итерации, частые проверки , перепланирования и т.д.) – проактивные реакции на риски. Можно, кстати, включить действия по предотвращению и уменьшению рисков в список задач, для того, чтобы атаковать риски еще до того, как они окажут влияние на проект. Все это можно рассматривать как часть увеличения стоимости бизнеса. Очень важно часто поднимать вопрос: что мы делаем дальше: работаем над функционалом или снижаем риски проекта. Часто этот вопрос подытоживается термином «следующий правильно потраченный доллар» и призывает задуматься о предотвращении и смягчении рисков, как части ценностное предложение и гибкого планирования. Таким образом, во время планирования следующей итерации, соблюдается баланс между донесением стоимости бизнеса и уменьшением рисков. Иногда выбирается функциональность, которая даст больший возврат инвестиций, а иногда предпринимаются шаги по предотвращению или смягчению риска, потому как влияние возникающего риска может быть выше, чем ценность от возврата инвестиций в следующую функциональность в нашем списке задач. По ходу проекта команды, использующие гибкие методы, работают с такими инструментами, как диаграммы сгорания задач и профили рисков. Эти инструменты используются для иллюстрации подхода, основанного на управлении рисками, и цель всего этого – быстро уменьшить риски проекта. Другое преимущество простого разрешения рисков – это стоимость сбережений по кривой изменений, которые вероятны в софтверных проектах. Если заранее предпринять действия по работе с рисками, то можно снизить их общее воздействие на проект. Здесь сравнивают ситуацию с этим же проектом, но если бы риски возникли позже, когда в ретроспективном подходе и ревизии эффект от них был бы значительно больше. Перефразируем: рано разрешенные риски более ценны, чем поздно разрешенные. Гибкие методы и их механизмы проталкивания и частые изменения приоритетов могут заранее предпринимать действия по управлению рисками. Эти действия предпринимаются настолько заранее, насколько это возможно в жизненном цикле, минимизируя эффект домино. Так как тестирование проводится в каждой итерации, то к окончанию проекта шансы того, что какие-то элементы риска остались не протестированными, существенно снижаются. По существу, гибкие методы могут быть названы «управляемые рисками» (risk-driven), так как варианты с рисками проталкиваются вперед в списке задач. В то время как гибкие методы предоставляют некоторые красивые подходы к проактивному охвату хороших практик по управлению рисками, они не проверяют на риски и не защищают проект от рисков. Действительно, если гибкий подход является новым для организации, то представление этого подхода само по себе будет риском – ведь все новое представляет риск неправильного использования, недопонимания, замешательства или провала. Однако, гибкие методы вряд ли уже являются новыми и проблемы адаптации здесь хорошо понятны. Вообще говоря, мы стремимся преодолеть большинство так называемых «правильных, но не достаточных» аспектов управления рисками, которые слишком часто встречаются в проектах:
  • Плохо вовлеченный – сухой, скучный, академический, не приносящий достаточных изменений
  • Сделано единожды – обычно происходит в самом начале, когда мало что известно о проекте
  • Недостаточно пересмотрено – обычно «заброшено» в одну сторону и больше не пересматривалось
  • Не интегрировано в цикл проекта – скудные инструменты для интеграции задачи
  • Без вовлеченности, слабая видимость – немногие участники регулярно проверяют проект на риски
Ниже попробуем показать управление рисками вне роли менеджера проектов и расскажем больше о преимуществах кооперативных командных упражнений. Во-первых, зачем нужны кооперативные игры? Ровно как техника вроде покер планирования и планирование итерациями эффективно дают оценку и распределяют активность команды и добывают технический инсайд, получившийся вследствие объединения команды, ближе к работе. Также действуют кооперативные игры для управления рисками. В конце концов, зачем оставлять управление рисками самому далекому от технической работы человеку – менеджеру проекта? Но прежде чем я разочарую менеджеров проекта, которые беспокоятся о размывании обязанностей, надо четко определиться с целью всего этого. Я сторонник близкого и более эффективного вовлечения участников команды, которые располагают инсайдами о технических и человеческих рисках. Я не предлагаю переложить весь учет рисков на плечи команды и предложить им разрешать их. Вместо этого предлагаю найти лучшие идентификации качества рисков и дополнительные инсайды о предотвращении и смягчении рисков, а не всецело заменять функции управления рисками. Итак, зачем вообще нужно заниматься организацией команды? Почему нельзя просто дать возможность делать то, что они делают – разрабатывают проект? В общем, есть ряд повторно возникающих проблем в том, как управление рисками покушается на проекты. Большинство софтверных проектов больше походят на задачи по решению проблем, чем на план по выполнению задач. Очень тяжело отделить экспериментирование и миграцию риска от чистого выполнения. Участники команды активно вовлечены в ежедневное управление рисками. Можно получить пользу от их вклада в процесс управления рисками и если они осознают риски проекта (будучи вовлеченными в их определение), то, то, какой подход к работе они используют, может лучше осведомлять о рисках и быть в итоге более успешным. Преимущества такого сотрудничества нашли широкое признание. В исследовании, проведенным Стивеном Яффи (Steven Yaffee) из университета Мичигана, выделяются следующие преимущества:
  1. Генерация более мудрых решений. Достигается через понимание комплексных и пограничных проблем посредством обмена информацией
  2. Популяризация решения проблемы, а не процессуальное принятие решений
  3. Поощрение действий (Foster action) через мобилизацию совместных ресурсов для хорошего выполнения работы
  4. Создание человеческого капитала через выстраивание отношений и понимание
  5. Поощрение принадлежности к общим проблемам через придание ценности участию и децентрализации.
Здесь есть несколько мощных концепций, на которые следует взглянуть еще раз. Достаточно очевидно, что объединение большой группы акционеров сможет предоставить лучший список возможных рисков и позже привести творческие пути предотвращения и уменьшения этих рисков. Однако, действительная польза объединения команды исходит от изменений, которые происходят в самой команде. Организуя команду, мы не только получаем лучший ввод информации и идей, но также поощряем решение проблем, поощряем действия, строим человеческий капитал и поощряем коллективную принадлежность к идеям. У нас больше нет менеджера проекта, который беспокоится о рисках, теперь у нас есть мотивированная, энергичная и воодушевленная команда, проактивно управляющая рисками. Слишком часто в проектах проделывается отличная работа по идентификации возможных рисков и плохая работа, чтобы что-то с ними сделать. Результат – срыв проекта, когда известный риск становится проблемой. Когда команда полностью сосредоточена на рисках проекта, небольшие изменения в их поведении исключают многие риски на корню, еще за долго до того, как эти риски смогут навредить проекту. Также следует обратить внимание на последний пункт в преимуществах, описанных Яффи. Придание ценности участию и децентрализация очень хорошо подходит для команд, наделенных правами, и для модели «лидер-ведомый», которые продвигаются гибкими подходами. Мы уже поощряем эти идеи, когда отчитываемся о ходе проекта на ежедневных митингах, оцениваем проект через технику «покер планирования» и принимаем решение с помощью технологии «кулак пяти», так почему же не использовать все это для управления рисками? Конечно же, сотрудничество – это не серебряная пуля. Как и во всех подходах здесь есть минусы и возможности неверного использования. Например, метод мозгового штурма может задушить инновации и свести все к групповому мышлению. Так что давайте проясним: совместная работа означает не только мозговой штурм, но также включает объединение частных идей. Но прежде чем закончить статью, давайте рассмотрим процесс управления рисками в институте менеджмента проектов (PMI) и обратим внимание на пофазный список кооперативных игр. Последнее руководство по управлению рисками, составленное институтом менеджмента проектов (PMI) идет от пятой предварительной редакции свода знаний по управлению проектами (PMBOK) и описывает процесс по управлению рисками, состоящий из шести шагов.
  1. Планирование управления рисками
  2. Идентификация рисков
  3. Выполнение качественного анализа рисков
  4. Выполнение количественного анализа рисков
  5. Планирование системы реагирования на риски
  6. Контроль рисков
Через кооперативные игры каждый из этих шести шагов по управлению рисками может быть воссоздан в виде высоко визуализированных и командных действий, которые позже создадут истории по предотвращению и миграции рисков в продуктовом списке задач. Нам важны именно визуальные кооперативные игры, потому как визуальное представление активирует работу правого и левого полушария мозга. Они помогают задействовать наглядное мышление и память, для того, чтобы не забыть про риски. Это та же причина, по которой сегодня военные до сих пор используют визуальные знаки для представления сил противника, не смотря на то, в их распоряжении уже есть самые передовые инструменты. Забыть о визуальных знаках – фатально. Аналогично – забыть о рисках проекта. Кооперативные игры, которые охватывают эти шаги: 1) Планируйте поход (Планируйте управление рисками) а. 4C – учитывайте стоимость, следствия, содержание и селекцию (Costs, Consequences, Context and Choices) б. Покупаем ли мы кофе, диван, машину или квартиру? Насколько все должно быть строго и какой подход самый лучший? в. Депозиты и банковские сборы – понимание функционала и рисков 2) Найдите друзей и врагов (идентификация рисков и возможностей) а. Часы судного дня б. День кармы в. Другие формы идентификации рисков (профили рисков, листы рисков проекта, ретроспективы, анализ историй пользователей, вальсирование с медведями – топ 5-10 для софта) 3) Размести свою рекламу – (качественный анализ риска) а. Разыскиваются инвесторы и помощь – классификация и визуализация возможностей и рисков. б. Перетягивание каната – категоризация проекта 4) Сегодняшний прогноз – (количественный анализ риска) а. Логова дракона – следующий лучшим способом потраченный доллар б. Битвы роботов – симуляции 5) Инъекции в записи (backlog) – (планирование реагирования на риски) а. Функция распределения – выберите путь реагирования на риски б. Баланс доллара – сравнение риска/возможности метода освоенного объема к окупаемости инвестиций (Risk / Opportunity EVM to ROI) в. Карточка отчета – соприкосновение покупатель/владелец продукта г. Инокулятор – проведите инъекцию избегание риска/смягчение и истории возможностей в записи списка задач 5) Радар рисков – (мониторинг и контроль рисков) а. Диаграмма сгорания рисков – отслеживание и мониторинг б. Ретроспектива рисков – оценка эффективности плана по управлению рисками в. Промывание и повторение – обновление артефактов по управлению рисками, процесс пересмотра