Dette er en ørlite omarbeidet versjon av en artikkel som ble sendt til Computerworld hvor en svært forkortet utgave ble trykket.
I Computerworld 6⁄7 2005 diskuteres det hvorfor IT-prosjekter går over tid og budsjett. Det hevdes at den viktigste årsaken er dårlig prosjektledelse. Jeg hevder at en av komponentene i dårlig prosjektledelse som vanligvis blir oversett, er forståelse av hvordan programmerere samhandler. I det følgende vil jeg presentere hva nyere forskning sier om hva prosjektledere, for å kunne utøve god prosjektledelse, bør vite om programmerere.
Det finnes ganske mye utenlandsk litteratur som kan kaste lys over programmererens atferd. Mange kjenner klassikere som «The Second Self» (Turkle, 1984), «The Hacker’s Dictionary» (Raymond, 1996), «Hackers» (Levy, 1984), «True Names» (Vinge, 1981), «Hiring is Obsolete» (Graham, 2005) og «Teach Yourself Programming in Ten Years» (Norvig, 2001). Denne litteraturen gir til dels svært spennende situasjonsbeskrivelser men sier ikke så mye om hva som kan gjøres. Norsk forskning på programmerere ser ut til å glimre med sitt fravær – i den grad det er gjort forskning later den ikke til å være publisert.
Tom deMarco og Joel Spolsky har skrevet underholdende og refklekterte bøker om prosjektstyring og ymist anna, om enn lite eller bare indirekte om personlighet. Spolsky sier at han ansetter programmerere bare dersom de er smarte og kan levere, men metoden han bruker er intervju. Han hadde antagelig truffet bedre om han styrket intervjene ved også å teste IQ, og sannsynligvis også den personlighetsfaktoren som innen moderne personlighetspsykolog kalles faktor III eller kontroll (på engelsk: «conscientiousness»).
En nylig amerikansk undersøkelse av 1000 firmaer som er representert i Fortune 2000 viste at ledere ikke hadde noen tro på psykologiske faktorer som suksessfaktor hos IT-ansatte. Det er kanskje ikke så rart det finnes så lite forskning rundt dette. Den forskningen som finnes tyder imidlertid på at psykologiske faktorer kan ha stor betydning.
Denne artikkelen er basert på en gjennomgåelse av den offentlig tilgjengelige forskningslitteraturen som har vært publisert de siste femten år. Denne kunnskapen foreligger stort sett i form av vitenskapelige artikler og ikke i form av bøker med glanset omslag, så den er ikke så godt kjent.
Det er viktig å merke seg at det som har vært gjennomgått stort sett er amerikansk litteratur og at beskrivelsene først og fremst gjelder amerikanske programmerere. Hvordan det er i Norge kan vi ennå dessverre bare anta.
I litteraturen ser det ut til at det bare skilles mellom to typer softwareutviklere: Systemerere og programmerere.
En vanlig metode for å lete etter den mest produktive søkeren til en stilling omfatter å bruke en personlighetstest. Dette er problematisk når det gjelder programmerere. Det finnes svært lite forskning som kaster lys over hvilke personlige egenskaper en dyktig programmerer bør ha. Det er ennå ikke enighet om noen metode for å måle produktivitet hos programmerere, noe som er en forutsetning for å kunne finne sammenhenger mellom personlighet og produktivitet. Mye av den forskningen på programmerere som finnes later til å være utført av ingeniører uten kontakt med arbeidspsykologisk forskning. Konsekvensen av dette er pussige valg når det gjelder både hvilken test og hvilken forskningsmetodikk som brukes. Resten av forskningen later til å være gjort av psykologer som er mer interessert i å studere kultur og samhandling hos programmere, enn produktivitet. Seriøse rekrutteringsbyrårer legger altså ikke allverdens vekt på personlighetstesten som en del av seleksjonsmetode ved rekruttering av programmerere, men tilsvarende stor vekt på den oppfølgningssamtalen som skal finne sted en stund etter ansettelsen.
Å kode
Det er ikke dokumentert noen sammenheng mellom personlighet og dyktighet som programmerer. Dette kan skyldes at forskningen innen området altså har vært litt vilkårlig: Det bør være sammenheng mellom leveringsdyktighet og tendens til å være samvittighetsfull. Gode programmerere identifiserer man ved evne- og ferdighetstester. Imidlertid er det en sammenheng mellom personlighet og ønske om å bli programmerer. Den type personlighet som ønsker å bli programmerer har høy risiko for å danne kulturer som er vanskelige å forstå, for å utvikle uheldige måter å kommunisere på, og for å utvikle gruppeprosesser med uheldige trekk.
Dyktige programmerere er vant med å være den flinkeste gutten i klassen. Dette vil de helst fortsette å være. Konsekvensen er at de begynner seint på prosjektet, de vil løse alle problemene selv, de spør ikke etter hjelp. Når det går galt er det fordi de ikke innser at de ikke får det til før det er for seint å ta tak for å holde seg til fristen. De har massevis av gode ideer og innser ikke nødvendigvis at de vil slippe opp for dem. De kan tenke så intenst rundt problemet at de opplever en følelse av at problemet er løst uten at det er det. Vi sier, igjen, at ikke alle programmerere er sånn – bare mange nok til at man må være oppmerksom på det.
Programmerere har gjerne en introvert arbeidsstil. Det betyr at de kommuniserer lite, i hvert fall om faget. Det henger delvis sammen med at de ønsker å løse oppgavene selv. Det er veldig vanskelig å se hvor mye en programmerer har gjort, mens programmereren føler på kroppen hvor mye han eller hun har gjort. I verste fall ender man – ifølge forskningen ikke rent sjelden – opp med team hvor alle programmerere ser på seg selv som den som drar lasset og alle de andre som snyltere. Slike holdninger er vanskelige både å identifisere og oppklare.
Alan Cooper skriver («The Inmates Are Running The Asylum», 2004) at før man skyter så mye som en meter film i Hollywood, er dreieboka ferdig skrevet. Man oppdager bare ikke midt inne i filmingen at plotet ikke henger sammen – å filme er så dyrt at slikt tar man ikke sjansen på. Tilsvarende er det for andre velutviklede profesjoner, som for eksempel innenfor bygg og anlegg: Man har standardiserte og velutviklede metoder for å sørge for at alt er klappet og klart på papiret før første spadetak tas. Og selv da ryker budsjettet og tidsplanen. Programmerere derimot, de kaster seg med friskt mot ut i store, kompliserte prosjekter med bare en vag formening om hvordan det skal skrus sammen – men med rike indre bilder av hvordan prosjektet skal være, og en sterk overbevisning om at dette skal man da få til! Det later til at det er noe med personligheten som gjør at man begynner å kode altfor tidlig.
Prosjektledere må være klar over at mange programmerere trenger trening i å gi dårlige nyheter. De trenger trening i å tape. De trenger trening i å samhandle med andre mennesker på jobb. De trenger trening i å planlegge før de koder.
Å få aksept hos brukeren
Programmerere ser på seg selv om en egen gruppe – de er «innenfor». De andre, for eksempel brukerne, er «utenfor». Dette er typisk i alle sosiale sammenhenger – mennesker danner inn- og utgrupper. Inn- og utgrupper karikerer hverandre og mistror hverandre (Se for eksempel «Group Processes» (Rupert Brown, 2000)). Dette er ikke spesielt for programmerere og brukere, men det gir visse interessante utslag.
Hvis en leder skal få med seg en prosjektgruppe, er en velkjent teknikk at lederen gir prosjektgruppa eierskap i prosjektet. Lederen gir prosjektgruppa mulighet til å komme med forslag og innspill, og gir prosjektgruppa tilbakemelding og setter opp prosjektet i lys av prosjektgruppas forslag og innspill slik at medlemmene føler seg sett, møtt og forstått. Ikke programmerere. Det er de, og ikke brukerne, som er inne og som vet. Resultatet er at brukerne ikke blir tatt med på råd, de blir ikke hørt, de får ingen mulighet til eierskap. Programmererne på sin side svarer med at når brukerne sliter lenge med å forstå softwaren er det fordi det er en tilvenningsprosess, all forandring og innlæring er vanskelig, og dessuten er de idioter. Når brukerne så vraker produktet deres til fordel for software med en tiendedel av funksjonaliteten men med et brukergrensesnitt som er mulig å forstå, skjønner de gjerne ingenting. Noen softwarefirmaer er enestående unntak her: Apple, Amazon, Palm. Apples legendariske kundelojalitet skyldes at Apple kan noen helt enkle psykologiske grep som hvem som helst kan lære seg men som fortoner seg som magi for den uinnvidde.
Å lede erfarne softwareuviklere sies å være av samme vanskelighetsgrad som å gjete katter. Vår uærbødige påstand er at mens katter likevel har det best når de ikke gjetes, er det mulig å lære nok om programmerere til å få dem til å yte atskillig bedre enn det som vanligvis er tilfelle under softwareutviklingsprosjekter.
Vi har erfart at oppfølgingssamtalen kan utgjøre forskjellen mellom suksess og fiasko i en rekrutteringsprosess. Seriøse rekrutteringsbyråer leverer alltid en «bruksanvisning» med kandidatene de leverer. Vi har erfaring med at å det å kontrollere at «bruksanvisningen» blir fulgt, og å ha kompetanse til å gi råd og veildning når den (av og til med god grunn – som f.eks. nødvendige endringer i stillingsinnstruksen pga. endringer i markedet) ikke blir det, kan være forskjellen mellom suksess og fiasko i en rekrutteringsprosess.
Vi antar altså at mange – ikke alle – programmerere har særegenheter som går igjen men som ikke er så godt forstått. I oppfølgningssamtalen kan det sjekkes ut om denne forståelsen er nødvendig og om den er til stede.
Hva alle softwareutviklingsprosjektledere burde vite
En systematisk gjennomgåelse av nylig litteratur om suksessfaktorer i softwareutviklingsprosjekter gir faktisk ganske mye interessant informasjon som på en eller annen måte henger sammen med særegenheter i programmereres personlighet.
- Programmerere bør bruke programmeringsspråk de kan. Det tar for lang tid å lære et nytt programmeringsspråk etter at prosjektet har startet.
- Prosjektspesifikasjonene kommer til å endre seg underveis, så at det kommer til å bli endringer bør være en del av prosjektplanen. Agile metoder er ei av flere løsninger på dette.
- Det er ikke alltid sant at å føre flere mennesker inn i et forsinket prosjekt gjør det enda mer forsinket.
- Prosjektlederen må til enhver tid vite hvor langt hver enkelt programmerer er kommet, slik at behov for ekstra tiltak er kjent i tide.
- De dyktigste programmererne kan flere forskjelligartede programmeringsspråk. De bør oppmuntres til å fortsette med dét.
- De dyktigste programmererne skårer høyt på IQ-tester.
- Dyktige prosjektledere blir ferdig i tide fordi de inngår kompromisser og fjerner unødvendig funksjonalitet. Tidlig i prosjektet bør det lages en liste over funksjonalitet som kan ofres.
- Det er ikke alltid oppdragsgiver selv er klar over hva han eller hun vil ha. Det må brukes nok tid i innledende faser til å bli sikker på at oppdragsgiver og kontraktør forstår hverandre.
- Utviklingen av brukergrensesnittet er et eget fagfelt som krever egen kompetanse. Hvor viktig dette er blir nesten alltid undervurdert.
- Individuelle forskjeller i produktivitet er enorme. De dyktigste programmererne kan være så mye som ni ganger så produktive som gjennomsnittlige programmerere (Dette med forbehold om at det er vanskelig å måle produktivitet hos programmerere).
- Jo lenger opp i linja en leder er, desto mindre realistisk bilde har vedkommende av årsaker til overforbruk at tid og penger, selv om lederen selv har ledet softwareutviklingsprosjekter. Prosjektledere glemmer uhyggelig fort hva som var problemene da de ledet prosjekter.
- Prosjektplaner er notorisk urealistiske. Alle som leverer inn et tilbud på software lyver, og dette vet man på begge sider av bordet. Kontrakten går til den dyktigste løgneren. Når tidsplanen og budsjettet sprekker, er det ingen som blir overrasket. Dette igjen leder til en kultur hvor overskridelser blir sett på som noe man må forvente.
Det trengs fortsatt mye mer forskning som går direkte på hvilke egenskaper dyktige programmerere bør ha. Vår påstand er at det dog finnes svært mye forskning som kan bidra drastisk til å øke effektiviteten i softwareutvikling dersom den brukes klokt. Rekrutteringsbyråene bør kjenne denne forskningen og bruke den i rekruttering og innføring av programmerere.
Norwegian