Cosa fare quando un cliente ha aspettative non realistiche? [chiuso]

Ho lavorato a un progetto negli ultimi sei mesi presso un sito client, dal momento che richiedono la riservatezza dei dati e non volevano che lavorassimo nel nostro ufficio.

Quando mi sono presentato da solo su questo sito client, mi è stato detto che dovevo finire il progetto in due mesi.

Dal momento che il client non è una società di software e, a causa di varie politiche, ci sono voluti circa 20-25 giorni solo per darmi i diritti sulla mia macchina per installare cose come Eclipse, Tomcat, ecc. Anche dopo il ritardo nella configurazione dell'ambiente, si aspettavano ancora che completassi il progetto nello stesso periodo di due mesi.

Non mi hanno fornito alcun documento sui requisiti, ma dal momento che sto lavorando sul sito del cliente, ci siamo incontrati regolarmente per discutere i requisiti.

Dopo sei mesi l'applicazione non è ancora terminata e tutti mi stanno incolpando, ma non riescono a rendersi conto che abbiamo aggiunto molte più funzionalità rispetto a quelle discusse nei primi incontri.

Ho dovuto rifare molte cose durante questo periodo, ad esempio separare un modulo in due sezioni; poche settimane dopo, mi hanno chiesto di unire nuovamente le due forme perché è confusa, e così via.

L'ambito dell'applicazione aumenta ogni giorno ma pensano ancora che sia un progetto di due mesi che è stato ritardato. Quando ho detto loro che l'ambito di applicazione è aumentato, mi chiedono perché all'inizio non ho richiesto requisiti.

Lavoro già 11-12 ore ogni giorno e viaggio 3-4 ore, e ora si aspettano che vada anche il sabato.

Devo fare tutto qui: prendere requisiti, design, codice e test.

Per favore, mi consigli cosa fare in questo caso?

_{Dettagli aggiuntivi: avevamo un elenco di risultati finali, ma poi hanno aggiunto alcune altre cose dicendo che anche questi sono importanti. Hanno anche cambiato alcuni risultati. Non hanno nemmeno il loro server UAT, testano sulla mia stessa macchina di sviluppo tramite il suo indirizzo IP.}

Questo è un fallimento del tuo manager . In quanto appaltatore, la vostra azienda non avrebbe dovuto trovarsi in una situazione con un termine così stretto senza una serie di requisiti precisi per iscritto. Niente di tutto ciò "hanno aggiunto funzionalità" in seguito senza senso - ogni volta che è successo, avrebbero dovuto firmare su un programma aggiornato che hai dato loro .

Il tuo manager, poiché sta pianificando di incontrarlo, deve ottenere dal cliente una serie specifica di requisiti: il progetto dovrebbe fare A, B, C, D ed E. E dopo, è completo. La firma del cliente deve trovarsi su quel documento accettando tale elenco. Avresti dovuto averlo dall'inizio.

Se il tuo manager non ti supporta e non ti supporta in questo - e non lo dico molto spesso - inizia a cercare un altro lavoro. Perché probabilmente finirai per essere il capro espiatorio di tutto il casino. E se sei disposto a lavorare per 11 ore al giorno e 3 ore di viaggio, è evidente che sei un individuo molto dedicato che merita di meglio.

L'importante in tali situazioni è costruire una traccia cartacea del CYA. Nulla dovrebbe essere fatto senza averlo scritto, soprattutto in una relazione d'affari complicata. Attenersi al programma iniziale, sebbene siano necessari 20 giorni per farti lavorare, è una grande bandiera rossa che diventerà complicata.

Tieni una riunione in cui sono richieste funzionalità aggiuntive? Scrivilo dopo, tagga "+ X giorni al programma attuale" su ogni articolo e spediscilo a tutti i soggetti coinvolti. Se si utilizza solo il sistema di posta interno del cliente, stamparlo ulteriormente, incluso l'elenco dei destinatari:: cc: e bcc: e archiviarlo accuratamente. Inoltre, come ha affermato GrandmasterB, il cliente dovrebbe firmare tali modifiche ai requisiti originali.

Se il programma richiesto non può essere mantenuto, scrivilo a loro. Se si verifica un cambiamento, scrivilo a loro, comprese le conseguenze. E così via.

Questo non è per "Te l'ho detto." quando il casino alla fine colpisce il muro, comunque non lo ascolteranno. Questa è la tua assicurazione quando il cliente ti fa causa perché pensa che tu non abbia adempiuto al contratto o quando la tua società fa causa al cliente perché nega il pagamento.

Da quello che descrivi, sembra che tu stia partecipando a un classico progetto della Marcia della morte :

Nella gestione dei progetti , una marcia della morte è uno dei diversi tipi di progetti patologici che coinvolgono un'analogia disphemistica, di umorismo oscuro con le marce della morte reali, ad esempio essere oberati di lavoro estenuante e (spesso e soprattutto) sovraccarichi di lavoro estenuante per motivi infondati in un progetto che è ovviamente ad alto rischio di esito negativo (es. fallimento del progetto e, eventualmente, minaccia di danni alla reputazione personale e di gruppo) . Pertanto, il nome "marcia della morte" può essere applicato a un progetto che alla fine ha successo ma implica un tratto domestico di superlavoro insostenibile o (forse più spesso) a un progetto che qualsiasi membro intelligente e informato può vedere è destinato a fallire (o è ad altissimo rischio di fallimento) ma che i membri sono comunque costretti a recitare dai loro superiori comunque ...

Fenomeno è ben noto e ci sono molte pubblicazioni su come procedere, incluso ovviamente il libro fondamentale di Edward Yourdon, Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Project .

L'articolo di Wikipedia citato sopra costituisce un buon punto di partenza per cercare ulteriori informazioni, ricerche e raccomandazioni per coloro che sono coinvolti / interessati ai progetti della marcia della morte .

Camminando nei tuoi panni, la prima cosa che prenderei in considerazione sarebbe passare un riferimento al precedente articolo al mio manager.

In questo modo farebbe sapere loro che sono consapevole di ciò che sta succedendo, e forse anche aiutarli a guidarmi in termini di quadro fornito per questa nozione, come "Guarda, il nostro stato attuale è vicino a quello descritto nel capitolo Xsu Yourdon. Controlla fuori, insieme al capitolo strettamente correlato Yecc ... "

Nel caso (non molto probabile) che il manager non sia a conoscenza di questo campo di studio, fare riferimento potrebbe fornire loro un sacco di spunti di riflessione per aiutare a identificare la situazione e decidere come gestirla.

Onestamente, se è possibile farlo, la soluzione migliore è smettere. Situazioni come questa sono tossiche per te e raramente migliorano con il tempo, non importa quanto ci provi.

Meglio tagliare le perdite e trovare un concerto diverso. Ma rifletti sulla tua esperienza e prendi i consigli dalle altre risposte su questo thread.

È una cosa seria issue in project management . Sembra che Project Managerdovresti lavorare sulla lista dei risultati e dare la priorità al cliente.

La maggior parte importante , il vostro PM should discusse sono d'accordo con il Cliente il lasso di tempo (compresa la progettazione e l'analisi di problema / soluzione) nelle stime.

Avere clear estimation of your work loade consegnare gli articoli del progetto ti alleggerirà dallo stress, oltre a aggiungere tranquillità e fiducia nel tuo lavoro.

Prova ad usare l' approccio Agile consegnando i tuoi articoli in volata (2-3 settimane) e facendo UAT (test di accettazione dell'utente) con il cliente. Ricorda, fai sempre la tua pianificazione dello sprint prima di iniziare lo sprint.

Modifica: dai commenti è chiaro che questo è davvero un fallimento del project manager . Non avere un ambiente di test e / o sviluppo adeguato impostato per un progetto serio come il tuo è un grande buco per il projectprocesso SDLC.

Pur concordando sul fatto che si tratta di un errore di gestione, è anche un errore da parte tua. A questo punto sarà molto difficile da risolvere, quindi parte di ciò di cui hai bisogno per uscirne è come gestire i progetti futuri.

Innanzitutto, è necessario insistere su un documento di base dei requisiti all'inizio del progetto. Non deve essere elegante o formale, ma non è possibile creare correttamente nulla fino a quando il client non specifica cosa è previsto. Se non lo hai per iscritto, le probabilità che il cliente sia soddisfatto del risultato finale sono approssimativamente dello 0%. Quindi questo è di fondamentale importanza. È anche tuo compito cercare le ambiguità in questo documento e chiarirle al più presto. Quando ti imbatti in uno di questi e non sei sicuro di come interpretarlo, non indovinare cosa pensi che significhi, assicurati che tu e il cliente siate nella stessa pagina su cosa significhi. Sì, questo significa più parlare con le persone, più incontri e meno programmazione. Ma ci vuole molto meno tempo per chiarire un requisito poco chiaro che per codificarlo in modo errato e quindi è necessario ricodificarlo. Inoltre, spesso devi dare loro la ricodifica gratuitamente e questo non va bene per l'azienda per cui lavori.

Successivamente, dici loro quanto tempo ci vuole per fare il lavoro e questo fissa la scadenza. Non accetti mai una scadenza basata su qualcosa di diverso dalla quantità di ore che ci vorrà per fare il lavoro per soddisfare i requisiti. Se lo fai, sarai di nuovo in una marcia della morte. Mostra loro come non è possibile rispettare la scadenza avendo una spiegazione dettagliata delle ore che ci vorranno. Non puoi adattare 200 ore di tempo di sviluppo in una settimana con un solo sviluppatore, non importa quanto lo desideri il cliente. A quel punto quando la scadenza è inamovibile, chiedi quali elementi dovrebbero essere spostati alla successiva iterazione.

Non dimenticare che il tempo di sviluppo è solo una piccola parte del tempo del progetto quando si effettuano le stime del tempo del progetto. È inoltre necessario tenere conto di riunioni e comunicazioni e-mail / telefoniche, test, implementazione, documentazione, configurazione fisica di server, workstation, software. Inoltre, nel pianificare la scadenza, puoi solo presumere che tu abbia a disposizione 6 ore al giorno e non 8. Questo è per tenere conto di ferie, lutto, tempo di malattia, ritardo inevitabile (come quando devi aspettare che ti ottengano le autorizzazioni sulla rete, ecc.), formazione, lavori non relativi al progetto (schede, riunioni delle risorse umane, ecc.). Uno dei maggiori motivi per cui le persone non rispettano le loro scadenze è che fanno il presupposto che faranno lo sviluppo e lavoreranno solo 8 ore ogni giorno. Questo semplicemente non è un presupposto realistico.

E ogni volta che aggiungono un altro pezzo, dici loro quanto tempo ci vorrà e quanto lavoro aggiuntivo sposterà la scadenza. Non chiedi di spostare la scadenza, dici loro che si sta muovendo a causa del nuovo requisito. Ora dovresti consultare il tuo manager per questo, ma è prima di tutto la tua responsabilità di assicurarti che il tuo manager sappia ogni volta che il requisito viene modificato e quanto verrà aggiunto al progetto. Assicurati che tutto ciò sia scritto, quindi puoi difenderti se necessario.

Successivamente, non permettere a te stesso di essere abusato di lavorare giorni e fine settimana di 11 ore. Questo è OK a breve (di meno di 1 settimana ogni sei mesi circa), ma a lungo termine non è semplicemente accettabile. Le persone stanche programmano più lentamente e fanno più errori. Puoi fare di più con una qualità superiore lavorando regolarmente 8 ore anziché regolarmente 11 ore. e nei fine settimana.

Ho scoperto che i grafici di Gantt possono essere molto validi in questo tipo di situazioni. Possono illustrare ai clienti il ​​programma attuale e possono essere utili per illustrare l'effetto dell'aggiunta di nuove funzionalità / modifiche. A volte dire a un cliente che la funzione x effettuerà la consegna entro y giorni non si registra con loro. Avendolo chiaramente su un grafico possono capirlo meglio.

Idealmente, ciò dovrebbe essere fatto dall'inizio del progetto. Potrebbe non essere utile spiegare i " ritardi " fino a questo punto, ma potrebbe essere d'aiuto per il futuro del progetto.

Da Wiki :

I diagrammi di Gantt illustrano le date di inizio e fine degli elementi terminali e degli elementi di riepilogo di un progetto.