Частые ошибки (bi)бизнес-аналитика – и кто он такой?

Eternal загуглил и...

Понятия системный аналитик и бизнес-аналитик

Сразу отмечу, что в мире принято различать понятия бизнес-аналитик (business analyst) и системный аналитик (system analyst).

Бизнес-аналитик выясняет, каковы реальные потребности бизнеса, и на базе этих знаний принимает решения по изменению IT-системы и отдельных процессов.

Подразумевается, что бизнес-аналитик (тезисно):

· анализирует текущие бизнес-процессы заказчика (as is);

· взаимодействует с заказчиком, чтобы понять его болевые точки;

· моделирует бизнес-процессы заказчика «после» автоматизации (to be).

Кроме того, бизнес аналитика требует понимание ГОСТов, моделирования процессов и методологий бизнес-анализа, потому обучение таких специалистов сопровождается погружением в нотации, стандарты и лучшие практики.

Системный аналитик, в свою очередь (тезисно):

· взаимодействует с бизнес-аналитиком, чтобы понять какой бизнес-процесс to-be необходим;

· описывает сценарии использования системы (use cases), требования к системе (функциональные и нефункциональные) и другие документы;

· проводит сессии с разработчиками и тестировщиками;

Таким образом, бизнес-аналитик больше взаимодействует с представителями заказчика, системный аналитик - с разработчиками.

Принимаем требования заказчика без уточнения его реальных потребностей

Ситуация: к вам приходит заказчик (например, СТО) и говорит: «я хочу, чтобы вы настроили нам интеграцию нашей системы управления ремонта машин с системой отчетности, чтобы мы могли проводить ежемесячную инвентаризацию». Аналитик берет это требование как данность, уточняет детали по шаблону требований к интеграции и передаёт их в разработку. В результате, мы получаем не оптимальное решение с точки зрения потребностей заказчика и ресурсов разработки. Главная проблема, и вы должны ее запомнить - заказчик далеко не всегда знает, чего он хочет на самом деле.

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

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

Создали и продолжаем поддерживать систему-франкенштейн

Ситуация: в вашей компании на поддержке находится самописная система, которая выступает в роли и разные системы. Такая монолитная система-франкенштейн (назовём ее система X). В очередной раз к вам приходит заказчик и говорит: «давайте добавим в систему X возможность создавать B2B заявки с новым набором полей.» Вы, конечно, можете взять это требование, оформить в виде ТЗ, передать разработчикам, а ваш заказчик получит результат. Но является ли это оптимальным решением?

Рекомендуемый подход:

· Соберите требование к желаемой функциональности как можно детальнее. Про то, как собирать требование, мы поговорим с вами в отдельной статье.

· Теперь у вас есть понимание того, что, действительно, нужно заказчику - его потребность (business need/requirement).

· Обратитесь к вашему корпоративному архитектору (в его отсутствие - к руководителю разработки), опишите ему ситуацию и попробуйте вместе найти решение.

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

Забыли обработать исторические данные

Ситуация: как мы уже привыкли, к вам приходит заказчик (тот же СТО) и просит: «я хочу добавить новый статус в заявке на ремонт машины - «заморожена», чтобы отслеживать ремонты, которые больше 3-х дней находятся в процессе».

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

Рекомендуемый подход: на самом деле это ошибка может быть более глубокой - аналитик не продумал часть нового функционала, но часто я встречал ее именно в таком виде. Правило простое - если это имеет место быть, сразу уточняйте (и прописывайте), что внедряемая фича не повлияет/повлияет на исторические данные.

Принимаем слова руководителей за «чистую монету»

Ситуация: обратимся к нашему кейсу с сто.

К вам приходит начальник отдела Сбыта и просит разработать модуль создания заявок на ремон. Он утверждает, что очень давно работает в компании и знает все процессы своего отдела. Вы верите ему на слово, проводите сессии интервьюирований с ним, формируете ТЗ на основе этих знаний, отдаете в разработку, на выходе есть продукт, которым начинают пользоваться сотрудники отдела Сбыта. В результате, оказывается, что часть сотрудников не способны выполнять свои функции в новой системе, потому что почти всегда есть какие-то исключительные случаи (corner cases), которые одному человеку не продумать.

Рекомендуемый подход: тут могу дать два совета:

1. Проводите демонстрации будущим пользователям как можно раньше и чаще (про это мы поговорим в отдельной статье);

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