Introduksjon
Programvareutvikling er komplisert. Det tar tid og er vanligvis mye mer komplisert enn f.eks. å bygge noe fysisk.
Folk har mye mer erfaring med å bygge, fordi vi har gjort det i tusenvis av år. I dag, hvis du vil bygge et hus, må du gå til en arkitekt, planlegge det veldig nøye og deretter bygge i henhold til tegningene du fikk fra ingeniøren.
Under prosessen kan du planlegge det meste av arbeidet og du vet hvordan du vil at det skal se ut når du er ferdig.
Vi har derimot ikke så mye erfaring med programvareutvikling. Historien om programmering går tilbake til 1940-tallet, og ble mer populær da Internett ble tilgjengelig for hele verden. Så vi kan si at vi har ca. 30 års erfaring med programvareutvikling som menneskehet, noe som egentlig er lite.
Dette er en av grunnene til at vi ofte ikke kan planlegge prosessen med programvareutvikling slik vi gjør når vi bygger et hus.
Hva er en endring i scope?
Et prosjektets scope er totaliteten av krav, mål, kostnader og ressurser. Scope defineres ofte tidlig i prosessen med programvareutvikling, basert på hva vi vet vi ønsker å bygge.
En endring i scope er enhver endring av krav, mål eller ressurser, som ofte påvirker kostnader og tidsfrister.
Hvorfor vil man endre noe?
Etter hvert som vi går frem, får vi mer kunnskap om problemet vi ønsker å løse med programvaren vår. Vi oppdager ofte at vi ikke har planlagt alt perfekt, og det vil være mye bedre å endre en bestemt del av prosjektet/produktet.
Man kan også nekte å tilpasse seg omstendighetene, men da ender man ofte opp med noe som man vet ikke er optimalt for behovene sine.
Hvordan håndtere endringer i scope?
Som et programvarehus møter vi ofte endrede behov/ønsker fra våre kunder. Vi forstår dette perfekt, fordi vi jobber tett sammen med virksomhetene og ser at det ofte må gjøres en endring – fordi noen av problemene har endret seg eller vi har fått mer informasjon om dem enn vi hadde i begynnelsen.
Nå finnes det to typer samarbeid: Fastpris og Time & Materials. Vi foretrekker sistnevnte, fordi da kan vi være virkelig agile sammen med kunden og bruke vår tid på å løse et problem under nye eller endrede omstendigheter. I det første er det veldig viktig å nøye skrive ned prosjektets spesifikasjon og på denne måten beskrive scope før oppstart. Deretter, under prosessen, hvis kunden endrer kravene, er det prosjektlederens jobb å håndtere endringen og avtale de nye målene for prosjektet med kunden. Nøkkelord her er: Prosess.
En prosess
Det første og viktigste er å forstå årsaken til endringen. Er det en ny «nice to have»-funksjon, eller er det virkelig essensielt? Hvis prosjektlederen ikke forstår årsaken til endringen i scope, hvordan skal han videreformidle det til teamet?
Det andre som må vurderes er avvisning av endringen. Noen ganger forstår ikke kunden teknologien eller prosessen, og de nye kostnadene ville være uutholdelige. Klar kommunikasjon er nøkkelen for å dekke alle aspekter av endringen.
Tenk deg at du har avtalt med noen å plante 2000 epletrær. Du har allerede kjøpt alle plantene og plantet 500 av dem, når kunden ønsker å ha kirsebærtrær i stedet – men han har ikke besøkt hagen og vet ikke hvor mye arbeid det er å endre dette på dette stadiet.
Tredje punkt er å måle effekten av endringen på andre aspekter av prosjektet. Hvis vi endrer X, bør vi kanskje også endre Y? Dokumenter det, og kommuniser igjen tydelig med kunden hvor stor endringen vil være. Hvis det påvirker budsjettet, vil det sannsynligvis også påvirke tidsplanen. Selv om det virker åpenbart, er klar kommunikasjon viktig.
Les om nøkkelen til prosjektets suksess – av Oskar Poprawski.
Effektiv kommunikasjon på ethvert punkt i prosjektet er avgjørende for å lykkes.
Vil du snakke med oss om prosjektets scope?
