“Сделали не так”: почему это происходит и как предотвратить
Фраза “сделали не так” звучит в проектах разработки чаще, чем хотелось бы. И неприятнее всего то, что стороны обычно уверены в своей правоте: заказчик “очевидно имел в виду одно”, подрядчик “сделал по брифу”. На самом деле причина почти всегда в том, что на старте не было общего, проверяемого понимания результата.
Почему так происходит
1) Задачу описали “в общем”, без сценариев
“Нужен личный кабинет” — это не описание. Кабинет для клиента, менеджера, партнера? Какие действия обязательны? В каком порядке?
Профилактика: 5–10 сценариев в формате “кто → что делает → что получает”.
2) Не договорились о пределах
Если нет списка того, что точно входит в релиз, проект начинает “обрастать” ожиданиями.
Профилактика: список “входит/не входит” на этап.
3) Роли и права не обсуждены
Один и тот же экран для разных ролей — разные требования. Если не определить права, на демонстрации всплывает “а почему менеджер это видит?”.
Профилактика: простая таблица ролей и доступов.
4) Не описаны исключения и “краевые случаи”
В реальной жизни всегда есть отмены, возвраты, ошибки, дубли, повторные оплаты, “клиент передумал”.
Профилактика: на старте собрать список “что делаем, если…”.
5) Не было промежуточных проверок
Если показывают проект только в конце этапа, вы поздно узнаете о расхождениях.
Профилактика: короткие демо раз в 1–2 недели с фиксацией решений.
6) “Готово” было размытым
Если критерии успеха не прописаны, любая сторона может считать результат “почти готовым”.
Профилактика: критерии приемки по сценариям: что должно пройти без ошибок.
Минимальный набор для старта, который экономит недели
- Цель проекта и метрика “успеха” (что улучшится в бизнесе).
- Сценарии “как работает процесс”.
- Роли и доступы.
- Источники данных и ключевые интеграции (если есть).
- Правило изменений: как добавляем новое без срыва сроков.
Если это сделать до начала разработки, вы резко снижаете риск получить “не то” и превращаете обсуждение из эмоций в проверку по заранее понятным правилам.