MVP, or how not to get into endless development

Читать статью на vc.ru.

‍

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

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

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

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

Страх № 1. Продукт будет низкого качества и нанесёт урон репутации

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

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

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

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

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

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

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

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

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

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

Если вы очень опасаетесь плохих отзывов об MVP, стоит выкатить релиз сначала на небольшую, самую лояльную аудиторию — friends & family, или несколько клиентов, с которыми будет легко договориться о пилотном запуске (в нашей практике большинство соглашается).

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

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

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

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

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

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

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

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

Страх № 2. Неопределённый бюджет на разработку

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

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

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

Разработка с ТЗ и без Agile обходится дороже по следующим причинам.

1. В ТЗ закладывают слишком много рисков и включают ненужные фичи.

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

В Agile над проектом работает фиксированная команда с фиксированной стоимостью. С этой командой можно (и нужно) договариваться; собственно, каждый спринт начинается с договорённости о том, какая ценность в конце спринта будет поставлена клиенту. Заказчик может любой бюджет тратить определённым образом, имея свободу корректировать и изменять ценности, отказываться от ненужных фич в пользу необходимых.

‍2. Клиент генерирует правки в самый последний момент.

Думаете, подробное ТЗ спасёт проект от корректировок и связанных с этим затрат? Практика показывает, что 99 % изменений клиенты требуют внести на самом последнем этапе, то есть на стадии приёмки. Представить готовый функционал заранее очень трудно, поэтому проект с абсолютно любым ТЗ будет требовать доработок. А значит, будут дополнительные циклы принятия бюджета. Ни о какой экономии не идёт речи, и согласовывать такой контракт тоже неудобно (шлифовать функционал можно бесконечно).

3. Принимать проект по ТЗ крайне затруднительно.

Представьте, вы тратите время на написание ТЗ и согласование его с департаментами (или это время тратят ваши сотрудники — неважно). Подрядчик оценивает этот объём и начинает работу. Далее он выдаёт объём работ большими частями, которые, соответственно, вам нужно тестировать большими кусками. Для проекта сложной разработки пройдёт минимум четыре месяца от старта: за это время кто-то может уволиться, в бизнесе может что-то измениться, само ваше видение идеала может стать совсем другим. В итоге, спустя несколько месяцев, вам приходит запрос на тестирование всего функционала, но не факт, что вы вообще помните, как он должен работать.

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

Сколько уйдёт времени на тестирование даже двух месяцев работы команды разработчиков? Очень много. В Agile приняты короткие циклы (спринт длится 1–2 недели), за это время на приёмку работ у вас уходит мало времени, вы быстро даёте корректировки, и они очень быстро вводятся в эксплуатацию, где пользователи тоже начинают давать обратную связь.

4. Не виден результат.

Если оценивать результат через ROI (коэффициент возврата инвестиций), MVP выгоден более ранним получением прибыли.

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

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

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

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

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

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

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

Страх № 3. Так никто не делает (в нашей нише, в нашем регионе и т. д.)

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

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

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

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

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

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

по теории:

• Дженнифер Грин, Эндрю Стеллман. «Постигая Agile. Ценности, принципы, методологии»;
• Эрик Рис. «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»;

по практике:

• глава из «Додо книги» на эту тему.

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

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

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

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

‍The second side of this fear is “only startups do this”

Is the fear justified or not?

‍The client might think, “Startups operate under uncertainty, so they need an MVP. And I've been in business for many years and I know exactly what I want from developers. I need very simple software. It should be here this button, and this field should be like this. Why do I need an MVP?” Here, simplicity is an illusion.

Not only startups, but also big businesses — with 10 or 20 years of experience or more — always face uncertainty when developing software.

First, the market situation and marketing trends are changing very quickly, and it is difficult to keep track of them. End users' behavior is changing even faster, as they gain new experiences from other companies every second. This can be called external uncertainty.

Secondly, there is internal uncertainty (on the customer's side): the more people make a decision, the more difficult it is for them to agree on exactly how the product should work.

A simple example: the customer thinks that the form of approving raw materials for the warehouse is very simple, because his employees do it manually every day. But automation reveals what the eye has been “blurred”: it turns out that the contractor must understand the batch number by the original invoice number, and the quantity of raw materials will be requested to enter the amount of raw materials based on knowledge that was not taken into account or digitized in any way in software development. The customer was sure that the task was simple and definite!

How to fight?

‍Assess the external and internal uncertainties surrounding your business. Remember how long it takes for your company to approve important documents. And how many mistakes have to be corrected in the process.

Estimate the loss of time in monetary terms for the year.

‍Example: The illusion of clarity

‍A small company focused on B2B clients ordered software for internal use using inflexible methodologies. It would seem like a simple product for a small number of users. The company has been on the market for a long time; all employees have more than 10 years of experience in doing business.

It took a year to approve the contract.

When the contractors accepted the task and clarified the requirements for field connectivity, they discussed each step for so long that it was clear that each of the four people in the department understood the project differently. Moreover, they did not know their own business processes. And when you automate business processes, you can't automate chaos. It is impossible to digitize this principle of appointing a responsible person: “Petya usually did it, but now let Vasya do it; it seems he is free now.” A clear algorithm is needed, and a lot of questions arise about the system.

The organization was far from being a startup, but this did not help it avoid internal uncertainties.

Fear number 4. It's hard, you'll have to work hard

Is the fear justified or not?

‍Before each sprint, you need to make a management decision about what is important for implementation for the next sprint (usually, a sprint takes 1-2 weeks in development, and 2-3 months in mechanical engineering, the main thing is rhythm!). This is difficult if your company does not have a strong manager, a leader who can clearly set goals for the next two weeks. Or when the company has too many decision makers and they can't come to an agreement.

How to fight?

‍Upgrade your managers. Learn the INVEST (or SMART) and Impact Mapping methods: this is a method of describing tasks that allows you to think through a task as deeply as possible in terms of user value, and a methodology according to which a specific task is aimed at improving specific indicators.

In addition to developers, serious IT companies also have a project manager who knows the INVEST and Impact Mapping methods and helps the customer come to the right wording (but, of course, not without the participation of management on the client's side).

Example: How MVP solves the problem of painful approvals

‍Without lengthy approvals, you can launch a trial version and supplement and improve it in every sprint. Making decisions about improvements in small steps is not easy, but it's usually easier than agreeing on a big project all at once! Neighboring departments no longer blame each other for not taking something into account, but are discussing the action plan for the next two weeks in detail.

Conclusion

So let me summarize: MVP is a means of contact with reality that helps you get feedback faster and adapt to the requirements of system users.

Flexible methodologies are beneficial to everyone (customer, contractor, and end user); they increase business management awareness.

‍We hope this article has at least slightly dispelled the fears surrounding MVP.

‍