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