Аналитика в IT: виды и как они влияют на успех продукта

Аналитика требуется не только на старте, но на других этапах разработки:

• На первых этапах разработки исследование необходимо, чтобы выстроить общий «каркас» решения, которое опирается на бизнес-потребности, и позволяет сразу видеть, в каком направлении будет развиваться продукт.
• Бизнес и окружение не стоят на месте - требуется анализировать текущую работу системы, вносить своевременные доработки и реализовывать новые актуальные функции.
• Новые возможности нужно бесшовно вписывать в текущую архитектуру системы и выводить в Prod максимально быстро. Без качественной аналитики существенно повышаются риски дорогостоящих ошибок.

В этой статье мы хотим показать «внутреннюю кухню» аналитиков и рассказать, какие виды аналитики существуют и какие задачи решает каждый из них. Начнем по порядку.

Типовые роли участников IT – проекта

Эти роли можно разделить на 2 категории - представители со стороны заказчика и представители команды разработки.

• Заказчик - лицо (или круг лиц), которое формулирует, какую итоговую цель должен достигать продукт, который мы разрабатываем. 
• Пользователи - люди, которые будут непосредственно пользоваться продуктом, выполняя задачи на пути к озвученной цели. Иногда пользователем может являться заказчик, но чаще это разные люди. 
• Менеджер проекта - человек, который отвечает за организацию процесса разработки: за коммуникации внутри команды, за коммуникации с заказчиком и за своевременное выполнение работ и достижение результата. 
• Аналитик, архитектор и проектировщик - не просто так указаны вместе. Они решают очень похожие задачи: моделируют будущий продукт, выявляют спорные/критические моменты, предлагают идеи решения. 
• Разработчик — это человек, который занимается непосредственно написанием кода.
• Тестировщик - человек, который контролирует качество продукта: в плане ошибок и в плане достижения итогового результата.

Подробно поговорим про задачи аналитика. Их условно можно разделить на 2 части: те, которые больше относятся к бизнес-анализу, и те, которые больше относятся к системному анализу.

Бизнес-анализ

Сюда относятся:

• Оценка продуктовых и технических метрик. К нам пришел заказчик, рассказал, что он хочет, а аналитик погружается в предметную область и начинает продумывать объективные показатели достижения поставленных целей. Например: что-то ускорить, автоматизировать, сделать дешевле, увеличить количество пользователей. В итоге аналитик отвечает на вопрос: как мы поймем, что поставленные цели достигнуты? И это является ключевыми метриками продукта.
• Сбор и классификация информации. Вводная информация может быть предоставлена в разных видах: подробное ТЗ, рассказ своими словами. Одним из ключевых навыков аналитика является умение собирать эту информацию через интервью, опросы и структурировать.
• Построение процессных и технологических цепочек. Аналитик формирует верхнеуровневое видение достижения поставленных целей.
• Анализ пользовательского поведения и сценариев. Это, в частности, UX-анализ, проработка различных краевых ситуаций - ошибки, подсказки и так далее. 
• Декомпозиция сложных сценариев на атомарные этапы и результаты. Разбиение сложных сценариев на более мелкие этапы, которые дадут быстрый результат. Конкретные, тестируемые и полезные кусочки системы.

Системный анализ

Обычно результатом качественного бизнес-анализа являются:

1. Проработанные цепочки бизнес-процессов (кто и что должен делать для достижения результата)
2.  UI-концепции со схемами основных пользовательских путей и экранов (Выполняется Дизайнером на этапе бизнес-анализа)
3. Архитектурные концепции с выделением основных функциональных модулей и потоков данных (Выполняется архитектором-проектировщиком на этапе бизнес-анализа)
4. План разработки в виде задач, реализуя которые, разработка достигнет цели

На этом этапе над каждой задачей выполняется так называемая системная аналитика.

Требуется проработать детальные технические требования по каждой задаче для передачи в разработку:

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

Акценты в проведении аналитики

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

Далее рассмотрим несколько свойств задач, которые влияют на то, какую аналитику проводить.

• Первое свойство - понятна ли предметная область или же требуется погружение команды в контекст происходящего?

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

- Если общедоступные и понятные всем сценарии - то погружение не требуется. 

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

• Второе свойство — изменения вносятся в существующий системный процесс или реализуется абсолютно новая возможность?

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

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

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

• Третье свойство задач— это тип пользователей. 

- Если пользователь имеет «размытый» профиль и одной из задач системы является «удержание» пользователя, то можно провести UX-исследование. 

- Если же пользователи - люди подготовленные и работают по заранее определенным алгоритмам (например, бухгалтер), то такой класс аналитики не требуется - важны другие подходы. 

• Четвертое свойство задачи- вариативность/ветвление реализуемого процесса. 

Бывают системы, в которых процессы линейные, понятные, их не нужно моделировать, оптимизировать. 

Если в системе планируются сложные и ветвистые процессы, то аналитику необходимо показать вариативность, смоделировать бизнес-процесс: например, в формате BPMN-диаграммы/диаграммы последовательности.

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

Итог

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

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

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