Håndtering av Scope Creep og Gold Plating i programvareprosjekter

I IT-prosjekter er Scope Creep (som kommer fra eierens side) og Gold Plating (som kommer fra prosjektleder, Scrum Master eller utviklere) de mest populære truslene. Ukontrollerte endringer i prosjektDet er ingen tvil om at det å legge til ny funksjonalitet eller innføre endringer er en trussel som påvirker både effektiviteten og hastigheten i prosjektene. Tidligere har vi hatt muligheten til å samarbeide med oppstartsbedrifter og større selskaper som Livenation / Ticketmaster, Stroer eller Agora (det største mediekonsernet i Europa). I løpet av denne tiden koordinerte jeg mange IT-prosjekter - spesielt de som var relatert til programvareutvikling. Denne erfaringen fikk meg til å forstå at det ikke spiller noen rolle om du jobber i en liten eller stor bedrift: Hvis du vil lykkes, må du ligge ett skritt foran konkurrentene dine.

Jeg vil gjerne dele min innsikt i effektiv utvikling av programvareutviklingsprosjekter. Som CCO i Codest gjennomfører vi hver dag prosjekter for globale selskaper over hele verden. Den riktige tilnærmingen til ledelse er den første viktige fasen som senere påvirker prosjektets suksess. Jeg skiller mellom fire grunnleggende prinsipper, og ved å følge dem har vi kunnet utvikle en virkelig effektiv styringsmodell. Takket være dem unngår vi senere problemer - inkludert de som er relatert til kryping og gullplanting. Her er de:

1. Metodolog. Uavhengig av prosjektets størrelse eller hvor langt det er kommet, implementerer vi alltid en egnet metodikk som gjør det mulig for oss å styre prosjektet på en måte som er i samsvar med Smidig tilnærming. I dette tilfellet hjelper Scrum-metodologen oss. Og på grunn av det har vi alle stadiene i prosjektet under kontroll. Hvert medlem fokuserer på strengt definerte oppgaver. På denne måten unngår vi unødvendige distraksjoner og opprettholder maksimal effektivitet i arbeidet.

2. MVP. Det kan kalles vårt hovedprinsipp. Hvis du vil lage en applikasjon, gjør det, men i et veldig grunnleggende utvalg. Du vil spare tid og unngå risikoen for budsjettutbrenthet. Den opprinnelige visjonen om produkt blir ofte verifisert og endret senere. Kunden kan over tid ombestemme seg når det gjelder hvilke funksjoner som kreves i en applikasjon, noe som i sin tur genererer unødvendige kostnader og forlenger arbeidet.

MVP-tilnærmingen fungerer ganske bra. Vi lager en applikasjon som for eksempel har 20% av alle funksjoner, men som allerede er i stand til å verifisere verdien på marked. På denne måten får kunden tilbakemeldinger fra brukerne og vet hvilke funksjoner produktet deres bør ha for å være effektivt. Deretter fokuserer vi på utviklingen av disse elementene. Grafikken nedenfor er et godt bilde på denne prosessen:

3. Testing. Testing av de enkelte applikasjonsfunksjonalitetene er direkte knyttet til MVP. Hvis det viser seg at noe ikke fungerer som det skal, er det bedre å forkaste det og se etter en alternativ løsning. I Codest har vi møtt kunder som helt fra begynnelsen av har pålagt oss den endelige formen på en applikasjon og vært sikre på at dette er den eneste riktige visjonen. Jeg vil ikke gå nærmere inn på hva denne tilnærmingen førte til. Derfor ser jeg det som nødvendig å understreke nok en gang at enkelhet er nøkkelen til suksess.

4. Utvikling. Oppbyggingen av applikasjonen bør begynne med UX, Design, Backend og Frontend. Kort sagt starter alt med de enkle "må ha"-oppgavene som utgjør MVP-produktet. Etter at denne utviklingsfasen er nådd, kan du fokusere på utviklingen av funksjonaliteten som kalles "nice to have".

Sammendrag

Etter min mening er dette fire grunnleggende prinsipper som er gode for styring av programvareutviklingsprosjekter. Denne tilnærmingen reduserer risikoen for unødvendige distraksjoner, lengre arbeidstid og kostnadsineffektivitet.

La meg til slutt gi deg ett eksempel til. For en tid tilbake mottok vi en prosjektspesifikasjon fra en kunde. Vi gikk umiddelbart i gang med team for å evaluere det. Kunden forventet at vi skulle lage produktet i løpet av tolv måneder. I henhold til vår tilnærming foreslo vi en MVP-tilnærming og en utviklingsperiode på tre måneder. Til slutt klarte vi å overbevise kunden. Etter noen måneder var de imponert over løsningen. Kunden fikk sitt fungerende produkt på relativt kort tid. For flere funksjonaliteters vedkommende bestemte de seg for å endre prosjektet helt fra begynnelsen.

Modellen som jeg har beskrevet i denne artikkelen, er vår måte å gjennomføre programvareutviklingsprosjekter på. Tro meg, denne løsningen forbedrer ikke bare arbeidet og gjør det effektivt, men bidrar også til å unngå kryping og gold plating.