Er IT-prosjekter som andre prosjekter der noe skal bygges? Eller er de kanskje ikke det? I Gaustadbekkdalen bygges det store LifeScience-bygget i disse dager; joda en budsjettsmell: Men der vet man noenlunde hva man skal ha, hvordan bygget skal brukes og hvem som skal bruke det. Det er lite sannsynlig at et rom i kjelleren skal flyttes til NTNU om to år, at man må bytte ut veggene grunnet oppdatering til ny versjon av betongen, eller at flyvende biler må få parkeringsplasser på taket. Men det er nettopp slike utfordringer som kjennetegner store utviklingsprosjekter for IT-systemer; de utvikler seg.
Og kanskje nettopp ordet «store» er utfordringen. Facebook er et av verdens største IT-produkter i dag. Tenkte Mark Zuckerberg på det da han startet? Hadde han styringsgruppe, verdikjedeutredere, referansegrupper? Hadde han Prince2 og ITIL fremst i pannebrasken? Eller hadde han rett og slett en reell ide om «ROI» (return of investment) i en «MVP» (minimum viable product) og satt seg deretter ned bak tastaturet.
For meg virker det som om man ikke har lov til å bare «starte» lenger, man må rigge en multi-million-klasse prosjektstruktur og ikke minst involvere samtlige aktører som noensinne kan mene noe om produktet, før man har lov til å nærme seg å skrive noe kode. Like fullt står det alltid i prosjektbeskrivelsene at vi skal være «agile» og «vi skal levere en MVP». En MVP gjerne omtalt slik at ingen ved sine fulle fem klarer å avdekke hva denne MVPen skal levere, og hvilken merverdi den skal gi for hvem.
Det er ganske fantastisk at det er slik, men det virker som om at hvis man ikke har en overdimensjonert prosjektorganisasjon så «vil det gå galt». Jeg heller mot det motsatte. Mitt postulat er at man antageligvis får testet, avklart og korrigert både idé, retning og ROI mye bedre, raskere, billigere og enklere om man «bare starter», så lenge man er enige om at ideen er forholdsvis god og nødvendig, og at man har et endelig budsjett og en endelig sluttdato for evaluering av en MVP. I tillegg kommer det noen viktige grunnleggende forutsetninger, også for MVPen som skal sørge for suksessen:
- fokuser på skalerbarhet fra første dag, selv om man ikke evner å gjøre det perfekt
- fokuser på løse koblinger (APIer) som gjør at en MVP kan vokse og utvikle seg, og at samtlige komponenter kan byttes ut over tid (unngå å bli låst til tredjepart)
- fokuser på at alle APIer skal kunne benyttes av «hvemsomhelst» fra «hvorsomhelst», gitt at de har riktig autorisasjon og autentifikasjon
- fokuser på en modulær og granulær tilgangskontroll (autorisasjons-system)
- bygg ut fra organisasjonens «installerte base*» om denne er i henhold til punktene over
Start raskt, evaluer raskt, feil raskt og endre deg raskt. «The proof is in the pudding», som det heter, og brukerens tilfredshet /betalingsvillighet er det som i de fleste tilfeller vil avgjøre om produktet ditt er bærekraftig. Tar det mer enn ett år å lage en MVP; gjør noe med ideen din, for du vil ikke være ferdig før produktet er utdatert.
En anbefaling i større IT-prosjekt er dermed at man dropper mye av utredningene om alternativer, arkitekturutredninger, konsekvensutredninger, osv. til fordel for noe helt annet. Start med å teste (den funksjonelle) ideen, ikke det IT-tekniske, på konsumentene i den grad det er mulig (ref. f.eks. Ford om raskere hestevogner vs. automobiler, Steve Jobs om Iphonen), for å konkludere om hvorvidt ideen virker bærekraftig. Så slenger man ut 1-5 summer med penger til ulike mulige leverandører, med tydelig beskjed om at «vi evaluerer MVP deres etter x måneder (ikke år, det er for lenge), og om det har livets rett, går vi videre med én eller flere av dere». I en MVP inngår, blant mye annet viktig, «å snakke med brukerne», altså; kartlegg om planlagt funksjonalitet og leveranse gir produktet levedyktighet. Videre er det åpenbart at man må ha visse rammer for IT-sikkerhet og tekniske valg (bruk organisasjonens installerte base), dette for å muliggjøre frihet under ansvar hos utviklerne, samt å beholde en kontrollerbar heterogenitet i produkt og tjenestelinje.
Moderne IT-systemer er organiske i stor eller noe mindre grad, men de lever sitt eget liv, de må kontinuerlig endres, oppdateres, integreres og tilpasses på helt andre måter enn motorveier og store bygninger. De må derfor bygges og behandles på andre måter. Og over alt dette henger de to gamle fjellvettreglene «vend i tide, det er ingen skam å snu» og «lytt til erfarne fjellfolk» – før milliardene har rullet ut produktet viser seg å ikke tilfredsstille kravene.
En hemmelig sjekkliste for dine prosjekt kan være så enkel som :
- Har du kontroll på tilgangsstyringen ?
- Har du løse koblinger mellom komponentene dine ?
- Kan du skalere opp?
- Kan samtlige funksjoner benyttes av hvem som helst, fra hvor som helst, via API (gjerne https)?
- Vil det dukke opp et brukbart produkt innen 2-6 mnd ?
- Gjenbruker du komponenter ?
*installert base (installed base) brukes ofte i IT-litteraturen om den eksisterende grunnleggende og mest basale IT-infrastruktur/tjeneste/produktportefølje i en organisasjon. Omfatter gjerne også etablerte omgivelser som rutiner, regler, m.m. knyttet til denne faktiske einfrastrukturen. Se for eksempel https://www.duo.uio.no/handle/10852/55781
