История одного аудита: улучшаем процессы бизнес-анализа
- Denis Gobov
- 25 авг. 2020 г.
- 4 мин. чтения
Обновлено: 17 окт. 2024 г.
English version: ModernAnalyst.com Словосочетание «аудит проекта» для кого-то звучит угрожающе, для кого-то от этих слов веет формализмом и бюрократией. Никто особо не любит, когда проверяют его работу, особенно если проверяющий — человек со стороны. Чаще всего мы слышали слово аудит в контексте проверки финансовой или бухгалтерской отчетности, а в последние несколько лет многие столкнулись с аудитом IT-безопасности. Но я хотел рассказать об аудите процессов бизнес-анализа для одного проекта нашей компании. Возможно, этот сервис будет полезен и вашему проекту.
Около десяти лет назад я впервые выступал в роли аудитора проекта в части бизнес-анализа. Сначала мы создали документ, регламентирующий работу бизнес-аналитика — процедуру разработки и управления требованиями. А аудит, большей частью, заключался в проверке ее соблюдения в конкретном проекте. Но в рамках аудита я мог дать рекомендации, напрямую не предусмотренные формальными документами, а построенные, скорее, на здравом смысле и моем практическом опыте. Таким образом, я объединял аудит и консалтинг. По результатам составлялся план, выполнение которого проверялось в рамках следующего аудита.
Отличительная особенность DataArt — культура компании приветствует разнообразие, нет необходимости строго соблюдать формальные правила и процедуры, в том числе, в бизнес-анализе. Проще говоря, мы приветствуем гибкость и стараемся избегать формализма. Вместо этого профессиональные сообщества вырабатывают рекомендации и шаблоны, которые проекты могут использовать как они есть, адаптировать или придумать свои. Поэтому у нас аудит чаще всего предполагает консультационную помощь со стороны эксперта и инициируется PM или DM. Т. к. заранее спланированных аудитов (кроме аудита информационной безопасности) у нас нет, эксперта для аудита привлекают, когда в проекте наблюдаются устойчивые проблемы. Их перечень достаточно стандартный:
Задержки с подготовкой требований к началу спринта.
Постоянные изменения требований и/или их приоритетов.
Команда и/или клиент недовольны качеством требований.
Но поводом для аудита могут быть не только печальные моменты, но и позитивные изменения: команда выросла, а старые подходы/процессы не масштабируются.
КЕЙС С БА-АУДИТОМ
В 2018 г. один из Delivery Manager-ов финансовой практики попросил меня помочь разобраться с накопившимися проблемами в одном перспективном проекте, который переживал болезнь роста. Команда выросла, усложнился процесс коммуникации и вышеперечисленные печальные проблемы стали проявляться чаще и сильнее. И DataArt предложил клиенту провести аудит для решения проблем.
Аудит начался с того, что меня пригласили на ежедневный стендап, где познакомили со всеми членами команды. С той встречи больше всего мне запомнилась фраза менеджера проекта: «Знакомьтесь, это Денис — наш эксперт бизнес-аналитик, но он с нами ненадолго». Забегая вперед, скажу, что это предсказание не сбылось, и после аудита я успешно влился в команду и работаю в ней уже больше двух лет. После быстрого знакомства с командой я провел серию интервью с ключевыми членами команды: PM, тимлидом, QA-лидом и бизнес-аналитиками. Параллельно начал изучать проектные артефакты: требования, диаграммы, планы релизов, описания текущего процесса. После получения общей картины, я перешел к детальному анализу текущих процессов:
Как планируется и отслеживается работа бизнес-аналитиков.
Как проводится выявление требований.
В каком формате требования готовятся для разработки и тестировщиков.
Как ведется база знаний проекта.
Какие инструменты и подходы используются.
На определенном этапе у меня появилась возможность участвовать в общении с клиентом, наблюдать за процессом взаимодействия с ним.
ПРОЦЕСС
В результате я выявил и глобальные проблемы (отсутствие видения проекта, сформулированных проблем, на решение которых направлен проект, дорожной карты и т. д.), которые были вызваны тем, что проект перерос границы Proof of Concept и стал стратегической инициативой, и ряд локальных. Например, для моделирования бизнес-процессов, которое проводилось перед написанием детальных требований, использовалась нотация BPMN, но использовалась не совсем корректно. Кому-то это может показаться мелочью, но представьте, что вы взяли слова (аналоги графических элементов нотации) и стали располагать их в произвольном порядке в предложении, еще и забывая о знаках препинания. В чем это выражалось в нашем случае:
Модели, допускающие двоякое трактование.
Фактические ошибки в модели, вызванные неправильным использованием элементов нотации.
Излишне сложные диаграммы, которые сложно читать и понимать.
Проблемы в описании процессов.
Все это приводило к тому, что модели не полностью выполняли свою функцию, вводили в заблуждение и представителей бизнеса, и команду, которой нужно было эти процессы автоматизировать. Казус был в том, что и клиент, хотя и был инициатором идеи использования нотации, не был в ней экспертом. Мы организовали внутреннее обучение всей команды по работе с BPMN, плюс провели ряд обучающих сессий для представителей клиента. И это лишний раз подчеркнуло, что DataArt готов предоставлять широкий набор сервисов. Похожая ситуация была и со стандартными техниками написания требований. Создание шаблонов, адаптированных под нужды проекта, позволило в дальнейшем повысить как скорость написания, так и качество требований.
Очень часто рекомендации, прекрасно работающие в теории, разбиваются о суровую реальность. Поэтому после анализа и выработки рекомендаций мы провели воркшопы для проверки предложений на реализуемость в условиях проекта.
ПРЕДЛОЖЕНИЯ
По результатам аудита был сформирован отчет, который включал:
Описание текущего состояния проекта с точки зрения бизнес-анализа связанных с ними активностей команды.
Перечень выявленных рисков и проблем, рекомендации по их решению или смягчению.
Предложения по изменению процессов работы с требованиями.
Точечные рекомендации по инструментам и шаблонам.
Что касается предложений по улучшению, какие-то гарантировали “quick wins”, некоторые, например, создание долгосрочного плана развития платформы, требовали значительных усилий и внедрялись год.
Уже в процессе аудита стало понятно, что некоторые риски и проблемы, в основе которых лежал человеческий фактор, мы решить не сможем. Но можем их учесть и постараться смягчить последствия.
Результаты аудита презентовали клиенту, обсудили порядок внедрения предложенных изменений, назначили ответственных. Вот несколько примеров из этого плана.
ИТОГИ
В дальнейшем у меня была возможность ознакомиться с результатами внедрения рекомендаций. По грубой оценке, удалось воплотить в жизнь порядка 70 % запланированных улучшений. Команда проекта начала расширяться еще активнее, преодолев большую часть выявленных проблем роста.
Подводя итоги, хотел бы еще раз сказать, что аудит/консалтинг позволил не только улучшить качество работы бизнес-аналитиков, но и убрать узкие места разработки, что позволило в дальнейшем команде вырасти приблизительно в два раза (например, количество бизнес-аналитиков с нашей стороны постепенно выросло с двух до шести), а проекту — динамично развиваться. Конечно, не только аудит привел к таким результатам, но и он сделал вклад в общий успех.
Comments