Forstå din programmør
Samarbejde med programmører går ofte galt, fordi vi tror, vi har aftalt det samme, når vi i virkeligheden taler om to forskellige ting. Jeg har lært, at det, jeg synes er indlysende, ikke nødvendigvis er en del af den opgave, programmøren har hørt mig stille.
Jeg får mange mails fra iværksættere om IT-projekter, der er kørt af sporet. Hjemmesider, webshops, bannerreklamer, Google AdWords, databaser og CRM-systemer. Her i 2010 kommer næsten enhver iværksætter på et tidspunkt i kontakt med tekniske folk.
Det gælder både tagdækkeren i Jylland og fiskeren på Bornholm. Man har en hjemmeside, en mailadresse eller noget andet, som gør IT til en del af forretningen.
Vi tænker ikke nødvendigvis ens
Jeg har haft rigtig mange programmører ansat gennem tiden. Over 100 og sikkert også over 200. En af mine erfaringer er, at kommunikationen mellem tekniske og mindre tekniske mennesker kan gå ufattelig galt.
I videoen bruger jeg en meget bred generalisering om autisme og påstår, at langt de fleste programmører har det i en eller anden grad. Det er min generalisering i 2010, ikke en dokumenteret oplysning om programmører eller en vurdering af bestemte menneskers diagnose.
Jeg siger det ikke for at nedgøre nogen. Tværtimod synes jeg, der er nogle enormt spændende og dygtige mennesker inden for programmering og ingeniørarbejde. Min pointe er, at nogle mennesker er stærke i tal, struktur og teknik, mens andre har lettere ved den kommunikation, jeg selv tager for givet.
Men når vi taler sammen, skal vi ikke regne med, at den anden automatisk opfatter alle de ting, vi ikke har sagt højt.
Banken ventede, men Poul var ikke gået i gang
For mange år siden havde jeg en programmør, som hed Poul. Vi havde lavet en hjemmeside til en bank, og banken ringede helt fortvivlet, fordi noget ikke fungerede, som de havde tænkt sig.
De skulle lancere meget snart. Jeg spurgte Poul, hvor lang tid det ville tage at rette fejlen. Tre timer, sagde han.
Så meldte jeg tilbage til banken: Tre timer. De var ikke glade, men bad os gøre, hvad vi kunne.
Poul sad i nærheden og programmerede videre. Da der var gået en halv time, spurgte jeg, hvordan det gik med problemet.
Han kiggede på mig: Hvad snakker du om?
Jeg henviste til de tre timer, han havde sagt. Men han var slet ikke begyndt. Jeg havde jo ikke spurgt, hvornår han havde tid. Jeg havde spurgt, hvor lang tid det tog at lave.
Han havde andre sager, som hastede, og ingen tid til den opgave lige nu.
En varighed er ikke det samme som en leveringstid
Det var en af mine første lektioner i, hvor forskelligt vi kunne tænke. Poul kunne høre, at jeg havde en ophidset bankdirektør i røret, og at jeg selv var ved at rive håret ud.
For mig var det indlysende, at mit spørgsmål betød: Hvornår kan banken få fejlen rettet? Men det var faktisk ikke det, jeg havde spurgt om.
Poul gjorde det ikke med vilje. Han svarede på det spørgsmål, jeg stillede. Og jeg hørte noget mere i svaret, end han havde sagt.
Det er et meget typisk eksempel på en kommunikationsbrøler mellem en programmør og en, som ikke er programmør.
Samarbejde med programmører kræver, at opgaven bliver tydelig
Jeg arbejder med flere virksomheder rundt omkring i verden, som laver gode ting for mig. En af dem anbefalede jeg til en bekendt, fordi jeg ved, de er dygtige.
Alligevel endte samarbejdet i næsten en retssag, tænderskæren og alt muligt andet. Hvorfor går det galt, når virksomheden kan levere så godt til mig?
Jeg tror, en del af forklaringen er, at jeg har arbejdet med så mange programmører, at jeg har lært, hvordan jeg skal formulere tingene. Jeg ved bedre, hvad jeg skal sige, for at opgaven bliver forstået og lavet på den måde, jeg forventer.
Det er ikke kun et spørgsmål om at finde nogle dygtige folk. Det er også et spørgsmål om selv at være i stand til at stille opgaven. Læs også Min vej som leder om mine erfaringer med at lede mennesker og gøre forventninger tydelige.
Henrik og jeg ganger med pi
Min makker Henrik og jeg har en stående joke: Når en programmør fortæller, hvor lang tid noget tager, ganger vi med pi. Cirka 3,14.
En uge bliver på den måde til næsten en måned. Og jeg bruger det faktisk som en tommelfingerregel i mine egne forventninger, også selv om jeg siger det med et glimt i øjet.
Det er ikke, fordi jeg mener, folk er onde, amatører eller klaphatte. Ofte løser de den opgave, vi har forklaret, inden for den aftalte tid.
Problemet er alt det, der ligger usagt. De ting, vi glemte at nævne. Det, vi regnede med, at den anden selv kunne regne ud. De ekstra dele, som vi i vores hoved allerede havde lagt ind i aftalen.
Jeg troede, Poul ville være færdig om tre timer, men han havde kun svaret på, hvor meget arbejde rettelsen krævede. På samme måde kan en aftalt uges arbejde blive til meget mere, når alle de uudtalte forventninger skal med.
Begge parter kan føle sig snydt
Så bliver kunden vred: Du sagde jo, at det tog en uge!
Og programmøren bliver også vred: Det, du bad om, tog cirka en uge. Alle de andre mærkelige ting, du forventede, jeg selv kunne regne ud, tager også tid.
Jeg siger også i videoen, at de sidste fem procent kan tage tre-fire gange så lang tid som resten, når man får at vide, at et projekt er 95 procent færdigt. Det er min hårde erfaringsregel, ikke en beregning, der gælder alle IT-projekter.
Min besked er, at du skal have plads til mere arbejde, end det første optimistiske tal måske får dig til at tro.
En dygtig projektleder kan oversætte mellem jer
Hvis du ikke har forstand på IT og ikke er vant til at arbejde med tekniske mennesker, kan du blive utrolig skuffet og forvirret. I værste fald kan projektet være med til at vælte din forretning.
Du er måske ikke teknisk kvalificeret til at beskrive hele opgaven. Og den anden part er måske ikke god til at spørge ind til dine forventninger og omsætte dem til en aftale, I begge forstår.
Derfor synes jeg, det er svinevigtigt at have dygtige projektledere. Og derfor skal du alliere dig med nogen, som kan hjælpe, hvis du ikke selv har den erfaring.
Jeg regner med store ekstra margener på tid og pris og med, at jeg skal have meget tålmodighed. Det er sådan, jeg selv håndterer de her projekter.
Det behøver ikke være dig eller programmøren, der er noget galt med. Det kan være kommunikationen, der vælter det hele.
Jeg sammenligner det til sidst med mænd og kvinder, som kan tale forbi hinanden og blive rasende, fordi de synes, de allerede har sagt noget ti gange. Den anden har bare ikke hørt det på samme måde.
Så god fornøjelse med projekterne. Husk pi som min lidt grove påmindelse om at give både tidsrammen og prisen mere luft.
Alle iværksættere skal på nettet og derfor kommer de sjældent uden om at snakke med teknikere og programmører og det går som regel galt…
Dbh Martin
Heheheh… "Gange med pi" Ret god regel faktisk 🙂
Godt indlæg, Martin!