Аналитики - 1 часть

Кто такой аналитик, зачем он на проекте

Аналитики в разработке делятся на бизнес-аналитиков и системных аналитиков, часто эти роли совмещаются.

Аналитики работают с требованиями.

Требование — совокупность запросов/утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.

Что делают бизнес-аналитики:

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

Что делают системные аналитики:

анализируют утвержденные требования бизнес-аналитиком, чтобы определить, что система должна сделать для выполнения этих требований;
смотрят на решение проблемы с технической точки зрения;
должны обладать сильными техническими навыками отладки, написания запросов, составления технических документов (классов, диаграмм последовательности и т. д.), навыков моделирования данных;
Общаются с ИТ, т.е. с технической командой, и понимают технических людей и технологии:
(на самом деле пунктов больше, но их пропустим).

Если есть совмещение ролей, соответственно, нужно уметь делать всё. На стажировке затрагиваем часть умений бизнес- и системных аналитиков.

Что еще делает аналитик:

формулирует задачи на основе требований разработчику, на этой основе работают и тестировщики;
часто — даёт оценку трудозатрат (в часах) на разработку;
участвует в приоритезации требований вместе с менеджером (product owner, project manager и т. д., кто есть на проекте);
согласовывает требования с заказчиком;
собирает требования в одном месте;
рисует wireframe (макет интерфейса) совместно с дизайнером или самостоятельно;
рисует схемы и диаграммы;
на начальном этапе позволяет составить "границы" проекта, увидеть его "в ширину";
подготавливает источник знаний для технических писателей, юристов, отдела продаж и так далее.

По некоторым исследованиям, от 50% до 70% проектов терпят неудачи из-за проблем с требованиями (выполнялись без них, требований было недостаточно, в них были ошибки, была путаница с приоритетами и т. д.).

Единого шаблона для формирования требований в мире нет. В гибкой методологии разработки (agile), которую будем использовать на стажировке, считается, что:

аналитик должен, в первую очередь, описывать проблемы, которые нужно решить, а не описывать вариант реализации (вариант реализации идет потом).

Работа аналитика на проекте

Нужно выяснить у заказчика: "В чём ваша бизнес-проблема?" Если проект не предполагает бизнес, то просто проблема. Часто заказчик начинает рассказывать не проблему, а сразу вариант реализации. Это нужно корректно остановить и вернуть заказчика к изложению проблемы.

Пример плохого ответа заказчика: "Хочу приложение, чтобы заносить туда гайки".

Пример хорошего ответа заказчика: "У нас производство. В одном месте мы производим болты разного размера, в другом - гайки разного размера. Наша проблема: к нам обращается заказчик, а мы не знаем точно, сколько у нас комплектов "гайка + болт", и какого размера.

За последний месяц мы потеряли 20 клиентов, которым не смогли ответить, сколько у нас комплектов на складе.

Наша цель: точно знать количество комплектов, чтобы менеджер смог во время звонка клиента сразу ответить, что есть на складе и свести потерю клиентов именно по этой причине к 0".

Рекомендовано задание

Сделать гугл-документ с общим доступом по ссылке для команды:

I Раздел: "Общее видение продукта"

Заказчик: ...(кто, учреждение, контактное лицо)
Глоссарий (список терминов - можно назвать как угодно) ....
Участники процесса: (кто участвует в бизнес-процессе заказчика, например: менеджер продаж, мастер цеха, работник производства)... Название - что делает
Бизнес-проблема (общее описание проблемы, в которой участвуют участники процесса)...
Список workflow (рабочий поток, верхнеуровнево) КАК ПРОЦЕСС РАБОТАЕТ СЕЙЧАС (AS IS) от заказчика:

Участник процесса 1:

верхнеуровнево процесс 1.1 (можно только перечислить артефакты, например, документов, с которыми взаимодействует, без деталей)
верхнеуровнево процесс 2.1
верхнеуровнево процесс 3.1

Участник процесса 2...

Например: "Работник производства:

приносит гайки на склад;
приносит болты на склад;
считает гайки и болты вручную....

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

Если есть:

Участник процесса 1:

процесс 1...

6. Ограничения: юридические и т. д., что должны учесть: например, требования к защите персональных данных и т. д.

II Раздел "Вариант реализации" (заполняется при участии разработчиков, т. к. они отвечают, что и как можно реализовать).

Описание решения основной бизнес-проблемы (техническое — создание программного обеспечения, веб-сервиса с такими-то функциями)...
Какие детальные проблемы помогает решать программное обеспечение списком (находить пару болт-шайба, быстро получать список деталей на складе...).
Пользователи программного обеспечения (могут совпадать с "участниками процесса", если при использовании ПО добавляется еще кто-то - нужно внести.)
Список workflow (рабочий поток, верхнеуровнево) КАК ДОЛЖЕН РАБОТАТЬ ПРОЦЕСС (TO BE):

Участник процесса 1:

верхнеуровнево процесс 1.1 (можно только перечислить артефакты, например, документов, с которыми взаимодействует, без деталей)
верхнеуровнево процесс 2.1
верхнеуровнево процесс 3.1

Участник процесса 2...

Например: "Работник производства:

заносит информацию о партии гаек в ПО;
заносит информацию о партии болтов в ПО;
формирует отчет о количество гаек и болтов....

Задачи:

Почитать статью, прикинуть, сколько времени займет подготовка раздела I для того, чтобы встретится с заказчиком (проджект-менеджерами) для его заполнения и согласовать с проджект-менеджерами — желательно не затягивать.
Создать документ, создать раздел I. Поделить задачи между аналитиками.
Перечитать ТЗ, внести в глоссарий непонятные слова.
Подготовить вопросы заказчику: кто участники процесса, какая у вас бизнес-проблема, что делают участники процесса.
Уточнить технические детели: интеграции, ограничения и т. д.
Написать список собственных вопросов, исходя из ТЗ, таблицы к ТЗ, написать вопросы ко всем непонятным моментам.
Показать ментору аналитиков, спрашивать ментора аналитиков.
Обратиться к продакт-менеджерам с документом и вопросами, чтобы назначили встречу с ними (скорее всего, они будут передавать ваши вопросы заказчику, а потом отвечать на них сами — тут как выстроят процесс).
Узнать на встрече ответы на свои вопросы.
Сесть подумать, всё ли понятно.
Уточнять вопросы, можно в slack, можно встречу, если много.
Встретиться с вместе с разработкой и проджектами, и тестировщиками — командой.
Выработать вариант реализации. Выслушать идеи, возражения, зафиксировать. Выбрать один вариант реализации. Если за 1 встречу не получается — до победного конца.
Заполнить Раздел II.
Дать проверить ментору аналитиков.
Согласовать вариант реализации с заказчиком через проджект-менеджеров.
Проджект-менеджеры формируют скоуп (список) доработок, приоритезируют.
Дальше будем собираться опять, чтобы расписывать требования на доработки.

Про необходимость этапа дискавери для аналитиков неплохо написано в этой статье: https://iampm.club/blog/rol-biznes-analitika-na-discovery-faze-proekta/