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

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

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

Обычно созданием технического задания занимается аналитик — именно он налаживает взаимодействие между бизнесом и производством. Специалист подключается к проекту на старте и становится ключевым звеном между заказчиком и технической командой. Он работает с каждой из сторон, собирает и обрабатывает информацию, а затем превращает её в конкретные требования, которые служат основой для разработки. Аналитик очерчивает скоуп работ и декомпозирует всё на задачи для дизайнеров, разработчиков и тестировщиков.

Без бизнес-аналитика не обходится ни одна крупная студия мобильной разработки. Поэтому обычно такой специалист уже есть в команде исполнителя. По сути, он выполняет сразу две роли. Во-первых, выступает доверенным лицом заказчика, которое описывает, каким должен получиться продукт. А, во-вторых, является частью команды, «переводит» запросы бизнеса на технический язык и тем самым помогает претворять замысел в реальность.

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

У ТЗ на разработку приложения есть зарубежные стандарты качества и отечественные ГОСТы. Однако пользуются ими редко. ТЗ по ГОСТу обычно требуются при работе с госсектором и компаниями, которые с ним сотрудничают. В остальных случаях каждая команда самостоятельно определяет формат и структуру документа. Например, технические задания, которые мы готовим в MobileUp, включают:

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

Этот раздел помогает получить общее представление о продукте: какие бизнес-задачи будет решать приложение и чем оно будет полезно для пользователей.

Во введении указывают:

1. Общую информацию о проекте. Это помогает погрузиться в бизнес заказчика и понять особенности продукта. Например, приложение Flawery — это цветочный маркетплейс. Он собирает предложения магазинов на территории РФ и даёт возможность пользователю заказать доставку в любой из городов.

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

3. Целевую аудиторию или ЦА продукта. Эта информация нужна, чтобы лучше продумать сценарии использования приложения, учесть потребности и поведение пользователей. Например, в ходе работы над Flawery мы поняли, что люди покупают цветы очень по-разному. Казалось бы, цель у всех одна — зайти в приложение и заказать букет. Но кто-то подходит к выбору более педантично и выставляет все фильтры, а кто-то приобретает акционные предложения. Кто-то оформляет доставку, а кто-то смотрит варианты из ближайших магазинов для самовывоза.

4. Краткое перечисление основных функций, как должна работать система. Например, поиск и выбор фильтров, онлайн-оплата, доставка. Отсюда можно понять, нужна ли интеграция с CRM и другими системами.

5. Состав команды разработки. Здесь перечисляют специалистов, которые будут привлечены к работе. Это помогает заказчику понять, как формируется стоимость проекта, поскольку она складывается из рабочего времени всей команды. Обычно разработке участвуют UX/UI-дизайнеры, frontend- и backend-разработчики, QA-инженеры и менеджер проекта.

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

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

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

UX/UI-требования описывают, как должен выглядеть интерфейс приложения (UI) и каким образом пользователи будут с ним взаимодействовать (UX). В этом разделе фиксируют всё, что связано с удобством, пользовательским опытом и внешним видом продукта.

Чёткие UX/UI-требования облегчают тестирование и оценку готового продукта. Когда в ТЗ указано, что оформление заказа в приложении должно занимать не более трёх шагов, тестировщикам проще проверить, насколько приложение отвечает этим критериям.

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

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

Если при проверке тестировщик находит в приложении ошибки — он передаёт их разработчикам для исправления. После этого снова тестирует продукт. В результате получается стабильно работающее приложение, готовое к релизу.

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

Как мы упоминали ранее, каждая команда самостоятельно определяет формат и структуру ТЗ. Однако за основу нередко берут шаблон, описанный в книге «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти. Он помогает не упустить важные аспекты в работе.

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

Отсутствие пользовательских сценариев. Для разработки приложения недостаточно описать его структуру, технические характеристики и внешний вид интерфейса. Нужно выстроить логику взаимодействия пользователя и приложения: какую кнопку нажимает пользователь — какой ответ выводит приложение — результат. Для этого используют пользовательские сценарии.

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

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