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

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

Задача аналитика при разработке ТЗ

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

Со стороны бизнеса это, как правило — собственники, руководители, акционеры. Со стороны разработки: разработчики, проджект-менеджеры, QA-специалисты и др. Со стороны внешних систем (от бизнеса или технической команды исполнителя) — архитекторы ПО либо разработчики.

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

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

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

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

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

Процесс проработки ТЗ

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

1. подготовить общее верхнеуровневое описание проекта
2. определить бизнес-задачи проекта в целом
3. сформировать список всех стейкхолдеров
4. определить список пользовательских требований (кто, что и зачем делает).

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

Этапы проработки ТЗ:

1#

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

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

2#

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

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

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

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

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

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

3#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

ТЗ помогает:

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

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

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