Generelt er Guds hånd et af de mest berømte fodboldmål i historien, udført af argentineren Diego Maradona i det 51. minut af 1986 FIFA World Cups kvartfinalekamp mod England. "Hånd" - fordi målet blev scoret i hånden.
I vores team kalder vi Guds hånd hjælp fra en erfaren medarbejder til en uerfaren til at løse et problem. Derfor kalder vi en erfaren medarbejder Maradona, eller blot M. Og dette er en af nøglemetoderne til at øge effektiviteten under forhold med utilstrækkeligt kvalificerede medarbejdere. Nå, det sker, at vi har mange praktikanter på vores hold. Jeg er ved at sætte et eksperiment op.
Statistisk set er der ikke brug for meget hjælp. "Gennemsnitstjekket" er 13 minutter - det er fra det øjeblik, hvor M løftede sin røv fra stolen til det øjeblik, hvor han vendte sin røv tilbage til stolen. Dette inkluderer alt - dykning i problemet, diskussion, fejlfinding, arkitekturdesign og samtaler om livet.
Tidsintervallet for hjælp var i starten stort, op til 1 time, men blev gradvist indsnævret, og går nu sjældent ud over en halv time. De der. Det tager et par minutter af M's tid for opgaven at bevæge sig fremad, eller endda at fuldføre med succes. Nogle gange sker det.
Nøglefunktion: regnskab og begrænsning af tid til "marooning". Indtil du tæller minutterne, ser det ud til at tage meget tid at hjælpe andre. Og når man skriver det ned, viser det sig, at alt ikke er så slemt.
For eksempel arbejder jeg deltid for Maradona i teamet. Grænsen var sat til 3 timer om dagen for alle medarbejdere. Jeg troede, det ikke ville være nok. Det viste sig, at selv 3 timer er tyveri, fordi... gennemsnitligt forbrug – 2 timer pr.
Regnskab og begrænsning har en magisk effekt på medarbejderne. Enhver, der beder om hjælp, forstår, at tiden skal bruges effektivt, for grænsen er den samme for alle, og det er urentabelt at spilde Ms tid. Derfor er der meget mindre snak om livet, hvilket selvfølgelig deprimerer mig.
Generelt er Guds hånd et glat trick. Det ser ud til, at medarbejderen selv skal finde ud af alt, løse alle problemerne, forstå hele sammenhængen. Men der er et problem - neurale forbindelser.
Hjernen fungerer som en simpel automat – den husker stien og resultatet. Hvis en person har fulgt en eller anden vej, og det har ført til et positivt resultat, dannes en neural forbindelse af typen "det skal du gøre". Nå, omvendt.
Så forestil dig en praktikant eller en nybegynder programmør. Han sidder alene og løser problemet, uden tekniske specifikationer. Klienten sætter et bestemt mål, og programmøren vælger måden at nå det på.
Han har ikke meget at vælge imellem, fordi... han kender ikke en eneste løsning på problemet. Jeg har ingen erfaring. Og han begynder at lede efter en løsning ved at gætte, eksperimentere, søge på internettet osv.
Til sidst finder han en mulighed, prøver det, og så - bam! - skete! Hvad vil medarbejderen gøre? Ideelt set vil han selvfølgelig se på, hvilke andre løsningsmuligheder der er tilgængelige, evaluere sin kode og træffe en beslutning om rigtigheden af arkitekturen og gyldigheden af at interferere med andres objekter og moduler.
Men lad mig minde dig om, at for vores mand betyder alle disse ord ingenting. Han ved bare ikke, hvad han taler om. Derfor, som, undskyld mig, en abe, vil han simpelthen huske den mulighed, der førte til succes. Den neurale forbindelse vil enten blive dannet eller styrket (hvis den allerede er blevet dannet tidligere).
Længere vi går, værre bliver det. En person vil stuve i sin egen juice, fordi der vil være meget få grunde til at komme ud af denne juice. Som vi sagde i afsnittet om kodekvalitet, vil ingen nogensinde fortælle en programmør, at han skriver lort kode. Kunder forstår ikke dette, og andre programmører ser sjældent på andres kode - der er ingen grund.
Derfor vender vi tilbage til den oprindelige tese om, at en person selv skal finde ud af alt - ak, det er en halvdårlig metode. I hvert fald når man arbejder med praktikanter.
Det er her, Guds hånd kommer til undsætning. Og han vil foreslå retningen for at søge efter en løsning, og give råd om sproget, og give muligheder, og fortælle formuer baseret på erfaring, hvilken løsning vil bestemt ikke fungere, og kritisere koden, og fortælle dig, hvor du skal kopiere det færdige kode.
Faktisk er der meget lidt brug for M. Praktikanten er som regel dum ud af det blå. Simpelthen fordi han ikke ved, for eksempel, hvordan man går til funktionsbeskrivelsen, formaterer koden, har han ikke mistanke om eksistensen af moment.js eller måder at fejlsøge tjenester på i Chrome. Alt du skal gøre er at pege fingeren på ham for at komme videre.
Og værdien af de timer, han vil bruge på at søge efter denne information på egen hånd, er nul. Men fra et forretningsmæssigt synspunkt er der generelt tale om tyveri. Virksomheden har allerede betalt Maradona for at opnå denne kompetence.
Og alt dette på et gennemsnit på 13 minutter. Eller 2 timer om dagen.
Ja, lad mig minde dig om: Guds hånd er nødvendig i tide. Det ville være sjovt for Maradona at komme ind på fodboldbanen efter kampens afslutning og score et mål med hånden.
UPD: Jeg glemte at sige, hvad der sker med M's produktivitet.
Mærkeligt nok steg produktiviteten med starten af denne aktivitet med 1.5-2 gange. Og produktiviteten for holdet som helhed er steget endnu mere.
På M er jeg i øjeblikket ved at teste quick shift-teknikken. Hvis det ikke dør, skriver jeg, når jeg samler statistik. Herunder om den anden M, som lige nu er i praktik.
Kilde: www.habr.com