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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Делайте записи встреч (если встречи проходят онлайн). Вряд ли вы их будете часто просматривать, но это поможет вам решить проблему в конфликтных ситуациях.

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

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

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

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

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

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