Чем занимается бизнес-аналитик?
Понятия системный аналитик и бизнес-аналитик
Сразу отмечу, что в мире принято различать понятия бизнес-аналитик (business analyst) и системный аналитик (system analyst).
Бизнес-аналитик выясняет, каковы реальные потребности бизнеса, и на базе этих знаний принимает решения по изменению IT-системы и отдельных процессов.
Подразумевается, что бизнес-аналитик (тезисно):
· анализирует текущие бизнес-процессы заказчика (as is);
· взаимодействует с заказчиком, чтобы понять его болевые точки;
· моделирует бизнес-процессы заказчика «после» автоматизации (to be).
Кроме того, бизнес аналитика требует понимание ГОСТов, моделирования процессов и методологий бизнес-анализа, потому обучение таких специалистов сопровождается погружением в нотации, стандарты и лучшие практики.
Системный аналитик, в свою очередь (тезисно):
· взаимодействует с бизнес-аналитиком, чтобы понять какой бизнес-процесс to-be необходим;
· описывает сценарии использования системы (use cases), требования к системе (функциональные и нефункциональные) и другие документы;
· проводит сессии с разработчиками и тестировщиками;
Таким образом, бизнес-аналитик больше взаимодействует с представителями заказчика, системный аналитик - с разработчиками.
Ошибки
Ошибка 1.
Принимаем требования заказчика без уточнения его реальных потребностей
Ситуация: к вам приходит заказчик (например, СТО) и говорит: «я хочу, чтобы вы настроили нам интеграцию нашей системы управления ремонта машин с системой отчетности, чтобы мы могли проводить ежемесячную инвентаризацию». Аналитик берет это требование как данность, уточняет детали по шаблону требований к интеграции и передаёт их в разработку. В результате, мы получаем не оптимальное решение с точки зрения потребностей заказчика и ресурсов разработки. Главная проблема, и вы должны ее запомнить - заказчик далеко не всегда знает, чего он хочет на самом деле.
Рекомендуемый подход: вы должны понимать, что ваш заказчик работает не в ИТ (чаще всего), у него нет понимания всего набора технических опций, более того, он может не обладать таким системным мышлением как вы.
Всегда старайтесь докопаться до сути, только факты, задавая вопросы «зачем» и «почему». Задав эти вопросы, вы, возможно, узнаете, что инвентаризацию можно (и нужно, но заказчик об этом не думал) проводить чаще, чтобы сразу же находить пропавшую продукцию.
Ошибка 2.
Создали и продолжаем поддерживать систему-франкенштейн
Ситуация: в вашей компании на поддержке находится самописная система, которая выступает в роли и разные системы. Такая монолитная система-франкенштейн (назовём ее система X). В очередной раз к вам приходит заказчик и говорит: «давайте добавим в систему X возможность создавать B2B заявки с новым набором полей.» Вы, конечно, можете взять это требование, оформить в виде ТЗ, передать разработчикам, а ваш заказчик получит результат. Но является ли это оптимальным решением?
Рекомендуемый подход:
· Соберите требование к желаемой функциональности как можно детальнее. Про то, как собирать требование, мы поговорим с вами в отдельной статье.
· Теперь у вас есть понимание того, что, действительно, нужно заказчику - его потребность (business need/requirement).
· Обратитесь к вашему корпоративному архитектору (в его отсутствие - к руководителю разработки), опишите ему ситуацию и попробуйте вместе найти решение.
· Возможно, в процессе анализа вы поймёте, что такая функциональность уже реализована в другой системе или ее стоит реализовать в другой системе.
Ошибка 3.
Забыли обработать исторические данные
Ситуация: как мы уже привыкли, к вам приходит заказчик (тот же СТО) и просит: «я хочу добавить новый статус в заявке на ремонт машины - «заморожена», чтобы отслеживать ремонты, которые больше 3-х дней находятся в процессе».
Заказчик этого явно не подразумевает, а вы забываете спросить, но после внедрения нового статуса в продакшн, оказывается, что исторические заявки на отгрузку готовой продукции, которые уже сейчас находятся более 3-х дней в процессе сбора, так и не перейдут в новый статус. Проблема в том, что вы забыли обработать исторические данные. Если бы вы подумали об этом раньше, в процессе сбора требований, вы бы указали это в ТЗ, а разработчик написал бы скрипт и все были бы довольны.
Рекомендуемый подход: на самом деле это ошибка может быть более глубокой - аналитик не продумал часть нового функционала, но часто я встречал ее именно в таком виде. Правило простое - если это имеет место быть, сразу уточняйте (и прописывайте), что внедряемая фича не повлияет/повлияет на исторические данные.
Ошибка 4.
Принимаем слова руководителей за «чистую монету»
Ситуация: обратимся к нашему кейсу с сто.
К вам приходит начальник отдела Сбыта и просит разработать модуль создания заявок на ремон. Он утверждает, что очень давно работает в компании и знает все процессы своего отдела. Вы верите ему на слово, проводите сессии интервьюирований с ним, формируете ТЗ на основе этих знаний, отдаете в разработку, на выходе есть продукт, которым начинают пользоваться сотрудники отдела Сбыта. В результате, оказывается, что часть сотрудников не способны выполнять свои функции в новой системе, потому что почти всегда есть какие-то исключительные случаи (corner cases), которые одному человеку не продумать.
Рекомендуемый подход: тут могу дать два совета:
1. Проводите демонстрации будущим пользователям как можно раньше и чаще (про это мы поговорим в отдельной статье);
2. Всегда старайтесь проинтервьюировать как можно больше сотрудников. Именно так у вас сформируется наиболее полная картина окружающего мира. Важно выбирать сотрудников, выполняющих разные функции.