Hackathonların karanlık yüzü

Hackathonların karanlık yüzü

В üçlemenin önceki bölümü Hackathon'lara katılmak için çeşitli nedenlere baktım. Pek çok yeni şey öğrenme ve değerli ödüller kazanma motivasyonu pek çok kişinin ilgisini çeker, ancak çoğu zaman organizatörlerin veya sponsor şirketlerin hataları nedeniyle etkinlik başarısızlıkla sonuçlanır ve katılımcılar memnuniyetsiz ayrılır. Bu tür hoş olmayan olayların daha az yaşanması için bu yazıyı yazdım. Üçlemenin ikinci kısmı organizatörlerin hatalarına ayrılmıştır.

Gönderi şu şekilde organize edilmiştir: Başlangıçta olay hakkında konuşuyorum, neyin yanlış gittiğini ve bunun neye yol açtığını (veya uzun vadede neye yol açabileceğini) açıklıyorum. Daha sonra olup bitenlere ve organizatörlerin yerinde olsaydım ne yapacağıma dair değerlendirmemi aktarırım. Tüm etkinliklere katıldığım için organizatörlerin gerçek motivasyonunu ancak tahmin edebiliyorum. Sonuç olarak değerlendirmem tek taraflı olabilir. Bana hatalı gelen bazı noktaların aslında bu şekilde tasarlandığını göz ardı etmiyorum.

Belli bir noktada okuyucu, yazarın kavgadan sonra yumruklarını sallamaya karar verdiğini düşünebilir. Ama sizi temin ederim ki durum böyle değil. Listelenen hackathonların bazılarında ödül almayı başardım, ancak bu, etkinliğin kötü organize edildiğini söylememize engel değil.

Organizatörlere ve katılımcılara olan saygımızdan dolayı, gönderide belirli şirketlere atıf yapılmayacaktır. Ancak dikkatli bir okuyucu kimden bahsettiğimizi tahmin edebilir (ya da Google'ı).

1 Numaralı Hackathon. Katı sınırlar

Altı ay önce büyük bir telekom şirketi veri analizi üzerine bir hackathon düzenledi. Ödül fonu için 20 takım yarıştı. Etkinlikte, analiz için şirketin destek servisine yapılan çağrılar, sosyal ağlardaki faaliyetler ve kullanıcılar hakkında kodlanmış bilgiler (cinsiyet, yaş vb.) içeren bir veri seti sağlandı. Veri setinin en ilginç kısmı (kullanıcı mesajları ve operatör yanıtları (metin verileri)) oldukça gürültülüydü ve daha ileri çalışmalar için temizlenmesi gerekiyordu.

Organizatörler, sağlanan verilerle ilginç bir şeyler yapmak için bir görev belirlediler ve ağdan ek açık veri kümelerinin kullanılması veya verileri kendiniz ayrıştırmanız yasaklandı. Veri seti ile ilgili olmayan fikirlerin öne sürülmesi de yasaklandı. Ne yazık ki, sağlanan veriler oldukça "zayıftı": onlardan ilginç ürünler elde etmek zordu ve mentorlarla yapılan iletişimden, önerilen fikirlerin çoğunun halihazırda uygulandığı (veya yakın gelecekte uygulanacağı) açıkça ortaya çıktı. şirkette.

Sonuç olarak, ezici sayıda ekip (15 ekipten 20'i) chatbot'lar oluşturdu. Gösteriler sırasında bir takımın kararı öncekinden biraz farklıydı. Jüri üyelerinden biri dayanamayıp sahneye çıkan diğer ekibe sordu: "Ne oldu arkadaşlar, sizin de chatbot'unuz var mı?" Sonuç olarak üç ödülden birincilik ve ikincilik, chatbot yapmayan takımlara verildi.

Karşılaştırma için, uluslararası bir danışmanlık şirketinin iki yıl önce Zvezdochka şirketi için düzenlediği hackathon'u ele alalım. Zvezdochka şirketinin faaliyetlerinin ayrıntıları birçok hackathon katılımcısına yabancı olduğundan, etkinliğin başında organizatörler şirkette kullanılan metrikler hakkında konuştular. Bundan sonra, farklı türden altı veri seti sağlandı: metin, tablolar, coğrafi konum; tüm katılımcılar için manevra alanı vardı. Organizatörler ek veri setlerinin kullanımını yasaklamadı ve hatta bu tür girişimleri destekledi. Yarışmanın finallerinde, farklı çözümlere sahip on takım ana ödül için yarıştı ve tüm takımlar, kaliteli ürünler elde etme konusunda iyi bir potansiyele işaret eden (kısıtlama olmamasına rağmen) şirket tarafından sağlanan verileri kullandı.

Ahlâk

Katılımcıların yaratıcı akışını sınırlamaya gerek yoktur. Organizatör olarak materyalleri sağlamalı ve onların vizyonuna ve profesyonelliğine güvenmelisiniz. Bir hackathona katılıyorsanız, herhangi bir kısıtlama veya yasaklama sizi alarma geçirmelidir.Genellikle bu, zayıf organizasyonun kanıtıdır (gerçek hayattan bir örnek, bir yere çit yapıştırmak için sürekli bir istektir). Kısıtlamalarla karşılaşırsanız, çok fazla rekabetin olduğu bir havuzda proje oluşturmak zorunda kalacağınız gerçeğine hazırlıklı olun. Bu durumda, risk almak zorundasınız: Monoton projelerin akışından sıyrılmak için temelde yeni bir şey yapın veya alışılmadık bir "mükemmel özellik" sunun.

2 Numaralı Hackathon. İmkansız görevler

Amador'daki hackathon ilginç olacağa benziyordu. Büyük bir telefon üreticisi olan sponsor firma, etkinlik tarihinden 4 ay önce hazırlıklara başladı. Etkinliğin PR'ı sosyal ağlarda gerçekleştirildi; potansiyel katılımcıların bu etkinliğe seçilebilmeleri için teknik bir testi geçmeleri ve geçmiş projeleri hakkında yazmaları gerekiyordu. Ödül fonu oldukça büyüktü. Hackathon'dan birkaç gün önce mentorlar teknik bir oturum düzenlediler, böylece katılımcıların sektörün ayrıntılarını anlamaları için zamanları oldu.

Etkinliğin kendisinde, organizatörler 8 GB hacimli bir ekipman günlükleri veri seti sağladılar; görev, arızaların ikili bir sınıflandırmasıydı. Projeleri değerlendirme kriterleri hakkında konuştular - sınıflandırma kalitesi, özellik oluşturmada yaratıcılık, takım halinde çalışabilme yeteneği vb. Bu sadece kötü şans - 8 GB'lık "özellikler" için trende yalnızca 20 örnek ve testte 5 örnek vardı. Hackathon'un tabutuna son çivi çakılan verilerden geldi: Çarşamba günü alınan ekipman kayıtları, ekipmanın çalışmasında bir hata içeriyordu, ancak Perşembe günü oluşturulanlar bunu içermiyordu (bu arada, sadece iki takım bunu biliyordu ve her ikisi de deneyimli veri madencilerinin anavatanı olan Rusya'dandı). Testin gerçek etiketlerini bilmek bile cevabı belirlemeye yardımcı olmasa da, görev çözülemezdi. Organizatörler istenen sonucu elde edemediler; katılımcılar kötü tasarlanmış bir problemi çözmek için çok zaman harcadılar. Hackathon başarısız oldu.

Ahlâk

Görevlerin teknik incelemelerini yapın ve görevlerinizin yeterliliğini kontrol edin. Ön inceleme için fazla ödeme yapmak (bu durumda herhangi bir veri bilimci, bu sorunu çözmenin imkansız olduğunu hemen belirtecektir), daha sonra pişman olmaktan daha iyidir.

Bu durumda, boşa harcanan zaman ve paraya ek olarak şirket, potansiyel adaylar nezdinde güvenilirliğini kaybetti ve muhtemelen sonuçlar hakkında yazdı. Bu arada, sadece katılımcılar değil, şirket de başarılı sonuçlar hakkında yazmalı ve hackathon'u halkla ilişkiler açısından en üst düzeye çıkarmalı. Ne yazık ki, tüm şirketler bunu yapmıyor ve kendilerini yalnızca bir duyuru gönderisi ve Twitter'daki etkinlikten birkaç fotoğrafla sınırlıyor.

3 Numaralı Hackathon. Al ya da git

Ekibimiz yakın zamanda Amsterdam'da bir hackathon'a katıldı. Ben (yenilenebilir enerji kaynakları alanında) eğitim almış bir elektrik mühendisi olduğum için konu tam bize göreydi: enerji. Hackathon çevrimiçi olarak gerçekleştirildi: bize görevin bir açıklaması ve bunu tamamlamamız için bir ay verildi. Organizatörler, Amsterdam evlerinin enerji verimliliğinin artırılmasına yardımcı olacak bitmiş bir proje görmek istediler.

Elektrik tüketiminin tahmin edildiği bir proje yaptık (bundan önce bu konuyla ilgili bir yarışmaya katılmıştım ve burada okuyabileceğiniz sotaya yakın bir çözüm aldım) burada) ve güneş paneli ile üretim. Bu tahminlere dayanarak pil performansı optimize edildi (bu fikir kısmen yüksek lisans tezimden alınmıştır). Projemiz hem organizatörlerin talimatlarıyla (o zamanlar bize öyle geliyordu) hem de Amsterdam yönetiminin önümüzdeki birkaç yıl boyunca yenilenebilir enerji kaynakları alanındaki politikasıyla iyi bir uyum içindeydi.

Projelerin değerlendirilmesi sırasında birçok ekip gibi bize de müşterinin beklediğinin bu olmadığı söylendi ve ödül için yarışmak istiyorsak projeyi yeniden yapmamız gerektiği söylendi. Yenilgiyi kabul ederek hiçbir şeyi yeniden yapmadık. Katılan kırk takım arasında ilk 7'ye bile giremedik, ancak organizatörlerin seçimi bana oldukça tuhaf geldi. Örneğin, rüzgar hızı ve güneş ışınımını (SI) akıllı telefon sensörlerinden gelen verileri kullanarak hesaplamak için bir uygulama yapan ekibin finale kalmasına izin verdiler: rüzgar için bir mikrofon, SI için bir ışık sensörü. Çarpıcı özellik, sosisli sandviç/sosisli sandviç değil sınıflandırmasının üç sınıfa ayrılmasıydı: Güneş, rüzgar, su ve ilgili makalenin Vikipedi'de görüntülenmesi (gösteri).

Bir an için konunun ahlaki yönünü bir kenara bırakalım: katılımcılara zafer olasılığıyla şantaj yapmak kesinlikle etik dışıdır. Hackathon'lara katılmanın motivasyonlarından biri (özellikle deneyimli geliştiriciler) fikirlerini hayata geçirmek olduğundan, birçok güçlü katılımcı bu tür geri bildirimleri dinledikten sonra etkinlikten ayrılabilir (bu sadece bizim ekibimize değil, aynı zamanda etkinliği durduran diğer birçok kişiye de oldu). mentoru dinledikten sonra sayfa projelerini güncellemek). Yine de organizatörlerin isteklerine uyduk ve projemizi onların gereksinimlerine göre yeniden tasarladık diyelim. Bundan sonra ne olabilir?

Organizatörlerin “ideal proje” konusunda kendi anlayışları olduğundan, tüm istekler (ve buna bağlı olarak değişiklikler) bizi bu ideale yönlendirecektir. Yarışmacılar zamanlarını boşa harcayacak ve daha fazla katılımı reddetmeleri onlar için giderek daha zor olacak (çünkü zaten çabalarını harcadılar ve öyle görünüyor ki zafere biraz uzaktalar). Ancak gerçekte, ödüller için rekabet artacak ve katılımcılar, ödül kazanma umuduyla, organizatörlerin düzenlemelerine dayanarak projeyi giderek daha fazla yeniden yapmak zorunda kalacaklar. Sonuç olarak, ödül almayan adamlar geriye dönüp baktıklarında parasız serbest çalışmaya katıldıklarını anlayacaklar: müşteri için düzenlemeler yaptılar ancak bunun karşılığında hiçbir şey almadılar (ilgili deneyim hariç, kurs).

Ahlâk

Çoğu zaman organizatörlerin dilekleri ve geri bildirimleri projenin yardımına koşuyor. Ancak aynı zamanda katılımcılar, bastonlu topal bir adam gibi mentorların tavsiyelerine güvenmemelidir. Organizatörlerden projenizle ilgili “alın şunu, bunu biz sipariş etmedik” şeklinde geri bildirimler duyarsanız hackathona katılımınız tamamlanmış sayılabilir.

Proje için net bir vizyona sahip bir hackathon düzenliyorsanız, ancak bunu kendiniz uygulama becerisine veya becerisine sahip değilseniz, vizyonunuzu bir serbest çalışan için teknik spesifikasyonlar şeklinde resmileştirmek daha iyidir. Aksi takdirde, hackathon ve serbest çalışanın hizmetleri için iki kez ödeme yapmak zorunda kalacaksınız.

Kaynak: habr.com

Yorum ekle