Англійська мова для Hackathon Pitches: Як представити свій проект суддям

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

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

Створена на основі відомого фільму «Пікассо»

Більшість хакатонів тривають 2-5 хвилин. Найкращі з них слідують жорсткій, передбачуваній структурі, яку судді цінують, тому що це робить оцінку легкою.

3-х хвилинна версія (англ. 3-minute version)

Крюк (20 секунд) Відкрити з повідомленням про проблему, яке створює негайну зв’ язок.

** Проблема (30 секунд) ** Розширити проблему з конкретним, людським сценарієм.

Рішення (45 секунд) Повідомте про свій проект і поясніть, що він робить.

Демонстрація (45-60 секунд) Показувати робочий продукт — це найважливіша частина.

Технічні моменти (20 секунд) Назвіть коротко ключові технології.

Вплив і майбутнє (20 секунд) Чим це може стати? Який потенціал?

Закрити (10 секунд) Запам’ятний фінал і вступ команди.

Перші 20 секунд

Судді вирішують, чи зацікавлені вони в перші 20 секунд. Не починайте з “Привіт, ми команда Nexus і сьогодні ми представимо…” — це марна трата часу.

Відкрийте з ** проблемним твердженням, яке пов’ язує емоційно або інтелектуально: **

“Кожного року 3 мільйони розробників пересилають код з твердими даними для реєстрації в публічні сховища GitHub. Більшість з них не усвідомлюють цього, поки не приходить рахунок за AWS. ”

“Моя бабуся не може використовувати мобільне застосування свого банку. Шрифт занадто малий, контраст занадто низький, і не підтримується жодний зчитувач екрану. Вона не є крайнім випадком — 15 % населення Великої Британії має порушення зору.»

• “Ви зневаджуєте інциденти в процесі виробництва о 2 годині ранку. У вас открыто 40 вкладок браузера, пять потоков Slack, и три человека кричат разные инструкции. Ми побудували інструмент, який хотіли б мати тієї ночі»

** Формули прив’ язки, які працюють: **

• ** Статистика: ** *“X% [людей] стикаються з [проблемою]…” *
• Історія: “Попереднього місяця, [схожий сценарій]…”
• Питання: “Ти коли-небудь намагався…”
• Парадокс: “Ми витрачаємо мільярди на безпеку, але…”

Опис проблеми

Після того, як ви встановили гачок, надайте проблемі ще один шар глибини перед тим, як представити ваше рішення. Використовувати конкретний, конкретний мова:

** Неясне: ** * “Є проблема з безпекою даних.” *

** Конкретно: ** * “Коли розробник випадково затверджує API-ключ до публічного сховища, середній час виявлення становить 4 години - і нападники постійно сканують GitHub, тому компроміс часто відбувається протягом декількох хвилин.” *

** Перехідні фрази до розділу задачі: **

• “Проблема в тому…”
• “Ось що відбувається зараз…”
• “Текущие решения не оправдывают ожиданий, потому что…”
• “Команды застряли с…”

Розглянемо його приклад

Це поворотний момент. Ясно вкажіть, що ви переходите від проблеми до рішення:

** Перехідні фрази: **

• “Тому ми побудували [Назва проекту].”
• • “Ми створили [Назва проекту] — інструмент, який…” *
• • “Знайомство з [Назва проекту].” *
• • « Наша відповідь — [Назва проекту]. » *

Потім вкажіть опис у одному реченні, який зрозумілий для судді, який не володіє технічними знаннями:

“Sentinel — це дія GitHub, яка сканує кожен звіт на предмет виявлених секретів і блокує відсилання перед тим, як воно досягне публічного сховища.”

“AccessAI автоматично перевіряє будь-яку веб-програму на відповідність стандарту доступності WCAG 2.1 і генерує звіт про виправлення за 60 секунд.”

** Одноречення: ** “[Назва продукту] це [що це таке] що [що це робить] для [кому це допомагає].”

Розповідає про Live Demo

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

Демонстрація принципів наррації

** Розповісти про подорож користувача, а не про інтерфейс: **

Погане: * “Я натискаю на кнопку тут… і зараз вона завантажується… добре, тож тут ви можете побачити панель приладів…” *

Добре: “Розробник відсилає звіт. Sentinel запускає негайно - ви можете бачити, як він сканує в реальному часі. Він виявляє ключ AWS на рядку 47, блокує відсилання і надсилає докладне попередження безпосередньо у запиті на відсилання. Розробник повідомляється перед тим, як ключ коли-небудь стає публічним. “

Корисні фрази для демонстрації розповіді

Настройка сцены:

• • “Уявіть, що ви [тип користувача]…” *
• • “Дозвольте мені показати вам поток з точки зору користувача.” *
• • “У цій демонстрації, наш користувач хоче…” *

Відображення моменту цінності:

• “Це ключовий момент - дивіться, що відбувається, коли…”
• “Зауважте, як автоматично…”
• “Це те, що зазвичай забирає [час/усі зусилля] — і це забирає у нас [менше].”

** Якщо щось завантажується: **

• “Пока это проходит, я скажу…”
• “Це зазвичай займає дві секунди — дозвольте мені перейти до результату.”

** Обробка помилки живого демо: **

Технічні неполадки трапляються. Заспокойся. Судді розуміють. Резервна копія:

• “Схоже, у нас проблема з’ єднання — я перейду до записаного демо. [перемикач] Як ви можете побачити тут, повний поток працює точно так, як описано…” *

• “Сервіс Live щойно перестав працювати — це, власне, ідеальний тест нашого рівня стійкості. Дозвольте мені показати вам послідовність знімків екрану замість цього.”*

Спокій під час невдачі часто вражає суддів більше, ніж бездоганний демо.

Розділ «Технічні характеристики»

Судді на технічних хакатонах хочуть розуміти інженерні рішення. Тримайте це коротким — 15- 20 секунд — і зосередьтеся на рішеннях, які не були очевидними або вражаючими:

** Що підкреслити: **

• Незвичайний архітектурний вибір з ясною причиною
• Бібліотека або API, яка уможливила щось, що раніше було складним
• Результат роботи, що демонструє технічну якість
• Компонент AI/ ML використовується розумним чином

** Фрази: **

• “З технічної точки зору, ми використовуємо [технологію], тому що…”
• “Цікавим інженерним викликом було…, що ми розв’язали…”
• “Ми побудували це на [стеку] — ключовим вибором було використання [X] замість [Y], що дало нам [вигоду].”

** Чого уникати: **

• Перелік всіх технологій у вашому стеку
• Технічні пояснення, які не технічні судді не можуть слідувати
• Все, что требует более 20 секунд для объяснения

Закриття майданчика

Завершення так само важливе, як і кріплення. Завершуйте з впевненістю і перспективним заявою:

** Типи сильних закривів: **

Вигляд близько:

• “Зараз Sentinel захищає затвердження. Далі, він моніторить розгорнуті середовища в реальному часі. Ми віримо, що кожна команда заслуговує на безпеку, яка працює автоматично — тому розробникам ніколи не потрібно думати про це.»*

Удар близько:

• “Якщо ми зможемо запобігти хоча б 1% витоків даних на GitHub, ми захистимо десятки тисяч компаній від порушень, яких вони ніколи б не очікували. Це те, що ми будуємо.»*

** Команда закрита: **

“Ми [Ім’я], [Ім’я] і [Ім’я] — і ми створили це, тому що ми жили з цією проблемою. Ми [Назва проекту] і ми б любили ваші запитання.”

** Не закінчуйте на: **

• “Вот и всё.”
• “Так что… да.”
• • “Я думаю, це все?” *
• “Мы закончили.”

Розгляд справ суддями

Після цієї частини йде Q&A — часто більш розкривальний, ніж сама частина.

Професійний час купівлі

Если вам нужно подумать:

• “Це чудове питання — дозвольте мені переконатися, що я відповім на нього правильно.”
• “Я хочу дать вам точную ответ…”
• • « Гарна думка — чи не могли б ви пояснити, що ви маєте на увазі під [X]? » *

Відповідає на важкі питання

** « Чим це відрізняється від [існуючого інструменту]? » **

• “Чудове питання. [Існуючий інструмент] виконує [X]. Наш ключовий диференціатор — [Y], який вирішує [спеціальну проблему], яку [інструмент] не вирішує. Особливо…»

** « Ви дійсно збудували це або використовували існуючу бібліотеку? » **

“Обидві — ми використовували [бібліотеку] для [компоненту], але ядро [спеціфічна логіка] є оригінальним кодом, який ми написали під час хакатону. Інтеграція була важкою частиною.»

“Що б ти зробив з ще трьома місяцями?”

“Нашим пріоритетом буде [X]. Ми знаємо, що поточне рішення має [обмеження] — з більшим часом, ми б вирішили це за допомогою…”

“Яка модель бізнесу?”

“У контексті цього хакатону, ми зосередилися на технічному дослідженні концепції. Але природний шлях монетизації є [freemium/API доступ/SaaS], схожий на те, як працює [порівнянний продукт].”

Якщо не знаєш відповіді

• “Честно кажучи, ми ще не до кінця пропрацювали це - це була 24-годинний збір. Те, що я можу вам сказати, це те, що ви знаєте, і [X] буде нашою початковою точкою для дослідження цього»

Чесність щодо обмежень, донесена з впевненістю, поважає. Блеф не брехун.

Ключеві моменти

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

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