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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ТЗ помогает:

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

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

#аутсорс #программирование #product #project #разработка #разработчики #приложение #azoft #аутсорсинг #аналитика #системныйанализ #бизнесанализ #тз