IAMPM
65000
+38 (091) 481 01 38+7 (495) 128 58 05info@iampm.club
BA

Роль бизнес-аналитика на Discovery-фазе проекта

3 сентября 2021

  • Автор: Александр Кононенко

  • Сложность: норм

  • Время: 8 мин

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

Как устроен процесс дискавери, какие сложности возникают чаще всего и что делать, если клиент отказывается от предварительного этапа? Спросили у двух BA Leads с опытом 14+ лет в IT.

Кирилл Белявский и Антон Бабенко, авторы и ведущие курса Badass BA, отвечают на вопросы о Discovery и роли бизнес-аналитика в нем.

Читайте ответы в статье или слушайте аудиоинтервью с Кириллом Белявским и с Антоном Бабенко в подкасте Нетехнического IT.

В IT-сфере существует, как минимум, два понятия о дискавери: продуктовое и проектное. Сразу определимся, о каком из них пойдет речь в статье:

Product Discovery — придумывание продукта либо его доработка и развитие. Здесь основной акцент на разработке гипотез, валидации, исследовании пользовательского опыта. О продуктовом дискавери говорить не будем. 

Project Discovery — предварительное или дополнительное изучение проекта, которое производят до старта работ или уже в текущем проекте. IT-компания выступает в роли подрядчика (вендора) для заказчика на аутсорсе. Именно о Project Discovery и пойдет речь дальше.

О целях дискавери и уровне бизнес-аналитика

IAMPM

Discovery — это фаза анализа и дизайна, когда выявляют бизнес-требования и подготавливают клиенту видение его проекта. Для аутсорс-компании, дискавери — это один из этапов продажи услуг по разработке решения заказчику. 

Клиенты часто приходят с документами, которые содержат минимум информации о том, что они хотят и зачем. Дискавери помогает понять, что на самом деле нужно бизнесу, и насколько настоящие цели отличаются от желаний клиента. Для ВА важно найти компромисс между реальными бизнес-потребностями и «хочу» заказчика.

Всегда ли нужна дискавери фаза? 

Если к вам заходит проект со сложной структурой и бизнес-логикой, который предполагает множество интеграций, — однозначно необходимо проводить дискавери. Если же поступил запрос на какое-то шаблонное решение, которое IT-компания уже выполняла раньше, то возможно, получится обойтись нулевым спринтом. Домены тоже влияют на необходимость Discovery. В нишах, где постоянно меняется законодательство или требования к программному обеспечению, без дискавери-фазы никак.

IAMPM

Цель Discovery — разобраться: что именно нам необходимо делать, какое решение предложить бизнесу клиента, какова сложность и объем реализации поставленных задач, — и выдать понятную оценку проекта.

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

Конечно компании хотят, чтобы в таком ответственном процессе участвовал максимально опытный специалист (как правило, уровня senior). В реальности, бывают ситуации, когда за неимением других альтернатив, на исследование отправляют и джунов, особенно если новичок ВА — хороший эксперт в конкретном домене. Но для качественного дискавери только опыта в конкретной нише или регионе все же недостаточно.

Что делать, если клиент не хочет Discovery

Антон Бабенко: Дискавери — это логичное продолжение пресейла и задача менеджера здесь — убедить клиента, что Discovery поможет найти решение, полностью покрывающее бизнес-потребности:

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

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

Чем обычно заканчивается сложный проект без дискавери:

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

Кирилл Белявский: Клиенты часто не понимают, зачем дополнительно платить за изучение проекта, ведь они пришли к профессионалам, принесли требования, — давайте стартовать. 

Что можно сделать: 

  • Предложить заказчику разделить с ним риски. Мы проводим дискавери, презентуем результаты, и, если клиент отказывается от сотрудничества, — тогда дискавери за наш счет. Если же ему все нравится, — он оплачивает эту стадию, и мы дальше продолжаем работу над проектом. 
  • Прописать оплату Discovery как отдельной услуги или предложить скидку.
  • Согласиться на разработку без дискавери-фазы, заложив все возможные риски в эстимейт. 

Отсутствие Discovery, как правило, выливается в рост скоупа, что, в свою очередь ведет недовольству клиента и  прекращению сотрудничества. Дискавери не гарантирует, что проблем не будет, но серьезно снижает риски провалить проект. Тут важна совместная работа команды: вопросы оплаты лучше оставить РМ-у и сейлз-менеджеру.   

Как устроен Discovery-процесс в SoftServe и Binariks?

Кирилл Белявский: В SoftServe мы работаем с большим количеством доменов, разными методологиями и разными объемами команд. Поэтому у нас нет единого стандарта или подхода к дискавери, зато есть специальное подразделение, которое «заточено» под проведение дискавери. В его составе —  бизнес-аналитики, архитекторы и проектные менеджеры, которые проводят Discovery на постоянной основе. У них есть свои фреймворки, которые зависят от доменов и других условий. Что-то вроде конструктора: кого привлечь к дискавери, каким будет процесс и так далее, в зависимости от продукта. 

Например, в проекте для массового пользователя, где важен UX, одним из ключевых участников дискавери будет дизайнер и в работе, скорее всего воспользуемся фреймворком design thinking.
Теперь возьмем проект технического характера, у которого в задачах load balancing серверов, а сам проект направлен на целевую аудиторию технических специалистов. Здесь UI и UX не столь критичны, и на первое место выходят нефункциональные либо чисто технические требования, и подход к выполнению Discovery в данном случае будет другим.

Антон Бабенко: В Binariks бизнес-аналитик подключается к общению с клиентом на этапе пресейла. Здесь первая задача BA — не спугнуть заказчика, задавая ему слишком подробные вопросы или глубоко «закапываясь» в его бизнес. На пресейле клиент хочет получить стоимость проекта, а не тщательный разбор бизнес-потребностей с возможным их пересмотром, как это обычно происходит на фазе Discovery.

Основные задачи ВА на Presale:

  • Продемонстрировать свой уровень профессионализма и знания домена, задавая правильные вопросы.
  • Натолкнуть заказчика на дополнительные идеи фразами вроде: «А какие варианты вы еще рассматривали?»
  • Показать интерес к бизнесу клиента и желание ему помочь. 

На Discovery задача немного иная. Здесь BA должен выявить проблемы, цели и реальные потребности бизнеса, выяснить, что и как хочет решить клиент с помощью будущего продукта. На основании этой информации бизнес-аналитик создает Scope and Vision документ (или подобный). Итогом всей работы и частью такого документа будет story map, в котором зафиксирован объем работ, разбитый по релизам/фазам проекта.

IAMPM

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

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

Что в этой ситуации делает опытный BA, чтобы не спугнуть клиента? Аккуратно подводит к пониманию с помощью наводящих вопросов по типу: «Ты помнишь, что ты хотел это и это? Сейчас же оказывается, что на самом деле нужно другое решение, которое вносит существенные коррективы в работу и стоимость». Обычно это помогает, если же нет, тогда идет предложение реализации проекта частями. Сначала делаем ключевое, а остальное потом. 

В Discovery, как и в любом проекте, важно правильно управлять ожиданиями клиента. Чтобы не случилось, что бизнес-аналитик собрал скоуп «на 5 лет разработки», а PM понимает, что бюджет на первый релиз ограниченн условно 35 000 $ и весь бэклог, который «нарыл» BA нужно резать, ломая при этом ожидания заказчика.  

Основные сложности на дискавери и как их решать

IAMPM

Антон Бабенко: Основная проблема любого Discovery-проекта — это отсутствие времени, потому что все нужно делать быстро. Чтобы не изобретать заново, что и в каком порядке делать, удобно разбить процесс на стандартные этапы, — и действовать по плану: 

  1. Проблемы бизнеса, которые нужно решить.
  2. Вопросы пользователей и процессов.
  3. Описание системы. 

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

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

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

В первом случае можно дальше «раскручивать» тему, чтобы понять бизнес-потребность и вместе с дизайнером предложить лучшее решение. Если же заказчик не отвечает на вопрос «Зачем?», сразу готовьтесь, что виджет придется переделывать несколько раз. 

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

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

Например, заказчику нужна booking-система. Если сразу начать с технических вопросов: какие фичи должны быть, какие пользователи, — можно упустить важное требование. В подобных ситуациях лучше использовать вопрос: Зачем вам нужна эта система, что она решает? — и узнавать у заказчика о реальных требованиях, просто расспрашивая о его бизнесе. Здесь задача BA — внимательно слушать, выстраивать логические связи и уточнять спорные моменты.

Еще одна из частых проблем — это нежелание клиента делиться информацией или непонимание, в чем роль бизнес-аналитика в принципе. Из моего опыта, в таких случаях лучше всего работает комплексный подход: на каждой встрече с заказчиком вы объясняете, что и зачем делаете, какая роль BA на проекте. Отлично, если в этом вопросе будут помогать sales и project manager.

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

Более дорогие или дешевые решения

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

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

Антон Бабенко: У меня на практике были случаи, когда приходилось настаивать на изначальном бюджете. Некоторые заказчики готовы раздуть скоуп до нереальных размеров, и приходится тормозить их, напоминая об изначальных требованиях и о том, что они и так решают свои бизнес-задачи.

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

banner

Какими навыками должен обладать BA для дискавери

Кирилл Белявский: Один из важных скилов для BA — это быстро разбираться в новом для него домене. Другие полезные навыки:

  • Развитая коммуникация: умение общаться, фасилитировать митинги, устраивать воркшопы, четко доносить свою мысль.
  • Способность фиксировать данные и результаты в диаграммах, структурировать документы (фич-листы, use кейсы, сценарии), представлять данные визуально. 
  • Навык качественной подготовки к дискавери: найти базовую информацию по проекту, изучить домен и бэкграунд клиента, сделать предположение по требованиям заказчика.
  • Умение правильно распределить свои активности, навыки тайм-менеджмента. 

Основные ошибки на фазе дискавери: 

  1. Концентрироваться только на solution, упуская из виду бизнес-потребности. 
  2. Быть уверенным, что все готовы с вами сотрудничать.
  3. Не иметь четкого понимания уровня стейкхолдеров и их влияния на проект.

Изучайте профильную литературу, найдите хорошего ментора и постарайтесь получить побольше практики. Оттачивание теории на практике под руководством опытного специалиста — это практически идеально!

Антон Бабенко: Точно могу сказать, что не нужно просто делать вид, что понял, если этого понимания нет. Лучше не побояться «выглядеть глупым» вначале — и задать уточняющие вопросы при любых сомнениях. Тогда не придется выглядеть глупо позже, уже в ходе проекта.  

Несколько советов: 

  • Не фокусируйтесь сразу на системе. Делайте акцент на целях и проблемах, которые нужно решить.
  • Не включайте «экскаватор». Не копайте на дискавери слишком глубоко, чтобы не формировать у заказчика ложных ожиданий.
  • Не нужно что-то делать без обсуждения своих действий с командой. «Лебедь, рак и щука» — не лучший пример для совместной работы.

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

Александр Кононенко

Александр Кононенко

Копирайтер-маркетолог с техническим образованием, опытом в продажах и маркетинге. Всегда в поисках лучших решений для достижения поставленных целей, и считает, что создание текстов — это симбиоз искусства и науки.