техническое задание для мобильного приложения пример
Техническое задание на разработку приложения
Написать хорошее ТЗ сложно, это не дело пяти минут. Но есть отличная новость! Эта ответственная задача ложится не только на ваши плечи, но и на плечи мобильного разработчика. Он тоже заинтересован в успехе вашего сотрудничества.
1 шаг. Идея разработки мобильного приложения
Опишите ваше будущее приложение будто рассказываете рецепт сложного блюда. Какие ингредиенты вы хотите туда положить? Какие функции они выполняют? Запишите их, продумайте, какая между ними логика взаимодействия. Не пытайтесь втиснуть в одно приложение все сразу — ведь в блюдах мы не мешаем все, что находим в холодильнике. Мы выбираем что-то главное и добавляем к нему несколько менее важных ингредиентов, для того чтоб вкус получился уникальным.
Посмотрите, нет ли аналогов приложения? Если нет, то вам крупно повезло. Обычно же аналоги находятся и в крупных размерах — ваша задача придумать, чем ваше приложение будет отличаться, причем в лучшую сторону. И если вам удастся найти эту прореху в нише, заполняйте ее смело и не теряйте драгоценных секунд — конкуренты не дремлют.
Если же вы делаете приложение под свои бизнес-задачи, то вам будет полезно посмотреть, какие приложения есть у ваших конкурентов. Возможно, что-то вы сможете сделать сильно лучше, и как итог — переманить клиентов у конкурентов.
2 шаг. Вопросы, с которых начинается ТЗ
Ответив на эти вопросы, можете смело заполнять бриф. А это первый шаг к тому, чтобы составить правильное ТЗ, а потом и к разработке успешного мобильного приложения.
Если вы не технический писатель или программист — подготовить грамотное ТЗ самостоятельно у вас, к сожалению, вряд ли получится. Но вам обязательно поможем мы, разработчики, ведь мы успешно делали это десятки раз.
3 шаг. Настало время ТЗ!
ТЗ – индивидуальный документ, и каждый раз составляется заново под каждый проект. Это также зависит и от разработчика, к которому вы обратились. Ведь у всех свой метод работы, а это значит, что в ваших интересах составить техзадание максимально подробно.
Ваше ТЗ может не содержать тех или иных разделов только в том случае, если это не существенно именно для вашего проекта. Но узнать, что именно существенно, а что нет, вы сможете только от разработчика.
Начните прямо сейчас!
На самом деле, написать хорошее ТЗ — просто, если подойти к этому делу с умом. И не возлагать на себя одного это нелегкое дело. Ведь ТЗ нужно для результативного взаимодействия. А значит, в составлении ТЗ должны принимать участие обе стороны и… та-дам! Основные технические трудности разработчик берет на себя!
Как говорится, глаза боятся — а руки-то вот они. Тут важно начать. Часто, это главная заминка в начале успешного проекта. Поэтому начинайте прямо сейчас — напишите бриф. Этого хватит, чтоб увидеть проект в общих чертах, а значит, дело останется за деталями!
Как сделать техническое задание на мобильное приложение
При знакомстве со студией клиент рассказывает, какое приложение он хочет получить. Все его характеристики от внешнего вида до функций фиксируются в техническом задании (ТЗ). Этот документ — руководство к действию, на него студия опирается во время разработки, чтобы создать для клиента продукт, который соответствует его ожиданиям. Но как его написать?
ТЗ по ГОСТу: поможет ли оно сделать классное приложение
У ТЗ на разработку мобильного приложения есть стандарты качества: отечественные ГОСТы и зарубежные 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.
Каким должно быть ТЗ для мобильного приложения
Слово “ТЗ” прочно вошло в нашу жизнь и попало в шутки о работе программистов, аналитиков и дизайнеров. Несмотря на широкую узнаваемость термина, он до сих пор трактуется неоднозначно. При работе с клиентами разница представлений о техническом задании зачастую приводит к недопониманию и ложным ожиданиям.
Мы понимаем, какую важную роль ТЗ играет в разработке приложений. В новой статье расскажем, что влияет на наполнение документов по проекту, по каким критериям качества они оцениваются, и чем полезна профессиональная аналитика.
Зачем нужно ТЗ, и что это вообще
Начиная наш разговор, давайте уточним, что ТЗ на разработку системы или приложения — это зачастую не единичный документ, шаблон которого можно найти в Интернете, а группа создаваемых документов (“артефактов”).
Хорошее ТЗ максимально четко и однозначно определяет требования к проекту и для команды, и для бизнеса, делая очевидными конечные цели и задачи. Благодаря нему уточнять требования к проекту по ходу разработки нужно существенно реже, а приёмка готового продукта происходит проще и быстрее.
ТЗ бывают крайне разными. Наполнение и содержание напрямую зависит от проекта, процессов разработки и подхода к ней. Например, ТЗ для приложения, которое создается по модели Waterfall, не совпадает с ТЗ приложения, команда которого работает по Agile.
Наши аналитики часто сталкиваются с представлением о том, что ТЗ — общее, верхнеуровневое описание стратегии или идеи приложения. Встречается и другое мнение: ТЗ обязательно должно быть максимально объемным и подробным.
Для нас это не так. То, зачем и в каком объёме пишется ТЗ, в каждом случае определяется командой. Мы формируем его на основе конкретных задач проекта, списка пользовательских требований и критериев качества, а не по стандартным лекалам. На выходе это — набор смысловых блоков, разделов документа, который определяет необходимые и достаточные требования бизнеса и команды разработки.
Задача аналитика при создании ТЗ
Разрабатывая ТЗ, аналитики должны определить и прояснить требования к проекту на основании требований стейкхолдеров. Стейкхолдеры — заинтересованные лица, которые существенно влияют на принятие решений по проекту.
Со стороны бизнеса это, как правило — собственники, руководители, акционеры. Со стороны разработки: разработчики, проджект-менеджеры, QA-специалисты и др. Со стороны внешних систем (от бизнеса или технической команды исполнителя) — архитекторы ПО либо разработчики.
Обычно в формировании бизнес-требований изначально участвуют топ-менеджеры. Хотя зачастую требования к продукту исходят от конкретных сотрудников или отделов, которым предстоит активно пользоваться им. Эти требования могут быть как утверждены, так и не утверждены высшим руководством.
Важно учитывать мнение о процессах разработки и со стороны технической части. Гораздо лучше для проекта, если команда сразу знает, кто входит в круг заинтересованных лиц и формирует цели приложения, а не выясняет перед релизом.
Чем больше стейхолдеров, тем больше углов зрения учитывается при разработке ТЗ, и выше вероятность, что документация по проекту разрастется.
Примером объемного ТЗ является ТЗ, написанное по ГОСТ. С такими мы работаем редко, документы этого типа нечасто требуются клиентам. Они нужны, когда ожидается многоступенчатое согласование деталей. Например, с госструктурами без ТЗ по ГОСТ работать проблематично: слишком много стейкхолдеров участвует в обсуждении проектов.
ТЗ по ГОСТ применяется на проектах, где важны максимальная полнота технической информации и стремление предельно четко определить требования к продукту. Документы насыщены информацией и деталями, от этого они теряют в читабельности и в простоте для восприятия. На разработку ТЗ по ГОСТ уходит много времени, и прорабатывать его стоит тогда, когда оно объективно нужно на проекте.
Процесс проработки ТЗ
Каковы границы проекта? Аналитик начинает прорабатывать любое ТЗ с поиска ответа на этот вопрос. Чтобы разобраться, нужно:
В процессе прояснения задач проекта и требований к нему создаются артефакты. Они нужны для фиксации договоренностей, достигнутых между клиентами и командой, и дальнейшего уточнения ограничений в выбранном варианте реализации.
Этапы проработки ТЗ:
1#
На первом этапе анализа мы готовим артефакт под названием Vision — наше видение проекта. Этот документ, как набросок, определяет границы будущего приложения, которое планируется разработать. В Vision аналитики определяют и явно формулируют цели всего приложения. Важно зафиксировать их так, чтобы все стейкхолдеры понимали смысл одинаково.
Также на этом этапе аналитики определяют основной скоуп фич (набор функционала) и цель создания каждой фичи. Иначе говоря, мы определяем, что надо сделать, а главное — зачем.
2#
На втором этапе на основе Vision мы можем сделать грубую оценку разработки и более точную оценку аналитики. Определяем структуру документации по проекту — какой комплект артефактов понадобится для исчерпывающего описания программного обеспечения, какие правила наполнения, управления изменениями и оповещения будем использовать.
На этом этапе нужно понять: зачем нужен каждый артефакт? Мы всегда можем составить максимально подробный комплект документов, но это должно быть обосновано. Например, если клиент торопится скорее выпустить новый продукт на быстро развивающемся рынке, начинать работу лучше с минимального набора артефактов.
Создание полного комплекта артефактов — дело небыстрое, оно сдвигает по времени и старт разработки. Так что лучше не плодить архивы, а определить цели создания и ценность всех артефактов и разработать действительно важные.
Цели разработки артефактов у заинтересованных лиц могут разниться и доходить до противоположных. Задача команды — сформулировать и выявить противоречия, точно установить задачи каждого документа и проекта. Увидеть, какими должны быть артефакты, команде помогают критерии качества.
Выбрав критерии качества, актуальные для проекта, мы снова определяем, какие ожидания есть у стейкхолдеров, вносим технические коррективы и проясняем, что нужно команде, чтобы продолжить работу.
Теперь можно заниматься глубокой проработкой ТЗ: детализацией частей системы и углублением в нюансы. В дальнейшем мы можем повторно прибегнуть к обсуждению проекта со стейкхолдерами, если появится потребность изменить часть системы, или при проработке ТЗ откроются новые детали, требующие внимания.
3#
При проработке ТЗ аналитики нередко используют шаблоны документов. Они используются, как черновики структуры документов либо как референсы, и наполняются информацией под конкретные задачи. Например, мы используем такие шаблоны, как Видение, Роли-кейсы, ТЗ, Описание прототипов. При наполнении мы добавляем в каждый документ описания частей системы с разных ракурсов, позволяющие наиболее точно понять требования к программному обеспечению.
Аналитик выбирает шаблоны в зависимости от проекта. Так, например, прототипы интерфейса и описание элементов можно не делать, если речь идет о панели администратора со стандартными интерфейсами. Как правило, в таком случае общего описания основных сценариев достаточно.
Особенности ТЗ мобильного приложения
Критично важно сразу учесть, на какой платформе будет выпущено приложение. Это задаёт технические ограничения и базовые характеристики. Например, в приложении на Android кнопка “Назад” на экране не обязательна, а в iOS необходима, потому что нет физической кнопки “Назад”.
Также немаловажно учитывать, что основа мобильного приложения сейчас — его визуальная часть, а главная часть логики ложится на сервер. Изменение требований к визуальной части зачастую влечет за собой необходимость переделки большей части мобильного приложения. Как следствие, растут затраты на разработку.
При проработке ТЗ приложения аналитики выявляют и определяют технические требования и ограничения, например, какие версии OS должны поддерживаться. Некоторые фичи, предлагаемые клиентом или командой при разработке требований к приложению, могут быть недоступны для старых версий либо требовать дополнительных затрат времени при реализации.
Всегда ли нужно детально прорабатывать ТЗ?
Как показывает опыт Azoft, есть случаи, когда важно прорабатывать ТЗ с начала проекта, а есть — когда можно начать с верхнеуровневого описания и динамично стартовать по Agile.
Детальная проработка ТЗ перед стартом разработки необходима, когда заказчикам принципиально важно зафиксировать сроки и стоимость работ.
При этом стейкхолдеры должны быть уверены, что изменения в требованиях после подробного описания и оценки будут минимальными.
ТЗ помогает, когда клиент выбирает подрядчика среди множества вариантов, сравнивая условия сотрудничества. Четкое и однозначное ТЗ — возможность убедиться, что все потенциальные подрядчики точно оценивают одно и тоже, и это именно то, что требуется клиенту. Оно позволяет выбрать команду разработки более взвешенно.
Чем больше неизвестных характеристик и меньше деталей, тем шире простор для интерпретаций. Особенно это актуально для крупных компаний, которые часто ищут подрядчиков поступенчато. В принятии решения о выборе разработчиков участвует много людей, это создает риск, что на одном из этапов поиска информация исказится.
Детальное ТЗ необязательно, а иногда даже вредно для проекта, когда:
В таких случаях можно начинать с проработки “Видения” проекта. Под него подбирают команду, подходящую по технической экспертизе и опыту разработки продуктов в условиях динамически меняющихся требований. С этой командой, определив цели и границы будущей системы, можно стартовать работу по методологии Agile. При таком подходе разработчики регулярно выкатывают промежуточные версии системы, что позволяет заказчику эффективно корректировать требования и приоритеты по ходу разработки.
Заключение
Аналитику невозможно не делать — для разработки проекта команда в любом случае должна прояснить и уточнить все требования к нему. Часть этого процесса начинается ещё до разработки системы, часть происходит во время неё. Клиент выбирает: либо он контролирует аналитику, либо аналитика протекает стихийно.
Проработка ТЗ, как часть аналитики, позволяет управлять соотношением числа деталей, которые проясняются заранее и по ходу реализации.
ТЗ помогает:
При создании и проработке ТЗ аналитики в Azoft максимально учитывают специфику каждого проекта и требования к нему. Они помогают клиенту найти оптимальный баланс между естественным желанием всё предусмотреть заранее и желанием поскорее начать тестировать готовый функционал, а не в сотый раз перечитывать описание.