Det som ofte mangler når programvaren nesten virker

En demo kan se ferdig ut lenge før systemet er ferdig. Skjermene henger sammen, de viktigste knappene reagerer, og den planlagte presentasjonen går fint. Så kommer en hel arbeidsdag, en uventet retur, en manglende godkjenning eller en operatør som må rette opp noe. Da viser det seg hva som faktisk mangler.

Dette betyr ikke at alle forsinkede programvareprosjekter har samme problem. Men når et viktig produkt eller internt verktøy stadig omtales som nesten ferdig, er det nyttig å undersøke sammenhengen før teamet legger på enda en synlig funksjon.

En demo beviser en mulighet, ikke hele driften

En god demo svarer på et viktig spørsmål: Kan denne ideen fungere? Den kan vise retning, skape forståelse og gjøre et abstrakt konsept konkret. Det er verdifullt.

Et driftbart system må svare på flere spørsmål. Hva skjer før den gode skjermen? Hva skjer etterpå? Hvem kan gjøre hva? Hvilke data er autoritative? Hvordan oppdager vi at noe gikk galt, og hvordan kommer vi videre uten å gjette?

Forskjellen ligger ofte ikke i én stor manglende funksjon, men i forbindelsene mellom de delene som allerede finnes.

Følg én virkelig arbeidsflyt fra start til slutt

Velg en vanlig, viktig oppgave. Ikke start på forsiden eller i funksjonslisten; start der arbeidet faktisk begynner. Følg oppgaven til den er ferdig for både brukeren og organisasjonen.

For en bestilling kan det bety opprettelse, kontroll, betaling, behandling, levering, avvik og eventuell refusjon. For et internt godkjenningsverktøy kan det bety innsending, dokumentkontroll, tildeling, vurdering, retur, ny innsending, beslutning og etterprøvbar lagring.

Spør underveis:

• Finnes hvert nødvendig steg, også det som utføres av en operatør?
• Bevarer systemet nok kontekst når ansvaret flyttes mellom roller?
• Kan oppgaven avsluttes uten et skjult regneark, en privat melding eller direkte databaseendring?
• Er det tydelig for neste person hva som har skjedd og hva som må skje nå?

Hvis arbeidsflyten må forlate systemet for å bli komplett, er det en konkret observasjon. Det er mer nyttig enn å si at produktet føles 90 prosent ferdig.

Gjør forretningsreglene synlige

Mange nesten ferdige systemer har regler, men reglene bor i hodet til en erfaren medarbeider, i en gammel e-posttråd eller i betingelser spredt over flere kodeområder. Da kan standardsituasjonen fungere mens reell variasjon blir uforutsigbar.

Skriv ned de viktigste beslutningene i vanlig språk:

1. Hvilke betingelser må være oppfylt før saken kan gå videre?
2. Hvem kan overstyre en beslutning, og hva må dokumenteres?
3. Hvilke verdier kan endres etter godkjenning?
4. Hva skjer når to regler peker i ulik retning?
5. Hvilken dato, pris eller status gjelder når grunnlaget endres underveis?

Reglene trenger ikke bli en tung håndbok. De må være presise nok til at produkt, utvikling og drift kan teste samme forventning.

Unntakene er en del av produktet

Tomt lager, duplikater, avbrutt betaling, utløpt tilgang, korrigerte personopplysninger og dokumenter i feil format er ikke nødvendigvis sjeldne tekniske kuriositeter. De er situasjoner virksomheten må håndtere.

Lag en kort liste over hendelser som bryter den ideelle banen. For hvert unntak bør teamet vite:

• hvordan systemet oppdager det;
• hvilken tilstand saken får;
• hvem som blir varslet;
• hvilke handlinger som er trygge;
• hva som aldri skal kunne skje automatisk.

Dette flytter samtalen fra vi må håndtere feil til en konkret modell for feil, gjenoppretting og nytt forsøk. Et nytt forsøk må for eksempel være idempotent når dobbel behandling kan gi dobbel belastning eller doble utsendelser.

Bestem hvilken kilde som forteller sannheten

Når status finnes i produktdatabasen, betalingssystemet, CRM-et og et regneark, kan alle skjermene se plausible ut samtidig som organisasjonen mangler ett pålitelig svar.

For hver kritiske opplysning bør det være mulig å peke på en kilde som er autoritativ, og på en tydelig regel for hvordan andre systemer oppdateres. Hvis systemene er uenige, må noen vite hvilken verdi som vinner, hvordan avviket oppdages og hvem som eier oppryddingen.

Kilde til sannhet er derfor ikke bare et databasevalg. Det er en avtale mellom data, prosess og ansvar.

Operatøren trenger kontroll, ikke bare innsyn

Et administrasjonspanel som viser en feil uten å tilby en trygg handling, flytter bare problemet. Operatøren ender fortsatt i en supportkanal eller ber en utvikler rette data manuelt.

Nyttige operatørkontroller kan være å sende en jobb på nytt, sette en sak på vent, korrigere en tillatt verdi, tilbakeføre en overgang eller markere at et avvik er undersøkt. Hver kontroll bør ha tydelig omfang, bekreftelse, tilgangsstyring og et spor som viser hvem som gjorde hva.

Her møtes eierskap og tillatelser. Hvem eier saken når den stopper? Hvilken rolle kan se følsomme opplysninger? Hvem kan utføre en irreversibel handling? Hvem kan gi eller fjerne denne tilgangen? Uklare svar er en del av produktgapet, ikke et problem som kan skyves til lanseringsdagen.

Planlegg feil, gjenoppretting og nye forsøk

Det holder ikke å vise en rød feilmelding. Teamet må vite om handlingen ble utført helt, delvis eller ikke i det hele tatt. Brukeren må få et ærlig svar, og operatøren må ha nok informasjon til å ta neste steg.

Undersøk minst disse situasjonene:

• En ekstern tjeneste svarer sent eller to ganger.
• Nettleseren mister forbindelsen etter at brukeren trykker Send.
• Ett av flere delsteg lykkes før det neste feiler.
• En planlagt jobb stopper og starter på nytt.
• En operatør forsøker å rette saken mens en automatisk prosess fortsatt arbeider.

For hver situasjon: Kan handlingen prøves på nytt uten dobbel effekt? Kan systemet fortsette fra et kjent punkt? Finnes det nok logging til å forstå hendelsen uten å lagre mer persondata enn nødvendig?

Flere funksjoner kan gjøre avslutningen fjernere

Når kjernen virker ustabil, er det fristende å legge til noe som er lett å vise frem. En ny graf, et filter eller en integrasjon gir synlig fremdrift. Men hver ny funksjon kan også legge til flere tilstander, regler, tillatelser og feilbaner.

Sett derfor en midlertidig grense rundt den viktigste arbeidsflyten. Fullfør reglene, unntakene og kontrollene som gjør akkurat dette løpet pålitelig. Nye synlige funksjoner kan vente dersom de ikke fjerner et dokumentert hinder i den avgrensede flyten.

En diagnose teamet kan gjøre denne uken

Samle én person fra produkt, utvikling og den operative siden. Velg én reell sak, gjerne en som tidligere har stoppet. Tegn hvert steg og marker hvor systemet, et menneske eller en ekstern tjeneste har ansvaret.

Bruk disse spørsmålene:

1. Hvor forlater arbeidet systemet i dag?
2. Hvilke beslutninger avhenger av regler som ikke er skrevet ned?
3. Hvilke unntak krever direkte hjelp fra en utvikler?
4. Hvilken kilde avgjør status, penger og tilgang?
5. Hvem eier en stoppet sak, og hvilke kontroller har personen?
6. Hva ser brukeren dersom et delsteg feiler?
7. Hva kan trygt prøves på nytt?
8. Hvilket bevis trenger vi for å si at hele flyten virker?

Resultatet bør være en kort liste over konkrete hull, ikke en ny ønskeliste. Da blir det lettere å velge den minste sammenhengende leveransen som gjør systemet mer pålitelig.

Hvis denne typen avgrenset fullføring er selve oppgaven, beskriver Product Completion Sprint hvordan jeg vanligvis rammer inn arbeidet.