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