Проектные риски из моей практики

Денис Бесков выделил 11 проектных рисков:
1️⃣ Построение системы, которая решает «не ту задачу»
2️⃣ Неприемлемая экономическая эффективность проекта (ROI < 0)
3️⃣ Непринятие системы пользователями
4️⃣ Неправильный выбор класса системы или вендора
5️⃣ Эскалация сроков и бюджета (scope creep)
6️⃣ Архитектурная несостоятельность решения
7️⃣ Конфликты со стейкхолдерами и управленческие кризисы
8️⃣ Регуляторные, юридические, комплаенс-риски
9️⃣ Низкое качество данных и решений на их основе
🔟 Рост стоимости изменений после внедрения
1️⃣1️⃣ Локальные дефекты реализации и бесконечные доработки

Поделюсь своим проектным опытом
❌ 3. Непринятие системы пользователями
📍2 заказчика, которым нужны шашечки, а не ехать

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

📍 Автоматизация Водоканалов
Мастера саботировали работу у канавы на планшете:
• холодно
• руки грязные
• камера не работает (затирали наждачной)
• «это невозможно»
Причина — система усиливала контроль за их работой. Им нужно было фиксировать на планшете каждую выполненную операцию с указанием времени начала и окончания, а также прикладывать фото с места проведения работ
Решение:
жёсткий контроль главным инженером + принятие работы только по результату аудита действий в системе.
Итог: система эксплуатируется по филиалам Водоканалов России.

❌ 6. Архитектурная несостоятельность

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

❌ 7. Конфликты со стейкхолдерами
Смена топ-руководства =
- остановка развития продукта
- повторный аудит решений
- необходимость каждый раз заново доказывать ценность

Частые смены руководства иногда вынуждают замораживать развитие продукта.

❌ 10–11. Рост стоимости изменений и локальные дефекты

Взяли на развитие систему другого подрядчика.
Задача: разработать 3 новых модуля к уже существующей системе.
В процессе вскрылась несостоятельность архитектуры БД:
➖между сотрудником и подразделением не было внешнего ключа
➖можно было удалить подразделение → пользователь из удалённого подразделения не проходил аутентификацию
Пришлось за наш счёт править ядро, хотя разработка новых модулей оценивалась без затрат на такой сюрприз.
Мораль: исходная архитектура чужой системы часто дороже новых функций.


Большинство проектных рисков — не технические.
Они про людей, данные, управление и мотивацию.
Код почти всегда можно переписать.
Непринятие пользователями, хаос управления и дефекты данных — дороже всего.
Крутой AI-аналитик