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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Один их кейсов, как мы применяем BPMN-движок Camunda, мы описали тут)

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

Итог

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

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

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

Больше материалов про ИТ-аналитику в True Engineering: 

Работа с целеполаганием и продуктовыми метриками в аналитике

Как непрерывно развивать продукт за счет инструментов аналитики?