8 ошибок бизнес-аналитиков: реальный опыт и советы

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

Кто такой бизнес-аналитик

Бизнес-аналитик — это специалист, который:

• собирает информацию о бизнесе, выявляя цели, задачи и текущие процессы последнего;
• взаимодействует с заказчиком, определяя проблемные места;
• на основе полученной информации формирует решения.

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

Важно понимать разницу между бизнес-аналитиком и системным аналитиком. В обязанности последнего входит следующее:

• работа с аналитиком с целью определения типов бизнес-процессов, которые необходимо реализовать;
• составление сценариев работы системы;
• определение требований к готовой системе и другое.

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

Типичные ошибки

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

Ошибка 1: бизнес-аналитик не выясняет реальные потребности заказчика

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

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

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

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

Ошибка 2: использование одной системы для решения разных задач

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

Реальный пример: Есть программа, отвечающая за отслеживание движения товара, печать чеков и отправку сообщений о скором истощении запасов на складе. Приходит клиент с просьбой создать подобную систему, но которая также будет автоматически обрабатывать поступающие заявки.

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

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

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

Ошибка 3: исторические данные не обрабатываются

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

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

Ошибка 4: верить словам руководителей

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

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

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

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

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

Ошибка 5: ТЗ не согласуется

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

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

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

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

Второй выход из ситуации — отказ от внесения доработок. В этом случае бизнес-аналитик может потерять клиента. Либо специалиста заставит руководство компании самостоятельно устранять ошибки.

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

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

Также рекомендуется в процессе реализации проекта присылать клиенту промежуточные результаты. Это поможет своевременно выявить ошибки и устранить неточности при минимальных трудозатратах.

Ошибка 6: бизнес-аналитик решает все сам

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

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

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

Рекомендации: Во избежание проблем следует привлекать дизайнеров к обсуждению проекта, а не стадии реализации последнего. Этот специалист может:

• до начала работы над проектом предложить несколько вариантов отображения информации;
• быстро вносить правки в дизайн-проект;
• предложить «потрогать» функционал приложения до того, как то будет создано.

Если дизайнера нет в штате компании, то бизнес-аналитик может самостоятельно создать макет, который позволит заказчику увидеть, как будет отображаться информация в приложении. Клиент в этом случае еще до запуска разработки проекта получит возможность внести правки.

Ошибка 7: не определена компетенция заказчика

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

Реальный пример: Начальник отдела сбыта обращается к бизнес-аналитику с задачей создать программу, которая будет формировать заказы на отгрузку товаров. Специалист формирует соответствующий ТЗ, проводит интервью и отправляет проект на разработку.

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

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

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

Ошибка 8: Все договоренности не фиксируются в заметках

При общении с заказчиками и согласовании новых доработок/изменений бизнес-аналитики не всегда фиксируют это в заметках.

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

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

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

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