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

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

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

Какую ценность создает аналитик для всех заинтересованных лиц? 

На что повлияет отсутствие аналитика? 

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

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

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

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

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

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

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

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

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

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

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

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

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

Какую ценность создает аналитик для всех заинтересованных лиц? 

На что повлияет отсутствие аналитика? 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласно последнему своду знаний от IIBA, к активностям аналитика относятся:

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

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

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

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

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

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

Поэтому разработка бизнес-стратегии – это для него некая эфемерная и непонятная активность (как и слово “стратегия”). 

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

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

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

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

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

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

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

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

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

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

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

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

И когда мы говорим о распределении активностей аналитика среди других ролей, то часто подразумеваем нечто вроде следующего:

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

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

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

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

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

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

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

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

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

Это, в некоторой степени, можно наблюдать в ситуации, когда владелец продукта, поработав с опытным аналитиком, к середине проекта набрал достаточно знаний, чтобы самостоятельно формулировать и документировать качественные требования и работать напрямую с одной или несколькими командами разработки. В таком случае потребность в отдельной роли аналитика резко снижается. 

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

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

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

Сразу стоит отметить, что “качество активностей” – это не то качество, которое мы хотели бы измерить. В идеальном мире хотелось бы измерить качество результата работы аналитика. А результатом должна являться решенная проблема или реализованная возможность. 

Но здесь мы снова упираемся в «стопицот» зависимостей, факторов и неопределенностей, которые на данный момент точно измерить нельзя. Да, сегодня качество результата ИТ-проекта с точки зрения измеряемости все еще ближе к творчеству, нежели к науке (скажем, к математике). Поэтому, преодолев последний порыв к философствованию и пустословию, предлагаю обсудить, что же мы сегодня все-таки можем измерить.

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

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

Итого измеряем:

• Качество аналитических активностей в общем процессе

• Качество аналитических артефактов

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

Иначе есть риск разработать и внедрить метрики, из-за которых:

• люди будут стараться подстроить свою работу под конкретные KPIs, не обращая внимание пользу от такой работы

• люди потеряют мотивацию

Также зачастую подход к оценке зависит от зрелости процессов в организации и общей договоренности между ключевыми заинтересованными лицами.

В целом, качество работы аналитика может измеряться с помощью как объективных (основанных на данных), так и субъективных метрик.

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

Оказалось, что существенных решений, которые можно было бы применить на практике почти нет. Коллеги в разных компаниях также расходятся во мнении относительно наилучшего подхода к анализу качества БА. 

Отсюда появились 2 гипотезы:

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

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 раза, вы:

1. измерили Cycle time эпиков в бэклоге за последние 3 месяца

2. изучили субъективную удовлетворенность команды и владельца продукта качеством работы аналитика

3. посчитали количество измененных требований

4. собрали всех вместе и провели root-cause анализ (а, возможно, еще и уволили проектного менеджера)

Всегда ли можно сосчитать количество требований? Да и нужно ли? 

Предположим, количество пользовательских историй в Jir’e мы посчитаем. Но что делать, если, помимо Jir’ы, есть еще спецификация пользовательского интерфейса и еще пара дизайн-артефактов? Можно ли уже говорить о том, что качество бизнес-анализа на данном проекте низкое? Или начать считать количество макетов интерфейса, страниц в спеке?

На практике имеет смысл использовать только те метрики, которые напрямую или косвенно связаны с конечным результатом работы команды. Отсюда и короткий ответ на вопрос “какие ВА метрики использовать?” – никакие. Не измеряйте, как работают аналитики. Измеряйте, какой результат выдает вся команда.

Другими словами, в проекте все хорошо, в том числе и аналитические активности, если соблюдаются оба из нижеперечисленных условий:

• Проект успешный (заказчик доволен, исполнитель доволен, все сделано в срок и в рамках бюджета)

• Достигнута ценность для бизнеса

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

Да-да, успешный проект и ценность для бизнеса – это не всегда взаимосвязанные сущности. Но это тема для отдельной статьи.

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

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

Качество работы аналитика – вещь сложно измеримая. Но в некоторых случаях измерять его все же может быть полезно. Например, вам нужно сравнить качество работы все того же 22-летнего ведущего аналитика Ивана, которого упоминали раньше, и скромного старшего аналитика Василия. Кому и насколько повысить ЗП? И как объективно доказать Ивану, что ему еще стоит получить немного практического опыта, прежде чем он получит очередное повышение?

Про “зачем измерять?” мы говорили в первой части. Про “что стоит и не стоит измерять?” – поговорили во второй части.

Теперь поговорим про “как измерять?”

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

Опять же, стоит измерять только то, что было исправлено:

• не все требования фиксировались? Измерять покрытие решения требованиями, измерять трассируемость требований к решению (solution requirements) к более высокоуровневым (stakeholder requirements, business requirements)

• многие требования были двусмысленными и неполными, поэтому команда по нескольку раз переделывала решение? Ввести дополнительный контроль качества спецификации (проверка спецификации тестировщиками или другими аналитиками). Соответственно, отслеживать, что требования проверяются, а измерять количество переделок.

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

Из различных методов анализа качества наиболее реалистичными мне кажутся следующие:

• Экспертная оценка

• Анализ данных

• Интервью, опросы

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

Рассмотрим реальный пример №1 — “Формальный”

Телекоммуникационная компания имеет свои продукты (как софт, так и железо), а также предоставляет многие услуги клиентам (интернет, телевидение, развлекательные сервисы). Компания эта работает давно на разных рынках (и континентах), успела поглотить еще дюжину других компаний и теперь хочет быть гибкой и эффективной. Руководство основного подразделения решило, что текущее время от появления идеи для существующих продуктов до ее конечной поставки потребителю никуда не годится (от 6 до 12 месяцев). И очень уж хочется это время сократить до, скажем, 3 месяцев.

В итоге, запустили проект по трансформации внутренних процессов. Работа с требованиями в отдельных подразделениях также оптимизируется. Проектная группа провела примерно 30 интервью с высшим руководством, менеджерами отделов, менеджерами проектов и продуктов. Были проанализированы некоторые завершенные и текущие проекты – все это позволило выделить проблемные области, требующие внимания.

Непосредственно анализ аналитических активностей делали следующим образом:

1. Сформировали подход к оценке качества

2. Отобрали контрольные группы проектов

3. Собрали количественные и качественные данные, напрямую или косвенно отражающие качество работы с требованиями

4. Проанализировали данные и выделили проблемные области согласно определенному ранее подходу

Подход к оценке качества в нашем случае выглядел так:

Суть подхода заключается в выделении отдельных категорий требований и анализе изменения конкретных атрибутов качества в рамках всего жизненного цикла.

Например, возьмем уровень бизнес-требований. В нашем случае бизнес-требования фиксировались в бизнес-кейсе и далее трансформировались в Product user story. Пусть название не покажется вам обманчивым – это еще не пользовательское требование. Одна Product user story далее делится на 5-6 более низкоуровневых требований (Technical user story), каждое из которых может реализовываться отдельной командой в течение спринта. Т.е. чтобы полностью реализовать Product user story (и, соответственно, предоставить хоть какую-то ценность для конечного пользователя), может уйти от одного до 3-х месяцев.

Для того чтобы понять, насколько качественно выполняется работа с требованиями на уровне “Product user stories” (повторюсь: в нашем случае это бизнес-требования), мы собрали информацию о том, как требования собирают, фиксируют и отслеживают их изменение, кто вовлечен в процесс, как измеряют результат.

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

• Изучили инструменты по работе с требованиями

• Составили 65 вопросов, покрывающих все уровни требований на всем этапе их жизненного цикла

• Провели 20+ интервью, включая топ-менеджмент, проектных менеджеров, менеджеров продукта на стороне заказчика, аналитиков и инженеров на стороне исполнителя

В итоге получили следующую картину:

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

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

Рассмотрим реальный пример №2 — Оценка “на глаз”

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

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

В итоге, получили такой отчет (текст анонимизирован, некоторые детали упущены, но суть не поменялась):

BA Process status

BA team: 2 Business analysts

Workload: 100% for each BA

Average number of active work streams: 10

Responsibilities

Clearly defined and separated between the BAs: there are 2 projects, each BA is responsible for all BA activities on a separate project . The BA is the single point of contact per project for the customer.

BA Process review

Requirements gathering

Requirements gathering process is adjusted to the project specifics. Most BA efforts are spent on gathering stakeholder and solution requirements, hence, the customer team is responsible for making sure that the business requirements are correct.

 

Specific issue (Project #1): For the last 2 months after the onsite session the most tasks (70% of a BA capacity) were related to data migration. During that time the BA was working as requirements/system analyst and was not involved into analysis of business requirements.

 

For other streams BA actively participates in analysis of business goals and objectives. However this area still has space for improvement.

 

Requirements analysis

Visual models, prototypes are timely created and validated with the customer. Requirements verification process includes gap analysis and is performed by BA and QA teams collaboratively.

In complex scenarios a BA creates a prototype on Staging environment to demonstrate a potential solution.

 

Regarding data migration issue (Project #1):

The  process for performing operational tasks has been improved only recently (e.g. BA received an urgent request from the customer and made changes on the Production with customer approval. However «urgent tasks» were not clearly analyzed and the solution was changed. Starting from June the process has been adjusted: any migration-related tasks (regardless how urgent they are) are analyzed and prioritized accordingly.

 

Requirements specification

Current approach to specifying requirements is completely sufficient to support the development process. It is confirmed by the Scrum team.

Additionally user guides are created for the entire solution. However we feel that the efforts for creating guidelines might be spent more efficiently, since the documents seem to be not used to the full extent.

 

Requirements management

Managing the requirements means being able to conduct impact analysis and eventually implement a change with sufficient quality and costs. Current process includes 2 stages for requirements management.

1. For the entire solution all the requirements are traced to code (via tasks in Jira and pages in Confluence) so that it’s easy to identify defects and their cause.

2. Additional optional step: using traceability matrices in case the solution is considered complex and effort for maintaining the matrix are justified.

 

BA Performance

Velocity

Average lead time for a user requirement (from a request to an estimated and prioritized User stories) is approx 2 weeks. The main challenge is validation and prioritization of the specified requirements. It might take up to 2 months until there is a prioritized and approved User story. However the average time needed to process a request, analyze and specify requirements is approx 1 day.

Other metrics

Stakeholders satisfaction:

Teams are completely satisfied with BA deliverables and the way of work. Subjective feedback from the team shows no issues.

Customer satisfaction shall be measured.

Change requests

Metrics baseline:

Low number of change requests — approx. 10% of overall tasks

Normal number of change requests — approx. 20% of overall tasks

High number of change requests — approx. 30% of overall tasks

1. Project #1 contains average (normal) number of change requests.

2. Data migration stream has the biggest number of change requests and can be considered unsatisfactory. Please see the list of issues for improvement for more details.

3. Number of change requests for other work streams is low. Now issues have been found here.

Summary — Issues that need improvement:

• End-users don’t read the documentation

• Data migration has become a problematic area from different perspectives.

The main issues:

• Not clear business requirements (there is no proper analysis of namely business requirements since they are provided by customer team and it’s difficult to find out the root cause for each requirement)

• End-users do not always provide detailed input which leads to longer time of processing a request

• Number of change requests is high. The main issue is related to the proper analysis BEFORE the request for implementation is created. The main improvement point is to involve a BA at earlier stages when an end-user contacts the customer team. BA shall discuss actual problems directly with end-users and then coordinate with the customer team members in case some changes are needed.

• Requests prioritization could be improved: too many tasks are marked as urgent. More thorough prioritization shall be made prior to submitting the request.

• BA performs support-related tasks that take more than 50% of BA workload which leads to longer duration of performing major activities (with the same amount of efforts needed). Hence, it affects an average lead time for a requirement.

Root cause:

• End-users are still not very comfortable with the platform and not educated about the solution. Solving this issue will reduce the number of requests from end-users. Hence, it will save time both for the customer and the vendor.

• L1 support team still lacks needed skills and knowledge about the solution. Additional trainings would allow to move more requests processing from BA to L1.

• BA should be allowed to access end-users directly to improve the communication and support process.

 

Summary — action items

Based on the conducted analysis we recommend to perform the following correction steps:

1. Review the original project goals and objectives. Many identified issues are related to two factors:

   1. Unclear justification of stakeholder requirements. Stakeholder requirements shall be mapped to business objectives. This will allow to prioritize the solution roadmap correctly, as well as identify work that should not be done at all.

   2. Lack of user adoption. Many of the requests originate from the customer employees who don’t have clear understanding of the platform in general and the solution in particular. We recommend to slow down the development of new functionality and focus on user training and optimization of the current solution.

2. Review the prioritization process, identify the criteria and formal workflow.

3. Conduct additional training of the L1 support team (or 1-2 of it’s members) so that eventually it would be possible to move support tasks to L1 entirely.

4. Review the overall life-cycle of a request and renegotiate BA involvement at each stage.

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

Заключение

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

Как вы, реализуя решение, помогаете клиенту получить эффект для бизнеса? 

Как этот эффект измеряется? Какой вклад вносит ваше решение? 

Какой возврат от инвестиций получит клиент, когда ваше решение будет внедрено? 

Если на любой из этих вопросов вы не можете четко ответить (а вы, скорее всего, не ответите хотя бы на один), то лучше потратить все усилия на уточнение этих вопросов, нежели на поиск способов улучшить работу аналитика, которая, в итоге, не принесет желаемого результата. Звучит банально, но, поверьте, все больше клиентов начинают об этом задумываться. И это замечательный тренд!

Как сказал один коллега из Питера: “Аналитик – это тот, кто важное делает явным”. Все остальное – второстепенно. Если решили оптимизировать качество работы ваших аналитиков – сделайте фокус на том, как они смогут лучше помочь бизнесу понять, что важно. С остальным вполне справятся толковые инженеры.

https://www.lobanov-logist.ru/library/352/64292/

https://ekspertov.ru/

Автор

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

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

EPAM Netherlands

http://analyst.by/news/kak-izmerit-kachestvo-rabotyi-analitika-chast-1