DEBATT: Da jeg leste Martin Bekkelund sitt innlegg i digi.no om planlegging i store prosjekter tenkte jeg; endelig er det noen som tar opp det store “skal vi virkelig planlegge oss ihjel”-spørsmålet.

Martin argumenterer mot for tidlig spesifisering av løsning og argumenterer for å fjerne sprinter, dette er jeg helt enig i. Å fjerne sprintene er en veldig god start på å få en smidigere prosess, men behovet for å planlegge på et litt overordnet nivå kommer alltid til å finnes der. Hvordan gjør man det uten å låse løsningen, men kunne eksperimentere for finne nye gode og kanskje til og med innovative løsninger?

Svaret er at vi må planlegge hvilket behov vi skal løse, ikke hvilken løsning vi skal produksjonsette.

For eksempel: hvis du planlegger å utvikle en transaksjonsliste i en nettbank om to måneder, så blir nok løsningen ganske annerledes enn om du planlegger å løse brukerens ønske om å få oversikt i sin økonomi. I det første caset kan du regne med at du får en liste med pluss- og minustall, men åpner du opp og begynner å jobbe med det virkelige behovet kan du ende opp med en helt annen løsning, en ny type visning/funksjonalitet for brukerens pengebruk (der kanskje en transaksjonsliste kun er en del av løsningen).

Planlegging etter en prioritert liste med behov gjør at du vet at du alltid løser det viktigste først og det gjør deg endringsdyktig. Du kan blant annet ta inn ny kunnskap fra det du har laget fra før, endringer i markedet (ny konkurrent osv.) og hvordan det skal henge sammen med resten av produktet du lager/vedlikeholder.

Det prioriterte behovet må konseptualiseres. Her er det viktig at designere, domeneeksperter og utviklere jobber sammen for å finne den optimale løsningen, både brukermessig og teknisk. Man kan også identifisere avhengigheter og risiko i denne fasen.

Når man har tygget på konseptet en stund og detaljert det litt mer, kan man vurdere å ta det inn, helt eller delvis, på tavla til utviklerne. Og nå er det plutselig lov å snakke løsning, fordi vi vet at det er riktig funksjonalitet og at det faktisk skal utvikles!

Man planlegger altså på to nivåer; på overordnet nivå planlegger vi hvilke behov vi skal løse og i det daglige planlegger vi hvilken funksjonalitet vi skal utvikle den nærmeste tiden, altså løsning.

Det er viktig å presisere at alt man prioriterer inn til utvikling er direkte eller indirekte knyttet til et brukerbehov. Også det å jobbe med teknisk gjeld kan for eksempel være knyttet til systemets responstid, som påvirker sluttbrukerens opplevelse av systemet. Det kan også være opprydding i kode eller prodsetting-prosesser, som gjør at man kan lansere funksjonalitet raskere. Noe som igjen kommer sluttbrukeren til gode.

Jeg oppfordrer små og store prosjekter å starte med å finne ut hvilke behov det er man skal løse og hvilke av dem som er viktigst, istedenfor å låse løsningen og produksjonsplanen for lang tid fremover. Flinke fagfolk som jobber sammen over tid er det som gir den beste løsningen!