Derfor trenger ditt prosjekt en funksjonell arkitekt

Derfor trenger ditt prosjekt en funksjonell arkitekt

For å løse store samfunnsutfordringer, trengs utvikling av komplekse systemer, helst i tverrfaglige team. Her trenger man også en nøkkelperson som kan ivareta behovene til kunden og brukere, og være en brobygger mellom de ulike disiplinene og teammedlemmene. Det blir behov for en funksjonell arkitekt!

Skrevet av Daniel Jensen og Lill Mari Ellingsen

Vi jobber begge som funksjonelle arkitekter i Itera, og har flere års erfaring fra spennende kundeprosjekter innen bransjer som offentlig, finans, forsikring, utdanning og offshore. Vi vil i dette blogginnlegget forklare nærmere hva en funksjonell arkitekt gjør, og hvorfor vi mener at IT-prosjekter lykkes bedre når man har denne rollen med i teamet.

 

Kravstyring

Er kravene i prosjektet uklare, tvetydige, eller ikke-eksisterende? Henger ikke kravene sammen med brukerbehov, eller kanskje løsningen ligger foran problemet?

Utydelig kommuniserte krav og behov resulterer ofte i unødvendig merarbeid, og ifølge en undersøkelse fra PMI er dette hovedårsaken til at IT-prosjekter feiler. Så, hvordan sikrer vi at behov og krav er godt kommunisert og ivaretatt mellom kunde og prosjektet, slik at eventuelle utfordringer oppdages så tidlig som mulig i utviklingsprosessen? Dette er en av de viktigste oppgavene til en funksjonell arkitekt.

For det første må det riktige problemet løses. Jo tidligere den funksjonelle arkitekten kommer inn i prosjektet, jo tidligere kan hun eller han bidra til å kartlegge behov fra alle interessenter, samt å definere mål for løsningen. Den funksjonelle arkitekten er opptatt av hvorfor og hvordan, og bidrar til å danne grunnlaget for et rasjonelt valg av konsept for endelig løsning.

Deretter, for at utviklingsteamet skal kunne lage best mulige løsninger, er det helt sentralt at de får formidlet behov og krav på en tydelig måte. Den funksjonelle arkitektens hovedoppgave er dermed å iterativt omforme behov til funksjonelle og ikke-funksjonelle krav som beskriver hvordan løsningen skal fungere, og hvordan det kan måles. For eksempel kan dette være i form av brukerhistorier som er sporbare til brukerbehov, og som effektivt kan tas videre til implementasjon og test.

 

En brobygger

Snakker utviklerne, testerne og designerne forskjellige språk? Er det uklart for testerne hva de skal teste og hva akseptansekriteriene er? Har teammedlemmene ulike syn på hva som er målet?

Den funksjonelle arkitekten jobber utfra et helhetlig perspektiv, og har ofte én fot i teknologien og én i det konseptuelle. Hun eller han kan skape konseptuelle modeller som beskriver problemet og løsningens struktur, funksjonalitet og integrasjoner. Gjennom å visualisere konteksten som teknologien skal fungere i, samt oversette behov og konsepter til tydelige og testbare kravbeskrivelser, fungerer den funksjonelle arkitekten som en brobygger mellom de forskjellige fagdisiplinene i et prosjekt.

For eksempel kan den funksjonelle arkitekten lage kontekst- og sekvensdiagrammer som forklarer løsningens konsept og integrasjoner, og som komplementerer brukerhistoriene og designerens grafiske prototyper.

 

Agile metoder

Sliter teamet med å levere verdi hyppig? Har teamet for lite kontakt med kunde og brukere?

I det siste tiåret har agile metoder snudd opp ned på styring av IT-prosjekter. Der prosjektledelse hovedsakelig styrte på tid og kost, er hovedfokuset nå styring av prosjektets omfang.

Evnen til å få agile team til å fungere er avgjørende for om et prosjekt lykkes, og her kan den funksjonelle arkitekten være en nøkkelperson. Gjennom styring av backlog og fokus på verdi er hun eller han utmerket i rollen som for eksempel scrum master. Den funksjonelle arkitekten vil gjennom hele implementasjonsfasen avklare uklarheter og prioriteringer med kunde, skjerme for støy, og sørge for at utviklingsteamet har fart.

Et eksempel er at den funksjonelle arkitekten bruker verktøy som Azure DevOps eller Jira for å bygge opp struktur for backlog, og roadmap for hva som skal utvikles. Hvis nødvendig kan hun eller han også lage et hierarki av flere team med hver sin backlog. Ved å bruke boards og dashbord, kan arbeidsoppgavene visualiseres på tvers av team og kunde, og sørge for at alle jobber i samme retning.

 

Distribuerte team

Jobber teamet geografisk spredt? Mangler man felles visjon og gode metoder for samarbeid på tvers av lokasjoner?

I moderne IT-prosjekter blir det mer og mer vanlig at teamet sitter geografisk spredt, og i de siste krisetider har evnen til å jobbe distribuert vist seg avgjørende for å lykkes. I et prosjekt hos Itera kan for eksempel flere av utviklerne og testerne jobbe i et såkalt nearshore-team i Ukraina eller Slovakia, mens resten av teamet jobber lokalt hos kunde i Norge. Itera har over ti års erfaring med å jobbe distribuert.

I slike prosjekter er det vanlig at de lokale ressursene går inn i prosjektet først, mens resten av nearshore-teamet skalerer opp etter hvert som man går over i implementasjonsfasen. En funksjonell arkitekt vil i et slikt prosjekt kunne bidra til å ivareta helheten i løsningen, dempe risiko, og sørge for kontinuitet i det prosjektet beveger seg gjennom ulike faser med mange involverte ressurser.

 

Livssyklus

Hva med når prosjektet er ferdig og løsningen skal overleveres til driftsorganisasjonen?

Ofte fokuseres det for lite på at løsningen etter hvert skal driftes, monitoreres, vedlikeholdes og videreutvikles. Den funksjonelle arkitekten vil fra starten av prosjektet identifisere behovene til hele livssyklusen til løsningen, og dermed unngå overraskelser når driftsfasen kommer. Et IT-prosjekt handler ikke bare om å levere programvare. Hun eller han vil også kunne sørge for at opplæring settes i gang, dokumentasjon er på plass, og at organisasjonen er klar for transisjon til ny løsning.

For eksempel kan den funksjonelle arkitekten tidlig avdekke hvordan løsningen skal administreres og monitoreres, og hva som skal måles, slik at dette kan utvikles parallelt med brukerfunksjonalitet. I tillegg er det tidlige arbeidet med krav og konseptuelle modeller et godt grunnlag for det som skal leve videre som dokumentasjonen til de som skal bruke og vedlikeholde løsningen.