Разработка мобильного приложения документация
Любое качественное мобильное приложение начинается с технического задания. Но далеко не каждый заказчик сможет самостоятельно составить его для команды разработчиков — необходимо понимание процессов создания такого продукта.
Кто тогда пишет техническое задание для приложения, что учитывает при написании и какие задачи решает с его помощью — рассказываем в этой статье.
Техническое задание (ТЗ) — это важный документ с подробным описанием требований к будущему приложению. Внутри него прописаны специфика и детали работы, на которые команда опирается при создании продукта. Также в этом документе прописываются сроки работы и порядок оплаты.
ТЗ на мобильную разработку — это руководство для разработчиков, дизайнеров, маркетолога и всей команды в целом, которое понятным языком объясняет каждому из участников, какое приложение вы хотите получить. Также ТЗ поможет понять, сколько будет стоить разработка вашего приложения, из чего складывается эта стоимость и сколько команде потребуется времени на работу.
Итак, кто же пишет ТЗ? Обычно, написанием такого документа занимаются несколько человек: сам заказчик и эксперты компании по разработке мобильных приложений. Давайте рассмотрим роль каждого в этом процессе:
Вы четко понимаете, зачем вам это приложение, для кого оно разрабатывается и как будет выглядеть. Если вы уже промониторили рынок на наличие конкурентов и выявили особенности их продуктов — это будет большим плюсов как для вас, так и для команды, потому что позволит грамотно формировать преимущества будущего приложения. Далее, со всей этой информацией, вы идете к команде экспертов, которые уже детально разбирают вашу идею.
Команда специалистов внимательно изучает запрос, всю собранную вами информацию и берется за профессиональное описание ТЗ. Кто участвует в работе?
- Маркетолог. Он занимается анализом рынка и спросом на подобные приложения, описывает цели и позиционирование платформы, работает с вашей потенциальной аудиторией: определяет ее целевые потребности, желания и отражает это в ТЗ. Такая информация помогает остальной команде понять, каким должен быть продукт, чтобы он был востребован среди потребителей. Некоторые компании предлагают услуги своего маркетолога, но большинство других, в том числе мы, используем информацию вашего специалиста.
- UI/UX Дизайнер. Разрабатывает дизайн интерфейсов с учетом логичного и понятного пользовательского опыта. То есть его главная задача, сделать приложение не только современным и приятным глазу, но и максимально удобным в использовании.
- Разработчик. Занимается технической частью проекта — пишет код, оптимизирует внутреннюю и серверную часть приложения, запускает продукт на рынок, при необходимости поддерживает его и добавляет необходимые функции. Разработчики лучше всех понимают, что необходимо вашему продукту для безупречной работы.
- Бизнес / Системный аналитик — всю информацию, которую аналитик получает от специалистов, он прописывает на простом и доступном языке в ТЗ. Его главная задача — донести до каждого из команды суть, идею и процесс создания будущего продукта.
Итак, КТО пишет ТЗ мы с вами разобрали, сейчас давайте рассмотрим, КАК его создают. Для примера возьмем структуру ТЗ, которую составляет наша команда LeanTech:
Информация о запросе. Тут мы прописываем идею будущего приложения, причину его создания и целевую аудиторию, на которую будет рассчитан продукт, указываем принцип его работы.
План работы. Прописываем сроки создания ТЗ, кто участвует в команде разработки и какие задачи будет выполнять. Расписываем подробно по неделям, что будет сделано и кем.
Коммерческое предложение. Презентуем смету, в которой прописана стоимость работы. При необходимости разрабатываем несколько вариантов.
Техническая поддержка. Здесь пишем о том, какие есть варианты технической поддержки после запуска приложения, какие могут возникнуть ситуации, как и насколько быстро мы их решаем.
Составление ТЗ — это полноценная работа разных специалистов, которые подробно прописывают задачи и их решения внутри одного документа. Наш аналитик переведет сложные термины разработчиков в конкретные задачи для каждого из команды — так специалисты будут точно понимать, что им нужно делать, а менеджер проекта всегда будет связующим звеном между вами и командой LeanTech от составления технического задания до разработки мобильного приложения. Чтобы узнать точные сроки составления ТЗ и разработки вашего мобильного приложения, свяжитесь с нашим специалистом — мы подробно разберем вашу идею, составим план, смету и дадим обратную связь.
У технического задания, как и у любого другого документа, есть свои стандарты качества, так называемый ГОСТ. Можно ли создать грамотное ТЗ по этому образцу, чтобы приложение получилось таким, каким вы хотите его получить? Рассказываем.
ГОСТ — это юридический документ, описывающий всю работу программного обеспечения по государственным стандартам. Обычно таким образцом пользуются структуры и учреждения, которые работают в госсекторе и имеют свои обязательные стандарты качества. Документ состоит из строгих требований к содержанию и оформлению, имеет структуру из нескольких разделов и не терпит поправок. Работать по такому документу тяжело, особенно если компания видит ваш проект с точки зрения гибкой системы разработки.
Большинство компаний по разработке мобильных приложений не используют жесткие рамки в создании технической документации, если этого не требует ваша сфера деятельности. В основном, студия составляет индивидуальное ТЗ по вашему проекту и лишь придерживается стандартной и понятной всем структуры — вводная часть, основная и заключительная.
Отвечая на вопрос, можно ли создать хорошее ТЗ по ГОСТу, скажем так — можно, если нет другого варианта. Дело в том, что гост довольно объемный документ и зачастую содержит информацию, которая затрудняет поиск нужных данных для разработки. Процесс затягивается, а команда теряет время. Однако такой документ удобно проверять, так как пишется он всегда одинаково.
Именно поэтому, мы не советуем использовать готовые шаблонные решения, которых много в интернете — они создавались под другие проекты и не смогут выгодно представить команде конкретно ваш проект. Там может быть акцент совершенно на другие задачи и цели, а ваши преимущества останутся незамеченными. То же касается и брифов — если вы заполняли анкеты в одной компании и хотите узнать сроки и стоимость в другой, расскажите о своем продукте заново. Не отправляйте одну и ту же анкету разным разработчикам — каждая студия работает по-своему и индивидуально. Те данные, что вы оставили в брифе для одной компании, могут оказаться недостаточно информативными для другой и менеджер все равно будет созваниваться с вами для уточнения. Отнеситесь к выбору команды ответственно и заложите время для общения с каждым потенциальным разработчиком.