Что делать, если в тикете недостаточно требований
Что проверяют
Не начнёте ли вы писать код по догадке и умеете ли добывать недостающее, не превращая тикет в недельное ожидание. Для разработчика это вопрос про риск переделки: неверно понятое требование стоит дороже, чем полчаса на уточнение.
Как отвечать
Сначала уточнить самому, потом спрашивать людей. Что смотреть: сам тикет и связанные с ним, историю изменений, код и схему базы вокруг задачи, как сделано похожее место рядом. Часто половина ответов уже там.
Дальше сформулировать своё понимание и задать конкретные вопросы, а не «расскажите подробнее». Для серверной задачи это обычно:
- что на входе и на выходе, какие поля обязательны, что с валидацией;
- что делать при ошибке: падать, повторять, складывать в очередь недоставленных;
- можно ли вызвать операцию дважды и что тогда должно произойти;
- объёмы и сроки: сто записей или миллион, синхронно или фоном;
- ломаем ли обратную совместимость API и нужна ли миграция данных;
- по каким проверкам задача считается готовой.
Сильный приём: предложить свой вариант поведения по умолчанию. Подтвердить готовую формулировку человеку проще, чем сочинять требования с нуля.
Спрашивать письменно и в самом тикете, чтобы ответ остался в задаче, а не в личной переписке. Пока ждёте, работа не стоит: пишутся каркас, тесты и то, что однозначно. Если ответа нет, сузить объём: сделать бесспорную часть, спорную вынести в отдельный тикет или закрыть флагом.
Где спотыкаются
Начинают кодить по своей догадке и молчат. Через неделю выясняется, что имелось в виду другое, и переделка съедает больше, чем стоило одно сообщение в чат.
Задают вопросы устно или в личке, по одному, без фиксации. Ответ теряется, а через месяц никто не помнит, почему поведение именно такое, и спор начинается заново.
Уходят в другую крайность: ставят задачу в ожидание и не делают ничего, хотя большая часть работы от спорного пункта не зависит. Полная остановка выглядит так же плохо, как и догадка.