Как подготовить ТЗ на разработку программного обеспечения. Часть 1.

Почему ТЗ — это важно

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

В статье я расскажу:

• почему оформлению ТЗ нужно уделить особое внимание,
• какие разделы включить в ТЗ и что в них должно быть;

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

ТЗ — это ваша гарантия

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

Первый сценарий — это работа с недобросовестным подрядчиком, когда он делает “тяп-ляп”.

Часто недобросовестные вендоры просят за разработку системы гораздо меньше всех остальных по рынку. Когда ищите разработчика, лучше забыть правило “дороже — не значит лучше”. Как раз-таки дороже — значит лучше, но и тут есть свои огрехи.

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

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

ТЗ — это фундамент вашего приложения

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

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

Всё ТЗ описывается “бизнесовым языком”, то есть, как должна вести себя система с точки зрения пользователя (о пользователях и их ролях расскажу позже). Такое описание упрощает компании разработчику его вычитку, а в дальнейшем и оценку, так как, вероятно именно бизнес-аналитик будет вычитывать ТЗ, а затем собирать оценку на выполнение задач у команды разработчиков.

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

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

В процессе разработки ТЗ часто дополняется. В какой-то момент разработчики понимают, что согласованный способ хранения данных ненадежен, невозможен или неудобен — в общем, можно сделать лучше. Однако, в ТЗ уже прописаны требования к хранению данных. Составляя ТЗ вы не учли некоторые детали, и теперь, чтобы продолжить разработку, нужно согласовывать дополнительные документы с уточнениями к ТЗ. Всё это растягивает время разработки, а значит и стоимость (если вы работаете по модели Time & Material).

ТЗ помогает лучше спланировать работу системы

Перечитывать свое ТЗ — не такая плохая идея. Даже так — это замечательная идея!
Приведу пример. Автомобильной дилерской сети нужна корпоративная система, в которой будет учитываться количество принятых автомобилей с завода с разбивкой на комплектации, количество предварительных продаж, отработанных часов автомеханика, продаж, закрепленных за менеджером и др.

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

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

Просто представьте, как часто вы опечатываетесь и ошибаетесь за день тяжелой работы. А если на ошибочных данных производится множество важных расчетов в системе, а ошибка не была вовремя замечена — это может стать для вас огромной проблемой.

В случае с примером, отсутствие возможности корректировать введенные данные — это существенный недостаток в системе, а виной всему — непроработанное ТЗ.

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

Если вы работаете по модели Time & Material (почасовая ставка), помните пословицу “Время — деньги”, а вместе с ней запомните — “Рассеянный делает одну работу дважды”.

ТЗ позволяет сокращать расходы

Представьте, что на разработку приложения выделено 5 миллионов. Вы присылаете ТЗ некоторому количество разработчиков и получаете оценку в 7-8 миллионов.

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

У вас есть 5 миллионов и точка, а система очень нужна. С проработанным ТЗ вы можете поступить следующим образом: самостоятельно, или обратившись к разработчику убрать требования к функциональности, которые не будут мешать основному назначению и целям системы. Назначение и цели системы прописываются в ТЗ. Об этом расскажу чуть позже.

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

Обязательно ли делать ТЗ своими силами

Как сказал Майкл Францезе: “Делайте то, что у вас лучше всего получается, а остальное перепоручите соответствующим специалистам.”

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

Практически любая аутсорсинговая компания разработчик может разработать за вас ТЗ. Конечно, в 9 из 10 случаев за это придется заплатить. Зато вы получите отличное, полное техническое задание! Более того, вы можете не обращаться к тому же подрядчику за разработкой, а начать исследования рынка и найти того вендора, который вам понравится.
В дальнейшем, если возникнут новые задачи на разработку, вы сделаете новое ТЗ по шаблону старого. Это очень удобно, не правда ли?

Как должно выглядеть ТЗ

Обратите внимание, что мы описываем структуру ТЗ по нашему шаблону. Наше ТЗ — гибрид из стандарта по ГОСТу и собственных предпочтений. Можно сказать, что этот шаблон — тот документ, который мы видим у “идеального” заказчика. По нашему мнению, такая структура ТЗ максимально удобна для описания системы, и поверьте, технических заданий за 10 лет работы мы видели не малое количество…

Документ состоит из основных разделов:

• общие сведения,
• назначение и цели создания,
• требования к системе в целом,
• функциональные требования,
• виды, состав, объем и методы испытаний системы,
• общие требования к приёмке,
• статус приемочной комиссии;

Раздел Общие сведения

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

Добавьте в раздел сроки начала и окончания работ. Вообще, я бы порекомендовал вам разбить всю разработку на этапы и для каждого этапа написать свои сроки. Поделив реализацию на этапы, вы сможете наблюдать за процессом разработки, и если вдруг какой-то этап провалится по срокам, тогда у вас получится оперативно среагировать (узнать почему так случилось, что нужно сделать, чтобы нагнать сроки и следующий этап сдать вовремя).

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

1. Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем ТЗ.
2. Все неоднозначности, выявленные в настоящем ТЗ после его подписания, подлежат двухстороннему согласованию между Заказчиком и Исполнителем

Резюмируем. Добавьте:

1. Реквизиты исполнителя и заказчика.
2. Сроки начала и окончания проекта (вплоть до разбивки по этапам).
3. Опишите требования, которые не касаются разработки приложения.

Цели и назначение проекта.

Помните, это то, о чём мы ранее говорили в разделе “ТЗ позволяет сокращать расходы”? Так вот, цель проекта — это основная причина, почему вам нужно разработать приложение, и примерно, что оно будет из себя представлять.

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

После прочтения цели мы понимаем, зачем вам нужна кастомная разработка (в данном случае нужно автоматизировать бизнес-процессы), и, если вы укажите “прототип” того, что нравится — это упростит дальнейшую разработку.

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

Что такое назначение? Назначение заключается в том, как будет использоваться продукт.

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

Резюмируем.

• Цель — это то, зачем нужен проект и какую роль он будет выполнять.
• Назначение — это то, как потом мы будем его использовать.

Продолжение