Stima del progetto con requisiti crescenti

Devi chiarire al cliente che le modifiche ai requisiti sono anche modifiche all'ambito e fornire aggiornamenti alle stime ogni volta che viene apportata una modifica ai requisiti.

Le stime del progetto sono denominate stime per un motivo. Non sono promesse. Se il cliente vuole farle promesse, è un affare diverso; ora devi fornire stime molto più grandi che hanno una maggiore probabilità di successo, usando i requisiti congelati .

La maggior parte delle stime di progetto fornisce un certo livello di riempimento, in qualsiasi punto dal 20% al 100% di premium time (o superiore) rispetto a una stima ideale. Assicurati che le tue stime includano questo riempimento.

Esistono metodologie agili che offrono una migliore visibilità per il cliente, in modo che possano avere un'idea migliore dello sforzo richiesto e di come le sue modifiche influiscono sulle scadenze.

Devi aggiornare le stime quando aggiornano i requisiti e avere una specifica definita di ciò che il cliente accetterà come "fatto". "La mia stima precedente era per il set di funzionalità X, Y. Se vuoi che aggiunga Z, ritengo che estenderà la data di consegna entro ...", ecc.

Dovresti comunicare formalmente impatto su pianificazione e costo al cliente e alla gestione quando modifichi i requisiti o ne aggiungi di nuovi. Fai del tuo meglio per imporre il meccanismo di approvazione formale in modo che riflettano profondamente prima di chiedere qualsiasi novità o cambiamento. Altrimenti continuerai a sentire "Voglio aggiungere XYZ" e poi "Ho detto XYZ che intendevo ABC".

Pensa al tuo progetto come a un triangolo (un mio amico PM ha effettivamente creato un triangolo fisico che ha usato per aggiungere effetti). I bordi sono chiamati tempo , costo e ambito . Dì al tuo cliente che può avere il controllo di 2 lati, ma tu (responsabile della consegna) devi avere il controllo di almeno uno.

Quindi, puoi farlo in modo rapido ed economico, ma devi avere il potere di tagliare l'ambito.

Oppure puoi ottenere più funzioni, ma ciò richiederà più tempo o più denaro.

Ulteriori informazioni su link

Puoi provare ad implementare Scrum , una metodologia agile che, secondo la tua situazione, potrebbe essere molto utile.

Da Wikipedia:

Scrum is a process skeleton that contains sets of practices and predefined roles. The main roles in Scrum are:

1. the “ScrumMaster”, who maintains the processes (typically in lieu of a project manager)
2. the “Product Owner”, who represents the stakeholders and the business
3. the “Team”, a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog”, which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting.

Non si tratta di metodologie, ma di comunicazione con un cliente.

Ho avuto molte situazioni in cui i clienti volevano aggiungere costantemente nuove funzionalità a un progetto non finito e siamo rimasti sorpresi del motivo per cui avrebbe aumentato i costi e i ritardi complessivi. Il contesto e la personalità di questi clienti sono diversi, hanno richiesto approcci diversi, ma potrei provare a isolare alcune linee guida e consigli:

• Assicurati che un cliente abbia accesso alle informazioni generali necessarie per capire perché una modifica di un requisito può avere un impatto sia sui costi che sui ritardi . In altre parole, pubblica alcuni articoli su queste cose, spiegando ciò che una persona non tecnica potrebbe non sapere affatto.

Ad esempio, per la maggior parte delle persone è assolutamente strano che un cambiamento che considerano piccolo possa avere un impatto enorme sul progetto ed essere molto costoso (vedi esempio nella mia domanda ). Se chiedono di fare qualche cambiamento, e ogni volta che gli dici, senza spiegare nulla, che dovrebbero pagare migliaia di dollari quando se lo aspettavano gratis o per qualche dozzina di dollari, probabilmente penserebbero che sei solo rubando i loro soldi. Questo è particolarmente vero dal momento che alcuni programmatori non etici e società di software sviluppano prodotti non gestibili (quindi non puoi chiedere di cambiarli in seguito da un normale sviluppatore), quindi chiedi di pagare troppo per ogni modifica.

• Assicurati che un cliente abbia compreso perché il specifico cambiamento che desidera abbia un impatto su un costo . Per questo, puoi darle i link ai tuoi articoli (vedi il punto precedente), o semplicemente riassumere, in modo non tecnico, ciò che è necessario per apportare una modifica richiesta.

Tali spiegazioni sono anche una buona idea poiché consentono al cliente di comprendere meglio il prodotto e il cambiamento. In alcuni casi, alcuni dei miei clienti finirono col dire che il cambiamento che volevano non era troppo intelligente e che lo avrebbero fatto in altro modo. Puoi anche suggerire cose. È molto apprezzato da alcuni clienti (attenzione: altri lo odiano) e mostra che sai di cosa stai parlando (rispetto al codice scimmia che traduce semplicemente i requisiti in codice, senza pensare troppo ai possibili approcci) .

• Assicurati che un cliente non possa fare quello che vuole, a meno che non sia davvero sicuro. Per alcune persone, l'unico modo è bloccare i requisiti in modo definitivo prima di iniziare con il codice . Altrimenti, è un disastro e il progetto non finirà mai . Per gli altri, è semplicemente una buona idea non vedere mai un progetto non terminato (in generale i miei clienti hanno accesso dal vivo al prodotto non terminato molto presto, quindi possono fare commenti / regolazioni anche in anticipo).

Ad esempio, ho avuto un cliente che, dopo aver inviato i requisiti "finali", ha inviato, in media, dieci messaggi al giorno con dieci modifiche ai requisiti, passando da piccole modifiche ("È possibile modificare la larghezza del bordo della zona centrale in la home page da tre a sei pixel? ") alle modifiche che hanno interessato l'intero progetto (dopo due mesi di sviluppo, una settimana prima del rilascio:" Infine, penso che ASP.NET sia una cattiva idea. Potresti passare a PHP per favore? ").

Quindi per quel cliente , siamo stati costretti a bloccare tutti i requisiti prima di scrivere il codice. Era scritto nel contratto. Nessuna modifica è stata accettata prima del rilascio finale.

Non è stato poi così male, finalmente, dal momento che curiosamente abbiamo permesso di essere molto organizzati: il progetto è stato rilasciato, in base ai vecchi requisiti, e poi, alcuni giorni dopo, abbiamo iniziato la prossima versione da zero con un insieme di requisiti completamente diversi.