Перейти к основному содержимому

Greensight Analysts Guide

Цель данного гайда - зафиксировать процесс сбора и формализации требований аналитиком платформы.

Шаг 1. Сбор требований​

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

Источники бизнес требований​

  1. Стейкхолдеры.

На встречах со стейкхолдерами необходимо:

Дать заказчику возможность рассказать и показать.

Задавать вопросы, не внедряясь в детали.

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

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

  1. Артефакты.

Заказчиком могут быть предоставлены следующие артефакты:

Дизайны или макеты.

Архитектурные схемы.

Документация по аналитике.

  1. Системы заказчика.

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

  1. Анкетирование.

Менее распространенный способ сбора требований.

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

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

Шаг 2. Декомпозиция​

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

  1. Собранные требования необходимо сгруппировать по эпикам ( Управление заказами, Настройка каталога, Товары, Контент и тд).
  2. Эпики должны включать себя список будущих задач - одна задача = один документ на разработку (Настройка каталога может включать такие задачи, как атрибуты, категории, справочники).
  3. Затем дополнительно согласовать с заказчиком по всему списку порядок взятия каждого требования в работу ( MVP / не MVP или 1,2, 3 этап).

Если есть ограничения по срокам, необходимо следить, чтобы в 1 итерации:

  • были только требования, без которых нельзя осуществить поставленную цель.

  • для требований с более сложным функционал были найдены простые альтернативы.

Полученный список - скоуп проекта. Каждое требование в нем отдельная задача. Любой выход за его рамки должен быть согласован с менеджером и аккаунт-директором.

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

  • Что является наиболее важным для достижении цели?

Если цель продавать товар, то важнее является товар, а не баннер.

  • Какие задачи связаны друг с другом?

Чтобы порядок задач не приводил блокерам. Пример: начала берем категории и атрибуты , а потом товар, так как в товаре используются категории и атрибуты.

Шаг 3. Описание документации.​

Скоуп утвержден, теперь можно писать документы на разработку.

В зависимости от проекта они могут называться по разному (ФЗ, US, ТЗ и тд), может отличаться шаблон для оформления, добавлены специфические разделы необходимые для заказчика. Но есть критерии, которые должны быть учтены в каждом документе.

MUST HAVE

  • Бизнес-требования - краткий список верхнеуровневых требований бизнеса, покрываемых разработкой задачи.

  • Функциональные требования - перечень функций выполняемых пользователем или системой в структурированном порядке.

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

  • Требования к данным - описание таблиц, которые должны появится в базе данных в результате реализации.

  • Интеграции - список эндпоинтов с ссылками на их описание, разрабатываемых в рамках задачи.

  • Сиквенс - диаграмма последовательности, необходима если задача на разработку сложных взаимодействий в системе (интеграция с несколькими эндпоинтами и/или системами; флоу заказа или любой другой сущности с расширенной статусной моделью).

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

Шаблоны и примеры можно посмотреть в примерах документации.