Di
bagian trilogi sebelumnya, saya memeriksa beberapa alasan untuk berpartisipasi dalam hackathons. Motivasi untuk belajar banyak dan memenangkan hadiah yang berharga menarik banyak, tetapi seringkali karena kesalahan penyelenggara atau perusahaan sponsor, acara tersebut berakhir dengan tidak berhasil dan para peserta tidak puas. Agar kasus tidak menyenangkan seperti itu jarang terjadi, saya menulis posting ini. Bagian kedua dari trilogi dikhususkan untuk kesalahan penyelenggara.
Posting ini diatur sebagai berikut: pada awalnya saya berbicara tentang acara tersebut, menjelaskan apa yang salah dan apa yang menyebabkannya (atau dapat mengarah pada jangka panjang). Kemudian saya memberikan penilaian saya tentang apa yang terjadi, dan bagaimana saya akan bertindak sebagai pengganti penyelenggara. Karena saya bertindak sebagai peserta di semua acara, saya hanya dapat mengasumsikan motivasi sebenarnya dari penyelenggara. Sebagai hasil dari ini, penilaian saya mungkin menjadi sepihak. Saya tidak mengesampingkan bahwa beberapa poin yang saya anggap salah sebenarnya dikandung.
Pada titik tertentu, tampaknya bagi pembaca bahwa penulis memutuskan untuk mengayunkan tinjunya setelah pertarungan. Tetapi saya dapat meyakinkan Anda bahwa ini tidak benar. Dalam beberapa hackathon yang terdaftar, saya berhasil mengambil hadiah, yang, bagaimanapun, tidak menghalangi saya untuk mengatakan bahwa acara tersebut tidak diorganisir dengan baik.
Karena menghormati penyelenggara dan peserta, pos tidak akan menunjukkan perusahaan tertentu. Namun, pembaca yang perhatian dapat menebak (atau google) siapa yang mereka bicarakan.
Hackathon No. 1. Kerangka kerja yang ketat
Enam bulan lalu, sebuah perusahaan telekomunikasi besar menyelenggarakan hackathon analisis data. Untuk hadiah dana bertarung 20 tim. Pada acara tersebut, sebuah dataset disediakan untuk analisis, yang berisi informasi tentang panggilan ke layanan dukungan perusahaan, aktivitas di jejaring sosial dan informasi yang dikodekan tentang pengguna (jenis kelamin, usia, dll.). Bagian paling menarik dari dataset - pesan pengguna dan respons operator (data teks) - cukup “berisik”, perlu dibersihkan untuk pekerjaan lebih lanjut.
Panitia mengatur tugas - untuk melakukan sesuatu yang menarik dengan data yang disediakan, dan dilarang menggunakan set data terbuka tambahan dari jaringan atau mengurai sendiri data tersebut. Juga dilarang menawarkan ide yang tidak terkait dengan dataset. Sayangnya, data yang diberikan agak "buruk": sulit untuk mendapatkan produk yang menarik dari mereka, dan dari berkomunikasi dengan mentor menjadi jelas bahwa banyak ide yang diusulkan sudah dilaksanakan (atau akan diimplementasikan dalam waktu dekat) di perusahaan.
Akibatnya, sebagian besar tim (15 dari 20) membuat bot obrolan. Selama pidato, keputusan satu tim tidak jauh berbeda dari yang sebelumnya. Tak tertahankan, salah satu anggota juri bertanya kepada tim berikutnya di atas panggung: "Apa, teman-teman, apakah Anda juga punya bot obrolan?" Akibatnya, dari tiga hadiah, tempat pertama dan kedua pergi ke tim yang tidak membuat bot obrolan.
Sebagai perbandingan, ambil hackathon, yang diselenggarakan oleh perusahaan konsultan internasional, untuk perusahaan Zvezdochka dua tahun lalu. Karena spesifikasi perusahaan Zvyozdochka tidak dikenal oleh banyak peserta hackathon, pada awal acara, panitia berbicara tentang metrik yang digunakan dalam perusahaan. Setelah itu, enam set data dari berbagai orientasi disediakan: teks, tabel, posisi geografis - ada ruang untuk bermanuver untuk semua peserta. Penyelenggara tidak melarang penggunaan set data tambahan dan bahkan mendukung upaya tersebut. Di final kompetisi, sepuluh tim dengan keputusan berbeda berjuang untuk mendapatkan hadiah utama, dan semua tim menggunakan data yang disediakan oleh perusahaan (meskipun tidak ada larangan), yang menunjukkan potensi yang baik untuk mendapatkan produk yang berkualitas.
Akhlak
Jangan membatasi aliran kreatif peserta. Sebagai penyelenggara, Anda harus memberikan materi dan mempercayai pandangan dan profesionalisme mereka. Jika Anda adalah anggota hackathon, segala larangan atau larangan harus mengingatkan Anda. Biasanya ini adalah bukti organisasi yang buruk (contoh dari kehidupan nyata adalah keinginan yang konstan untuk memagari pagar di suatu tempat). Jika Anda masih menghadapi batasan, maka bersiaplah untuk kenyataan bahwa Anda harus membuat proyek di kolam dengan kompetisi yang hebat. Dalam hal ini, Anda harus mengambil risiko: melakukan sesuatu yang secara fundamental baru atau menawarkan "fitur pembunuh" yang tidak biasa agar dapat menonjol dari aliran proyek monoton.
Hackathon nomor 2. Tugas yang tidak mungkin
Hackathon di Amadore berjanji akan menarik. Perusahaan sponsor, produsen utama telepon, memulai persiapan 4 bulan sebelum tanggal acara. Sebuah acara sosial diadakan di jejaring sosial, calon peserta harus lulus tes teknis dan menulis tentang proyek masa lalu mereka untuk dipilih untuk acara ini. Kolam hadiah itu sangat besar. Beberapa hari sebelum hackathon, para mentor mengadakan sesi teknis sehingga para peserta punya waktu untuk menembus spesifikasi industri.
Pada acara tersebut, panitia menyediakan dataset peralatan 8 Gb dengan klasifikasi biner dari kerusakan. Mereka berbicara tentang kriteria untuk mengevaluasi proyek - kualitas klasifikasi, kreativitas menciptakan fitur, kemampuan untuk bekerja dalam tim, dll. Itu hanya nasib buruk - untuk 8 GB "fitur", hanya ada 20 contoh di kereta dan 5 di tes. Paku terakhir di tutup peti mati hackathon memberi angka pada data: log peralatan yang diterima pada hari Rabu mengandung kesalahan dalam operasi peralatan, dan yang dibuat pada hari Kamis tidak mengandung (omong-omong, hanya dua tim yang tahu tentang hal itu, dan keduanya berasal dari Rusia - tanah air dari datameners berpengalaman) ) Meskipun mengetahui label tes yang sebenarnya tidak membantu untuk menyesuaikan jawaban, tugas itu tidak dapat diselesaikan. Panitia tidak mendapatkan hasil yang diinginkan, para peserta menghabiskan banyak waktu untuk menyelesaikan tugas yang disusun dengan buruk. Hackathon itu gagal.
Akhlak
Lakukan pemeriksaan tugas teknis dan periksa tugas Anda untuk kecukupan. Lebih baik membayar lebih untuk pemeriksaan pendahuluan (dalam hal ini, pusat data apa pun akan segera menunjukkan bahwa tidak mungkin untuk menyelesaikan masalah ini) daripada menyesalinya nanti.
Dalam hal ini, selain waktu dan uang yang dihabiskan, perusahaan kehilangan pinjaman kepercayaan dari kandidat potensial dan dimungkinkan untuk menulis tentang hasilnya. Ngomong-ngomong, bukan hanya para peserta, tetapi juga perusahaan harus menulis tentang hasil yang sukses, secara maksimal mewujudkan hackathon dari sudut pandang PR. Sayangnya, tidak semua perusahaan melakukan ini, membatasi diri hanya pada post-pengumuman dan beberapa foto dari acara di Twitter.
Hackathon nomor 3. Ambil atau tinggalkan
Baru-baru ini, tim kami berpartisipasi dalam hackathon di Amsterdam. Karena saya seorang insinyur listrik dengan pelatihan (di bidang sumber energi terbarukan), subjek hanya untuk kita - energi. Hackathon dilakukan dalam format online: kami diberi deskripsi tugas dan satu bulan untuk selesai. Panitia ingin melihat proyek selesai yang akan membantu meningkatkan efisiensi energi rumah-rumah Amsterdam.
Kami membuat sebuah proyek di mana konsumsi listrik diprediksi (sebelum itu saya berpartisipasi dalam kompetisi tentang topik ini di mana saya mendapat solusi hampir-sota, yang dapat dibaca di
sini ) dan dihasilkan oleh panel surya. Berdasarkan prediksi ini, kinerja baterai dioptimalkan (ide ini sebagian diambil dari ijazah master saya). Proyek kami dalam perjanjian yang baik baik dengan tugas dari penyelenggara (seperti yang tampak bagi kami saat itu) dan dengan kebijakan administrasi Amsterdam di bidang energi terbarukan untuk beberapa tahun mendatang.
Selama evaluasi proyek, kami, seperti banyak tim lainnya, diberitahu bahwa ini bukan yang diharapkan pelanggan, dan menambahkan bahwa kami harus mengulang proyek jika kami ingin bersaing untuk mendapatkan hadiah. Kami tidak mengulangi apa pun, pasrah untuk kalah. Dari empat puluh tim yang berpartisipasi, kami bahkan tidak masuk ke 7 besar, meskipun pilihan penyelenggara, menurut saya, agak aneh. Misalnya, mereka melewatkan tim final, yang membuat aplikasi untuk menghitung kecepatan angin dan radiasi matahari (SI) menurut sensor ponsel cerdas: mikrofon untuk angin, sensor cahaya untuk SI. Fitur killer memiliki klasifikasi hotdog / bukan hotdog menjadi tiga kelas: Matahari, angin, air dan tampilan artikel Wikipedia yang sesuai (
demo ).
Mari kita tinggalkan sejenak sisi moral dari masalah ini: memeras peserta dengan kemungkinan kemenangan sama sekali tidak etis. Karena salah satu motivasi untuk berpartisipasi dalam hackathon (terutama pengembang berpengalaman) adalah realisasi ide-ide mereka, banyak peserta yang kuat dapat meninggalkan acara setelah mendengar umpan balik tersebut (yang terjadi tidak hanya dengan tim kami, tetapi juga dengan sejumlah orang lain yang berhenti memperbarui halaman) proyek Anda setelah mendengarkan mentor). Namun demikian, katakanlah kami setuju dengan penyelenggara dan mendesain ulang proyek kami sesuai kebutuhan mereka. Apa yang bisa terjadi selanjutnya?
Karena penyelenggara memiliki pemahaman mereka sendiri tentang "proyek ideal", semua keinginan (dan, dengan demikian, perubahan) akan membawa kita ke cita-cita ini. Kontestan akan menghabiskan waktu mereka dan akan semakin sulit bagi mereka untuk menolak berpartisipasi lebih lanjut (karena mereka telah menginvestasikan kekuatan mereka, dan tampaknya mereka tidak akan bisa menang). Namun dalam kenyataannya, kompetisi untuk hadiah akan meningkat, dan peserta akan semakin harus mengulangi proyek untuk koreksi dari penyelenggara dengan harapan menerima hadiah. Akibatnya, orang-orang yang tidak menerima hadiah, melihat ke belakang akan menyadari bahwa mereka berpartisipasi dalam freelance tanpa uang: mereka membuat perubahan pada pelanggan, tetapi pada saat yang sama tidak menerima imbalan apa pun (kecuali untuk pengalaman yang relevan, tentu saja).
Akhlak
Seringkali, keinginan dan umpan balik dari penyelenggara datang untuk membantu proyek. Namun dalam hal ini, peserta tidak boleh mengandalkan saran dari mentor sebagai orang lumpuh. Jika Anda mendengar dari penyelenggara umpan balik tentang proyek Anda dalam semangat "bawa pergi, kami tidak memesannya" - partisipasi Anda dalam hackathon tentang hal ini dapat dianggap selesai.
Jika Anda mengorganisir hackathon dengan visi proyek yang jelas, tetapi tanpa keterampilan atau kemampuan untuk mengimplementasikannya sendiri, lebih baik untuk merancang visi Anda dalam bentuk tugas teknis untuk freelancer. Jika tidak, Anda harus membayar dua kali - untuk hackathon dan untuk layanan freelancer.