Как написать техническое задание на разработку мобильного приложения

Привет! С вами снова мы, разработчики мобильных приложений «Лайв Тайпинг». В этот раз мы расскажем, что такое техзадание на разработку, как его написать и можно ли сделать это самостоятельно. А ещё покажем, как делаем документацию мы. Если хотите разобраться в этом вопросе — наша статья поможет вам

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

ТЗ можно написать вообще на всё. Просите коллегу заказать обед — напишите ТЗ. Просите жену/мужа/брата/троюродную бабушку купить молоко — напишите ТЗ. Мы, конечно, утрируем и шутим, но зато так вы получите результат, который хотели: )

На разработку мобильного приложения тоже можно составить ТЗ: можно сделать это самостоятельно, можно с помощью специалистов. А можно не писать его вообще. Сейчас мы как раз и разберёмся, когда и как лучше поступить! Ну, а если ТЗ у вас уже есть, и вы ищите команду, которая сможет воплотить его в жизнь, — вы знаете, к кому обратиться.

Что в статье

• Техническое задание на разработку мобильного приложения: что это такое
• Когда нужно составлять техзадание на разработку
• Как написать ТЗ для мобильного приложения самостоятельно
• Структура технического задания на разработку
• Где искать шаблоны и примеры ТЗ на разработку
• Кто занимается созданием технического задания на разработку
• Сколько обычно стоит разработка ТЗ на мобильное приложение
• Как понять, что ТЗ написано неудачно: red flags в проектной документации
• Проектная документация в Лайв Тайпинге: что используем мы
• Главные выводы про техническое задание на разработку

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

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

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

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

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

2. Когда вы меняете подрядчиков в процессе разработки. Бывает такое сотрудничество, когда вы с подрядчиками занимаетесь разработкой без ТЗ и отлично понимаете друг друга. Но если вам вдруг придётся менять команду, то без ТЗ новым разработчикам будет сложно понять, что делать. Конечно, они в итоге разберутся, но потратят много времени (=ваших денег) на коммуникацию в процессе разработки.

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

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

Вообще, у ТЗ на разработку мобильного или веб-приложения есть стандарты качества: отечественные ГОСТы и зарубежные стандарты (например, ISO/IEC/IEEE 29148:2018). Но ими пользуются редко: зарубежные стандарты на российском рынке не прижились, а ТЗ по ГОСТу необходимо только госсектору и компаниям, которые с ним сотрудничают. У крупных корпораций могут быть свои стандарты. Все остальные же пишут ТЗ как… чувствуют)

Точных и однозначных правил написания ТЗ нет. Главное, чтобы оно выполняло основную задачу — описывало будущий проект и взаимодействие на нём. Структура ТЗ, которую мы приведём далее, вполне отвечает этим задачам.

Возможная структура ТЗ на разработку мобильного приложения

1. Введение: общая информация о проекте; цели разработки мобильного приложения.

2. Основные требования: бизнес-требования; пользовательские требования; функциональные и нефункциональные требования; требования к интерфейсу; требования к безопасности.

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

4. Архитектура приложения: описание основных модулей и компонентов; схема базы данных.

5. Дизайн и пользовательский интерфейс: описание дизайна и внешнего вида приложения; референсы; примеры интерфейсных элементов.

6. Тестирование: план тестирования приложения; описание тестовых сценариев.

7. Интеграция и релиз: планы по интеграции приложения с другими системами; план релиза и обновления приложения.

8. Поддержка и обслуживание: планы по поддержке и обновлению приложения.

9. Управление проектом: расписание работ; бюджет проекта; план приёмки работ.

10. Риски и ограничения: описание потенциальных рисков: ограничения при разработке и использовании приложения.

11. Соглашения и разрешения: лицензионные соглашения, разрешения на использование сторонних компонентов

Дополнять, развивать, уточнять эту структуру дальше можно как угодно. Лишь бы она закрывала и объясняла все важные для вас моменты.

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

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

Нам кажется, доверять интернету в этом случае = неоправданно рисковать деньгами и проектом. Скорее всего, пользуясь готовым шаблоном, вы переймёте недостатки чужого приложения и не проанализируете потребности своего. Нет, мы в вас не сомневаемся — но предупреждаем.

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

Обычно созданием технических заданий занимаются аналитики и архитекторы. Вопреки распространённому мему аналитик не тот, кто «проверяет, чтобы у всех было налито».

Аналитик — это человек, настраивающий коннект между вашим бизнесом и командой разработки. Своего рода билингвист, который может понять ваши требования на человеческом языке и переложить их на язык технический. То есть описать функционирование будущего приложения конструкциями, прочитав которые разработчики скажут: «А, это понятно! Я пошёл делать». В общем, грамотный аналитик — половина успеха будущего приложения.

Ещё созданием ТЗ могут заниматься технические писатели. Они специализируются на создании документации и могут помочь структурировать и оформить информацию в ТЗ. Если не вдаваться в подробности — технические писатели тоже аналитики. Но где же их искать?

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

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

В команде исполнителя. Ни одна крупная студия мобильной разработки не обходится без аналитического отдела. И тут аналитики работают на две стороны: с одной, они — ваши доверенные лица, которые помогают описать, что вам нужно от приложения. С другой — часть команды (часть корабля) , которая будет претворять ваш замысел в реальность. Такой «стереоподход» помогает работать на общую цель.

А ещё вы можете нанять аналитика в свой штат — такая опция тоже есть. Или взять его на аутстаф у другой команды.

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

Стоимость ТЗ в агентстве варьируется от 1500 до 2000 ₽ за час. Сколько часов на разработку ТЗ потребуется специалистам — зависит от объёма и сложности вашего проекта. Точную стоимость конкретное агентство сможет назвать только после оценки.

Стоимость ТЗ на фрилансе. На биржах фрилансеров всё тоже не очень прозрачно: часто можно встретить плашку «Цена договорная». На YouDo рекомендованная стоимость часа аналитика — 1400 ₽. Понятно, что кто-то из специалистов может поставить более низкую стоимость, а кто-то более высокую. Но тут нужно ещё потратить своё время, чтобы среди всех желающих написать ТЗ, выбрать лучшего.

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

На составление ТЗ для приложения без бэкенда уходит около 60 часов, а на сложный eCommerce можно потратить больше двухсот. А если каждый час стоит больше полутора тысяч… Не хочется платить такие деньги за документ so-so качества.

Прежде, чем пуститься в эту авантюру, лучше разобраться, как отличить качественное техзадание от некачественного. Если вы столкнулись с одним из этих «флажков», технического писателя лучше поменять (или хотя бы задуматься об этом) .

🚩 Вы не понимаете, что написано. Несмотря на то, что в ТЗ описываются сложные технические системы, текст должен быть понятным. Иногда мы жертвуем красивостью в пользу ясности, и пишем подряд одно и то же слово: «Пользователь может нажать на кнопку. После нажатия на кнопку, кнопка становится…» — не очень литературно, но однозначно.

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

🚩 Вам кажется, что автор что-то упустил. Если так, то вам скорее всего не кажется. Когда непрофессионал находит ошибку в работе профессионала, есть почти 100% вероятность, что ТЗ нужно перепроверить на более серьёзные неточности.

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

Мы так много рассказали о том, что такое ТЗ в классическом смысле, чтобы сказать, что в реальности всё может работать немного иначе. Важно — договориться. А всё остальное — только инструментарий.

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

Какие документы готовим для проектной работы мы

Функциональное задание. Самый мощный артефакт в нашей проектной документации — оно подробно описывает функции, которые доступны пользователю при работе с приложением. На его основе дизайнеры создают экраны, разработчики пишут код, а отдел QA проводит тестирование.

Архитектурные схемы. Это в прямом смысле схемы, которые иллюстрируют, как простые функции приложения группируются в более сложные и взаимодействуют друг с другом. Для них используем этот фреймворк.

Описание компонентов системы. Вспомогательный артефакт, который уточняет работу архитектурных схем — что-то вроде пояснительной записки, которую могут понять те, кто не связан с разработкой напрямую. Этот документ создаём при необходимости.

Схемы баз данных. Этот артефакт только для приложений с бэкендом. Описывает, какие данные хранятся в системе, как они устроены и как связаны между собой.

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

Спецификация API. Документ устанавливает нормы коммуникации приложения со своей серверной частью. Спецификация не нужна приложениям без бэкенда.

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

А понимать, как и когда мы сдаём работы и кто их принимает, нам и нашим клиентам помогает договор. Если тоже хотите всё понимать — приходите к нам!

Как это работает на практике

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

⏵ Для приложения Gym Record мы не делали API, схемы и пояснения к ним. Это проект, который работает без бэкенда, поэтому документы, описывающие работу с серверами, были не нужны. Тут мы обошлись только функциональным заданием.

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

⏵ При разработке приложения D-Style использовали базовый набор документов. Написали функциональное задание, технические заметки, спецификацию API, архитектурные схемы и их описания, а описание компонентов системы делать не стали: на стороне клиента не было специалистов, которым была нужна эта информация.

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

• Статья «Договор NDA, или non-disclosure agreement в ИТ: что это»
• Статья «Договор на разработку мобильного приложения»
• Статья «Что такое функциональное задание и как его написать»
• Статья «Как заполнить бриф на разработку приложения»