Функциональная спецификация: описать механику и технологии для каждой функции продукта
Коротко: как в Skipp описывают задачу разработчикам
У традиционного ТЗ, даже если это документ на сто страниц по ГОСТу, много проблем. На рынке все пишут ТЗ по-своему, заказчику в принципе сложно написать полное ТЗ самому, а разработчикам сложно однозначно оценить его.
Когда клиент обращается в Skipp, мы не пишем ему ТЗ, а вместе проходим три этапа предпроектной подготовки. Ими можно заниматься параллельно, но общий логический порядок устроен так:
Концептуальное проектирование, которое клиенту поможет сделать продакт-менеджер. Они вместе разберутся, какой нужен продукт, и создадут USM.
Визуальное проектирование, которое поможет сделать UX-дизайнер. Он продумает интерфейсы, набросает базовый дизайн и создаст прототипы разной степени детализации.
Функциональная спецификация, которой займётся руководитель проекта — продакт, проджект или скрам мастер. Он создаст фич-лист: опишет механику и технологии функций, которые придумали в USM, даст ссылку на прототип или приложит скриншоты.
USM, прототип и фич-лист мы отправим на оценку нескольким командам разработки. По опыту мы знаем: с таким ТЗ клиент получает более однородные и точные оценки от команд, а разработчикам проще провести декомпозицию и собрать бэклог.
Третий и заключительный этап описания задачи в Skipp — это функциональная спецификация.
Здесь мы подробно объясняем механику каждой функции и описываем требования к используемым технологиям.
Функцию описываем так: берём User Story, из которой она родилась, объясняем условия её возникновения или действия, которые совершает пользователь, затем описываем результат функции и прикладываем скриншоты дизайна.
Чтобы быстро создать функциональную спецификацию, важно заранее провести два предыдущих этапа предпроектной подготовки: концептуальный и визуальный. Тогда у вас всегда будет ответ на вопрос «зачем нужна эта функция?» и «как эта функция выглядит?». Функциональная спецификация будет логичным продолжением предыдущих этапов и её подготовка не займёт много времени.
Спецификация, как и другие этапы, помогает сделать более точную оценку стоимости проекта. В спецификации могут вскрыться технические тонкости, которые превратят разработку в нестандартную или просто будут незнакомы разработчикам. Если они увидят что-то новое для себя, то зададут уточняющие вопросы, заложат больше времени.
В Skipp функциональная спецификация состоит из двух элементов. Первый — фич-лист, формат которого мы адаптировали из статьи на Хабре. Это таблица из функций или фич, которые будут в ИТ-проекте. Каждую описывают по шаблону: User Story / Условия возникновения и действия пользователя / Результат / Дизайн. По такому фич-листу легко провести декомпозицию: превратить его в список задач и собрать бэклог.
Второй элемент — описание архитектуры продукта. В некоторых проектах в Skipp используют микросервисную архитектуру. Это значит, что система не монолитная, а состоит из самостоятельных частей — сервисов. Так продукт легче менять и масштабировать. Если потребуется, например, доработать сервис авторизации, разработчик сможет заниматься им, не затрагивая работу других сервисов.
Чтобы показать, какие микросервисы нужны в продукте и как они будут взаимодействовать друг с другом, рисуют схему — описание архитектуры продукта. В простых или типовых проектах схемой архитектуры можно пренебречь.
В Skipp на этом этапе также могут подготовить дорожную карту разработки для заказчика. Это календарный план работы, где наглядно показывают, сколько продлятся верхнеуровые задачи и какие технологии будут использовать в проекте.
Почему важно сделать
Функциональная спецификация обуславливает выбор технологий. Это удобно для работы: разработчикам не придётся додумывать, предпроектная оценка будет более точной, процесс подбора команды ускорится.
Функциональная спецификация помогает согласовать все ключевые моменты разработки до старта. Значит, получится точнее создать смету, будет меньше проблем и ошибок, меньше времени уйдёт на тестирование и доработки. Ещё будет намного проще составлять сопутствующую документацию по проекту. Например, инструкции и руководства для пользователей и документы для испытаний. Александр Лаптев Руководитель команды системных аналитиков, которая работает со Skipp
Что будет, если не сделать
Если не подготовить функциональную спецификацию, разработчики соберут функции, как захотят. Каждая команда будет трактовать задачу по-своему, использовать привычные решения, шаблоны и технологии. Иногда это плохо для проекта: приводит к некорректной оценке, усложняет работу и интеграции с другими системами, снижает гибкость и масштабируемость продукта, накладывает другие технические ограничения.
Если заранее не продумать архитектуру в сложном ИТ-продукте, будет трудно вводить новые сущности, характеристики объектов или пользователей, настраивать взаимодействие между разными компонентами системы. В базах данных могут сделать разную логику. Всё это усложнит работу для команд, которые будут развивать проект.
Кто делает в Skipp
Руководитель проекта, который будет общаться с разработчиками: продакт-менеджер, проджект-менеджер или скрам-мастер.
Если в проекте сложная архитектура, функциональную спецификацию делает системный архитектор или системный аналитик.
Вовлечённость заказчика
Минимальная: функциональную спецификацию для разработчиков готовят руководители проекта, архитектуру — аналитики. Заказчику будет важно изучить только дорожную карту.
Артефакт этапа в Skipp
Фич-лист, описание архитектуры продукта, дорожная карта разработки.
