Gestire lo Scope Creep e il Gold Plating nei progetti software

Nel caso dei progetti IT, lo Scope Creep (proveniente dal sito del proprietario) e il Gold Plating (proveniente da PM, Scrum Master o sviluppatori) sono le minacce più diffuse. I cambiamenti incontrollati nel progettoL'aggiunta di nuove funzionalità o l'introduzione di modifiche fanno indubbiamente parte delle minacce che incidono sull'efficienza e sulla velocità dei progetti. In passato abbiamo avuto l'opportunità di collaborare con startup e grandi aziende come Livenation / Ticketmaster, Stroer o Agora (il più grande gruppo di media in Europa). Durante questo periodo, ho coordinato molti progetti IT, in particolare quelli relativi a sviluppo software. Questa esperienza mi ha permesso di capire che non importa se si lavora in una piccola o grande azienda: se si vuole avere successo, bisogna essere un passo avanti rispetto alla concorrenza.

Vorrei condividere le mie intuizioni sullo sviluppo efficace di progetti di sviluppo software. Come CCO di Codest, realizziamo ogni giorno progetti per aziende globali in tutto il mondo. Il giusto approccio alla gestione è la prima fase fondamentale che influenza poi il successo del progetto. Distinguo quattro principi fondamentali, il cui mantenimento ci ha permesso di sviluppare un modello di gestione veramente efficace. Grazie ad essi, evitiamo i problemi successivi - compresi quelli legati al creep e al gold planting 'scope'. Eccoli:

1. Metodologo. Indipendentemente dalle dimensioni del progetto o dal suo livello di avanzamento, implementiamo sempre una metodologia appropriata che ci consenta di gestire il progetto in modo coerente con la normativa vigente. Agile approccio. In questo caso, il metodologo Scrum ci aiuta. E grazie a ciò, abbiamo tutte le fasi del progetto sotto controllo. Ogni membro si concentra su compiti rigorosamente definiti. In questo modo, evitiamo distrazioni inutili e manteniamo la massima efficienza del lavoro.

2. MVP. Questo può essere definito il nostro principio principale. Se volete creare un'applicazione, fatelo, ma in una gamma molto semplice. Risparmierete tempo ed eviterete il rischio di esaurimento del budget. La visione iniziale del prodotto è spesso verificata e modificata in seguito. Nel corso del tempo, il cliente può cambiare idea sulle caratteristiche richieste di un'applicazione, generando così costi inutili e prolungando il lavoro.

L'approccio MVP funziona abbastanza bene. Creiamo un'applicazione che abbia, ad esempio, 20% di tutte le funzionalità, ma che sia già in grado di verificare il suo valore sulla mercato. In questo modo, il cliente riceve il feedback degli utenti e sa quali caratteristiche deve avere il suo prodotto per essere efficace. Poi ci concentriamo sullo sviluppo di questi elementi. Un ottimo riflesso di questo processo è la grafica allegata qui sotto:

3. Test. Il test delle funzionalità delle singole applicazioni è direttamente collegato all'MVP. Se si scopre che qualcosa non funziona come dovrebbe, è meglio rifiutare e cercare una soluzione alternativa. In Codest abbiamo incontrato clienti che, fin dall'inizio, hanno imposto la forma finale di un'applicazione ed erano sicuri che quella fosse l'unica visione giusta. Non vorrei dilungarmi sugli ulteriori effetti di questo approccio. Per questo ritengo necessario sottolineare ancora una volta che la semplicità è la chiave del successo.

4. Sviluppo. La costruzione dell'applicazione dovrebbe iniziare con UX, Design, Backend e Frontend. In breve, tutto inizia con i semplici "must have" che costituiscono il prodotto MVP. Una volta raggiunta questa fase di sviluppo, ci si può concentrare sullo sviluppo delle funzionalità chiamate "nice to have".

Sintesi

A mio parere, questi sono quattro principi fondamentali che sono ottimi per la gestione dei progetti di sviluppo software. Questo approccio riduce i rischi di distrazioni inutili, di allungamento delle ore di lavoro e di inefficienza dei costi.

Infine, vorrei fare un altro esempio. Qualche tempo fa abbiamo ricevuto le specifiche di un progetto da un cliente. Ci siamo immediatamente uniti al squadra per valutarlo. Il cliente si aspettava che creassimo il prodotto entro dodici mesi. In base al nostro approccio, abbiamo proposto un approccio MVP e un periodo di sviluppo di tre mesi. Alla fine siamo riusciti a convincere il cliente. Dopo qualche mese, il cliente è rimasto impressionato dalla soluzione. Il cliente ha ricevuto il prodotto funzionante in tempi relativamente brevi. Nel caso di alcune funzionalità, ha deciso di cambiare il progetto ipotizzato fin dall'inizio.

Il modello che ho descritto in questo articolo è il nostro modo di implementare con successo i progetti di sviluppo software. Credetemi, questa soluzione non solo migliora il lavoro e lo rende efficace, ma, di conseguenza, aiuta a evitare il rischio di creep e di gold plating.