“Hvordan kan du levere et godt produkt om du ikke bryr deg om å forstå kundens opplevelse? Kunden selv har aldri bygget kjøkken før. Det har du.”

Siden EDB kom til verden hvor vi måtte lære oss å programmere “bits & bytes” og frem til i dag, har både  kravet og egenskapene til den moderne programmereren endret seg. Fra barneårene med prøving og feiling, gjennom tenårene i kjelleren, til en voksen person som er likestilt med andre voksne jobber. Dessverre har ikke alle den samme forståelsen av hva en programmerer kan og bør gjøre. Noen programmerere er fortsatt mentalt i kjelleren og bør komme seg opp og få litt lys og oversikt. Noen ledere ser fortsatt på programmereren som “hodet” som trenger å bli fortalt hva som skal gjøres.

Programmereren har aldri vært opptatt av penger og makt (det er alltid noen unntak selvfølgelig…). Indre drivkraft har vært å løse analytiske utfordringer og få datamaskinen til å gjøre ting – gjerne nyttige ting. Man har vært opptatt av å lage, leke og lære.

Med Internett ble det raskt et behov å forstå forretning og kommunikasjon også, i tillegg til selve teknologien. Flere fagområder ble tatt inn på teamet i utviklingen av IT-systemer. Programmereren ble etterhvert degradert og plassert stillesittende i et hjørne. Flere og flere lærte seg å programmere og gjorde kompetansen tilgjengelig blant mange – ihvertfall på papiret. Håndverket er programmering. Noen kaller dem hoder, kodere eller utviklere. Og da kommer raskt assosiasjonen til nerdene som sitter nede i en mørk kjeller. Code monkeys. Gi dem dem nok bananer og la dem være i fred.

Jeg mener at alle programmerere, og prosjektdeltagere forsåvidt, kan bidra i mye større grad om vi klarer aktivisere hele mennesket i oss og fremprovosere den kollektive kunnskapen. Da vil vi ta de klokeste beslutningene. Da kan vi etterhvert også få ned størrelsen på teamene og en mye mer effektiv kommunikasjon og beslutningeprosess i utviklingen av produktet. Det krever at vi forstår programmeringens moderne rolle.

Må forstå brukereffekten

Nå som “alle” kan lage sine egne programmer og app´er, og gjøre de tilgjengelige for alle, så er utfordringen en helt annen. I mange tilfeller så vet man ikke hvem brukeren er og hva de egentlig ønsker seg. I større grad enn før er det ekstrem usikkerhet knyttet til hva som er den beste løsningen. Brukbarhetseksperten blir inhabil og brukeren selv vet sjelden hvilke muligheter som finnes. Svaret finnes et sted i mellom (mer om dette i artikkelen “The User Feedback Problem” av Anders Haugeto). Og for å finne svaret trenger vi i dag det vi hos oss kaller Produktutvikleren som både evner og ønsker å forstå helheten.

En forblåst høstdag i oktober 2006…

Scrum Master: – Vi har nå fire måneder på å implementere den nye selvbetjeningsløsningen. Den skal produksjonsettes 15. februar 2007.

Produkteier: – Vi har nå skrevet om kravspesifikasjonen til brukerhistorier, som jeg har prioritert i en såkalt backlogg.

Scrum Master: – Vi har fått laget alle skjermbilder og knyttet dem til brukerhistoriene. Så da er det bare å gyve løs på oppgavene!

Programmererne: OK, vi kan klare 3-4 brukerhistorier til demonstrasjonen om to uker.

Programmereren er navet

I dag er produktutvikleren på full fart tilbake som sentral midtbanespiller på laget. Det nytter ikke lenger å ha masse eksperter og teoretikere som bare synser. Synsingen må testes ut i produksjon raskt. Det er produktutvikleren som må programmere og sørge for å kunne legge ut ny kode raskt for å verifisere hypotesene om hva som er riktig løsning. Produktutvikleren må kunne logge, analysere og ha et forhold til hvilken effekt endringer har på brukeren. Og som i gamle dager på samlebåndet hos Toyota, er det produktutvikleren som må stoppe båndet, når noe er feil og utbedre dette. Gjerne i samarbeid med andre fagfelt. Produktutvikleren må være en innovatør (mer om dette i bloggartikkelen; Developer´s DNA). Men, ingen andre fagfelt vil noen gang kunne være en like effektiv erstatning.

…en kald og klar vinterdag i 2012…

Produkteier: – Ledelsen ønsker at vi fokuserer mer på å skape lojale brukere

Programmerer 1: – Hvordan kan vi vite om brukerne våre er mer lojale?

Produkteier: – Det er vår første oppgave å finne ut av. Vi skal definere en måleparameter som skal gi oss en indikasjon på lojalitet

Programmerer 2: – Jeg kan finne ut hvor mange som har besøkt oss mer enn en gang. Hvis brukeren kommer tilbake så er vel det tegn på lojalitet? Eller hva UX?

UX: – Jo, men erfaringsvis så er den sterkeste tegn på lojalitet brukere som er villige til å komme tilbake å bruke penger igjen.

Programmerer 3: – Det kan vi også logge.

Produkteier: – Bra! Da rapporterer jeg tilbake til ledelsen at vi vil starte med å logge hvor mange brukere som kjøper noe mer enn én gang. Når kan vi ha de første resultatene klare?

UX: – Vi bør nok logge det over en periode på to uker, og gjerne få med datostempel for å kunne lese ut når på døgnet de kjøper.

Programmerer 1: – Vi bør kunne starte loggingen i løpet av morgendagen, så kan vi implementere en enkel rapport/visning i løpet av perioden, som vi kan vise til ledelsen.

Produktutvikleren forstår helheten

Vi gjør oss selv en bjørnetjeneste om vi tror at en programmerer ikke trenger å forstå helheten. Den moderne programmereren – produktutvikleren – må forstå. Hvordan kan du vite om snekkeren lager et møbel du vil være fornøyd med om han ikke forstår behovet? Skal du stå å passe på snekkeren mens han jobber? Liker du når andre kikker over din skulder? Har du ikke viktigere ting å gjøre?

Tre måneder senere…på morgenmøtet…mens våren trenger inn gjennom vinduet…

Programmerer 1: – Siste periode viser at gjenkjøpsgraden har økt med 1,3%

Programmerer 2: – Det er litt lavere enn vi håpet, men jeg kan også se at 22% har falt av på steg tre i betalingsprosessen hvor vi la inn tre nye valgalternativer for to dager siden.

UX: Av de som har fullført, har under 5% valgt alternativ b og c.

Produkteier: Da prøver vi å fjerne de alternativene igjen.

Programmerer 3: Ehh… jeg gjorde det i går ettermiddag da jeg hadde samme mistanke…

Produkteier: Jasså?!

Programmerer 3: Ja, altså…

Produkteier: – Ja, men fortell da! Hvilken effekt hadde det?

Programmerer 3: Kun 3% har falt av på steg tre, siden jeg produksjonsatte endringen.

Produkteier: Bra! Jeg har fått ett innspill fra ledelsen om at de ser behovet for å possisjonere oss sterkere gjennom mobilkanalen, og de vil gjerne ha forslag til hvordan vi kan måle dette og hva vårt første eksperiment skal være…

Det jeg forsøker å formidle her. Er det samme som bl.a. Eric Ries har erfart og forsøker å formidle, fra en investor´s ståsted, i boken sin “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses”. Jeg har valgt å kalle en moderne programmerer for en Produktutvikler, fordi det er veldig betegnende for hvordan rollen bør utøves i moderne tid. Forstå målet. Eksperimentere. Analysere. Lære. Forbedre. Og iterere i takt med omgivelsene. Løp og kjøp!