Π Saya telah melihat beberapa sebab untuk menyertai hackathon. Motivasi untuk mempelajari banyak perkara baru dan memenangi hadiah berharga menarik ramai, tetapi selalunya, disebabkan kesilapan penganjur atau syarikat penaja, acara itu berakhir dengan tidak berjaya dan para peserta pergi dengan tidak berpuas hati. Untuk mengurangkan kejadian yang tidak menyenangkan seperti itu, saya menulis siaran ini. Bahagian kedua trilogi ini didedikasikan untuk kesilapan penganjur.
Jawatan itu disusun seperti berikut: pada mulanya saya bercakap tentang acara itu, terangkan apa yang salah dan apa yang membawa kepada (atau boleh membawa kepada dalam jangka masa panjang). Kemudian saya memberikan penilaian saya tentang apa yang berlaku, dan apa yang saya akan lakukan jika saya menjadi penganjur. Memandangkan saya mengambil bahagian dalam semua acara, saya hanya boleh menganggap motivasi sebenar penganjur. Akibatnya, penilaian saya mungkin berat sebelah. Saya tidak mengecualikan bahawa beberapa perkara yang nampaknya salah bagi saya sebenarnya bertujuan sedemikian.
Pada satu ketika, pembaca mungkin berfikir bahawa penulis memutuskan untuk melambaikan penumbuk selepas bergaduh. Tetapi saya boleh memberi jaminan bahawa ini tidak berlaku. Dalam beberapa hackathon yang disenaraikan, saya berjaya mengambil hadiah, yang, bagaimanapun, tidak menghalang kami daripada mengatakan bahawa acara itu tidak teratur.
Sebagai penghormatan kepada penganjur dan peserta, tidak akan ada rujukan kepada syarikat tertentu dalam jawatan tersebut. Pembaca yang penuh perhatian, bagaimanapun, boleh meneka (atau Google) siapa yang kita bicarakan.
Hackathon No. 1. Rangka kerja yang ketat
Enam bulan lalu, sebuah syarikat telekomunikasi besar menganjurkan hackathon pada analisis data. 20 pasukan bertanding untuk dana hadiah. Pada acara itu, set data disediakan untuk analisis, yang mengandungi maklumat tentang panggilan ke perkhidmatan sokongan syarikat, aktiviti di rangkaian sosial dan maklumat berkod tentang pengguna (jantina, umur, dll.). Bahagian paling menarik dalam set dataβmesej pengguna dan respons pengendali (data teks)βadalah agak bising dan perlu dibersihkan untuk kerja selanjutnya.
Penganjur menetapkan tugas - untuk melakukan sesuatu yang menarik dengan data yang disediakan, dan dilarang menggunakan set data terbuka tambahan daripada rangkaian atau menghuraikan data itu sendiri. Ia juga dilarang untuk mencadangkan idea yang tidak berkaitan dengan set data. Malangnya, data yang diberikan agak "lemah": sukar untuk mendapatkan produk yang menarik daripada mereka, dan dari komunikasi dengan mentor menjadi jelas bahawa banyak idea yang dicadangkan telah dilaksanakan (atau akan dilaksanakan dalam masa terdekat) dalam syarikat.
Akibatnya, bilangan besar pasukan (15 daripada 20) membuat chatbots. Semasa persembahan, keputusan satu pasukan sedikit berbeza daripada yang sebelumnya. Tidak dapat menahannya, salah seorang ahli juri bertanya kepada pasukan seterusnya yang menaiki pentas: "Apa, kawan-kawan, adakah anda juga mempunyai chatbot?" Hasilnya, daripada tiga hadiah, tempat pertama dan kedua menjadi milik pasukan yang tidak membuat chatbots.
Sebagai perbandingan, mari kita ambil hackathon yang dianjurkan oleh syarikat perunding antarabangsa untuk syarikat Zvezdochka dua tahun lalu. Memandangkan spesifik aktiviti syarikat Zvezdochka tidak diketahui oleh ramai peserta hackathon, pada permulaan acara penganjur bercakap tentang metrik yang digunakan dalam syarikat. Selepas ini, enam set data pelbagai jenis telah disediakan: teks, jadual, geolokasi - terdapat ruang untuk bergerak untuk semua peserta. Penganjur tidak melarang penggunaan set data tambahan malah menyokong inisiatif sedemikian. Di peringkat akhir pertandingan, sepuluh pasukan dengan penyelesaian berbeza bersaing untuk hadiah utama, dengan semua pasukan menggunakan data yang disediakan oleh syarikat (walaupun tiada sekatan), yang menunjukkan potensi yang baik untuk mendapatkan produk berkualiti.
Akhlak
Tidak perlu mengehadkan aliran kreatif peserta. Sebagai penganjur, anda mesti menyediakan bahan dan mempercayai visi dan profesionalisme mereka. Jika anda seorang peserta dalam hackathon, sebarang sekatan atau larangan harus membimbangkan anda. Biasanya ini adalah bukti organisasi yang lemah (contoh dari kehidupan sebenar ialah keinginan berterusan untuk melekatkan pagar di suatu tempat). Jika anda menghadapi sekatan, maka bersiaplah untuk fakta bahawa anda perlu membuat projek dalam kolam dengan banyak persaingan. Dalam kes ini, anda diwajibkan untuk mengambil risiko: melakukan sesuatu yang pada asasnya baharu atau menawarkan "ciri pembunuh" yang luar biasa untuk menonjolkan diri daripada aliran projek yang membosankan.
Hackathon No. 2. Tugas yang mustahil
Hackathon di Amador menjanjikan menarik. Syarikat penaja, pengeluar telefon besar, memulakan persiapan 4 bulan sebelum tarikh acara. PR untuk acara itu dijalankan di rangkaian sosial; bakal peserta perlu lulus ujian teknikal dan menulis tentang projek masa lalu mereka untuk dipilih untuk acara ini. Dana hadiah adalah besar. Beberapa hari sebelum hackathon, mentor mengadakan sesi teknikal supaya peserta mempunyai masa untuk memahami spesifik industri.
Pada acara itu sendiri, penganjur menyediakan set data log peralatan dengan volum 8 GB, tugasnya ialah klasifikasi binari pecahan. Mereka bercakap tentang kriteria untuk menilai projek - kualiti klasifikasi, kreativiti dalam mencipta ciri, keupayaan untuk bekerja dalam satu pasukan, dsb. Nasib malang - untuk 8 GB "ciri", terdapat hanya 20 contoh dalam kereta api dan 5 dalam ujian. Paku terakhir dalam keranda hackathon berasal dari data: log peralatan yang diterima pada hari Rabu mengandungi ralat dalam operasi peralatan, tetapi yang dibuat pada hari Khamis tidak (dengan cara itu, hanya dua pasukan yang tahu tentang ini, dan kedua-duanya dari Rusia, tanah air pelombong data berpengalaman ). Walaupun pengetahuan tentang label sebenar ujian tidak membantu untuk menentukan jawapan - tugas itu tidak dapat diselesaikan. Penganjur tidak mendapat keputusan yang diingini; para peserta menghabiskan banyak masa untuk menyelesaikan masalah yang direka dengan buruk. Hackathon itu gagal.
Akhlak
Jalankan semakan teknikal tugasan dan semak tugasan anda untuk kecukupan. Adalah lebih baik untuk membayar lebih untuk peperiksaan awal (dalam kes ini, mana-mana saintis data akan segera menunjukkan bahawa adalah mustahil untuk menyelesaikan masalah ini) daripada menyesal kemudian.
Dalam kes ini, selain membuang masa dan wang, syarikat itu kehilangan kredibiliti dengan calon berpotensi dan mungkin menulis tentang keputusannya. Dengan cara ini, bukan sahaja peserta, tetapi juga syarikat harus menulis tentang hasil yang berjaya, memaksimumkan hackathon dari sudut pandangan PR. Malangnya, tidak semua syarikat melakukan ini, mengehadkan diri mereka hanya kepada siaran pengumuman dan beberapa foto dari acara itu di Twitter.
Hackathon No. 3. Ambil atau tinggalkan
Terbaru, pasukan kami mengambil bahagian dalam hackathon di Amsterdam. Memandangkan saya seorang jurutera elektrik melalui latihan (dalam bidang sumber tenaga boleh diperbaharui), topik itu sesuai untuk kami - tenaga. Hackathon itu diadakan dalam talian: kami diberi penerangan tentang tugas dan sebulan untuk menyelesaikannya. Penganjur ingin melihat projek siap yang akan membantu meningkatkan kecekapan tenaga rumah Amsterdam.
Kami membuat projek di mana penggunaan elektrik telah diramalkan (sebelum itu, saya menyertai pertandingan mengenai topik ini di mana saya menerima penyelesaian hampir-sota, yang boleh anda baca ) dan penjanaan oleh panel solar. Berdasarkan ramalan ini, prestasi bateri dioptimumkan (idea ini sebahagiannya diambil daripada tesis sarjana saya). Projek kami adalah dalam persetujuan yang baik dengan arahan daripada penganjur (seperti yang kami nampak pada masa itu), dan dengan dasar pentadbiran Amsterdam dalam bidang sumber tenaga boleh diperbaharui untuk beberapa tahun akan datang.
Semasa penilaian projek, kami, seperti banyak pasukan, diberitahu bahawa ini bukan apa yang pelanggan jangkakan, sambil menambah bahawa kami perlu membuat semula projek jika kami ingin bersaing untuk hadiah. Kami tidak melakukan apa-apa lagi, menerima kekalahan. Daripada empat puluh pasukan yang mengambil bahagian, kami tidak sampai ke 7 teratas, walaupun pilihan penganjur, bagi saya, agak pelik. Contohnya, mereka membenarkan pasukan itu mara ke peringkat akhir yang membuat permohonan untuk mengira kelajuan angin dan sinaran suria (SI) menggunakan data daripada penderia telefon pintar: mikrofon untuk angin, penderia cahaya untuk SI. Ciri pembunuh ialah klasifikasi hotdog/bukan hotdog kepada tiga kelas: Matahari, angin, air dan paparan artikel yang sepadan di Wikipedia ().
Mari kita tinggalkan sisi moral isu ini seketika: memeras ugut peserta dengan kemungkinan menang adalah tidak beretika. Memandangkan salah satu motivasi untuk menyertai hackathon (terutamanya pembangun berpengalaman) adalah untuk merealisasikan idea mereka, ramai peserta yang kuat boleh meninggalkan acara tersebut selepas mendengar maklum balas sedemikian (yang berlaku bukan sahaja kepada pasukan kami, tetapi juga kepada beberapa orang lain yang berhenti. mengemas kini projek halaman mereka selepas mendengar mentor). Namun, katakan kami bersetuju dengan kehendak penganjur dan membuat semula projek kami untuk memenuhi keperluan mereka. Apa yang boleh berlaku seterusnya?
Memandangkan penganjur mempunyai pemahaman mereka sendiri tentang "projek ideal," semua keinginan (dan, dengan itu, perubahan) akan membawa kita ke arah ideal ini. Pesaing akan membuang masa mereka dan akan menjadi lebih sukar bagi mereka untuk menolak penyertaan selanjutnya (kerana mereka telah melaburkan usaha mereka, dan nampaknya mereka hanya sedikit jauh dari kemenangan). Tetapi pada hakikatnya, persaingan untuk hadiah akan meningkat, dan peserta semakin perlu membuat semula projek berdasarkan suntingan daripada penganjur dengan harapan memenangi hadiah. Akibatnya, lelaki yang tidak mengambil hadiah, melihat ke belakang, akan memahami bahawa mereka mengambil bahagian dalam pekerjaan bebas tanpa wang: mereka membuat pengeditan untuk pelanggan, tetapi tidak menerima apa-apa sebagai balasan untuk ini (kecuali untuk pengalaman yang berkaitan, daripada kursus).
Akhlak
Selalunya hasrat dan maklum balas daripada penganjur datang untuk membantu projek itu. Walau bagaimanapun, pada masa yang sama, peserta tidak boleh bergantung kepada nasihat mentor seperti orang tempang di atas rotan. Jika anda mendengar maklum balas daripada penganjur tentang projek anda dengan semangat "bawa pergi, kami tidak memesan ini", penyertaan anda dalam hackathon boleh dianggap selesai.
Jika anda menganjurkan hackathon dengan visi yang jelas untuk projek itu, tetapi tanpa kemahiran atau keupayaan untuk melaksanakannya sendiri, maka adalah lebih baik untuk memformalkan visi anda dalam bentuk spesifikasi teknikal untuk freelancer. Jika tidak, anda perlu membayar dua kali - untuk hackathon dan untuk perkhidmatan freelancer.
Sumber: www.habr.com