Hackathon sunumu, genellikle 3 ila 5 dakika içinde bir problemi, geliştirilen çalışan prototipi ve teknik uygulanabilirliği jüriye aktarma görevidir. Genel kurumsal sunumlardan farklı olarak hackatonda uzun kurumsal arka plan yerine; net problem tanımı, çalışan demo, yazılım mimarisi ve kısıtlı sürede üretilen somut değer öne çıkar. Zamanı aşmamak ve canlı sunum anındaki teknik riskleri yönetmek başarının temelidir.
Hackathon Sunumunun Genel Sunumlardan Temel Farkları
Standart bir iş sunumunda pazar araştırması ve kurumsal vizyon geniş yer tutarken, hackathon jürisi somut çıktıya bakar. 24 ila 48 saatlik maratonda üretilen kodun, tasarımın veya veri modelinin gerçekten çalışıp çalışmadığı sorgulanır.
Klasik slayt dizilimleri yerine demo merkezli bir kurgu yapılmalıdır. Bir hackathon sunumunda jüri değerlendirme kriterleri çoğunlukla problem tanımı, yenilikçilik, teknik zorluk düzeyi ve uygulama başarısı eksenindedir. Benzer bir teknik akış disiplini gerektiren web sitesi projesi sunumu hazırlama adımlarında olduğu gibi, kullanıcı deneyimi ve işlevsellik doğrudan eşleştirilmelidir.
Ön Hazırlık ve Sunum Ön Koşulları
Hackathon salonlarında internet erişimi sıklıkla yavaşlar veya kesintiye uğrar. Bu nedenle sunum öncesinde teknik ortamınızı yedeklemeniz şarttır:
- Prototipin yerel ortamda (localhost) veya çevrimdışı çalışabilen bir yerel sunucuda hatasız çalıştığını doğrulayın.
- Canlı demoda gösterilecek kritik akışın ekran kaydını (en fazla 45 saniyelik sessiz video veya GIF) slayt içine yedek olarak gömün.
- Görüntü bağlantı adaptörlerini (HDMI, USB-C) sunum cihazınızda test edin ve ekran çözünürlüğünü projeksiyona göre ayarlayın.
- Jüriye yönelik rol dağılımı yapın; kimin konuşacağını, demoda fareyi ve klavyeyi kimin yönlendireceğini önceden belirleyin.
Yarışma kılavuzlarında belirtilen kuralları ve süre kısıtlamalarını resmi belgelerden doğrulamak gerekir; örneğin eğitim odaklı etkinlik planlarında belirtilen yapısal yönergeleri incelemek için Kaynak kaynağındaki deneyimsel öğrenme çerçevelerine bakabilirsiniz.
3-5 Dakikalık İdeal Sunum Akışı
Başarılı bir hackathon sunumu saniyesi saniyesine planlanmalıdır. 3 dakikalık standart bir sunum için önerilen zaman dağılımı şöyledir:
- İlk 30 saniye: Problem ve Hedef Kitle. Hangi acı noktası çözülüyor? Neden mevcut araçlar yetersiz kalıyor?
- 30-60. saniyeler: Çözüm Yaklaşımı. Ürününüz bu sorunu nasıl gideriyor ve temel yenilikçi önerisi ne?
- 60-120. saniyeler: Canlı Demo. Prototipin temel senaryosunu baştan sona tek bir iş akışında gösterin.
- 120-150. saniyeler: Mimari ve Teknik Zorluk. Hangi kütüphaneler, modeller veya API'ler kullanıldı? Karşılaşılan teknik engel nasıl aşıldı?
- 150-180. saniyeler: Etki, Gelecek Planı ve Kapanış. Proje ileride nereye evrilecek?
Kullanıcı yolculuğunu netleştirmek adına, görsel ekranların ve arayüz kararlarının mantığını arayüz tasarımı sunumu prensipleriyle hizalamak jürinin projeyi hızla kavramasını sağlar.
Örnek Vaka Çalışması: NöbetRota Projesi
Aşağıdaki örnek, kurgusal bir sağlık lojistiği hackathonu için hazırlanmış sunum taslağıdır:
- Problem Slaytı: Acil servislerde vardiya planlaması manuel yapıldığında haftada 14 saatlik zaman kaybı ve dengesiz nöbet dağılımı oluşuyor (kurgusal örnek veri).
- Çözüm Slaytı: NöbetRota, hekimlerin izin taleplerini ve yasal dinlenme sürelerini kural tabanlı bir algoritmayla eşleştiren otomatik çizelgeleme aracıdır.
- Demo Akışı: Ekrana üç hekim profili ve kısıtlar girilir; 'Çizelge Oluştur' düğmesine basılır ve 2 saniye içinde çakışmasız haftalık takvim üretilir (kurgusal test akışı).
- Mimari Slaytı: FastAPI arka uç, React ön yüz ve açık kaynaklı kısıt çözücü kütüphane entegrasyonu.
- Kapanış ve Gelecek: Hastane bilgi yönetim sistemleri entegrasyonu ve mobil bildirim altyapısının eklenmesi.
Üniversite tabanlı hackathon programlama yaklaşımlarında da vurgulandığı üzere, katılımcıların net bir problem alanı etrafında toplanması esastır; detaylı modelleme örnekleri için Kaynak kılavuzuna göz atabilirsiniz.
Canlı Demo Sırasında Dikkat Edilmesi Gerekenler
Canlı demo, jüriye çalışan bir prototipiniz olduğunu kanıtlayan en kritik andır. Bu aşamada karmaşık ve uç senaryoları denemek yerine, sistemin ana başarı yolunu (happy path) baştan sona eksiksiz göstermelisiniz. Boş bir veritabanı veya doldurulmamış form alanları sunumun ritmini bozar. Bu nedenle önceden temiz, mantıklı ve gerçekçi verilerle doldurulmuş test hesapları hazırlayın.
Demoyu gerçekleştiren kişi ile sunumu yapan konuşmacının rolleri kesinlikle ayrılmalıdır. Konuşmacı ekrandaki adımı anlatırken, diğer ekip üyesi arayüzde doğru düğmelere tıklamalıdır. İki eylemin aynı kişi tarafından yapılmaya çalışılması konuşmada duraksamalara ve süre kaybına yol açar.
Teknik Mimari ve Altyapı Slaytının Kurgusu
Mimari slaytında tüm kaynak kod satırlarını veya karmaşık veritabanı tablolarını listelemek teknik jüriyi bile yorar. Bunun yerine tek bir bakışta anlaşılan blok diyagramlar tercih edilmelidir:
- İstemci Katmanı: Ön yüz kütüphanesi veya mobil arayüz teknolojisi.
- Sunucu ve API Katmanı: İstekleri karşılayan arka uç çatısı ve kimlik doğrulama adımları.
- Veri ve Yapay Zeka Katmanı: Kullanılan veritabanı motoru, makine öğrenmesi modeli veya harici API entegrasyonları.
Hackathon kapsamında sıfırdan yazdığınız kısımlar ile hazır kullandığınız harici kütüphaneleri dürüstçe ayrıştırın. Jüri üyeleri hazır kütüphane kullanımına değil, onların nasıl birleştirildiğine ve özgün mühendislik katkısına odaklanır.
Yaygın Hatalar ve Kriz Yönetimi
Hackathon sahnelerinde en sık düşülen hataların başında demonun sahnede çökmesi gelir. Canlı demo çalışmadığında kod ekranını açıp hata ayıklamaya çalışmak sürenizi tamamen tüketir. Böyle bir durumda paniklemeden, slaytınızdaki önceden kaydedilmiş yedek video kaydını devreye sokmalı ve akışı sözlü olarak tamamlamalısınız.
İkinci yaygın hata, slaytlara uzun teknik metinler yığmaktır. Jüri aynı anda hem metni okuyup hem sizi dinleyemez. Metin yerine mimari şemaları ve net ekran görüntülerini kullanın.
Üçüncü hata ise süreyi aşmaktır. Süre bittiğinde mikrofon kapatılabilir ve demonuzu hiç gösterememiş olabilirsiniz. Slayt hazırlarken araçların şablon yeteneklerinden hesap planınız dahilinde yararlanabilir, ancak her slaytın konuşma süresini kronometreyle mutlaka elle doğrulamalısınız.
Hackathon Sunum Kontrol Listesi
- Sunum süresi etkinliğin belirlediği sınıra (örneğin 3 dakikaya) tam oturacak şekilde kronometreyle prova edildi mi?
- Canlı demo senaryosu için temiz bir test verisi ve açık sekmeler hazırlandı mı?
- Ağ bağlantısının kesilmesi veya sunucu çökmesi ihtimaline karşı yerel ekran kaydı slayt içinde yedeklendi mi?
- Mimari şemasında kullanılan bileşenler açık ve anlaşılır şekilde görselleştirildi mi?
- Sunum dosyası olası teknik aksaklıklara karşı yerel diske veya taşınabilir belleğe aktarıldı mı?
Sıkça Sorulan Sorular
Canlı demo yapmak şart mı, yoksa sadece video göstersek yeterli olur mu?
Çoğu hackathonda çalışan bir prototip görmek esastır. İmkan varsa canlı demo tercih edilir çünkü jürinin projenin çalıştığına dair güvenini artırır. Ancak ağ bağlantısının güvenilmez olduğu veya donanım kurulumunun zor olduğu durumlarda yüksek kaliteli ve montajsız bir ekran kaydı, sahnede çökme riski almaktan daha güvenli bir yöntemdir.
Sunumda teknik ayrıntılara mı yoksa iş modeline mi daha çok yer verilmeli?
Hackathonun temasına göre değişir. Geliştirici odaklı bir hackathonda mimari, veri akışı ve algoritma performansı ağırlıklı olmalıdır. Girişimcilik temalı bir yarışmada ise çözülen problemin büyüklüğü ve pazar potansiyeli eşit derecede önem taşır. Etkinlik yönergelerindeki puanlama tablosunu inceleyerek dengeyi kurmalısınız.
← Bloga dön
