Håndtering af Scope Creep og Gold Plating i softwareprojekter

I forbindelse med IT-projekter er Scope Creep (der kommer fra ejerens side) og Gold Plating (der kommer fra PM, Scrum Master eller udviklere) den mest populære trussel. Ukontrollerede ændringer i projektAt tilføje nye funktioner eller indføre ændringer hører utvivlsomt til de trusler, der påvirker både effektivitet og hastighed i projekterne. Tidligere havde vi mulighed for at samarbejde med startups og større virksomheder som Livenation / Ticketmaster, Stroer eller Agora (den største mediekoncern i Europa). I løbet af denne tid koordinerede jeg mange IT-projekter - især dem, der var relateret til softwareudvikling. Denne erfaring fik mig til at forstå, at det er ligegyldigt, om du arbejder i en lille eller stor virksomhed: Hvis du vil have succes, skal du være et skridt foran dine konkurrenter.

Jeg vil gerne dele min indsigt i effektiv udvikling af softwareudviklingsprojekter. Som CCO hos Codest gennemfører vi hver dag projekter for globale virksomheder over hele verden. Den rigtige tilgang til ledelse er den første nøglefase, som senere påvirker projektets succes. Jeg skelner mellem fire grundlæggende principper, som har gjort det muligt for os at udvikle en virkelig effektiv ledelsesmodel. Takket være dem undgår vi senere problemer - herunder dem, der er relateret til krybning og guldplantning. Her er de:

1. Metodolog. Uanset projektets størrelse eller fremskridtsniveau implementerer vi altid en passende metode, der gør det muligt for os at styre projektet på en måde, der er i overensstemmelse med Agil tilgang. I dette tilfælde hjælper Scrum-metodologen os. Og på grund af det har vi alle projektets faser under kontrol. Hvert medlem fokuserer på strengt definerede opgaver. På den måde undgår vi unødvendige distraktioner og opretholder maksimal effektivitet i arbejdet.

2. MVP. Det kan man kalde vores hovedprincip. Hvis du vil lave en applikation, så gør det, men på et meget grundlæggende niveau. Du sparer tid og undgår risikoen for udbrændthed i budgettet. Den oprindelige vision for produkt bliver ofte verificeret og ændret senere. Kunden kan med tiden skifte mening om de nødvendige funktioner i en applikation, hvilket igen skaber unødvendige omkostninger og forlænger arbejdet.

MVP-tilgangen fungerer ret godt. Vi opretter en applikation, der f.eks. har 20% af alle funktionaliteter, men som allerede er i stand til at verificere dens værdi på marked. På den måde får kunden feedback fra brugerne og ved, hvilke funktioner deres produkt skal have for at være effektivt. Derefter fokuserer vi på udviklingen af disse elementer. En god afspejling af denne proces er den grafik, der er vedhæftet nedenfor:

3. Testning. Test af individuelle applikationsfunktioner er direkte forbundet med MVP. Hvis det viser sig, at noget ikke fungerer, som det skal, må man hellere forkaste det og se sig om efter en alternativ løsning. Hos Codest har vi mødt kunder, som helt fra begyndelsen havde pålagt sig selv den endelige form af en applikation og var sikre på, at det var den eneste rigtige vision. Jeg vil ikke komme nærmere ind på de yderligere konsekvenser af denne tilgang. Det er derfor, jeg ser det som nødvendigt endnu en gang at understrege, at enkelhed er nøglen til succes.

4. Udvikling. Opbygningen af applikationen bør begynde med UX, design, backend og frontend. Kort sagt starter alt med de simple "must have"-opgaver, der udgør MVP-produktet. Når denne udviklingsfase er nået, kan du fokusere på udviklingen af den funktionalitet, der kaldes "nice to have".

Sammenfatning

Efter min mening er det fire grundlæggende principper, som er gode til at styre softwareudviklingsprojekter. Denne tilgang reducerer risikoen for unødvendige forstyrrelser, længere arbejdstid og ineffektivitet i forhold til omkostningerne.

Lad mig til sidst give dig endnu et eksempel. For nogen tid siden modtog vi en projektspecifikation fra en kunde. Vi gik straks i gang med at hold for at evaluere det. Kunden forventede, at vi skulle skabe produktet inden for tolv måneder. I henhold til vores tilgang foreslog vi en MVP-tilgang og en udviklingsperiode på tre måneder. I sidste ende lykkedes det os at overbevise kunden. Efter et par måneder var de imponerede over løsningen. Kunden modtog sit fungerende produkt på relativt kort tid. I tilfælde af flere funktionaliteter besluttede de at ændre det projekt, der var forudsat helt fra begyndelsen.

Den model, jeg har beskrevet i denne artikel, er vores måde at gennemføre softwareudviklingsprojekter på. Tro mig, denne løsning forbedrer ikke kun arbejdet og gør det effektivt, men hjælper som følge heraf med at undgå omfanget af creep og gold plating.