Книга: Мобильное приложение как инструмент бизнеса

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

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

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

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

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

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

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

Государство позаботилось о правильности создания ТЗ, выпустив для этого соответствующие межгосударственные стандарты (ГОСТ, ОСТ). Вот только проблема в том, что они несколько устарели. Например, ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» был выпущен еще в 1989 г. Не советую использовать ГОСТ как основу для создания качественного ТЗ, хотя вы можете почерпнуть там что-то полезное.

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

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

1. Назначение, цели, задачи и результат.

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

2. Целевая аудитория.

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

3. Структура.

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

4. Макеты экранов (страниц).

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

5. Функционал.

Описать все функции: как они будут реализованы, как будут работать и зачем они нужны.

6. Дизайн.

Привести примеры понравившихся приложений, описать пожелания по оформлению.

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

Оглавление книги