📊 Аналитика проекта: что это и зачем вам это нужно — Блог Live Typing

«аналитик и» проектный менеджер

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

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

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

Кейс из практики: месяц разработки был потрачен на функционал переноса списка активностей из объекта №1 в объект №2. На этапе приемочного тестирования обнаружилось, что заказчик ожидал совершенно иной функционал — копирование, а не перенос активностей. В процессе переделывания функционала и детализации двусмысленности IT-команда, во-первых, договорилась с заказчиком о MVP, а, во-вторых, о необходимости работы с корнем бизнес-проблемы. Было выдвинуто предположение, что сам функционал копирования требуется только лишь по причине недостаточно качественно реализованного функционала подгрузки шаблонов активностей.

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

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

Записывайте цели вместе с заказчиком, чтобы абсолютно все участники процесса в любой момент времени понимали, зачем они выполняют свою работу.

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

Во время очной встречи руководителя подразделения с подчиненным, где мы — аналитик и UX-дизайнер — сидели «в фоне», выявился целый ряд требований, который не проявлялся в течение целого года работы команды. Мы обращали внимание на все детали: ручные записи руководителя и сотрудника, на стикеры, на пометки в windows-блокноте, на действия внутри системы. По итогу такой встречи бэклог был существенно дополнен, а мы приступили к глубокой переделке реализованного в системе функционала.

Взгляд с позиции руководителя проекта

Через 1,5 года, заняв позицию РП в той же компании, на проблематику удалось взглянуть со стороны. Имея в подчинении 3 разных бизнес-аналитиков, стало очевидным, без преувеличения, колоссальное влияния компетенций бизнес-аналитика на все параметры проекты:

• Функциональные границы проекта — без комментариев.
• Рабочая атмосфера. Как показывает практика, обычно проектная команда, пусть и не в открытую, считает главным виновником всех проблем почему-то именно бизнес-аналитика (ну если не считать РП естественно). Умение не допускать больших «погрешностей», а главное умение достойно выйти из напряженной ситуации взаимных претензий внутри команды, сглаживать конфликты во многом позволяет БА существенно повысить мотивацию всей группы.
• Сроки проекта. Зачастую этап, назовем его «анализ» (обследование, проектирование), существенная часть проекта по длительности, в среднем 10-30%, который зачастую нельзя поставить параллельно с другими работами по этому проекту, даже при большом желании. Соблюдение срока этого этапа, прямо влияющего на срок всего проекта, почти полностью зависит от организованности и компетенций БА (или ведущего БА или РП, если в одном проекте их несколько).
• Решение организационных проблем путем облегчения коммуникаций. Как правило, бизнес-аналитик лучше, чем кто-либо еще знаком и пользуется доверием большинства сотрудников у заказчика. Организовать оперативно взаимодействие с сотрудниками клиента, не дожидаясь формальной эскалации — через него гораздо проще.
• Незаменимый ресурс в ходе проекта. Думаю, что смена руководителя проекта в ходе проекта среди топ-5 основных причин появления некачественных проектов в этой сфере (за исключением наверное совсем уж типовых проектов). Смена бизнес-аналитика в ходе проекта — вероятно на соседней строчке такого рейтинга. На аргумент о необходимости качественного документирования, ответил бы так: к сожалению все не задокументируешь. В проекте помимо понятных вещей, в виде функциональных требований, целей, описания задач, очень часто важны атмосфера, эмоции, «тайные» ожидания заказчика. Формализовать и перенести это на бумагу в принципе далеко не всегда возможно.
• Приемка проекта и его бюджет. Обычно в практике внедрения на рынке компания-заказчик по выручке и другим показателям в десятки, сотни раз крупнее компании-внедренца. Слон и Моська так сказать. Зачастую «Слон» считает вполне приемлемым опираться в таких отношениях не только на задокументированные договоренности, но и на кулуарные разговоры, обещания «фишечек», «плюшечек», которые когда-то по его мнению звучали, но почему в документацию не попали. Аргументация вида, что «Вы же профессионалы, должны были это учесть, мы естественно могли что-то пропустить, согласовывая сотни страниц документации, но это Вы же мне лично обещали» вполне состоятельная, как минимум потому, что он — «Слон», а Вы — «Моська», а проект сдавать как-то надо. Недопущения таких ситуаций, вероятно это часть так называемого управления требованиями и ожиданиям, и — одна из главнейших задач БА совместно с РП. Самое печальное, что этому, на мой взгляд, в принципе невозможно научить, это своего рода искусство и талант, ну и естественно опыт.