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

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

ТЗ по ГОСТу: поможет ли оно сделать классное приложение

У ТЗ на разработку мобильного приложения или веб-сервиса есть стандарты качества: отечественные ГОСТы и зарубежные SRS (software requirements specification). У SRS более разветвлённая структура: его содержание похоже на реферат с введением, главами, подглавами и заключением. Но и в том и в том стандарте есть общие смысловые
части:

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

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

Поскольку в законодательстве нет жёстких требований к проектной документации, студии мобильной разработки «настраивают» ТЗ под себя. Некоторые продолжают писать по ГОСТу — такой документ удобнее проверять: вы открываете
стандарт, открываете техзадание и сверяете разделы. Ну, а больше плюсов мы не нашли. Из минусов:

1. Гостовский документ кажется нам слишком громоздким. В нём сложно ориентироваться. Если вы приходите за конкретной информацией и не знаете, где её искать, вам придётся изучить весь документ. На листание
   страниц уходит время, которое можно было потратить на завершение других задач.
2. ТЗ по ГОСТу не подходит для сотрудничества по Agile. Стандарт, написанный в конце
   80-х, не знает, что проектная разработка может идти спринтами. Приложение разрабатывается поэтапно.
   У каждого спринта — своя документация, поэтому монументальное ТЗ будет не к месту.

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

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

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

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

Проблема любых больших документов, особенно аналитических, в том, что их сложно читать как клиентам, так и самим разработчикам, поэтому мы не пропагандируем ТЗ по определённым форматам, будь то ГОСТ или зарубежные
стандарты. Я за то, чтобы делать ТЗ под конкретный проект. Более того, я сторонник подхода «меньше текста без ущерба смыслу — лучше». Если можно обойтись без документа и заменить его на изображения или схемы,
тем самым сократив объём, то лучше сделать именно так.

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

Как понять, что вы попали к плохому аналитику

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

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

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

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

Сколько стоит техническое задание

В масштабах общей стоимости приложения цена, которую клиент платит за ТЗ, небольшая. Час работы техписателя оценивается в 1500–2000 рублей. На простое
приложение без бэкенда уходит 60 часов, а на сложный eCommerce можно потратить больше двухсот. Но экономить на ТЗ нельзя. В мобильной разработке оно выполняет ту же роль, что и чертёж в строительстве дома: одна неправильная линия и всё может рухнуть. Поэтому вкладываться нужно с самого начала. Компании IBM выяснила:
если вы найдёте ошибку на ранних этапах разработки, исправить её будет дешевле.

Зависимость стоимости ошибок от этапов, на которых они выявлены

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

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

— Иван Леонтьев,
Android-разработчик «Лайв Тайпинга»

Можно ли скачать готовый шаблон ТЗ 

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

Техническое задание без ошибок, воды, повторов — наш подход к проектной документации

Главная задача ТЗ — описать, что должно быть сделано: понятно, наглядно и ёмко, а формат не имеет значения. В «Лайв Тайпинге» документы создаются не ради документов, а для того, чтобы привести проект клиента к успеху.
Мы отказались от многостраничного ТЗ в пользу артефактов — лаконичных документов, которые решают точечные задачи. Набор артефактов, из которых сложится техническое задание, зависит от размера и целей вашего
проекта. Мы определим его вместе на этапе знакомства и оценки.

Из чего может состоять проектная документация в «Лайв Тайпинге»:

1. Функциональное задание

Функциональное задание (ФЗ) — самый мощный артефакт в нашей проектной документации. К нему обращаются на каждом этапе разработки
от прототипирования до релиза. На его основе дизайнеры создают экраны, разработчики пишут код, а отдел QA проводит тестирование. И при этом у него нет ни одного магического свойства. Сила ФЗ в том,
что оно подробно описывает функции, которые доступны пользователю при работе с приложением. На интервью с клиентом мы узнаём, какие ролевые модели (администратор, модератор, простой пользователь) предусмотрены в приложении,
и описываем набор функций для каждой роли: куда пользователь может пойти, что сделать и какой результат его ждёт. Пока мы с клиентом готовим этот артефакт, дизайнеры делают прототипы экранов, которые соответствуют возможностям
приложения, прописанным в ФЗ. Готовый документ проверяют разработчики.

На этапе проектирования я читаю готовое ФЗ минимум два раза. Первый — целиком, ни на чём не останавливаясь, чтобы у меня сложилось общее впечатление о работе приложения. Затем я начинаю читать ФЗ на второй раз, более вдумчиво и критически. Это позволяет мне: 1) задать вопросы, которые
меня интересуют, чтобы проверить документ на ошибки; 2) дополнить конкретные моменты в приложении исходя из своего опыта; 3) дать более точную оценку проекту.

— Павел Разуваев, iOS-разработчик «Лайв Тайпинга»

Содержание функционального задания

Изображения

2. Функциональные схемы

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

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

3. Описание компонентов системы

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

4. Технические заметки

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

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

— Андрей Дёмин,
Android-разработчик «Лайв Тайпинга»

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

5. Спецификация API (application programming interface)

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

6. Карта рисков

Мы составляем карту рисков для того, чтобы показать клиенту опасные места в проекте: размытые задачи и интеграции, с которыми мы ещё не работали. Почему это важно? Есть задачи, выполнение которых нельзя точно оценить в процессе
проектирования. Если мы не скажем об этом клиенту, у него сложатся неверные ожидания по срокам и стоимости проекта. Артефакт получает одну комету, потому что такие задачи в нашей практике появляются редко.

7. Документация на фичу

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

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

Как «Лайв Тайпинг» сокращает затраты клиента на документацию

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

• Gym Record — лёгкий и удобный дневник для записи тренировок. Клиенту не нужна была сложная
  авторизация, поэтому мы сделали приложение без серверной части. Таким проектам не требуются документы, которые описывают работу с сервером — API, схемы и пояснения к ним. Основной упор в приложении сделан
  на дизайне, который отталкивается от функциональности. Поэтому для нашего клиента мы сделали только функциональное задание, в котором прописали особенности UX и UI.
  На создание документа мы потратили 20 часов — суммарно 2–2,5 рабочих дня.

• Justfood — сервис по доставке готовых блюд для тех, кто следит за фигурой. Проект пришёл к нам на поддержку со своей документацией. Она помогла нашим разработчикам понять принцип работы приложения.
  Но чтобы вносить изменения, нам потребовалось сделать документацию на фичи, которые мы добавляли. В артефакте мы прописали шесть новых фичей и к каждой указали функциональные, технические требования
  и ограничения. Например, «Автопродление подписки» выглядит так: 1) пользователь применят продление и получает скиду — это функциональное требование; 2) при применении промокода скидки не суммируются — это ограничение;
  3) карта клиента сохраняется в приложении с помощью дополнительных параметров метода оплаты — это техническое требование. Разобраться в документах клиента и создать новый артефакт — 24 часа, или 3 дня.

• D-Style — приложение для одноимённого московского магазина одежды. Набор документации для eCommerce однотипен: функциональное задание, технические заметки, спецификация API, функциональные схемы и их описания.
  Исключение — крупные ретейлеры, которые сами готовят документацию. Для
  D-Style мы не делаем описание компонентов системы: на стороне клиента нет людей, которым пригодится эта информация. Поэтому мы не видим смысла тратить деньги и время клиента на артефакт, который не приносит
  пользы. Сейчас для
  D-Style мы пишем технические заметки — как только закончим, здесь появится время, которое мы потратили на документацию для этого проекта.

Вы уже придумали концепцию для мобильного приложения? Можете составить для него полезную проектную документацию по нашему методу. А если вам потребуется помощь — свяжитесь с нами или позвоните
+7 495 204-35-03. Мы вместе разберёмся в деталях, определим какие артефакты нужны вашему проекту и превратим его в героя Меча и Магии.

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

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

---

Этапы разработки технического задания для приложения

Разработчик технического задания должен учитывать следующие этапы:

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

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

Важно ориентироваться на успешные проекты, которые «выстрелили». Не рекомендуется брать во внимание «прогоревшие» приложения.

---

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

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

• Конкретика. Если у заказчика есть требование к цветовой гамме, об этом нужно четко прописать в инструкции. «Белый фон, синие иконки» — это общие слова без конкретики. Можно указать определенные параметры RGB или HEX-код цвета. Если есть требование к шрифту — это не «Классический шрифт среднего размера», а точное название — «Arial 14 pt».

• Разделение полномочий. Каждый специалист должен заниматься своим делом. Дизайнер отвечает за интерфейс приложений, программист за создание кода. Нельзя перекладывать обязанности друг на друга — тогда финальный продукт получится некачественным.
• Факты вместо оценок. Слова «полезно», «красиво», «круто» не несут конкретики. У каждого человека свои понятия и оценки, поэтому не стоит разрабатывать мобильное приложение с таким техническим заданием.

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

---

Как понять, что клиент попал к плохому аналитику

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

Следует насторожиться в следующих случаях:

• Исполнитель не понимает, что написано в инструкции. Подробное руководство может состоять из множества технических моментов, но при этом текст должен быть читаемым и понятным. Профессиональные аналитики жертвуют терминами и красивостью в пользу ясности. В этих случаях допустима тавтология. Например: «Пользователь нажимает на кнопку». «После нажатия на кнопку он переходит в раздел «Фильмы»». Смотрится не очень привлекательно, зато исполнитель поймет задачу.

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

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

---

Сколько стоит техническое задание

Один час работы технического писателя оценивается в 1 500 — 2 000 рублей. Написание руководства для простого приложения занимает около 60 часов, а на сложный eCommerce отводится более 200 часов.

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

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

---

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

Одному сложно составить подробное руководство. Клиент может хорошо объяснить идею для бизнеса, однако перевести ее в терминологию IT — это другой вопрос, требующий навыков и определенной подготовки. Узконаправленные писатели и аналитики помогают клиенту на техническом языке сформулировать его ожидания и закрепляют это в документе.

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

Если в каких-то моментах можно обойтись без текста, лучше использовать изображения или схемы для наглядности. Объем сократится, а задание станет понятнее.

---

Чем отличается профессиональное техническое задание от обычного

Грамотное техническое задание требует опыта и знаний. Рассмотрим главные отличия инструкции, составленной новичком и профессионалом.

Обычное техническое задание

Можно прочитать несколько статей о том, как правильно составить техническое задание. В большинстве случаев такая инструкция будет бесполезной, так как она не отразит всех требований к продукту.

В каких случаях заказчик может создать техническое задание самостоятельно:

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

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

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

Профессиональное техническое задание

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

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

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

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

---

Из чего еще может состоять техническое задание

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

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

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

• Технические заметки. Здесь описываются места, которые кажутся разработчикам самыми сложными и рискованными, требующими отдельного внимания (например, алгоритмы, расчеты, интеграции с сервисами).
• Карта рисков. Она используется для того, чтобы показать клиенту опасные места в проекте — например, сложные интеграции. Это важный момент, так как в процессе проектирования есть задачи, выполнение которых нельзя оценить при создании приложения. Если не сообщить клиенту об этой информации, то стоимость проекта может возрасти, а срок запуска программы — передвинуться на позднюю дату.

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

---

Пример технического задания на разработку мобильного приложения «Эвдик»

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

Целевая аудитория — люди любого возраста, которые поставили цель выучить эвенкийский язык (или ознакомиться с ним).

Приложение состоит из следующих разделов:

• Словарь. Здесь представлены слова на русском языке и их перевод на эвенкийский.
• Разговорник. Доступно несколько подразделов с разговорными темами, включающие в себя фразы на русском языке и эвенкийском (есть отдельная звуковая дорожка).
• Условные обозначения. В разделе указаны сокращенные обозначения слов и фраз с их полной расшифровкой.

«О программе» — информационный раздел, где пользователь может почитать общие сведения о приложении. При желании — поделиться им в социальных сетях.

Основной экран

На основном экране пользователь работает со словарем. Как работает раздел:

1. Наверху представлены название раздела и поиск. В области содержимого находятся слова на русском языке и их перевод на эвенкийский.

1. Когда пользователь нажимает на иконку в виде лупы (находится в правом нижнем углу), появляется поле ввода. Слова можно вводить на русском языке.

1. Если юзер ввел данные неправильно, система сообщит о некорректном вводе. «Не найдены слова, начинающихся на здравствуйте».

Посмотрим на работу других разделов.

Условные обозначения

На экране «условные обозначения» представлен сокращенный вариант обозначения слов и фраз.

О программе

В верхней части экрана находится раздел «О программе» и кнопка возврата в меню.

Здесь пользователю представлена следующая информация:

• общие сведения о программе (разработчик, сайт, версия, количество переводов в словаре, количество фраз в разговорнике, электронная почта);
• изображение иконки приложения;
• кнопка «Поделиться с друзьями».

При нажатии на кнопку цвет интерфейса меняется с серого на голубой. Пользователю предлагается на выбор несколько вариантов пересылки информации: через Bluetooth, email, gmail, Google, Google Keep и SMS/MMS.

Панель навигации

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

Виджеты

Пользователь может добавить виджеты разделов «Словарь» и «Разговорник» на рабочий стол.

• Виджет словаря. Здесь представлены слова и их сочетания на русском языке с переводом на эвенкийский. Когда юзер кликает на кнопку «Назад», он переходит к предыдущему слову. Чтобы перейти дальше, необходимо нажать на «Вперед».

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

Дополнительные требования к разработке

Несколько требований заказчика к разработке мобильного приложения:

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

• Операционная система и устройства. Программа должна работать на операционной системе Android версии 2.3 и выше.
• Язык программирования — Java.

Команда разработчиков успешно справилась с техническим заданием заказчика и качественно выполнила работу.

---

Шесть советов по написанию технического задания

Создание правильного технического задания формируется из следующих элементов:

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

• Примеры конкурентов. В техническом задании необходимо прикрепить ссылки на похожие проекты с дополнительным описанием. Разработчик сможет внимательно посмотреть удачные примеры и использовать «фишки» в новом проекте.

• Расписать сценарий использования продукта. Сценарий необходим для понимания принципа работы продукта. Если специалист разрабатывает IT-приложение, необходимо задать вопрос: «Как будет вести себя пользователь?»
• История правок. Перед составлением технической инструкции необходимо создать таблицу со столбцами «дата», «описание», «автор». В каждую графу нужно записывать любые изменения. Это поможет понять, на каком этапе работы возникли противоречия.

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

• Описать требования к проверке проекта. Во время составления технического задания необходимо продумать список критериев, по которым заказчик будет проверять степень успешности реализованного проекта.

Применив шесть советов на практике, пользователь создаст грамотное техническое задание.

Вывод

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

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

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

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

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

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

Вопросы, с которых начинается ТЗ на разработку приложения (пример)

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

Готовые ответы на следующие вопросы упростят и ускорят составление технического задания.

Каким заказчик видит свое приложение? 

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

Какова специфика программы? 

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

Будет ли выгода от запуска сервиса? 

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

Каким бюджетом располагает заказчик? 

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

Какую платформу выбрать?

Android — более массовая платформа, устройства и приложения для нее дешевле. Доля аудитории iOS ниже, однако она более платежеспособна. Если сервис подразумевает массовость, имеет смысл готовить техническое задание на разработку приложения для нескольких платформ или же воспользоваться кроссплатформенными решениями.

Кто будет отвечать за внедрение, релиз и отладку?

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

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

Как написать ТЗ для мобильного приложения

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

• Конкретика во всём: у шрифтов есть названия, у цвета — коды, у форм и элементов — размеры.
• Четкое разделение полномочий: участие и ответственность исполнителя и заказчика строго регламентированы.
• Нет субъективных оценок, только факты: «красиво» и «полезно» — субъективно. Оперируя в техзадании подобными терминами, стороны рискуют качеством процессов.

Учесть все нюансы не получится даже в самом совершенном ТЗ, а останавливать работу для обсуждения каждой мелочи — контрпродуктивно. Проблему решает Agile-подход, который позволяет вносить изменения в ТЗ по ходу разработки.

Кто пишет ТЗ?

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

Заказчик

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

Когда заказчик может составить этот документ самостоятельно:

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

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

Эксперты

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

• Маркетологи находят целевую аудиторию (ЦА), определяют ее мотивы и вносят в ТЗ рекомендации, подсказывающие остальным специалистам, каким должен быть продукт, чтобы отвечать ожиданиям потребителей и быть востребованным.
• Разработчики отвечают за технические компоненты: код, оптимизацию внутренней и серверной частей программы. Они лучше других понимают особенности, которые помогут приложению работать стабильно и быстро.
• Дизайнеры вносят предложения по визуальному представлению ПО. Здесь важно учитывать не только модные тренды в оформлении, но и удобство пользовательского интерфейса.
• Технический писатель обрабатывает информацию, собранную другими специалистами, грамотно компилирует ее и переводит на общедоступный язык, понятный всем участникам проекта.

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

Структура ТЗ для приложения

В техническом задании для разработки приложения можно выделить следующую структуру: 

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

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

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

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

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

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

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

Вывод

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

Правильное техническое задание помогает:

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

От ТЗ на разработку зависит управление проектом: либо он контролируется, либо процесс протекает стихийно.

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

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

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

Вопросы, с которых начинается ТЗ на разработку приложения (пример)

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

Ответы клиента на следующие вопросы помогут сторонам лучше понять друг друга и станут основой для структуры техзадания.

Каким он видит приложение?

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

Какова специфика программы?

Для чего клиенту приложение? Если при помощи мобильного ПО предприятие планирует автоматизировать внутренние бизнес-процессы — это один масштаб, если же цель программы — охват внешней аудитории, другой. Специализация определяет потребность в ресурсах на проект, это время и деньги.

Ожидаемая выгода от запуска сервиса?

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

Каким бюджетом располагает заказчик?

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

Какую платформу выбрать?

С точки зрения массовости и ценовой доступности приложения на платформе Android более эффективны, чем ПО в сегменте iOS. С другой стороны, ограниченная аудитория владельцев премиум-устройств, более состоятельна. Если в маркетинговой стратегии будущего сервиса ставка делается на масштаб аудитории, возможно, стоит подготовить техническое задание на разработку приложения для проекта с несколькими платформами, либо обратить внимание на кроссплатформенные решения.

Кто будет отвечать за внедрение, релиз и отладку?

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

Как написать ТЗ для мобильного приложения

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

Тем не менее качественная техническая документация имеет несколько вполне очевидных критериев:

1. конкретика — все процессы и элементы описаны максимально подробно с использованием чисел;
2. разделение обязанностей — участие и ответственность сторон заранее определены, ясно изложены и зафиксированы;
3. объективность — в ТЗ нет персональных оценок и описаний — «красиво» и «эффективно», но есть факты и общепринятая проф. терминология.

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

Кто составляет ТЗ?

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

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

Поэтому наиболее оптимальным вариантом является написание ТЗ совместно. Взаимодействие заказчика и команды разработчиков наиболее точно поможет зафиксировать требования к продукту.

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

Специалисты, участвующие в составлении техзадания:

1. маркетологи — проводят анализ ЦА приложения, определяют их боли и потребности;
2. программисты — отвечают за проектирование, разработку, внедрение и поддержку мобильного ПО;
3. дизайнеры — создают интерфейс приложения, совмещая визуальные тренды с эффективным юзабилити;
4. авторы — обрабатывают и компилируют данные, облекая, собранную у технических специалистов информацию, в лаконичную, доступную для понимания форму.

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

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

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

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

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

Данное решение наиболее комфортно, так как обещает слаженную командную работу, главное достоинство которой — отработанный алгоритм реакции на возникающие возможности, вызовы и риски при создании нового продукта.

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

Схема построения ТЗ для приложения

В техзадании для реализации приложения выделяют определенную структуру:

1. Общие положения. Сюда входят глоссарий, а еще — прописывают цели и задачи будущего приложения.
2. Состав и содержание работ. В этом пункте затрагиваются страницы приложения, демонстрируются прототипы и пользовательские сценарии, архитектура баз данных, описание логики работы приложения.
3. Требования к системе. Здесь описывают технические принципы приложения. Например, требования к хостингу, конфиденциальности данных, требования к техническим характеристикам девайса пользователя.

Вывод

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

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

1. увеличивает шансы создания ПО, в максимальном соответствии с задачами клиента;
2. готовит объективный прогноз сроков и бюджета проекта;
3. сводит к минимуму риск споров между исполнителем и заказчиком из-за разницы в понимании задач и противоречий в методах их решений;
4. снижает вероятность переделок проекта из-за некорректно зафиксированных требований.

Оригинал статьи: https://sibdev.pro/blog/articles/kak-napisat-tz-dlya-mobilnogo-prilozheniya

Ликбез по техническому заданию

Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.

Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).

Время чтения: 7 минут.

Отправная точка — требования

Хочу пирожное, потом морожное!
Вовка в тридевятом царстве

Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.

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

Жутко правда? Бюджет уже потрачен и срок истек.

Чтобы такого не произошло все требования к продукту фиксируют, это и есть то, с чего начинается любая разработка.

Удобный вид требований — ТЗ

Замесить и нарубить!
Вовка в тридевятом царстве

Хорошо. Будут требования. Теперь вас точно поймут разработчики. Но тут возникает подводный камень №1: человечество пока не научилось читать мысли. Поэтому нужно в каком-то виде передать информацию и лучший для этого способ — Техническое задание.

Его также называют ТЗ, SRS, PRD — все это названия документа, в котором в правильной форме зафиксированы требования к продукту.

Подводный камень №2: память человека не безгранична, всегда лучше иметь одно место, где все ваши пожелания и требования зафиксированы (не переписка в telegram или звонок по телефону). Поэтому ТЗ это печатный текстовый документ с приложением схем и инфографики, не написанный от руки или сфотографированный. Лучше всего в формате .PDF или Google Docs.

Рецепт грамотного ТЗ

Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта. Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:

• Концептуальная модель
• Функциональная карта
• Путь пользователя
• Пользовательский интерфейс
• Программные интерфейсы
• Нефункциональные требования

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

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

Концептуальная модель

В этот пункт входит краткое описание продукта, в нем отражается цель проекта и его отличительные черты.

Например: “Приложение для знакомств, в котором можно смотреть короткие видео в профилях пользователей и общаться в чате”.Также не помешает сказать пару слов об аудитории продукта, так команда проекта сможет понять его особенности и дать вам несколько полезных советов. Расскажите о ее возрасте, характере и территориальном расположении, каких-то особенностях, которые должны отразиться на проекте.

Например: “Это молодые люди, выезжающие за рубеж для отдыха и интересующиеся общением за пределами языкового барьера, которые любят снимать фото и видео”.

Стоит рассказать о типах пользователей и их ключевых отличиях.

Например: “В приложении должны быть обычные пользователи и модераторы, которые получают жалобы от пользователей на контент или профили. Модераторы могут просматривать чат обычных пользователей после жалобы и заблокировать в сервисе нарушающий правила аккаунт”.

И в завершении расскажите о компонентах вашего продукта.

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

Высшим пилотажем будет сделать так называемый data flow или контекстную диаграмму, в которой будет отражено как пользователи взаимодействуют с продуктом, его компонентами и между собой.

Функциональная карта

Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.

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

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

Путь пользователя

Так называемый user flow или путь пользователя, это последовательный список действий или экранов, по которым может переходить пользователь в процессе взаимодействия с продуктом. Опишите, как в вашем представлении будет взаимодействовать с продуктом пользователь. Очень удобно это можно сделать также майнд картой или просто списком действий.

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

Путь пользователя — это общий алгоритм работы с продуктом. Также существует еще use cases (варианты использования) — это детализация user flow. В случае мобильного приложения для знакомств вы создали путь пользователя по экранам, а затем описываете, что пользователь может сделать на каждом экране.

Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.

Пользовательский интерфейс

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

• ukraine.craigslist.org
• www.theworldsworstwebsiteever.com (предупреждение, если вы страдаете приступами эпилепсии то не переходите по ссылке
• www.art.yale.edu

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

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

Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.

Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.

Программные интерфейсы

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

Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.

Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).

Нефункциональные требования

Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.

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

Советы

1. Создавайте текстовый документ в онлайн офисе или PDF, который легко будет прочесть. Это гораздо лучше переписки в чате или голосового сообщения, его всегда можно будет посмотреть с любого устройства.
2. Соблюдайте последовательность, переходите от общих требований к частным, приведенная выше структура не идеальна, но может служить хорошей основой.
3. Все требования должны быть в одном документе или вики-структуре, не храните их отдельно, они должны быть всегда доступны из одного источника.
4. Давайте четкие и разумные указания, избегайте неточностей, пишите максимально простым языком.
5. Описывайте ваши требования максимально подробно. Лучше один раз все продумать, чем постоянно уточнять различные детали и нюансы.
6. Приготовьтесь потратить больше нескольких дней или обратитесь к профессионалу для составления документа. Грамотное техническое задание спасет вас от долгих обсуждений деталей с разработчиками и обозначит четкие критерии сдачи проекта. Например, полноценное ТЗ по стандарту IEEE-830, приложенное к договору на разработку, является аргументов в суде в случае невыполнения требований.