Разбираем задачу бизнеса до того, как команда возьмёт продукт в разработку: проводим интервью с заинтересованными сторонами, собираем и анализируем требования, выстраиваем карту пользовательских историй и готовим документацию, по которой дизайнер, разработчики и тестировщики понимают задачу одинаково.
Бизнес-аналитик FITTIN разбирает задачу вместе с заказчиком: выясняет, какую проблему бизнеса решает продукт, кто им пользуется и по каким сценариям, какие ограничения задают действующие процессы и смежные системы. Результат работы — согласованный перечень требований и документация, по которой команда разработки ведёт проект без домыслов.
Услуга работает и как отдельный этап перед стартом разработки, и как усиление проекта, который уже идёт: когда требования расходятся между отделами, объём работ растёт от спринта к спринту, а команда переспрашивает по каждой второй задаче.
О компанииРабота аналитика складывается из четырёх направлений. На небольшом продукте они проходятся одним циклом, на крупном — повторяются по каждому функциональному блоку.
Собираем требования от бизнеса, пользователей и смежных систем, отделяем обязательное от желательного, проверяем формулировки на противоречия и выполнимость. На выходе — перечень требований с приоритетами, понятный и заказчику, и команде разработки.
Разговариваем с теми, кого затрагивает продукт: руководителями, сотрудниками продаж, поддержки, логистики, ИТ-службы. У каждой роли своя картина процесса — задача аналитика собрать их в одну и снять расхождения до старта разработки.
Раскладываем продукт на сценарии пользователя и шаги внутри них: что человек делает, в каком порядке, что должно произойти в системе. Карта пользовательских историй (User Story Map) показывает объём целиком и помогает разделить его на очереди разработки.
Переводим согласованные требования в документы: описание продукта, ролей и прав доступа, требования по экранам и сценариям, правила обработки данных, требования к интеграциям со смежными системами.
Смежные направления. Если по итогам аналитики нужен документ для договора и приёмки — это разработка технического задания. Если продукт нужно проверить на пользователях короткой версией — разработка MVP. Саму разработку продукта закрывают разработка ПО на заказ и корпоративные приложения.
Аналитика и техническое задание — соседние этапы одной цепочки. Аналитик выясняет, что нужно бизнесу и пользователям, и фиксирует это в требованиях. Техническое задание переводит согласованные требования в документ для разработки: экраны, роли, правила обработки данных, требования к интеграциям.
Обе задачи часто закрываются одним пакетом работ: команда начинает с интервью и карты пользовательских историй, а заканчивает готовым техническим заданием, по которому фиксируются стоимость и срок в договоре. Аналитика нужна и отдельно — когда требования собираются под уже идущий проект или под выбор подрядчика.
Что подойдёт вашему проекту, определяем на первом обсуждении: сначала смотрим объём продукта и состояние требований, потом выбираем формат работы.
Разработка ТЗПроект проходит одну и ту же последовательность — от знакомства с задачей до передачи документации команде разработки. У каждого этапа свой конечный результат, который передаётся заказчику.
Изучаем задачу бизнеса, действующие процессы и системы, определяем границы продукта и список тех, с кем предстоит говорить. Фиксируем цель продукта и критерии, по которым его будут оценивать.
Проводим встречи с заинтересованными сторонами, разбираем сценарии работы, ограничения смежных систем и ожидания от продукта. Требования записываем в единый перечень.
Проверяем требования на противоречия и выполнимость, отделяем обязательное для запуска от того, что относится к развитию продукта, согласуем приоритеты с заказчиком.
Раскладываем продукт на сценарии и шаги пользователя, связываем их с требованиями, размечаем очереди разработки. Карта показывает объём продукта целиком.
Оформляем согласованные требования в документы и передаём их команде разработки. Дальше аналитик отвечает на вопросы по документации и уточняет формулировки по ходу проекта.
Каждый этап заканчивается документом, который остаётся у заказчика. Материалы написаны так, чтобы их читали и бизнес, и команда разработки.
Требования от бизнеса, пользователей и смежных систем в одном списке: что обязательно для запуска, что относится к развитию продукта. Формулировки проверены на противоречия и согласованы с заказчиком.
Сценарии пользователя разложены по шагам и связаны с требованиями. По карте видно объём продукта целиком и понятно, что входит в первую очередь разработки, а что — в следующие.
Описание продукта, ролей и прав доступа, требования по экранам и сценариям, правила обработки данных, требования к интеграциям со смежными системами.
По согласованным требованиям команда разработки оценивает объём работ и срок. По этим же документам потом принимают результат — сверяют готовый продукт с тем, о чём договаривались на старте.
Стоимость зависит от объёма продукта и состояния требований на входе, поэтому точную цену называем после обсуждения задачи. Работаем по двум моделям — выбираем ту, что подходит под формат проекта.
объём известен заранее
Состав работ фиксируется на старте: сколько функциональных блоков разбираем, с кем проводим интервью, какие документы готовим. На этой основе стоимость и срок закрепляются в договоре.
объём гибкий
Оплата по факту отработанных часов, оценка со сметой перед стартом задачи. Подходит, когда аналитик подключается к идущему проекту и объём уточняется по ходу работы.
сценарии и роли
Количество пользовательских сценариев, ролей и функциональных блоков определяет, сколько требований предстоит собрать, проверить и описать.
что есть на входе
Когда часть материалов уже собрана — процессы описаны, сценарии понятны, — работы меньше. Когда продукт обсуждается с нуля, цикл интервью и согласований длиннее.
данные и интеграции
Учётные системы, CRM, платёжные сервисы и внутренние сервисы компании задают ограничения. Чем их больше, тем дольше разбор данных и правил обмена.
| Входит в стоимость | Оплачивается отдельно |
|---|---|
| Интервью с заинтересованными сторонами и сбор требований | Разработка полного технического задания для договора и приёмки |
| Анализ требований, снятие противоречий и согласование приоритетов | UX/UI-дизайн и прототипы экранов |
| Карта пользовательских историй и функциональная документация | Разработка продукта и подключение интеграций |
| Ответы на вопросы команды разработки по документации | Новые функциональные блоки сверх согласованного объёма |
Механика оценки. Работа стартует с обсуждения задачи: смотрим, что по продукту уже описано, какие функциональные блоки предстоит разобрать и с кем нужно поговорить. По итогам фиксируем объём работ, стоимость и срок. До этого возможен только предварительный ориентир. Изменения объёма по ходу работы оформляются дополнительным соглашением.
Когда по итогам аналитики нужен документ для договора и приёмки — это разработка технического задания. Прикинуть бюджет и срок будущей разработки можно на калькуляторе стоимости.
Бизнес-аналитик выясняет, какую задачу бизнеса решает продукт, кто им пользуется и по каким сценариям, какие ограничения задают действующие процессы и смежные системы. Он проводит интервью с заинтересованными сторонами (в индустрии их называют стейкхолдерами), собирает требования в единый перечень, снимает противоречия между отделами, раскладывает продукт на пользовательские сценарии и описывает результат в документации. По этой документации команда разработки оценивает объём работ и ведёт проект.
Бизнес-аналитика отвечает на вопрос, что нужно бизнесу и пользователям: требования, сценарии, приоритеты, ограничения смежных систем. Техническое задание переводит согласованные требования в документ для разработки и для договора — с описанием экранов, ролей, правил обработки данных и требований к интеграциям. Это соседние этапы одной цепочки: аналитика даёт материал, техническое задание оформляет его в документ, по которому фиксируются стоимость, срок и приёмка. Разработку технического задания FITTIN ведёт отдельной услугой, и обе задачи можно закрыть одним пакетом работ.
User Story Map — карта пользовательских историй: продукт разложен на сценарии пользователя и шаги внутри каждого сценария. По горизонтали идёт путь человека от первого действия до результата, по вертикали — функции, которые этот шаг обеспечивают. Карта показывает объём продукта целиком на одном полотне и помогает разделить его на очереди разработки: что входит в первую работающую версию, а что относится к развитию продукта.
Стоимость зависит от объёма продукта, состояния требований на входе и количества смежных систем. Мы работаем по двум моделям: Fix Price — состав работ и документов фиксируется на старте, стоимость и срок закрепляются в договоре; Time & Materials — оценка по часам со сметой перед стартом задачи, удобно, когда аналитик подключается к идущему проекту. До обсуждения задачи возможен только предварительный ориентир.
Аналитик составляет список тех, кого затрагивает продукт: руководителей, сотрудников продаж, поддержки, логистики, ИТ-службы. С каждой ролью проходит отдельная встреча по заранее подготовленным вопросам — как устроен процесс сейчас, где он даёт сбои, что должно измениться. Встречи идут онлайн или в офисе заказчика, записи расшифровываются, а расхождения между ролями выносятся на общее согласование.
Да. Аналитик разбирает текущее состояние требований, приводит их к единому виду, дописывает недостающие сценарии и фиксирует договорённости, которые до этого жили в переписке. Отдельно разбираются места, где требования расходятся между отделами, — их выносим на согласование с заказчиком. Такой формат не требует остановки проекта: аналитик подключается к текущим задачам команды.
Перечень требований с приоритетами, карта пользовательских историй, функциональная документация по продукту: описание ролей и прав доступа, требования по экранам и сценариям, правила обработки данных, требования к интеграциям со смежными системами. Материалы передаются заказчику и остаются у него — по ним можно оценивать объём работ и принимать готовый продукт.
Начните с обсуждения задачи: расскажите, какую проблему бизнеса решает продукт и какие процессы он затрагивает. Этого достаточно, чтобы определить объём аналитики и состав работ. Дальше цепочка стандартная: интервью и сбор требований, карта пользовательских историй, документация, затем разработка технического задания и оценка проекта.
