Как техзадание помогает избежать провала

И зачем вообще нужен этот документ

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

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

Что внутри? 

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

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

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

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

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

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

• • сферу деятельности и размер компании – чтобы мы сразу понимали, с каким продуктом и для кого нам нужно будет работать

• • основное назначение ПО: систематизация документооборота, управление финансами, электронная коммерция, маркетплейс или автоматизация бизнес-процессов – выбор за Вами

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

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

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

• • конечных пользователей ПО и их примерное число: сотрудникам и клиентам компании необходимо одно, массовому пользователю — совсем другое

• • требования к безопасности проекта: работа с персональными данными, дополнительное шифрование, двухфакторная аутентификация – такие вещи мы тоже обговариваем на этапе проектирования 

• • сроки проекта, его бюджет и тип контракта: чётко установленные дедлайны и договор об оплате – неотъемлемые условия хорошей сделки 

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

Заказчик или исполнитель: кто пишет ТЗ?

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

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

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

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