В Saya telah melihat beberapa alasan untuk berpartisipasi dalam hackathon. Motivasi untuk mempelajari banyak hal baru dan memenangkan hadiah berharga menarik banyak orang, namun seringkali karena kesalahan pihak penyelenggara atau perusahaan sponsor, acara berakhir tidak berhasil dan para peserta pulang dengan perasaan tidak puas. Agar kejadian tidak menyenangkan seperti itu lebih jarang terjadi, saya menulis postingan ini. Bagian kedua dari trilogi ini didedikasikan untuk kesalahan penyelenggara.
Postingan ini disusun sebagai berikut: pada awalnya saya berbicara tentang peristiwa tersebut, menjelaskan apa yang salah dan apa akibatnya (atau dapat menyebabkannya dalam jangka panjang). Lalu saya memberikan penilaian saya tentang apa yang terjadi, dan apa yang akan saya lakukan jika saya menjadi penyelenggaranya. Karena saya berpartisipasi dalam semua acara, saya hanya bisa berasumsi motivasi sebenarnya dari penyelenggara. Akibatnya, penilaian saya mungkin hanya sepihak. Saya tidak mengecualikan bahwa beberapa poin yang tampaknya salah bagi saya sebenarnya dimaksudkan demikian.
Pada titik tertentu, pembaca mungkin berpikir bahwa penulis memutuskan untuk mengacungkan tinjunya setelah bertengkar. Namun saya dapat meyakinkan Anda bahwa hal ini tidak terjadi. Dalam beberapa hackathon yang terdaftar, saya berhasil mendapatkan hadiah, namun tidak menghalangi kami untuk mengatakan bahwa acara tersebut diselenggarakan dengan buruk.
Untuk menghormati penyelenggara dan peserta, tidak akan ada referensi ke perusahaan tertentu di postingan tersebut. Namun, pembaca yang penuh perhatian dapat menebak (atau Google) siapa yang sedang kita bicarakan.
Hackathon No. 1. Batasan ketat
Enam bulan lalu, sebuah perusahaan telekomunikasi besar mengadakan hackathon tentang analisis data. 20 tim bersaing untuk memperebutkan dana hadiah. Pada acara tersebut, kumpulan data disediakan untuk dianalisis, yang berisi informasi tentang panggilan ke layanan dukungan perusahaan, aktivitas di jejaring sosial, dan informasi kode tentang pengguna (jenis kelamin, usia, dll.). Bagian paling menarik dari kumpulan data—pesan pengguna dan respons operator (data teks)—cukup berisik dan perlu dibersihkan untuk pekerjaan lebih lanjut.
Penyelenggara menetapkan tugas - melakukan sesuatu yang menarik dengan data yang disediakan, dan dilarang menggunakan kumpulan data terbuka tambahan dari jaringan atau mengurai data sendiri. Dilarang juga mengajukan ide yang tidak berhubungan dengan dataset. Sayangnya, data yang diberikan cukup “buruk”: sulit mendapatkan produk menarik dari mereka, dan dari komunikasi dengan mentor terlihat jelas bahwa banyak dari ide yang diajukan sudah dilaksanakan (atau akan dilaksanakan dalam waktu dekat) di perusahaan.
Hasilnya, sebagian besar tim (15 dari 20) membuat chatbots. Dalam pementasannya, keputusan satu tim sedikit berbeda dengan tim sebelumnya. Tak tega, salah satu juri bertanya kepada tim selanjutnya yang naik ke panggung: “Gimana, kalian juga punya chatbot?” Alhasil, dari tiga pemenang tersebut, juara pertama dan kedua diraih oleh tim yang tidak membuat chatbot.
Sebagai perbandingan, mari kita ambil hackathon yang diselenggarakan oleh perusahaan konsultan internasional untuk perusahaan Zvezdochka dua tahun lalu. Karena aktivitas spesifik perusahaan Zvezdochka masih asing bagi banyak peserta hackathon, di awal acara pihak penyelenggara membicarakan tentang metrik yang digunakan di perusahaan tersebut. Setelah itu, enam kumpulan data dari berbagai jenis disediakan: teks, tabel, geolokasi - ada ruang untuk bermanuver bagi semua peserta. Penyelenggara tidak melarang penggunaan kumpulan data tambahan dan bahkan mendukung inisiatif tersebut. Di babak final kompetisi, sepuluh tim dengan solusi berbeda bersaing untuk mendapatkan hadiah utama, dan semua tim menggunakan data yang disediakan oleh perusahaan (walaupun tidak ada batasan), yang menunjukkan potensi bagus untuk mendapatkan produk berkualitas.
Akhlak
Tidak perlu membatasi aliran kreatif peserta. Sebagai penyelenggara, Anda harus menyediakan materi dan memercayai visi dan profesionalisme mereka. Jika Anda adalah peserta hackathon, pembatasan atau larangan apa pun akan membuat Anda khawatir. Biasanya ini adalah bukti organisasi yang buruk (contoh dari kehidupan nyata adalah keinginan terus-menerus untuk memasang pagar di suatu tempat). Jika Anda masih menghadapi batasan, bersiaplah dengan kenyataan bahwa Anda harus membuat proyek di kumpulan dengan banyak kompetisi. Dalam hal ini, Anda wajib mengambil risiko: melakukan sesuatu yang secara fundamental baru atau menawarkan “fitur mematikan” yang tidak biasa agar menonjol dari arus proyek yang monoton.
Hackathon No.2. Tugas yang mustahil
Hackathon di Amador dijanjikan akan menarik. Perusahaan sponsor, sebuah produsen telepon besar, memulai persiapan 4 bulan sebelum tanggal acara. Humas acara dilakukan di jejaring sosial; calon peserta harus lulus tes teknis dan menulis tentang proyek masa lalu mereka agar dapat dipilih untuk acara ini. Dana hadiahnya cukup besar. Beberapa hari sebelum hackathon, para mentor mengadakan sesi teknis agar para peserta memiliki waktu untuk memahami secara spesifik industri tersebut.
Pada acara itu sendiri, penyelenggara menyediakan kumpulan data log peralatan sebesar 8 GB, tugasnya adalah klasifikasi kerusakan biner. Mereka berbicara tentang kriteria untuk mengevaluasi proyek - kualitas klasifikasi, kreativitas dalam menciptakan fitur, kemampuan bekerja dalam tim, dll. Ini hanya nasib buruk - untuk "fitur" 8 GB, hanya ada 20 contoh di kereta dan 5 di pengujian. Paku terakhir di peti mati hackathon berasal dari data: log peralatan yang diterima pada hari Rabu berisi kesalahan dalam pengoperasian peralatan, namun yang dibuat pada hari Kamis tidak (omong-omong, hanya dua tim yang mengetahui hal ini, dan keduanya berasal dari Rusia, tanah air para penambang data berpengalaman). Meskipun pengetahuan tentang label tes yang sebenarnya tidak membantu menentukan jawabannya, masalahnya tidak dapat diselesaikan. Penyelenggara tidak mendapatkan hasil yang diinginkan, para peserta menghabiskan banyak waktu untuk memecahkan masalah yang dirancang dengan buruk. Hackathon itu gagal.
Akhlak
Lakukan tinjauan teknis terhadap tugas dan periksa kecukupan tugas Anda. Lebih baik membayar lebih untuk pemeriksaan pendahuluan (dalam hal ini, data scientist mana pun akan segera menunjukkan bahwa masalah ini tidak mungkin diselesaikan) daripada menyesalinya nanti.
Dalam kasus ini, selain membuang-buang waktu dan uang, perusahaan kehilangan kredibilitas di mata calon kandidat dan mungkin menulis tentang hasilnya. Omong-omong, tidak hanya peserta, tetapi juga perusahaan harus menulis tentang hasil yang sukses, memaksimalkan hackathon dari sudut pandang PR. Sayangnya, tidak semua perusahaan melakukan hal ini, membatasi diri hanya pada postingan pengumuman dan beberapa foto dari acara tersebut di Twitter.
Hackathon No.3. Ambil atau tinggalkan
Baru-baru ini, tim kami mengikuti hackathon di Amsterdam. Karena saya seorang insinyur listrik dengan pelatihan (di bidang sumber energi terbarukan), topik yang tepat bagi kami adalah energi. Hackathon diadakan secara online: kami diberi gambaran tugas dan waktu satu bulan untuk menyelesaikannya. Penyelenggara ingin melihat proyek selesai yang akan membantu meningkatkan efisiensi energi rumah-rumah di Amsterdam.
Kami membuat proyek yang memperkirakan konsumsi listrik (sebelumnya, saya berpartisipasi dalam kompetisi tentang topik ini di mana saya menerima solusi mendekati sota, yang dapat Anda baca ) dan pembangkitan dengan panel surya. Berdasarkan prediksi tersebut, kinerja baterai menjadi optimal (ide ini sebagian diambil dari tesis master saya). Proyek kami sejalan dengan instruksi penyelenggara (seperti yang kami lihat saat itu), dan dengan kebijakan pemerintah Amsterdam di bidang sumber energi terbarukan selama 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 ingin bersaing memperebutkan hadiah. Kami tidak melakukan apa pun, menerima kekalahan. Dari empat puluh tim peserta, kami bahkan tidak masuk 7 besar, meski pilihan penyelenggara menurut saya agak aneh. Misalnya, mereka lolos ke final tim yang membuat aplikasi penghitungan kecepatan angin dan radiasi matahari (SI) menggunakan data dari sensor smartphone: microphone untuk angin, sensor cahaya untuk SI. Fitur mematikannya adalah klasifikasi hotdog/bukan hotdog menjadi tiga kelas: Matahari, angin, air, dan tampilan artikel terkait di Wikipedia ().
Mari kita tinggalkan sejenak sisi moral dari masalah ini: memeras peserta dengan kemungkinan menang adalah tindakan yang tidak etis. Karena salah satu motivasi untuk berpartisipasi dalam hackathon (terutama pengembang berpengalaman) adalah untuk merealisasikan ide-ide mereka, banyak peserta yang kuat dapat meninggalkan acara begitu saja setelah mendengar masukan tersebut (yang terjadi tidak hanya pada tim kami, tetapi juga pada sejumlah orang lain yang berhenti. memperbarui proyek halaman mereka setelah mendengarkan mentor). Namun, katakanlah kita setuju dengan keinginan penyelenggara dan membuat ulang proyek kita agar sesuai dengan kebutuhan mereka. Apa yang bisa terjadi selanjutnya?
Karena penyelenggara memiliki pemahaman mereka sendiri tentang “proyek ideal”, semua keinginan (dan, karenanya, perubahan) akan membawa kita menuju cita-cita ini. Para pesaing akan membuang-buang waktu mereka dan akan semakin sulit bagi mereka untuk menolak partisipasi lebih lanjut (karena mereka telah menginvestasikan upaya mereka, dan tampaknya mereka hanya tinggal sedikit lagi untuk menang). Namun kenyataannya, persaingan untuk mendapatkan hadiah akan semakin meningkat, dan peserta harus semakin sering mengulang proyek berdasarkan editan dari pihak penyelenggara dengan harapan dapat memenangkan hadiah. Akibatnya, orang-orang yang tidak mengambil hadiah, melihat ke belakang, akan memahami bahwa mereka mengambil bagian dalam pekerjaan lepas tanpa uang: mereka melakukan pengeditan untuk pelanggan, tetapi tidak menerima imbalan apa pun untuk ini (kecuali untuk pengalaman yang relevan, dari kursus).
Akhlak
Seringkali keinginan dan umpan balik dari penyelenggara membantu proyek ini. Namun, pada saat yang sama, peserta tidak boleh bergantung pada nasihat mentor seperti orang lumpuh di atas tongkat. Jika Anda mendengar masukan dari penyelenggara mengenai proyek Anda dengan semangat “ambil saja, kami tidak memesan ini”, partisipasi Anda dalam hackathon dapat dianggap selesai.
Jika Anda menyelenggarakan hackathon dengan visi proyek yang jelas, tetapi tanpa keterampilan atau kemampuan untuk mengimplementasikannya sendiri, maka ada baiknya Anda memformalkan visi Anda dalam bentuk spesifikasi teknis untuk seorang freelancer. Jika tidak, Anda harus membayar dua kali – untuk hackathon dan layanan freelancer.
Sumber: www.habr.com