Alle er enige om at planlegging lønner seg. Færre har et konkret bilde av hvor mye, og hvilke beslutninger det faktisk gjelder. Det er verdt å se nærmere på, fordi det forklarer hvorfor to prosjekter med samme omfang kan ende med svært ulik regning.
Kjernen er enkel: den samme endringen blir dyrere jo lenger ut i prosjektet den kommer.
Hva en endring koster på ulike tidspunkt
Si at dere oppdager at et skjermbilde mangler et valg.
I skissefasen er dette å flytte en grå boks. Fem minutter. I den klikkbare prototypen er det litt mer, kanskje en halvtime, fordi designet må justeres og koblingene oppdateres.
Etter at skjermbildet er bygget, må utvikleren endre grensesnittet, sannsynligvis også datamodellen bak, kanskje hvordan informasjonen lagres, og alle testene som dekker dette. En dag, kanskje to.
Er appen lansert, kommer det enda mer på toppen. Dataene som allerede finnes må håndteres, og endringen må gjennom en ny runde i app-butikkene.
Samme innsikt, samme endring. Forskjellen er når den kom.
Beslutningene som er dyrest å utsette
Ikke alt er like kritisk å avklare tidlig. Noen valg kan trygt tas underveis, mens andre setter seg fast i alt som bygges etterpå.
Hvem brukerne er og hva de skal få gjort, er den dyreste å ta feil om. Alt annet bygger på den, og oppdager dere sent at målgruppen jobber annerledes enn antatt, kan store deler av løsningen måtte tenkes om.
Hvordan dataene henger sammen er den nest dyreste. Om en ordre kan ha flere kunder, om et prosjekt kan ha underprosjekter, om en bruker kan tilhøre flere avdelinger. Dette former databasen, og databasen former alt som snakker med den. Å endre en slik antakelse etter at systemet er i bruk, er blant de mest tidkrevende tingene som finnes.
Hvem som skal ha tilgang til hva er den tredje. Rettigheter som legges på til slutt, blir sjelden riktige, og det er en av de vanligste kildene til alvorlige feil i forretningsapper.
Resten, som farger, tekster, rekkefølgen på felter og de fleste enkeltfunksjoner, kan endres underveis uten store konsekvenser.
Hva planlegging faktisk betyr her
Det betyr ikke en tykk kravspesifikasjon. Lange dokumenter gir ofte falsk trygghet, fordi de beskriver en løsning ingen har prøvd.
Det som virker er å gjøre de tre dyre beslutningene konkrete før utviklingen starter. Snakk med folk som skal bruke løsningen. Tegn opp hvordan informasjonen henger sammen, i vanlig språk. Og beskriv rollene og hva hver av dem skal kunne se og gjøre.
En klikkbar prototype er det mest effektive verktøyet for dette, fordi den tvinger fram svarene. Du kan ikke tegne et skjermbilde uten å ta stilling til hva som står der og hvem som får se det.
Hvorfor sene endringer likevel skjer
Fordi det er umulig å tenke ut alt på forhånd, og det er ikke målet heller.
Noen ting kan man rett og slett ikke vite før folk har prøvd løsningen. Det er derfor vi anbefaler å bygge lite først og sette det i drift tidlig. Da kommer innsikten mens det fortsatt er billig å handle på den.
Forskjellen mellom en god og en dårlig endring sent i prosjektet er om den kommer fra ny kunnskap eller fra manglende forarbeid. Den første er verdifull og skal ønskes velkommen. Den andre kunne vært unngått med en samtale i uke én.
Det som koster mest av alt
Ingen av de tekniske endringene måler seg med å bygge feil ting.
En app med førti funksjoner der brukerne bare bruker seks, har kastet bort mesteparten av budsjettet uten at noen enkeltbeslutning var feil. Dette er hovedargumentet for å starte med en avgrenset første versjon, som vi har utdypet i MVP-apputvikling.
Den nest dyreste er ventetid på avklaringer. Utvikleren trenger et svar, spørsmålet sendes, og det tar fire dager. Skjer det ti ganger, har prosjektet mistet et par uker uten at noen har gjort noe galt. Å utpeke én person som kan bestemme, er det billigste tiltaket i hele prosjektet.
Et praktisk utgangspunkt
Bruk de første ukene på tre spørsmål. Hvem skal bruke dette, og hva skal de få gjort? Hvordan henger informasjonen sammen? Hvem skal se hva?
Har dere gode svar på de tre, tåler prosjektet en god del endringer underveis uten at det koster mye.
Vil du ha hjelp til forarbeidet? Se hvordan vi jobber med apputvikling og prototyper, eller ta kontakt.