Карьера
Victor Dmitriev

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

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

Давайте знакомиться

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

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

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

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

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

  • BCG
  • Норникель
  • Inframine
  • KPMG
  • Paybis

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

Чем занимается бизнес-аналитик

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

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

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

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

  • анализирует текущие бизнес-процессы заказчика (as is);
  • взаимодействует с заказчиком, чтобы понять его болевые точки;
  • моделирует бизнес-процессы заказчика «после» автоматизации (to be).

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

  • взаимодействует с бизнес-аналитиком, чтобы понять какой бизнес-процесс to-be необходим;
  • описывает сценарии использования системы (use cases), требования к системе (функциональные и нефункциональные) и другие документы;
  • проводит сессии с разработчиками и тестировщиками;

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

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

Ошибки

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

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

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

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

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

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

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

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

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

  • Соберите требование к желаемой функциональности как можно детальнее. Про то, как собирать требование, мы поговорим с вами в отдельной статье.
  • Теперь у вас есть понимание того, что, действительно, нужно заказчику - его потребность (business need/requirement).
  • Обратитесь к вашему корпоративному архитектору (в его отсутствие - к руководителю разработки), опишите ему ситуацию и попробуйте вместе найти решение.
  • Возможно, в процессе анализа вы поймёте, что такая функциональность уже реализована в другой системе или ее стоит реализовать в другой системе.

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

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

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

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

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

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

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

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

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

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

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

Что дальше

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

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

  • Типичные ошибки бизнес-аналитика. Часть 2
  • Прохождение собеседования на позицию аналитика
  • Курсы для прокачки скиллов аналитика
  • Hard и sofl скиллы аналитика
  • Опыт прохождения Go Practice Simulator
  • Как собирать и описывать требования
  • Методологии моделирования бизнес-процессов
  • Структуры вопросов для интервьирования заказчика
  • Зарплаты аналитиков
  • Опыт работы аналитиком в Европе

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

Интересна для вас тема бизнес-аналитики?
Да
Нет
Ну такое
Показать результаты
Переголосовать
Проголосовать

Мои контакты

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

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

0
26 комментариев
Написать комментарий...
Timur e la squadra

Статья крутая, спасибо!

И непонимание границы ролей бизнес и системных аналитиков это прям боль. Причем работающая в обе стороны, с одной стороны, раз аналитик работает в ИТ команде, то от него принято требовать быть "тру" айтишником. То есть не только бизнес опросить, но и API запросы раскурить.
С другой стороны, увидел допущение и в обратную сторону. В первых двух описанных ошибках от аналитика вроде как требуется побыть в роли Product/Project Manager и не просто повысить уровень условной автоматизации выделенных процессов, а подумать и выйти на уровень ценности ИТ решения.
Это не укладывается в тезисные описания обязанностей бизнес-аналитика в самой статье.

ИМХО. Нет ничего плохого в том, что бизнес-аналитик разбирает проблемы Заказчика и докапывается до ценности, которую хочет клиент. Но его ли это главная работа?
Обычно так случается, когда PM номинален и работает как администратор, бегая с бумажками. Если в такой команде будет сильный аналитик, он может взять на себя провисающие роли. Но хорошо ли это, вопрос.

Ответить
Развернуть ветку
Victor Dmitriev
Автор

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Victor Dmitriev
Автор

Я говорил про канонического BA в контексте ожидания российского бизнеса от соискателей, а не представлении BABOK.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Victor Dmitriev
Автор

Я на своей практике встречал другие ожидания от БА.
Скорее российский бизнес ожидает универсального солдата, который пойдёт и с бизнесом пообщается, и составит ТЗ, и API проанализирует.

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Pablo

Люди разные же

Ответить
Развернуть ветку
Mercator

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

Ответить
Развернуть ветку
Victor Dmitriev
Автор

Согласен, хоть я с таким и не сталкивался)
Но эта проблема вряд ли аналитику «под силу», единственное, что можно - эскалировать ее на уровень проектного менеджера или выше.

Ответить
Развернуть ветку
Mercator

Проектного менеджера уровень аналитик-телепат устраивает.

Ответить
Развернуть ветку
Savchenko Ivan

А можно обойтись без аналитика в описываемых кейсах? Архитектор и PM вместе вполне же способны затащить эти задачи, принять и разделить зоны ответственности более эффективно. Если же выделять только одного спеца под такие кейсы, то он скорее бы назывался product owner, чем аналитик.

Ответить
Развернуть ветку
Администратор Аккаунта

Аналитика частенько выпускают как того, кто умеет слушать и общаться с марьиваннами и разного рода красными директорами, кто терпеливо сможет поддакивать, выявлять потребности и т.д. Архитектор и ПМ - слишком "аристократичны" (в своих глазах) для этого. Говорю как человек, проработавший несколько лет БА.

Ответить
Развернуть ветку
Victor Dmitriev
Автор

Иван, соглашусь, что кейс №2 - это зона ответственности архитектора, но аналитик может инициировать это обсуждение.
Но кейсы №1, 3, 4 - это исключительно зона ответственности аналитика, т.к. это всё ошибки на этапе сбора и формализации требований.

Ответить
Развернуть ветку
Savchenko Ivan

Спасибо. Стало понятнее

Ответить
Развернуть ветку
Pavel Kolosov

Спасибо за помощь в телеграмме, вы настоящий спец

Ответить
Развернуть ветку
Vladimir Tsay

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

Ответить
Развернуть ветку
Timur e la squadra

Потому что им так kpi ставят. Когда у команды главный критерий успешности - это скорость и беспроблемность подписания акта выполненных работ от заказчика, логичным становится поведение делать то, что нравится заказчику и не делать то, что не нравится.
На моей практике, абсолютное большинство руководства на стороне исполнителя требует от команды скорейшего закрытия актов и завершения проектов, так как ресурсы дорогие и чем больше актов закрывается за условный год, тем больше денег. В итоге, когда команда или её отдельные члены начинают «раскачивать лодку», объясняя, (реальный пример), что на BI системе, к которой привык заказчик не стоит строить формы ввода, так как это пипец какой костыль. Такая команда не находит поддержки ни внутри своей компании, ни на стороне заказчика и, либо соглашается играть по навязанным правилам и получать свои премии, либо люди уходят.

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

Ответить
Развернуть ветку
Юрий Фоменко

А какие ещё на практике бывают KPI? Кто может произвести сравнительный расчёт бюджета на желаемую доработку или смену ПО в нынешних реалиях? Иначе, собственника бизнеса интересуют рубли, но никак не зона комфорта отдела IT.

Ответить
Развернуть ветку
Alexandra Frolova

Вопросы 2 и 3 невозможно решить аналитику самому. Поэтому ошибка 5 - не выявлены все стейкхолдеры по проекту. Стейкхолдер не только заказчик, ещё и разработка, архитекторы всех затрагиваемых систем, пользователи и т д и т д.

Ответить
Развернуть ветку
Victor Dmitriev
Автор

Согласен) Я и не говорил о том, что бизнес-аналитик должен сам решать ошибки 2 и 3. Он просто должен о них подумать. Кстати, ошибка 3 частично находится в зоне ответственности БА.

Про стейкхолдеров полностью согласен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
1 1

Добрый день! Не совсем поняла про исторические данные. Это про указание на датафикс или системная ориентация решения?

Ответить
Развернуть ветку
Victor Dmitriev
Автор

Добрый день!
А я не понял ваш вопрос)

Ответить
Развернуть ветку
Читать все 26 комментариев
null