Alcune abitudini non vengono mai messe in discussione. E a torto. La stima dei carichi di lavoro per prevedere i costi e la stima delle scadenze attraverso la "sacrosanta tabella di marcia" sono alla base della gestione dei progetti.
La tradizione è tale che lo consideriamo un imperativo, un obbligo. Ma la domanda merita di essere posta.
Dubbi sulla pertinenza delle stime
Le stime sono ovunque:
- Già prima dell'inizio di un progetto, ogni fornitore di servizi si impegna a rispettare costi e scadenze per assicurarsi una vendita;
- durante la fase di contrattazione, con la definizione di penali per i ritardi di pagamento;
- e alla fine del progetto, quando si verifica il rispetto degli impegni.
Ciò dimostra che il criterio principale per il successo di un progetto è il rispetto degli impegni iniziali. Le stime iniziali erano giuste?
Quindi il successo di un progetto non è legato al buon funzionamento del prodotto? O all'adozione di massa dello strumento da parte degli utenti? O all'aspetto finanziario di un forte e rapido ritorno sull'investimento?
Un progetto che ha superato i tempi e il budget, è stato ampiamente adottato dagli utenti e ha avuto un ROI esponenziale, sarebbe davvero un fallimento?
Esiste una pletora di metodi per effettuare le stime
Da più di mezzo secolo, avendo capito che i metodi precedenti erano inaffidabili, ognuno ha escogitato il proprio. Tutti hanno una cosa in comune: sono previsioni sul futuro... Attività irrazionali.
Uno dei più noti è quando, dopo aver letto le specifiche, lo stimatore utilizza gli unici due processi intellettuali disponibili in quel momento: il "dito bagnato" e la "stima", per darvi un numero preciso di giorni lavorativi e un calendario preciso.
Alcuni metodi di stima sono molto elaborati, come COCOMO, che include molte formule matematiche che lo fanno sembrare eminentemente scientifico. Tuttavia, ciò presuppone che questi informatici sappiano, prima di iniziare lo sviluppo, quante linee di codice ci saranno alla fine del progetto... Una sfida che né gli indovini né gli oracoli negherebbero.
I metodi agili hanno anche portato i loro metodi di previsione, come il poker di pianificazioni, rendendoli meno rischiosi:
- Le stime sono effettuate da sviluppatori esperti nel lavoro da svolgere;
- parlando direttamente con il cliente;
- su un perimetro funzionale molto limitato.
Tuttavia, il poker di pianificazione non può essere utilizzato prima dell'inizio del progetto. Richiede tempo e quindi è costoso. Inoltre, che senso ha indovinare cosa verrà consegnato tra quindici giorni?
Gli svantaggi delle stime
Quando la scadenza viene raggiunta e il lavoro è stato completato solo in parte, gli sviluppatori hanno due opzioni: annunciare che hanno bisogno di più tempo o consegnare al cliente il lavoro così com'è, con tutti i bug che ciò comporta. Più lunga è la scadenza, più bassa è la qualità.
Per quanto riguarda il debito tecnico, se il lavoro non può essere svolto correttamente, si prenderanno molte scorciatoie. Risultati :
- meno aggiornamenti software;
- perdita di conoscenze tecniche e funzionali ;
- sviluppi più lunghi, costosi e rischiosi;
Il meglio arriva quando il cliente si sente dire "è più conveniente riqualificare tutto piuttosto che apportare modifiche al software", sintomo della completa perdita di controllo sul progetto.
L'ambiente in cui operano le organizzazioni è in continua evoluzione.
Un concorrente lancia un nuovo prodotto, vengono pubblicati i decreti attuativi di una nuova legge, si presenta un'opportunità di crescita esterna e così via. Sono tutti eventi non pianificati che possono richiedere un rapido adattamento delle applicazioni.
Allo stesso tempo, un cliente che ha espresso il desiderio di un software con tali o tali funzioni può cambiare idea, perché dovrà riflettere sulle sue esigenze, consultarsi con altri e svilupparle ulteriormente.
Se all'inizio i preventivi possono sembrare rassicuranti e dare l'impressione di un controllo, in realtà sono una trappola che si chiude progressivamente sul cliente. Alla fine, il fornitore di servizi rifiuta qualsiasi proposta di aggiornamento del software con il pretesto di rispettare gli impegni presi.
La necessità di preventivi non è tanto una necessità aziendale quanto un segno di sfiducia (da parte del cliente nei confronti del fornitore di servizi o del manager nei confronti dei suoi team)?
Se la "scadenza", il limite fatale, non viene rispettato, partiranno e-mail "assassine" perché le persone "hanno la testa sul ceppo". Una cultura mortale, dove la paura è alla base della gestione.
Questo è l'opposto di una cultura basata sull'iniziativa individuale, sul desiderio, sul rinforzo positivo di cui le aziende hanno un disperato bisogno nelle loro organizzazioni.
Il movimento «no estimate»
Il movimento "no estimate" non è un'utopia e chi lo pratica quotidianamente lo sa.
Ciò che conta è la rilevanza delle funzionalità per gli utenti e il valore creato dal software per il cliente.
Ma questo richiede il coraggio di sfidare l'ordine stabilito e una grande immaginazione per reinventare tutto: le vendite, la contrattualizzazione, le interazioni tra clienti e fornitori di servizi, ma anche la gestione degli sviluppatori e la gestione dei progetti.
Con "no estimate", i clienti potranno gestire i loro progetti in modo molto preciso, in modo da ottenere le funzionalità di cui hanno realmente bisogno. Potranno beneficiare di un'assistenza per tutta la durata del progetto, qualunque sia la sua direzione.
Ridiamo ai clienti il potere che è stato loro negato per troppo tempo: cambiare idea sul loro progetto.