Мнение читателя — PMtalk-3 (в защиту бизнес-аналитика)

opinionПо результатам PMtalk-3 нам поступило несколько очень интересных комментариев. Ради одного из них мы даже решили открыть рубрику «Мнение читателя». Комментарий Полины Филаретовой публикуем ниже, без купюр.

В основном хотела бы заступиться за бизнес-аналитика.

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

Итак, мое слово в качестве адвоката БА. 🙂 Для начала – пара слов от «капитана Очевидность».

 Первое. Результатом любого проекта является продукт (в широком понимании этого слова).

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

 Второе. В проекте всегда существует определенный набор функциональных ролей.

Например, если говорим о разработке ПО / АПК, это: руководитель проекта, продакт-менеджер, бизнес-аналитик, архитектор, системный аналитик, разработчик, кодировщик, тестировщик, технический писатель… Ну и при желании можно еще добавить заказчика, конечного потребителя и т.д.

(Заметим: БА – роль, которая участвует в проекте в любом случае.)

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

 Вопрос, заданный «адвокатом дьявола»: «БА – кто это такой и зачем он мне нужен в команде», наверное, было бы правильно перефразировать в: «когда в проекте целесообразно выделять отдельного человека для той или иной роли, в частности для роли БА».

Здесь было бы полезно вспомнить о компетенции каждой из ролей.

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

 

Роль в проекте Компетенция
Руководитель проектов Процессная и организационно-контролирующая сторона проекта, связанная с производством, изменением, внедрением, эксплуатацией продукта. Сюда, в том числе, входит и «высокий политИк» – внутрифирменный и на уровне взаимодействия с заказчиком и третьими сторонами.   
Продакт-менеджер Продукт, его потребительские свойства, перспективы жизни и развития на рынке.
Архитектор Проектирование продукта, выбор технических решений, оптимальных для тех требований, условий и задач, которые определены для продукта.
Разработчик Непосредственная разработка и реализация продукта в тех рамках, которые обозначил архитектор и которые заданы требованиями.
Тестировщик Разработка системы тестирования, соответствующей уровню продукта, создаваемого в проекте, и выявление недостатков продукта (т.е. выявление отклонений от требований, которые предъявляются к продукту).
Бизнес-аналитик Выявление (формализация) требований к продукту, их систематизация, актуализация, адаптация и верификация (а также контроль изменений требований). Это первично.Все прочее: переводческая деятельность (с языка заказчика и продакт-менеджера на язык разработчиков), работа в качестве инфо-брандмауэра, баннера бредовых идей, возмутителя спокойствия и т.д. и т.п.) — вторично и является необходимым следствием первичной компетенции.

 В общем-то функция БА сводится к трем составляющим:

1) получить от прочих участников проекта данные,

2) полученные данные, применяя анализ и синтез, верифицировать, обработать и преобразовать в материал, «съедобный» для прочих участников проекта,

3) предоставить обработанные данные (материал) прочим участникам проекта.

 

Частным и наиболее частым материалом (в данном контексте) являются требования.

А требования – суть «основа основ » продукта. (Да, это была ремарка от «капитана Очевидность» 🙂 ). Без требований немыслимы ни разработка, ни тестирование продукта. В данном случае работа БА носит для проекта не «промежуточный», а ключевой характер. (А это была «шпилька в бок» адвокату дьявола.)

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

Обладают ли менеджер проекта, архитектор и другие разработчики, технический писатель этими знаниями и навыками в должной мере? Если «да» – то замечательно: кому-то из них вместе с его основной ролевой функцией можно поручить выполнение и функции БА… А если «нет»?

Следует отметить еще одну «значимую точку» в вопросе «нужен ли в проекте отдельно выделенный БА».

К сожалению, до сих пор в проектах уделяется крайне мало внимания формированию и управлению требованиями. (Правда это мое личное наблюдение, которое может быть не лишено субъективизма.) Здесь я говорю не столько о тех требованиях, которые содержатся в ТЗ, сколько о требованиях, необходимых для архитектора и разработчика. Чаще такое «невнимание» наблюдается там, где в команде проекта отсутствует отдельно выделенный БА. Стоимость для проекта «незамеченных» или «недодуманных» требований к продукту бывает весьма высока.

 

Ну и если подытожить:

1) нередко в проекте один специалист выполняет несколько функциональных ролей. Также никто не отменял «специализации» и «кооперации» участников проекта. В зависимости от сложности проекта должен быть найден здоровый баланс этих подходов,

2) функция БА в проекте в любом случае выполняется,

3) если БА в проекте нет, то вопрос – действительно ли тот, кто выполняет функции БА, обладает необходимыми знаниями и навыками? Кто, в какой мере, насколько регулярно и успешно работает с требованиями? Все-таки в не самых простых проектах выделение БА в качестве отдельной штатной единицы имеет смысл и приносит больше пользы, чем затрат.  

PS: Полина, спасибо за развернутый комментарий, за то что нашли время и вступили в дискуссию! Коллеги, приглашаем вас делиться своим мнением (будем выборочно публиковать на сайте) и без ограничений участвовать в обсуждениях на linkedin.

Дата публикации: 29.01.2015

Обсуждение закрыто.