техническое задание мобильное приложение пример
Как сделать техническое задание на мобильное приложение
При знакомстве со студией клиент рассказывает, какое приложение он хочет получить. Все его характеристики от внешнего вида до функций фиксируются в техническом задании (ТЗ). Этот документ — руководство к действию, на него студия опирается во время разработки, чтобы создать для клиента продукт, который соответствует его ожиданиям. Но как его написать?
ТЗ по ГОСТу: поможет ли оно сделать классное приложение
У ТЗ на разработку мобильного приложения есть стандарты качества: отечественные ГОСТы и зарубежные SRS (software requirements specification). У SRS более разветвлённая структура: его содержание похоже на реферат с введением, главами, подглавами и заключением. Но и в том и в том стандарте есть общие смысловые части:
SRS популярен на западе — на российском рынке он пока не прижился. ТЗ по ГОСТу необходимо только госсектору и тем компаниям, которые с ним тесно связаны. У крупных корпораций, которые заказывают приложение, могут быть свои стандарты качества — тогда студия оформляет документы по их образцу.
Поскольку в законодательстве нет жёстких требований к проектной документации, студии мобильной разработки «настраивают» ТЗ под себя. Некоторые продолжают писать по ГОСТу — такой документ удобнее проверять: вы открываете стандарт, открываете техзадание и сверяете разделы. Ну, а больше плюсов мы не нашли. Из минусов:
Кто пишет техническое задание на мобильную разработку
Независимо от формата написать такой документ одному сложно. Клиент хорошо объясняет идею приложения на языке своего бизнеса, но не может перевести её в терминологию айти, что естественно. Для этого и существуют технические писатели и аналитики. Они помогают клиенту на техническом языке сформулировать его ожидания и закрепляют это в документе.
Люди, которые привыкли к формату официальных документов, могут спокойно работать с ТЗ по ГОСТу. Но чаще техзадание сокращают до ёмких инструкций и схем.
Проблема любых больших документов, особенно аналитических, в том, что их сложно читать как клиентам, так и самим разработчикам, поэтому мы не пропагандируем ТЗ по определённым форматам, будь то ГОСТ или зарубежные стандарты. Я за то, чтобы делать ТЗ под конкретный проект. Более того, я сторонник подхода «меньше текста без ущерба смыслу — лучше». Если можно обойтись без документа и заменить его на изображения или схемы, тем самым сократив объём, то лучше сделать именно так.
Помните, что даже самая хорошая проектная документация не гарантирует, что всё пойдёт по плану. Успех проекта зависит не от документов, а от команды разработчиков. А вот ТЗ, составленное неправильно, может навредить вашему приложению.
Как понять, что вы попали к плохому аналитику
Тратить много часов на разработку проектной документации — нормально. Не спешите убегать от аналитика, который пишет ТЗ на сложные проекты неделями. Насторожитесь, если:
Сколько стоит техническое задание
В масштабах всего проекта цена, которую клиент платит за ТЗ, небольшая. Час работы техписателя оценивается в 1500–2000 рублей. На простое приложение без бэкенда уходит 60 часов, а на сложный eCommerce можно потратить больше двухсот. Но экономить на ТЗ нельзя. В мобильной разработке оно выполняет ту же роль, что и чертёж в строительстве дома: одна неправильная линия и всё может рухнуть. Поэтому вкладываться нужно с самого начала. Компании IBM выяснила: если вы найдёте ошибку на ранних этапах разработки, исправить её будет дешевле.
Вдумчивая и внимательная работа аналитиков убережёт вас от финансовых потерь. Исключая ошибки на этапе написания технических требований, они подготовят документацию, которая станет надёжным каркасом для разработки приложения. А ещё ТЗ для вашего проекта — один раз и на всю жизнь. Вы можете передавать его вместе с приложением другой студии на поддержку и развитие. Хорошо составленное ТЗ поможет им быстрее разобраться в новом проекте.
Сейчас я работаю над приложением, в котором чувствуется необходимость ТЗ. Это нестандартный проект, у клиента имеется своя команда по разработке бэкенда, они управляют всеми заданиями, которые идут к нам. Но по тем или иным причинам информации нам недостаточно — приходится почти по каждой задаче обращаться к клиенту с вопросами, что сильно увеличивает затрачиваемое время.
— Иван Леонтьев, «Лайв Тайпинга»
Можно ли скачать готовый шаблон ТЗ
Из миллиона готовых шаблонов выбрать свой тяжело. В интернет выкладывают примеры, созданные под другие приложения, поэтому они не смогут помочь вашему бизнесу достигнуть цели. Скачивая шаблон, вы принимаете на веру потребности чужого приложения и не анализируете свои. В нём могут быть лишние пункты, которые не нужны вашему приложению. В то же время многие важные для проекта вещи останутся непрописанными, ведь автор шаблона не знал о них, когда делал ТЗ. Доверять интернету рискованно — лучше доверьтесь людям, которые напишут проектную документацию под ваши задачи.
Техническое задание без ошибок, воды, повторов — наш подход к проектной документации
Из чего может состоять проектная документация в «Лайв Тайпинге»:
1. Функциональное задание
Функциональное задание (ФЗ) — самый мощный артефакт в нашей проектной документации. К нему обращаются на каждом этапе разработки от прототипирования до релиза. На его основе дизайнеры создают экраны, разработчики пишут код, а отдел QA проводит тестирование. И при этом у него нет ни одного магического свойства. Сила ФЗ в том, что оно подробно описывает функции, которые доступны пользователю при работе с приложением. На интервью с клиентом мы узнаём, какие ролевые модели (администратор, модератор, простой пользователь) предусмотрены в приложении, и описываем набор функций для каждой роли: куда пользователь может пойти, что сделать и какой результат его ждёт. Пока мы с клиентом готовим этот артефакт, дизайнеры делают прототипы экранов, которые соответствуют возможностям приложения, прописанным в ФЗ. Готовый документ проверяют разработчики.
На этапе проектирования я полностью читаю готовое ФЗ на один раз — у меня складывается общая картина приложения. Затем я начинаю читать ФЗ на второй раз, это позволяет мне: 1) задать вопросы, которые меня интересуют, чтобы проверить документ на ошибки; 2) дополнить конкретные моменты в приложении исходя из своего опыта; 3) дать более точную оценку проекту.
— Павел Разуваев, «Лайв Тайпинга»
2. Функциональные схемы
Функциональные схемы (ФС) иллюстрируют, как простые функции приложения группируются в более сложные и взаимодействуют друг с другом. Те, у кого много очков опыта в айти, легко воспользуются этим артефактом. Но если вы ещё не подняли скилл до нужно уровня, прочитать функциональные схемы вам поможет описание компонентов системы.
3. Описание компонентов системы
Вспомогательный артефакт, который уточняет работу ФС. Схемы изображают функциональные модули и их связи, а описание подробно рассказывает о том, что это за компоненты, чтобы человеку было удобнее читать схему. Нужен, когда мы хотим пояснить детали людям из команды клиента: это могут быть как разработчики, так и те, кто не связан с программированием напрямую. Пишем его по необходимости, поэтому по шкале важности он получает только один огонёк из трёх.
4. Технические заметки
Артефакт описывает, как разработчики реализуют функции из ФЗ. Мы не хотим тратить деньги клиента на очевидные вещи, поэтому делаем технические заметки только на те места, которые кажутся нам рискованными и требующими внимания: любые алгоритмы, расчёты, интеграции.
До начала работы над проектом в техзаметках фиксируется информация, которая помогает более комплексно понимать технические требования проекта и быстро включает в него новых людей. Заметки избавляют от необходимости рассуждать на митингах, как именно реализовать ту или иную фичу. Благодаря этому ты меньше отвлекаешь тиммейтов во время работы, а тиммейты — тебя.
— Андрей Дёмин, «Лайв Тайпинга»
Мы бы очень хотели видеть технические заметки в проектах, которые приходят к нам на поддержку и развитие. Когда к нам поступает новая система, нам нужно понять, как она работает внутри. Если артефакта нет, то нам приходится разбираться в чужой работе самостоятельно — обычно это долго и больно.
5. Спецификация API (application programming interface)
API — язык, на котором приложение «общается» с серверной частью. Когда пользователь совершает действие, внутри приложения формируется запрос, который улетает в сервер, обрабатывается и возвращается в виде ответа. Спецификация устанавливает нормы этой коммуникации. Артефакт не используется в приложения без бэкенда.
6. Карта рисков
Мы составляем карту рисков для того, чтобы показать клиенту опасные места в проекте: размытые задачи и интеграции, с которыми мы ещё не работали. Почему это важно? Есть задачи, выполнение которых нельзя точно оценить в процессе проектирования. Если мы не скажем об этом клиенту, у него сложатся неверные ожидания по срокам и стоимости проекта. Артефакт получает одну комету, потому что такие задачи в нашей практике появляются редко.
7. Документация на фичу
Этот артефакт — референс к гостовскому ТЗ: он собирает технические и функциональные характеристики на одну фичу в одном месте. Нужен, когда к нам на поддержку приходит готовый проект и мы добавляем в него новые функции или исправляем баги.
Есть обязательные артефакты, без которых невозможно представить приложение, — это функциональное задание и технические заметки. В проектах, которые приходят на поддержку, их заменяет документация на фичу. Наличие остальных артефактов зависит от сложности проекта и опыта команды. Мы делаем некоторые вещи с закрытыми глазами, поэтому собираем только те документы, которые несут реальную пользу проекту. Этот подход выгоден и нам, и клиенту: мы не тратим ресурсы на банальные вещи и больше вкладываемся в то, что повлияет на работоспособность приложения и оценку пользователей.
Как «Лайв Тайпинг» сокращает затраты клиента на документацию
Чтобы вы лучше представили, как набор артефактов меняется от проекта к проекту, и поняли, что не нужно делать всё и сразу, мы расскажем про документацию, которую готовили для наших последних проектов: спортивного дневника, приложения по доставке еды и мобильного eCommerce.
Техническое задание на разработку приложения
Написать хорошее ТЗ сложно, это не дело пяти минут. Но есть отличная новость! Эта ответственная задача ложится не только на ваши плечи, но и на плечи мобильного разработчика. Он тоже заинтересован в успехе вашего сотрудничества.
1 шаг. Идея разработки мобильного приложения
Опишите ваше будущее приложение будто рассказываете рецепт сложного блюда. Какие ингредиенты вы хотите туда положить? Какие функции они выполняют? Запишите их, продумайте, какая между ними логика взаимодействия. Не пытайтесь втиснуть в одно приложение все сразу — ведь в блюдах мы не мешаем все, что находим в холодильнике. Мы выбираем что-то главное и добавляем к нему несколько менее важных ингредиентов, для того чтоб вкус получился уникальным.
Посмотрите, нет ли аналогов приложения? Если нет, то вам крупно повезло. Обычно же аналоги находятся и в крупных размерах — ваша задача придумать, чем ваше приложение будет отличаться, причем в лучшую сторону. И если вам удастся найти эту прореху в нише, заполняйте ее смело и не теряйте драгоценных секунд — конкуренты не дремлют.
Если же вы делаете приложение под свои бизнес-задачи, то вам будет полезно посмотреть, какие приложения есть у ваших конкурентов. Возможно, что-то вы сможете сделать сильно лучше, и как итог — переманить клиентов у конкурентов.
2 шаг. Вопросы, с которых начинается ТЗ
Ответив на эти вопросы, можете смело заполнять бриф. А это первый шаг к тому, чтобы составить правильное ТЗ, а потом и к разработке успешного мобильного приложения.
Если вы не технический писатель или программист — подготовить грамотное ТЗ самостоятельно у вас, к сожалению, вряд ли получится. Но вам обязательно поможем мы, разработчики, ведь мы успешно делали это десятки раз.
3 шаг. Настало время ТЗ!
ТЗ – индивидуальный документ, и каждый раз составляется заново под каждый проект. Это также зависит и от разработчика, к которому вы обратились. Ведь у всех свой метод работы, а это значит, что в ваших интересах составить техзадание максимально подробно.
Ваше ТЗ может не содержать тех или иных разделов только в том случае, если это не существенно именно для вашего проекта. Но узнать, что именно существенно, а что нет, вы сможете только от разработчика.
Начните прямо сейчас!
На самом деле, написать хорошее ТЗ — просто, если подойти к этому делу с умом. И не возлагать на себя одного это нелегкое дело. Ведь ТЗ нужно для результативного взаимодействия. А значит, в составлении ТЗ должны принимать участие обе стороны и… та-дам! Основные технические трудности разработчик берет на себя!
Как говорится, глаза боятся — а руки-то вот они. Тут важно начать. Часто, это главная заминка в начале успешного проекта. Поэтому начинайте прямо сейчас — напишите бриф. Этого хватит, чтоб увидеть проект в общих чертах, а значит, дело останется за деталями!
Как мы работаем с ТЗ приложений — делимся опытом
Как разработчики приложений, мы не понаслышке знаем о роли ТЗ в создании качественных продуктов. В новой статье расскажем, что влияет на наполнение документов по проекту, по каким критериям они оцениваются, и как мы в Azoft прорабатываем ТЗ.
Начнем с того, что термин «ТЗ» проник в нашу жизнь и давно попал в мемы о работе программистов, дизайнеров и маркетологов. Но, хотя слово получило широкую узнаваемость, оно трактуется неоднозначно. В работе с клиентами это часто приводит к неверным ожиданиям и недопониманию.
Прежде всего, давайте уточним, что ТЗ на разработку системы или приложения — это чаще всего не единичный документ, шаблон которого можно скачать в Сети, а группа создаваемых для проекта документов («артефактов»).
Качественное ТЗ четко и однозначно определяет требования к проекту и для команды, и для клиента, делая прозрачными конечные цели и задачи. Оно позволяет уточнять требования к проекту по ходу разработки в разы реже, а приёмку готового продукта производить проще и быстрее.
ТЗ бывают разными. Наполнение и содержание напрямую зависит от проекта, производственных процессов и подхода к разработке. Так, техническое задание для приложения, которое создается по модели Waterfall, не совпадает с техническим заданием приложения, команда которого работает по Agile. Общие черты, конечно, есть, но и различий немало.
Аналитики в Azoft часто сталкиваются с представлением, что ТЗ — общее, верхнеуровневое описание стратегии или идеи приложения. А бывает и обратное мнение: ТЗ обязательно должно быть объемным (чем больше страниц, тем круче).
Не можем с этим согласиться. Зачем и в каком объёме пишется ТЗ, в каждом случае определяется командой. Мы формируем его на основе конкретных задач проекта, списка пользовательских требований и критериев качества, а не по условным стандартам. На выходе это — набор смысловых блоков, разделов документа, который определяет необходимые требования бизнеса и команды разработки.
Чтобы создать хорошее ТЗ, прежде всего, аналитики должны максимально точно определить и прояснить требования к проекту на основании требований стейкхолдеров. Стейкхолдеры — заинтересованные лица, которые оказывают влияние на принятие решений по проекту.
Стейкхолдеры со стороны бизнеса: собственники, руководители, акционеры.
Стейкхолдеры со стороны разработки: разработчики, PM-менеджеры, QA-специалисты.
Стейкхолдеры со стороны внешних систем (от бизнеса или команды исполнителя) — архитекторы ПО либо разработчики.
Часто в формировании бизнес-требований изначально участвует только высшее руководство, хотя нередко требования к продукту исходят от конкретных сотрудников или отделов, которым предстоит пользоваться им. Эти требования могут быть как утверждены, так и не утверждены топ-менеджерами.
Нужно учитывать мнение о процессах разработки и со стороны технической части. Лучше для проекта, если команда сразу знает, кто входит в круг стейкхолдеров и формирует цели приложения с этим учетом, а не узнает об этом слишком поздно.
Число стейкхолдеров определяет то, сколько точек зрения учитывается при разработке ТЗ. Чем их больше, тем выше вероятность, что документация по проекту разрастется.
Пример объемного технического задания — ТЗ по ГОСТ. С этим типом документов мы работаем редко (нечасто требуются нашим клиентам). ГОСТ документация нужна, когда согласование деталей происходит поступенчато и требует длительного времени. Например, в госструктурах, где в обсуждении проектов участвует очень много стейкхолдеров.
ТЗ по ГОСТ полезно на проектах, где важны максимум технической информации и стремление предельно четко определить требования к продукту. Такие документы перенасыщены информацией и деталями, от этого они становятся более сложными для восприятия и использования. На разработку ТЗ по ГОСТ уходит много времени, и работать над ним стоит лишь тогда, когда оно действительно требуется по проекту.
Разработка технического задания (ТЗ)
Каждая разработка программного обеспечения, начинается с оформления технического задания (ТЗ). Государственные заказчики и компании режимного регламента обязаны составлять ТЗ в соответствии с ГОСТ 19. В бизнесе, формат технического задания, обычно, не регламентируется какими-либо правилами, но имеет ряд основных разделов.
Основные разделы ТЗ
Назначение разработки
Данный раздел должен донести до исполнителя цель создания приложения. Это очень важно – когда программист понимает то что он создает, т.к. он может учитывать специфику темы и заложить возможность для будущего развития ПО. Абстрактная цель не позволит получить удобства в использовании, т.к. критерий оценки работы будет не явный.
Технические условия, Технические требования.
Технические условия для мобильного приложения должны выглядеть следующим образом:
В зависимости от условий – описание сервера может описывать требования по обеспечению необходимой нагрузки.
Если приложения создаются под определенные требования (Безопасность, секретность и т.д.), то они, так же, описываются в данном разделе в произвольной форме.
Логика работы
Раздел логики работы является ключевым для всего технического задания. В данном разделе описываются основные алгоритмы получения и преобразования информации. В процессе описания основных бизнес-процессов для приложения, следует упомянуть и связанные бизнес-процессы компании. Подробное изложение, позволяет получить обобщенное представление и цели постановки задачи на разработку приложения.
При оформлении раздела, рекомендуется использовать графические блок-схемы, наглядное описание, какие-либо снимки и т.д., чтобы у программиста собралось наглядное описание процесса работы приложения. В тестовом описании желательно системное мышление и причинно-следственные связи. Применение сокращений из словаря, разумеется необходимо, но желательно своими словами описывать происходящий процесс.
В описании логики — много не бывает, больше конструктивизма, внимания к мелочам. Дифирамбы или длительные суждения с красивыми словами тут не нужны, это не рекламный текст, а самый технический. Этот текст будет перед глазами программиста все время разработки.
Если Вы не имеете достаточной компетенции для составления разделал логики, привлеките профессионала. Объясните профессионалу то что Вы хотите получить, и он будет задавать те дополнительные вопросы, которых может не хватать в Вашем толковании.
Описав логику работы, несколько раз вычитайте ее и определите, нет ли в ней упущений. Программист не додумает за Вас если чего-либо будет не хватать, а если и додумает, то не факт что его мнение совпадет с Вашим. Вносить изменение в приложение, где реализован дополнительный функционал, за рамками раздела логики никто не будет.
Интерфейс приложения
Мы уже описали требования к исходным данным, где преимущественно говорится о формате представления интерфейса приложения.
Интерфейс должен быть описан и показан в графическом виде. Если в приложении должны присутствовать элементы атрибутики фирменного стиля, то подобные медиаматериалы должны передаваться на цифровом носителе или размещены на файлообменнике с указанием прямой ссылки на файл. Корпоративные цвета описываются в формате HEX (например #4177ab).
Желательно приложить блок-схему переходов между экранами, с описанием переходов. При необходимости включения эффектов анимации, они должны быть описаны четко, техническими терминами. Если уже подготовлены макеты экранов, то можно включить их в эту схему или сослаться на название конкретного макета. В случаях, когда на макете присутствует много элементов управления (кнопок) то желательно явно прорисовывать от какой кнопки к какому экрану должен производиться переход
Описание интерфейса должно точно соответствовать логике работы, в противном случае не явно что является истинным. Перед окончанием правки раздела ТЗ связанного с интерфейсом, убедитесь что нет ничего лишнего. Если есть какой-то рисунок или эскиз, но ни один другой объект на него не ссылается, значит следует его описать дополнительно.
Сервер API
Данный раздел описывается в том случае, если приложение сетевое. Более подробно о том, что такое сервер API и для чего он нужен, мы описали в статье «сервер API«.
Описание сервера API должно включать состав протокола, а также методы взаимодействия с системами, которые не были описаны в разделе «Логика работы».
Минимальное описание с применением формата JSON в архитектуре REST:
Авторизация
URL: https://site.ru/api/login
Метод передачи входных параметров : POST
username — логин пользователя
password — md5-хэш контантенации логина и пароля
autologin — автовход (значение null/on)
Формат выходных данных : JSON
Пример
Подобное описание должно сопровождаться на каждую функцию сервера API. Помимо описания функций, должно сопровождаться общим блоком ошибок работы, например: сервер данных недоступен, ошибка формата API, бан за превышение квоты, ошибка сессии и т.п.
Панель администрирования / Настройки
При создании приложений, обычно вводится достаточно большое количество переменных. Переменные отвечают за режимы работы, изменяемые в процессе эксплуатации данные, давайте рассмотрим на примере.
Приложение по доставке еды из сети ресторанов. Приложение позволяет делать заказ еды на доставку или предварительный заказ к самовывозу. В настоящем случае, переменными хранимыми на сервере будут:
Переменные могут меняться в процессе работы. Синхронная работа через сервер данных, позволяет вносить функциональные изменения практически без задержек.
Помимо управления пременными средами, панель администрирования отвечает за отображение и модификацию накапливаемых/изменяемых данных. В нашем примере можно увидеть историю заказов через мобильное приложение, получить отчет о нагрузке на оборудование (если много заказов, следует увеличить мощность сервера). Имея историю заказов и инструментарий работы с ними, можно вычислить средний чек, помесячную динамику изменения заказов для планирования развития. В спорных случаях, панель управления позволит отобразить полную детализацию работы.
Чаще всего, для работы с системами обеспечения данных (API), мы разрабатываем панели управления по технологии WEB. Данный подход прост, эргономичен, функционален и не тянет за собой установки какого-либо дополнительного софта.
В разделе ТЗ про панель администрирования, опишите максимум зависимых переменных. Если сервер будет собирать данные, опишите в каком виде должна отображаться информация. После накопления, опишите желательные виды отчетов, графиков или диаграмм.
В случае если система должна сопрягаться с внешним сервером ( например 1С), то панель администрирования должна поддерживать изменение реквизитов подключения (адрес, логин, пароль).
Рекомендуем узнать подробнее о панели администрирования в статье Web-офис.
Входные данные
Если приложение является потребителем какого-либо контента, то входной контент должен быть описан и сопровождаться примерами для тестирования разработчиком. Примеры входных данных:
Любая информация, полученная до работы приложения, относится к входным данным.
Выходные данные
Приложение, которое создает какой-либо контент в хранилище смартфона, должно содержать данный раздел в ТЗ.
В выходные данные описывается формат получаемой информации, а также все технические условия, которым должна соответствовать выходная информация. Если есть возможность предварительно создать пример или юнит-тест для проверки выходных данных, приложите его к техническому заданию.
После оформления технического задания, подготовьте остальные исходные данные, необходимые для разработки мобильного проиложения
Примеры ТЗ
Техническое задание на разработку системы по доставке продукции из магазинов и ресторанов на дом. Включает:
Техническое задание на разработку службы по бронированию автомобилей как сервис франшизы (аналог Hetzner). Включает:
Помощь в разработке ТЗ
Мы понимаем, что не всегда в организации есть профессиональные технические сотрудники, которые могут качественно выполнить работу по разработке технического задания. Предлагаем рассмотреть наши услуги по разработке ТЗ под ключ. Мы описали процесс этой услуги в разделе разработка технического задания на проект. Узнайте о правильных этапах разработки ТЗ. С нами Вы не допустите ошибок при поставновке задачи подрядчику (исполнителю), а наше ТЗ будет четко описывать цели и ограничения для исполнителя. С корректным ТЗ, в случае проблем в ходе работ, Вы гарантированно получите ожидаемый результат, или защитите свои права даже в судебном порядке.
Узнайте цены на наши услуги по разработке ТЗ и эскизного проекта. Съэкономьте свое время и используйте его с умом в своей основной работе, а мы позаботимся о технической части, в которой отлично разбираемся сами.