Hantering av Scope Creep och Gold Plating i mjukvaruprojekt

När det gäller IT-projekt är Scope Creep (som kommer från ägarens sida) och Gold Plating (som kommer från PM, Scrum Master eller utvecklare) de populära hoten. Okontrollerade förändringar i projektAtt lägga till nya funktioner eller införa förändringar hör utan tvekan till de hot som påverkar både effektiviteten och hastigheten i projekten. Tidigare har vi haft möjlighet att samarbeta med både nystartade företag och större företag som Livenation/Ticketmaster, Stroer eller Agora (Europas största mediekoncern). Under den här tiden samordnade jag många IT-projekt - särskilt de som var relaterade till Utveckling av programvara. Denna erfarenhet fick mig att förstå att det inte spelar någon roll om du arbetar i ett litet eller stort företag: om du vill lyckas måste du ligga ett steg före dina konkurrenter.

Jag skulle vilja dela med mig av mina insikter om effektiv utveckling av projekt för utveckling av programvara. Som CCO på Codest genomför vi varje dag projekt för globala företag runt om i världen. Rätt sätt att leda ett projekt är det första viktiga steget som senare påverkar projektets framgång. Jag kan urskilja fyra grundläggande principer, som vi har kunnat upprätthålla för att utveckla en verkligt effektiv managementmodell. Tack vare dem undviker vi senare problem - inklusive de som är relaterade till kryp- och guldplanteringens omfattning. Här är de:

1. Metodolog. Oavsett projektets storlek eller hur långt det har kommit implementerar vi alltid en lämplig metodik som gör det möjligt för oss att hantera projektet på ett sätt som överensstämmer med Agil tillvägagångssätt. I det här fallet hjälper Scrum-metodologen oss. Och på grund av det har vi alla stadier i projektet under kontroll. Varje medlem fokuserar på strikt definierade uppgifter. På så sätt undviker vi onödiga distraktioner och upprätthåller maximal effektivitet i arbetet.

2. MVP. Det kan kallas vår huvudprincip. Om du vill skapa en applikation, gör det, men i ett mycket grundläggande sortiment. Du kommer att spara tid och undvika risker för budgetutbrändhet. Den ursprungliga visionen av Produkt verifieras och ändras ofta i efterhand. Kunden kan med tiden ändra uppfattning om vilka funktioner som krävs i en applikation, vilket i sin tur genererar onödiga kostnader och förlänger arbetet.

MVP-strategin fungerar ganska bra. Vi skapar en applikation som till exempel har 20% av alla funktioner, men som redan kan verifiera sitt värde på marknad. På så sätt får kunden feedback från användarna och vet vilka funktioner deras produkt bör ha för att vara effektiv. Sedan fokuserar vi på utvecklingen av dessa element. En bra återspegling av denna process är den grafik som bifogas nedan:

3. Testning. Testning av enskilda applikationsfunktioner är direkt kopplad till MVP. Om det visar sig att något inte fungerar som det ska, är det bäst att förkasta det och leta efter en alternativ lösning. På Codest har vi träffat kunder som redan från början har lagt fast den slutliga formen för en applikation och varit säkra på att detta är den enda rätta visionen. Jag vill inte gå in på de ytterligare effekter som detta tillvägagångssätt fick. Det är därför jag ser det som nödvändigt att än en gång understryka att enkelhet är nyckeln till framgång.

4. Utveckling. Konstruktionen av applikationen bör börja med UX, Design, Backend och Frontend. Kort sagt, allt börjar med de enkla "måste ha"-uppgifterna som utgör MVP-produkten. När denna utvecklingsfas har uppnåtts kan du fokusera på utvecklingen av den funktionalitet som kallas "nice to have".

Sammanfattning

Enligt min mening är detta fyra grundläggande principer som är utmärkta för att hantera mjukvaruutvecklingsprojekt. Detta tillvägagångssätt minskar riskerna för onödiga distraktioner, längre arbetstider och kostnadsineffektivitet.

Låt mig slutligen ge er ytterligare ett exempel. För en tid sedan fick vi en projektspecifikation från en kund. Vi gick omedelbart med i Team för att utvärdera den. Kunden förväntade sig att vi skulle skapa produkten inom tolv månader. Enligt vår strategi föreslog vi en MVP-strategi och en utvecklingsperiod på tre månader. I slutändan lyckades vi övertyga kunden. Efter några månader var de imponerade av lösningen. Kunden fick sin fungerande produkt på relativt kort tid. När det gäller flera funktioner bestämde de sig för att ändra projektet som antogs redan i början.

Den modell som jag beskriver i den här artikeln är vårt sätt att framgångsrikt genomföra projekt för mjukvaruutveckling. Tro mig, den här lösningen förbättrar inte bara arbetet och gör det effektivt, utan hjälper också till att undvika krypning och guldplätering.