Одна агенція надає кошторис на робочий продукт. Інша — на екрани інтерфейсу. Обидві називають це MVP.
Перш ніж погодити будь-яку з пропозицій, потрібно зрозуміти, що клієнти зможуть робити в першій версії, що саме передасть команда та що ви дізнаєтеся, перш ніж витрачати більше.
Розробка MVP для стартапів перетворює ці рішення на продукт з обмеженим набором можливостей, яким уже можуть користуватися перші клієнти. Найскладніше — визначити, що має увійти до цієї версії, і знайти партнера, який зможе пояснити компроміси.
Top Netics поєднує R&D і підтримку розробки продуктів з проєктуванням архітектури та технічним керівництвом. Цей посібник пояснює, які роботи варто замовити, перш ніж передати перший продукт користувачам.
Ключові висновки щодо розробки MVP:
- Визначайте обсяг MVP навколо конкретного робочого процесу клієнта й питання, на яке може відповісти реальне використання.
- Відокремлюйте функції, які можна відкласти, від захисних механізмів і підтримки, необхідних першим користувачам.
- Порівнюйте пропозиції за результатами робіт, критеріями приймання, виключеннями з обсягу та розподілом відповідальності.
- Плануйте вартість і строки розробки MVP до запуску та завершення першого циклу навчання, враховуючи експлуатаційні витрати, зміни й оцінювання результатів використання клієнтами.
- Обирайте партнера з розробки, який може пояснити, що створювати, що відкласти та які дані можуть змінити план.
Що таке розробка MVP?
Розробка MVP — це процес створення й випуску мінімально життєздатного продукту: версії з обмеженими можливостями, яка дає корисний результат першим користувачам і допомагає команді перевірити конкретні припущення до подальших інвестицій.
У проєкті з розробки програмного забезпечення це передбачає основний робочий процес, належні захисні механізми та спосіб вимірювати, що відбувається під час використання.
Методологія Lean Startup пов’язує MVP із циклом «створити — виміряти — навчитися». Випуск продукту розпочинає цей цикл, а результати допомагають ухвалити наступне рішення.
MVP може обслуговувати невелику групу запрошених користувачів. Для нього не обов’язкові публічний запуск чи всі функції майбутнього продукту. Частину роботи можна виконувати вручну, якщо це підходить користувачам і її вартість обліковується.
Корисна перша версія відповідає, наприклад, на таке питання: чи користуватимуться операційні менеджери цим робочим процесом щотижня і чи виправдає заощаджений час ціну? Сама лише успішна демонстрація відповіді не дає.
Що потрібно спочатку: MVP, прототип чи PoC?
Вибір того, що створювати першим, цілком залежить від невизначеності, яку потрібно усунути перед наступною інвестицією. Підтвердження концепції (PoC) перевіряє технічну здійсненність, прототип — окремі аспекти запропонованого досвіду взаємодії, а MVP — придатний до використання продукт за участі перших клієнтів.
Створювати MVP варто тоді, коли потрібне реальне використання й ви можете залучити людей, готових його спробувати.
| Основна невизначеність | Доцільний наступний крок | Які докази шукати |
|---|---|---|
Чи мають ці клієнти проблему, яку варто розв’язувати? | Інтерв’ю та спостереження | Наявні обхідні рішення, частота проблеми, витрати та причини змінити підхід |
Чи може технічний підхід працювати з нашими даними або системами? | Підтвердження концепції (PoC) | Виміряні результати щодо визначеного критерію технічної здійсненності |
Чи можуть користувачі зрозуміти й виконати запропоновану послідовність дій? | Прототип | Спостереження за виконанням завдань, труднощі з розумінням і проблеми зручності використання |
Чи користуватимуться клієнти рішенням і чи отримають достатню цінність, щоб продовжувати? | MVP | Реальне використання, результати, повторне використання та купівельна поведінка, де це доречно |
Ці методи можуть перетинатися. Прототип може містити робочий код, а PoC — стати частиною подальшої розробки. Важлива відмінність полягає в питанні, на яке відповідає кожен із цих видів робіт.
Якщо попит не підтверджено, почніть із валідації ринку. Якщо можливості ШІ ще не перевірено на відповідних тестових даних, розгляньте розробку PoC для ШІ, перш ніж замовляти створення продукту навколо цієї технології.
Уже маєте прототип або застосунок, створений агенцією? Технічне оцінювання наявного програмного забезпечення допоможе визначити, що можна використати повторно, а що потребує додаткової перевірки.
Як визначити обсяг MVP?
Визначити обсяг MVP означає встановити, хто буде першими користувачами, який робочий процес вони мають виконувати, які можливості для цього потрібні та які функції свідомо відкладаються. Також потрібно визначити, як команда вимірюватиме результати й вирішуватиме, що розробляти далі.
Почніть із робочого процесу та вимірюваного результату
«Платформа для фінансових команд» залишає майже все невизначеним. «Фахівець із розрахунків із постачальниками завантажує рахунок, перевіряє розпізнані поля та експортує погоджений запис» — це вже робочий процес, який команда може спроєктувати й оцінити.
Перш ніж запитувати пропозицію, запишіть:
- хто користуватиметься першою версією і як ви залучите цих людей
- з чого починається робочий процес і як виглядає виконане завдання
- як користувачі розв’язують проблему сьогодні
- який результат виправдає наступну інвестицію
- граничний бюджет і будь-яку дату, недотримання якої матиме реальні наслідки для бізнесу
Залучіть перших користувачів до запуску, щоб випущена версія могла дати відповідь на комерційне питання.
Вирішіть, що можна залишити ручним
Для невеликої першої групи клієнтів може бути доцільно вручну проводити онбординг, виставляти рахунки та допомагати з імпортом даних. Фіксуйте, хто виконує цю роботу, скільки часу вона забирає і коли такий підхід стане недоцільним.
Ручна робота допомагає отримувати знання з невеликими витратами. Необлікована ручна робота може створити враження, що продукт ефективніший, ніж є насправді.
Визначте, що не можна скорочувати
Навіть невеликий набір функцій має відповідати потребам цільових користувачів і характеру їхніх даних. Розмежування даних клієнтів, права доступу, обробка помилок і відновлення можуть бути необхідні вже в першій версії, навіть якщо вони не додають видимих переваг для продажу.
Попросіть підрядника пояснити, яких засобів контролю потребує заплановане використання і як їх перевірятимуть. OWASP Application Security Verification Standard містить вимоги, які допоможуть конкретизувати перевірку безпеки вебзастосунку. Посилання на стандарт — це відправна точка для погодження робіт, а не доказ того, що продукт уже пройшов перевірку.
Приклад обсягу MVP: що розробити, залишити ручним і відкласти
Розгляньмо стартап, який створює продукт для обробки рахунків із застосуванням ШІ для невеликих бухгалтерських фірм. Його найближче питання — чи зможуть фахівці готувати точні записи для експорту швидше, ніж за нинішнього процесу.
Наведений сценарій і порогові значення є гіпотетичними.
Перша група складається з трьох фірм, які використовують одну й ту саму бухгалтерську програму. Версія підтримує одну погоджену категорію рахунків, а фахівець перевіряє кожен запис перед експортом.
| Елемент обсягу робіт | Рішення для першої версії | Причина |
|---|---|---|
Приймання документів | Завантаження PDF у межах погоджених обмежень формату й розміру | Визначає обмежений набір вхідних даних, який команда може перевірити |
Розпізнавання та перевірка | Розпізнавання визначених полів із можливістю виправлення фахівцем | Забезпечує виконання основного завдання зі збереженням перевірки людиною |
Експорт | Формування сумісного CSV-файлу | Дає змогу перевірити робочий процес до створення прямої інтеграції з бухгалтерською системою |
Доступ | Розмежування записів кожної фірми та обмеження доступу за ролями | Захищає дані клієнтів під час реального використання |
Нестандартні ситуації | Відображення збоїв обробки та можливість відновлення без повторного експорту тих самих даних | Дає користувачам змогу завершити роботу, коли стандартний сценарій не спрацьовує |
Вимірювання | Фіксація часу обробки, виправлень, завершення завдань і вартості використання моделі | Показує, чи дає робочий процес цінність за прийнятної вартості |
Онбординг і виставлення рахунків | Виконання обох процесів вручну для першої групи клієнтів | Дає змогу не автоматизувати малочисельні операції, доки команда не вивчить їх на практиці |
Подальші функції | Відкласти мобільні застосунки, інтеграції з кількома бухгалтерськими системами та автономне погодження платежів | Вони розширюють обсяг робіт за межі питання, яке перевіряється |
Перша версія забезпечує виконання одного клієнтського завдання в межах визначених обмежень вхідних даних та інтеграцій.
До запуску стартап погоджує чотиритижневе оцінювання. Він порівнюватиме медіанний час повної обробки одного рахунка з початковим показником кожної фірми, враховуючи виправлення й перевірку експорту. Попередня ціль щодо цінності — скорочення часу на 30% без погіршення точності підсумкових записів. Кожна з трьох фірм має надати достатній обсяг порівнюваної роботи, щоб її результати можна було інтерпретувати окремо.
Команда окремо відстежує вартість обробки й час ручної підтримки. Після випробування вона пропонує продовжити використання за визначеною ціною. Швидша обробка підкріплює висновок про цінність; платне продовження перевіряє інше припущення.
Якщо економія часу з’являється лише в одній фірмі, дослідіть відмінності робочих процесів до розширення. Якщо економія стабільна, але підтримка поглинає маржу, наступні роботи можуть стосуватися онбордингу чи обробки нестандартних ситуацій, а не нових функцій.
Маєте список функцій, але не визначили, що увійде до першої версії? Обговоріть обсяг вашого MVP з Top Netics. Опишіть робочий процес, цільових користувачів і рішення, яке має допомогти ухвалити розробка.
Що має містити пропозиція з розробки MVP?
Пропозиція з розробки MVP має визначати обсяг і результати робіт, критерії приймання, ціну, графік та відповідальність аж до передачі продукту й підтримки.
Використовуйте цей чекліст пропозиції з розробки MVP, щоб запитувати порівнювані кошториси на основі одного й того самого брифу.
| Розділ пропозиції | Що вимагати | Що уточнити перед погодженням |
|---|---|---|
Дослідження й визначення обсягу | Погоджений робочий процес, припущення та виключення | Хто розв’язує відкриті питання щодо продукту? |
Дизайн і розробка | Екрани, поведінка, інтеграції та підтримувані платформи | Кошторис стосується робочого програмного забезпечення чи дизайн-прототипу? |
Тестування | Перелік конкретних перевірок і докази результатів | Чи включено сценарії збоїв і відповідні засоби контролю безпеки? |
Випуск | Розгортання, моніторинг і погоджений підхід до відновлення | Хто запускає продукт і реагує на проблеми під час запуску? |
Вимірювання | Події та звіти, пов’язані з питанням, яке потрібно перевірити | Чи знатимете ви, де користувачі стикаються з труднощами або припиняють виконання завдання? |
Доступ і передача | Доступ до репозиторію та облікових записів, документація й демонстрація роботи | Чи зможе інша кваліфікована команда експлуатувати та розвивати продукт? |
Комерційні умови | Етапи оплати, порядок внесення змін і витрати на сторонні сервіси | Що спричиняє додаткові платежі або перегляд графіка? |
Після запуску | Усунення дефектів, межі підтримки й домовленості щодо ітерацій | Які зміни включено, які оцінюються окремо, а які виключено? |
Перевірте кожен рядок, перш ніж порівнювати загальні суми: неврахована робота може лягти на засновника.
Погодьте критерії приймання
«Обробку рахунків завершено» — надто розпливчасте формулювання. Чіткіший критерій приймання описує вхідні дані, дію користувача, очікуваний результат і поведінку під час збою: уповноважений фахівець може завантажити рахунок підтримуваного формату, виправити розпізнані поля, експортувати погоджений запис і побачити зрозумілий статус у разі збою обробки.
Технічне приймання підтверджує реалізацію погодженого робочого процесу. Продовження оплати — окрема комерційна перевірка.
Засновникам, які не мають власного керівника інженерної команди, варто визначити відповідального за технічні рішення, перш ніж погоджувати архітектуру та рішення щодо приймання.
Скільки коштує розробка MVP?
Вартість розробки MVP залежить від трудомісткості дизайну, інженерних робіт, тестування й випуску, зокрема інтеграцій і підготовки даних. Плануйте бюджет до завершення першого циклу навчання, включно з експлуатаційними витратами та змінами після запуску.
Три гіпотетичні бюджети MVP: від дослідження до перших змін
Порівняймо три варіанти обсягу робіт для пілотного продукту з обробки рахунків:
- A — Ручне введення та перевірка: фахівці вводять поля рахунків, перевіряють записи й експортують CSV-файли. Це перевіряє робочий процес, але не розпізнавання за допомогою ШІ чи економію часу від нього.
- B — Розпізнавання за допомогою ШІ з експортом у CSV: наведений вище приклад з автоматичним розпізнаванням полів і обов’язковою перевіркою людиною. Він перевіряє, чи покращує виконання завдання обробка з допомогою ШІ.
- C — Розпізнавання за допомогою ШІ з однією бухгалтерською інтеграцією: додається прямий експорт до однієї бухгалтерської системи, включно з авторизацією, запобіганням дублюванню й обробкою збоїв передавання. Це перевіряє більшу частину наскрізного робочого процесу.
Нижче наведено ілюстративні бюджети MVP у доларах США з умовною усередненою ставкою $60 за годину.
| Гіпотетична стаття бюджету (USD; умовна ставка $60/год) | A: Ручне введення + CSV | B: Розпізнавання ШІ + CSV | C: Розпізнавання ШІ + інтеграція |
|---|---|---|---|
Дослідження й визначення обсягу | 40 годин / $2,400 | 60 годин / $3,600 | 80 годин / $4,800 |
Проєктування робочого процесу й інтерфейсу | 40 годин / $2,400 | 60 годин / $3,600 | 80 годин / $4,800 |
Інженерні роботи, включно з вимірюванням | 220 годин / $13,200 | 340 годин / $20,400 | 540 годин / $32,400 |
Тестування, розгортання, документація та передача | 100 годин / $6,000 | 140 годин / $8,400 | 200 годин / $12,000 |
Проміжний підсумок до передачі продукту | 400 годин / $24,000 | 600 годин / $36,000 | 900 годин / $54,000 |
Перший аналіз результатів і зміни після запуску | 40 годин / $2,400 | 60 годин / $3,600 | 100 годин / $6,000 |
Резерв на інфраструктуру та сторонні сервіси: період розробки + перший місяць експлуатації | $600 | $900 | $1,500 |
Резерв на непередбачені витрати: 15% проміжного підсумку | $3,600 | $5,400 | $8,100 |
Гіпотетичний плановий підсумок — не комерційна пропозиція | $30,600 | $45,900 | $69,600 |
У сценарії B гіпотетичні $36,000 до передачі продукту перетворюються на $45,900 з урахуванням першого місяця експлуатації.
Сценарій A коштує менше, але не відповідає на питання, чи скорочує ШІ час обробки. Сценарій B дає змогу перевірити обробку з допомогою ШІ без прямої інтеграції. Сценарій C варто розглядати, коли саме передавання через CSV заважає клієнтам отримати або виміряти очікувану цінність.
Скільки часу займає розробка MVP?
Строк розробки MVP залежить від складності продукту й технологічного стеку та може становити від 4 до 12 тижнів. Запитайте в підрядника календарний план, який показує паралельні етапи та період оцінювання результатів використання клієнтами після запуску.
Наприклад, у сценарії B на роботи до передачі продукту закладено 600 годин. Це дорівнює 15 людино-тижням за 40-годинного робочого тижня, але не означає строк виконання у 15 тижнів. Дизайн, розробка й тестування можуть частково відбуватися паралельно; проблеми з доступом або погодження з клієнтами можуть збільшити календарну тривалість без пропорційного збільшення робочих годин.
Ось етапи MVP та результати, які має забезпечити кожен із них:
- Дослідження й визначення обсягу: погодити користувачів, робочий процес, виключення та критерії приймання.
- Дизайн: конкретизувати основний робочий процес і сценарії збоїв.
- Розробка: реалізувати й інтегрувати погоджені можливості.
- Тестування та підготовка до випуску: перевірити поведінку, права доступу, відновлення й розгортання.
- Запуск: надати цільовим користувачам доступ до версії та призначити відповідальних за підтримку.
- Оцінювання результатів використання клієнтами: виміряти результати й вирішити, що змінити.
Як обрати компанію для розробки MVP
Обирайте партнера з розробки MVP, оцінюючи його рішення щодо обсягу робіт, досвід реалізації подібних продуктів і технічне керівництво. Познайомтеся із запропонованим керівником і поставте ці шість запитань, щоб перевірити його логіку:
- Що ви прибрали б із нашої першої версії і чому? Шукайте пояснення, пов’язане з цінністю для клієнта, отриманням нових знань або ризиками реалізації.
- Яке припущення потрібно перевірити, перш ніж ви зможете впевнено оцінити роботи? Корисна відповідь називає невизначеність і співмірний спосіб її дослідження.
- Який подібний продукт ви вже реалізували? Запитайте про початковий обсяг робіт, обмеження, особистий внесок і те, що відбувалося після випуску.
- Покажіть, як ви демонструєте прогрес. Попросіть показати, як команда переглядає чергову робочу частину продукту і як зворотний зв’язок перетворюється на погоджену зміну.
- Розкажіть про випуск, який ви відклали. Запитайте, які дані обґрунтували затримку і як команда пояснила її наслідки.
- Як інша команда переймала вашу роботу? Попросіть приклад документації або демонстрації, які зробили перехід можливим.
Загальні відповіді без прикладів не дають змоги перевірити якість рішень підрядника.
А як щодо no-code та розробки з допомогою ШІ?
No-code, розробка з допомогою ШІ та індивідуальна програмна розробка можуть бути доречними. Попросіть підрядника пояснити обмеження інтеграцій, роботу з даними, регулярні витрати й те, як майбутня команда зможе підтримувати продукт або перенести його на іншу технологічну основу.
Для згенерованого коду вимагайте такої самої перевірки й доказів відповідності критеріям приймання, як і для будь-якого іншого коду. Швидша реалізація не визначає, чи корисний робочий процес і чи готова версія до випуску.
Що відбувається після запуску MVP?
Після запуску вимірюйте, чи завершують цільові клієнти робочий процес, чи отримують очікувану цінність і чи повертаються або платять, де це доречно. Поряд із поведінкою клієнтів відстежуйте помилки, експлуатаційні витрати й трудомісткість підтримки.
Погодьте дату аналізу результатів і критерії рішення до випуску. Наступною інвестицією може стати ще одна перевірка, виправлення робочого процесу, підвищення надійності експлуатації або розширення групи користувачів. Робоча версія не виправдовує автоматичного збільшення списку запланованих функцій.
Призначте відповідального за аналіз результатів і замовлення наступних робіт відповідно до домовленостей щодо підтримки та змін, погоджених у пропозиції.
Обговоріть обсяг вашого MVP з Top Netics
Опубліковане портфоліо Top Netics охоплює продукти у сферах ШІ, фінтеху та блокчейну, а також компетенції з досліджень, архітектури й інженерної розробки. Серед прикладів — Crypto Attention, що оцінює увагу криптомедіа; Innfinn, платформа доступу до вже заробленої зарплати з інтеграцією із системами її нарахування; і Sealbound, проєкт у сфері документів, що підтверджують кваліфікацію, та сертифікатів. Ці приклади можуть стати доречною відправною точкою для обговорення технічних залежностей вашого продукту.
Обговорення MVP з Top Netics особливо доречне, коли перша версія передбачає невирішені технічні питання, складні інтеграції або потребу в старшому технічному керівництві поряд із розробкою. Попросіть нас пояснити, як запропонований підхід пов’язаний із відповідними проєктами та людьми, які братимуть участь у роботі.
Приходьте з ідеєю, прототипом або наявною пропозицією. Розкажіть, хто буде першими користувачами, що їм потрібно виконувати та на який бюджет або строк ви орієнтуєтеся. Для початку розмови не потрібне готове технічне завдання.
