Generellt sett är Guds hand ett av de mest kända fotbollsmålen i historien, framfört av argentinaren Diego Maradona i den 51:a minuten av 1986 års kvartsfinalmatch i fotbolls-VM mot England. "Hand" - eftersom målet gjordes för hand.
I vårt team kallar vi Guds hand för hjälp av en erfaren medarbetare till en oerfaren med att lösa ett problem. Därför kallar vi en erfaren anställd Maradona, eller helt enkelt M. Och detta är en av nyckelmetoderna för att öka effektiviteten under förhållanden med otillräckligt kvalificerade anställda. Tja, det råkar vara så att vi har många praktikanter i vårt team. Jag sätter upp ett experiment.
Statistiskt sett behövs inte mycket hjälp. "Genomsnittskontrollen" är 13 minuter - det här är från det ögonblick då M lyfte sin rumpa från stolen till det ögonblick då han återvände sin rumpa till stolen. Detta inkluderar allt - fördjupning i problemet, diskussion, felsökning, arkitekturdesign och samtal om livet.
Tidsintervallet för hjälp var till en början stort, upp till 1 timme, men minskade gradvis och går nu sällan längre än en halvtimme. De där. Det tar några minuter av M:s tid för uppgiften att gå framåt, eller till och med slutföras framgångsrikt. Det händer ibland.
Nyckelfunktion: redovisning och begränsning av tid för "marooning". Tills du räknar minuterna verkar det ta mycket tid att hjälpa andra. Och när man skriver ner det visar det sig att allt inte är så illa.
Jag jobbar till exempel deltid för Maradona i teamet. Gränsen sattes till 3 timmar per dag för alla anställda. Jag trodde att det inte skulle räcka. Det visade sig att till och med 3 timmar är en stöld, för... genomsnittlig konsumtion – 2 timmar per dag.
Redovisning och begränsning har en magisk effekt på anställda. Den som ber om hjälp förstår att tiden måste spenderas effektivt, eftersom gränsen är densamma för alla, och det är olönsamt att slösa bort M:s tid. Därför pratas det mycket mindre om livet, vilket förstås deprimerar mig.
I allmänhet är Guds hand ett halt knep. Det verkar som att medarbetaren själv måste lista ut allt, lösa alla problem, förstå hela sammanhanget. Men det finns ett problem - neurala anslutningar.
Hjärnan fungerar som en enkel automat – den kommer ihåg vägen och resultatet. Om en person har följt någon väg och det har lett till ett positivt resultat, bildas en neural koppling av typen "det här ska du göra". Tja, vice versa.
Så tänk dig en praktikant eller en nybörjare. Han sitter ensam och löser problemet, utan tekniska specifikationer. Klienten sätter ett visst mål och programmeraren väljer sättet att uppnå det.
Han har inte så mycket att välja på, för... han vet inte en enda lösning på problemet. Jag har ingen erfarenhet. Och han börjar leta efter en lösning genom att gissa, experimentera, söka på Internet osv.
Till slut hittar han något alternativ, provar det och sedan - bam! - hände! Vad ska den anställde göra? Helst kommer han naturligtvis att titta på vilka andra lösningsalternativ som finns tillgängliga, utvärdera sin kod och fatta ett beslut om arkitekturens riktighet och giltigheten av att störa andras objekt och moduler.
Men låt mig påminna dig om att för vår man betyder alla dessa ord ingenting. Han vet bara inte vad han pratar om. Därför, som, ursäkta mig, en apa, kommer han helt enkelt att komma ihåg alternativet som ledde till framgång. Den neurala anslutningen kommer antingen att bildas eller förstärkas (om den redan har bildats tidigare).
Längre vi går, värre blir det. En person kommer att stuva i sin egen juice, eftersom det kommer att finnas väldigt få anledningar att ta sig ur denna juice. Som vi sa i avsnittet om kodkvalitet, kommer ingen någonsin att berätta för en programmerare att han skriver taskig kod. Kunder förstår inte detta, och andra programmerare tittar sällan på någon annans kod – det finns ingen anledning.
Därför återvänder vi till den ursprungliga tesen att en person måste räkna ut allt själv - tyvärr är detta en so-so-metod. Åtminstone när man jobbar med praktikanter.
Det är här Guds hand kommer till undsättning. Och han kommer att föreslå riktningen för att söka efter en lösning, och ge råd om språket, och ge alternativ, och berätta förmögenheter baserat på erfarenhet, vilken lösning kommer definitivt inte att fungera, och kritisera koden och berätta var du ska kopiera den färdiga koda.
Faktum är att mycket lite behövs från M. Praktikanten är som regel dum i det blå. Helt enkelt för att han till exempel inte vet hur man går till funktionsbeskrivningen, formaterar koden, misstänker inte existensen av moment.js eller sätt att felsöka tjänster i Chrome. Allt du behöver göra är att peka fingret mot honom för att gå vidare.
Och värdet av timmarna han kommer att spendera på att söka efter denna information på egen hand är noll. Men ur affärsmässig synvinkel är detta i allmänhet stöld. Företaget har redan betalat Maradona för att få denna kompetens.
Och allt detta på i genomsnitt 13 minuter. Eller 2 timmar om dagen.
Ja, låt mig påminna dig: Guds hand behövs i tid. Det skulle vara roligt för Maradona att komma in på fotbollsplanen efter matchens slut och göra ett mål med handen.
UPD: Jag glömde säga vad som händer med M:s produktivitet.
Märkligt nog, med början av denna aktivitet ökade produktiviteten med 1.5-2 gånger. Och produktiviteten i teamet som helhet har ökat ännu mer.
På M:n testar jag just nu snabbväxlingstekniken. Om det inte dör, skriver jag när jag samlar statistik. Bland annat om den andra M, som just nu genomgår praktik.
Källa: will.com