Управление рисками IT-проекта: чек-лист для заказчика
Практика3 минРедакция Innovialabs
Коротко
Выпишите риски по пяти группам (люди, объём, технологии, интеграции, сроки), оцените вероятность и влияние каждого, назначьте ответственного и действие — и пересматривайте этот список на каждой встрече по проекту.
Коротко о главном
Управление рисками — это не толстый документ, а короткий список того, что может пойти не так, с понятным ответом на вопрос «что мы делаем, чтобы этого не случилось». Заказчику не нужно разбираться в коде: достаточно знать типичные риски, вести простой реестр и регулярно его обновлять вместе с командой.
Пять групп рисков
Люди
- Ключевой разработчик уходит, и знания уходят вместе с ним.
- Со стороны заказчика нет человека, который быстро принимает решения.
- Команда перегружена параллельными проектами.
Что делать: документация и code review, чтобы знания не жили в одной голове; один ответственный со стороны бизнеса с правом принимать решения.
Объём работ
- Требования меняются по ходу, и проект «расползается».
- Разные участники понимают задачу по-разному.
Что делать: зафиксировать объём первой версии, новые идеи складывать в бэклог, каждое изменение оценивать отдельно.
Технологии
- Выбран стек, который команда знает плохо.
- Не продумана нагрузка, безопасность или резервное копирование.
Что делать: небольшой технический прототип для рискованных частей, ревью архитектуры до начала основной разработки.
Интеграции
- Внешний сервис (платёжная система, 1С, CRM, госсервис) работает не так, как описано в документации.
- Доступ к тестовой среде партнёра получают с опозданием.
Что делать: запрашивать доступы в первую же неделю, начинать с интеграций, а не оставлять их на конец.
Сроки
- Оценка дана одной цифрой без запаса.
- Тестирование и исправление ошибок не заложены в план.
Что делать: просить оценку диапазоном, закладывать время на тестирование, делить проект на этапы с промежуточными демо.
Простой реестр рисков
Достаточно обычной таблицы. Вероятность и влияние оценивайте по шкале «низкое / среднее / высокое».
| Риск | Вероятность | Влияние | Действие | Ответственный |
|---|---|---|---|---|
| Задержка доступа к API банка | Средняя | Высокое | Запросить доступ в первую неделю | Менеджер заказчика |
| Уход ведущего разработчика | Низкая | Высокое | Документация, ревью кода | Тимлид |
| Рост объёма работ | Высокая | Среднее | Бэклог и оценка каждого изменения | Владелец продукта |
Начинайте с рисков, у которых высокое влияние: именно они способны остановить проект.
Чек-лист заказчика
- Назначен один человек, который принимает решения по проекту.
- Объём первой версии записан и согласован.
- Все доступы к внешним сервисам запрошены.
- Код хранится в вашем репозитории.
- Есть регулярные демо работающего продукта, а не только отчёты.
- Реестр рисков пересматривается хотя бы раз в пару недель.
- Есть план на случай срыва ключевого срока.
Частые ошибки
- Составить реестр один раз и больше к нему не возвращаться.
- Записывать риски без конкретного действия и ответственного.
- Считать риски исключительно задачей подрядчика.