Распрацоўка MVP: як запусціць прадукт хутка і без лішніх выдаткаў

Большасць прадуктаў праваліваецца не праз дрэнны код, а таму, што вырашае праблему, за якую ніхто не гатовы плаціць. Мінімальная версія патрэбна, каб праверыць гэта за тыдні і за разумныя грошы, а не за год і ўвесь бюджэт.

У гэтым артыкуле — практычны погляд на распрацоўку MVP: што лічыць мінімальным прадуктам, які фармат выбраць, як адрэзаць лішнія функцыі, якія метрыкі глядзець пасля запуску і ў колькі абыходзіцца першая версія. Без тэорыі дзеля тэорыі — з лічбамі, тэрмінамі і тыповымі памылкамі.

MVP — што гэта і чым ён не з'яўляецца

MVP (minimum viable product) — гэта самая простая версія прадукту, якая вырашае адну ключавую праблему карыстальніка настолькі добра, што ён гатовы ёю карыстацца і плаціць. Ключавое слова — viable, «жыццяздольны». Гэта не макет і не дэма для інвестара, а працоўны прадукт з рэальнымі карыстальнікамі і рэальнымі данымі.

Чым MVP не з'яўляецца

• Не «сырая» версія. Адна функцыя, зробленая добра, лепшая за дзесяць, зробленых напалову: карыстальнік не адрознівае «мінімальны прадукт» ад «дрэннага прадукту».
• Не прататып. Клікабельны прататып правярае зразумеласць інтэрфейсу, MVP — гатоўнасць плаціць і вяртацца.
• Не абрэзаная копія фінальнага прадукту. Гэта асобны зрэз: поўны шлях карыстальніка па адным сцэнарыі, а не 30% ад кожнага з дзесяці.
• Не аднаразовы код. Калі архітэктура не разлічана на рост, пасля паспяховага тэсту ўсё давядзецца перапісваць — і страціць паўгода.

Добры тэст: сфармулюйце гіпотэзу ў выглядзе «Мы верым, што [аўдыторыя] будзе [дзеянне], таму што [прычына]. Мы зразумеем, што маем рацыю, калі [метрыка] дасягне [значэнне] за [тэрмін]». Калі гіпотэзу не атрымліваецца запісаць так, пісаць код пакуль рана.

Фарматы MVP: ад бота да платформы

Адзін і той жа бізнес можна праверыць прадуктамі рознага маштабу. Часта першую гіпотэзу танней за ўсё праверыць у Telegram: у карыстальніка ўжо ёсць мэсэнджар, рэгістрацыі няма, аплата — у два тапы. Параўнайце фарматы:

Фармат выбіраюць па сцэнарыі, а не па модзе. Калі карыстальнік вяртаецца раз на месяц — дадатак у краме яму не патрэбны, хопіць сайта або Telegram Mini App. Калі прадукт выкарыстоўваецца штодня, з push і геалакацыяй, — лагічней адразу закладваць мабільны дадатак або PWA. Параўнанне гэтых варыянтаў — у артыкуле PWA або мабільны дадатак.

Як адабраць функцыі для першай версіі

Самая дарагая частка MVP — не тое, што вы зрабілі, а тое, што вы зрабілі дарэмна. Адбор функцый — галоўная работа да старту распрацоўкі.

Крок 1. Адзін ключавы сцэнарый

Апішыце шлях карыстальніка ад першага дотыку да атрымання каштоўнасці. Для маркетплэйса паслуг: кліент апісвае задачу → атрымлівае водгукі выканаўцаў → выбірае → аплачвае → ацэньвае. Усё, што не ляжыць на гэтым шляху, — кандыдат на другую версію.

Крок 2. Ручныя аперацыі замест аўтаматыкі

На старце шмат што можна рабіць уручную: мадэрацыю, падбор выканаўцы, вяртанні, складаную аналітыку. Аўтаматызуюць тое, што стала вузкім месцам, — калі аперацый дзясяткі ў дзень, а не дзве на тыдзень.

Крок 3. Сумленная разметка прыярытэтаў

• Must — без гэтага сцэнарый не праходзіцца (каталог, замова, аплата, апавяшчэнні).
• Should — прыкметна паляпшае досвед, але не блакуе запуск (фільтры, абранае, прамакоды).
• Could — добра было б мець (тэмы афармлення, рэферальная праграма, гейміфікацыя).
• Won't — свядома адкладаем (шматмоўнасць, уласны чат, складаная аналітыка).

Практычнае правіла: калі ў Must больш за 7–10 функцый, гэта ўжо не MVP. Такі адбор зручна рабіць адразу ў ТЗ — як яго структураваць, мы разабралі ў артыкуле як скласці ТЗ на распрацоўку.

Колькі каштуе MVP і ад чаго залежыць цана

На пытанне «колькі каштуе MVP» сумленны адказ — ад 60 000 ₽ за бота да некалькіх мільёнаў за платформу з мабільнымі дадаткамі. Цэны ў табліцы вышэй даведачныя; дакладны кошт можна назваць толькі пасля прапрацоўкі ТЗ. На выніковы каштарыс найбольш уплываюць:

1. Колькасць роляў. Кліент і адміністратар — адна складанасць; кліент, выканаўца, мадэратар, дыспетчар і бухгалтар — зусім іншая.
2. Платформы. Вэб, iOS і Android — гэта тры інтэрфейсы, нават пры агульнай кодавай базе на React Native.
3. Плацяжы. Прыём аплаты — проста; эскроу, спліт-плацяжы, выплаты выканаўцам і чэкі — асобны блок работ.
4. Інтэграцыі. Кожная знешняя сістэма (1С, CRM, склад, карты, тэлефанія) дадае дні і рызыкі, асабліва калі ў яе няма нармальнага API.
5. Патрабаванні да даных. 152-ФЗ (расійскі закон аб персанальных даных), размяшчэнне на сваіх серверах, закрыты контур, аўдыт дзеянняў.
6. AI-функцыі. RAG па дакументах кампаніі або шматагентная логіка патрабуюць асобнай прапрацоўкі і тэставання якасці адказаў.

Зэканоміць можна на шырыні, але не на якасці ключавога сцэнарыя. Скараціць колькасць роляў, адкласці адну платформу, замяніць складаную інтэграцыю выгрузкай у Google Sheets на першыя месяцы — нармальна. Зэканоміць на тэставанні аплаты — не. Арыенціры па ўсіх напрамках сабраны на старонцы цэн на распрацоўку.

Распрацоўка MVP пад ключ: этапы і тэрміны

Распрацоўка MVP пад ключ для платформы звычайна ўкладваецца ў 8–12 тыдняў. Вось як размяркоўваецца час на тыповым праекце такога маштабу:

Для бота або Mini App тыя ж этапы сціскаюцца да дзён, для мабільнага дадатку расцягваюцца да 8–14 тыдняў — сюды дадаецца рэўю ў App Store і Google Play. Прыклад з практыкі: маркетплэйс бытавых паслуг з вэб-версіяй і дадаткамі для iOS і Android дайшоў да MVP за 9 тыдняў, а далей развіваўся спрынтамі без перапісвання архітэктуры.

Метрыкі: як зразумець, што MVP спрацаваў

Метрыкі выбіраюць да запуску, інакш пасля яго любы вынік падасца «нядрэнным». Мінімальны набор:

• Актывацыя — якая доля новых карыстальнікаў прайшла ключавы сцэнарый да канца (зрабіла замову, запісалася, атрымала адказ).
• Утрыманне — колькі вярнуліся праз 7 і 30 дзён. Для прадуктаў штодзённага выкарыстання гэта галоўны сігнал.
• Канверсія ў аплату — колькі карыстальнікаў заплацілі хоць бы раз.
• Юніт-эканоміка — кошт прыцягнення супраць даходу з карыстальніка; для маркетплэйса — яшчэ і ліквіднасць (доля замоў, якія знайшлі выканаўцу).
• Якасны сігнал — 10–15 інтэрв'ю з першымі карыстальнікамі: што спадабалася, дзе затрымаліся, за што гатовыя плаціць больш.

Аналітыку падзей закладваюць у першую версію, а не «потым». Кожны крок ключавога сцэнарыя павінен быць размечаны — інакш праз месяц вы даведаецеся, што карыстальнікі сыходзяць, але не даведаецеся, дзе.

Памылкі MVP стартапа і карпаратыўнага праекта

MVP стартапа і пілот унутры буйной кампаніі памыляюцца па-рознаму, але прычыны падобныя:

Калі вы плануеце двухбаковы рынак, пачніце з артыкула як стварыць маркетплэйс — там падрабязна пра праблему «курыцы і яйка» і пра тое, які бок рынку прыцягваць першым. А як мы праектуем платформы, якія растуць без перапісвання, — на старонцы распрацоўкі платформ і маркетплэйсаў.