Ретроспектива — це зустріч, на якій команда аналізує свій досвід роботи на хакатоні й виділяє конкретні дії для покращення. Без неї ви втрачаєте головну цінність будь-якого хакатону: навчання на власних рішеннях і помилках. Нижче — формат, порядок обговорення та правила фіксації висновків.
Формат ретроспективи для хакатонної команди
Оптимальний час проведення — протягом 48 годин після оголошення результатів, поки деталі ще свіжі. Зустріч триває 60–90 хвилин, залежно від тривалості самого хакатону та кількості учасників.
Ролі на зустрічі:
- Фасилітатор — веде обговорення, стежить за таймінгом, не дає зациклитися на одному питанні. Бажано, щоб це не був лід команди, щоб уникнути авторитетного тиску.
- Учасники — кожен висловлюється, наводить приклади з проєкту, пропонує корективи.
- Фіксатор — записує ключові тези в реальному часі. Може збігатися з фасилітатором, але за умови, що це не уповільнює процес.
Формат проведення — онлайн або офлайн, але обов'язково з загальним екраном або дошкою, де всі бачать записи. Використовуйте будь-яку дошку з колонками, головне — щоб структура була однаковою для всіх учасників.
Базова структура колонок:
- Що спрацювало добре
- Що не спрацювало і чому
- Що змінити в наступному хакатоні
Правила: жодних особистих звинувачень, лише процеси й рішення. Якщо хтось каже «ти не встиг», фасилітатор переформульовує: «ми не встигли, бо не розбили завдання на частини».
Що обговорити
Що спрацювало добре
Фіксуйте конкретні процеси, інструменти й рішення, які реально зекономили час або покращили результат. Не обмежуйтеся загальними фразами на кшталт «команда зібралася». Приклади того, що варто записати:
- Ранній вибір архітектури дозволив розподілити роботу між фронтендом і смарт-контрактами без блокувань.
- Загальна дошка з задачами давала змогу бачити прогрес кожного учасника в реальному часі.
- Попереднє обговорення scope MVP уберегло від спроб реалізувати зайвий функціонал.
- Готові шаблони репозиторію або CI/CD зекономили кілька годин налаштувань.
Критерій якості запису: інша людина, яка не брала участі в хакатоні, має зрозуміти, що саме було зроблено й чому це допомогло.
Що не спрацювало і чому
Тут важливо дійти до причини, а не зупинитися на симптомі. Типові помилки при аналізі:
- Симптом: «Ми не встигли зробити demo». Причина: «Ми почали записувати відео за годину до дедлайну, не маючи готового сценарію й тестованого сценарію використання».
- Симптом: «Смарт-контракт не деплоївся». Причина: «Ми не перевірили сумісність версій Anchor із версією Solana на тестовій мережі до останнього дня».
- Симптом: «Дизайнер нічого не зробив перший день». Причина: «Ми не визначили чіткі вимоги до інтерфейсу на старті, дизайнер чекав на технічні обмеження від розробників».
Фасилітатор має запитувати «чому» щонайменше двічі для кожного пункту, щоб уникнути поверхневих висновків.
Що змінити в наступному хакатоні
Кожен пункт у цій колонці має бути сформульований як конкретна дія, а не як побажання. Порівняйте:
- Погано: «Краще планувати час».
- Добре: «Виділити перші дві години хакатону виключно на розбір завдань, призначення відповідальних і фіксацію дедлайнів для кожного етапу».
- Погано: «Більше тестувати».
- Добре: «Писати тести паралельно з розробкою смарт-контрактів, а не відкладати на кінець».
- Погано: «Краще комунікувати».
- Добре: «Проводити синхронізацію кожні 4 години фіксованої тривалості — 15 хвилин, без відхилень».
Обмежте цю колонку п'ятьма–сімома пунктами. Більше — означає, що ви намагаєтеся виправити все одразу, що не спрацює на практиці.
Як фіксувати висновки для майбутнього
Головна помилка — записати висновки на дошку й закрити її. Через тиждень ніхто не згадає, де лежать ці нотатки. Щоб ретроспектива мала практичну цінність:
- Збережіть результат у спільному просторі команди — репозиторій проєкту, спільний канал або документ, до якого всі мають доступ.
- Створіть окремий файл або розділ з назвою на кшталт «ретроспектива-[назва хакатону]». Це дозволить знайти його пізніше без пошуку по історії повідомлень.
- Прив'яжіть кожну дію до конкретного етапу — підготовка, перший день, другий день, підготовка submission. Так ви знатимете, коли саме застосувати висновок.
- Призначте відповідального за кожну зміну — без цього пункти перетворюються на побажання.
Типова структура запису:
- Назва хакатону й дата
- Склад команди й ролі
- Що спрацювало (список із прикладами)
- Що не спрацювало (симптом → причина)
- Що змінити (конкретна дія, відповідальний, етап застосування)
Якщо команда планує брати участь у наступних хакатонах, відкривайте цей документ на початку підготовки й проглядайте перед тим, як домовлятися про процес.
Чи варто зберігати команду для наступного хакатону
Ретроспектива дає факти для прийняття цього рішення, а не емоції. Оцініть команду за трьома критеріями:
Ефективність розподілу ролей. Чи було зрозуміло, хто за що відповідає? Чи виникали ситуації, коли двоє робили одне й те саме, а якась завдання зависла? Якщо розподіл був хаотичним, але команда готова його виправити — це аргумент на користь збереження. Якщо учасники ігнорували свої зони відповідальності — це сигнал.
Комунікація під час тиску. Як команда поводилася, коли виникали проблеми: розгортання не проходили, API не відповідало, час закінчувався? Конструктивне обговорення й пошук рішень — зелений світ. Звинувачення, мовчання або ігнорування повідомлень — червоний.
Спільна мотивація. Чи всі учасники були зацікавлені в результаті? Чи був хтось присутній формально? Різниця в мотивації на хакатоні множиться під час тривалої роботи над проєктом.
Якщо за всіма трьома критеріями команда показала себе добре — зберігайте й не шукайте нових людей без вагомої причини. Якщо є проблеми за одним критерієм — обговоріть їх відкрито на ретроспективі й вирішіть, чи виправні. Якщо проблеми за двома чи трьома — краще розійтися мирно, ніж повторити негативний досвід.
Наступний крок: пошук ментора
Якщо ретроспектива показала, що проєкт має потенціал, а команда готова продовжувати роботу, наступний логічний крок — знайти людину з досвідом у вашій ніші на Solana. Ментор допоможе уникнути типових помилок, які ви вже зафіксували в колонці «що не спрацювало», але на рівні архітектури й стратегії проєкту.
Що саме треба знати перед пошуком ментора:
- Які технічні чи продуктові прогалини ви виявили під час хакатону.
- Який конкретний досвід вам не вистачило (наприклад, робота з PDA — Program Derived Addresses, оптимізація транзакцій, дизайн токеноміки).
- Який формат взаємодії вам підходить — разова консультація чи регулярні сесії.
Ці дані стануть вашою базою для наступного етапу. Як саме знайти ментора й на що звертати увагу — детально розібрано в наступному матеріалі.