Реестр рисков проекта: скучный документ, который экономит деньги

Реестр рисков — таблица из семи столбцов, которую заводят на старте проекта и обновляют раз в неделю. Она не предотвращает проблемы, а убирает спор о том, кто виноват и за чей счёт исправлять. Ниже форма, порядок ведения и типовой перечень рисков для проектов разработки.

1. Назначение документа

1.1. Реестр фиксирует события, которые могут повлиять на срок, бюджет или состав работ проекта.

1.2. Реестр ведётся с даты подписания договора до даты подписания акта сдачи-приёмки.

1.3. Реестр не заменяет договор и приложение с перечнем работ. Он дополняет их перечнем допущений и мер реагирования.

2. Форма реестра

2.1. Реестр ведётся в виде таблицы со следующими столбцами:

2.2. Формулировка риска должна содержать событие, а не состояние. Допустимо: «Прайс-лист не будет предоставлен до начала работ по каталогу». Недопустимо: «Проблемы с контентом».

2.3. Строка без указанной зоны ответственности считается незаполненной.

3. Порядок ведения

3.1. Первичный реестр составляет исполнитель в течение трёх рабочих дней с даты старта работ.

3.2. Заказчик дополняет реестр рисками своей стороны и утверждает документ.

3.3. Актуализация проводится еженедельно в фиксированный день. Изменения вносятся с указанием даты.

3.4. Строка закрывается, когда риск утратил актуальность, с отметкой «закрыт» и датой.

3.5. При наступлении риска исполнитель уведомляет заказчика в течение одного рабочего дня и указывает влияние на срок и бюджет.

4. Типовой перечень рисков

4.1. Контент не предоставлен в срок. Зона — заказчик. Влияние — сдвиг этапа на количество дней задержки. Мера — перечень материалов с датами в приложении к договору.

4.2. Прайс-лист предоставлен в формате, не пригодном для импорта. Зона — заказчик. Влияние — до трёх дней. Мера — согласование шаблона выгрузки на старте.

4.3. Доступ к внешней системе не получен. Зона — заказчик. Влияние — блокировка этапа интеграции. Мера — запрос доступов на первой неделе.

4.4. Внешнее API изменилось или недоступно. Зона — внешняя сторона. Влияние — от двух дней. План Б — ручной режим операции на период недоступности.

4.5. Подключение эквайринга и онлайн-кассы задержано банком. Зона — внешняя сторона. Влияние — сдвиг даты приёма платежей. Мера — подача заявления до начала разработки оплаты.

4.6. Согласование проводится более чем одним лицом. Зона — заказчик. Влияние — удлинение каждого круга правок. Мера — назначение одного согласующего с правом решения.

4.7. Состав работ расширяется в ходе проекта. Зона — обе стороны. Влияние — бюджет и срок. Мера — оформление изменений отдельным соглашением с новой оценкой.

4.8. Болезнь или недоступность исполнителя. Зона — исполнитель. Влияние — сдвиг срока. Мера — доступ заказчика к репозиторию с первого дня.

4.9. Объём данных превышает заявленный. Зона — заказчик. Влияние — переработка структуры каталога. Мера — фиксация количества позиций и вариантов в приложении.

4.10. Требуется дополнительная роль пользователя, не учтённая в смете. Зона — заказчик. Влияние — от трёх дней на роль. Мера — перечень ролей и прав до начала работ.

4.11. Домен занят или не переносится. Зона — внешняя сторона. Влияние — сдвиг запуска. Мера — проверка и регистрация домена до старта.

4.12. Сроки приёмки затянуты. Зона — заказчик. Влияние — задержка подписания акта и следующего этапа. Мера — фиксация срока рассмотрения в договоре.

5. Примечания по практике

5.1. Типовой узел разграничения прав — сборщик видит заказы, но не суммы платежей; менеджер видит клиентов, но не настройки системы. Изменение этого разграничения после начала работ относится к пункту 4.7.

5.2. Импорт данных со сторонней площадки следует выделять отдельной строкой реестра. В проекте «Жук и Плут» импорт с Wildberries был вынесен в отдельную вкладку админки, поскольку ручное заведение трёхсот позиций занимало вечер.

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

6. Ограничения применения

6.1. Для проектов со сроком до пяти рабочих дней ведение реестра нецелесообразно. Достаточно списка допущений в составе сметы.

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

6.3. Реестр не является основанием для отказа от обязательств. Наличие строки о риске не освобождает сторону от мер реагирования, указанных в этой же строке.

7. Порядок действий при наступлении риска

7.1. Сторона, обнаружившая наступление события, уведомляет вторую сторону в течение одного рабочего дня.

7.2. Исполнитель в течение двух рабочих дней представляет оценку влияния на срок и бюджет.

7.3. Стороны согласуют одно из решений: применение плана Б из реестра, сокращение объёма работ этапа, перенос срока, изменение бюджета.

7.4. Принятое решение оформляется письменно и вносится в реестр с датой. Устные договорённости в реестр не вносятся.

7.5. Строка реестра дополняется отметкой о фактическом влиянии после закрытия события.

8. Пример заполненной строки

8.1. № 3. Риск: доступ к личному кабинету службы доставки не будет предоставлен до начала работ по интеграции. Зона: заказчик. Вероятность: высокая. Влияние: блокировка этапа, до пяти рабочих дней. Мера: запрос доступа в первый день работ, ответственный со стороны заказчика назначен. План Б: интеграция через агрегатор доставки без прямого подключения перевозчика.

8.2. Приведённая строка содержит все обязательные элементы по пункту 2.1 и является образцом заполнения.

8.3. Строки, оформленные без указания меры и плана Б, к утверждению не принимаются.

Коротко

Реестр рисков — таблица из семи столбцов, которую заводит исполнитель, дополняет заказчик и обновляют раз в неделю. Каждая строка называет событие, зону ответственности, влияние в днях или рублях и два действия: до и после. Документ окупается на проектах от ста тысяч рублей и теряет смысл, если его не обновлять.