Разработка технического задания: 3 варианта

Процесс разработки любого IT-решения начинается с технического задания (далее – ТЗ) и технического проекта, которые фиксируют ожидания заказчика и содержат инструкции для исполнителя.

При составлении ТЗ для программного продукта мы используем разные подходы в зависимости от особенностей проекта. Например, для крупных государственных IT-систем зачастую нужно сделать ТЗ, прописанное в соответствии с правилами ГОСТ. А для бизнес-проектов формализация не так важна – вид документа может отличаться в зависимости от используемой методологии разработки и других особенностей проекта.

В этой статье наши коллеги из направления аналитики поделятся рекомендациями по подготовке технического задания на разработку.

Чтобы требования к программному продукту любой специфики и масштаба были качественными, они должны соответствовать следующим принципам:

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

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

Техническое задание можно считать эффективным, если по итогам разработки заказчик в рамках ожидаемого бюджета и сроков получит необходимое (=соответствующее требованиям) IT-решение. 

Как разработать техническое задание для программного продукта

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

• обязательные,
• необязательные,
• повторяющиеся,
• противоречивые.

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

После согласования ТЗ передаётся команде – по нему осуществляется оценка и постановка задач команде разработки.
Готовый артефакт может иметь несколько видов в зависимости от специфики проекта и требований заказчика к документации:

• После согласования ТЗ передаётся команде – по нему осуществляется оценка и постановка задач команде разработки.
• ТЗ, оформленное в строгом соответствии с ГОСТом – для госзаказчиков, 
• универсальное ТЗ – для большинства проектов (мы применяем собственный шаблон),
• визуальное ТЗ – для проектов, где важна скорость: небольших проектов и MVP.
• Об особенностях каждого расскажем далее.

№ 1. Техническое задание для крупных государственных IT-систем

Требования, порядок создания техзадания и самой IT-системы для крупных государственных проектов определяют:

• ГОСТ 34.602–2020 «Техническое задание на создание автоматизированной системы»,
• ГОСТ 19.201-78 «Единая система программной документации. Техническое задание. Требования к содержанию и оформлению».
• Такое ТЗ определяют конкурсные процедуры по выбору подрядчика – им необходимо чётко соответствовать.

ГОСТ допускает, что техзадание может быть разработано в виде:

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

На основании ГОСТ в техническое задание необходимо включить такие разделы:

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

В каждом из пунктов предусмотрены подразделы. Также к техническому заданию можно добавить приложения, а сами разделы и подразделы при необходимости ─ расширить, объединить или удалить.

№ 2. Внутренний шаблон технического задания от SimbirSoft

Наши аналитики постоянно проходят международную сертификацию в области системного анализа CPRE (Certified Professional for Requirements Engineering) в компании IREB – мировые стандарты нашли отражение в нашей работе с клиентами и внутреннем шаблоне ТЗ. Структура такой документации соответствует не только зарубежным канонам, но и отечественному ГОСТ. 

Наш шаблон отличает обязательное краткое представление проекта в начале (мини-introduction), которое можно прочитать и осмыслить за пару часов. С его помощью исполнители смогут быстрее погрузиться в проект в первые дни и понять, что от них требуется. 
В мини-introduction мы включаем такие разделы:

• аудитория системы,
• цели разработки,
• структура IT-решения.

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

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

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

№ 3. Визуальное техническое задание, или Lite-ТЗ

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

Lite-ТЗ состоит из описательной части и изображений мобильного приложения. В документе есть:

• карта экранов и связи между ними;
• прототипы (дизайн) всех экранов;
• user story – описание того, что пользователю дают конкретные функции приложения.

В ТЗ для мобильных приложений не добавляют требования по Human Interface Guidelines для IOS и Material design для Android.

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

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

Резюмируем

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

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

В SimbirSoft мы очень гибко подходим к подготовке ТЗ, у нас есть три варианта работы с документом: на основе ГОСТ в случае государственных проектов России, внутренний шаблон для крупных и сложных решений, визуальное ТЗ для небольших мобильных приложений и простых систем. Это позволяет уже на стадии ТЗ индивидуально подходить к каждому новому проекту.

Подробнее о подготовке документации и роли IT-аналитика можете прочитать по ссылке.