Omgaan met Scope Creep en Gold Plating in softwareprojecten

In het geval van IT-projecten zijn Scope Creep (afkomstig van de eigenaar) en Gold Plating (afkomstig van PM, Scrum Master of ontwikkelaars) de populaire bedreigingen. Ongecontroleerde veranderingen in de projectHet toevoegen van nieuwe functionaliteiten of het doorvoeren van wijzigingen behoren zonder twijfel tot de bedreigingen die zowel de efficiëntie als de snelheid van projecten beïnvloeden. In het verleden hebben we samengewerkt met startups en grotere bedrijven als Livenation / Ticketmaster, Stroer of Agora (de grootste mediagroep in Europa). Gedurende deze tijd heb ik veel IT-projecten gecoördineerd - vooral projecten met betrekking tot softwareontwikkeling. Door deze ervaring begreep ik dat het niet uitmaakt of je in een klein of groot bedrijf werkt: als je succesvol wilt zijn, moet je je concurrentie een stap voor zijn.

Ik wil graag mijn inzichten delen over de effectieve ontwikkeling van softwareontwikkelingsprojecten. Als CCO bij Codest implementeren we elke dag projecten voor internationale bedrijven over de hele wereld. De juiste aanpak van het management is de eerste belangrijke fase die later van invloed is op het succes van het project. Ik onderscheid vier basisprincipes, waarmee we een echt effectief managementmodel hebben kunnen ontwikkelen. Dankzij deze principes kunnen we latere problemen voorkomen - waaronder problemen die te maken hebben met de creep en het goud planten van de 'scope'. Hier zijn ze:

1. Methodoloog. Ongeacht de omvang van het project of het niveau van de voortgang, implementeren we altijd een geschikte methodologie waarmee we het project kunnen beheren op een manier die consistent is met het Agile aanpak. In dit geval helpt de Scrum-methodoloog ons. En daardoor hebben we alle fasen van het project onder controle. Elk lid richt zich op strikt gedefinieerde taken. Op deze manier vermijden we onnodige afleiding en behouden we maximale efficiëntie van het werk.

2. MVP. Dit kan ons belangrijkste principe worden genoemd. Als je een applicatie wilt maken, doe het dan, maar op een zeer basisniveau. Zo bespaar je tijd en vermijd je het risico van een budget burnout. De initiële visie van de product wordt vaak later geverifieerd en gewijzigd. De klant kan na verloop van tijd van gedachten veranderen over de vereiste functies van een applicatie, wat op zijn beurt onnodige kosten met zich meebrengt en het werk verlengt.

De MVP-aanpak werkt vrij goed. We maken een applicatie die bijvoorbeeld 20% van alle functionaliteiten heeft, maar al wel in staat is om zijn waarde te verifiëren op de markt. Op deze manier krijgt de klant feedback van gebruikers en weet hij welke eigenschappen zijn product moet hebben om effectief te zijn. Vervolgens richten we ons op de ontwikkeling van deze elementen. Een goede weergave van dit proces is de onderstaande grafiek:

3. Testen. Het testen van individuele applicatiefunctionaliteiten is direct verbonden met MVP. Als blijkt dat iets niet werkt zoals het zou moeten, kun je het beter verwerpen en op zoek gaan naar een alternatieve oplossing. Bij Codest hebben we klanten ontmoet die vanaf het allereerste begin de uiteindelijke vorm van een applicatie oplegden en er zeker van waren dat dit de enige juiste visie was. Ik wil niet uitweiden over de verdere gevolgen van deze aanpak. Daarom vind ik het nodig om nogmaals te benadrukken dat eenvoud de sleutel tot succes is.

4. Ontwikkeling. De bouw van de applicatie moet beginnen met UX, Design, Backend en Frontend. Kortom, alles begint met de eenvoudige "must have" taken die samen het MVP product vormen. Nadat deze ontwikkelingsfase is bereikt, kun je je richten op de ontwikkeling van de functionaliteit die "nice to have" wordt genoemd.

Samenvatting

Naar mijn mening zijn dit vier basisprincipes die geweldig zijn voor het managen van softwareontwikkelingsprojecten. Deze aanpak vermindert het risico op onnodige afleiding, langere werkuren en kosteninefficiëntie.

Tot slot wil ik nog een voorbeeld geven. Enige tijd geleden ontvingen we een projectspecificatie van een klant. We hebben ons meteen aangesloten bij de team om het te evalueren. De klant verwachtte dat we het product binnen twaalf maanden zouden maken. Volgens onze aanpak stelden we een MVP-benadering en een ontwikkelingsperiode van drie maanden voor. Uiteindelijk wisten we de klant te overtuigen. Na een paar maanden waren ze onder de indruk van de oplossing. De klant ontving zijn werkende product in relatief korte tijd. In het geval van een aantal functionaliteiten besloten ze om het project vanaf het begin aan te passen.

Het model dat ik in dit artikel heb beschreven is onze manier om softwareontwikkelingsprojecten succesvol uit te voeren. Geloof me, deze oplossing verbetert niet alleen het werk en maakt het effectief, maar helpt als resultaat ook om de reikwijdte van creep en gold plating te vermijden.