Как измерить качество работы аналитика (часть 1)

Сколько практикующих аналитиков и мечтающих ими стать, не задумываясь, смогут ответить, чем полезна выделенная роль БА на проекте? Какую ценность создает аналитик для всех заинтересованных лиц? На что повлияет отсутствие аналитика? Как измерить качество работы аналитика?

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

Часто смысл разговора о необходимости присутствия аналитика на проекте сводится к следующему:

• Здравствуйте, Вам в проекте нужен аналитик.

• Здравствуйте. А зачем?

• Ну как зачем?! Чтобы требования собрать, обсудить… с заказчиком.. спецификация… разработчику задачи поставить…

• Простите, Вы неразборчиво что-то говорите. Я Вас не понимаю.

• Аналитик! Он нужен! Требования! Команда! Качественно, чтобы…

• У нас продакт оунер работает напрямую с командой разработки. Все замечательно.

• Понятно. Спасибо…

Если вы – уже не первый год в ИТ и высокоуровневые рассуждения – не для вас, смело дожидайтесь второй части статьи.

Как вы знаете, аналитик – это, прежде всего, роль. Эту роль можно разделить среди нескольких людей. И дядюшка Вигерс (K.Wiegers) нам про это говорит, и Международный институт по бизнес-анализу (IIBA) про это не забывает.

Неполный список критериев, которые определяют необходимость в выделенной роли аналитика, может выглядеть так:

• Зрелость организации (как заказчика, так и исполнителя)

• Размеры проекта (с т.зр. сроков, бюджета, количества заинтересованных лиц)

• Географическая распределенность заинтересованных лиц

• Сложность организационной структуры компании

• Сложность предметной области

Не стесняйтесь этот список дополнять в комментариях к статье.

Если мы считаем, что аналитик – это роль, то данная роль будет описывать ограниченное множество действий, выполняемых кем-то или чем-то в рамках определенного процесса (спасибо Википедии). “Действия” для удобства заменим на “активности”.

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

• Определение проблем и целей организации

• Анализ потребностей и решений

• Создание стратегий

• Осуществление изменений

• Фасилитация взаимодействия между заинтересованными лицами

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

Карл Вигерс выделяет следующие области (группы) активностей по бизнес-анализу:

• Определение бизнес-требований

• Определение подхода к работе с требованиями

• Выявление заинтересованных лиц

• Сбор требований

• Анализ требований

• Документирование требований

• Коммуницирование требований

• Фасилитация в валидации и приоритизации требований

• Управление требованиями

Поскольку слово “анализ” присутствует как в списке основных активностей, так и в самом названии нашей с вами профессии, можно предположить, что это важная активность (капитан не дремлет!). А возможно, и самая важная. И когда мы говорим о распределении активностей аналитика среди других ролей, то часто подразумеваем нечто вроде следующего:

• Продакт оунер (он же Product owner, владелец продукта) сам определяет и формулирует бизнес-потребности, приоритизирует бизнес-требования

• Проектный менеджер вместе с ведущим разработчиком занимаются сбором и документированием требований

• Тестировщик проверяет качество требований (например, полноту)

• Кто-то из перечисленных выше ролей будет также заниматься коммуницированием требований и управлением ими

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

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

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

Значит ли это, что при прочих равных условиях проект, в котором есть аналитик, будет более успешным, чем проект без аналитика? Если да, то как это своевременно определить? Как понять, что аналитические активности выполняются в достаточной степени и с достаточным качеством? Как повлияют на проект плохо выполняемые те или иные БА активности?

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

Автор

Роман Баканович

Бизнес-аналитик

EPAM Netherlands