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

Чек-лист технічної готовності

Технічна готовність залежить від вашої ролі. Розробник, дизайнер і маркетолог оцінюються за різними критеріями, але кожен має чіткий мінімум, без якого участь перетворюється на стрес замість роботи.

Для розробника на Solana:

  • Ви розумієте, що таке акаунт у Solana, транзакція, підпис і комісія (gas fee).
  • Ви можете локально запустити готовий проєкт із GitHub (наприклад, приклад із Anchor) і побачити його в роботі.
  • Ви маєте встановлені та налаштовані базові інструменти: Rust, Solana CLI, Node.js, Anchor (або фреймворк, який плануєте використовувати).
  • Ви розумієте різницю між програмою (smart contract) і клієнтською частиною, і знаєте, де закінчується ваша зона відповідальності.
  • Ви маєте доступ до RPC-провайдера (локальний devnet або зовнішній) і вмієте перевіряти логи транзакцій.

Для дизайнера:

  • Ви вмієте створювати інтерфейс у Figma (або аналогу) з готовими компонентами: кнопки, поля вводу, модальні вікна.
  • Ви розумієте, що таке wallet-підключення в контексті веб3, і можете спроєктувати екран підключення гаманця.
  • Ви можете передати розробнику макет із зрозумілою структурою: шари, автолейаути, стані компонентів (default, hover, disabled, error).

Для маркетолога чи продуктовика:

  • Ви можете сформулювати проблеми та рішення проєкту трьома реченнями без жаргону.
  • Ви розумієте, що таке target audience і чому «всі користуватели крипти» — це не сегмент.
  • Ви вмієте структурувати pitch-деку: проблема → рішення → технічна реалізація → чому Solana → наступні кроки.

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

Чек-лист навичок роботи в команді

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

  • Ви можете чітко назвати свою роль і межі. Не «робитиму, що скажуть», а «я відповідальний за смарт-контракти, фронтенд — не моя зона».
  • Ви вмієте давати зворотний зв'язок без агресії та без ухиляння. «Цей підхід не спрацює, бо…» замість «це погано» або мовчання.
  • Ви готові до асинхронної комунікації. Якщо команда в різних часових зонах, ви не чекаєте, поки всі зберуться онлайн, а фіксуєте рішення текстом.
  • Ви вмієте просити допомогу до того, як застрягнете на 6 годин. Це не слабкість, а навичка управління часом.
  • Ви розумієте, що демо важливіше за ідеальний код. Ви не будете рефакторити архітектуру за годину до дедлайну, якщо демо вже працює.
  • Ви можете погодитися з рішенням, яке не ваше. Обговорення триває обмежений час — рішення має бути прийняте і підтримане всіма.

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

Скільки часу реально потрібно на хакатон

Час — найменш зрозумілий ресурс у хакатонах. Більшість учасників недооцінюють його у двох напрямках одночасно.

Формальна тривалість vs. робочий час. Якщо хакатон триває 48 годин, це не означає 48 годин коду. Реальний робочий час команди з 3–4 осіб зазвичай становить 20–30 годин на людину. Решта — сон, перерви, обговорення, блокери.

Декомпозиція за фазами (орієнтовно для типової команди):

Фаза Час Що відбувається
Ідея та скоупінг 2–4 години Вибір ідеї, визначення мінімального демо, розподіл завдань
Технічний фундамент 6–10 годин Сетап проєкту, базова архітектура, розгортання програми на devnet
Розробка функціоналу 10–16 годин Основна логіка, інтеграція фронтенду з блокчейном, wallet-підключення
Полірування демо 4–6 годин Виправлення критичних багів, підготовка тестових даних, стабілізація
Pitch та submission 3–5 годин Запис відео, підготовка деки, заповнення форми, фінальне тестування

Типова помилка: залишити pitch і submission на останню годину. Форма submission часто містить неочікувані поля (посилання на репозиторій, опис архітектури, відео-демо). Заповнення може зайняти 40–60 хвилин, якщо ви не підготували матеріали заздалегідь.

Практичне правило: плануйте так, щоб повністю робоче демо було готове за 4–5 годин до дедлайну. Цей буфер рятує проєкти.

Як заповнити прогалини перед стартом

Якщо чек-листи виявили прогалини — це не привід відмовлятися. Більшість прогалин можна закрити за 3–7 днів цілеспрямованої роботи, якщо ви точно знаєте, що саме вчити.

Базові концепції Solana — коротко та з посиланням на академію розробника

Вам не потрібно знати всю архітектуру Solana. Для хакатону достатньо розуміти такий мінімум:

  • акаунт — одиниця зберігання даних у Solana. Програми, користувачі, токени — все це акаунти з різними даними.
  • Транзакція — набір інструкцій, які виконуються атомарно (всі або жодна).
  • Програма (smart contract) — код, що виконується на блокчейні. Написується на Rust (через Anchor) або TypeScript (через Seahorse).
  • PDA (Program Derived Address) — детермінована адреса, яку генерує програма для зберігання своїх даних. Це ключова концепція для роботи зі станом.
  • CPI (Cross-Program Invocation) — виклик однією програмою іншої програми. Потрібно, якщо ваш контракт взаємодіє з токен-програмою або іншими контрактами.

Для структурованого вивчення зверніться до розділу академії розробника на сайті — там послідовно викладені ці концепції з практичними вправами.

Інструменти розробки — мінімальний набір

Не встановлюйте все підряд. Ось набір, який покриває 90% потреб на хакатоні:

  • Solana CLI — управління локальним валідатором, розгортання програм, створення акаунтів. Перевірте: після встановлення команда solana --version має видавати номер версії без помилок.
  • Anchor — фреймворк для розробки програм на Rust. Перевірте: anchor --version працює, команда anchor init test-project створює робочий шаблон.
  • Node.js (v18+) — потрібен для клієнтської частини та інструментів навколо Anchor. Перевірте: node --version видає 18 або вище.
  • Редактор коду — VS Code з розширеннями Anchor, Rust Analyzer, Solana.
  • Гаманець для devnet — Phantom або Solflare з перемиканням на devnet-мережу. Перевірте: ви бачите тестові SOL на балансі та можете підписати тестову транзакцію.

Спосіб перевірки: створіть порожній Anchor-проєкт, запустіть локальний валідатор (solana-test-validator), задеплойте програму та викличте її через тест. Якщо весь цикл пройшов без помилок — ваше середовище готове.

Безпечний відкат: якщо щось зламалося при встановленні, не витрачайте час на діагностику в останній день перед хакатоном. Скоротіть стек: використовуйте Solana Playground (браузерне середовище) замість локальної установки. Це повільніше, але надійніше.

Наступний крок: реєстрація

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

  • Перевірте офіційний пакет першоджерел поточного хакатону: там вказані актуальні дедлайни, правила участі, вимоги до submission та формат подачі. Не покладайтеся на інформацію з минулих сезонів — правила змінюються.
  • При реєстрації вкажіть реальну роль, а не ту, яка «звучить краще». Це впливає на формування команд і оцінку.
  • Якщо ви шукаєте команду — вкажіть це явно в профілі з описом того, що саме ви приносите (конкретні навички, а не «допоможу чим зможу»).
  • Після реєстрації одразу перевірте доступ до комунікаційних каналів хакатону (Discord, Telegram). Буває, що запрошення надсилають не миттєво — краще виявити це за тиждень, а не за годину до старту.

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

Джерела