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