Риски проекта в разработке: как их видеть и не прятать

Чем риск отличается от проблемы

Риск — событие, которое может случиться и повлиять на срок, бюджет или качество. Проблема — то, что уже случилось. Разница во времени, и в этом времени вся ценность управления.

Пока событие остаётся риском, у команды есть варианты: снизить вероятность, подготовить запасной план, договориться с заказчиком. Когда риск стал проблемой, вариантов меньше и все дороже.

Стандарт PMBOK отдельно подчёркивает, что риск бывает и положительным. Например, заказчик может раньше срока отдать доступ к API, и команда выиграет неделю. На практике в IT почти всегда говорят об угрозах.

Почему риски прячут

Заказчик хочет быть уверен, что всё в сроке, бюджете и качестве. Менеджер не хочет получать от него за плохие новости. В итоге один слышит то, что хочет, а второй говорит то, за что не ругают. Разбор этой игры я делал в посте про «лавину», здесь — что делать с рисками системно.

Типичные риски в IT-проекте

Список у каждого проекта свой, но некоторые пункты повторяются почти везде.

• размытые требования: заказчик сам ещё не решил, что хочет;
• зависимость от внешних систем: API партнёра, 1С, платёжный шлюз, служба доставки;
• один человек знает критичную часть системы, и если он заболеет или уйдёт, работа встанет;
• ошибка в оценке: в начале проекта неопределённость оценки может доходить до четырёх раз в обе стороны;
• задержки со стороны заказчика: доступы, контент, согласования;
• изменения рынка или приоритетов у заказчика посреди проекта.

Управление рисками проекта по шагам

Процесс не обязан быть тяжёлым. Для проекта на 3–6 месяцев хватает таблицы и получаса в неделю.

• выявить: на старте пройтись по списку типичных рисков и спросить команду, чего она боится;
• оценить: вероятность и влияние по шкале от 1 до 5;
• назначить владельца: человек, который следит за риском и сигналит, если он приближается;
• выбрать реакцию и прописать триггер — признак, по которому понятно, что риск начинает сбываться;
• пересматривать раз в неделю на статусе и закрывать то, что уже неактуально.

Реестр рисков: какие поля нужны

Реестр — это обычная таблица. Сложнее всего не завести её, а не забросить через месяц.

Матрица вероятности и влияния

Произведение вероятности на влияние даёт балл от 1 до 25. Всё, что выше 12, я бы обсуждал с заказчиком сразу. От 6 до 12 — держал на контроле. Ниже 6 — фиксировал и не тратил на это время статусов.

Цифры условные. Их задача не в точности, а в том, чтобы команда спорила о приоритетах на одном языке.

Ещё одна польза матрицы — она снимает эмоции. Вместо «мне кажется, всё плохо» на статусе звучит «риск с баллом 16 вырос до 20, триггер сработал». С таким сообщением проще и менеджеру, и заказчику.

Как риски меняются по ходу проекта

Реестр, составленный на старте, через месяц устаревает. Риски не исчезают, они переезжают из одной части проекта в другую.

В начале главная угроза — требования. Это хорошо видно на «конусе неопределённости»: Барри Боэм описал его ещё в 1981 году в книге «Software Engineering Economics», а Стив Макконнелл популяризировал в книгах об оценке ПО. На старте оценка может ошибаться в разы, и сужается разброс только по мере того, как решения принимаются и фиксируются.

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

Ближе к запуску риски другие: перенос данных из старой системы, нагрузка в первый день, приёмка, к которой заказчик не успел подготовить тестовые сценарии. Здесь помогает простое правило — чек-лист запуска и репетиция переключения на тестовом стенде за неделю до даты.

Стратегии реагирования

Для угроз обычно выделяют четыре базовые стратегии, а PMBOK 6-й редакции добавил к ним пятую — эскалацию, когда риск вне полномочий проекта и его передают руководству. Выбор зависит от балла и от того, сколько стоит каждая.

• избежать: изменить план так, чтобы риска не стало, например отказаться от сомнительной библиотеки;
• передать: отдать риск тому, кто справится лучше, — подрядчику, страховщику, вендору по договору;
• снизить: уменьшить вероятность или влияние — прототип, ранний доступ к API, второй человек на критичном модуле;
• принять: ничего не делать заранее, но держать резерв по срокам или бюджету.

Резерв — не признак слабости

Часто менеджер боится закладывать резерв, потому что заказчик увидит «воздух». На деле резерв под конкретные риски из реестра выглядит честно: видно, на что он и когда сгорит. Голый процент сверху без объяснений вызывает подозрение, а резерв с привязкой к рискам — нет.

Как говорить о рисках с заказчиком

Формула простая: лучше немного неприятно сейчас, чем полный провал потом. Но и неприятный разговор можно провести так, чтобы он помогал проекту.

Сообщая о риске, стоит назвать три вещи: что может случиться, как это скажется на сроке или деньгах и что команда предлагает сделать. «Будем больше стараться» — не решение. Решение — это действие с владельцем и датой.

Заказчику тоже есть что делать. Оценивать менеджера стоит не только по результату, но и по тому, как рано он находит проблемы. Менеджер, который приносит риски на статус, полезнее того, у кого всегда всё зелёное.

Вопросы, которые заказчику стоит задавать

Если на эти вопросы нет ответа, реестра, скорее всего, тоже нет.

• Что может сдвинуть срок следующего этапа?
• Какие три риска сейчас самые опасные и кто за ними следит?
• Что нужно от нас, чтобы риск не сбылся?
• Какой резерв заложен и на что?