Come posso stimare i progetti quando devo includere una curva di apprendimento per le nuove tecnologie?

A volte, ci sono progetti di ricerca e sviluppo in cui nulla è noto in anticipo sulla tecnologia, i concetti e il cliente. Tuttavia, il gestore ha ancora bisogno di stime del tempo. Cosa posso fare per produrre stime utili?

Onestamente, come scrive Nassim Nicholas Taleb nel suo libro The Black Swan: "non possiamo proprio prevedere". Principalmente a causa di incognite-incognite. In genere è meglio comunicare questo fatto, il fatto che non è possibile prevedere, invece di comunicare un preventivo.

Come scrive Taleb: è meglio avere ragione, piuttosto che sbagliare. Quindi assicurati di comunicare il fatto che hai difficoltà a stimare e usa cose come "l'apprendimento delle curve nella nuova tecnologia" come uno degli argomenti. Ciò significa che la gamma della stima sarà grande: "questo progetto avrà un costo compreso tra 100.000 e 500.000".

Dicendo una cosa del genere, colui che ti chiede di stimare qualcosa si rende conto che le cose non sono così semplici.

La prima cosa assoluta di cui hai bisogno è un'idea del campo di applicazione. Più concreto è il migliore, ma qualsiasi forma di requisiti può essere utilizzata per produrre stime iniziali. I requisiti del cliente, la visione e la portata e i documenti concettuali possono essere utilizzati in anticipo. Man mano che i requisiti e l'ambiente operativo iniziano a diventare più chiari, le stime miglioreranno. Una maggiore comprensione del cliente (in particolare le interfacce tra il cliente e l'organizzazione in via di sviluppo), il team che esegue il lavoro, le tecnologie da utilizzare, l'architettura del sistema e una progettazione dettagliata contribuiranno tutti a una stima più accurata. Questo è visibile nel Cono di incertezza.

Se si utilizza uno strumento di modellazione parametrica, come SLIM o COCOMO (solo Intermedio o Avanzato, poiché Basic non tiene conto dei fattori di costo), dovrebbero esserci fattori di aggiustamento per la non familiarità della tecnologia. Ad esempio, COCOMO ha un gran numero di driver di costo , compresi alcuni che sono specificamente orientati verso la familiarità con la piattaforma di destinazione, nonché il linguaggio e gli strumenti utilizzati per sviluppare il sistema. SLIM rappresenta anche l'esperienza complessiva del team di sviluppo, che dovrebbe includere considerazioni sugli strumenti e sulle tecnologie utilizzate.

Con questa tecnica, l'output degli strumenti di modellazione viene in genere convalidato perché è stato utilizzato con successo per stimare progetti software precedenti per molti anni in molte organizzazioni. Tuttavia, l'output è buono solo quanto l'input allo strumento.

Se non stai usando modelli parametrici per la stima, dovrai semplicemente considerare questi fattori quando produci le tue stime. Diventa più una richiesta di giudizio, ma puoi prendere in considerazione attività come la lettura della documentazione, l'impostazione del nuovo ambiente di sviluppo e lo sviluppo di applicazioni di esempio sulla piattaforma di destinazione o con le lingue di destinazione.

In questi casi, dovrai suddividere le stime per attività ed essere in grado di utilizzare il tuo giudizio professionale per eseguirne il backup. Si spera che tu abbia dati storici e altre prove concrete su cui basare le tue stime. Altrimenti, è più una battaglia in salita.

Separare i principali tempi di formazione e ricerca dai tempi di sviluppo. Suddividere il progetto in più sottoprogetti con lieto fine. Assicurati di creare una prova di concetto dopo l'allenamento.

Se non conosci la tecnologia, non ti avvicinerai mai al tempo di sviluppo effettivo. Aumenta questo rischio all'inizio del progetto e sii generoso nel tuo preventivo. Questo vale per le tecnologie di base che tu e il tuo team non conoscete.

Dipende, ho usato FPA ( Function Point Analysis ) per la maggior parte del tempo, ma eravamo in questo "sviluppo web intraprendente", voglio dire, sapete, le aziende web di Forbes 500.

Lì l'attività può essere sempre divisa in due parti: una, che si adatta davvero bene a FPA: hai interfacce di input, interfacce di output, file logici interni (ovvero tabelle / tipi di database da esportare) e hai questi sistemi complessi e sconosciuti .

Nella versione semplice, l'attività complessa è un componente già scritto, è solo difficile e sconosciuto interfacciarsi con esso.

La versione difficile è quando deve essere scritta, quindi stime basate sul pilota, COCOMO, qualunque cosa.

Due cose, tuttavia, di importanza:

1. Ogni tipo di sistema di stima deve avere un tempo di calibrazione per la tua organizzazione. Non ti sviluppi mai da solo, almeno c'è un cliente in attesa del tuo codice (o non saresti così disperato per questo, scrivendo codice per il tuo bene). La domanda non è "quanto velocemente può essere sviluppata?", Ma "quanto velocemente può essere sviluppata con tutti voi?"

2. Una volta avevo un manager che leggeva quel romanzo di Black Swan e ne era maniaco. Ci stava dicendo che era impossibile stimare, e stavo facendo le mie solite stime precise al + -10% senza sosta ...

Faccio progetti che si adattano a questa descrizione in qualche modo regolarmente e non l'ho ancora capito! Per fortuna dove lavoro mi viene data la latitudine di fare ciò di cui ho bisogno e di non avere inutili limiti di tempo. I progetti non hanno sempre successo e questa è solo una parte di ciò che il lavoro fa con così tante incognite. La società acquisisce conoscenza ogni volta però.

Mi dispiace che non aiuta affatto.

Stimare quanto tempo ci vorrà per fare un progetto simile usando una tecnologia familiare. Moltiplica per 4. Aggiungi del tempo di apprendimento.

Se la stima è troppo breve, sembrerai ingenuo e arrogante. se la stima è troppo grande sembrerai ignorante e incompetente. Scegliere saggiamente.