Перефразируя известную фразу: никто не знает, каким будет результат, если нет ТЗ. Отдел аналитики Mad Brains в лице ведущего специалиста Ирины Мироновой рассказывает об этапах создания технического задания, необходимых составляющих документа и тонкостях. Вы узнаете, какое ТЗ точно решит поставленные задачи бизнеса и поможет создать приносящий профит продукт.
Что такое техническое задание Техническое задание – это согласованный сторонами документ, раскрывающий различные стороны разработки. Что может входить в техническое задание? Это зависит от многих аспектов: сложности проектов, выбранных технологий и уровня их понимания участниками проекта.
Какие этапы проработки ТЗ бывают? Обычно сначала командой обсуждаются две вещи:
технологии реализации;
бизнес-требования.
Первичное видение проекта может наложить отпечаток на вариант реализации. Поэтому технологии и их ограничения накладываются на проект.
Следующий этап — детальная проработка бизнес-требований. Аналитик с бизнес-заказчиком детально обсуждают проект и все возможные исключения.
В этот момент самое важное – соотносить желания с реальностью. Каждое требование для реализации в системе будет увеличивать сроки сдачи проекта и отдалять его запуск. Поэтому важно держать в голове MVP (!) и стараться не отходить от него. Помните: зачастую часть действий можно реализовать именно в бизнес-процессе. Электронно-цифровую подпись можно заменить реальной подписью на бумаге, формирование отчетов – выгрузкой максимальных данных в xls для дальнейшей обработки и пр.
Обычно после проработки бизнес-требований есть согласованная bpmn-диаграмма. Почему согласованная? Бизнес должен четко понимать, как это будет работать на деле, а сторона разработки — видеть задачи для анализа и примерные алгоритмы обработки данных. В голове у аналитика в этот момент сформирован набросок будущего проекта, появились ограничения, есть список ролей, есть понимание, с какими системами команде придется интегрироваться и откуда забирать или получать данные, список задач на последующие этапы. Почему список последующих задач появляется именно здесь? Вместе с бизнесом мы «откидываем» все то, что нужно, но мы по разным причинам не успеваем это реализовать в первый или ближайшие релизы. Такие задачи обязательно фиксируются, и из них формируется план для развития проекта.
После этого появляется список функциональных требований к разработке. Такие задачи приоритезируют и оценивают. Оценка позволяет спланировать реализацию задач и сроки проектов. Приоритет учитывает срочность запуска самой задачи и требования ко времени реализации или тестирования. Например, бывают задачи сложные в тестировании или интеграции. Такие задачи стараются проанализировать и описать в начале, чтобы команда быстрее могла приступить к ним.
Когда готов план, запускаются работы по детальной проработке требований. Обычно этот процесс состоит из нескольких этапов.
Изначально аналитик проверяет бизнес-требование и все затронутые бизнес-процессы. Если процессы существуют, опрашиваются эксперты, выясняются детали и отхождение от основных инструкций. Это позволяет спроектировать точки отказа и поведение систем в исключительных ситуациях. По итогу анализа процессов чаще всего появляются bpmn-диаграммы, как вариант — idef и dfd диаграммы. Эти артефакты обязательно согласовываются с бизнесом. Бизнес подтверждает, что процессы на предприятии действительно работают так или предоставляет корректировки.
В момент сбора информации по процессу также выясняются ограничения реализации. Важными ограничениями являются задачи, которые не выпускаются в данном релизе. Также ограничения могут быть напрямую связаны с процессом: например, услуги не предоставляются несовершеннолетним и пользователю нужно проверить паспорт до начала работ. Выявляются риски, которые появляются при реализации проекта. Например, что при количестве заказов более чем 1000 в минуту сервер может проседать в скорости ответа. Кроме этого, выясняются нефункциональные требования: язык, количество пользователей, нагрузки на сервера, объем сохраняемых данных, время доступности сервиса.
В ходе описания бизнес-процессов выясняют роли пользователей. Это будет в дальнейшем влиять на права доступа. С точки зрения безопасности очень важно, чтобы конкретному пользователю были доступны только те данные и действия, которые ему необходимы для выполнения его рабочих задач. Это закроет возможности различных видов атак на информацию. Для быстрого и понятного описания ролей и их взаимодействия с системой зачастую используют uml-диаграмму вариантов использования. Она описывает, какие сценарии могут быть использованы конкретной ролью.
Для наполнения системы данными (например, наполнения справочников) и для управления процессами, пользователями и конфигурациями требуется административная панель. Ее проектирование также необходимо учитывать при разработке технического задания. Данные интерфейсы используются малым количеством людей, которые перед этим зачастую проходят обучение. Поэтому при проработке административной панели акцент делается на функционал.
Главная проблема согласования документации — ее понимание заказчиком. Обычно человек со стороны бизнеса не понимает процессов разработки и не имеет глубоких познаний в технологиях. И не должен их знать. Но документация должна быть согласована. Разработчики и бизнес должны договориться о конечном результате таким образом, чтобы в момент приемочных испытаний заказчик был доволен. Хорошим инструментом для описания пользовательских действия являются user story. Они описывают как именно, при помощи каких шагов пользователь достигает своих целей в системе.
Следующий элемент описания в техническом задании — описание интерфейсов прототипа. Его детализация и инструмент выбирают, исходя из задачи. Если дорабатывается уже существующий функционал, уместно использовать скриншоты с комментариями. Это не потребует большого количества времени, но позволит сориентировать разработчиков.
Если система создается с нуля, то необходимо сделать полноценный прототип. Он может быть динамическим (Axure) и статическим (Figma). Если разрабатывается или дорабатывается семейство систем, сложно интегрированные системы или процесс нелинейный, может потребоваться описание user flow. Он позволит детально рассказать, как пользователь доходит до конца сценария с учетом всех разрабатываемых интерфейсов.
Сердце системы — база данных. Если в системе не будет нужных данных или они будут недоступны, то она не сможет корректно работать. Поэтому проектирование баз данных — крайне важный пункт при проработке задач. Чаще всего для описания БД используется er-диаграмма.
Основное описание алгоритмов работы системы можно сделать различными методиками, чаще всего используются блок-схемы или диаграммы последовательности. Они позволяют наглядно показать этапность обработки данных и отследить состояние процесса в каждый момент. Цель этих инструментов — описать каждый минимальный шаг алгоритма так, чтобы его было просто переложить на программный код. Для сложных интеграционных систем могут также потребоваться архитектурные схемы, показывающие основные для бизнес-процесса потоки данных.
Мобильная разработка подразумевает распределенную архитектуру: проектируется единый backend, который реализует функционал для различных фронтов. Этими фронтами могут быть как различные мобильные приложения, так и web-решение. В таких случаях отдельно проектируется API, для которого описываются методы. Список методов согласуется с реализуемым бизнес-процессом. Например, если директор должен подтвердить платежку, значит должен быть метод подтверждения, в котором проверяются все данные, и платеж переводится в состояние «Подтвержден». Основными параметрами описания метода являются входящие и исходящие параметры и алгоритм обработки данных.
Для подготовки проекта к приемочному тестированию в техническом задании могут быть размещены основные тест-кейсы. Они не покрывают все вариации алгоритмов, а чаще всего показывают основной позитивный путь пользователя, который добивается в системе ожидаемого результата. При необходимости раздел технического задания может быть расширен при командной работе с тестировщиками.
После завершения описания задачи документация должна быть согласована с командой. Бизнес-часть согласовывается с бизнесом, а описание реализации — с командой: прототипы — с дизайнерами, блок-схемы — с разработчиками и т.д. Каждое согласование подразумевает несколько этапов правок, происходит коррекция возможной реализации после обсуждения с командой. После завершения работ над всеми задачами проекта собирается готовое ТЗ. Этапность согласования и параллелизация задач подразумевает четкую версионность ТЗ, которая позволит сохранить все данные и внесенные корректировки.
Хотим отметить, что состав и наполнение технического задания полностью зависит от задач. Если мы дорабатываем небольшой кусок системы и интерфейсы не меняются, то вряд ли в ТЗ нужны прототипы и так далее.
Пример технического задания можно посмотреть здесь.