Я – разработчик. Что этот аналитик делает на моем проекте?

ImDeveloper Оригинальная статья: «I’m a software developer, why is this business analyst on my project?» by Laura Brandenburg.

На прошлой неделе я выступала с докладом в чартере IIBA в Финиксе на тему окупаемости инвестиций в бизнес-анализ. Уже в самом начале презентации стали прослеживаться две важные тенденции:

1. Более 90% всех присутствующих бизнес-аналитиков приходилось постоянно отчитываться о выполненных задачах и потраченном времени.

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

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

Есть подозрение, что эти люди столкнулись с чем-то похожим на то, что Rachel озвучила в своем комментарии к статье о пользе бизнес-анализа. Суть ее комментария в том, что бизнес-аналитик скорее вредит проекту, чем приносит пользу.

Она писала следующее:

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

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

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

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

Давайте зададим такой вопрос: если бы я был разработчиком, что бы это мне дало? Другими словами, какую конкретно пользу разработчикам приносит наличие на проекте бизнес-аналитика?

Меньше переделок = меньшее количество времени потрачено на один и тот же кусок кода

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

В большинстве случаев разработчики, с которыми мы работаем, не имеют почасовую оплату. Наши запросы на изменения (change requests) не всегда ведут к продлению проекта, скорее к дополнительным часам в офисе по вечерам или выходным.

Меньше разговоров о требованиях = меньше потраченного на обсуждения времени

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

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

Поиск более эффективных решений = Проект не нужен!

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

Определение реальных бизнес-целей = Решение верной проблемы

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

Расстановка приоритетов фокусирует усилия на важнейших аспектах = Моим кодом реально пользуются

У разработчиков тоже присутствует эго. Им хочется, чтобы написанным ими кодом реально пользовались. Если вы будете скидывать им требования на наименее важные части системы и они будут неделями писать код для этих частей, их эго вскоре пошатнется. Если вы уверенно можете заявить «Да, это на самом деле нужно заказчику», то вы предоставляете разработчикам возможность построить нечто, что будет иметь реальное применение.

Более эффективная реализация бизнес-решений = Опять же, мой код реально используется и…

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

Вся первоначальная работа бизнес-аналитика направлена на минимизацию подобного рода жалоб, хотя и не в состоянии устранить их все. Менять систему – всегда сложно, а программное обеспечение редко бывает совершенным. Когда аналитиков привлекают к процессу поставки системы, к примеру, для обучения пользователей или координации приемочного тестирования, они зачастую выступают в качестве щита между пользователями и разработчиками, оставляя последним лишь наиболее важные запросы на изменения (и при этом помогая пользователям найти обходные пути решения «небольших изъянов»).

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

Laura Автор: Laura Brandenburg. Независимый консультант в сфере бизнес-анализа. Страстно относится к своей профессии и активно поддерживает ресурс и форум http://www.bridging-the-gap.com для того, чтобы бизнес-аналитики обменивались своим опытом. Другие статьи от Laura Brandenburg: http://www.bridging-the-gap.com/author/laura-brandau/