Порядок, экономия, скорость — зачем проекту нужен аналитик
В разработке сайтов, приложений или порталов участвует целая команда специалистов. Работу разработчиков и дизайнеров сложно недооценить, но есть специалист, чью работу считают несущественной, а она напрямую влияет на результат, — это аналитик. Расскажем, зачем нужно привлекать его к работе над проектом, а также об этапах его работы.
Существует множество категорий аналитиков — они собирают данные, анализируют их и делают выводы, как улучшить то или иное направление проекта. Мы остановимся на специалисте, который помогает компаниям понять, в чем нуждается бизнес, и оценить, получится ли это реализовать, — на бизнес-аналитике.
Аналитические подходы
При работе над проектом важно не только привлечь аналитика, но и определить его подход к работе. Подход зависит от финансов и времени и выражается в том, когда именно аналитик подключается к проекту. Мы выделяем три подхода к аналитике проекта.
Подход № 1. Документация создается до разработки
Разработчики приступают к работе с готовой документацией. Подход дает максимальную скорость разработки и предсказуемый результат.
Плюсы подхода:
- предсказуемый результат разработки;
- максимальная скорость разработки;
- предсказуемые сроки ввода продукта в эксплуатацию;
- минимум исправлений и переделок;
- подходит для «водопадного» управления проектом.
Минусы:
- сложно внести изменения в разрабатываемый продукт;
- увеличивается срок ввода проекта в эксплуатацию;
- функционал продукта может потерять актуальность во время написания документации;
- низкая гибкость разработки продукта;
- не подходит для Agile-проектов;
- существенный «люфт» во взаимодействии между бизнесом и разработкой.
Подход № 2. Документация создается параллельно с разработкой
Этот подход построен на тесном взаимодействии бизнеса и разработки. Аналитик начинает работать одновременно с командой разработки. Все стороны активно участвуют в создании документации — это позволяет адаптировать продукт прямо во время разработки, если какая-то функция или решение больше неактуальны.
Плюсы:
- сокращается срок ввода продукта в эксплуатацию;
- бизнес и разработка тесно взаимодействуют друг с другом;
- продукт можно адаптировать в ходе разработки;
- подходит для Agile-проектов.
Минусы:
- повышаются риски существенных переделок и исправлений в ходе разработки продукта;
- высокая нагрузка на аналитика в начале проекта, поскольку аналитик стремится обогнать разработку по темпу;
- риски упустить существенные верхнеуровневые требования;
- плохо сочетается с «водопадным» подходом к управлению проектом;
- потенциально создает стрессовые ситуации для команды, так как не все члены команды понимают суть проекта.
Подход № 3. Комбинированный
Этот подход используется чаще всего. Бизнес-требования и общий раздел документации подготавливают до начала разработки, а все остальное — в процессе разработки. Такой подход позволяет составить четкое представление продукта с точки зрения бизнеса и адаптировать продукт в процессе разработки.
Плюсы:
- четкое представление продукта с точки зрения бизнеса;
- сокращение срока ввода продукта в эксплуатацию, но не настолько, как при предыдущем подходе;
- подходит как для Agile-проектов, так и для «водопадного» подхода к управлению проектами;
- тесное взаимодействие бизнеса и разработки;
- средняя стоимость и средний уровень рисков исправлений;
- равномерная нагрузка на аналитика.
Минус:
- не самые короткие сроки ввода продукта в эксплуатацию.
Этапы аналитики
Количество этапов аналитики различается от проекта к проекта. Мы обычно выделяем четыре этапа. Список документов непостоянный и может изменяться под конкретный проект.
Список документов, которые готовил наш аналитик для работы над проектом «Кредитный брокер»
Этап № 1. Выявление бизнес-требований
Бизнес-требования — это основной перечень документов, который определяет, какие потребности бизнеса решает разрабатываемое приложение. Если в какой-то момент разработки теряется верное направление, то можно обратиться к бизнес-требованиям, чтобы опереться на них.
На этом этапе создаются следующие документы.
| Документ | Описание |
|---|---|
| Документ Vision | Составляется в первую очередь. Полноценно, точно, но кратко описывает концепцию и ценности проекта для клиентов и внешний вид проекта для разработчиков. Описывает, какие проблемы решает продукт или какие цели преследует. Изучив его, аналитик и команда разработки понимают, чего именно хочет клиент, и составляют бизнес-правила. |
| Документ о границах проекта | Описывает границы проекта: какие фичи и части должны входить в него, а какие — нет. В этом документе также указываются сроки и этапы сдачи проекта. |
| Бизнес-правила | В любой организации действует широкий набор корпоративных политик, законов и промышленных стандартов. Все эти контролирующие принципы в целом называются бизнес-правилами. Здесь указывается, что должен делать продукт, а не как. Все бизнес-правила должны быть реализованы и должны поддерживаться в соответствии с более детально описанными требованиями: сценариями и пользовательскими историями. |
| Возможности бизнеса | Описывает цели и задачи продукта, а также способы их решения и технико-экономические показатели успеха. |
| Бизнес-цели | Описывает заранее установленные ориентиры, которых продукт должен достичь за определенный период времени. |
| Критерии успеха | Совокупность показателей, которые помогают оценить успешность проекта. |
Этап № 2. Разработка общей документации
В общей документации дается определение всех понятий, описываются все объекты, роли, структура решений.
На этом этапе создаются следующие документы.
| Документ | Описание |
|---|---|
| Глоссарий | Создается на основе Vision и бизнес-правил и содержит список всех технических и бизнес-терминов, чтобы бизнес-стейкхолдеры* и разработчики говорили на одном языке. |
| Концептуальная модель | Абстрактная модель, которая определяет структуру проекта, свойства ее элементов и причинно-следственные связи. Модель необходима архитекторам, разработчикам, аналитикам для формирования архитектуры решения. На основе концептуальной модели создается логическая модель данных и описание спецификации объектов, по которым можно создавать структуру базы данных (БД). |
| Архитектурная модель | Представляет всесторонний обзор архитектуры проекта. Модель показывает разработчикам и другим членам команды важные с точки зрения архитектуры решения, принимаемые для реализации проекта. |
| Диаграмма классов / ER-диаграмма | Определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. |
| Спецификация объектов | Понятно и точно описывает существенные технические требования для объектов, материалов или операций. Объекты — это цифровые аналоги реальных сущностей, но описанные в контексте программного обеспечения (ПО), которые необходимы для его функционирования. Описываются только существенные для ПО атрибуты и методы работы с этими аналогами. |
| Описание ролей | Представляет собой текстовое описание ролей для пользователей системы. Готовится на каждую роль отдельно. |
| Матрица доступности функций | Содержит детальное описание функций, доступных определенной роли пользователя. |
*Бизнес-стейкхолдер — это физическое или юридическое лицо или группа лиц, чьи действия и решения могут влиять на деятельность бизнеса, процессы в нем и прибыль. К стейкхолдерам относятся поставщики, сотрудники, акционеры, заказчики ПО, клиенты и другие стороны, которые напрямую заинтересованы в работе компании и ее результатах или имеют возможность воздействовать косвенно.
Этап № 3. Формирование функционального раздела требований
Этот раздел содержит задачи для разработчиков. В этих документах можно найти полное содержание всех возможных ответов на вопросы, которые могут возникнуть в процессе разработки.
На этом этапе создаются следующие документы.
| Документ | Описание |
|---|---|
| Верхнеуровневая диаграмма деятельности | Описывает действия системы или людей, выполняющих действия, и последовательный поток этих действий. Диаграмма деятельности — самая простая и понятная для всех участников команды, поскольку похожа на обычную блок-схему, но более подробная. |
| Требования в формате Use Case | Представляет собой пошаговый сценарий взаимодействия пользователя с проектируемой системой. Такое представление включает в себя описание метаданных этого взаимодействия: областей применения, предусловий, триггеров, постусловий, релевантных бизнес-правил и прочего. |
| Модель BPMN | Блок-схема, которая отображает этапы выполнения бизнес-процесса от начала до конца. BPMN-схемы наглядно и подробно демонстрируют последовательность рабочих действий и перемещение информационных потоков, необходимых для выполнения процесса. Это один из ключевых инструментов управления бизнесом. |
| Диаграмма последовательности | Отображает жизненный цикл объекта и взаимодействие действующих лиц информационной системы в рамках единого сценария для некоторого набора объектов на единой временной оси. |
| Спецификации интеграций | Детальное описание интеграционных сценариев, например, платежных систем или онлайн-карт. А также дополнительная информация, описывающая аспекты интеграции: тип, модели данных, параметры и нефункциональные требования интеграции. |
| Низкодетализированные макеты экрана | Изображения экранов проекта. На них должна быть только основная информация о переходах и функциях. |
| Диаграмма переходов между экранами | Простая, удобная и наглядная диаграмма, подходящая для моделирования переходов между экранами, отображения сообщений, системных действий и процедур. |
| Спецификации экранных форм | Подробное описание элементов пользовательского интерфейса и их атрибутов: тип данных, размерность, маски, источник данных и прочее. |
| User Story | Описание пользовательских требований в одном или двух предложениях. В предложениях формулируют потребность пользователя или описывают конкретную функцию, а также говорят о пользе, которую эта функция приносит пользователю. |
Этап № 4. Подготовка требований к реализации
Аналитик согласовывает разработанные документы со всеми командами разработки и готовит их к реализации.
Необходимо согласовать документы:
- с бизнес-стейкхолдерами, чтобы подтвердить, что это нужно бизнесу;
- разработчиками и архитектором, чтобы понять, что эти требования можно реализовать в указанные сроки;
- тестировщиками, что эти требования можно протестировать.
На этом этапе создаются следующие документы.
| Документ | Описание |
|---|---|
| Структурная модель функций | Это иерархическая модель, которая отображает связь между отдельными сценариями, нужными для реализации конкретных функций. Эти функции позволяют достичь определенной бизнес-ценности. |
| Задачи в таск-трекере | Аналитик создает задачи в таск-трекере, откуда проджект-менеджер распределяет их по разработчикам. |
Выгоды от участия аналитика в проекте
Аналитик не просто делает работу команды комфортнее — он экономит общее время и стоимость разработки проекта. Плюсы работы с аналитиком:
1. Улучшает коммуникацию. Причем как внутри команды, так и с внешними лицами. Это сокращает издержки при разработке, связанные с совещаниями и обсуждениями.
2. Упрощает ведение документации. Все связанные доработки описаны либо в отдельных документах требований, либо переиспользуют уже согласованные и реализованные ранее требования.
Документация ведется однородно, понятно, с сохранением истории требований. Это позволяет вернуться назад к прежним требованиям и тратить минимальное количество времени на последующую доработку ПО.
3. Экономит время разработчиков. Благодаря тому, что код пишется по согласованным требованиям, разработчикам не приходится тратить время на лишние обсуждения. «А как же это должно работать?», «Что же хочет бизнес?» --- это все уже выяснили аналитики, которые более профессиональны в сборе, выявлении, документировании и согласовании требований.
Один аналитик обеспечивает информацией небольшую команду разработчиков, позволяя последним сконцентрироваться на написании кода. Это сокращает время переключений разработчиков с задачи на задачу, снижает дополнительные расходы времени и уровень стресса в команде.
4. Снижает непрофильную нагрузку с руководителя проекта и владельца продукта. Им не приходится детально описывать требования и ставить задачи разработчикам. Поэтому процесс не провисает и не уходит на дополнительные круги разработки. Это становится возможно благодаря однородной документации, которая составляется по однозначным методикам, общим для всего проекта.
Документация также дает членам команды понять, как работать с требованиями, какие ограничения учитывать при разработке и где есть пространство для творчества.
5. Четко обрисовывает результат. На выходе получается именно то, что нужно заказчику и удовлетворяет его требования. Все белые пятна и двойственности устраняются на этапах выявления требований. Предусматриваются все отхождения от основного позитивного сценария, и на каждое отхождение описывается алгоритм действий. Это сокращает издержки при разработке, связанные с переделками и лишними доработками.
6. Уменьшает время адаптации новых сотрудников. Благодаря однородной и детальной документации, новые сотрудники переходят к эффективной работе за минимальный срок.
7. Определяет четкие сроки проекта. Подход «от общего к частному» позволяет уже на начальном этапе оценить сроки реализации проекта с определенной точностью, которая увеличится при более детальном описании.
8. Дает импульс для начала проекта. Некоторые проекты застревают на этапе планирования, а некоторые так и не выходят в свет. Это происходит из-за неопытности команды или величины проекта, когда ни команда, ни руководитель не знают, с чего начать.
Аналитик берет идеи и превращает их в четкую документацию, которой можно следовать во время разработки. У проекта появляется план и структура, и он не стоит на месте.
Работа аналитика во многом позволяет снизить расходы времени, а следовательно, и денег на разработку проекта и легко увеличивать численность команды. Она делает проект контролируемым, снижает общий уровень стресса в команде и позволяет каждому члену команды заниматься своими профильными обязанностями.
В 2023 году качественная разработка продукта невозможна без полноценного и всестороннего анализа. Заказчику важно разбираться в аналитических подходах и спрашивать у компании-разработчика, какими методиками они пользуются.
В следующих статьях мы рассмотрим аналитику на примерах конкретных финтех-проектов. Подписывайтесь на наш Telegram-канал, чтобы не пропустить их.
У вас есть проект, но вы не знаете, сколько времени и денег он потребует? Заполните форму и запишитесь на бесплатную консультацию.