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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

---

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

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

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

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

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

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

Вывод

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

Структура ТЗ

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

Определение цели проекта

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

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

Полный бюджет проекта

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

Перечень необходимых работ

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

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

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

Тщательно описывается готовый продукт

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

Оценивание результата проекта

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

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

Сроки выполнения работ

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

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

Будущее обслуживание проекта

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

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

Выявление проблем

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

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

Пример ТЗ для программиста

Приведем реальный пример технического задания для веб-разработчика на тему: «Доработка полей в CMS». Это ТЗ содержит следующие пункты с заданием:

• Цель проекта: доработать поля в CMS.
• Исходная информация. Произошла путаница с тем какое поле за что отвечает, в каком шаблоне, какой функционал. В итоге, слетела оптимизация этих элементов. Далее подробнее.
• Описание. Есть 2 типа страниц: записи и страницы.