Дискавери помогает оценить, сможет ли компания выполнить проект клиента и сколько это будет стоить. ВА на этапе дискавери выясняет бизнес-проблемы, исследует домен, выявляет требования и участвует в проектировании решения.
Как устроен процесс дискавери, какие сложности возникают чаще всего и что делать, если клиент отказывается от предварительного этапа? Спросили у двух BA Leads с опытом 14+ лет в IT.
Кирилл Белявский и Антон Бабенко, авторы и ведущие курса Badass BA, отвечают на вопросы о Discovery и роли бизнес-аналитика в нем.
Читайте ответы в статье или слушайте аудиоинтервью с Кириллом Белявским и с Антоном Бабенко в подкасте Нетехнического IT.
В IT-сфере существует, как минимум, два понятия о дискавери: продуктовое и проектное. Сразу определимся, о каком из них пойдет речь в статье:
Product Discovery — придумывание продукта либо его доработка и развитие. Здесь основной акцент на разработке гипотез, валидации, исследовании пользовательского опыта. О продуктовом дискавери говорить не будем.
Project Discovery — предварительное или дополнительное изучение проекта, которое производят до старта работ или уже в текущем проекте. IT-компания выступает в роли подрядчика (вендора) для заказчика на аутсорсе. Именно о Project Discovery и пойдет речь дальше.
О целях дискавери и уровне бизнес-аналитика
Discovery — это фаза анализа и дизайна, когда выявляют бизнес-требования и подготавливают клиенту видение его проекта. Для аутсорс-компании, дискавери — это один из этапов продажи услуг по разработке решения заказчику.
Клиенты часто приходят с документами, которые содержат минимум информации о том, что они хотят и зачем. Дискавери помогает понять, что на самом деле нужно бизнесу, и насколько настоящие цели отличаются от желаний клиента. Для ВА важно найти компромисс между реальными бизнес-потребностями и «хочу» заказчика.
Всегда ли нужна дискавери фаза?
Если к вам заходит проект со сложной структурой и бизнес-логикой, который предполагает множество интеграций, — однозначно необходимо проводить дискавери. Если же поступил запрос на какое-то шаблонное решение, которое IT-компания уже выполняла раньше, то возможно, получится обойтись нулевым спринтом. Домены тоже влияют на необходимость Discovery. В нишах, где постоянно меняется законодательство или требования к программному обеспечению, без дискавери-фазы никак.
Цель 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, в котором зафиксирован объем работ, разбитый по релизам/фазам проекта.
Дискавери — это логичное продолжение пресейла, поэтому бизнес-аналитику важно держаться в рамках начальных договоренностей. Сильные расхождения между тем, что было сказано на Presales и после Discovery-проекта, могут запутать или испугать клиента.
Допустим, заказчику нужен модуль календаря. На пресейле был разговор, что нужно простое решение: условно с тремя кнопками. После дискавери выяснилось, что понадобится многофункциональная система, поэтому стоимость решения серьезно увеличивается.
Что в этой ситуации делает опытный BA, чтобы не спугнуть клиента? Аккуратно подводит к пониманию с помощью наводящих вопросов по типу: «Ты помнишь, что ты хотел это и это? Сейчас же оказывается, что на самом деле нужно другое решение, которое вносит существенные коррективы в работу и стоимость». Обычно это помогает, если же нет, тогда идет предложение реализации проекта частями. Сначала делаем ключевое, а остальное потом.
В Discovery, как и в любом проекте, важно правильно управлять ожиданиями клиента. Чтобы не случилось, что бизнес-аналитик собрал скоуп «на 5 лет разработки», а PM понимает, что бюджет на первый релиз ограниченн условно 35 000 $ и весь бэклог, который «нарыл» BA нужно резать, ломая при этом ожидания заказчика.
Основные сложности на дискавери и как их решать
Антон Бабенко: Основная проблема любого Discovery-проекта — это отсутствие времени, потому что все нужно делать быстро. Чтобы не изобретать заново, что и в каком порядке делать, удобно разбить процесс на стандартные этапы, — и действовать по плану:
- Проблемы бизнеса, которые нужно решить.
- Вопросы пользователей и процессов.
- Описание системы.
Когда бизнес-аналитик понимает, что и в какой день он делает, это помогает уложиться в сроки. Даже, если что-то идет не по плану, всегда есть примерная карта действий, — и процесс движется гораздо быстрее, чем без «домашних заготовок».
Кроме отсутствия времени, заказчик часто не хочет/не может ответить на вопросы о своем бизнесе, рассказать, как работают стейкхолдеры или пользователи.
Например, поступает запрос на разработку виджета: заказчик говорит, что ему нужно вывести на экран какую-то информацию. Хороший бизнес-аналитик всегда спросит, зачем, для какой цели это нужно. Клиент или объясняет или … уходит от ответа.
В первом случае можно дальше «раскручивать» тему, чтобы понять бизнес-потребность и вместе с дизайнером предложить лучшее решение. Если же заказчик не отвечает на вопрос «Зачем?», сразу готовьтесь, что виджет придется переделывать несколько раз.
Кирилл Белявский: Клиент не всегда может правильно описать задачу, которую хочет решить. Когда заказчики приходят и говорят, что им нужна такая-то система, важно помнить, что предложенное ими решение может не охватывать всех нюансов, и тут ВА должен думать в категориях бизнеса, а не solution.
Всегда начинаем с исследования бизнеса: основные понятия, потребности, модель, как все работает. Затем переходим к предложенной клиентом системе. Изучаем, подходит она бизнесу или нет. Дальше набираем кейсы по приложениям, ролям, взаимодействию между разными элементами системы, интеграциям и так постепенно приходим к выбору технологии.
Например, заказчику нужна booking-система. Если сразу начать с технических вопросов: какие фичи должны быть, какие пользователи, — можно упустить важное требование. В подобных ситуациях лучше использовать вопрос: Зачем вам нужна эта система, что она решает? — и узнавать у заказчика о реальных требованиях, просто расспрашивая о его бизнесе. Здесь задача BA — внимательно слушать, выстраивать логические связи и уточнять спорные моменты.
Еще одна из частых проблем — это нежелание клиента делиться информацией или непонимание, в чем роль бизнес-аналитика в принципе. Из моего опыта, в таких случаях лучше всего работает комплексный подход: на каждой встрече с заказчиком вы объясняете, что и зачем делаете, какая роль BA на проекте. Отлично, если в этом вопросе будут помогать sales и project manager.
Часто бывает так, что бизнес-аналитик начинает Discovery с мыслью, что на стороне клиента все готовы с ним сотрудничать. Это далеко не всегда бывает правдой. Не все стейкхолдеры поддерживают проект и готовы отвечать на вопросы.
Более дорогие или дешевые решения
Кирилл Белявский: При оценке любого проекты мы учитываем ограничения клиента: бюджет, сроки, ограничения вне сферы влияния клиента (к примеру, проект ранее разрабатывался на какой-то специфической технологии и просто физически нет возможности уйти на другое решение). Еще бывают так называемые «политические ограничения», когда менеджмент компании не доверяет новым технологиям по каким-то своим причинам, обоснованным или не очень.
В любом случае, мы предлагаем заказчику лучшее решение, которое может быть, в том числе, и дороже изначального бюджета клиента. Его право согласиться или отказаться от этого.
Антон Бабенко: У меня на практике были случаи, когда приходилось настаивать на изначальном бюджете. Некоторые заказчики готовы раздуть скоуп до нереальных размеров, и приходится тормозить их, напоминая об изначальных требованиях и о том, что они и так решают свои бизнес-задачи.
Еще интересней задача, когда приходится находить компромисс между разными стейкхолдерами. Единственный выход здесь — заставить их говорить друг с другом, чтобы они обсудили между собой, чего хотят и как видят движение дальше. Тогда есть вероятность конструктивного диалога.
Какими навыками должен обладать BA для дискавери
Кирилл Белявский: Один из важных скилов для BA — это быстро разбираться в новом для него домене. Другие полезные навыки:
- Развитая коммуникация: умение общаться, фасилитировать митинги, устраивать воркшопы, четко доносить свою мысль.
- Способность фиксировать данные и результаты в диаграммах, структурировать документы (фич-листы, use кейсы, сценарии), представлять данные визуально.
- Навык качественной подготовки к дискавери: найти базовую информацию по проекту, изучить домен и бэкграунд клиента, сделать предположение по требованиям заказчика.
- Умение правильно распределить свои активности, навыки тайм-менеджмента.
Основные ошибки на фазе дискавери:
- Концентрироваться только на solution, упуская из виду бизнес-потребности.
- Быть уверенным, что все готовы с вами сотрудничать.
- Не иметь четкого понимания уровня стейкхолдеров и их влияния на проект.
Изучайте профильную литературу, найдите хорошего ментора и постарайтесь получить побольше практики. Оттачивание теории на практике под руководством опытного специалиста — это практически идеально!
Антон Бабенко: Точно могу сказать, что не нужно просто делать вид, что понял, если этого понимания нет. Лучше не побояться «выглядеть глупым» вначале — и задать уточняющие вопросы при любых сомнениях. Тогда не придется выглядеть глупо позже, уже в ходе проекта.
Несколько советов:
- Не фокусируйтесь сразу на системе. Делайте акцент на целях и проблемах, которые нужно решить.
- Не включайте «экскаватор». Не копайте на дискавери слишком глубоко, чтобы не формировать у заказчика ложных ожиданий.
- Не нужно что-то делать без обсуждения своих действий с командой. «Лебедь, рак и щука» — не лучший пример для совместной работы.
Не бойтесь учиться и применять что-то новое. Всегда интересно узнать мнение других специалистов, у них наверняка есть множество кейсов, которые могут дать полезную информацию для изучения и использования в своей практике. Всегда нужно учиться, развиваться и стремиться понять бизнес. Мы ведь бизнес-аналитики.