Як описати навчальний проєкт так, щоб не видавати його за бізнес

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

Нижче — покрокова інструкція, як описати навчальний проєкт чесно й водночас переконливо.

Коли варто почати звідси

Ця інструкція корисна, якщо ви:

• Створили демо під час вивчення Rust, Anchor або клієнтської частини на Solana й хочете покласти це в портфоліо.
• Подаєте заявку на баунті, грант або першу роботу й потрібно описати, що саме ви зробили.
• Готуєте дашборд як портфоліо і не хочете, щоб кожен проєкт виглядав як претензія на готовий бізнес.
• Відповідаєте на запитання співбесіди «розкажіть про ваш проєкт» і хочете звучати професійно, не перебільшуючи.

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

Що підготувати заздалегідь

Перш ніж писати опис, відповідайте собі на три питання:

1. Яка саме навичка була ціллю? Не «зробив дапп», а «навчився працювати з PDA (Program Derived Address — похідні адреси програми в Solana) у Anchor».
2. Які технічні обмеження я свідомо прийняв? Наприклад: без фронтенду, без тестів, лише devnet (тестова мережа Solana), без обробки помилок.
3. Що я б зробив інакше, якби це був реальний продукт? Це найважливіше питання. Воно показує, що ви розумієте різницю між навчальним завданням і продуктом.

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

Порядок виконання

Крок 1. Назвіть проєкт тим, чим він є

Замість «DeFi-протокол для кредитування» — «Навчальний смарт-контракт: базова логіка кредитування на Anchor». Замість «Маркетплейс NFT» — «Демо-дапп: створення й перегляд NFT з використанням Metaplex». Назва має одразу сигналізувати: це навчальний артефакт, а не продукт.

Крок 2. Вкажіть контекст і мотивацію

Одне-два речення: чому ви це робили. «Щоб зрозуміти, як працюють крос-програмні виклики (CPI) у Solana» або «у межах курсу з Rust писав свій перший контракт на Anchor». Це знімає очікування: читач розуміє, що метою не був запуск.

Крок 3. Опишіть технічну сутність без маркетингових слів

Перелічіть конкретно:

• Які інструкції або функції реалізовані.
• Які акаунти використовуються і чому.
• Де розгорнуто — devnet, localnet, testnet.
• Які бібліотеки чи інструменти застосовано.

Уникайте слів на кшталт «рішення для…», «платформа», «екосистема». Вони створюють враження продукту. Замість цього — «контракт із трьома інструкціями», «CLI-скрипт для взаємодії з програмою».

Крок 4. Чесно перелічіть обмеження

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

• «Не реалізовано: перевірка прав доступу, обробка помилок на клієнті, міграція бази даних.»
• «Тестовано лише на devnet, без навантажувальних тестів.»
• «Фронтенд — мінімальний UI для виклику інструкцій, не готовий до публічного використання.»

Крок 5. Покажіть, що ви навчилися

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

Ознаки коректного результату

Прочитайте свій опис і задайте собі три контрольні питання:

1. Чи може читач після цього тексту вирішити, чи підходите ви на конкретну роль? Якщо опис занадто загальний — ви не дали достатньо інформації. Якщо занадто схожий на пітч-дек — ви перебільшили.
2. Чи є в тексті хоча б одне слово, яке натякає на готовність до продакшену? Якщо так — замініть або уточніть. «Працює» → «працює на devnet». «Готовий» → «готовий для демонстрації логіки».
3. Чи зрозуміло, де закінчується код і починається уява? Якщо ви описуєте функції, які не реалізовані, але «плануєте» — це вже червоний прапорець. Або реалізуйте й опишіть, або не згадуйте.

Додатковий тест: дайте прочитати опис людині, яка не бачила ваш код. Якщо вона після прочитання думає, що це працюючий продукт — потрібно переписувати.

Критерії для зупинки

Є ситуації, коли самостійно описати навчальний проєкт складно або ризиковано:

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

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

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

Редакція солана.укр