Where’s the pain?
“Spesifikasjoner av krav er ikke bare uhensiktsmessig, det er helt galt”. Kent spiller orgelkantater av Bach mens han varmer hendene på tekoppen. Kontorveggene er kledd fra gulv til tak med en imponerende samling og nesten surrealistisk blanding av faglitteratur. Shakespeares samlede verker – illustrated version, en bok om flykrasj gjennom historien – og hva man lærte fra dem, kompilatordesign, logikkprogrammering, design patterns, optimalisering av Java-kode, hvordan være en god far …
Vi har funnet oss hver vår stol i et kontor tydelig innredet etter Kents måte å jobbe på: 2 pulter, 2 skjermer, 4 stoler. Her jobber man i par, ingen tvil. “Men i store, komplekse prosjekter må vi jo ha en avsjekk fra kunden på hva som skal utvikles”. Jeg tar meg selv i argumentere imot. En smule ambisiøst til å være tidlig på morgenkvisten. Har ikke lyst til å gjøre han sint heller.
Han smiler og forklarer med tålmodig stemme: En kravspesifikasjon har en aura av noe absolutt over seg. Og det til tross for at vi driver med utvikling. Ville du stilt detaljerte krav til piloten når du gikk ombord i flyet? Take-off-hastighet, marsjhøyde, rutevalg? Nei, du sier istedenfor at du er invitert på fest i Trondheim og vil gjerne komme deg dit i en fei.
Slik er det med programvareutvikling også, sier Kent. Det er historiene bak funksjonaliteten som inneholder kruttet. Det som får oss til å utvikle. Ikke bare grave oss ned i gudsjammelig kjedelige matriser, tabeller og punktlister.
For å kjenne på kroppen Kents måte å tenke på har vi bestemt oss for å utvikle et helt reelt system. IT-støtte for Individuell Plan, et regime for å gjøre samarbeidet enklere mellom pasienter med komplekse sykdomsbilder og alle involverte funksjoner. Leger, fysioterapeuter, ergoterapeuter osv. “Tenk på den historien Alice forteller sin betrodde venninne når hun har brukt systemet deres for første gang!” messer Kent. “Før måtte jeg ringe rundt og ingen hadde oversikt. Avtaler med de som behandlet meg kom i feil rekkefølge og alt var bare fullstendig ukoordinert! Nå bruker vi dette systemet der alle kan logge seg på og se hva som skjer”.
Det dreier seg om å finne smerte. Hva er det som plager brukerne så mye at de nesten har problemer med å snakke om det? Hva er det de vil oppleve som en stor forbedring av sin hverdag? Det er disse historiene vi er ute etter.
Fremgangsmåten kan være enkel:
- Finn ut hvor det gjør “vondt” for brukerne dine. Hva er upraktisk og tidkrevende i deres arbeidsprosesser?
- Verifiser at de faktisk er klar over disse problemene. Vet de at det smerter?
- Hva er “workarounds”? Hva gjør de for å komme rundt problemene?
- Hva slags budsjett har de mulighet til å bruke på et system?
“Det er typisk for oss systemuviklere å tenke på systemutvikling” fortsetter han mens han vandrer filosofisk frem og tilbake foran bokhyllen. Av og til plukker han ut bøker vi skal lese. Alltid et spørsmål om vi allerede har lest den. Gang på gang innrømmer vi med en viss flauhet at “den boken der var nok også ny for meg”. Kent har lest dem alle, fra perm til perm. Han er som en bibliotekar som kan hele samlingen sin utenat.
“Før dere får lov til å programmere noe som helst skal dere vise meg at dere kan tre ut av rollen som systemutviklere”. Vi ser på hverandre. Ingeniørene i oss sitrer etter å komme igang med håndtverket, og få se Kentern “in action”. Men vi må gjøre som Kent, og ile langsomt. Gå inn i hodet til sluttbrukeren og kunden og tenke på hva de trenger. Og ikke nok med det: Vi får også krevende spørsmål om forretningsmodeller og kommersielle betingelser. “Hvordan skal dere ta betalt for dette systemet? Jeg lager aldri noe som helst, før jeg har bestemt meg for betalingsmodell. Det styrer hele produktet” sier han mens vi ligger under benken og prøver å koble laptoppene våre til amerikanske stikk-kontakter.
Dette har vi heldigvis tenkt på, og han synes vi er på riktig spor. Hvis du tar betalt for et system én gang og deretter overlater det til kunden, havner du fort i et dilemma når en ny kunde dukker opp. Den nye kunden vil ha funksjonalitet X, som du mangler, mens den eksisterende kunden vil ha funksjonalitet Y, som du også mangler. Med denne betalingsmodellen vil du favorisere den nye kunden. Du vil rett og slett nedprioritere en eksisterende kunde, selvom alle vet at dette er idiotisk. Jeg vil aldri havne i en slik situasjon sier han og peker på abonnementsordninger istedenfor. Da er alle kundene “nye” i den forstand at de når som helst kan kansellere abonnementet. Du ender opp med å prioritere bedre, og kundene dine får en bedre tjeneste.
Imorgen får vi forhåpentligvis lov til å begynne programmeringen …
