Episode 2: Fra prosjekter til produkter

Da jeg studerte var vannfall gjeldende prosjektmetodikk:

Planlegge først. Deretter gjennomføre. Så rulle ut og avslutte.

Er det rart det gikk galt når man lagde programvare etter samme metode som man lagde hus?

Hei, Martin her, og du lytter til Fimbul!

Studerte på siste halvdel av 90-tallet. Innser at det er en stund siden, selv om jeg selvfølgelig er like ung. Studerte for å programmere. Men stinket i programmering. Var langt bedre i metodefagene. Et av metodefagene var prosjektledelse. Vannfall. FAURIDA — jeg husker det godt. Selv i dag kan du søke opp FAURIDA og se at det faktisk undervises i fortsatt.

1)Forandringsanalyse (hva er problemet og hva bør gjøres) 2)Analyse (dele opp og finne sammenhenger) 3)Utforming (design) 4)Realisering (lage) 5)Implementering (ta i bruk) 6)Drift/vedlikehold (sikker, stabil drift og mindre endringer ved behov) 7)Avvikling (ta vare på data og gjenbrukbare komponenter)

I dag er dette helt surrealistisk. Det er lett å tenke seg hvor tankegodset kommer fra. Bygg- og anleggsbransjen. Bygge nedenfra og opp. Tok med erfaringene fra prosjektstyring over i abstrakte prosjekter.

Og det er her det går feil. Programvare er ikke husbygging. Hvis grunnmuren er feil i programvaren kan du lage den på nytt. Databaser kan byttes ut. Programmeringsspråk kan byttes ut. Infrastruktur kan byttes ut.

Programvare er heller ikke et hus i den forstand at det bygges og overleveres for bruk. Det trenger i hvert fall ikke være slik.

Allikevel sitter tankegodset fra vannfall godt fast hos mange. Spesielt planleggingsfasen. Falsk følelse av kontroll når man har brukt lang tid på planlegging. Det er først når erfaringene fra faktisk gjennomføring kommer at man lærer. Resultatet blir derfor at man bommer på tid og pris og løsning.

Smidige prosjektmetodikker løser delvis problemet, men ikke alt. Smidig er… Å iterere seg igjennom et prosjekt vil fortsatt medføre en start- og sluttdato for prosjektet. Vi kan snakke mer om smidige prosjektmetodikker i en senere episode.

Dermed snakker man ikke lenger om prosjekter, men om produkter og produktsykluser.

Programvare er under kontinuerlig utvikling så lenge den er i bruk. Etableres team. Utvikles og videreutvikles kontinuerlig. Endrer funksjonalitet. Justerer forretningsmodeller. Folk kommer og går. Til produktet dør og avvikles.

Som leder må man anerkjenne denne måten å arbeide på. «Når er prosjektet ditt ferdig?» er et spørsmål som ikke bør stilles annet enn når det faktisk er snakk om et ekte prosjekt. Penger bevilges og driften løper til man ser om produktet er levedyktig. Så får vi senere snakke om smidig budsjettering og forskjellige måter å lede eksperimentelle produkter.

Gmail er ikke et prosjekt fra Google. Office er ikke et prosjekt fra Microsoft. Vipps er ikke et prosjekt fra DNB.

Dette er produkter eller tjenester. De videreutvikles til de dør.

Tusen takk for at du lytter til Fimbul, vi høres!