PoC, MVP, CustDev: три способа не инвестировать в провал

PoC, MVP, CustDev: три способа не инвестировать в провал

Автор статьи
Елена Руденец

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

За 10 лет работы мы реализовали более 200 IT-проектов, в том числе выпустили на рынок несколько собственных продуктов. Новые идеи мы проверяем на ранней стадии, используя для этого три разных способа: MVP, PoC и CustDev. В этой первой, обзорной статье мы рассказываем о Discovery-фазе, которая служит для MVP, PoC и CustDev отправной точкой, а также делимся собственным опытом того, как именно каждый из этих способов снижает риск провала проекта.

  1. Что такое Discovery-фаза IT-проекта?
  2. Почему IT-проекту нужна Discovery-фаза?
  3. Что включает в себя Discovery-фаза?
  4. Discovery-фаза: опыт Umbrella IT
    4.1. Proof of Concept (PoC)
    4.2. Minimum Viable Product (MVP)
    4.3. CustDev и UX-дизайн
  5. Итоги

1. Что такое Discovery-фаза IT-проекта

Discovery-фаза — это этап, предваряющий разработку, который помогает ответить на стоящие перед стейкхолдерами вопросы и максимально снизить неопределенность на старте проекта: 

  • зафиксировать скоуп, который будет реализован в текущем проекте;
  • получить приближенную к реальности оценку сроков и стоимости разработки.

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

2. Почему IT-проекту нужна Discovery-фаза

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

Так произошло с приложением Everest, которое задумывалось как технологичная платформа, помогающая пользователям идти к мечте: ставить цель, прописывать шаги к ее достижению, получать поддержку и вдохновение от друзей и единомышленников. Идея сразу нашла отклик у аудитории и привлекла инвестиции в $2,2 млн. Однако реализация проекта заняла гораздо больше запланированных 4-6 месяцев. В процессе разработки не раз принималось решение добавить новые функции вместо того, чтобы сосредоточиться на основных. Например, много ресурсов было потрачено на оффлайн-синхронизацию – неприоритетную функцию, без которой вполне могла обойтись первая версия приложения. Когда наступил долгожданный релиз, приложение оказалось медленным, периодически сбоило, а юзабилити оставляло желать лучшего. Поддерживать приложение было дорого, на проекте накопился технический долг, бюджет истощился. Уже через 2 года после запуска проект был закрыт.

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

3. Что включает в себя Discovery-фаза

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

3.1. Постановка бизнес-целей

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

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

3.2. Исследование рынка

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

На этом этапе прорабатывается user story – пошаговый путь взаимодействия потенциального клиента с вашим сайтом или приложением. Это помогает проследить, все ли потребности ЦА решаются в текущей модели системы, а также отсечь функционал, который не решает важных для пользователя задач. В дальнейшем user story используется дизайнерами для разработки прототипа UX будущего продукта.

3.3. Поиск “узких мест” и первичная проработка спецификаций

Это наиболее важная часть Discovery, без которой мы не рекомендуем приступать к разработке. Здесь фиксируются функциональные требования к сайту/приложению, которые необходимы и достаточны для создания минимально жизнеспособного продукта (MVP).

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

Если возникают сомнения, то самый сложный или инновационный функционал рекомендуется проверить до старта проекта. Для этого существует отдельный инструмент – Proof of Concept, его мы коснемся позже.

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

  • ограничения по инструментам и стратегиям разработки;
  • правила выполнения определенных бизнес-процессов в компании или стране;
  • взаимодействие с внешними интерфейсами – например, требования к API продукта или системы;
  • юридические требования.

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

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

4. Discovery-фаза: опыт Umbrella IT

Discovery-фаза в классическом виде позволяет очертить потенциал продукта, определить факторы, которые могут помешать запуску проекта, а также определиться с выбором дополнительных этапов проверки идеи – таких как MVP, PoC и CustDev. Каждый из них включает в себя элементы Discovery, однако выходит за рамки только аналитики, потому что итоговый результат этих этапов шире и затрагивает область разработки или подготовки к ней.

Расскажите нам о своем проекте и узнайте, какой способ подойдет в вашем случае:

4.1. Proof of Concept (PoC)

Если Discovery лишь подсвечивает “узкие места” на проекте, то проверка концепции (англ. Proof of concept) дает однозначный ответ на вопросы о практической осуществимости какого-либо метода, идеи, технологии: будет ли продукт работоспособен? насколько сложной и дорогостоящей будет реализация?

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

Проверку концепции часто путают с MVP (разработкой минимально жизнеспособного продукта), принимая PoC за некий “черновик” проекта, который можно немного доделать и выпустить в продакшн. В реальности PoC – это исследование, которое касается лишь небольшой части будущего продукта, а не всей системы. Оно показывает, какие у идеи есть ограничения с точки зрения технологий и можно ли их обойти.

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

В Umbrella IT проверка концепции занимает 1 месяц. За этот срок мы определяем инновационный функционал, формируем список сценариев его использования, разрабатываем и тестируем PoC. По итогу работ наши клиенты получают техническое доказательство идеи, заключение с указанием выявленных ограничений и рекомендаций по дальнейшей разработке.

4.2. Minimum Viable Product (MVP)

Если PoC нужен, чтобы подтвердить возможность технической реализации идеи, то минимально жизнеспособный продукт (MVP) – чтобы проверить, будет ли она востребована у конечных пользователей.

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

Разработка MVP занимает в Umbrella IT 1,5 месяца. За это время мы выделяем основной функционал, сортируем его по приоритетности, составляем функциональную карту и подготавливаем прототипы будущего продукта. После этого приступаем к разработке MVP. В результате вы получаете работающий продукт в рамках заранее известного бюджета.

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

4.3. CustDev и UX-дизайн

Еще одна эффективная методология, которая помогает создать продукт, востребованный у целевой аудитории – Customer Development, или CustDev. Помните, как на этапе Discovery мы собирали информацию о продукте, прорабатывали user story, чтобы создать прототип UX, отвечающий потребностям потенциальных клиентов? На этапе CustDev мы глубже анализируем потребности ЦА и тестируем прототипы продукта на реальных пользователях еще до того, как продукт будет разработан.

Совместно с заказчиком мы согласуем портреты ЦА и детализируем клиентские пути, отрисовываем макет интерфейса и на его основе проводим тестирование продукта на фокус-группе. В подборе участников для фокус-группы нам помогает партнер – UX-лаборатория ВШЭ. После каждой итерации вносим изменения в прототипы и снова тестируем их. Заказчик получает детально проработанные макеты сайта/приложения, которые можно сразу отдавать в работу проектной команде.

Главный результат – возможность создать именно тот продукт, который будет нужен конечному потребителю и не тратить ресурсы вашей компании впустую. Практика показывает, что CustDev на этапе предевелопмента экономит до 70% бюджета.

Возможно, по итогам одного из этапов предевелопмента вы обнаружите, что идея не реализуема, не имеет спроса или потребует выйти за рамки бюджета – но и такой исход будет выгоднее, чем силы и средства, вложенные в заведомо убыточный проект, особенно когда речь идет о дорогостоящей разработке IT-продуктов.

5. Итоги

Discovery-фаза, PoC, MVP и CustDev – дополнительные и необязательные этапы разработки IT-продукта. Однако когда эти процессы становятся обычной практикой при работе над новым продуктом, выигрывают все: бизнес ускоряется, опережая конкурентов и увеличивая прибыль, а новые пользователи закрывают свои потребности с помощью продукта, который точно отвечает их требованиям.

Специалисты Umbrella IT готовы помочь вам проверить новую идею и снизить риски, связанные с разработкой и дальнейшей поддержкой продукта: