Рассказываем в деталях, что такое техническое задание на разработку, из чего оно состоит, и почему нельзя просто взять и начать пилить код.
Технологии
Как ускорить подготовку технического задания с ИИ и не потерять качество
PDF-материал для аналитиков: как управлять контекстом, требованиями и решениями при работе с LLM, проверять результат и пересобирать документацию без противоречий. Внутри — методика Rubius, практический пример, чек-лист и готовый шаблон промпта.
Статья пригодится заказчикам программного обеспечения на начальном этапе проекта: менеджерам, стартаперам и бизнес-аналитикам. Особенно она будет полезна тем, кто делает техническое задание впервые и хочет избежать типовых ошибок.
Техническое задание (ТЗ) – это документ, который детально описывает функции, требования, характеристики и пользовательские сценарии программного обеспечения. Также в нём фиксируют необходимый объём работ, их порядок и критерии приёмки. Если совсем просто, ТЗ – это инструкция для команды разработки: что нужно сделать и как это должно в итоге функционировать.
Однако ТЗ нужно не только исполнителю. Заказчику документ помогает сформировать чёткое видение разрабатываемого ПО, оценить жизнеспособность идеи, объём, время и стоимость разработки, а после по пунктам проверить качество готового решения.
Начинать разработку софта без ТЗ – большой риск и прямая дорога к недопониманию между заказчиком и исполнителем. Меньшее из зол здесь – увеличение сроков и стоимости проекта. Но может получиться и так, что готовое ПО вообще не будет решать задачу клиента. Время потеряно, бюджет потрачен, а KPI не выполнен – для менеджера проекта это всегда удар по репутации и риск не получить ни новых проектов, ни финансирования.
Поверхностное ТЗ лучше его полного отсутствия, но от проблем тоже не избавит. Разработчикам придётся часто уточнять детали, что значительно увеличит время и стоимость разработки.
Но даже круглосуточная связь с заказчиком при отсутствии чёткого ТЗ не гарантирует идеальное качество. Поэтому к составлению технического задания нужно подходить серьёзно и воспринимать его как фундамент для всего проекта.
Составить техническое задание может как заказчик ПО, так и его разработчик.
В основном этим занимаются бизнес-аналитики. Они собирают требования к проекту, определяют его цели и превращают всё это в понятные и структурированные спецификации.
Лайфхак: дайте почитать готовое ТЗ человеку, который не участвовал в его разработке. После задайте вопросы по содержанию – если он понимает смысл так же, как и вы, значит, формулировки в ТЗ однозначные и понятные.
В крупных проектах, особенно для участия в тендере, для разработки технического задания собирается целая команда. Менеджеры координируют работу над ТЗ, оценивают временные рамки и необходимые ресурсы. Разработчики, архитекторы и системные аналитики продумывают технические детали и выявляют ограничения, чтобы адаптировать требования к реальным условиям. UX/UI-дизайнеры готовят прототипы или макеты интерфейса. Юристы и финансисты проверяют техническое задание на соответствие юридическим требованиям и бюджетным ограничениям.
– Техническое задание по ГОСТ 34 и ГОСТ 19. Обязательный документ для тендеров и крупных корпоративных проектов. Содержит детализированное описание этапов проекта, технические требования, стандарты качества, критерии приёмки и сроки выполнения. Учитывает юридические и нормативные аспекты проекта.
– ТЗ для малых проектов и доработок. Менее формальное описание конкретных задач или улучшений. Составляется вместе с командой разработчиков.
– Внутреннее ТЗ. Описание проекта, используемое внутри компании заказчика. Как правило, менее формальное и предполагает возможность изменений в процессе разработки.
– Product Requirements Document (PRD). ТЗ для стартапов и новых продуктов на начальной стадии разработки. Описывает видение продукта, какую проблему пользователя он решает, ключевые функции и желаемые результаты. Всегда отражает текущее представление о проекте и может меняться в процессе развития.
– Гибкие технические задания. Набор пользовательских историй или задач и критериев их готовности. Применяются в методиках гибкой разработки, таких как Scrum или Kanban. Их особенность в быстрой адаптации к меняющимся требованиям и постоянном фокусе на пользе решения для конечного пользователя.
Универсального шаблона для технического задания в IT нет – его содержание зависит от особенностей проекта. Но есть общепринятые стандарты оформления документации на разработку, например, ГОСТ 34, ГОСТ 19, IEEE STD 830-1998, ISO/IEC/IEEE 29148:2018 и другие. Можно использовать их не меняя или адаптировать под свои нужды.
Техническое задание должно содержать достаточно информации для понимания и реализации проекта. Вот необходимый минимум.
Общее описание проекта:
Требования к функциональности:
Почему нужно продумать архитектуру решения и структуру данных задолго до начала разработки? Это позволяет понять, насколько готовая система будет быстрой, да и вообще заработает ли этот "космический корабль". Особенно это важно, если планируете использовать сложные технологии: ML, CV, IoT, облачные вычисления. Однажды у Rubius заказали проект системы, где должны были взаимодействовать сразу 3 ML-модуля. Мы оценили набор необходимых данных, проработали архитектуру. Система была сложной, громоздкой, дорогой, а главное – что выяснилось только в предпроектном обследовании – плохо решала задачу бизнеса. В итоге от первоначальной концепции отказались в пользу более простой, но работающей.
Нефункциональные требования:
Что делать, если у заказчика нет чёткого понимания, что нужно разработать? Лучший вариант здесь – описать в техническом задании концепцию системы (назначение, основные функции), а потом детализировать требования вместе с исполнителем. Новые версии ТЗ при этом можно оформлять как дополнения к основному заданию.
По возможности в ТЗ можно добавить:
Общее описание проекта:
Требования к функциональности:
Зачем в ТЗ визуализация? Она помогает лучше понять концепт программного обеспечения. Можно на десятках страниц в красках описывать пожелания по интерфейсу. А можно приложить к ТЗ один его скетч – и он без слов донесёт, что именно хотел заказчик. То же самое с описаниями бизнес-процессов и путей пользователя: качественные BPM-схемы и User Flow заменяют собой часы объяснений. Как-то мы дорабатывали ТЗ на систему-помощника для строительной фирмы. По текстовому описанию было сложно понять, как она должна в итоге работать. Чтобы это исправить, мы сделали макеты интерфейса и User Flow. Благодаря им стало очевидно, в какой ситуации начинается путь пользователя и какую задачу человек решает с помощью ПО.
Нефункциональные требования:
Составляя техническое задание на разработку, важно помнить про баланс. Порой излишняя детализация вредит не меньше недостатка информации. В избыточном ТЗ сложнее найти несостыковки и упущения. Оно лишает заказчика возможностей адаптироваться под меняющуюся ситуацию и ограничивает разработчиков, не позволяя внедрять более подходящие под задачу решения.
Если техническое задание удовлетворяет всем 4 пунктам, можно переходить к разработке. Но помните: ТЗ – живой документ, он может и должен корректироваться по мере развития проекта.
Стоимость проекта рассчитывается индивидуально — заполните форму на сайте, и мы свяжемся с вами, чтобы подобрать оптимальное решение