MVP, или как не попасть в бесконечную разработку

MVP (minimum viable product, минимально жизнеспособный продукт) — это начальная версия продукта, в которой реализована главная ценность для потребителя, но нет полного функционала и, возможно, не до конца оформлена визуальная часть. Понять это просто: запомните принцип капкейка.

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

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

Боитесь продавать кекс, потому что он совсем не торт и клиент будет недовольно морщить нос? Тогда эта статья для вас. Давайте только перенесёмся из кондитерской в опенспейс IT-компании и порассуждаем, может ли MVP стать адом для перфекциониста, какие страхи толкают заказчиков к бесконечной разработке и как с ними бороться, чтобы не было мучительно больно за бесцельно слитый бюджет.

Понятие MVP тесно связано с философией Agile. Заказчики иногда считают, что если продукт сделан быстро и без чёткого технического задания, значит, он сделан с кривым кодом и костылями. В таком случае неудивительно, что они хотят подстраховаться, долго готовят подробное ТЗ и избегают спешки.

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

Страх оправдан или нет?

Моё мнение — нет! Не все конечные потребители вообще поймут, что MVP содержит только часть возможного функционала.

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

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

Обратная связь от рынка поступает быстрее (выпуск MVP занимает в среднем три месяца).

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

Как бороться?

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

Пример 1: разработка страницы чекаута e-Commerce-продукта

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

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

Пример 2: разработка B2B-портала

IT-компания разработала MVP для B2B-портала оптового поставщика и начала собирать обратную связь от реальных пользователей — ретейлеров, которые были достаточно лояльны и согласились принять участие в тестировании. Оказалось, что дилеры выбирают товар и собирают его в партии совсем не так, как представлял себе заказчик. Разработчики внесли изменения в MVP, и после релиза портал получил высокий NPS от пользователей (индекс потребительской лояльности). В этом кейсе и команда, и заказчик очень хорошо прочувствовали на себе, каких потерь помогает избежать MVP и насколько важно получать быструю обратную связь о продукте.

Пример 3: создание ТЗ длиной в год

Департамент нашего постоянного клиента попросил сделать объём по фикспрайсу. Мол, требования понятны, функционал простой, мы сами нарисуем макеты, вы только сделайте. Собрать ТЗ на «понятные» требования и подписать на них договор удалось только через год (!), ведь у заказчика есть работа, кроме согласования ТЗ, читать большой документ сложно и долго — пока обсуждаешь одну часть документа, забывается другая, через какое-то время нужно отредактировать уже ранее написанные части и так далее.

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

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

Страх оправдан или нет?

С точки зрения планирования бюджета может показаться, что классический проектный подход выгоднее и проще, чем Agile. Подписали один документ с идеальным ТЗ на двенадцать миллионов — и ждём понятный результат. Но составить идеальное ТЗ невозможно: его просто не существует.

Как бороться?

С гибкой методологией и MVP вы избавляетесь от большого количества лишних согласований. Команда работает на проекте столько, сколько понадобится; ежемесячные траты прозрачны и зависят от размера команды; вы определяете новые фичи в разработку и принимаете результат небольшими итерациями. Никто через четыре месяца не скажет вам, что разработчики сделали совсем не то, что ожидалось, и вам как менеджеру проекта не придётся нести ответственность за неточности в ТЗ. Разработчики будут заинтересованы не «сделать функционал по списку», а создать полезный продукт.

Пример: к каким убыткам приводит неоправданный перфекционизм

Одна известная нам команда делала интернет-магазин год! Год, и на этом ещё не всё! Проект не вышел в релиз, но уже пережил три редизайна просто потому, что клиент хочет довести проект до совершенства. А представления о совершенстве меняются регулярно (со сменой власти в компании, моды, погоды, политической обстановки...). И знаете, это не радует никого. Потому что бесконечная разработка не выгодна ни заказчику, ни исполнителю.

Потрачены миллионы рублей, но ни одной продажи ещё не было. Неизвестно, окупится ли этот проект. При разработке с MVP уже через три месяца была бы видна реакция рынка.

В итоге проект всё-таки запустился, но после запуска и начала содержательной работы всех департаментов над проблемами конкретных заказов (маркетинг, логистика, ДИТ) потребовалась смена концепции, а вместе с ней и дизайна, и многих технических моментов.

Страх оправдан или нет?

Методы гибкой разработки родились не вчера. Сам термин MVP появился примерно в 2001 году, но можно сказать, что предпосылки для этого были в истории научной организации труда, бережливого производства и улучшений маленькими шагами (Toyota, 1960-е годы). Сейчас работают с MVP многие, причём даже крупные бизнесы, которые на рынке очень давно. Яркие представители: «Додо Пицца», Dropbox, Uber, Airbnb, «Яндекс».

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

Как бороться?

Познакомьтесь с MVP поближе.

Рекомендую прочитать:

Пример: разнообразие проектов с MVP

Что радует: гибкие методы в разработке явно становятся популярнее.

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

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

Вторая сторона этого страха — «так делают только стартапы»

Страх оправдан или нет?

Клиент может думать: «Стартапы работают в условиях неопределённости, поэтому им нужен MVP. А я в своём бизнесе много лет и точно знаю, чего хочу от разработчиков. Мне нужен очень простой софт. Здесь должна быть такая кнопка, а это поле должно быть таким. Зачем мне MVP?» Здесь простота — это иллюзия.

Не только стартап, но и крупный бизнес — с 10-, 20-летним опытом работы и более — при разработке программного обеспечения всегда встречается с неопределённостью.

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

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

Простой пример: заказчик думает, что форма утверждения сырья на склад очень простая, ведь его сотрудники делают это вручную каждый день. Но при автоматизации выясняется то, на что взгляд был «замылен», — оказывается, по номеру исходной накладной исполнитель должен понять номер партии, и ввод количества сырья будет запрашиваться на основе тех знаний, которые в разработке софта не учитывались и никак не оцифровывались. Заказчик был уверен, что задача простая и определённая!

Как бороться?

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

Оценить потери времени в денежном эквиваленте за год.

Пример: иллюзия ясности

Небольшая компания, ориентированная на B2B-клиентов, заказала софт для внутреннего использования по негибким методологиям. Казалось бы, простой продукт для малого количества пользователей. Компания на рынке давно, опыт в ведении дел у всех сотрудников — более 10 лет.

Согласование договора заняло год.

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

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

Страх оправдан или нет?

Перед каждым спринтом нужно принимать управленческое решение о том, что важно для реализации на следующий спринт (обычно в разработке спринт занимает 1–2 недели, а в машиностроении — 2–3 месяца, главное — ритмичность!). Это тяжело в том случае, если в вашей компании нет сильного менеджера, лидера, который может чётко ставить цели на следующие две недели. Или когда в компании слишком много лиц, принимающих решение, и они не могут договориться.

Как бороться?

Прокачать своих управленцев. Изучить методы INVEST (или SMART) и Impact Mapping: это метод описания задач, который позволяет максимально глубоко продумать задачу со стороны пользовательской ценности, и методика, согласно которой конкретная задача ложится на улучшение конкретных показателей.

В серьёзных IT-компаниях, кроме разработчиков, есть ещё проектный менеджер, который владеет методами INVEST и Impact Mapping и помогает заказчику прийти к нужным формулировкам (но, конечно, не без участия менеджмента со стороны клиента).

Пример: как MVP решает проблему мучительных согласований

Без долгих согласований можно запустить пробную версию и дополнять, улучшать её в каждом спринте. Принимать решения об улучшениях маленькими шагами нелегко, но обычно это проще, чем согласовать сразу крупный проект! Соседние департаменты теперь не винят друг друга в том, что кто-то что-то не учёл, а содержательно обсуждают план действий на следующие две недели.

Итак, резюмирую: MVP — это средство контакта с реальностью, которое помогает быстрее получить обратную связь и подстроиться под требования пользователей системы.

Гибкие методологии выгодны всем (и заказчику, и подрядчику, и конечному пользователю), они повышают осознанность управления бизнесом.

Надеюсь, эта статья хоть немного развеяла страхи, окружающие MVP :) Буду рада получить обратную связь в комментариях.