Частые ошибки бизнес-аналитика

Время чтения статьи: примерно 5 минут.

Всем привет! Я уже года 3 сижу на vc в качестве читателя. Думаю, пришло время опубликовать свою первую статью, к тому же мне есть, о чем вам рассказать.

Меня зовут Виктор Дмитриев. Я родился и вырос в Липецке, последние 8 лет живу в Москве, переехав сюда в 2012-м, когда поступил в НИУ ВШЭ, но сейчас речь пойдет не об этом

Что важнее для нас сегодня, я последние 5-6 лет работаю в ИТ на должностях бизнес-аналитик / старший бизнес-аналитик / lead бизнес-аналитик. Кроме того, занимался проектным и продуктовым управлением, управлял ИТ-командами до 15-20 человек, запускал достаточно крупные корпоративные продукты на десятки тысяч пользователей, сейчас работаю в B2C продукте (финтех).

Но все-таки бОльшая часть моего профессионального опыта связана с бизнес-/системной аналитикой.

Работал в следующих компаниях:

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

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

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

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

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

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

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

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

Теперь, наконец, про ошибки)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оставшиеся ошибки я оставлю для второй части статьи.

Мне очень многое хочется вам рассказать. Конечно, если вам это будет интересно.

Потенциальные темы для обсуждения:

и многое другое.

Вы всегда можете связаться со мной в tg.

Я также являюсь ментором. Ко мне можно обратиться с техническими вопросами, интересными кейсами, поиском карьерных возможностей и помощью в подготовке к собеседованиям. Конечно же, в сфере бизнес-/системной аналитики. Если вам интересно, пишите также в tg.