Продуктовые требования и MVP

Опишите процесс формулирования продуктовых требований и выделения из них MVP. Выберите проект из своего опыта и используйте его как пример.

 

Современный подход к созданию ИТ-продуктов рассматривает создание продукта как проведение эксперимента и подразумевает, что нужно как можно быстрее дать пользователям самую базовую версию продукта, решающую их задачи — minimum viable product (MVP) — и использовать обратную связь и статистику использования продукта, чтобы проверять гипотезы, дальше развивать продукт, менять концепцию или совсем отказаться от продукта. Такой подход позволяет быстрее выходить на рынок, лучше адаптироваться к потребностям пользователей и изменениям на рынке и уменьшать стоимость эксперимента (что, в свою очередь, позволяет проводить больше экспериментов, делать более смелые эксперименты и легче отказываться от неудачных, не попадая в ловушку sunk cost fallacy).

В декабре 2013 года, компания B2B-Center, решила сделать мобильное приложение. Им занимался Антон Иванов как руководитель проекта и я как аналитик. 


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

Первый этап. Определение направления

Для формулирования продуктовых требований нужно сначала определиться с ответами на три основные вопроса:

  1. Зачем делается продукт?

  2. Для кого?

  3. Какую задачу он решает?

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

  2. Из-за специфики сайта, мы не рассматривали мобайл, как канал для привлечения новых пользователей, поэтому приложение должно было решать задачи существующих клиентов площадки. Мобильное приложение было наиболее актуально для руководителей отделов закупки (специалистам оно менее актуально, так как они весь день проводят за компьютером, который необходим для создания длинных юридических документов и использования электронной подписи; руководители же чаще бывают на встречах и им нужна возможность контролировать ход торгов из любого места) и для менеджеров отделов продажи (поставщики — это обычно менее крупные компании и у них одни и те же люди ходят на встречи с потенциальными клиентами и создают с компьютеров заявки на участие в торгах ).


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


Этот этап позволит зафиксировать направление, в котором все задействованные люди будут думать о приложении, и не позволит «прыгать» между несколькими взаимоисключающими направлениями.



Второй этап. Создание продуктовых требований

На этом этапу нужно создать пул функции, которые может иметь приложение и записать их в виде user stories.


Для этого мы использовали сессии design thinking, на которые позвали коллегу из QA и арт-директора.


У нашего design thinking были следующие этапы:

  1. Представить пользователей и увидеть мир их глазами.
Для этого мы придумали двух персонажей: начальника отдела закупок и менеджера отдела продаж. Мы представили сколько им может быть лет, как живут, с какими проблема сталкиваются, какие у них характеры, какой опыт использования программ и сайтов.


  2. Записать, с какими проблема сталкиваются пользователи. На этом этапе важно не начать придумывать решения для этих проблем.
Мы обнаружили такие проблемы, как «боится пропустить оповещение и проиграть торги», «не знает, когда закончатся торги».


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


  4. Отобрать лучшие идеи
Для каждой проблемы мы отобрали самые простые и удобные решения и записали их, как user stories в виде
«A хочет сделать B, чтобы C», например, 
«Менеджер по продажам хочет посмотреть список своих текущих торгов, чтобы будь в курсе своих торгов».

По итогам design thinking, мы придумали несколько функций, которых не было на сайте, но которые были актуальны на мобильных устройствах (например, «Поделиться ссылкой на торги через почту или SMS») и записали требования, которые подразумевались, но не были зафиксированы до этого (например, «Авторизоваться в приложении»).

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

Третий этап. Выделение MVP

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

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


Сначала мы убрали все сложно реализуемые функции (например, участие в торгах, поскольку оно требует электронную подпись) и функционал, нереализованный ещё на сайте (например, планировщик задач). От других функций было сложно отказаться. Например, нам казалось, что площадка не мыслима без каталога торгов и поиска. Мы много сомневались и обдумывали разные варианты, пока не убрали разом почти всё кроме возможности просматривать торги, в которых участвует компания. И тогда всё встало на свои места и стало понятно, что это единственный возможный вариант MVP.

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