Качество работы аналитика – вещь сложно измеримая. Но в некоторых случаях измерять его все же может быть полезно. Например, вам нужно сравнить качество работы все того же 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-матрицу и по ней работать все еще иногда полезно). Но гораздо, гораздо более актуальный и эффективный метод – фокусироваться на результате. Как вы, реализуя решение, помогаете клиенту получить эффект для бизнеса? Как этот эффект измеряется? Какой вклад вносит ваше решение? Какой возврат от инвестиций получит клиент, когда ваше решение будет внедрено? Если на любой из этих вопросов вы не можете четко ответить (а вы, скорее всего, не ответите хотя бы на один), то лучше потратить все усилия на уточнение этих вопросов, нежели на поиск способов улучшить работу аналитика, которая, в итоге, не принесет желаемого результата. Звучит банально, но, поверьте, все больше клиентов начинают об этом задумываться. И это замечательный тренд!

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

Автор

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

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

EPAM Netherlands