Как PM’у запланировать и провести Discovery-проект

Статья написана в соавторстве с Мэри Ротарь, CEO IAMPM.

За более чем 17 лет работы в аутсорсинге разработки ПО я неоднократно сталкивался с ситуациями, когда требования к проекту настолько неясны, что сделать оценку, а тем более спланировать и запустить проект, просто не представляется возможным. Стандартным решением для таких ситуаций будет проведение Discovery, в ходе которого компания-аутсорсер активно работает с клиентом, детализируя требования, разрабатывая видение архитектуры и составляя предварительный план проекта.
В данной статье рассмотрены основные аспекты организации Discovery с точки зрения менеджера проектов.

Начнем с того, зачем и когда нужна фаза Discovery.

«Давайте проведем Discovery перед тем, как брать проект в разработку? Много непонятных моментов». Часто такую фразу можно услышать от проектных менеджеров, бизнес-аналитиков и инженеров, когда приходит запрос на новый проект. Особенно когда этот проект большой, а уровень детализации требований — низкий.

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

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

В статье сделан акцент на те особенности Discovery-проекта, которые важны для менеджера, отвечающего за его проведение. Именно поэтому мы не углубляемся в анализ требований, проработку архитектуры или UI/UX — это темы отдельных специализированных материалов.

Когда нужен Discovery-проект

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

Для лучшего понимания бизнес-требований — когда скоуп недостаточно ясен, а при этом клиент требует:
- дать оценку на проект;
- «подписаться» на fixed-price;
- начать работу поскорее, чтобы успеть к дедлайну.
Для проработки технической стороны решения. Тот случай, когда скоуп понятен, но неизвестно, что уже есть у клиента в плане используемых систем и инфраструктуры. Одно дело — разработать проект с нуля, другое — доработать существующий, попутно интегрируя внешние системы. К примеру, у клиента есть система обработки заказов, которой уже 10 лет. При этом бизнес требует существенно доработать функциональность, а также повышает требования к производительности, ведь количество пользователей растет. Здесь нужно дополнительное исследование. Дискавери-фаза поможет определить: имеют ли смысл доработки, сколько они могут стоить, как много времени займут. На практике были примеры, когда клиенты просто хотели понимать, могут ли они дальше эксплуатировать свою систему или проще переписать её с нуля.
Для детализации уже проработанных требований до уровня, который позволит команде инженеров начать разработку: то есть для получения бэклога на уровне пользовательских историй и более детальном.

Соответственно, мы видим три разные ситуации, в которых необходима Discovery-фаза, что приводит нас к трем типам Discovery-проектов.

Типы Discovery-проектов

Discovery. Происходит на этапе пресейла, когда проект еще не взят в работу. Акцент на анализе, оценке, планировании проекта и подготовке технико-коммерческого предложения (proposal) клиенту. По результатам этого типа возможен вариант, что клиент откажется от проекта вообще (так как полученные сроки и стоимость его не удовлетворят) или решит сравнить вашу оценку с оценками других подрядчиков.
Inception. Проводят в качестве подготовительной фазы перед началом работы над текущим проектом. Основная цель — детализировать требования, особенно на первые итерации, чтобы на старте у команды не было задержек. В результате этого исследования вы вместе с командой должны создать детальный бэклог на несколько первых спринтов проекта, хотя бы базово определиться с архитектурой и утвердить расписание работ. Inception, как правило, не является отдельным проектом (в отличие от первого и третьего типов), а представляет собой первую фазу основного проекта.
Assessment/Audit. Это исследование (аудит) существующей системы (или систем) с целью понять, соответствуют ли она текущим бизнес-требованиям клиента. И если нет, то что с этим можно сделать. В результате клиент получает документ с анализом и рекомендациями по дальнейшим действиям (audit report): оставить систему как есть, дорабатывать или думать над альтернативой, например, о покупке готового продукта или разработке новой версии с нуля. Тут также важно понимать, что основной проект после Assessment необязательно начнется — причины те же, что и в случае Discovery.

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

Результаты Discovery-проекта

Конечная цель любого Discovery — это составление реалистичного коммерческого предложения (proposal) и подписание договора (при условии, что клиент выбрал вас и что что ваша компания готова работать над проектом). Для этого в самом Discovery-проекте необходимо получить следующие результаты/артефакты:

Документы требований, отвечающие на вопрос «что нужно сделать в проекте». Начинать работу над требованиями лучше с создания документа под названием Project Vision. В нем описывают бизнес-цели (зачем нужен проект), скоуп (что именно будем делать) и ограничения (например, несдвигаемый дедлайн вроде выставки или старта сезона продаж, допустимый бюджет, ключевые требования стандартов и так далее). Следующий шаг — подготовка бэклога, который в зависимости от размера проекта может быть проработан на уровне эпиков, пользовательских историй или критериев приемки (реже).
Документы архитектуры, описывающие, как будет реализовано решение с технической точки зрения. Здесь важно определить структуру будущей системы, выбрать технологию для ее построения и проработать способы интеграции со сторонними системами. Пакет документов должен также включать расчет стоимости сторонних компонентов, которые вы планируете закупить.
Создать базовое представление UI/UX — как будет выглядеть приложение. В этом блоке задач во время Discovery важно сделать список/схему основных экранов. Достаточно будет высокоуровневой структуры. Также нужно нарисовать 2–3 экрана, типичных для проекта, чтобы фронтенд-разработчики смогли оценить сложность интерфейса.
Разработать артефакты управления проектом. Здесь необходимо получить оценку бэклога, расписание работ составом будущей команды, плюс стоимость проекта для клиента. Все цифры должны сопровождаться описанием предположений (assumptions) и рисков, а также стратегией реагирования на них. В дальнейшем эти артефакты станут основой коммерческого предложения и помогут в управлении проектом уже на этапе реализации.

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

Не менее важным этапом Discovery-проекта будет презентация его результатов. Большинство артефактов необходимо прорабатывать в итеративном режиме, то есть показывать клиенту промежуточные результаты, получать фидбэк, готовить новую версию с его учетом и так далее. Таким образом к окончанию Discovery большинство документов будут уже знакомы клиенту и согласованы с ним. Особенно это касается документов, описывающих требования и архитектуру.

На финальной встрече проекта необходимо уделить внимание предлагаемому расписанию проекта, его срокам, а также тому, как результаты проекта распределены во времени: что клиент получит через месяц, через два, через полгода. Требований и архитектуры на финальной встрече можно касаться поверхностно, отметив лишь ключевые моменты (ведь вы показывали их ранее).

ВАЖНО! Разговор о бюджете на дальнейшие работы по проекту стоит либо перенести в конец презентации, либо же вовсе вынести на отдельную встречу с клиентом.

Основные активности на Discovery-проекте

Основные активности в рамках Discovery-проекта можно разделить на пять потоков: коммуникация, анализ требований, архитектура, UI/UX, оценка и планирование.

Коммуникация

В рамках этого блока наиболее важны две встречи с клиентом: установочная встреча на старте Discovery-проекта (Kick-Off) и презентация proposal-документа, завершающая проект.

Встречу по презентации результатов Discovery мы обсудили в предыдущем разделе, здесь же остановимся на Kick-Off.

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

К Kick-Off-встрече стоит хорошо подготовиться: составить план, продумать роли, провести репетицию представлений и так далее.

Помимо Kick-Off и презентации proposal, на плечи команды ложатся интервью стейкхолдеров, показ результатов работы (черновики документов требований, архитектура и так далее) вместе со сбором фидбэка и его обработкой.

Как и на любом другом типе проекта, в задачи PМ’а входит мониторинг прогресса, предоставление отчетности клиенту и координация действий команды и клиента, чтобы покрыть все цели, намеченные на Discovery.

Анализ требований

Cбор и анализ требований происходят на протяжении всего Discovery-проекта вплоть до составления proposal, однако акцент этой деятельности несколько меняется.

В начале дискавери бОльшая часть усилий направлена на интервью со стейкхолдерами (представителями бизнеса, пользователями, техническим персоналом). Здесь мы больше слушаем, задаем клиенту вопросы, уточняем детали.

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

Если говорить о типах документов требований, здесь акцент тоже смещается:

В начале проекта команда занята формированием Project Vision на основе высокоуровневых требований, а значит, пониманием общего контекста и бизнес-целей.
Ближе к середине и окончанию проекта — документированием и согласованием детальных требований: в формате бэклога, SRS или любом другом, принятом в конкретной компании.

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

В любом проекте важно найти баланс между требуемой точностью оценки (а значит и детализацией требований) и длительностью/стоимостью дискавери.

Архитектура

В задачи архитектора в рамках Discovery-проекта входят:

Сбор требований, которые значимы для архитектуры будущего проекта: производительность, надежность, технические ограничения, интегрируемые системы и так далее. Сюда же относится проработка стандартов безопасности, обработки и хранения персональных данных. Особенно это актуально на проектах в сферах, которые сильно зарегулированы: медицинских, финансовых, системах управления движением.
Анализ технической документации и информации от клиента: где хостить, какая IТ-инфраструктура уже есть и так далее. Обычно производится параллельно со сбором требований.
Дизайн и документирование архитектуры, выбор технологического стека.

К перечисленному иногда добавляют разработку архитектурных прототипов. Это может быть оправданным решением, когда есть сомнения в выборе той или иной модели архитектуры, технологии разработки 3rd-party-компонентов.

UI/UX

В этом блоке присутствуют уже традиционный сбор требований и анализ документов на начальном этапе. Затем разрабатывают Site Map, схему основных экранов. В целом же проработка UI/UX в фазе дискавери не всегда релевантна. Если у вас на Discovery-проект отводится неделя-две, то дизайнер вряд ли сможет вам что-то предложить из-за нехватки времени. Единственное, что для оценки проекта все же стоит набросать хотя бы примерно требования, чтобы фронтенд-команда могла получить представление о сложности интерфейса. Если у вас на Discovery-проект отводится неделя-две, то дизайнер вряд ли сможет вам что-то предложить из-за нехватки времени.

Оценка и планирование

Этот блок, бесспорно, — основная задача PM’а.

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

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

Результаты дискавери-проекта оформляются в пакет документов, основным из которых является коммерческое предложение (proposal). Типичная структура этого документа представлена на рисунке ниже.

Команда Discovery-проекта

Для полноценной проработки дискавери в нем должна участвовать команда, состоящая из опытного PМ’а, бизнес-аналитика, архитектора, разработчиков, UI/UX-консультанта.

PM, как правило, присутствует с первого до последнего дня Discovery, так как он ведет коммуникацию с клиентом, составляет proposal. Бизнес-аналитик необходим для изучения требований и подготовки документации и потому тоже обычно присутствует на проекте с первого до последнего дня.

Разработчиков чаще всего привлекают на этапе оценивания, а также для создания прототипов. Архитектор и UI/UX специалист участвуют в Discovery по необходимости.

Роль менеджера проектов на Discovery двойственна: с одной стороны, он, как специалист по управлению проектами, занимается всем, что относится к составлению плана «основного» проекта и подготовкой документации. С другой — координирует сам Discovery-проект, фасилитирует основные встречи, управляет командой Discovery.

Биллинг

Вы же помните, что Discovery-проект — это такой же проект, но только меньше? Так что для него актуальны те же модели продажи, но чаще всего используют следующие две: Fixed Price и Time and Materials.

При продаже Discovery-проекта также стоит учитывать следующие моменты:

Обычно он имеет четкие временные рамки.
Перед стартом Discovery часто берут предоплату. Причина в том, что после дискавери ваш клиент получает документы с ценной информацией, а в итоге может пойти к другому вендору для получения альтернативной оценки. С учетом реалий рынка логично обезопасить себя от возможной неуплаты за услуги. В особенности это касается ситуаций, когда ваш клиент — стартап с непонятным объемом финансирования и отсутствием кредитной истории.
Discovery-проекты обычно низкомаржинальные, поэтому их следует рассматривать в качестве средства для того, чтобы начать работу с клиентом, завоевать доверие и сформировать адекватные ожидания на проект по разработке. Исключение, если ваша компания занимается только консалтингом и аудитом технических решений и у вас есть отдельные высокомаржинальные рейты специально для дискавери-проектов.

Как рассчитать цену дискавери проекта для клиента? С математической точки зрения правильно будет использовать формулу:

вовлеченность специалистов (часов в день) * длительность проекта * рейт = цена

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

Как «продать» Discovery клиенту

Для продажи Discovery клиенту можно сказать, что в случае покупки он:

Получит более точную оценку будущего проекта, а значит, лучше сможет спланировать свой бюджет и временные рамки.
Сможет использовать результаты Discovery для сравнения разных вендоров, что позволит ему выбрать оптимальное предложение по соотношению цена/качество.
Сможет увидеть, как его проект будет выглядеть. Особенно хорошо этот аргумент работает, когда в Discovery-проект включена проработка UI/UX.
Сэкономит деньги в будущем за счет выбора правильной технологии разработки его проекта. Можно привести много примеров, когда первичный бизнес-анализ был выполнен неверно, что в итоге, приводило к перерасходу бюджета.

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

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

Еще есть вариант предложить «чистый» Time and Materials проект без каких-либо обязательств со стороны вендора. В этом случае обязательно предупредите клиента о рисках такого решения.