Kuidas häkkerit häkkida: Pitch Perfect

(Põhiartikkel ja lingid teistele Hackathon 101 ja tööstuse postitustele on lingitud siin)

Ma ei usalda inimesi, kes osalevad võistlustel lihtsalt osalemises ja numbrite koostamises. Nagu, mis mõte sellel on? Kui kavatsete millelegi aega pühendada, sel juhul nädalavahetuse, siis võiksite ka täieliku kallutuse minna ja sellest midagi saada. Päeva lõpus, kui keegi tegelikult ei kaota, on kindlasti võitjaid ja selles postituses jagan mõnda oma lähenemist, mis on mind hästi teeninud.

Agrim, mida ma ehitan?

Suure osa hackatoni (ja toote) edust määrab võib-olla see, millise probleemiga otsustasite tegeleda ja kuidas te selle lahendasite. Uurime mõlemat valdkonda.

Millise probleemi peaksite lahendama?

See on muidugi keeruline küsimus; siin maailmas on palju inimesi, kes küsivad endalt seda küsimust, üritades oma idufirmasid üles ehitada, mõeldes, kas see, mille kallal nad töötavad, on oluline ja mida tasub lahendada, kui see on üldse probleem.

Ma teen seda nii - mul oli õnn olla ülikooli õppekavas, mis rõhutas disainmõtlemise olulisust. Lihtsamalt öeldes viib disainilahendus keerukate probleemide, eriti valesti määratletud või tundmatute probleemide lahendamisel lahenduspõhise lähenemiseni. Nüüd saate valida, kas kriimustada oma sügelust või valida uue domeeni, mille jaoks lahendada, kuid järgmine protsess töötab täpselt samamoodi.

Kujunduse mõtlemise protsess

Empaatia

Liiga sageli oleme süüdi lahenduse loomises, mõtlemata sellele eelnevatele asjadele palju järele - miks me seda teeme, kelle jaoks me seda teeme, mida ta tegelikult teeb, kas ta teeb seda, mida ta kavatseb teha ja õige publik. Suur osa sellest seisneb probleemi empaatiavõime puudumises. Me laseme oma eeldustel dikteerida, milles probleem on, ja see on vale. Seadsin silmitsi selle esimese käega, kui üritasin välja töötada lahenduse, mis aitaks nägemispuudega inimestel iseseisvalt navigeerida. Eeldasin, et:

  • Esiteks on see probleem, kuna juhtkoerad on kallid ja abistaja saamine on tülikas,
  • Teiseks on takistuste vältimine suurim lahendatav probleem,
  • Viimaseks, selline kantav kangas nagu Google Glass võiks lõpuks suhkruroo lahti saada.

Ma eksisin kõigis kolmes loendis.

Ehkki esimene abistaja vabastamise punkt oli tõsi, polnud see kiireloomuline mure, mis nõuaks tehnoloogilisi sekkumisi. Takistuste vältimist käsitlev teine ​​punkt polnud kõige suurem teema; fooride tuvastamine oli ilmselt suurem väljakutse, arvestades, et suhkruroo kattis enamus takistusi. Viimane punkt oli ränk, kuna ma eeldasin, et tehnoloogia asendamine on lihtne. Inimese eluviisi ei saa dramaatiliselt muuta; vaegnägijad on harjunud kasutama oma suhkruroo- ja kombatava katte markereid, nii et iga uus tehnoloogiauuendus peab selle peale rajama, mitte seda täielikult asendama.

Kuidas seda parandada? Väljaminek ja inimestega vestlemine on kindlaim viis rohkem teada saada, kuna saate otsest teavet kasutajate ja nende vajaduste kohta. Suutsin oma toote visuaalselt väljakutsujate abistamiseks parandada, kuna rääkisin tegelikult inimesega, kes neid väljakutseid igapäevaselt elab.

Aga mis siis, kui te ei saa hackathon ajal õige publikuga rääkida? Aeg on lühike ja võib-olla pole te õiges kohas nende inimestega kohtumiseks. Peate improviseerima ja koguma teavet, mis aitab teil objektiivselt määratleda probleemi, mida tasub lahendada. Eelmisel nädalavahetusel töötasin ma hackathonil, mis tahtis, et me saaksime lahenduse India jaoks. See on tohutu teema; Indial ei ole puudust probleemidest, millest igaüks on olulisem kui viimane, ja selle tõhus raamimine on juba iseenesest väljakutse, rääkimata katsest seda lahendada. Otsustasime aidata tööstussektoris töötavaid inimesi ja lahendasime probleemi väsimuse leevendamiseks. Miks?

  • India on tööõnnetuste osas halvim,
  • Indiaanlased on elatise teenimiseks tugevalt sõltuvad tööstustööstustest ja
  • On palju tõendeid selle kohta, et väsimus ja unepuudus põhjustavad õnnetusi / äpardusi ja isegi surmajuhtumeid erinevatel töösuundadel, nagu näiteks pikamaaveokiga sõitmine või raskete masinate käsitsemine - mõlemad riskantsed tööliinid pikkade vahetustega, mis muudavad töötajad väsimuseks ja kaotuseks tähelepanu.

Nüüd pole mul mingit võimalust seda isiklikult kontrollida; Olen sõltuvuses sellest, millised avalikud andmed ja faktid on narratiivi koostamiseks kättesaadavad, kuid vähemalt tekitab see teave piisavalt empaatiat, et määratleda lahendamist vajav probleem.

Määratlege

Ükskõik kui palju olete end veennud, läbite kindlasti Empathize'i etapi. Väidete kahekordseks / kolmekordseks kinnitamiseks pole lihtsalt piisavalt aega. Kui aga mängite oma kaarte õigesti, on teil piisavalt teavet, millega töötada. Töötagem koos meie eelmise näitega väsimuse kohta. Oleme kindlaks teinud, et vajalik on ohutum töökeskkond (väide 1) ja üks viis selle saavutamiseks on väsimuse leevendamine (väide 3). Meie probleemi määratlus põhineb sellel -

"Vajame turvalisema ja produktiivsema töökeskkonna loomiseks väsimuse jälgimise süsteemi."

Nüüd võite uurida kõiki muid selle domeeni probleeme ja see on täiesti kehtiv. Lihtsalt veenduge, et teie määratlus põhineb väidetel, mille olete loonud oma esialgse eeltöö käigus. Protsessi järgmise etapi seadistamiseks järgige lihtsat heuristikat -

  • Kelle jaoks me seda teeme? Sel juhul peamiselt töötajatele, aga ka tööandjatele.
  • Kuidas me seda teeme?
  • Milline on meie edu mõõde?
  • MIS SÕLMAB ÜKS VÕTMED, MIS TEIE TOODE SÕLMAB?

Ideaalne

Siin on, kui hakkate vastama küsimusele “kuidas”. See tähendab, et nüüd, kui teil on kogu teave olemas, mida kavatsete ehitada? Kas peaksime meie jaoks üles ehitama järelevalvesüsteemi? Või häire töötajale? Milline on meie edu mõõde - juhi ärkamine? Tööandjale registreerimisandmed? Mis kõige tähtsam - millest see kõik sõltub?!

Hakatonid on toodete valideerimisel ja loomisel imelikult tõhusad. Seal on ainult piiratud hulk asju, mida saate 3 minuti jooksul tõestada ja näidata, nii et peate valima kõige olulisema. Meie näites on see väsimuse jälgimissüsteem, kuna toote kõik muud aspektid - palgid, alarmid - sõltuvad väsimuse tuvastamise toimimisest. Seetõttu peate selle üles ehitama ja tagama, et see töötab teie demos. Kui see ebaõnnestub, pole ülejäänud toode enam veenev.

Liiga palju kordi võistkonnad kas põrkavad ühte peamist omadust, mis toodet kokku hoiab, või loovad 17 erinevat funktsiooni (“funktsiooni paistetus”), mis ajab kohtunikud segadusse, kuna nad kaotavad teate, mille meeskond suunas. See on väga lihtne asi - tehke üks või kaks asja ja tehke need hästi veriseks. See on kõigi suurepäraste toodete tunnus. Hakatonid ei erine.

Prototüüp / test

Nüüd on aeg ehitada. Valige oma tööriistad kaubanduseks - meie puhul läksime OpenCV-ga ja dlibiga võtmepunkti tuvastamiseks - ja alustage ehitamist. Võib juhtuda, et joonistate eskiisid / paberi prototüübid kõigepealt välja enne tegelikku toodet ja see on kõik korras. Kasutage neid, et oma ideede / määratluse / empaatia etappide vahel põrgata ning võimaluse korral kasutada mentorite ja ekspertide abi üritusel, et anda teile rohkem teadmisi. Teie lahendus areneb ja “puhastatakse”, mille järel saate ärisse minna. Kombineerisin prototüübi ja testimise etappe, kuna hackathon-lõigud lõppevad prototüübiga, kuid kui te tunnete, et pikendate projekti säilivusaega üle 24 tunni, peate katsetama oma valitud vaatajaskonnaga.

Kuidas lahendada probleem hackathonil?

Oleme õppinud, kuidas valida lahendamist väärt probleem ja kuidas see hackathonil töötab. Kuid nüüd konkreetsete juurde - mis teid hackathonist võidab? Ideaalses maailmas võiks e-teenus, portaal või madaltehnoloogiline lahendus pakkuda eeliseid miljonitele inimestele, kuid see ei võida kunagi hackathonil. Miks? Sest selleks pole tehnilist rangust. Selles on kahtlemata tööd, kuid kindlasti ei võta see kunagi lahenduse elegantsi ega tähelepanu, mida peate tekitama suurtes hakatonides. Õppisin seda raskelt.

Ehitate alati demo jaoks. Alati.

HackingEDU-s otsustasime luua selle armsa portaali, kus kõik kasutajad nägid olevat loomuliku keele vormi, kus seisis: “Ma tahan õppida tundma X-i ja mul on Y-minutit saadaval.” Väga selge probleem, mis lahendatakse seoses inimestega, kellel pole aega asju õppida ja mitmekülgsust. teave Internetis. Meie lahendus tooks välja ja valiks välja parimad lingid, mis teie aega väärt on. Kõik töötas ja nägi ilus välja.

Välja arvatud see, et ruumis oli 140 meeskonda ja see oli näituse stiilis paigutus. Kohtunikud ja võistkonnad klappisid laudade peal, kus olid suured eksponaadid või mitu monitori või vidinat, näiteks VR-peakomplektid, samal ajal kui meie lauas oli kurb MacBook, mille brauseriaken oli avatud. Meie häkkimisel polnud šokiväärtust. Isegi kui üritasin toodet müüa kõigile, kes külla tulid, teadsin, et töötan loodete vastu; külastaja tähelepanu oli vaevalt mõni sekund ja see polnud toode, mis vähemalt piiratud pilguga pani nad minema “Holy F * ck”.

Loomulikult me ​​ei võitnud. Kas oleksime võinud sellest stseeni teha? Kindlasti. Pärast seda sündmust on mul hackathon'i viimases etapis - hukkamises - asi olnud selgem. Te ei ehita lihtsalt „toodet”. Meenutate endale, et see on ju etendus ja jutustamine. Inimesed peavad olema valesti hoolimata sellest, kas teete seda õigesti või mitte. Olgu tegemist API-ühiskasutuse või õiguspäraselt maailma kujundava lahendusega, on selle šokiväärtus ainus, mis võib anda kohese mulje isegi enne, kui teil oleks olnud võimalus seda selgitada. Võtke see südamesse.

Kasutades oma aega targalt hackathonil

Aeg on hackathonil piiratud kaup. Arvate, et olete valmis minema, kui teie paketid on installitud ja buum käes - pool hackathonist on läbi. Te jääte magama, toitu ei pakuta veel kaks tundi, keegi on Red Bulli ürituste pakkumise ära kutsunud ja nüüd olete unine, õnnetu ega teinud tööd.

Ärge laske sellel jutul olla.

24–48-tunnisel hackathonil ei vaja te kunagi kogu ette nähtud aega. Kui te ei soovi avaldada tootmiseks valmis rakendust, millel on õige kood, mis on valmis turule jõudmiseks kohe, kui hackathon lõpeb, siis minge kindlasti edasi. Kuid kontseptsiooni tõendi ehitamine ei tohiks teid maha tappa.

Siin on mõned asjad, mida peaksite tegema -

  1. Enda vastutus. Kui tulete üksinda arendaja / kujundajana, siis laske kõik oma tööriistad installeerida ja töövalmis olla. Stardikomplektid, tarkvara, mida iganes arvate, et vajate. Jah, see on mittetäielik loetelu, kuid ma ei taha oma elu jooksul kunagi näha, et mõni teine ​​inimene laadiks ja kompileeriks sündmuse toimumise päeval nii suurt tarkvara kui OpenCV. Seda on valus vaadata. Tehke seda kodus, lahendage oma vead ja olge valmis tööle. Kui tulete meeskonnana, otsustage, milliste tööriistade / riistvaraga plaanite töötada, ja valmistage need ette ette.
  2. Võtke disainilahenduse mõtlemise protsessi tõsiselt. See aitab teil vastustest õiged küsimused hõlpsalt välja pigistada ja seejärel ülesanded tõhusalt meeskonna liikmete vahel jagada.
  3. Ülesannete jaotamine ja vastutus on esmatähtis. Enne kui hüppad sisse, tead enne, kes mida teeb. Kui keegi peab meeskonna koos hoidmiseks töötama peaministrina, siis tehke seda. Ma võtan selle rolli tavaliselt enda kanda mõnedel põhjustel -
  • See hoiab meid kursis, kui saan kontrollida, mida me ehitame ja miks me seda teeme,
  • See võimaldab meil jälgida, kui kaugel me konkreetsel ajahetkel oleme, ja eesmärke vastavalt kohandada,
  • See võimaldab meil üheskoos selgeks teha, mis on esmatähtsad ja millised on venitusfunktsioonid (heli näevad välja / lisavad sädet, kuid ei ole demos hädavajalikud).

Mulle meeldib oma hackathon meeskonna jaoks tiheda laevaga joosta või ühe peal olla. Eesmärkide jaoks ajamarkerite seadmine võimaldab kõigil palju aega puhata ja taastuda.

Iga kord naelutamine - vastupidine intuitiivne lähenemine

Kui olete mängus piisavalt aega veetnud, on see suur osa teisest olemusest; Mul on tavaliselt stabiilne meeskond, kellega võistlen, ja meil on selge, mida peame ideede ja teostuse osas tegema. Siiski on võimalik, et see ei pruugi ikkagi võitu saada. Mõned vastupidised lähenemisviisid -

  1. Ehitage uue tehnoloogia abil. Kõik ehitavad hackathonides mobiilirakendusi / veebirakendusi. Teil pole võimalust end teistest aktiivselt eristada. Jah, ma olen rahulolematu, eriti arvestades asju, mida saate nüüd teha mobiili ja veebi abil, kuid 70–80% häkkidest ei kasuta seda. Oleme kõigis uutes projektides kasutanud aktiivselt uute tehnoloogiate, näiteks Computer Visioni või tõestatava masinõppe kasutamist (ei piisa masinõppe nõudmiseks :)) või riistvara, kui hackathon seda nõuab. Mitte paljud inimesed ei saa seda korrata ja me jääme sündmuse lõpus peaaegu alati meelde.
  2. Koostage oma lõpptoode ja pigi, et lüüa hindamismarkereid. Kui hackathon hindab tehnilist täpsust 40% ja ideed 10%, siis teate, et võite ehitada midagi hullu, kui see on uudne ja loominguline, vaatamata mõjule. Kui fookus on vastupidine, st idee on 40%, tehniline on 10%, siis teate, et närvivõrkude suurepärase harjutamine ei anna teile võitu. Rääkides probleemist, kontekstist, miks see on oluline, kuidas seda lahendate ja kuidas teete seda paremini kui status quo, saab klinker.

Järeldus

Vau, veel üks pikk postitus samal ööl. Ma oleksin pidanud seda palju varem tegema.

Olen teiega jaganud seda, mida tean hakatonite kohta. Kuidas otsustan, mida ehitada, kuidas haldame aega, kuidas tagame, et vähemalt midagi võidame. Soovin siiralt, et see, kes seda loeb, leiaks selle kasuliku ja võidaks hakatonite abil midagi sellist, mille ma võib-olla siin kirjutasin.

Tagasiside / kommentaarid teretulnud! Olen saadaval Twitteris ja Facebookis.