Есть заказчики, требующие создать вначале договор с прикрепленным к нему ТЗ, а затем говорящими: «Только тогда мы подумаем над тем, заказывать ли у вас». Дескать, иначе они не смогут понять уровень профессионализма разработчика или сразу хотят увидеть, что он способен предложить. Частично это правда, и по ТЗ действительно можно судить о разработчике, но ТЗ не создается на коленке за несколько часов. Это сложная работа, требующая участия многих специалистов и отнимающая много времени. Разработка ТЗ должна оплачиваться, иначе оно не будет качественным. При заказе и составления ТЗ, и разработки мобильного приложения стоимость составления ТЗ будет ниже, чем для тех, кто заказывает только одно ТЗ. Это связано с затратами времени специалистов: если они тратят его как на ТЗ, так и на производство приложения, то это окупается, в отличие от написания ТЗ без продолжения работы.
Государство позаботилось о правильности создания ТЗ, выпустив для этого соответствующие межгосударственные стандарты (ГОСТ, ОСТ). Вот только проблема в том, что они несколько устарели. Например, ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» был выпущен еще в 1989 г. Не советую использовать ГОСТ как основу для создания качественного ТЗ, хотя вы можете почерпнуть там что-то полезное.
Как и договор, ТЗ в процессе работы над приложением может изменяться. Не стоит относиться к договоренностям так, будто они высечены на камне – эти времена давно прошли. Действуйте гибко. Если выгодно изменить договор, в том числе техническое задание, – меняйте. Жизнь часто вносит коррективы, и лучше вовремя приспосабливаться к происходящему.
Из-за отсутствия единых стандартов каждая компания делает ТЗ по-своему. С одной стороны, это дает невиданную гибкость, а с другой, ведет к полной неразберихе, и если заказчик захочет передать свой проект другому разработчику, то не исключено, что придется менять ТЗ. Ниже я расскажу только о самых важных частях технического задания.
1. Назначение, цели, задачи и результат.
Понятно и доступно опишите, зачем вам мобильное приложение и какие задачи оно должно решать. Обычно кратко описывают каждую большую задачу, а детализацию делают в описании подзадач.
2. Целевая аудитория.
Максимально подробно опишите будущих пользователей приложения. Многие создают собирательные образы наиболее распространенных типов пользователей, а некоторые даже описывают, как будет себя вести каждая из этих личностей, создавая так называемые user story, или истории пользователей.
3. Структура.