В предыдущей части статьи мы описали, почему зачастую сложно определить пользу от бизнес-анализа. Однако популярность этой профессии активно растет, что косвенно говорит о том, что польза, как правило, есть.
В этой части поговорим о том, как можно измерить качество аналитических активностей.
Сразу стоит отметить, что “качество активностей” – это не то качество, которое мы хотели бы измерить. В идеальном мире хотелось бы измерить качество результата работы аналитика. А результатом должна являться решенная проблема или реализованная возможность. Но здесь мы снова упираемся в «стопицот» зависимостей, факторов и неопределенностей, которые на данный момент точно измерить нельзя. Да, сегодня качество результата ИТ-проекта с точки зрения измеряемости все еще ближе к творчеству, нежели к науке (скажем, к математике). Поэтому, преодолев последний порыв к философствованию и пустословию, предлагаю обсудить, что же мы сегодня все-таки можем измерить.
Из всех определений термина “качество”, на мой взгляд, к бизнес-анализу лучше всего подходит следующее: сравнение ожиданий от услуги и производительности данной услуги. Перевод вольный, оригинал можно найти здесь.
Качество бизнес-анализа в рамках определенного контекста (фаза проекта, проект, программа) будет определяться тем, насколько полно и качественно выполняются отдельные аналитические активности. Также имеет смысл рассматривать качество артефактов, насколько это возможно. Итого измеряем:
-
Качество аналитических активностей в общем процессе
-
Качество аналитических артефактов
Важно понимать, что любые попытки что-то измерить должны нести под собой основание. Мы должны четко представлять цель измерения. Иначе есть риск разработать и внедрить метрики, из-за которых:
-
люди будут стараться подстроить свою работу под конкретные KPIs, не обращая внимание пользу от такой работы
-
люди потеряют мотивацию
Также зачастую подход к оценке зависит от зрелости процессов в организации и общей договоренности между ключевыми заинтересованными лицами.
В целом, качество работы аналитика может измеряться с помощью как объективных (основанных на данных), так и субъективных метрик.
Проведя некоторое время в поисках идеального решения для нашей с вами задачи, я изучил все научные или близкие к таковым материалы, которые смог найти. Их оказалось примерно 35, скачать все можно тут. Если вы знаете какие-либо еще книги, статьи или реальные примеры, буду благодарен за информацию.
Оказалось, что существенных решений, которые можно было бы применить на практике почти нет. Коллеги в разных компаниях также расходятся во мнении относительно наилучшего подхода к анализу качества БА. Отсюда появились 2 гипотезы:
-
Полноценно измерять качество бизнес-анализа с учетом зрелости процессов и технологии на сегодняшний день невозможно
-
Никто толком этим не занимается, потому что это
(нафиг никому не надо)не представляет особой ценности
Если задаться целью, то теоретически измерить можно что угодно. Вопрос только в целесообразности и доступных ресурсах. Про целесообразность обсудили выше в статье. Теперь немного о доступности ресурсов.
Обобщенный и далеко не полный список того, что теоретически можно измерить, может выглядеть так:
Количественные метрики
-
Время от появления идеи до финального утверждения требований (Сycle time from ideation to Feature approval)
-
Уровень покрытия тестами каждой функциональной области (Test coverage for Feature)
-
Количество дефектов на каждую функциональную область (Number of defects per Feature)
-
Уровень завершенности требования по каждой функциональной области (Feature Completeness)
-
Количество изменений в требованиях (Amount of Requirement Changes)
-
Доля функциональных доработок по причине измененных/новых требований (% of rework attributable to requirements)
-
Доля приоритизированных требований от общего объема (% of prioritized requirements)
-
Доля полностью реализованных требований (% of requirements fully implemented)
-
Доля утвержденных, но, в итоге, не реализованных требований (% of approved requirements not implemented)
-
Доля протестированных требований (% of Requirements Tested)
-
Количество упущенных требований (Number of missing requirements)
Качественные метрики
-
Уровень ценности для бизнеса от каждой функциональной области (Business value per Feature)
-
Уровень удовлетворенности заинтересованных лиц со стороны бизнеса (Stakeholder satisfaction with BA activities)
-
Удовлетворенность команды работой аналитика (Implementation team satisfaction with BA activities)
-
Активность заинтересованных лиц при работе с функциональными областями (Stakeholder activity by Feature)
-
Уровень своевременности аналитических активностей (Timeliness)
-
Качество спецификации требований
-
Полная (Complete)
-
Консистентная (Consistent)
-
Изменяемая (Modifiable)
-
Трассируемая (Traceable)
-
-
Качество отдельных требований
-
Полное (Complete)
-
Правильное (Correct)
-
Реализуемое (Feasible)
-
Необходимое (Necessary)
-
Приоритизированное (Prioritized)
-
Недвусмысленное (Unambiguous)
-
Проверяемое (Verifiable)
-
Понятное (Understandable)
-
Краткое (Concise)
-
Аннотированное версией (Annotated by version / Baselined)
-
Неизбыточное (Not redundant)
-
Можно повторно использовать (Reusable)
-
Наверняка, есть еще что-то, что можно рассмотреть как потенциальную метрику. Например, можно рассмотреть вариант от IIBA.
Почти каждая из метрик связана не только с работой аналитика, но и с другими активностями. Поэтому сложно провести четкую связь между отдельным показателем метрики (KPI) и качеством бизнес-анализа. Отсюда и редкость случаев, когда в провале проекта винят исключительно аналитика.
Из вышеперечисленных метрик большинство весьма трудно измеримы. Зачастую просто невозможно получить необходимые данные для количественных метрик. А результаты качественных измерений очень субъективны.
Количественные метрики, даже будучи измеримыми, могут оказаться не такими полезными. Например, количество требований в проекте. Отдельная цифра ни о чем не говорит. Сравнение этого показателя во времени или относительно других метрик представляет больший интерес – можно отследить тренды:
-
В феврале было зафиксировано на 30% больше требований. Значит ли это, что в марте у команды будет больше работы или просто аналитик стал более внимательным к деталям?
-
Количество новых требований растет быстрее, чем количество приоритизированных требований. Значит ли это, что в процессе находится узкое место (либо аналитик, либо бизнес-стейкхолдер)?
Более правдоподобным кажется подход, когда на основании нескольких несвязанных показателей выделяются тренды, а уже дальше проводится анализ причинно-следственных связей. Например, чтобы понять, как связано качество работы вашего 22-летнего ведущего бизнес-аналитика Ивана с тем, что бюджет проекта превышен в 1,5 раза, а сроки – в 2 раза, вы:
-
измерили Cycle time эпиков в бэклоге за последние 3 месяца
-
изучили субъективную удовлетворенность команды и владельца продукта качеством работы аналитика
-
посчитали количество измененных требований
-
собрали всех вместе и провели root-cause анализ (а, возможно, еще и уволили проектного менеджера)
Всегда ли можно сосчитать количество требований? Да и нужно ли? Предположим, количество пользовательских историй в Jir’e мы посчитаем. Но что делать, если, помимо Jir’ы, есть еще спецификация пользовательского интерфейса и еще пара дизайн-артефактов? Можно ли уже говорить о том, что качество бизнес-анализа на данном проекте низкое? Или начать считать количество макетов интерфейса, страниц в спеке?
На практике имеет смысл использовать только те метрики, которые напрямую или косвенно связаны с конечным результатом работы команды. Отсюда и короткий ответ на вопрос “какие ВА метрики использовать?” – никакие. Не измеряйте, как работают аналитики. Измеряйте, какой результат выдает вся команда.
Другими словами, в проекте все хорошо, в том числе и аналитические активности, если соблюдаются оба из нижеперечисленных условий:
-
Проект успешный (заказчик доволен, исполнитель доволен, все сделано в срок и в рамках бюджета)
-
Достигнута ценность для бизнеса
Если одно из условий не выполняется, то есть вероятность, что причина – низкое качество бизнес-анализа. И обычный анализ причинно-следственных связей должен помочь выявить проблему. Чтобы о проблеме узнать заранее, лучше обратиться к общим принципам мониторинга проектов. Опытный проектный менеджер – ваше все.
Да-да, успешный проект и ценность для бизнеса – это не всегда взаимосвязанные сущности. Но это тема для отдельной статьи.
Возможно, стоило бы опубликовать только предыдущие четыре абзаца и на этом закончить. Но ведь тогда бы мы не раскрыли тему сложности и целесообразности измерения качества работы аналитика.
Конечно, в отдельных случаях измерить качество работы все-таки имеет смысл. И об этом поговорим в следующей части.
Автор
Роман Баканович
Бизнес-аналитик
EPAM Netherlands
