summary-header

Статья. Техническое задание в IT: код для кода

Рассказываем в деталях, что такое техническое задание на разработку, из чего оно состоит, и почему нельзя просто взять и начать пилить код.

Статья пригодится заказчикам программного обеспечения на начальном этапе проекта: менеджерам, стартаперам и бизнес-аналитикам. Особенно она будет полезна тем, кто делает техническое задание впервые и хочет избежать типовых ошибок. 

Что такое техническое задание

Техническое задание (ТЗ) – это документ, который детально описывает функции, требования, характеристики и пользовательские сценарии программного обеспечения. Также в нём фиксируют необходимый объём работ, их порядок и критерии приёмки. Если совсем просто, ТЗ – это инструкция для команды разработки: что нужно сделать и как это должно в итоге функционировать. 

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

В чём риски работы с плохим ТЗ или без него

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

ТЗ vs реальность
ТЗ vs реальность

Поверхностное ТЗ лучше его полного отсутствия, но от проблем тоже не избавит. Разработчикам придётся часто уточнять детали, что значительно увеличит время и стоимость разработки. 

Ошибка 1. Неполное ТЗ
Ошибка 1. Неполное ТЗ

Но даже круглосуточная связь с заказчиком при отсутствии чёткого ТЗ не гарантирует идеальное качество. Поэтому к составлению технического задания нужно подходить серьёзно и воспринимать его как фундамент для всего проекта. 

Ошибка 2. Нет важных разделов
Ошибка 2. Нет важных разделов

Кто составляет техническое задание

Составить техническое задание может как заказчик ПО, так и его разработчик. 

В основном этим занимаются бизнес-аналитики. Они собирают требования к проекту, определяют его цели и превращают всё это в понятные и структурированные спецификации.

Лайфхак: дайте почитать готовое ТЗ человеку, который не участвовал в его разработке. После задайте вопросы по содержанию – если он понимает смысл так же, как и вы, значит, формулировки в ТЗ однозначные и понятные.

Из практики Rubius

Из практики Rubius

Проектный офис

В крупных проектах, особенно для участия в тендере, для разработки технического задания собирается целая команда. Менеджеры координируют работу над ТЗ, оценивают временные рамки и необходимые ресурсы. Разработчики, архитекторы и системные аналитики продумывают технические детали и выявляют ограничения, чтобы адаптировать требования к реальным условиям. 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-модуля. Мы оценили набор необходимых данных, проработали архитектуру. Система была сложной, громоздкой, дорогой, а главное – что выяснилось только в предпроектном обследовании – плохо решала задачу бизнеса. В итоге от первоначальной концепции отказались в пользу более простой, но работающей.

Из практики Rubius

Из практики Rubius

Проектный офис

Нефункциональные требования: 

  • Требования к техническому обеспечению, инфраструктуре и компонентам: характеристики серверов, ПК, систем хранения данных  
  • Требования к информационному обеспечению: используемые ОС, среды, СУБД, браузеры и т.д.

Что делать, если у заказчика нет чёткого понимания, что нужно разработать? Лучший вариант здесь – описать в техническом задании концепцию системы (назначение, основные функции), а потом детализировать требования вместе с исполнителем. Новые версии ТЗ при этом можно оформлять как дополнения к основному заданию. 

Дополнительная информация в ТЗ

По возможности в ТЗ можно добавить: 

Общее описание проекта: 

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

Требования к функциональности: 

  • Логическая структура данных
  • Ролевая модель пользователей
  • Результаты продуктовых исследований (CustDev) в случае разработки нового продукта 
  • Примеры решений-аналогов
  • Визуализация: дизайн-исследования, прототипы или макеты интерфейса, User Flow 

Зачем в ТЗ визуализация? Она помогает лучше понять концепт программного обеспечения. Можно на десятках страниц в красках описывать пожелания по интерфейсу. А можно приложить к ТЗ один его скетч – и он без слов донесёт, что именно хотел заказчик. То же самое с описаниями бизнес-процессов и путей пользователя: качественные BPM-схемы и User Flow заменяют собой часы объяснений. Как-то мы дорабатывали ТЗ на систему-помощника для строительной фирмы. По текстовому описанию было сложно понять, как она должна в итоге работать. Чтобы это исправить, мы сделали макеты интерфейса и User Flow. Благодаря им стало очевидно, в какой ситуации начинается путь пользователя и какую задачу человек решает с помощью ПО.

Из практики Rubius

Из практики Rubius

Проектный офис

Нефункциональные требования: 

  • Технологический стек: используемые языки программирования, фреймворки, библиотеки
  • Требования к производительности, надёжности, безопасности и защите данных 

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

Чек-лист: как понять, что ТЗ готово

Чек-лист готовности ТЗ

Если техническое задание удовлетворяет всем 4 пунктам, можно переходить к разработке. Но помните: ТЗ – живой документ, он может и должен корректироваться по мере развития проекта. 

Давайте обсудим ваш проект

Мы будем рады ответить на ваши вопросы



Нажимая на кнопку "Оставить заявку", вы даёте согласие на обработку персональных данных и соглашаетесь с политикой конфиденциальности

Позвоните нам

Напишите нам