Guds Hand. Hjälp med kvitton

Guds Hand är faktiskt ett av de mest kända fotbollsmålen i historien, utfört av argentinska Diego Maradona på den 51:a minuten av kvartfinalmatchen i fotbolls-VM 1986 mot England. "Hand" — för målet gjordes med handen.

I vårt team kallar vi Guds Hand hjälp från en erfaren medarbetare till en novis i att lösa uppgiften. Den erfarna medarbetaren kallar vi i sin tur Maradona, eller helt enkelt M. Detta är en av de nyckelmetoder som ökar effektiviteten under förhållanden med otillräcklig kompetens hos medarbetarna. Så har det blivit att vi har många praktikanter i vårt team. Jag gör ett experiment.

Enligt statistiken krävs det inte mycket hjälp. "Genomsnittstiden" är 13 minuter – det vill säga från den tidpunkt då M reser sig från stolen och till dess han återvänder till den. Här ingår allt – att sätta sig in i uppgiften, diskutera, justera, designa arkitekturen och livliga samtal.

Spridningen av tidsåtgången för hjälp var först stor, upp till 1 timme, men har gradvis minskat och nu sällan överstiger en halvtimme. Det vill säga, M behöver bara några minuter för att uppgiften ska gå framåt eller till och med lyckas avslutas. Sådana saker händer.

Nyckelfunktionen: registrera och begränsa tiden för "maradonande". När du inte räknar minuter verkar det som att hjälpa andra tar massor av tid. Men när du skriver ner det, visar det sig att det inte är så illa.

Till exempel arbetar jag som Maradona i teamet. Jag har satt en gräns – 3 timmar om dagen för alla medarbetare. Jag trodde det skulle vara för lite. Det visade sig att 3 timmar är mer än tillräckligt, eftersom det genomsnittliga uttaget är 2 timmar om dagen.

Registrering och begränsning har en magisk effekt på medarbetarna. Den som ber om hjälp förstår att han måste använda tiden effektivt, eftersom begränsningen är gemensam för alla, och det är olönsamt att slösa M:s tid. Därför har det blivit mycket mindre prat om livet, vilket förstås gör mig nedslagen.

Generellt sett är Guds Hand en halvhjärtad metod. Man får intrycket att medarbetaren själv borde kunna förstå allt, lösa alla problem och förstå hela kontexten. Men det finns en obehaglig aspekt – de neurala kopplingarna.

Hjärnan fungerar som en enkel automat – den minns vägen och resultatet. Om en person har gått en väg och detta har lett till ett positivt resultat – skapas en neuronkoppling av typen "så här ska man göra". Och vice versa.

Tänk er då en praktikant eller en nybörjarprogrammerare. Han sitter ensam och försöker lösa en uppgift utan någon kravspecifikation. Kunden sätter ett mål, och sättet att nå dit väljer programmeraren.

Han har inte mycket att välja på, eftersom han inte känner till någon lösning på problemet. Han har ju ingen erfarenhet. Och han börjar söka lösningen genom trial and error, experiment, googling osv.

I slutändan hittar han någon lösning, prövar den, och plötsligt - voilà! Vad gör han nu? Idealiskt sett skulle han kolla vilka fler lösningar som finns, utvärdera sin kod, bedöma om arkitekturen är korrekt och om det är motiverat att blanda sig i andras objekt och moduler.

Men, jag vill påminna om – för vår person betyder alla dessa ord inget. Han vet helt enkelt inte vad de handlar om. Därför, likt en apa, kommer han bara att minnas den lösning som ledde till framgång. En neuronkoppling kommer antingen att skapas eller förstärkas (om den redan har skapats tidigare).

Ju längre in i det han går, desto värre blir det. Personen kommer att simma i sitt eget fett, därför att det kommer att finnas väldigt få anledningar att kliva ur. Som vi nämnde i avsnittet om kodens kvalitet, kommer ingen någonsin att säga till programmeraren att han skriver skräpkod. Kunderna förstår inte detta, och andra programmerare kollar sällan på andras kod – det finns ingen anledning.

Därför, tillbaka till det ursprungliga påståendet om att personen måste kunna lösa allt själv – tyvärr är det en så där metod. Åtminstone under förhållandena som gäller för praktikanter.

Här kommer Guds hand in och hjälper till. Den kommer att föreslå sökriktning för lösningen, ge råd om programmeringsspråk, komma på olika lösningar, och förutspå baserat på erfarenhet vilket alternativ som definitivt inte kommer att fungera, och kritisera koden samt säga var man kan klistra in redan färdig kod.

I grund och botten handlar det om väldigt lite. Praktikanter, som regel, har svårt för enkelheten. Bara för att de inte vet, till exempel, hur man går till funktionsbeskrivningen, formaterar koden, eller inte misstänker existensen av moment.js eller hur man debuggar tjänster i Chrome. Man behöver bara peka med fingret för att de ska ta sig vidare.

Värdet av de timmar han spenderar på att självständigt söka denna information är noll. Och ur ett affärsperspektiv är det rena stölden. Företaget har redan betalat Maradona för att få denna kompetens.

Och allt detta – i genomsnitt på 13 minuter. Eller 2 timmar per dag.

Ja, jag påminner: Handen från Gud behöver komma i tid. Det skulle vara ganska roligt att se Maradona komma ut på fotbollsplanen efter att matchen avslutats och göra mål med handen.

UPD: glömde att säga, vad som händer med produktiviteten M.

Som konstigt det än låter, med början på denna aktivitet har produktiviteten ökat med 1,5-2 gånger. Och produktiviteten för hela teamet har ökat ännu mer.

På M testar jag just nu tekniken för snabba omställningar. Om det inte kraschar, skriver jag när jag samlat statistik. Inklusive om den andra M, som just nu gör praktik.

Källa: habr.com