Зачем бизнесу MVP, как проверить идею продукта на рынке и избежать лишних затрат на преждевременную разработку.
20.11.2019 Обсудим, чем обычно пугает заказчиков гибкая разработка минимальной жизнеспособной версии продукта (MVP) и почему выгодно избавиться от этих страхов сегодня, чтобы разработка была осознаннее.
Страх № Неопределённый бюджет на разработку Страх №
Так никто не делает (в нашей нише, в нашем регионе и т. д.) Страх №
Это сложно, придётся напрягаться Выводы Время на прочтение: 12 мин. Читать статью на vc.ru. MVP (minimum viable product, минимально жизнеспособный продукт) - это начальная версия продукта, в которой реализована главная ценность для потребителя, но нет полного функционала и, возможно, не до конца оформлена визуальная часть. Понять это просто: запомните принцип капкейка. Перед продажей огромного торта нужно дать клиенту попробовать маленькое пирожное с той же начинкой.
Понравится - будете масштабировать и доводить до идеала, нет - сэкономите деньги и время, а по замечаниям улучшите рецепт. В разработке программного обеспечения всё то же самое. Перед созданием сложного софта есть смысл создать сначала прототип, протестировать его на реальных пользователях и только после этого «допиливать» и внедрять улучшайзинг. Боитесь продавать кекс, потому что он совсем не торт и клиент будет недовольно морщить нос? Тогда эта статья для вас.
Давайте только перенесёмся из кондитерской в опенспейс IT-компании и порассуждаем, может ли MVP стать адом для перфекциониста, какие страхи толкают заказчиков к бесконечной разработке и как с ними бороться, чтобы не было мучительно больно за бесцельно слитый бюджет.
Заказчики иногда считают, что если продукт сделан быстро и без чёткого технического задания, значит, он сделан с кривым кодом и костылями.
В таком случае неудивительно, что они хотят подстраховаться, долго готовят подробное ТЗ и избегают спешки. «Мы не для того зарабатывали репутацию двадцать лет, чтобы испортить её за три месяца»
, - так говорят крупные бренды, которые хотят цифровизации, но настороженно относятся к MVP.
Не все конечные потребители вообще поймут, что MVP содержит только часть возможного функционала. К сожалению, заказчики часто забывают, что качество сильно зависит от них самих.
Огромный риск несут в себе слабые команды (на стороне клиента), которые не хотят работать по гибкой методологии, а работают по старинке: например, делают ТЗ целый год, в мельчайших подробностях.
Мой опыт говорит, что большинство потребителей оценивают качество продукта с MVP выше, чем без него.
Обратная связь от рынка поступает быстрее (выпуск MVP занимает в среднем три месяца).
Продукт постоянно развивается, улучшается, чтобы соответствовать требованиям покупателей, которые они доносят в обратной связи.
Получается качественный и удобный софт, созданный под конкретные запросы клиентов.
В первую очередь собрать внутри вашей компании команду людей, способных принимать решения.
Они должны быть готовы к тому, что придётся жертвовать частью функционала и делать действительно капкейк, а не огромный торт.
Никакого излишнего перфекционизма, сплошная прагматика.
Команде необходимо понимать, каких функций для MVP достаточно, а от чего можно отказаться.
Если вы очень опасаетесь плохих отзывов об MVP, стоит выкатить релиз сначала на небольшую, самую лояльную аудиторию - friends & family, или несколько клиентов, с которыми будет легко договориться о пилотном запуске (в нашей практике большинство соглашается).
Пример 1: разработка страницы чекаута e-Commerce-продукта С одним из IT-продуктов приключилась такая история.
На странице чекаута было невозможно прикрутить полноценную форму оплаты, а запустить MVP нужно было срочно.
Разработчики смогли предложить четыре варианта, как обойти проблему без ухудшения качества. С онлайн-оплатой вообще интересная ситуация.
Иногда кажется, что невозможность сделать оплату без перехода на сайт банка - это большая проблема, из-за которой может теряться часть продаж.
Но мнение целевой аудитории может вас удивить: часть клиентов не доверяет такому формату и предпочитает, чтобы с сайта происходил переход на страницу банка (к ней больше доверия).
Не всегда отсутствие дополнительного функционала означает низкое качество.
Если на вашем сайте есть товар, который срочно нужен покупателю, в этом - главная ценность вашего MVP, и покупателю будут неважны прочие мелочи.
Пример 2: разработка B2B-портала IT-компания разработала MVP для B2B-портала оптового поставщика и начала собирать обратную связь от реальных пользователей - ретейлеров, которые были достаточно лояльны и согласились принять участие в тестировании. Оказалось, что дилеры выбирают товар и собирают его в партии совсем не так, как представлял себе заказчик.
Разработчики внесли изменения в MVP, и после релиза портал получил высокий NPS от пользователей (индекс потребительской лояльности). В этом кейсе и команда, и заказчик очень хорошо прочувствовали на себе, каких потерь помогает избежать MVP и насколько важно получать быструю обратную связь о продукте. Пример 3: создание ТЗ длиной в год
Департамент нашего постоянного клиента попросил сделать объём по фикспрайсу. Мол, требования понятны, функционал простой, мы сами нарисуем макеты, вы только сделайте.
Собрать ТЗ на «понятные» требования и подписать на них договор удалось только через год (!), ведь у заказчика есть работа, кроме согласования ТЗ, читать большой документ сложно и долго - пока обсуждаешь одну часть документа, забывается другая, через какое-то время нужно отредактировать уже ранее написанные части и так далее.
В итоге через два месяца разработки увольняется один из функциональных заказчиков, а «понятные и простые» требования после уточнения стали настолько сложными, что сам заказчик начал теряться в методике расчёта, которую сам же и предложил.
Бизнесу важно как можно точнее планировать бюджет, и мы как подрядчик, конечно, это понимаем.
С точки зрения планирования бюджета может показаться, что классический проектный подход выгоднее и проще, чем Agile. Подписали один документ с идеальным ТЗ на двенадцать миллионов - и ждём понятный результат. Но составить идеальное ТЗ невозможно: его просто не существует. Разработка с ТЗ и без Agile обходится дороже по следующим причинам.
В ТЗ закладывают слишком много рисков и включают ненужные фичи. При классическом проектном подходе заказчик стремится включить в ТЗ много ненужного про запас, в счёт рисков. Он думает: «Я не смогу изменить ТЗ потом, поэтому лучше заложить резерв заранее». Так проект становится действительно дорогим: в «запас» обычно идёт большое количество ненужных, непонятных фич, которые невозможно или сложно сделать. Например, заказчик требует функционал, который в реальной жизни работает не так, как в его мечтах.
Выяснится это только при тестировании продукта одним из департаментов (который не посчитали нужным привлечь к созданию ТЗ). Запуск проекта придётся отодвинуть. Долгие циклы бизнес-аналитики, согласований и уточнения бюджета гарантированы. Другая крайность - в ТЗ попадают слишком размытые формулировки, зачастую специально только для того, чтобы какой-то отдел мог снять с себя ответственность. В Agile над проектом работает фиксированная команда с фиксированной стоимостью.
С этой командой можно (и нужно) договариваться; собственно, каждый спринт начинается с договорённости о том, какая ценность в конце спринта будет поставлена клиенту. Заказчик может любой бюджет тратить определённым образом, имея свободу корректировать и изменять ценности, отказываться от ненужных фич в пользу необходимых.
Клиент генерирует правки в самый последний момент. Думаете, подробное ТЗ спасёт проект от корректировок и связанных с этим затрат? Практика показывает, что 99 % изменений клиенты требуют внести на самом последнем этапе, то есть на стадии приёмки. Представить готовый функционал заранее очень трудно, поэтому проект с абсолютно любым ТЗ будет требовать доработок. А значит, будут дополнительные циклы принятия бюджета.
Ни о какой экономии не идёт речи, и согласовывать такой контракт тоже неудобно (шлифовать функционал можно бесконечно).
Принимать проект по ТЗ крайне затруднительно. Представьте, вы тратите время на написание ТЗ и согласование его с департаментами (или это время тратят ваши сотрудники - неважно). Подрядчик оценивает этот объём и начинает работу. Далее он выдаёт объём работ большими частями, которые, соответственно, вам нужно тестировать большими кусками.
Для проекта сложной разработки пройдёт минимум четыре месяца от старта: за это время кто-то может уволиться, в бизнесе может что-то измениться, само ваше видение идеала может стать совсем другим. В итоге, спустя несколько месяцев, вам приходит запрос на тестирование всего функционала, но не факт, что вы вообще помните, как он должен работать. Принимать такие проекты - ад для заказчика. Подписывать акты страшно (вдруг чего-то не доглядели).
Не подписывать тоже плохо - пока не подписан акт на большой объём работ, заказчик может отказываться реализовывать новый функционал. Сколько уйдёт времени на тестирование даже двух месяцев работы команды разработчиков? Очень много. В Agile приняты короткие циклы (спринт длится 1-2 недели), за это время на приёмку работ у вас уходит мало времени, вы быстро даёте корректировки, и они очень быстро вводятся в эксплуатацию, где пользователи тоже начинают давать обратную связь.
Если оценивать результат через ROI (коэффициент возврата инвестиций), MVP выгоден более ранним получением прибыли. Если же продукт изначально нерентабелен или вы допустили какую-то ошибку в своих начальных гипотезах, то с MVP вы быстро это поймёте и сможете перестроиться нужным образом. Выгода будет в уменьшении потерь.
С гибкой методологией и MVP вы избавляетесь от большого количества лишних согласований. Команда работает на проекте столько, сколько понадобится; ежемесячные траты прозрачны и зависят от размера команды; вы определяете новые фичи в разработку и принимаете результат небольшими итерациями. Никто через четыре месяца не скажет вам, что разработчики сделали совсем не то, что ожидалось, и вам как менеджеру проекта не придётся нести ответственность за неточности в
ТЗ. Разработчики будут заинтересованы не «сделать функционал по списку»
, а создать полезный продукт.
Одна известная нам команда делала интернет-магазин год! Год, и на этом ещё не всё!
Проект не вышел в релиз, но уже пережил три редизайна просто потому, что клиент хочет довести проект до совершенства. А представления о совершенстве меняются регулярно (со сменой власти в компании, моды, погоды, политической обстановки...). И знаете, это не радует никого.
Потому что бесконечная разработка не выгодна ни заказчику, ни исполнителю.
Потрачены миллионы рублей, но ни одной продажи ещё не было. Неизвестно, окупится ли этот проект.
В итоге проект всё-таки запустился, но после запуска и начала содержательной работы всех департаментов над проблемами конкретных заказов (маркетинг, логистика, ДИТ) потребовалась смена концепции, а вместе с ней и дизайна, и многих технических моментов.
Методы гибкой разработки родились не вчера.
Сам термин MVP появился примерно в 2001 году, но можно сказать, что предпосылки для этого были в истории научной организации труда, бережливого производства и улучшений маленькими шагами (Toyota, 1960-е годы).
Сейчас работают с MVP многие, причём даже крупные бизнесы, которые на рынке очень давно.
В разработке программного обеспечения вы не найдёте ни одну успешную и динамичную компанию, которая работает негибкими методологиями.
Рекомендую прочитать: по теории: Дженнифер Грин, Эндрю Стеллман. «Постигая Agile. Ценности, принципы, методологии» ;
Эрик Рис. «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»
; по практике: глава из «Додо книги» на эту тему.
Что радует: гибкие методы в разработке явно становятся популярнее. 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.