Техническое задание на разработку ПО: что описывать, а что вынести в roadmap

Техническое задание на разработку ПО нужно не для того, чтобы записать все будущие идеи в один большой документ. Его задача — зафиксировать управляемое обязательство: зачем создается система, какие требования входят в текущий объем, какие ограничения важны, как будет проверяться результат и как меняются требования после согласования.

В ТЗ стоит описывать то, что влияет на оценку, разработку, приемку и ответственность сторон. Будущие улучшения, гипотезы, спорные пожелания, технический долг и возможные этапы после первого результата лучше выносить в roadmap или backlog. Так ТЗ остается пригодным для оценки и приемки, а план развития не превращается в молчаливое обещание сделать все сразу.

• нужно согласовать объем разработки перед оценкой, договором или стартом этапа;
• проект включает несколько ролей пользователей, систем, интеграций, данных или ограничений;
• результат должен приниматься по понятным критериям, а не по общему впечатлению;
• есть требования из встреч, brief, предпроектного обследования, старого ТЗ, макетов или реестра требований, которые нужно привести к согласованной рамке;
• часть идей важна для будущего развития, но не должна становиться обязательством текущего этапа.

• задача маленькая и ее можно описать одним изменением, критерием проверки и короткой оценкой;
• требования еще противоречат друг другу и сначала нужен сбор требований, предпроектное обследование или discovery;
• команда хочет использовать ТЗ как полный backlog всех идей продукта;
• нужно описать уже выбранную архитектуру и технические решения после согласования требований — для этого ближе технический проект или спецификация;
• документ готовят только ради формальности, без владельца требований, порядка изменений и критериев приемки.

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

Состав ТЗ зависит от проекта, но рабочий документ должен помогать разработке, оценке и приемке. Обычно в нем фиксируют несколько групп сведений.

• Цель и границы системы: какую задачу решает ПО, где проходит граница текущего этапа, что не входит в объем.
• Роли и пользователи: кто работает с системой, какие права, действия и ограничения нужны разным участникам.
• Функциональные требования: какие сценарии, операции, статусы, проверки, уведомления, отчеты или формы должна поддерживать система.
• Данные и интеграции: какие сущности, справочники, документы, API, файлы, очереди или внешние сервисы участвуют в работе.
• Ограничения: безопасность, доступы, производительность, надежность, хранение данных, аудит действий, регуляторные или закупочные условия.
• Эксплуатация и сопровождение: что должно быть понятно после запуска: роли поддержки, журналы, мониторинг, резервное копирование, обновления и передача знаний.
• Приемка и изменения: как подтверждается результат, какие материалы передаются, кто принимает решение и как оформляются новые требования.

Не все полезные идеи должны попадать в ТЗ текущего этапа. Если включить в документ все пожелания, оценка станет тяжелой, а приемка — спорной.

• Будущие улучшения: функции, которые полезны после запуска первого результата, но не нужны для приемки текущего этапа.
• Гипотезы: идеи, которые нужно проверить на пользователях, данных, интеграциях или экономике проекта.
• Спорные пожелания: требования без владельца решения, приоритета или критерия готовности.
• Нерешенные архитектурные варианты: выбор платформы, способ интеграции, модель данных или контур размещения, если решение еще не принято.
• Технический долг и улучшения качества: задачи, которые важны для развития, но требуют отдельной оценки влияния на сроки, стоимость и эксплуатацию.
• Этапы после MVP: расширения, дополнительные роли, отчеты, интеграции и автоматизации, которые должны быть видны в плане, но не становиться обязательством первого этапа.

В проектах по ГОСТ 19 или ГОСТ 34 структура ТЗ может быть формальнее, но смысл остается тем же: документ должен связывать требования, границы системы, условия разработки, проверку результата и управление изменениями. Механическое копирование разделов стандарта не помогает, если в них нет реального содержания проекта.

• по каждому важному требованию понятно, откуда оно взялось и кто его подтверждает;
• обязательный объем текущего этапа отделен от будущих улучшений и идей;
• описаны данные, интеграции, роли, ограничения и критерии приемки, влияющие на оценку;
• нет формулировок вроде «система должна быть удобной» без проверки, сценария или критерия результата;
• roadmap и backlog не читаются как обещание реализовать все пункты в текущем этапе;
• понятно, какие изменения требуют пересмотра оценки, сроков, договора или состава этапа;
• ТЗ можно передать разработке, закупке, руководителю и приемочной стороне без устного пересказа всех договоренностей.

• начинать с шаблона ГОСТ, не разобрав цель проекта, пользователей, данные и ограничения;
• смешивать подтвержденные требования, идеи, гипотезы и будущие пожелания в одном списке;
• не фиксировать, что не входит в текущий этап;
• описывать интерфейсы и экраны, забывая про интеграции, данные, права доступа, ошибки и приемку;
• оставлять критерии приемки на потом, когда разработка уже выполнена;
• использовать backlog как приложение к договору без приоритетов и процедуры изменений;
• обещать фиксированную оценку при открытых архитектурных развилках или непроверенных внешних системах.

Хорошее ТЗ на разработку ПО дает не просто большой документ, а рабочую рамку для оценки и выполнения этапа. В нем понятно, какую систему или часть системы создают, какие требования входят в текущий объем, какие ограничения нельзя нарушить, как проверяется результат и что будет считаться изменением.

Отдельно должны быть видны материалы, которые не входят в обязательный объем: roadmap будущих этапов, backlog идей и запросов, гипотезы для discovery, вопросы для технического проекта или спецификаций. Такое разделение снижает риск споров по срокам, бюджету и приемке.

Если требования еще не собраны, начните со страницы как собрать требования к ИТ-проекту перед оценкой разработки. Если нужно превратить требования в этапы, используйте roadmap проекта из требований. Если полного ТЗ пока нет, но нужна модель оценки, проверьте оценку проекта без полного ТЗ.

Если задача начинается с текущих процессов и систем, полезно предпроектное обследование ИТ-проекта. Если нужен комплект документов, смотрите документацию на программное обеспечение. Если требования уже стабилизированы и нужно описать проектное решение, переходите к странице технический проект по ГОСТ 34.