Skip to main content

Методология работы аналитика на проекте

Задачи аналитика на проекте#

  1. Сбор или изучение верхнеуровневых требований по проекту, их приоритезация (совместно с менеджером) и декомпозиция задач на аналитику (или блоков задач, направлений работы). Например, в формате User Stories.
  2. Подготовка документации
    1. Общие документация по проекту - эти документы должны актуализироваться по ходу проекта и/или после завершения разработки
      1. модель данных (например, ERD или UML Class diagram)
      2. ролевая модель
    2. Требования к проекту (для разработки)
      1. описания процессов (BPMN, UML Use Case diagram, UML Activity diagram)
      2. функциональные требования (например, в формате Use Cases с критериями приемки)
      3. нефункциональные требования
      4. требования к контрактам
      5. изменения в архитектуре решений и структуре хранения данных
    3. Закрывающая документация по проекту

До старта проекта необходимо согласовать с клиентом:

  • нужны ли закрывающие документы и какие
  • формат документации (например, клиент может принимать только BPMN)
  • где должны быть размещены документы (confluence, google docs, etc). если пространство закрытое, у аналитика должен быть к нему доступ

Выяснение и уточнения требований может проходить:

  • на встречах. К встрече аналитик должен подготовить вопросы и после нее зафиксировать договоренности по своей части (в системе планирования или непосредственно в документе с требованиями)
  • в системе планирования через комментарии в задаче
  • в документе с требованиями через комментарии и меншн клиента

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

  1. Поддержка разработки, тестирования, UX на этапах их работы. То есть ответы на вопросы по функционалу в чатах телеграмм, даже если аналитик уже занят на других проектах. Если вопросы объемные (более 30мин) и/или не касаются уже сданного аналитиком функционала, необходимо запланировать отдельную задачу.

  2. Аудит UX макетов на их соответствие требованиям. Необходимо проверить, весь ли функционал учтен в макетах и нет ли лишних функций.

  3. Приемка функционала. Т.е. дополнительная проверка функционала на соответствие требованиям после QA.

  4. Презентация функционала заказчику (например, в формате демо) и подготовка пользовательских инструкций, шаблонов (например, файлов на импорт).

Формат работы аналитика на проекте#

Возможны 2 варианта работы

  1. Работа в системе планирования клиента. В этом случае для аналитика создается общая задача на месяц. Время списывается в эту общую задачу с комментарием, что было сделано за день. Коммуникация с клиентом происходит в системе планирования клиента (чаще всего Jira или Wrike).
  2. Классическая работа в redmine.

Пример организации работы:

  1. Аналитик получает постановку от клиента (например, в формате BRD, описания проблемы в jira/wrike или задачи в redmine)
  2. Аналитик уточняет требования, описывает их и готовит постановку на разработку, в том числе критерии приемки
  3. (если прототипы есть) Аналитик аудирует UX макеты на соответствие требованиям
  4. Аналитик согласовывает требования, передает задачу менеджеру или сразу в разработку
  5. После QA, аналитик тестирует функционал на соответствие ФЗ и презентует его клиенту (или просит клиента принять самому)

Онбординг

При старте работы на проекте аналитику необходимо предоставить

  1. Описание цели всего проекта и его этапов. Описание блока, над которым будет работать аналитик.
  2. Требования к организации работы (где ведется планирование, по какой методологии (Agile, Kanban) и формату документов (если есть от клиента).
  3. Доступы к системе планирования и пространству для документации.
  4. Уже готовые артефакты: архитектурная схема, модели данных, требования, зафиксированные клиентом.
  5. Доступы на SELECT к БД или ее реплике (если есть).
  6. Приглашения во внутренние чаты ТГ по проекту (кроме управления) и релевантные чаты с заказчиком.

Что еще нужно учесть#

  1. Постановки не должны содержать требований к интерфейсу
    1. типы интерфейсных элементов (кнопка, раздел сайта/админки и т.п.) 
    2. названия интерфейсных элементов (кнопка “Сохранить”)

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

НеверноВерно
Пользователь нажимает на кнопку “Сохранить” для добавления товара в избранноеПользователь добавляет товар в избранное
Пользователь может перейти в раздел “Товары” для просмотра списка товаров.

Пользователь может просмотреть список товаров.

1. Доступна фильрация товаров по:

- цене (<название сущности и параметра в БД>), тип: от - до

- бренду(<название сущности и параметра в БД>), тип: множественный выбор

- …

При выборе фильтров список товаров обновляется только после того, как пользователь применил фильтры.

2. Доступна сортировка по:

- цене (<название сущности и параметра в БД>), тип: по возрастанию, по убыванию

- популярности (<название сущности и параметра в БД>), тип: по возрастанию, по убыванию

Сортировка по умолчанию: по популярности.

3. В списке товаров отображаются товары

- опубликованные на выбранной витрине (<название сущности и параметра в БД> = <значение>)

- только в наличии (<название сущности и параметра в БД> = <значение>)

4. В списке товаров должна отображаться следующая информация по товару

- название (<название сущности и параметра в БД>)

- фотография (<название сущности и параметра в БД>)

- цена (<название сущности и параметра в БД>)

- возможные модификации (<название сущности и параметра в БД>)

5. В списке товаров пользователю доступны действия:

- добавить товар (модификацию товара) в корзину

- изменить количество товаров (модификации товаров) в корзине

- удалить товар (модификацию товара) из корзины

- добавить товар (модификацию товара) в избранное

- удалить товар (модификацию товара) из избранного

6. …

  1. На наших проектах принят подход contract first. То есть контракт должен быть подготовлен до разработки API. Контракты, подготовленные аналитиком, должны пройти аудит со стороны разработки до согласования их с клиентом.

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