Как составить техническое задание на разработку ПО

В этой части нашего цикла статей про создание IT-концепции рассказываем про стандарты и шаблоны для ТЗ на разработку программного обеспечения. 

Техническое задание (ТЗ)

Сейчас мы находимся на этапе, когда определены скоуп работ и приоритетность задач проекта. Следующий шаг — определить функциональные и нефункциональные требования: 

Функциональные требования: функции продукта — что могут делать пользователи, процесс взаимодействия, интеграция с другими сервисами.

Нефункциональные требования: ограничения и свойства продукта, производительность и безопасность. 

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

Зачем нужно техническое задание

Классическая картинка, которая четко описывает отсутствие ТЗ:

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

Заказчик:

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

Команда разработки:

  • Понимает желания заказчика и детальные требования. 
  • Показывает свою компетентность и профессионализм.
  • Зарабатывает деньги (иногда составление технического задания оценивается как отдельная услуга).
  • Выполняет работу быстрее. Качественное техническое задание упрощает понимание функциональности продукта.

Кто пишет ТЗ

Это зависит от конкретного проекта и договоренностей сторон. 

Вариант 1. ТЗ разрабатывает Заказчик. 

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

Вариант 2. ТЗ разрабатывает команда разработки. 

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

Формат ТЗ

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

Основные стандарты: 

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

Структура ТЗ

Структура ТЗ включает следующие смысловые блоки:

  1. Общие сведения, термины.
  2. Назначение и цели создания системы.
  3. Характеристики объекта автоматизации.
  4. Требования к системе
    1. Функциональные
    2. Нефункциональные.
  5. Состав и содержание работ по созданию системы.
  6. Порядок контроля и приемки системы.
  7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
  8. Требования к документированию.

Наш гайд по разработке ТЗ

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

Описывайте функции подробно. Описание должно быть достаточным, чтобы после реализации можно было оценить степень выполнения функции. Излишние подробности приведут к увеличению сроков разработки ТЗ. Недостаточные подробности — к расхождению. Если функция критична с точки зрения достижения бизнес-ценности, то следует описать ее в деталях. 

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

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

Используйте модели, диаграммы, картинки. Это позволит посмотреть на требования с разных ракурсов и сделает ТЗ более читаемым. Обязательно описывайте все модели и рисунки текстом, чтобы не упустить детали, которые сложно отразить в схеме. 

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

Учитывайте концепцию развития системы и скоуп работ, чтобы при проектировании отразить масштабируемость и возможность развития системы. 

Наша опытная команда готова прийти к вам на помощь и взять функцию написания технического задания на себя. Мы всегда стараемся максимально учитывать интересы заказчика и работать в тесном взаимодействии со всеми заинтересованными сторонами.