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

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

Небольшая предыстория

Меня зовут Виктор Дмитриев. Я практикующий бизнес-/системный аналитик с опытом управления командой / глубокого бизнес-анализа / запуска Web и Mobile проектов. В отрасли больше 7 лет, успел поработать в следующих компаниях:

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

Месяц назад я написал на vc статью про ошибки, которые часто допускают бизнес-аналитики в своей ежедневной работе. Ошибки, которые были рассмотрены:

  • Ошибка 1. Принимаем требования заказчика без уточнения его реальных потребностей
  • Ошибка 2. Создали и продолжаем поддерживать систему-франкенштейн
  • Ошибка 3. Забыли обработать исторические данные
  • Ошибка 4. Принимаем слова руководителей за «чистую монету»

Если не читали, настоятельно рекомендую ознакомиться с прошлой статьёй для полного понимания.

Терминология

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

Таким образом, бизнес-аналитик - это роль, которая в проекте отвечает за:

  • уточнение и формализацию процессов as-is и to-be
  • определение потребностей и болевых точек заказчика
  • формализацию и согласование бизнес, функциональных и нефункциональных требований
  • описание технических требований: требований к интеграции, миграции, структуре данных
  • написание и согласование ТЗ
  • и т.д.

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

Ошибки

Ошибка 5. Забыли получить согласование ТЗ

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

  • аналитику кажется, что всё уже обсудили "словами";
  • заказчик - мой приятель по работе, вряд ли он будет "возникать", если что-то пойдет не так;
  • на таких проектах часто нет выделенного ПМ-а, а аналитики банально забывают про шаг согласования.

Ситуация: вы собрали требования и описали ТЗ к реализации новой задачи - добавление новых статусов на объект "Заказ". Вы всё подробно расписали - переходы между статусами, обработку исторических данных, возможные действия пользователя с учетом новой статусной модели. Вам кажется, что всё то, что вы обсуждали с заказчиком, отражено в ТЗ, и нет смысла еще раз отнимать время заказчика на согласование ТЗ.

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

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

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

Так или иначе, у вас появится дополнительная головная боль.

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

1. Получайте формальное согласование ТЗ:

  • идеальный путь - организовать встречу, куда пригласить заказчика, разработчиков, тестировщиков и вместе провалидировать требования:
    a. вы подтвердите соответствие ожиданий заказчика описанному в ТЗ;
    b. разработчики зададут уточняющие вопросы и будут понимать ценность изменений, которые они делают;
    c. тестировщики зададут уточняющие вопросы и смогут подготовить тестовые сценарии.
  • неидеальный (но иногда приемлемый) путь - послать ТЗ по почте с указанием адекватных сроков на рассмотрение и согласование ТЗ. Если за это время комментариев не последует, то можно считать ТЗ согласованным (явно прописать это в письме).

2. Не ждите окончания сбора и формализации требований. Показывайте заказчику промежуточные версии ТЗ, чтобы понимать, что вы движетесь в правильном направлении.

Ошибка 6. Не привлекаете дизайнера на интервью заказчика

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

Ситуация: у вас есть достаточно большая задача. Добавить в мобильное приложение вашей финтех-компании новую функциональность - дать возможность вашим пользователям анализировать их расходы в виде разных диаграмм (PFM - personal financial management functionality). Вы подробно собираете все требования: спрашиваете, как должны быть расположены диаграммы, что они должны содержать, в каком цвете должны быть и т.д. После этого вы оформляете это в виде ТЗ, где подробно описываете требования к пользовательскому интерфейсу (UI) и вовлекаете дизайнера только на том этапе, когда ТЗ и требования к UI уже согласованы заказчиком.

Результат: со 100%-вероятностью дизайнер предложит другие, более интересные способы визуализации этих данных, когда ознакомится с ТЗ. Вы будете вынуждены собрать еще одну встречу, внести изменения в ТЗ и потратить свой ресурс и ресурс заказчика.

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

1. Я не сторонник описания подробных требований к UI аналитиками. Идеальный подход - привлекать дизайнера уже на этапе сбора требований, чтобы вы уточняли, как будет работать бизнес-логика приложения, а дизайнер определял, как будет выглядеть приложение.
Дизайнер сможет готовить небольшие макеты в Figma (или другом софте) и каждую новую встречу с заказчиком выдавать какой-то прогресс. У заказчика:
- будет больше понимания того, что проект движется;
- он сможет давать более осознанный фидбэк, чем если бы просто читал ТЗ;
- он сможет "потрогать" функционал еще без его фактической разработки за счет кликабельных макетов дизайна.

2. Если у вас нет дизайнера, то на примере этой задачи вы могли бы сделать что-то типо простого макета в Excel - сгенерировать данные (пользовательские траты), сформировать сводные таблицы, диаграммы и т.д.. Это дало бы заказчику возможность примерно представить, как будет выглядеть эта аналитика в мобильном приложении.

Ошибка 7. В процессе сбора требований вы общаетесь не с тем человеком

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

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

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

Команде приходится в срочном порядке возвращать старые шаблоны форм, а ваш авторитет как аналитика слегка подпорчен.

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

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

2. Если вы только пришли на проект / в компанию, уточните роль пришедшего к вам заказчика со своим руководителем, прежде чем слепо браться за описание требований.

3. Если к вам пришел сотрудник, а не руководитель отдела, уточняйте, получено ли согласование руководителя на такого рода изменения. Всегда можете сами "сходить" к руководителю и завалидировать эти требования с ним.

Ошибка 8. Не фиксируете все договоренности в заметках встреч

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

Ситуация: обсудили с заказчиком определенное изменение, например, добавление страницы формирования заказа. В рамках встречи выяснили, какие поля должны быть на этой странице, в каком порядке они должны появляться, какая валидация на эти поля и т.д. Через некоторое время всё это подробно описали в ТЗ в виде вариантов использования (use cases) и функциональных требований.

Результат: вы описали в ТЗ подробную реализацию изменений, затратив значительное количество времени. В результате, может оказаться что что-то вы просто поняли не так, как это подразумевал заказчик. Т.к. у вас нет никакого подтверждения, почему вы описали так, а не иначе, то в этой ситуации проблема переходит в область "его слово против вашего", где заказчик всегда одерживает верх. У вас не останется другого выбора, кроме как внести правки в ТЗ, а это требует вашего дополнительного ресурса.

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

1. Пишите небольшие заметки (meeting minutes / meeting notes / MEMO, etc.) с ключевыми итогами каждой встречи по шаблону (простой пример):

  • Участники
  • Темы обсуждения
  • Договоренности
  • Дальнейшие планы

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

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

Конечно, фиксации договоренностей в заметках встреч не гарантирует того, что вам не придется вносить изменения в ТЗ, но однозначно митигирует этот риск.

Что будет дальше?

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

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

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

Постараюсь выпустить следующую статью раньше, чем через месяц:)

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

Мои контакты

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

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

0
23 комментария
Написать комментарий...
Antsiforov Stanislav

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

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

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

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

Попробую объяснить свою позицию на этот счёт не влезая в кучу других смежных проблем:

Бизнес-анализ давольно определённый высокий уровень абстракции, и люди которые умеют эффективно переключиться между таким высоким уровнем и атрибутивным составом в потоке данных при интеграции какой-то конкретной штуки и при этом не сгореть - ну их мало. Может быть человек 100 на всю страну, если с головы цифры взять.

Остальные просто будут страдать и молча ходить на собеседования когда им дадут работу системного аналитика.

Ответить
Развернуть ветку
Илья Ланкевич

Дык всегда вопрос широты и глубины познаний. И чуточку – точки зрения.
БА скорее НЕ ДОЛЖЕН говорить о [технической] реализации, т. к. не его роль.
Но "класс", "атрибут", "метод" и "отношения" – это абстракции, скорее философские категории, а не технические.😀

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

Я бы сказал так: говорить о технических вопросах БА может и должен. Но принимать решения о технической реализации - нет, это не его зона ответственности.

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

Проблема в том, что в текущий момент многие работодатели закладывают в требования к бизнес-аналитику понимание интеграций, API, структур данных и других технических моментов.

Плохо это или хорошо, мне сложно сказать) Но реалии сейчас таковы

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

Это не проблема. Это систематическое отсутсвие нормального и толкового руководства которое понимает процессы на своём же производстве. Когда 99.9% софта делают идиоты - в айти всегда будет работа.

Ответить
Развернуть ветку
Сергей S.L.

Короткое резюме: коммуникация решает проблемы.

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

Спасибо за резюме)
На самом деле так можно многое обозначить "пишите качественный код", "тестируйте внимательно систему" и т.д.
Но это не значит, что не надо рассматривать частные кейсы)

Ответить
Развернуть ветку
Сергей S.L.

Конечно! Я бы сказал, их даже нужно рассматривать. Это как теорема с доказательством. Но вдруг кто-то испугался и сразу полез в каменты, а тут вот он я :)
Мой опыт говорит о том, что самым главным вопросом в коммуникации будет вопрос «зачем»? Несмотря на всю его дерзость и неоднозначное понимание - на любом этапе снимает кучу проблем на будущее. К сожалению, при составлении ТЗ или интервью многие пренебрегают им, после чего то «я хотел не то» и «нам надо не это».

Ответить
Развернуть ветку
Надежда Казакова

Как мне нравится слово "дерзость")) Нужно добавить в требования к аналитика "быть дерзким, учитывая контекст, зону ответственности, иерархию"))

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

+++ к вопросу "зачем"

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

Немного не понял про п.7. Я, правда, не айтишный аналитик, а занимался общекорпоративными вопросами плюс кое-где про фронт-офису.

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

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

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

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

Ответить
Развернуть ветку
Isuzu Dzanarnoghno
Затем оказывалось, что человек, который выдавал требования, не согласовал их перед этим с начальством

Да зачем именно с начальством согласовывать? Ведь есть еще и горизонтальное согласование по связанным процессам. А, если оно не сделано, БА должен задуматься насчет "это ж-ж-ж-ж неспроста". Или он хотя бы общей структуры процессов не понимает? А тогда что он на своем месте делает?

Но, как я сказал, я не айтишный процессник. Может, в айти есть свои особенности...

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

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

Важно просто проводить KYC перед тем, как собирать требования)

Ответить
Развернуть ветку
Isuzu Dzanarnoghno
Да, БА в ИТ не обязан знать всю орг.структуру компании.

О, спасибо. Немного мне открыли глаза на различия.
Т.е. чисто техтребования? Ну, тогда да. Весьма сложная местами процедура согласований...

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

Ну такое, Карл учит, что должен, конечно

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

Да, согласен!
Но я не ссылался бы на Вигерса как на бенчмарк в российских реалиях)

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

Все-таки use cases чаще переводят как варианты использования, а пользовательские истории это user stories и пишутся (в теории) они по-разному. Ошибка 7, мне кажется, звучит узковато. В идеале аналитик должен беседовать со всеми заинтересованными лицами, и заказчиками, и пользователями процесса, и исполнителями. Как только кого-то упустил, риск переделок возрос. Но, безусловно, интересно послушать, как оно на практике.

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

Спасибо за комментарий)
Так и есть, опечатался. Имел в виду «варианты использования». Да, use cases и user stories - это разное, у них разный смысл и ценность. На практике они тоже пишутся по-разному.
Касательно ошибки 7, да, соглашусь, но хотел выделить отдельно именно дизайнера, потому что чаще всего сталкивался именно с таким примером

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

Что-то про задачи бизнес аналитика тут особо ничего нет, это все системный аналитик делает, в корне другие задачи, подходы, знания у бизнес аналитика.

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

Поэтому я и сказал, что речь про бизнес-аналитика в ИТ. Есть ещё БА, которые занимаются анализом метрик, расчётом показателей и т.д.
Проблема в современной терминологии. Но если будете искать вакансии БА на хэдхантере условном, то 90% будут именно про БА в ИТ и требования будут выдвигать именно такие.

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