Главная ошибка требований — их пишут слишком рано

Большинство требований в IT-проектах появляются раньше, чем команда понимает, какой риск она пытается снять.

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

Через несколько месяцев выяснилось неприятное: даже идеально работающая система почти не дала бы экономического эффекта. Закупки делались раз в месяц, поставщики работали с крупными минимальными партиями, поэтому точность прогноза почти не влияла на реальные решения. Проект упёрся в первый риск:

отрицательная экономическая эффективность.

Нужно было начать не с проектирования системы, а с проверки экономики. Взять одну категорию товаров, один регион и посчитать: если точность прогноза вырастет на 10–15%, изменятся ли списания и объём закупок. После этого проект сузили до пилота для категорий, где эффект вообще возможен.

На втором витке решили купить готовое решение у известного вендора. Через несколько месяцев стало ясно: система рассчитана на e-commerce. Там прогноз напрямую управляет закупками — спрос вырос, товар можно быстро дозакупить. У ритейлера всё было иначе: поставки шли через распределительные центры, крупными партиями и с длинным циклом. Проект столкнулся со вторым риском:

неправильный выбор класса системы.

Решение было простым: сначала проверить соответствие операционной модели, прогнав реальные цепочки поставки через несколько типов решений.

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

низкое качество данных.

Только тогда команда сформулировала требования к качеству данных и правила их подготовки — после этого точность прогноза начала расти.

Все эти проблемы возникли по одной причине: требования написали слишком рано. Команда сразу описывала систему: витрины данных, интерфейсы, отчёты. Но сначала нужно было проверить три вещи:

— даст ли система экономический эффект — подходит ли выбранный класс решения — можно ли вообще доверять данным

И только после этого описывать саму систему.

Потому что требования — это не описание системы. Это способ снять главный риск проекта.

В проекте требования отвечают только на один вопрос: какой риск мы сейчас снимаем.

Если хотите продолжить тему — я собрал 11 типовых рисков проектов, которые снимаются требованиями.

Заполните короткую анкету, и я пришлю этот список в личку: https://forms.yandex.ru/cloud/696f578c02848f9a7de3de06