Azoft

Как мы работаем с ТЗ приложений — делимся опытом

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

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

Для чего нужно ТЗ

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

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

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

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

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

Роль аналитика в разработке ТЗ

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

Стейкхолдеры со стороны бизнеса: собственники, руководители, акционеры.

Стейкхолдеры со стороны разработки: разработчики, PM-менеджеры, QA-специалисты.

Стейкхолдеры со стороны внешних систем (от бизнеса или команды исполнителя) — архитекторы ПО либо разработчики.

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

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

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

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

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

Как осуществляется процесс проработки ТЗ

Аналитик начинает прорабатывать любое ТЗ с поиска ответа на вопрос: каковы границы проекта. Для этого нужно:

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

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

Какие этапы проработки ТЗ существуют

Подготовка видения проекта

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

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

Определение структуры документации по проекту

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

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

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

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

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

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

Наполнение ТЗ

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

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

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

Очень важно вовремя учесть, на какой платформе выйдет новое приложение. Это задаёт технические ограничения и базовые характеристики. Так, в приложении на Android кнопка «Назад” на экране не нужна, а в iOS она обязательна, поскольку там нет физической кнопки “Назад».

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

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

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

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

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

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

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

Подробное ТЗ необязательно, а иногда даже нежелательно для проекта, если:

  • нужно максимально быстро запустить новый продукт — время, затраченное на детальное описание требований, едва ли окупится, но точно замедлит старт разработки и дату выпуска MVP на рынок.
  • заранее понятно, что проект продлится долго, и бизнес не может сразу сформулировать все требования к системе: они ещё формируются и будут меняться довольно долго.

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

Заключение

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

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

ТЗ помогает:

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

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

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

{ "author_name": "Azoft", "author_type": "editor", "tags": ["\u0442\u0437","\u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u0439\u0430\u043d\u0430\u043b\u0438\u0437","\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0438","\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430","\u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435","\u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435","\u0431\u0438\u0437\u043d\u0435\u0441\u0430\u043d\u0430\u043b\u0438\u0437","\u0430\u0443\u0442\u0441\u043e\u0440\u0441\u0438\u043d\u0433","\u0430\u0443\u0442\u0441\u043e\u0440\u0441","\u0430\u043d\u0430\u043b\u0438\u0442\u0438\u043a\u0430","project","product","azoft"], "comments": 0, "likes": 0, "favorites": 9, "is_advertisement": false, "subsite_label": "azoft", "id": 139245, "is_wide": true, "is_ugc": false, "date": "Fri, 03 Jul 2020 10:13:03 +0300", "is_special": false }
0
0 комментариев
Популярные
По порядку
Читать все 0 комментариев
«М.Видео» не привёз часть заказа и клиент не может ничего сделать уже несколько недель

TL;DR;
Заказал и оплатил 02 октября два товара в М.видео, в доставку 06 октября привезли один товар и не привезли сетевой фильтр. Три недели попыток хоть как-то решить проблему официально и неофициально безуспешны, за это время не было даже попытки позвонить например мне. Обращение без ответа, операторы врут, фильтра у меня нет, денег у меня…

Cloud CDN: что это такое, как устроено и кому нужно. Разбираем на примере бургеров

Cloud CDN — это сеть быстрой доставки статического контента в формате услуги облачного провайдера. Объяснить, как работает технология, проще всего на примере — сравнить Cloud CDN с популярным продуктом, который выглядит плюс-минус одинаково вне зависимости от того, заказали вы его в Москве, Питере или Нью-Йорке. Знакомьтесь: классический бургер.…

Исследование: сотрудники хотели бы иметь комнату отдыха, бесплатный сок, а работодатели уже готовы покупать ЗОЖ-снеки

Онлайн-сервис доставки продуктов и товаров СберМаркет и исследовательское агентство Research Me спросили сотрудников, как они хотели бы питаться в офисе и что в нем видеть. В опросе приняли участие более 1500 работающих людей по всей России. Сервис также спросил работодателей – В2В-клиентов СберМаркета: что они покупают в офис, что точно никогда…

Как не попасть в карьерную ловушку тимлида: личный опыт

Кажется, что тимлиду просто некуда расти: дальше надо либо идти в менеджмент, либо наоборот, становиться узконаправленным разработчиком. По просьбе «Лаборатории Касперского» Евгений Мацюк, который прошел в компании неординарный путь, рассказал о своих карьерных развилках во время и после тимлидства, а также поделился опытом горизонтального роста.

Реклама в газетах и CRM: как мы массово нанимаем синих воротничков в швейное производство

У нас в Кофтёнышах, 80% сотрудников — это производственный персонал: швеи, упаковщицы, мастера, а 20% — коммерческий и административный: дизайнеры, маркетологи, менеджеры интернет-магазина.

Несколько лет у нас было чёткое деление, где искать людей на свои позиции: синие воротнички на SuperJob и Авито, белые воротнички — на HeadHunter. Со временем видение изменилось, а подход мы систематизировали.

ПСБ запустил личный кабинет для предпринимателей. Там можно следить онлайн за каждым своим терминалом

Сервис предоставляется бесплатно.

Как OTUS стал платформой для самореализации. История преподавателя

Наш преподаватель, специалист по Data Science, решил поделиться своей историей преподавания. Он рассказал, как пришел в эту сферу, с какими трудностями столкнулся на пути к преподаванию и что ему помогает. А еще поделился советами, как поддерживать внимание студентов и сделать занятия полезными и увлекательными.

М.Видео обманул меня с предзаказом Apple Watch Series 7

Печали пост. Как только 8 октября открылся предзаказ на Apple Watch Series 7, поспешил на сайты apple.com, М.Видео и еще несколько маркетплейсов.

Правительство обязало мессенджеры регистрировать пользователей по паспортным данным с марта 2022 года Статьи редакции

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

Я устал жить на автомате и сделал бота в Telegram, который напоминает сколько мне осталось жить

Теперь бот присылает каждую неделю новую таблицу жизни, где видно сколько мне осталось до 90 лет. Красный квадрат – 1 прожитая неделя.

Пример календаря жизни. @life_table_bot
Наладили производство подделок и обманули Лувр: как братья из Одессы заработали на фальшивых древностях Статьи редакции

Шепсель и Лейба Гохманы в конце 19-го века продали Франции подделку под видом древней золотой тиары за 200 тысяч франков и ушли безнаказанными, а создатель украшения прославился в Европе — его тиара до сих пор хранится в Лувре.

Открытка с изображением поддельной тиары скифского царя Сайтаферна Amusing Planet
null