Gestione dei progetti software - consulenza necessaria

La cosa da ricordare è che il prodotto originariamente richiesto è molto raramente il prodotto che il cliente desidera realmente. L'80% di esso non verrà mai utilizzato e il restante 20% verrà utilizzato in modo diverso.

Cambiare i requisiti mentre il progetto procede quasi sempre consente al cliente di ritrovarsi con il prodotto di cui aveva bisogno, piuttosto che con il prodotto che desiderava. Questo è buono. Per te e per loro.

Ma hanno bisogno di capire che ogni nuovo requisito costerà loro un vecchio requisito (o ritarderà il progetto) e dovrebbero sempre passare attraverso un Product Owner, che sta gestendo sia il piano a lungo termine che lo sprint corrente (che non dovrebbe cambiare a meno che non sia necessario).

Ottieni un backlog di storie di alto livello e segnalo punti-punto - abbattili solo quando si avvicinano alla cima della pila. Inoltre, avvia un grafico di burn-down. Metti tutte queste cose in un posto visibile al cliente; se ciò significa una copia elettronica, abbastanza equa, ma se visitano regolarmente il tuo ufficio, allora copri i muri con le lavagne e metti le informazioni lì, dove tutti possono vederlo e farsi guidare da esso.

Questo servirà per insegnare loro su causa ed effetto. Quando riescono a vedere il lavoro viene controllato ma il grafico di burn-down non si muove nella giusta direzione, è molto facile spiegargli perché. E se non lo è, è la tua squadra che ha bisogno di mettere in discussione le loro stime.

Il più delle volte, tali progetti sono guidati da scadenze piuttosto che da funzioni, in modo che il cliente possa esaminare le funzionalità che hanno chiesto e iniziare a pensare "aspetta, questa funzione non è così importante, dovremmo perderla per assicurarci di raggiungere la scadenza. "

Infine, insegna loro che lo sprint dovrebbe essere sacrosanto. Una volta che hanno richiesto qualcosa da consegnare in questo sprint, il costo di cambiare idea dovrebbe essere maggiore di cambiare idea sul piano futuro. Aggiungi un lavoro in 3 punti allo sprint corrente e dovresti rimuovere un lavoro in 5 punti da esso.

clients have direct access to the developers any time they want

Questo è un problema importante proprio lì. I clienti dovrebbero mai avere accesso diretto agli sviluppatori. Gli sviluppatori dovrebbero sempre essere protetti da richieste ad-hoc, che dovrebbero essere canalizzate attraverso la gestione o lo sviluppatore capo (o una combinazione di questi).

Una volta che i requisiti sono stati raccolti dal team lead / manager (e controllati dal lead - alcune richieste dovrebbero essere reinserite, fare ulteriori indagini su di loro, ecc. ecc. prima di colpire direttamente gli sviluppatori). Una volta che i requisiti sono bloccati, allora dovrebbe essere dato agli sviluppatori, che sono responsabili della prioritizzazione (con l'aiuto del lead) e della stima.

Anche se lo sviluppatore deve cercare ulteriori dettagli dal client a quel punto, (IMHO) dovrebbe essere essere fatto attraverso un singolo punto di contatto (lead / manager) per evitare confusione tra i clienti chi dovrebbero contattare e quando. Quindi, ovviamente, più interruzioni colpiscono uno sviluppatore, meno sono produttive.

Non ho il documento a portata di mano, ma è provato che ci vogliono almeno quindici minuti perché uno sviluppatore torni nello spazio della testa del programmatore quando si verificano interruzioni. È compito del manager (e del lead) proteggere le interruzioni assolutamente necessarie dagli sviluppatori per consentire loro di fare il loro lavoro.

Una volta che hai iniziato a proteggere gli sviluppatori dai clienti, il passo successivo è gestire meglio le aspettative dei clienti: Se non è specificato nelle specifiche che sono state disattivate (spero che i tuoi clienti < strong> do si disconnette da loro), non fa parte del progetto . I clienti devono capire che se vogliono aggiungere compiti, altri non possono essere completati in una data pietra miliare. Ciò dà loro loro l'onere di dare la priorità a ciò che vogliono fatto e non fatto una volta che gli sviluppatori hanno fornito una stima dell'attività per la richiesta.

Tu devi educare i tuoi clienti sull'impatto delle loro richieste. Generalmente, una volta capito come ciò che stanno chiedendo influenza il resto del progetto, scoprirai che ricevi molte meno richieste che non sono ben pensate.

software specifications are not as thorough as possible

Essere agili non significa non produrre documentazione approfondita, ma minimizzare la documentazione che è dispendiosa. In altre parole, producendo ciò di cui hai bisogno, quando ne hai bisogno, in una forma "appena abbastanza buona" che può essere evoluta come il bisogno implica. Consiglierei di leggere l'articolo di Scott Ambler sulla documentazione agile e di assicurarci di produrre abbastanza del giusto tipo di documentazione. Ci sono molte considerazioni su quali documenti produrre, quindi assicurati di tenere conto dei punti chiave.

clients have direct access to the developers any time they want

Questa è generalmente una cattiva idea. Le persone in un ruolo di sviluppatore sono pagate per sviluppare software. Alcuni sviluppatori potrebbero avere più ruoli, incluso un ruolo che richiede l'interfaccia con i rappresentanti dei clienti. Tuttavia, per massimizzare il tempo di ognuno che fa qual è il loro lavoro, consente solo ai clienti di parlare con certe persone. Queste persone sarebbero responsabili della diffusione delle informazioni alle persone appropriate della squadra in modo che possano essere gestite.

We are having a lot of difficulty managing this process. With no experienced software project managers in our team, we need to come up with a better way to both internally identify whether work being requested is “out of spec”, and be able to communicate this to a client in such a manner that they can understand why what they are asking for is “extra” work. We need a way to track this work and be transparent with it.

Questo viene fatto implementando una commissione di controllo delle modifiche o una commissione di revisione delle modifiche. Queste persone sono quelle che esaminano tutte le modifiche proposte, indipendentemente da dove provengono. Una modifica potrebbe essere una richiesta da parte di un cliente per una nuova funzionalità, un rapporto sui difetti che proviene dal team di controllo qualità / test o un'attività che uno sviluppatore vorrebbe fare per semplificare il proprio lavoro. La commissione esamina ogni richiesta in merito alla pianificazione, al budget e alle risorse disponibili, decide se è una richiesta valida, la stabilisce in ordine di priorità e, a seconda della metodologia di processo, la assegna a uno sviluppatore. Se una funzione viene rifiutata o differita, spiega anche il motivo.

Tutte le risposte qui sono state buone, solo per buttare i miei 2 centesimi.

Personalmente non darei al cliente l'accesso diretto agli sviluppatori. Il cliente, la maggior parte delle volte, non saprà come ottenere il meglio dallo sviluppatore e l'impatto che avranno le sue richieste. Qualcuno mi ha detto una volta "puoi essere un imbuto di merda o un ombrello di merda", potresti non vederlo ma sei una specie di cacca di merda - gli sviluppatori sono le persone più importanti in un progetto, non il cliente, nel mio opinione.

Riecheggiato qui già, il cliente deve capire che lo sviluppo è un settore basato sul servizio, stanno acquistando le mani sulle tastiere, non su un'app web.

Vorrei provare a dare una stima, a prendere il budget dei clienti. Distribuisci i tuoi progetti: settimana d'inizio, settimana sprint, settimana di revisione, settimana sprint, settimana di revisione ecc. Più tempo (recensioni) riesci a ottenere meglio - idealmente non voglio che gli sviluppatori lavorino più di due giorni alla settimana un progetto.

Il mio obiettivo è far sì che il prodotto sia "di lancio" al termine di ogni settimana sprint, nelle settimane di revisione possiamo quindi lavorare con il cliente per decidere cosa succede nella settimana successiva. Se la squadra che sta lavorando al progetto può liberare solo 20 unità di lavoro in una settimana, allora ci devono essere 20 unità di lavoro - se vuoi aggiungere lavoro devi portare via altri lavori.

Se il cliente richiede nuove funzionalità, prenota in un altro sprint - di solito dico "se pensi che vorrai prenotarlo ora, perché potremmo essere prenotati con un altro progetto entro la fine".

Trovo che sia più facile da pianificare, più facile da pianificare e insegna al cliente l'impatto dell'aggiunta di funzionalità.

Spero che sia di qualche aiuto.

Mi sembra che ci siano 2 problemi separati.

1. La funzione implementata non è in realtà come volevano che fosse.
2. Vedendo la funzione, ora desiderano svolgere un lavoro aggiuntivo.

Suggerirei quanto segue:

• Crea l'elenco di priorità di ciò che viene elaborato pubblico

La gestione (il tuo o il tuo manager) dovrebbe essere il modo in cui il lavoro viene definito come prioritario. Il lavoro che non ha la priorità non ha tempo di sviluppo. Consenti al tuo cliente di comunicare con te sul suo lavoro e quando verrà avviato. Ho trovato che i clienti di solito vogliono solo essere sicuri che non siano stati dimenticati.

• Implementa l'approvazione in base alla funzionalità per caratteristica

Lavoriamo a fette verticali al lavoro. Ciò significa che quando una funzione viene eseguita può essere dimostrata in un sistema funzionante. Ho gli sviluppatori comunicare prima e dopo l'avvio delle funzionalità con il cliente. Ciò assicura allo sviluppatore una buona idea di ciò che il cliente desidera, il cliente può apportare piccole modifiche che non gli sono mai accadute prima o che non ha acquisito nei requisiti. Una volta implementata la funzionalità, lo sviluppatore ottiene l'approvazione in modo che il cliente ottenga ciò che desidera. Gli sviluppatori devono sapere come rinviare le richieste di lavoro aggiuntivo che non appartengono all'ambito della funzione al gestore appropriato.

• Crea sempre i mockup per primi

Crea sempre i mockup e trattali come se fosse una tua caratteristica. Quindi chiedi al cliente di valutare i prototipi e di firmarli.

• Follow-up

Follow up come progetti (o fasi del progetto) sono completati. Ho parlato con i clienti per assicurarmi che fossero contenti di ciò che hanno ottenuto. Chiedi loro come hanno apprezzato il processo utilizzato durante il progetto. Hanno ottenuto ciò che vogliono, hanno qualche suggerimento, ecc.

Ho trovato che queste tecniche funzionano abbastanza bene per me.