Щоденний стендап у хакатоні — це не статус-звіт для керівника, а інструмент синхронізації команди за умов жорсткого обмеження часу. Правильно організований, він займає 15 хвилин, виявляє блокери до того, як вони зупинять розробку, і дає всім учасникам чітке розуміння, де знаходиться проєкт щодо демо. Нижче — покрокова схема, як це зробити.
Формат короткого стендапу (15 хвилин)
Головне правило хакатонного стендапу — жорсткий таймбокс. 15 хвилин означає рівно 15 хвилин, а не «почали о 10:00 і закінчили, коли вичерпали тему».
Структура зустрічі
- 0–1 хвилина. Фасилітатор (зазвичай той, хто відповідає за координацію) нагадує поточну дедлайн-точку: скільки годин чи днів залишилось до submission, який мінімальний функціонал має працювати до кінця дня.
- 1–13 хвилин. Кожен учасник по черзі відповідає на три питання (про них — нижче). На людину — не більше 2 хвилин. Якщо тема потребує обговорення, вона йде в «паркінг».
- 13–15 хвилин. Фасилітатор озвучує зафіксовані блокери та призначає парні обговорення (після стендапу) для тих, хто взаємодіє за задачами.
Типові помилки формату
- Обговорення замість звіту. Якщо розробник каже «я не впевнений, який підхід кращий для PDA (Program Derived Address)», фасилітатор зупиняє: «Записую в паркінг, після стендапу розберемо з архітектором».
- Відсутність фасилітатора. Без людини, яка стежить за часом і напрямком, стендап перетворюється на 40-хвилинну розмову.
- Запізнення учасників. Стендап починається точно в призначений час, навіть якщо когось немає. Пропущена людина отримує запис або текстовий самарі.
Частота
У хакатоні, де тривалість сягає від 24 годин до кількох тижнів, оптимальна частота — щодня, у фіксований час. Для 24-годинних форматів замість одного стендапу можна робити три контрольні точки: старт дня, середина, вечірній чек-ін перед сном.
Що повідомляти: що зробив, що планую, що блокує
Класична трійка питань працює в хакатоні краще за будь-які альтернативи, але з важливим уточненням: кожна відповідь має бути прив'язана до конкретної завдання з трекера, а не до абстрактної діяльності.
Що зробив
Не «писав смарт-контракт», а «завершив завдання #12: базова структура Anchor-програми з двома інструкціями». Якщо завдання не закрита — назвати конкретний прогрес: «зробив 3 з 5 кроків із завдання #14».
Що планую
Не «продовжувати розробку», а «до наступного стендапу планую завершити завдання #14 і розпочати #15 — інтеграцію з RPC-провайдером». Фокус на тому, що буде зроблено до наступної синхронізації.
Що блокує
Це найважливіша частина. Блокер — це не «мені важко» чи «я не впевнений». Блокер — це конкретна перешкода: «не можу деплоїти програму на devnet — отримую помилку з RPC-ендпоінту, потрібен хтось із досвідом налаштування Anchor CLI» або «чекаю на дизайн-макет картки NFT, щоб верстати фронтенд».
Критерій якісної відповіді
Якщо після відповіді учасника інший член команди не може однозначно сказати, чи просунувся проєкт до демо — відповідь була недостатньо конкретною.
Як вести загальний трекер завдань
Стендап не працює без єдиного джерела правди. Усі завдання, про які говорять на стендапі, мають бути в трекері. Усі завдання з трекера мають бути озвучені на стендапі.
Базова структура дошки
- Backlog. Усе, що потрібно зробити, але ще не взято в роботу. Формулювання завдань — конкретні: не «фронтенд», а «сторінка підключення гаманця з кнопкою Connect Wallet».
- In Progress. завдання, за які зараз відповідає конкретна людина. У хакатонній команді в цьому стовпці має бути не більше завдань, ніж учасників, інакше це сигнал про розпорошення.
- Done. Завершені завдання. Переміщуються сюди тільки за умови, що результат можна продемонструвати (скомпільований код, задеплоєний контракт, працююча кнопка).
- Blockers. Окремий стовпець або маркер на завдання. Усе, що тут, — пріоритет для обговорення після стендапу.
Правила ведення трекера
- Кожна завдання має одного відповідального, а не «команду».
- Оцінка часу не обов'язкова для хакатону, але пріоритетність — так. завдання на критичному шляху до демо мають бути позначені.
- Трекер оновлюється до стендапу, а не під час нього. Стендап — для озвучення, а не для переписування дошки.
Типова помилка
Вести трекер «в голові» або в розрізнених чатах. Якщо половина завдань у Notion, половина в Telegram-нотатках, а ще щось на стікерах — стендап перетворюється на спробу згадати, хто що робив.
Як вирішувати конфлікти та блокери в команді
У хакатоні конфлікти найчастіше виникають не через особистості, а через розбіжність у пріоритетах, технічних рішеннях або розподіл ресурсів. Стендап — це місце, де такі проблеми стають видимими.
Алгоритм роботи з блокером
- Фіксація на стендапі. Учасник озвучує блокер конкретно: хто блокує, що саме потрібно, чому не можна обійти.
- Призначення відповідального. Фасилітатор прямо запитує: «Хто може допомогти з цим до [час]?» Якщо ніхто — блокер піднімається на рівень всієї команди для перерозподілу пріоритетів.
- Парне обговорення. Після стендапу зацікавлені учасники зустрічаються на 10–15 хвилин для вирішення. Якщо за 15 хвилин рішення не знайдене — це сигнал для зміни підходу (спрощення завдання, пошук альтернативи, відмова від фічі).
- Контроль на наступному стендапі. Блокер обов'язково фігурує в наступній відповіді: «блокер знято» або «блокер досі актуальний, ось що спробували».
Конфлікти пріоритетів
Ситуація: дизайнер робить анімації, а розробнику потрібен базовий UI для інтеграції. На стендапі це проявляється як блокер розробника. Рішення приймається не шляхом дискусії «що важливіше», а через посилання на спільну мету: «Що нам потрібніше для демо — красива анімація чи працюючий флоу транзакції?». Фасилітатор фіксує рішення в трекері.
Технічні суперечки
Якщо два розробники мають різні погляди на архітектуру, стендап не є місцем для дебатів. Фасилітатор фіксує: «Є дві пропозиції щодо структури PDA. Після стендапу ви 15 хвилин обговорюєте і приймаєте рішення. Якщо не зійдетеся — я вирішу як фасилітатор, щоб команда рухалася далі». У хакатоні рішення, прийняте зараз, краще за ідеальне рішення, яке так і не було реалізоване.
Інструменти для асинхронної комунікації
Стендап покриває синхронну частину, але в хакатонній команді завжди є питання, які не можуть чекати до наступної зустрічі. Асинхронна комунікація має бути структурованою, інакше вона створює шум і ховає важливі повідомлення.
Канали комунікації
- Загальний канал команди. Для оперативних питань, які не є блокерами: «де лежить файл», «хто бачив останній лог». Усі учасники тут, але не всі повідомлення вимагають відповіді.
- Канал блокерів. Тільки для повідомлень формату «зупинився, потрібна допомога». Правило: повідомлення тут завжди отримує відповідь протягом 30 хвилин. Якщо ніхто не відповів — це сигнал підняти тему на екстреному дзвінку.
- Приватні парні чати. Для обговорення конкретної завдання між двома учасниками. Результат обговорення обов'язково дублирується в трекер.
Правила асинхронного спілкування
- Ніяких голосових повідомлень у загальному каналі — вони не пошукові, їх не можна швидко просканувати.
- Кожне повідомлення про проблему містить: що робив, що очікував, що отримав, скріншот або лог. Без цього — це не блокер, а скарга.
- Тегування конкретної людини, а не «хтось допоможіть». Невизначене звернення дорівнює відсутності звернення.
- Фіксація рішень. Якщо в чаті прийнято технічне рішення, воно одразу переноситься в трекер або спільний документ.
Типова помилка
Використовувати один загальний чат для всього: від мемів до критичних блокерів. Через годину активного обговорення важливе повідомлення тонне серед десятків непотрібних, і блокер залишається непоміченим.
Наступний крок: дотримання плану спринту
Стендап дає інформацію, трекер фіксує завдання, але результат залежить від того, чи виконується план між синхронізаціями. Перехід від стендапу до реального виконання вимагає трьох елементів.
Чіткий фокус дня
Після кожного стендапу кожен учасник має розуміти свою одну-дві головні завдання на день. Якщо людина має п'ять завдань «in progress» — це червоний прапор. Фасилітатор має допомогти скоротити фокус до того, що критично для демо.
Проміжні чек-іни
Для команд, що працюють віддалено, корисно додати один текстовий чек-ін посередині дня: коротке повідомлення в канал блокерів з одним реченням — «на треку» або «зупинився на [проблема]». Це дозволяє не чекати наступного стендапу, щоб виявити відставання.
Вечірній самарі
Наприкінці робочого дня (або перед сном у 24-годинному форматі) фасилітатор оновлює трекер і формує коротке резюме: що зроблено, що не встигли, що переноситься на наступний день. Це резюме стає стартовою точкою для наступного стендапу.
Коли стендапи, трекер і асинхронна комунікація працюють як єдина система, команда отримує головну перевагу в хакатоні — здатність швидко реагувати на проблеми і впевнено рухатися до працюючого демо, а не сподіватися, що «все зійдеться в останню ніч».