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

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

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

У ТЗ на разработку мобильного приложения или веб-сервиса есть стандарты качества: отечественные ГОСТы и зарубежные 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. Мы вместе разберёмся в деталях, определим какие артефакты нужны вашему проекту и превратим его в героя Меча и Магии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кто пишет ТЗ?

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

Заказчик

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

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

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

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

Эксперты

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

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

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

Что указывают в техническом задании:

  • Описание функций и действий, которые будут доступны пользователю (что он получит, совершая то или иное действие).
  • Особенности работ базы данных, нюансы офлайн-работы и взаимодействия с сервером.
  • Уникальность проекта. Особое внимание уделяется «фишкам» — характеристикам, которые будут отличать новое приложение от тех, что уже представлены на маркетплейсах. Важно проработать их детально, чтобы они несли максимальную пользу, были интересными и запоминающимися.

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

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

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

Хорошее ТЗ — это понятный, структурированный текст, где прописан ожидаемый результат работы. От лица исполнителя в составлении ТЗ участвуют руководитель проекта, бизнес-аналитик, UI/UX дизайнер-проектировщик, руководитель iOS и Android разработки, тестировщик. Заказчик может быть не знаком с многими техническими нюансами и особенностями сферы IT. Специалисты же знают о разработке приложений все: каждый несет ответственность за свой участок задач. Совместная работа — гарантия того, что будут учтены все детали. Наша цель — понятно рассказать о всех возможностях, чтобы в итоге получился лучший продукт.

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

  • Как написать ТЗ на мобильную разработку?

  • Что такое техническое задание?

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

  • Структура ТЗ

  • Можно ли написать хорошее ТЗ по ГОСТу?

  • Как выбрать команду для работы над будущим проектом?

  • Сколько стоит ТЗ?

  • Заключение

  • Связаться с менеджером LeanTech

Как написать ТЗ на мобильную разработку?

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

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

Что такое техническое задание?

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

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

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

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

Заказчик

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

Эксперты

Команда специалистов внимательно изучает запрос, всю собранную вами информацию и берется за профессиональное описание ТЗ. Кто участвует в работе?

  • Маркетолог. Он занимается анализом рынка и спросом на подобные приложения, описывает цели и позиционирование платформы, работает с вашей потенциальной аудиторией: определяет ее целевые потребности, желания и отражает это в ТЗ. Такая информация помогает остальной команде понять, каким должен быть продукт, чтобы он был востребован среди потребителей. Некоторые компании предлагают услуги своего маркетолога, но большинство других, в том числе мы, используем информацию вашего специалиста.
  • UI/UX Дизайнер. Разрабатывает дизайн интерфейсов с учетом логичного и понятного пользовательского опыта. То есть его главная задача, сделать приложение не только современным и приятным глазу, но и максимально удобным в использовании.
  • Разработчик. Занимается технической частью проекта — пишет код, оптимизирует внутреннюю и серверную часть приложения, запускает продукт на рынок, при необходимости поддерживает его и добавляет необходимые функции. Разработчики лучше всех понимают, что необходимо вашему продукту для безупречной работы.
  • Бизнес / Системный аналитик — всю информацию, которую аналитик получает от специалистов, он прописывает на простом и доступном языке в ТЗ. Его главная задача — донести до каждого из команды суть, идею и процесс создания будущего продукта.

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

Структура ТЗ

Итак, КТО пишет ТЗ мы с вами разобрали, сейчас давайте рассмотрим, КАК его создают. Для примера возьмем структуру ТЗ, которую составляет наша команда LeanTech:

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

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

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

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

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

Можно ли написать хорошее ТЗ по ГОСТу?

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

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

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

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

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

Как выбрать команду для работы над будущим проектом?

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

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

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

Сколько стоит ТЗ?

Как правило, написание ТЗ входит в цену создания мобильного приложения. Бюджет рассчитывается на этапе аналитики и прописывается сметой внутри документа. Кроссплатформенная разработка MVP продукта в LeanTech, составит от 1 800 000 рублей и по срокам займет от 2 месяцев. Если вашему бизнесу нужна нативная разработка, то есть для определенной платформы, то цена такого проекта от 2 700 000 рублей, а сроки создания примерно от 3 месяцев.

Если у вас уже есть команда разработчиков, с которой вы планируете создавать свое будущее приложение, но вам необходимо грамотное ТЗ, мы напишем его для вас. Стоимость будет складываться из сложности проекта, его задач и составит от 80 000 до 600 000 рублей.

Подытожим

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

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

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

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

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

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

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


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

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

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

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

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


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

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

    • Конкретика. Если у заказчика есть требование к цветовой гамме, об этом нужно четко прописать в инструкции. «Белый фон, синие иконки» — это общие слова без конкретики. Можно указать определенные параметры 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-приложение, необходимо задать вопрос: «Как будет вести себя пользователь?»
    • История правок. Перед составлением технической инструкции необходимо создать таблицу со столбцами «дата», «описание», «автор». В каждую графу нужно записывать любые изменения. Это поможет понять, на каком этапе работы возникли противоречия.

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

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

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

    Вывод

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

    Вы составляли ТЗ под мобильное приложение?

    1 голос


    Да — 0%



    Нет — 100%

    Добавить комментарий