Scope першої версії — це чітка межа того, що продукт робить зараз, і того, що він не робить. Без цієї межі команда або розтягне розробку на місяці, або побудує щось велике, але нікому не потрібне. Нижче — практичний підхід до визначення scope для продукту на Solana, який допоможе вам дійти від гіпотези до працюючої версії без зайвих витрат.

Різниця між scope, MVP та повним продуктом

Ці три поняття часто плутають, але кожне відповідає на своє запитання.

Scope — це перелік фіч і обмежень, які ви фіксуєте для конкретної версії. Це документ або угода всередині команди: «ось що ми робимо, ось що не робимо». Scope може належати будь-якій версії — не лише першій.

MVP (minimum viable product) — це продукт у найменшому вигляді, який дозволяє перевірити головну гіпотезу на реальних користувачах. MVP має scope, але не кожен scope — це MVP. Можна випустити першу версію з широким scope, і це не буде мінімальною.

Повний продукт — це версія, яка вирішує завдання цільового користувача повноцінно, з усіма необхідними для масового використання елементами: онбординг, підтримка, аналітика, інтеграції, стабільність. Ви не починаєте з нього, і ви не знаєте напевно, як він виглядатиме, поки не перевірите гіпотези.

Помилка — вважати, що scope першої версії має бути «малим» за замовчуванням. Він має бути достатнім для перевірки гіпотези, а не штучно урізаним.

Як визначити, що входить у першу версію

Відправна точка — не список фіч, а гіпотеза. Що саме ви хочете дізнатися від ринку? Відповідь на це запитання визначає, що входить у scope.

Фічі, що підтверджують головну гіпотезу

Кожна фіча в першій версії має проходити один тест: «Якщо цієї фічі не буде, я не зможу перевірити свою гіпотезу». Якщо відповідь «зможу» — фіча не входить у scope.

Приклад: ви гіпотезуєте, що креатори готові продавати доступ до закритого контенту через токени на Solana. Щоб це перевірити, вам потрібні: створення токенізованого доступу, покупка, перевірка доступу. Вам не потрібні: реферальна програма, дашборд аналітики, мобільний додаток, інтеграція з Discord. Вони не спростовують і не підтверджують гіпотезу.

Критерій простий: фіча в scope, якщо без неї користувач не може виконати ключову дію, яка доводить або спростовує вашу гіпотезу.

Фічі, потрібні для користувацького досвіду мінімуму

Є фічі, які не підтверджують гіпотезу безпосередньо, але без них користувач не зможе або не захоче виконати ключову дію. Це не «зручності» — це бар'єри завершення.

  • Базовий онбординг. Якщо користувач не розуміє, що робити за перші 30 секунд, він піде. Але онбординг — це три кроки, а не інтерактивний тур із анімаціями.
  • Зрозуміла помилка. Якщо транзакція не пройшла, користувач має побачити причину, а не просто червоний екран.
  • Мінімальна навігація. Два-три екрани, які логічно ведуть від входу до ключової дії.

Усе, що виходить за межі «бар'єра завершення» — у backlog.

Як оцінити зусилля на кожну фічу

Оцінка зусиль на Solana відрізняється від звичайного Web2-продукту. Блокчейн-операції мають іншу природу: вони залежать від смарт-контрактів, стану мережі, моделі безпеки та взаємодії з гаманцями користувачів.

Блокчейн-операції коштують дорожче: плануйте відповідно

Розділіть усі фічі на три категорії за типом зусилля:

  • Клієнтська частина (frontend). Інтерфейс, навігація, форми. Оцінюється приблизно так само, як у Web2.
  • Офчейн-логіка (backend). База даних, авторизація, API. Теж знайома територія.
  • Ончейн-логіка (смарт-контракти). Програми на Solana, написані зазвичай на Rust за допомогою фреймворку Anchor. Тут оцінка зростає суттєво: кожна нова транзакція — це розробка, тестування, аудит безпеки, обробка edge-кейсів.

Практичне правило: якщо фічу можна реалізувати офчейн без втрати функціональності для гіпотези — робіть офчейн. Solana потрібна тоді, коли без неї продукт не працює: токенізація, децентралізоване володіння, прозорість транзакцій, composability з іншими протоколами.

Не додавайте блокчейн «на майбутнє» або «для довіри». Кожна ончейн-фіча в scope першої версії має відповідати на питання: «Чому без Solana ця дія неможлива або втрачає сенс?»

Для оцінки часу на ончейн-фічу множте вашу початкову оцінку мінімум на 1.5–2 порівняно з аналогічною офчейн-логікою. Це не песимізм — це облік тестування на devnet, обробки невдалих транзакцій, роботи з PDA (Program Derived Addresses — механізм Solana для визначення адрес програм), інтеграції з гаманцями.

Як сказати «ні» фічам на цьому етапі

Найскладніша частина визначення scope — не те, що додати, а те, що відкласти. Фічі накопичуються з кількох джерел: ваші власні ідеї, побажання перших користувачів, натхнення від конкурентів.

Backlog для майбутнього, а не скасування назавжди

Сказати «ні» на цьому етапі — не означає сказати «ні» назавжди. Фіча йде в backlog із коротким записом: що це, чому хтось її хотів, за якої умови вона може стати пріоритетною.

Коли виникає спокуса додати фічу в поточний scope, поставте три запитання:

  1. Чия це проблема? Хто конкретно просить або потребує цієї фічі? Це ваша цільова аудиторія чи випадковий запит?
  2. Хто платить? Чи готовий той, хто просить, платити за це зараз, чи це «було б круто»?
  3. Що станеться, якщо фічі не буде? Чи заблоковано ключову дію? Чи втрачається сенс гіпотези?

Якщо хоча б на одне з цих питань відповідь негативна — фіча не входить у scope.

Типова пастка: «ми не можемо випускати без X, бо конкуренти мають». Конкуренти випускали свій scope для своєї гіпотези на своєму етапі ринку. Ви не знаєте, чи працює їхня фіча, поки не перевірили свою базову.

Таймлайн: реалістичні терміни для Solana-продукту

Не існує універсального терміну, але є орієнтири, які допомагають перевірити, чи ваш план реалістичний.

Якщо scope першої версії включає одну-дві ончейн-операції та базовий клієнтський інтерфейс, зазвичай це від кількох тижнів до двох місяців роботи досвідченого розробника або невеликої команди. Якщо ончейн-логіка складніша — кілька програм, взаємодія через CPI (Cross-Program Invocation — виклики між програмами на Solana), робота з MEV-захистом — терміни зростають.

Фактори, що найчастіше подовжують таймлайн:

  • Недостатня специфікація ончейн-логіки. «Користувач купує токен» — це не специфікація. Специфікація: хто емітує токен, де зберігається ліквідність, як розподіляються кошти, що відбувається при відмові транзакції.
  • Пізнє тестування на devnet. Якщо ви вперше запускаєте транзакцію на devnet за тиждень до релізу, ви майже гарантовано зіткнетеся з несподіванками.
  • Зміна scope під час розробки. Кожна нова фіча посеред процесу — це не «маленьке доповнення», а перерахунок залежностей, тестів і термінів.

Реалістичний підхід: зафіксуйте scope, оцініть терміни з запасом, потім подивіться, чи можете ви скоротити scope ще раз, щоб вийти швидше. Швидший вихід із меншим scope майже завжди кращий за повільний із більшим.

Як scope змінюється після першого зворотного зв'язку

Після того як перша версія опинилася в руках користувачів, scope не залишається тим самим. Він змінюється на основі того, що ви дізналися.

Є три типи реакцій на зворотний зв'язок:

  • Гіпотеза підтвердилася. Користувачі виконують ключову дію, повертаються, готові платити. Наступний scope розширюється в бік стабільності, масштабування та фіч, які підсилюють підтверджену цінність.
  • Гіпотеза частково підтвердилася. Користувачі виконують дію, але з неочікуваним поведінковим патерном. Наприклад, вони використовують продукт не для того, для чого ви призначали. Scope наступної версії переспрямовується: ви посилюєте те, що працює, і прибираєте те, що ігнорується.
  • Гіпотеза не підтвердилася. Користувачі не виконують ключову дію або не повертаються. Тут scope не розширюється — він переосмислюється. Можливо, проблема реальна, але ваше рішення не підходить. Можливо, проблема не така болюча, як ви думали. У цьому випадку наступний крок — не нова версія, а нова гіпотеза.

Головне правило: scope наступної версії формується з даних, а не з припущень. Якщо ви не можете пояснити, чому фіча потрапила в новий scope інакше ніж «мені здається» — вона не потрапляє.

Після першого зворотного зв'язку також перегляньте ончейн-фічи. Можливо, те, що здавалося необхідним на Solana, можна перенести офчейн без втрати для користувача. Або навпаки — зворотний зв'язок показав, що саме ончейн-частина створює головну цінність, і саме її треба посилювати.

Scope — це не одноразове рішення на старті. Це інструмент, який ви використовуєте після кожного контакту з ринком, щоб вирішити: що далі, а що чекає.

Джерела