Quin tipus de grup acostumes a assistir a hackatons? Inicialment, vam dir que l'equip ideal està format per cinc persones: un gerent, dos programadors, un dissenyador i un venedor. Però l'experiència dels nostres finalistes va demostrar que pots guanyar un hackathon amb un petit equip de tres persones. Dels 26 equips que van guanyar la final, 3 van competir i van guanyar amb mosqueters. Com ho van fer - segueix llegint.
Hem parlat amb els capitans dels tres equips i ens hem adonat que la seva estratègia té molt en comú. Els herois d'aquesta publicació són els equips PLEXeT (Stavropol, nominació del Ministeri de Telecomunicacions i Comunicacions Massives), "Clau composta" (Tula, nominació del Ministeri d'Informació i Comunicacions de la República de Tatarstan) i Jingu Digital (Ekaterinburg, nomenament del Ministeri d'Indústria i Comerç). Per a aquells que estiguin interessats, s'amaga una breu descripció de les ordres sota el gat.
Descripcions de comandamentsPLEXeT
L'equip compta amb tres persones: un desenvolupador (web, C++, competències de seguretat de la informació), un dissenyador i un gestor. No ens coneixíem abans del hackathon regional. L'equip va ser reunit pel capità a partir dels resultats de les proves en línia.
Clau composta
L'equip compta amb tres companys desenvolupadors: fullstack amb deu anys d'experiència en TI, backend i mòbil, i backend centrat en bases de dades.
Jingu Digital
L'equip està format per dos programadors: backend i AR/Unity, així com un dissenyador que també era responsable de la gestió de l'equip. Guanyat en la nominació del Ministeri d'Indústria i Comerç
Trieu una tasca propera a les vostres competències
Recordes que hi havia una rima "club de teatre, club de fotos, i jo també vull cantar"? Crec que molta gent està familiaritzada amb aquest sentiment: quan tot el que t'envolta és interessant, vols mostrar-te d'una manera nova en la teva direcció i provar una nova indústria/àrea de desenvolupament. L'elecció aquí només depèn dels objectius del vostre equip i de la voluntat d'assumir riscos: podeu acceptar el vostre error si de sobte, enmig del hackathon, us adoneu que no és realista resoldre aquest problema? Els experiments de la categoria "No sóc bo per al desenvolupament mòbil, però què dimonis és?" no són per a tothom. Ets el tipus d'aficionat?
Artem Koshko (), comanda "Clau composta": "Al principi teníem previst provar alguna cosa nova. A l'etapa regional, vam provar diversos paquets nuget, que mai no vam aconseguir, i Yandex.Cloud. Al final, vam implementar CockroachDB a Kubernetes i vam intentar fer-hi migracions mitjançant EF Core. Algunes coses van anar bé, altres no tant. Així que vam aprendre coses noves, vam provar-nos a nosaltres mateixos i ens vam assegurar de la fiabilitat dels enfocaments provats"..
Com triar una tasca si els teus ulls vaga:
- Penseu en quines competències es necessiten per resoldre aquest cas i si tots els membres de l'equip les tenen
- Si us falten competències, podeu compensar-les (trobeu una altra solució, apreneu ràpidament alguna cosa nova)
- Feu una breu investigació del mercat per al qual elaborareu un producte
- Calcula la competència: a quina pista/empresa/tasca anirà més gent?
- Respon a la pregunta: què et motivarà més?
Oleg Bakhtadze-Karnaukhov (), comanda PLEXeT: "Vam prendre una decisió sobre una escala de deu hores a l'aeroport: just en el moment de l'aterratge, ens van arribar al nostre correu una llista de pistes i breus declaracions de tasques. De seguida vaig identificar quatre tasques que m'interessen com a programador i per a les quals el pla d'acció després de l'inici estava clar: què cal fer i com ho farem. Després vaig valorar les tasques de cada membre de l'equip i vaig valorar el nivell de competició. Com a resultat, vam triar entre les tasques de Gazprom i del Ministeri de Telecomunicacions i Comunicacions de Mass. El pare del nostre dissenyador treballa en petroli i gas; el vam trucar i li vam fer preguntes sobre la indústria. Al final, ens vam adonar que sí, és interessant, però no podrem oferir res fonamentalment nou i definitivament no podrem igualar les competències, perquè hi ha massa particularitats del sector que cal tenir en compte. compte. Al final ens vam arriscar i vam anar a la primera pista”.
Diana Ganieva (), equip de Jingu Digital: “A l'etapa regional teníem una tasca relacionada amb l'agricultura, i a la final - AR/VR a la indústria. Van ser escollits per tot l'equip perquè cadascú pogués adonar-se de les seves capacitats. Després vam eliminar allò que no vam trobar tan interessant".
Fes els deures
I ara no estem parlant de la preparació del codi; generalment no té sentit fer-ho. Es tracta de la comunicació dins de l'equip. Si encara no heu jugat junts, no heu après a entendre's i a posar-vos d'acord, reuniu-vos un parell de vegades abans i simulau un hackathon, o almenys truqueu-vos per parlar dels punts principals, penseu a través d'un pla d'acció, i discutir els punts forts i febles dels altres. Fins i tot podeu trobar algun cas i intentar resoldre'l, almenys de manera esquemàtica, al nivell de "com arribar del punt A al punt B".
Durant aquest paràgraf, correm el risc d'agafar minus en el karma i comentar, dient, com és possible, no entens res, però què passa amb l'emoció, l'empenta, la sensació que ara naixerà un prototip del primordial? caldo (hola, classes de biologia).
Sí, però.
La improvisació i la conducció només són bones quan només es converteixen en una lleugera desviació de l'estratègia; en cas contrari, els riscos són massa grans per dedicar temps a netejar el caos i corregir errors, en lloc de treballar, menjar o dormir.
Oleg Bakhtadze-Karnaukhov, equip de PLEXeT: “No coneixia cap dels membres del meu equip abans de la competició; els vaig seleccionar i convidar en funció de les seves competències i avaluacions a l'etapa de proves en línia. Quan vam guanyar la hackathon regional i ens vam adonar que encara havíem d'anar junts a Kazan i acabar el projecte d'hackathon a Stavropol, vam decidir que ens reuniríem i entrenaríem. Abans de la final, ens vam reunir dues vegades: vam trobar un problema aleatori i el vam resoldre. Una cosa així com un campionat de casos. I ja en aquesta etapa vam veure un problema en la comunicació i la distribució de tasques: mentre Polina (dissenyador) i Lev (gerent) pensaven en l'estil corporatiu, les característiques del producte, buscant dades de mercat, jo tenia molt de temps lliure. Així que ens vam adonar que havíem d'assumir una nominació més difícil (no m'estic presumir, ens hem trobat majoritàriament amb tasques relacionades amb la web, però per a mi només en són una o dues) i he d'implicar-me més en els processos de treball. . Com a resultat, a la final, durant la investigació preliminar, em vaig dedicar a la modelització matemàtica i al desenvolupament d'algorismes".
Artem Koshko, equip de claus compostes : “Ens vam preparar més mentalment; no es va parlar de preparar un codi. Ja havíem assignat rols a l'equip per endavant: tots tres som programadors (tenim una pila completa i dos backends, a més en sé una mica sobre el desenvolupament mòbil), però estava clar que algú hauria d'assumir el rols de dissenyador i gestor. Així va ser com, sense saber-me, em vaig convertir en cap d'equip, vaig provar-me com a analista de negocis, conferenciant i realitzador de presentacions. Crec que si no haguéssim parlat d'això per endavant, no hauríem pogut gestionar el temps correctament i no hauríem arribat a la defensa final".
Diana Ganieva, Jingu Digital: "No ens vam preparar per a l'hackathon, perquè creiem que els projectes de pirateig s'han de fer des de zero; això és just. Per endavant, en l'etapa de selecció de pistes, teníem un concepte general del que volíem fer".
No pots treballar amb desenvolupadors sols
Diana Ganieva, equip de Jingu Digital: “Tenim tres especialistes en diferents camps al nostre equip. Al meu entendre, aquesta és la composició ideal per a un hackató. Tothom està ocupat amb el seu propi negoci i no hi ha cap superposició ni divisió de tasques. Una persona més seria superflu".
Les estadístiques han demostrat que la composició mitjana dels nostres equips és de 4 a 5 persones, incloent (en el millor dels casos) un dissenyador. Generalment s'accepta que cal reforçar l'equip amb desenvolupadors de diferents franges, per poder afegir a la base de dades i sorprendre amb una "màquina" si passa alguna cosa. En el millor dels casos, encara s'emporten un dissenyador amb ells (no t'ofensi, t'estimem!), la presentació i les interfícies no es dibuixaran per si soles, al final. El paper d'un gerent es descuida encara més sovint; normalment aquesta funció l'assumeix el capità de l'equip, un desenvolupador a temps parcial.
I això és fonamentalment incorrecte.
Artem Koshko, equip de claus compostes: “En algun moment, vam lamentar no haver incorporat a l'equip un especialista especialitzat. Tot i que d'alguna manera vam poder fer front al disseny, va ser difícil amb el pla de negoci i altres coses estratègiques. Un exemple sorprenent és quan va ser necessari calcular el públic objectiu i el volum del mercat, TAM, SAM".
Oleg Bakhtadze-Karnaukhov, equip de PLEXeT: “La contribució del desenvolupador al producte està lluny del 80% del treball, com es creu habitualment. No es pot dir que fos més fàcil per als nois: gairebé la major part de les tasques els corresponia. El meu codi sense interfícies, presentacions, vídeos, estratègies és només un conjunt de símbols. Si hagués hagut més desenvolupadors a l'equip en comptes d'ells, probablement ho hauríem aconseguit, però tot hauria semblat menys professional. Sobretot la presentació en general té la meitat de l'èxit, tal com em sembla. Durant la defensa i després a la vida real en un parell de minuts, ningú tindrà temps d'entendre si el vostre prototip funciona realment. Si et deixes portar amb esquemes, ningú t'escoltarà. Si vas massa lluny amb el text, tothom entendrà que tu mateix no saps què és important en el teu producte, com presentar-lo i qui ho necessita".
Gestió del temps i relaxació
Recordeu com en els dibuixos animats infantils com "Tom i Jerry" els personatges es posen llumins sota les parpelles per evitar que es tanquin? Els participants de hackathon sense experiència (o massa entusiastes) semblen més o menys iguals.
En un hackathon, és fàcil perdre el contacte amb la realitat i la sensació del temps: l'ambient és propici per a una codificació desenfrenada sense pauses per descansar, dormir, jugar a la sala de jocs, comunicar-se amb els socis o assistir a classes magistrals. Si tractes això com els Campionats del Món o els Jocs Olímpics, llavors sí, potser així t'has de comportar. No realment.
Artem Koshko, equip de claus compostes: "Vam tenir molt chak-chak, molt; una torre es va construir al mig de la nostra taula, ens va mantenir la moral alta i ens va donar carbohidrats en el moment adequat. Descansàvem i treballàvem gairebé tot el temps junts, i no descansàvem per separat. Però dormien de manera diferent. A l'Andrey (desenvolupador fullstack) li agrada dormir durant el dia, a Denis i a mi ens agrada dormir a la nit. Per tant, vaig treballar més amb Denis durant el dia i amb Andrey a la nit. I dormia durant els descansos. No teníem cap sistema de treball ni d'establir tasques, sinó que tot era espontani. Però això no ens va molestar, perquè ens entenem bé i ens complementem. Ha ajudat que siguem companys i ens comuniquem de prop. Sóc l'antic intern de l'Andrey i el Denis va venir a l'empresa com a becari".
I aquí, per cert, hi ha la mateixa muntanya chak-chak.
Gairebé tots els participants que vam entrevistar van anomenar la gestió del temps competent com el criteri principal per a l'èxit a la hackató. Què vol dir? Distribuïu les tasques perquè tingueu temps per dormir i menjar, i les tasques no es realitzen de manera regular. tot es va ensorrar, però a un ritme còmode per a cada membre de l'equip.
Oleg Bakhtadze-Karnaukhov, equip de PLEXeT'El nostre objectiu no era treballar tantes hores com fos possible, sinó mantenir-nos productius el màxim de temps possible. Tot i que dormim entre 3 i 4 hores al dia, semblava que vam tenir èxit. Podríem anar a la sala de jocs o passar l'estona a les casetes dels nostres socis i reservar temps normal per menjar. El segon dia, vam intentar alleujar en Lev el màxim possible perquè pogués dormir prou i tingués temps per posar-se en ordre abans de l'actuació. Els assajos de hackaton ens van ajudar, ja que ja enteníem com repartir les tasques, i la sincronització de la rutina diària: menjàvem, dormim i estàvem desperts alhora. Com a resultat, van funcionar com un únic mecanisme".
No sabem com aquest equip va aconseguir portar Agomoto’s Eye al hackathon, però al final fins i tot van aconseguir rodar un vídeo sobre el projecte i preparar un fullet.
Alguns consells per a la gestió del temps en un hackató:
- Passa de gran a petit: divideix les tasques en blocs petits.
- Un hackathon és una marató. Què és el més important en una marató? Intenta córrer al mateix ritme, en cas contrari cauràs al final de la distància. Intenta treballar aproximadament a la mateixa intensitat i no esforçar-te fins a l'esgotament.
- Pensa amb antelació quines seran les tasques de cada participant i quant de temps li trigarà. T'ajudarà a evitar sorpreses quan s'acabi mitja hora de termini i no tinguis una gran feina a punt.
- Comproveu les coordenades per ajustar l'abast de les tasques. Sents que et va bé i fins i tot et queda temps? Genial: podeu gastar-lo per dormir o per finalitzar la vostra presentació.
- No et quedis pendent dels detalls, treballa a grans trets.
- És difícil fer una pausa de la feina, així que reserva un temps específicament per dormir, relaxar-te o relaxar-te. Podeu configurar alarmes, per exemple.
- Preneu-vos el temps per preparar i assajar el vostre discurs. Això és obligatori per a tothom i sempre. D'això n'hem parlat en un dels anteriors .
I també hi ha aquesta opinió alternativa. Per a quina opció estàs: tortura per codificació o guerra amb guerra i dinar segons un horari?
Diana Ganieva, equip de Jingu Digital: “Cada persona del nostre equip és responsable d'una cosa, no hi havia ningú que ens substituís, així que no podíem treballar per torns. Quan ja no quedaven forces, vam dormir tres hores, depenent de la quantitat de feina que encara quedava per al participant. No hi havia absolutament temps per passar l'estona, no perdem un temps preciós en això. La productivitat es va recolzar, encara que amb un son breu, i llaminadures amb te, sense begudes energètiques ni cafè.
Sota el tall s'amaguen diversos enllaços útils si voleu aprofundir en el tema de la gestió del temps. Serà útil a la vida quotidiana - creu l'autor d'aquesta publicació, que sempre arriba tard :)
Per als conqueridors del temps — Un gestor de projectes de Kaspersky Lab va recopilar tècniques efectives de gestió del temps al bloc de Netology:
— Un bon article per a principiants sobre Cossa:
Intenta destacar
Més amunt vam escriure sobre l'equip que va fer un fullet per protegir el projecte. Van ser els únics a la seva pista, i estem segurs que entre els més de 3500 participants no n'hi havia d'altres com ells.
Per descomptat, aquest no va ser el motiu principal de la seva victòria, però definitivament va aportar un avantatge addicional, almenys, la simpatia dels experts. Podeu destacar de diferents maneres: alguns dels nostres guanyadors comencen cada actuació amb una broma sobre com van fer una bomba (equip Sakharov, hola!).
No ens detenem en això en detall, sinó que simplement compartirem un cas de l'equip de PLEXeT; creiem que val la pena convertir-se en una broma sobre el fill de l'amic d'una mare.
Oleg Bakhtadze-Karnaukhov, equip PLEXeT: "Ens vam adonar que estàvem per davant de la corba i vam decidir que estaria bé venir a la predefensa amb un cas de traspàs. El projecte té molts detalls tècnics, explicacions d'algorismes, que no s'inclouen en absolut a la presentació. Però ho vull mostrar. Els experts van donar suport a la idea i fins i tot van ajudar a optimitzar-la. Ni tan sols van mirar la primera versió; van dir que mai llegirien una pintura així. Érem els únics en defensa”.
Alguna cosa està obligat a sortir malament, i això està bé.
En un hackathon, com a la vida normal, sempre hi ha lloc per a errors. Encara que sembli que has pensat en tot, qui entre nosaltres no ha arribat tard a un avió/examen/boda simplement perquè els cotxes van decidir quedar-se encallats en un embull, l'escala mecànica va decidir avariar-se i el passaport es va oblidar a casa?
Oleg Bakhtadze-Karnaukhov, equip PLEXeT: “La Polina i jo ens vam passar tota la nit fent una presentació, però al final ens vam oblidar de pujar-la a l'ordinador del vestíbul on es va fer la defensa. Intentem obrir-lo des d'una unitat flaix, i l'antivirus percep el fitxer com un virus i l'elimina. Com a resultat, vam aconseguir que tot comencés només un minut abans d'acabar la nostra actuació. Vam aconseguir mostrar el vídeo, però encara estàvem molt molestos. Una història semblant ens va passar durant la predefensa. El nostre prototip no va començar, els ordinadors de la Polina i el Lev es van congelar i, per alguna raó, vaig deixar el meu a l'hangar on hi havia la nostra pista. I encara que els experts van veure la nostra feina al matí, semblava un equip d'excèntrics amb un fullet, unes paraules boniques, però sense producte. Tenint en compte que molts participants van percebre el meu treball sobre models matemàtics com "ell està assegut, dibuixant alguna cosa, sense mirar l'ordinador", la situació no era gaire bona".
Sonarà cursi, però tot el que pots fer en aquesta situació és respirar. Ja ha passat. No, no ets l'únic, tothom s'enfonsa. Encara que això sigui un error fatal, és una experiència. I pensa també, la persona que t'està avaluant considerarà aquest cas un fakap?
Comparteix als comentaris quina composició et sents més còmode treballant en un hackathon (tant persones com especialistes) i com construeixes processos en equip.
Font: www.habr.com