История одного аудита: улучшаем процессы бизнес-анализа

14 июля
Денис Гобов, Senior Business Analyst и соруководитель BA community, DataArt
История одного аудита: улучшаем процессы бизнес-анализа
Словосочетание «аудит проекта» для кого-то звучит угрожающе, для кого-то от этих слов веет формализмом и бюрократией. Никто особо не любит, когда проверяют его работу, особенно если проверяющий — человек со стороны. Чаще всего мы слышали слово аудит в контексте проверки финансовой или бухгалтерской отчетности, а в последние несколько лет многие столкнулись с аудитом IT-безопасности. Но я хотел рассказать об аудите процессов бизнес-анализа для одного проекта нашей компании. Возможно, этот сервис будет полезен и вашему проекту.

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

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

  • Задержки с подготовкой требований к началу спринта.
  • Постоянные изменения требований и/или их приоритетов.
  • Команда и/или клиент недовольны качеством требований.

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

Кейс с БА-аудитом

В 2018 г. один из DM финансовой практики попросил меня помочь разобраться с накопившимися проблемами в одном перспективном проекте, который переживал болезнь роста. Команда выросла, усложнился процесс коммуникации и вышеперечисленные печальные проблемы стали проявляться чаще и сильнее. И DataArt предложил клиенту провести аудит для решения проблем.

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

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

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

Процесс

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

  • Модели, допускающие двоякое трактование.
  • Фактические ошибки в модели, вызванные неправильным использованием элементов нотации.
  • Излишне сложные диаграммы, которые сложно читать и понимать.
  • Проблемы в описании процессов.

Все это приводило к тому, что модели не полностью выполняли свою функцию, вводили в заблуждение и представителей бизнеса, и команду, которой нужно было эти процессы автоматизировать. Казус был в том, что и клиент, хотя и был инициатором идеи использования нотации, не был в ней экспертом. Мы организовали внутреннее обучение всей команды по работе с BPMN, плюс провели ряд обучающих сессий для представителей клиента. И это лишний раз подчеркнуло, что DataArt готов предоставлять широкий набор сервисов. Похожая ситуация была и со стандартными техниками написания требований. Создание шаблонов, адаптированных под нужды проекта, позволило в дальнейшем повысить как скорость написания, так и качество требований.

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

Предложения

По результатам аудита был сформирован отчет, который включал:

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

Что касается предложений по улучшению, какие-то гарантировали “quick wins”, некоторые, например, создание долгосрочного плана развития платформы, требовали значительных усилий и внедрялись год.

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

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

table
table
table

Итоги

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

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

За новыми публикациями Дениса Гобова можно следить на сайте и страницах DataArt в соцсетях, а также на его личных страницах в Facebook и LinkedIn