Upande wa giza wa hackathons

В sehemu ya awali ya trilojia Nimeangalia sababu kadhaa za kushiriki katika hackathons. Hamasa ya kujifunza mambo mengi mapya na kushinda zawadi zenye thamani huwavutia wengi, lakini mara nyingi, kutokana na makosa ya waandaaji au makampuni yanayodhamini, tukio hilo huisha bila mafanikio na washiriki huondoka bila kuridhika. Ili kufanya matukio kama haya yasiyofurahisha kutokea mara nyingi, niliandika chapisho hili. Sehemu ya pili ya trilogy imejitolea kwa makosa ya waandaaji.

Chapisho limepangwa kama ifuatavyo: mwanzoni ninazungumza juu ya tukio hilo, eleza ni nini kilienda vibaya na nini kilisababisha (au inaweza kusababisha kwa muda mrefu). Kisha ninatoa tathmini yangu ya kile kinachotokea, na ningefanya nini ikiwa ningekuwa waandaaji. Kwa kuwa nilishiriki katika hafla zote, naweza tu kudhani motisha ya kweli ya waandaaji. Matokeo yake, tathmini yangu inaweza kuwa ya upande mmoja. Siondoi kwamba baadhi ya hoja zinazoonekana kuwa na makosa kwangu kwa kweli zilikusudiwa hivyo.

Wakati fulani, msomaji anaweza kufikiria kwamba mwandishi aliamua kutikisa ngumi zake baada ya mapigano. Lakini ninaweza kukuhakikishia kwamba hii sivyo. Katika baadhi ya hackathons zilizoorodheshwa, nilifanikiwa kuchukua tuzo, ambayo, hata hivyo, haituzuii kusema kwamba tukio hilo lilipangwa vibaya.

Kwa heshima kwa waandaaji na washiriki, hakutakuwa na marejeleo ya kampuni maalum kwenye chapisho. Msomaji makini, hata hivyo, anaweza kukisia (au Google) tunazungumza nani.

Hackathon No. 1. Mifumo mikali

Miezi sita iliyopita, kampuni moja kubwa ya mawasiliano ilipanga hackathon juu ya uchambuzi wa data. Timu 20 ziligombea hazina ya zawadi. Katika tukio hilo, seti ya data ilitolewa kwa ajili ya uchambuzi, ambayo ilikuwa na taarifa kuhusu simu kwa huduma ya usaidizi ya kampuni, shughuli kwenye mitandao ya kijamii na maelezo ya msimbo kuhusu watumiaji (jinsia, umri, nk). Sehemu ya kuvutia zaidi ya seti ya data—ujumbe wa mtumiaji na majibu ya waendeshaji (data ya maandishi)—ilikuwa yenye kelele na ilihitaji kusafishwa kwa kazi zaidi.

Waandaaji waliweka kazi - kufanya kitu cha kufurahisha na data iliyotolewa, na ilikatazwa kutumia hifadhidata wazi za ziada kutoka kwa mtandao au kuchanganua data mwenyewe. Pia ilipigwa marufuku kupendekeza mawazo yasiyohusiana na mkusanyiko wa data. Kwa bahati mbaya, data iliyotolewa ilikuwa "maskini" kabisa: ilikuwa vigumu kupata bidhaa yoyote ya kuvutia kutoka kwao, na kutoka kwa mawasiliano na washauri ikawa wazi kuwa mawazo mengi yaliyopendekezwa tayari yanatekelezwa (au yatatekelezwa katika siku za usoni). katika kampuni.

Kwa hivyo, idadi kubwa ya timu (15 kati ya 20) ilifanya gumzo. Wakati wa maonyesho, uamuzi wa timu moja ulikuwa tofauti kidogo na uliopita. Kwa kushindwa kustahimili hilo, mmoja wa washiriki wa jury aliuliza timu iliyofuata iliyopanda jukwaani: "Nini, nyie, je! nyinyi pia mna chatbot?" Kwa matokeo hayo, kati ya zawadi tatu, nafasi za kwanza na za pili zilikwenda kwa timu ambazo hazikufanya gumzo.

Kwa kulinganisha, hebu tuchukue hackathon iliyoandaliwa na kampuni ya kimataifa ya ushauri kwa kampuni ya Zvezdochka miaka miwili iliyopita. Kwa kuwa maelezo ya shughuli za kampuni ya Zvezdochka hayakuwa ya kawaida kwa washiriki wengi wa hackathon, mwanzoni mwa tukio hilo waandaaji walizungumza juu ya metrics ambayo hutumiwa katika kampuni hiyo. Baada ya hayo, hifadhidata sita za aina tofauti zilitolewa: maandishi, meza, eneo la kijiografia - kulikuwa na nafasi ya ujanja kwa washiriki wote. Waandaaji hawakukataza matumizi ya hifadhidata za ziada na hata waliunga mkono mipango kama hiyo. Katika fainali ya shindano hilo, timu kumi zilizo na suluhisho tofauti zilishindana kupata tuzo kuu, na timu zote zikitumia data iliyotolewa na kampuni (licha ya kukosekana kwa vizuizi), ambayo ilionyesha uwezekano mzuri wa kupata bidhaa bora.

Maadili

Hakuna haja ya kupunguza mtiririko wa ubunifu wa washiriki. Kama mratibu, lazima utoe nyenzo na uamini maono na taaluma zao. Ikiwa wewe ni mshiriki katika hackathon, vikwazo au marufuku yoyote yanapaswa kukutisha. Kawaida hii ni ushahidi wa shirika duni (mfano kutoka kwa maisha halisi ni hamu ya mara kwa mara ya kushikilia uzio mahali fulani). Ikiwa unakutana na vikwazo, basi uwe tayari kwa ukweli kwamba utakuwa na kuunda mradi katika bwawa na ushindani mkubwa. Katika kesi hii, unalazimika kuchukua hatari: fanya kitu kipya kabisa au toa "kipengele cha muuaji" kisicho kawaida ili kujitofautisha na mkondo wa miradi ya kusikitisha.

Hackathon nambari 2. Kazi zisizowezekana

Hackathon huko Amador iliahidi kuwa ya kuvutia. Kampuni inayofadhili, mtengenezaji mkubwa wa simu, ilianza maandalizi miezi 4 kabla ya tarehe ya tukio. PR kwa tukio hilo ilifanywa kwenye mitandao ya kijamii; washiriki wanaotarajiwa walipaswa kupita mtihani wa kiufundi na kuandika kuhusu miradi yao ya awali ili kuchaguliwa kwa tukio hili. Mfuko wa tuzo ulikuwa mkubwa wa kupendeza. Siku chache kabla ya hackathon, washauri walifanya kikao cha kiufundi ili washiriki wapate muda wa kuelewa maalum ya sekta hiyo.

Katika hafla yenyewe, waandaaji walitoa seti ya kumbukumbu ya vifaa na kiasi cha GB 8, kazi ilikuwa uainishaji wa binary wa kuvunjika. Walizungumza juu ya vigezo vya kutathmini miradi - ubora wa uainishaji, ubunifu katika kuunda huduma, uwezo wa kufanya kazi katika timu, nk. Ni bahati mbaya tu - kwa 8 GB ya "sifa", kulikuwa na mifano 20 tu kwenye gari moshi na 5 kwenye jaribio. Msumari wa mwisho kwenye jeneza la hackathon ulitoka kwa data: magogo ya vifaa vilivyopokelewa Jumatano yalikuwa na hitilafu katika uendeshaji wa vifaa, lakini wale walioundwa siku ya Alhamisi hawakufanya (kwa njia, timu mbili tu zilijua kuhusu hili, na. wote wawili walikuwa kutoka Urusi, nchi ya wachimbaji wenye uzoefu wa data ). Ingawa hata ujuzi wa maandiko ya kweli ya mtihani haukusaidia kuamua jibu - kazi hiyo haikuweza kutatuliwa. Waandaaji hawakupata matokeo yaliyohitajika; washiriki walitumia muda mwingi kutatua shida iliyoundwa vibaya. Hackathon haikufaulu.

Maadili

Fanya ukaguzi wa kiufundi wa kazi na uangalie mgawo wako kwa utoshelevu. Ni bora kulipia uchunguzi wa awali (katika kesi hii, mwanasayansi yeyote wa data atasema mara moja kuwa haiwezekani kutatua tatizo hili) kuliko kujuta baadaye.

Katika kesi hii, pamoja na kupoteza muda na pesa, kampuni ilipoteza uaminifu na wagombea wanaowezekana na ikiwezekana ikaandika juu ya matokeo. Kwa njia, sio tu washiriki, lakini pia kampuni inapaswa kuandika juu ya matokeo ya mafanikio, na kuongeza hackathon kutoka kwa mtazamo wa PR. Kwa bahati mbaya, sio kampuni zote hufanya hivi, zikijiwekea kikomo kwa chapisho la tangazo tu na picha kadhaa kutoka kwa tukio kwenye Twitter.

Hackathon nambari 3. Ichukue au iache

Hivi majuzi, timu yetu ilishiriki katika hackathon huko Amsterdam. Kwa kuwa mimi ni mhandisi wa umeme kwa mafunzo (katika uwanja wa vyanzo vya nishati mbadala), mada ilikuwa sawa kwetu - nishati. Hackathon ilifanyika mtandaoni: tulipewa maelezo ya kazi na mwezi wa kuikamilisha. Waandaaji walitaka kuona mradi uliokamilika ambao ungesaidia kuongeza ufanisi wa nishati ya nyumba za Amsterdam.

Tulifanya mradi ambao matumizi ya umeme yalitabiriwa (kabla ya hapo, nilishiriki katika mashindano juu ya mada hii ambapo nilipata suluhisho la karibu-sota, ambalo unaweza kusoma kuhusu hapa) na kuzalisha kwa paneli ya jua. Kulingana na utabiri huu, utendakazi wa betri umeboreshwa (wazo hili kwa sehemu lilichukuliwa kutoka kwa nadharia ya bwana wangu). Mradi wetu ulikuwa katika makubaliano mazuri na maagizo kutoka kwa waandaaji (kama ilivyoonekana kwetu wakati huo), na kwa sera ya utawala wa Amsterdam katika uwanja wa vyanzo vya nishati mbadala kwa miaka kadhaa ijayo.

Wakati wa tathmini ya miradi, sisi, kama timu nyingi, tuliambiwa kuwa hii sio ile ambayo mteja alitarajia, na kuongeza kwamba tulilazimika kufanya mradi upya ikiwa tunataka kushindania tuzo. Hatukufanya tena chochote, tukikubali kushindwa. Kati ya timu arobaini zilizoshiriki, hatukufanikiwa hata kuingia 7 bora, ingawa chaguo la waandaaji, inaonekana kwangu, lilikuwa la kushangaza. Kwa mfano, waliruhusu timu kufika fainali ambayo ilituma maombi ya kukokotoa kasi ya upepo na mionzi ya jua (SI) kwa kutumia data kutoka kwa vitambuzi vya simu mahiri: maikrofoni ya upepo, kitambuzi cha mwanga cha SI. Kipengele cha kuua kilikuwa uainishaji wa hotdog/sio hotdog katika madaraja matatu: Jua, upepo, maji na onyesho la makala sambamba kwenye Wikipedia (demo).

Hebu tuache upande wa kimaadili wa suala hilo kwa muda: kuwatusi washiriki na uwezekano wa ushindi ni kinyume cha maadili. Kwa kuwa moja ya motisha ya kushiriki katika hackathons (haswa watengenezaji wenye uzoefu) ni kutambua maoni yao, washiriki wengi wenye nguvu wanaweza kuondoka kwenye hafla hiyo baada ya kusikia maoni kama haya (ambayo yalifanyika sio kwa timu yetu tu, bali pia kwa wengine kadhaa ambao waliacha. kusasisha mradi wao wa ukurasa baada ya kumsikiliza mshauri). Bado, tuseme tulikubaliana na matakwa ya waandaaji na tukarekebisha mradi wetu ili kuendana na mahitaji yao. Nini kinaweza kutokea baadaye?

Kwa kuwa waandaaji wana ufahamu wao wenyewe wa "mradi bora," matakwa yote (na, ipasavyo, mabadiliko) yatatuongoza kuelekea bora hii. Washindani watapoteza muda wao na itakuwa vigumu zaidi na zaidi kwao kukataa ushiriki zaidi (kwani tayari wamewekeza juhudi zao, na inaonekana kwamba wako mbali kidogo na ushindi). Lakini katika hali halisi, ushindani wa zawadi utaongezeka, na washiriki watazidi kulazimika kufanya upya mradi kulingana na mabadiliko kutoka kwa waandaaji kwa matumaini ya kushinda tuzo. Kama matokeo, wavulana ambao hawakuchukua tuzo, wakiangalia nyuma, wataelewa kuwa walishiriki katika uhuru bila pesa: walifanya mabadiliko kwa mteja, lakini hawakupokea chochote kwa malipo ya hii (isipokuwa kwa uzoefu unaofaa, wa. kozi).

Maadili

Mara nyingi matakwa na maoni kutoka kwa waandaaji huja kusaidia mradi huo. Wakati huo huo, hata hivyo, washiriki hawapaswi kutegemea ushauri wa washauri kama vile kiwete kwenye fimbo. Ikiwa unasikia maoni kutoka kwa waandaaji kwenye mradi wako kwa roho ya "kuiondoa, hatukuamuru hii", ushiriki wako katika hackathon unaweza kuchukuliwa kuwa umekamilika.

Ikiwa unapanga hackathon na maono wazi ya mradi huo, lakini bila ujuzi au uwezo wa kutekeleza mwenyewe, basi ni bora kurasimisha maono yako kwa namna ya vipimo vya kiufundi kwa mfanyakazi huru. Vinginevyo, utalazimika kulipa mara mbili - kwa hackathon na kwa huduma za freelancer.

Chanzo: mapenzi.com