Hackathon Projesi Nasıl Sunulur? Beş Dakikalık Yapı

Sunum neden bu kadar belirleyici

Hackathonda 48 saat kod yazılıyor, jürinin karşısında ise üç ile beş dakika kalıyor. Bu oran acımasız görünüyor ama mantığı var: jüri projeyi kullanmıyor, anlatıldığı kadarını görüyor.

Sonuçlara bakınca tekrar eden bir tablo çıkıyor: teknik olarak en iyi proje her zaman kazanmıyor. Kazanan, problemi net kuran ve çözümünün çalıştığını gösterebilen takım oluyor.

Bu bir haksızlık değil. Gerçek hayatta da ürünü yatırımcıya, yöneticiye ya da müşteriye anlatan kişi aynı sınırla karşılaşıyor.

Beş dakikalık yapı

İşleyen hackathon sunumu neredeyse her zaman aynı iskelete oturuyor:

Bu tablodaki en büyük dilim demo ve bu tesadüf değil. Anlatılan çözüm ile gösterilen çözüm arasındaki fark, jürinin en çok dikkat ettiği şey.

Problemle başlamak

Sunumların çoğu şöyle başlıyor: "Biz X uygulamasını geliştirdik." Bu cümle, dinleyiciyi hiçbir yere bağlamıyor — henüz neden umursaması gerektiğini bilmiyor.

İşleyen açılış, jürinin tanıdığı bir durumu anlatıyor:

Bu iki cümle, problemi somut ve tanınabilir kıldı. Ardından gelen "biz bunu şöyle çözdük" cümlesi artık bir yere oturuyor.

Uydurma sayı vermekten kaçınmak gerekiyor. "Öğrencilerin %73'ü bu sorunu yaşıyor" gibi kaynağı olmayan bir istatistik, jüride güven kaybettiriyor — soru sorulduğunda cevap veremiyorsunuz. Somut bir gözlem, uydurma bir orandan daha ikna edici.

Demo

Demo, sunumun en riskli ve en değerli parçası. Riskli çünkü canlı gösterilen her şey bozulabiliyor; değerli çünkü çalıştığını gösteren tek kanıt.

Pratik kurallar:

• Ekran kaydı alın. Canlı demo tercih edilir ama kaydı yedekte tutmak, internetin ya da sunucunun çöktüğü durumda sunumu kurtarıyor.
• Tek bir akış gösterin. Uygulamanın her ekranını gezmek dakikaları yiyor. Baştan sona tek bir senaryo, on ekrandan daha etkili.
• Veriyi önceden hazırlayın. Demo sırasında form doldurmak zaman kaybı; örnek veriyle dolu bir ekran gösterin.
• Küçük ekranı büyütün. Projeksiyonda telefon arayüzü okunmuyor; yakınlaştırılmış görüntü kullanın.

Demo bozulursa panik yapmadan kayda geçmek en profesyonel davranış. Jüri, bozulan demodan çok bozulunca donan takımı olumsuz not ediyor.

Teknik kısmı ne kadar anlatmalı

Takımların en sık düştüğü ikinci tuzak, sunumun yarısını mimariye ayırmak. Hangi kütüphaneyi kullandığınız, jürinin puanladığı beş kriterden yalnızca birine giriyor.

Teknik bölüm için otuz saniye yeterli ve şu üç şeyi söylemeli:

1. Neyi kendiniz yazdınız, neyi hazır aldınız.
2. En zor kısım neydi ve nasıl çözdünüz.
3. Ölçeklenirse ne değişir.

İkinci madde, teknik jüri üyesinin en çok ilgilendiği kısım. "Bu veriyi gerçek zamanlı işlemek için şunu yaptık" cümlesi, kullanılan teknoloji listesinden daha çok şey anlatıyor.

Kim konuşmalı

Tek kişi sunmalı. Üç kişinin sırayla konuştuğu sunumlarda geçişlerde zaman kaybediliyor ve anlatım bütünlüğü bozuluyor.

Ancak demo bölümünde ikinci bir kişinin ekranı yönetmesi işe yarıyor: anlatan kişi konuşurken, diğeri tıklıyor. Bu ikili, tek kişilik sunumdan daha akıcı ilerliyor.

Takımın tamamı sahnede durabilir; konuşmak zorunda değil. Soru-cevapta ilgili kişinin cevap vermesi doğal.

Soru-cevap

Jüri soruları çoğunlukla üç başlıkta toplanıyor:

• "Bu zaten var, farkınız ne?" — Hazırlıklı olunması gereken soru. Benzer çözümleri bilmemek, en çok puan kaybettiren cevap.
• "Nasıl para kazanır / sürdürülür?" — Kurumsal jürilerde sık. "Düşünmedik" demek yerine bir varsayım söylemek daha iyi.
• "Bunu gerçekten siz mi yaptınız?" — Kod deposunun geçmişi bu soruyu kendiliğinden cevaplıyor.

Bilmediğiniz bir soruya "bilmiyorum, bakmadık" demek kabul edilebilir; uydurmak değil. Jüri üyeleri alanın içinden geliyor ve uydurma cevabı fark ediyor.

Son bir saat

Kod dondurma saatinden önceki son saat, kod yazmaya değil sunuma ayrılmalı. Bu, takımların en zor uyguladığı kural — son dakikaya kadar özellik eklemek cazip geliyor.

Son saat planı:

1. Demo senaryosunu bir kez baştan sona deneyin.
2. Ekran kaydını alın.
3. Sunumu yüksek sesle bir kez prova edin ve süreyi tutun.
4. Kim ne söyleyecek, netleştirin.

Prova yapmayan takımlar süreyi neredeyse her zaman aşıyor ve mikrofon kapatılınca sunum yarım kalıyor.

Slaytın kendisi

Hackathon sunumunda slayt, anlatımın yerine geçmiyor; arkasında duruyor. Beş dakikalık bir sunum için altı-yedi slayt üst sınır.

İşleyen sıra: problem (1), kime ait (1), çözüm ekranı (1-2), nasıl çalışıyor (1), sırada ne var (1), takım (1).

En sık yapılan hata, slayta konuşulacak metni yazmak. Jüri okumaya başladığı anda konuşmacıyı dinlemiyor ve ikisi aynı anda olmuyor. Slaytta cümle değil, kısa ifade ve görsel olmalı.

İkinci hata, mimari şemasını büyük bir slayta koymak. Kutulardan ve oklardan oluşan diyagram, beş dakikalık sunumda anlaşılmıyor; teknik jüri sorarsa yedek slayt olarak sonda tutulabilir.

Sunumdan sonra proje ölmesin

Hackathon bittiğinde çoğu proje o gece kapanıyor. Oysa sunum, projenin sonu değil portföye giriş anı.

Etkinlik biter bitmez yapılması gereken üç şey var ve toplamda yarım saat sürüyor:

• Kod deposunu düzenleyin. Kısa bir açıklama dosyası, ekran görüntüleri ve nasıl çalıştırılacağı. Boş bir depo, mülakatta bağlantı paylaşıldığında hiçbir şey anlatmıyor.
• Demo kaydını saklayın. Proje bir daha çalışmasa bile kayıt duruyor; özgeçmişte ve başvurularda kullanılıyor.
• Takım arkadaşlarınızla bağlantı kurun. İki gün baskı altında birlikte çalıştığınız kişiler, sonraki yıllarda en gerçekçi referanslarınız.

Derece alan projelerin bir kısmı sonrasında gerçek ürüne dönüşüyor; dönüşmeyenler de mülakatta anlatılacak somut bir deneyim bırakıyor. Kaydedilmeyen proje ise iki hafta sonra hatırlanmıyor.

Sık sorulanlar

Slayt gerekli mi? Az sayıda slayt yeterli: problem, çözüm, ekran görüntüsü, takım. Metinle dolu slayt, dinleyiciyi okumaya yönlendiriyor ve konuşmacıyı dinlemiyor.

Projeyi bitiremediysek ne yapmalı? Bitmiş kısmı gösterin ve bitmeyeni açıkça söyleyin. "Şu kısım çalışıyor, şu kısım tasarım aşamasında" cümlesi, çalışmayan bir demoyu çalışıyormuş gibi göstermekten çok daha iyi karşılanıyor.

Sunum dilini nasıl seçmeliyiz? Jürinin diline göre. Karışık jürilerde slaytları İngilizce, anlatımı Türkçe tutmak yaygın ve işleyen bir çözüm.

Özet

Hackathon sunumu, 48 saatlik işin beş dakikaya sığdırılması değil; jürinin karar verebilmesi için gereken asgari bilginin doğru sırayla verilmesi. Problemle başlanmalı, en büyük dilim demoya ayrılmalı, teknik ayrıntı kısa tutulmalı ve son bir saat kod yerine provaya harcanmalı. Bitmemiş proje dürüstçe anlatıldığında, abartılmış bir demodan daha iyi puan alıyor.