Что такое ТЗ (техническое задание) и зачем оно нужно в ИТ-разработке, наверно, ни у кого вопросов не вызывает. Но вопросы могут возникнуть тогда, когда приходится слышать (особенно в постановке задачи для технического писателя) про "ТЗ для разработчика".

А что это такое и каким оно вообще может быть?

Само ТЗ на продукт ("большое" или "главное" ТЗ) представляет собой спецификацию высокоуровневых требований заказчика к создаваемому продукту. Сам ИТ-продукт (программа, информационная/автоматизированная система) справедливо воспринимается на этом уровне как чёрный ящик, внутреннее устройство которого заказчика не интересует (нам же, как пользователям, не интересно, как устроен телевизор или смартфон - главное, чтобы он выполнял те функции и обладал теми потребительскими характеристиками, которых мы от него ждём). Строго говоря, ТЗ на продукт - это базовый документ, который, с одной стороны, устанавливает договорённости между заказчиком и исполнителем, с другой - является основой для проверки соответствия функциональности и характеристик готового продукта исходным требованиям при его сдаче-приёмке.

Иногда ТЗ пишут на основе стандартов (например, ГОСТ 19.201 или ГОСТ 34.602), иногда делают свой шаблон. Главное, чтобы документ получился достаточно подробным, понятным (притом однозначно понятным), всеобъемлющим и непротиворечивым (хотя бы самому себе, не говоря уже про логику, здравый смысл, технические возможности и существующие ограничения, в т.ч. законодательные). Потом на его основе делают ПМИ (программу и методику испытаний), чтобы проверить, что продукт сделан правильно, делает то, что нужно заказчику, и работает так, как от него требуется.

Но как передать это ТЗ непосредственным разработчикам - дизайнеру (разработчику интерфейса), системному архитектору, архитектору баз данных, программисту?

Конечно, самый простой вариант - просто отдать "большое" ТЗ. Но это не всегда верный вариант, потому что, как мы уже сказали, оно пишется в расчёте на "чёрный ящик", а как он должен быть реализован, никто не знает.

А решение есть. Оно заключается в том, что после согласования ТЗ с заказчиком начинается процесс проектирования (независимо от того, какая методология выбрана для организации работ), и вот этот этап следует разбить на две фазы: общее "высокоуровневое" проектирование, когда внутри "чёрного ящика" выделяются компоненты и определяются концептуальные решения по реализации продукта, и проектирование и разработка уже непосредственно компонентов продукта. Вот на этом "водоразделе" между двумя фазами и следует сформировать промежуточные "ТЗ для разработчиков" - ТЗ на дизайн, ТЗ на ПО (фронт-энд/бэк-энд), ТЗ на БД/СХД, ТЗ на КТС (аппаратное обеспечение), ТЗ на интеграцию, ТЗ на контент и SEO и т.п.

Кто должен это делать? Тут тоже есть решение. В зависимости от методологии (выбранной модели процесса создания продукта) это может быть: - для методологии «водопад» — главный инженер проекта (ГИП) или системный архитектор - для Scrum/agile — владелец продукта (Product Owner) или менеджер проекта; - для DevOps — DevOps‑инженер.

Как оформить такие ТЗ и в каком виде передать разработчикам? Тут можно исходить из того, что задача на разработку должна быть зафиксирована в информационном артефакте, таком как: - документ (бумажный/электронный); - запись в репозитории (подход Docs as Code); - задача в таск‑трекере (например, Jira); - Kanban‑доска или чек‑лист (для кратких формулировок). В крупных проектах для этого может привлекаться технический писатель. В небольших задачу должен формулировать главный инженер проекта, владелец продукта или системный архитектор.

Для гибких методологий (agile, scrum, XP и т.д.) возможен подход MVP (Minimum Valuable Product) — итеративное приближение к целевому состоянию, т.е. задания разработчику разбиваются на мелкие задачи, умещаемые в спринт или карточку Kanban.

Резюме: ТЗ на продукт — основа для согласования внешних требований к продукту, но не готовое задание для разработчиков. А ТЗ для разработчиков должны делаться по итогам высокоуровневого проектирования и разработки архитектуры продукта.