Может ли все работы в проекте выполнять один человек? Может, но проект не может обойтись без, например, тестирования. Тестировать могут разработчики, менеджеры, конечные пользователи. Также и с бизнес-анализом. Предположим, у нас есть потенциальный клиент и он ставит задачу «хочу второй Amazon» или «хочу новую CRM». Пожелание высказано, но что именно нужно делать команде — непонятно. Есть расхожее выражение «Когда люди покупают дрель, им не нужна сама дрель. Им нужны дырки в стене (или разъяренные соседи). Результат, а не сам инструмент». Так и заказчику нужна не сама CRM, а нужно решить бизнес-проблемы.
Если мы поможем эту проблему выявить, проанализировать ее значимость, определить каким бизнес должен стать, повысим вероятность успеха и проекта, и бизнеса клиента. А ведь именно в этом и заключается идея партнерских взаимоотношений — не просто продавать время специалистов, а помогать развивать бизнес наших клиентов за справедливую плату. И в процессе этого анализа может оказаться, что клиенту нужна вовсе не CRM, а что-то другое, а разработка CRM привела бы просто к пустой трате ресурсов.
ЗАДАЧИ И ТРЕБОВАНИЯ
Итак, перед началом проекта нам необходимо определить, на решение какой проблемы направлен проект, понять, как устроен бизнес-процесс сейчас, каким он должен стать, каковы границы проекта, каковы критерии успеха. В процессе поиска ответов на эти вопросы мы можем столкнуться с тем, что со стороны клиента есть несколько влиятельных заинтересованных лиц и у каждого из них свое видение по проекту. Если не привести их к единой точке зрения, проект может остановиться в любой момент. Значит, кто-то должен взять на себя роль модератора/фасилитатора, организовать серию обсуждений и сформировать общее видение. Эта задача будет повторяться и по ходу проекта, когда будут обсуждаться детали реализации: бизнес-правила, шаги бизнес-процесса, обязательность атрибутов, внешний вид интерфейсов и многое другое.
Вот мы сформировали общее видение, поставили высокоуровневые цели. Можно приступать к реализации. Но что именно нужно делать команде? Есть только постановка задач на высоком/концептуальном уровне. А теперь ее нужно декомпозировать на относительно небольшие задачи, прописать на детальном уровне критерии приемки, объяснить задачу разработчикам и тестировщикам. Не так важно, кто это сделает, главное, чтобы было сделано. Проект продвигается и меняется контекст. То, что вчера было очень важным, сегодня может стать второстепенным. Могут поменяться требования регулятора или измениться интерфейс системы, с которой наше решение должно быть проинтегрировано. К сожалению, требования после утверждения практически всегда меняются. Этими изменениями нужно управлять, иначе команда будет делать не, что нужно клиенту или не в той последовательности.
ДАЛЕКО ЛИ МОЖНО УЕХАТЬ БЕЗ БИЗНЕС-АНАЛИЗА
Все вышеперечисленное — работы по бизнес-анализу. Часть этих работ может выполнять клиент, но он, как правило, ограничивается широкими мазками и высокоуровневым видением. Эту работу может делать менеджер проекта или архитектор, но, если проект достаточно большой, и у него не хватает времени. Можно попытаться эти работу распределить или назначить на разработчиков, тестировщиков, тимлидов или дизайнеров. Но у семи нянек дитя без глаза. В результате — хаос или значительная неопределенность, расползающиеся границы проекта, демотивированная команда и недовольный заказчик.
Кто-то может сказать, что бизнес-анализ — не самая важная проектная активность. Давайте посмотрим, что об этом говорит специалисты, отвечающие за успех проекта. В 2017 году PMI (Project Management Institute) проводил глобальное исследование, в котором приняло участие более 3 234 специалистов по управлению проектами. Один из вопросов исследования — «какие основные причины неуспеха проектов, которые были начаты в вашей организации за последние 12 месяцев? (укажите до 3-х причин)».
Первые пять причин, набравшие наибольшее число голосов, напрямую связаны с бизнес-анализом: изменения в приоритетах организации (41 %), ошибки на этапе сбора требований (39 %), изменение целей проекта (36 %), неадекватное видение и цели проекта (30 %), слабая коммуникация в проекте (30 %). Из этого можно сделать вывод, что именно развитие бизнес-аналитических компетенций способно увеличить количество успешных проектов.
ПОЧЕМУ БИЗНЕС-АНАЛИТИК В КОМАНДЕ — ЭКОНОМИЯ
Ответов на вопрос «в чем заключается работа бизнес-аналитика?» много. Но, с точки зрения команды, основная его задача — снижение неопределенности. Мало делать вещи правильно (у нас отличная техническая экспертиза и богатый опыт создания сложных решений), но нужно еще делать правильные вещи — те, которые решат проблемы бизнеса клиента и помогут ему достичь цели. Бизнес-аналитик предоставляет команде информацию, отвечает на вопросы, устраняет препятствия и гарантирует, что техническое решение развивается в соответствии с ожиданиями заказчика.
Для заказчика наличие бизнес-аналитика в команде позволяет снизить стоимость решения. Можем показаться, что еще один человек в команде требует дополнительных инвестиций, но в долгосрочной перспективе это приводит к уменьшению стоимости. ROI бизнес-аналитика = (Затраты на переделки, которых мы избежали)/Цена бизнес-аналитика. Ключевой элемент — сокращение объема работ, требуемых для достижения целей. Прояснение потребностей всех заинтересованных лиц, формирование общей согласованной картины, привязка всех требований к бизнес-целям — все это позволяет избегать многочисленных переделок в дальнейшем.
В одном из моих первых проектов команды трижды переделывала модуль, потому что результат не устраивал заказчика. А не устраивал он его потому, что не были выяснены все детали процесса, команда полагалась на свою интуицию и результаты разговоров с конечными пользователями. И именно добавление бизнес-аналитика в команду после второй неудачной попытки сдать подсистему заказчику позволило выровнять ситуацию и избежать похожих проблем в дальнейшем.
Второй бонус для заказчика — повышение отдачи от проекта. По правилу Парето, 20 % усилий дают 80 % результата. Благодаря роли связующего звена между бизнесом и техническими специалистами, бизнес-аналитик позволяет определить эти самые 20 % функциональности, реализация которой закроет 80 % бизнес-сценариев и позволит начать использовать решение раньше.
Один из невосполнимых ресурсов проекта (кроме терпения его участников) — время. Выявление требований, достижение консенсуса со всеми заинтересованными лицами — задача очень трудоемкая. И не всегда у технических специалистов хватает на это времени. С другой стороны, представители бизнеса не всегда готовы общаться с техническими специалистами: у одних пробелы в технических знаниях, другие не до конца понимают, как устроен бизнес, и хотят обсуждать именно технические детали.
Нет сомнений, что это общение повышает осознанность разработки, но также истинно, что эти встречи могут занимать много времени, разная терминология приводит обе стороны в замешательство, и вместо позитивного эффекта мы можем прийти к противоположному эффекту. А бизнес-аналитик позволяет закрыть этот разрыв между бизнес-требованиями и техническими требованиями, построить правильные коммуникации между всеми заинтересованными лицами.
БИЗНЕС-АНАЛИЗ И ПРОЕКТ
Давайте рассмотрим, как соотносятся бизнес-аналитические работы с проектом.
ПРЕДПРОЕКТНЫЕ РАБОТЫ (Discovery/Solution Design) — фаза, на которой проводится обоснование целесообразности старта разработки.
Понять текущее состояние бизнеса, его проблемы или возможности, которых ему не хватает.
Понять, что именно бизнес-хочет получить по результатам разработки и внедрения решения.
Определить подходы к решению выявленных проблем и выбрать из них тот, который приносит максимальную ценность для заказчика.
Определить на высоком уровне границы решения и критерии успеха.
ПРОЕКТНЫЕ РАБОТЫ — фаза, на которой идет активная разработка и тестирование.
Выявить, описать и согласовать детальные требования к решению.
Управлять изменениями требований.
Проводить приоритизацию требований.
Организовать приемочное тестирование.
ПОСТПРОЕКТНЫЕ РАБОТЫ — фаза оценки полученной ценности/пользы.
Оценить полученный результат.
Обработать замечания и предложения, полученные по результатам эксплуатации.
Обновить базу знаний по проекту.
Как видим, на всех этапах предполагается выполнение бизнес-аналитических работ. И как сказано в заглавии, не так важно, кто их сделает. Главное, чтобы они были сделаны правильно. Нужен ли для них отдельно выделенный человек, каждый проект решает самостоятельно. Но сама история развития человечества, во многом построенная на принципе разделения труда и специализации, подсказывает, что для решения сложных задач целесообразней привлекать профильных специалистов.
Так в каждый ли проект требуется бизнес-аналитик? Нет. Если проект чисто технический, например, перевод продукта на другой технологический стек, при этом по продукту есть исчерпывающие требования и все остается как есть, можно обойтись без него. Если проект небольшой, например, два разработчика плюс тестировщик, бизнес-аналитик будет лишним.
Распределение бизнес-аналитических задач между членами команды может сильно варьироваться. Часть работ может выполнять Solution Architect, часть — менеджер проекта, часть — тестировщик, если у них хватает времени и желания. Или со стороны клиента есть бизнес-аналитик, который будет выполнять все вышеперечисленные бизнес-аналитические работы, и он готов плотно взаимодействовать с командой разработки ежедневно. Но такая ситуация — возможность для нас показать, что, кроме проектирования, разработки и тестирования, мы можем предложить и еще один сервис — сервис бизнес-анализа.
(Оригинал статьи опубликован на сайте компании DataArt)
Comments