Det finnes mange prosjektstyringsmetodikker. Hver av dem hjelper på sin måte med å oppnå forretningsmål. Ofte er de ikke enkle å etablere, spesielt i starten av et prosjekt, og de formes først under gjennomføringen. Agile metodikker ble utviklet som et svar på dette problemet, hvor kjernen er hyppig utveksling av informasjon mellom utviklingsteamet og forretningsrepresentanter.
Men hvordan ser dette ut i praksis? Jeg vil prøve å gi noen eksempler fra virkeligheten som beskriver viktigheten av godt samarbeid mellom utviklere og business, og hvilke problemer det bidrar til å unngå. Mange tekniske personer vil sannsynligvis nå tenke "det finnes en product owner i teamet mitt, jeg vil ikke snakke med business". I en ideell verden kan dette fungere, men virkeligheten er litt annerledes.
1) Prosjektets tidsramme
Det vil høres utrolig ut, men noen ganger er ikke utviklingsteamet klar over tidsrammen som funksjonaliteten skal leveres innenfor. Dette er en av de viktigste arkitektoniske driverne, som gjør det mulig å bestemme hvilken arkitektur som vil være passende for å løse et gitt problem. Denne typen uklarhet kan oppstå av flere grunner:
Business tar tidsfristen for gitt, f.eks. Black Friday
Business bruker navn på høytider, f.eks. Thanksgiving (i Canada 11.10.2021 i USA 25.11.2021)
Business bruker begrepet Q2 og har starten av andre kvartal i tankene, mens utviklingsteamet sikter mot slutten av Q2.
Det siste eksempelet viser ganske tydelig at et så vanlig begrep som Q2 kan gi så mye som 90 dagers forskjell i betydningen av et gitt begrep. Det er ganske mye… Derfor er et felles språk så viktig, og det kan forbedres ved å stille enkle spørsmål:
"Når skal en gitt funksjonalitet være levert – hva er den eksakte datoen?"
"Hva er denne datoen basert på?"
"Hvilke av prosjektets funksjonaliteter er mest kritiske?"
"Hva skjer hvis en gitt funksjonalitet ikke leveres i tide?"
Et system som skal håndtere økt trafikk på Black Friday og leveres 2 dager etter tiden er allerede ubrukelig, så det er verdt å kjenne tidsrammen og det neste punktet når man utvikler en gitt programvare:
2) Formålet med prosjektet
Utviklere liker å "lukke oppgaver." De får en spesifikk user story, estimerer, skriver kode og lukker oppgaven. Ved første øyekast ser alt greit ut, men det hender at oppgaven ikke er spesifisert eller "kolliderer" med en annen oppgave. Det er verdt å stille spørsmål i en slik situasjon:
"Hvilket problem prøver prosjektet vårt å løse?"
"Hvordan bidrar oppgaven til å løse dette problemet?"
"Er business klar over inkonsistenser mellom oppgaver?"
"Er den gitte løsningen ment å tilfredsstille business eller sluttbrukeren?"
"Vet jeg om en bedre måte å løse dette problemet på?"
Mange ganger spurte hele teamet oss selv: "Hvordan vil denne oppgaven bidra til det gode for hele prosjektet?" Ofte oppdaget vi et helt annet perspektiv på problemet fra business- og utviklersiden, som vi ikke tidligere var klar over. Ved å kjenne formålet med prosjektet, kan vi som utviklere også komme opp med bedre løsninger:
Problem -> Business ønsker at standardspråket i applikasjonen skal være engelsk, det skal være en språkvalgmeny på hver skjerm.
Teamets forslag -> Vi kan hente språket som brukes på brukerens enhet og dermed sette språket i appen, som kan endres i innstillingene. En liten endring, men for en app hvor det visuelle laget var ekstremt viktig, var det betydningsfullt å skjule språkvalgmenyen.
Noen ganger er det verdt å spørre seg selv "Hvorfor?" før man tar en oppgave. Vi kan se en inkonsistens med prosjektets mål, og det kan være verdt å gå tilbake til business med vårt synspunkt. Spør om opprinnelsen til oppgaven og om oppgaven i sin nåværende form samsvarer med prosjektmålet. Det er bare noen få minutters samtale, og det kan spare mange timer med programmering, og det vil bidra til å forbedre kommunikasjonen med business, som er neste punkt.
3) Kommunikasjon med business
Det sies at god kommunikasjon er nøkkelen til et vellykket prosjekt, og jeg er helt enig. Når jeg hører historier om "tragiske prosjekter", er problemet som nevnes veldig ofte dårlig kommunikasjon med business. Hva betyr dette egentlig? Fra min egen erfaring kan jeg nevne noen av problemene jeg har hatt:
Business er redd for å snakke med utviklingsteamet.
Utviklere er redde for å snakke med business.
Kaos i kommunikasjonskanaler - man vet ikke hva man skal gjøre.
Mange typer business - man er ikke sikker på hvilken som er viktigst.
Business setter urealistiske tidsfrister.
Business forstår ikke teknologien vår.
Svaret på punkt 1, 2, 3 er å etablere felles kommunikasjonskanaler. Det er viktig at det finnes én felles kanal. Det er bra om andre prosjektmedlemmer kan se diskusjonene og bidra til dem. Én kommunikasjonskanal sikrer at feil eller opplastinger ikke forsvinner i mengden av spam i en privat innboks, og hvis noen vil endre fargen på knappene i hele applikasjonen, kan alle lese hvorfor, slik at de eventuelt kan mene noe om det. Det er verdt å ta i bruk prinsippet om at vi spiller for ett mål, og at prosjektets suksess avhenger av felles innsats.
Punkt 4, 5, 6 kan løses ved å organisere "demoer" etter slutten av sprinten for flere interessenter/businesser. Det er også viktig å diskutere prioriteringer for nåværende og neste sprint eller gi business tilgang til Jira (read only er nok). Hvis det oppstår vanskeligheter, kan man vise hva teamet for øyeblikket sliter med. Jeg har hatt muligheten til å observere hvordan representanter for relativt uavhengige businesser etter en felles demo seg imellom bestemmer hvilken funksjonalitet som er viktigst, og noen ganger klarer å trekke ut en felles del, og alle er fornøyde 🙂
Tekniske målinger i et prosjekt er veldig viktige, det er bra å vite hvilken testdekning vi har eller prosentandelen av vellykkede implementeringer. Men gjennom erfaring fra prosjekter ser jeg også på hvordan samarbeidet med business fungerte. Det er verdt å gjøre en felles retro etter at prosjektet er avsluttet og finne ut hva som fungerte bra i kommunikasjonen og hva som fortsatt kan forbedres. Til syvende og sist er det mennesker bak prosjektene, ikke bare målinger – la oss gjøre dette samarbeidet fruktbart og skape gode følelser.
Dette er hva jeg ønsker for alle, at samarbeidet mellom utviklingsteamet og business er smidig og naturlig. Å bygge vegger og rigide skiller i agile metodikker gjør lite godt – det er verdt å legge til at et felles eller universelt språk i stor grad forenkler programvareutvikling, slik Eric Evans skrev om i sin bok om DDD.
Ps. Det er verdt å legge til at dette er mine subjektive tanker, like mange team som problemer og løsninger. I agile metodikker tar ulike personer på seg ulike ansvar, og det er fullt mulig at en programmerer i store team ikke engang har tilgang til business. Likevel mener jeg det er verdt å rive ned slike kunstige vegger, og før eller senere blir avstanden mellom utviklere og business kortere – det pleier å gi gode resultater.
Ha en fin dag! 🙂
