«Сделали не так»: борьба с очевидностью

Нужно принять как факт: компьютер и программист понимают только прямые указания. Если вы не написали, что при регистрации клиенту нужно отправить SMS с подтверждением, система его не отправит. Программист не видит ваш бизнес изнутри, он видит алгоритмы. Для него «кнопка меняет статус» — это буквально изменение одного значения в базе. Все дополнительные действия (уведомления, пересчеты, логирование) должны быть прописаны. Только так вы получите контролируемый результат.

Читайте сценарии буквально (метод «Робота»).

Попробуйте прочитать свое ТЗ или описание задачи так, будто вы — робот, который не знает ничего о вашем бизнесе. Если там написано «Добавить поле для ввода имени», робот добавит поле, в которое можно вписать цифры, иероглифы и даже целую книгу. Если вы хотите «Имя» длиной до 30 символов только русскими буквами — это должно быть зафиксировано.

• Проверяйте маски ввода: телефон, почта, даты.
• Уточняйте условия появления кнопок: когда кнопка активна, а когда — серая.
• Фиксируйте ошибки: что увидит пользователь, если введет неверный пароль?

Кто отвечает за полноту сценария?

Подрядчик может быть профессионалом высочайшего класса, он может задавать наводящие вопросы и предлагать лучшие практики. Но он не обязан (и часто просто не может) знать все нюансы вашего делопроизводства. Например, только вы знаете, что при возврате товара нужно обязательно уведомлять не только менеджера, но и старшего смены. Если вы упустили этот момент в описании — подрядчик не виноват. Полнота бизнес-логики — это зона ответственности заказчика.

Как застраховаться от недопониманий.

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