Что включает в себя техническое задание для разработчиков?

Что проверяют

Понимаете ли вы, что техническое задание пишется не ради документа, а чтобы разработчик и тестировщик начали работу без цепочки уточняющих вопросов. Ждут не оглавление по памяти, а перечень того, без чего задачу нельзя брать в спринт.

Как отвечать

Начните с критерия готовности: задание готово, когда аналитик, разработчик и тестировщик одинаково понимают, что считается сделанным. Дальше пройдитесь по содержанию:

• контекст и цель: какую проблему закрываем и по какой метрике поймём, что получилось;
• границы: что входит в объём и что сознательно не входит;
• пользователи и сценарии, включая роли и права доступа;
• функциональные требования на языке поведения системы, с критериями приёмки;
• правила и алгоритмы с примерами расчёта на конкретных числах, особенно если есть округления, валюты, даты и часовые пояса;
• данные: модель, справочники, что делаем с уже накопленными записями;
• интеграции: контракты вызовов, форматы, коды ошибок, таймауты, повторы и идемпотентность;
• нефункциональные требования с проверяемыми числами: нагрузка, время ответа, доступность, ограничения на размер;
• поведение в крайних случаях: пусто, дубликат, отказ смежной системы, недостаточно прав;
• макеты и тексты, аналитика и события, миграция и обратная совместимость;
• открытые вопросы списком, у каждого владелец и срок.

Отдельно скажите про версионность документа и порядок внесения изменений: без этого задание устаревает на второй неделе.

Где спотыкаются

Описывают интерфейс вместо поведения. Из фразы про кнопку справа неясно, что происходит при нажатии дважды, при отсутствии прав и при ошибке сервера, и разработчик додумывает сам.

Пишут нефункциональные требования словами «быстро» и «надёжно». Такое требование нельзя ни реализовать осознанно, ни проверить, нужны число и условия замера.

Прячут нерешённое. Открытые вопросы, не вынесенные в отдельный список, всплывают в середине разработки и стоят переделки, а не уточнения.