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

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

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). если пространство закрытое, у аналитика должен быть к нему доступ

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

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

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

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

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

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

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

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

Возможны 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. …

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

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