Сообщить об ошибкеКороткий ответ
Нужно явно выявить и зафиксировать противоречие, собрав всех заинтересованных сторон (или задав уточняющие вопросы письменно), и добиться одного согласованного и зафиксированного требования, прежде чем продолжать разработку.
Как это работает подробнее
Противоречивые требования почти всегда означают, что разные люди имеют в голове разные картины результата, и один из источников (или оба) ошибается или не в курсе деталей другого. Разработчик не должен выбирать между ними самостоятельно без согласования — это решение продукта, а не кода, и ошибочный выбор здесь обойдётся дороже любой технической недоработки.
Пример кода
example.txt
Сообщение в общем чате с ПМ и дизайнером:
"Вижу расхождение: в макете фильтр показывает 3 статуса (Новый/В работе/Завершён),
а в тикете описаны 6 внутренних статусов системы. Подскажите, пожалуйста,
какой вариант верный — фильтруем по 3 укрупнённым статусам для пользователя
или по всем 6? От этого зависит и модель данных на фронте."Что использовать на практике
- Практика. Эффективный способ — задать конкретный вопрос с явными вариантами («фильтр должен показывать все 6 статусов заказа или только 3 клиентских статуса, скрывая внутренние?») и попросить зафиксировать ответ в тикете или связать с макетом. Если решить быстро нельзя, стоит реализовать ту часть, которая не зависит от спорного вопроса, не блокируя всю задачу целиком и давая время продукту определиться.
Подводные камни
- Риски. Частая ошибка — молча выбрать «более вероятный» вариант и продолжить разработку, что часто приводит к переделке после демо и потере доверия к оценкам сроков. Другая ошибка — эскалировать конфликт как межличностный («дизайнер не прав»), вместо того чтобы представить его как техническую неопределённость, которую нужно решить фактами, макетами и данными о поведении пользователей. Также вредно затягивать с уточнением, рассчитывая, что противоречие «само рассосётся» по ходу разработки.