Vi liker å si at vi setter brukernes behov i fokus. De fleste bedrifter som ønsker å fremstå som moderne, gjør det. Men hvor mange bedrifter, ikke bare tillater, men oppfordrer ansatte til å stoppe opp og sette av tid til å fundere - og ikke bare utføre, utføre, utføre? Vi i CoWork gjør det. Ikke bare for hver og en alene, men gjerne sammen med en eller flere kollegaer. Vi tillater oss å heve føttene høyt, lene oss tilbake og si “nå vet jeg ikke helt hvordan jeg skal løse dette”. Uten blygsel.
Slike stopp-tenk! øyeblikk kan gi resultater man ikke på forhånd ville gjettet på. Ofte, for oss teknologer, handler det om ting som arkitektur og forretningsdomener. Hva har brukeren egentlig behov for her? Hva er egentlig “the job to be done”? Men av og til pipler de små tingene opp. Du vet, detaljene. Her kommer en liten historie om en slik detalj som kan virke som en ubetydelighet, den illustrerer dog noe rundt hvordan vi bestandig leter etter forbedringer av det vi driver med i CoWork.
Vi skulle lage en integrasjon mellom et nettsted og et forsikringssystem for å vise priser på forsikringsprodukter. Overordnet informasjonsflyt var: Nettstedet kaller vår integrasjonsmodul som igjen henter priser fra forsikringssystemet og får tilbake en pris. Greit nok det. Og oppstår det en feil, sender vi en feilmelding som fanges opp i nettstedet og det kan håndteres adekvat der.
Men fremtiden er en volatil kompis. Hva skjer når en eller annen ny konsulent kommer inn i kodebasen på nettstedet og gjør endringer? Det er akkurat her jeg og en kollega stoppet opp og tillatte oss å tenke. Hvis feilhåndteringen i nettstedet ble svekket (som kan skje i programvare når utviklere er i overkant stresset, nye krav kommer til og forretningslogikk ikke er backet opp av automatiske tester) og det oppstode en feil i integrasjonen, ville prisen som ble presentert på nettsiden bli 0,- kroner. En sluttbruker ville kanskje oppfatte det som litt rart, hvis brukeren i det hele tatt la merke til det. Var det noe vi kunne gjøre her som bedret situasjonen - om enn bare litt? Og inn fra siden kom det et forslag som vi etter hvert har døpt til Krilic’ number. Dette er ikke ett bestemt tall, men et tall som skiller seg ut. Krilic’ number er:
Et tall valgt for å klart identifisere en utilsiktet tilstand eller feilsituasjon i et programvaresystem, som ikke vil bli forvekslet med reelle tall systemet kan tenke seg å bruke.
Tallet brukes spesielt i situasjoner der det kan bli eksponert direkte til bruker av et programvaresystem for å høyne sjansen for at brukeren legger merke til feilsituasjonen og kan reagere. Høye, negative primtall er foretrukket, da vi tror at spesielt partall kan gi mennesker et falskt inntrykk av at tallet har informasjon ut over funksjonen i normal tilstand. I tillegg vil høye primtall redusere risiko for at tallet samsvarer med andre tall i systemet og dermed forårsaker forvirring, både for sluttbrukere og teknikere.
Vi bestemte oss for å teste dette ut og returnerte -17 i tillegg til normal feilmelding. Og skulle du ha sett - allerede neste dag oppstod en slik situasjon. Umiddelbart fikk vi respons fra testere fra forretningssiden til vår oppdragsgiver. “Det må være noe feil med prisene på produktene - det står jo at det koster -17 kroner.” Nå skal jeg ikke påstå at ikke denne personen også ville reagert hvis prisen hadde stått til 0,- kroner, hen er for dyktig til det. Men jeg påstår at Krilic’ number gjorde det mye mer synlig. 0,- kroner er mistenkelig, -17 kroner er åpentbart feil.
Krilic' number illustrerer hvordan selv små detaljer kan bidra til kvalitet og pålitelighet i programvaren vi bygger. I CoWork vet vi at det er nettopp slike gjennomtenkte valg som gjør en forskjell, både for utviklere, kunder og brukere. Når vi tar oss tid til å stoppe opp, til å stille spørsmål og finne unike løsninger, skaper vi mer enn bare kode – vi bygger systemer som kommuniserer tydelig, også når noe går galt. Krilic' number er en påminnelse om vår forpliktelse til å sette brukeren i fokus, ikke bare med ord, men gjennom praktiske valg i hvert eneste prosjekt.
