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