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

Questo è un fallimento del tuo gestore . Tu, in qualità di imprenditore, non dovresti essere messo in una situazione con una scadenza così stretta da parte della tua azienda senza un solido insieme di requisiti in anticipo, per iscritto. Niente di tutto ciò "hanno aggiunto funzionalità" in seguito senza senso - ogni volta che ciò accadeva, avrebbero dovuto firmare una pianificazione aggiornata che tu ti diede loro .

Il tuo manager, dal momento che sta pianificando di incontrarlo, ha bisogno di ottenere dal cliente una serie specifica di requisiti: il progetto dovrebbe fare A, B, C, D ed E. E dopo averlo fatto, è completo . La firma del cliente deve essere su quel documento accettando quella lista. Avresti dovuto averlo fin dall'inizio.

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

La cosa importante in queste situazioni è costruire un sentiero cartaceo del CYA. Niente dovrebbe essere fatto senza averlo scritto, specialmente in un complicato rapporto commerciale. Attenersi al programma iniziale anche se hanno bisogno di 20 giorni per lasciarti lavorare è una grande bandiera rossa che diventerà complicata.

Tieni una riunione in cui sono richieste funzionalità aggiuntive? Scriverlo in seguito, taggare "+ X giorni sul programma corrente" su ciascun articolo e spedirlo a tutti gli interessati. Se si utilizza solo il sistema di posta interna del cliente, stamparlo ulteriormente, incluso l'elenco a :, cc: e bcc: recipients e archiviarlo attentamente. Inoltre, come ha detto GrandmasterB, il cliente dovrebbe firmare tali modifiche ai requisiti originali.

Se la pianificazione richiesta non può essere mantenuta, scrivila a loro. Se si verificano dei cambiamenti, scriviglielo, comprese le conseguenze. E così via.

Questo non è per "te l'ho detto". quando il casino finisce per colpire il muro, non lo ascolteranno comunque. Questa è la tua assicurazione quando il cliente ti fa causa perché pensa che tu non abbia adempiuto al contratto, o quando la tua azienda fa causa al cliente perché nega il pagamento.

Da ciò che descrivi, sembra che tu stia partecipando a un classico progetto Death March :

In project management, a death march is any of several types of pathologic projects involving a dysphemistic, dark-humor analogy to real death marches, such as being gruelingly overworked, and (often and most especially) being gruelingly overworked for ill-founded reasons on a project that is obviously at high risk of bad outcome (i.e., project failure, and possibly threat of personal and group reputation damage). Thus the name "death march" may be applied to a project that is ultimately successful but involves a home stretch of unsustainable overwork, or (perhaps more often) to a project that any intelligent, informed member can see is destined to fail (or is at very high risk of failure) but that the members are nevertheless forced to act out by their superiors anyway...

Il fenomeno è ben noto e ci sono molte pubblicazioni su come procedere, incluso naturalmente il libro di Edward Yourdon Death March: Il progetto completo di sviluppatori di software per sopravvivere a Mission Impossible ".

articolo di Wikipedia sopra citato costituisce un buon punto di partenza per cercare ulteriori informazioni, ricerche e raccomandazioni per quelli coinvolti / interessati ai progetti death march .

Camminare nei tuoi panni, per prima cosa prenderei in considerazione il passaggio di un riferimento all'articolo sopra al mio manager.

In questo modo vorrei far loro sapere che sono a conoscenza di ciò che sta accadendo, e forse anche aiutarli a guidarmi in termini di framework fornito per questa nozione, come "Guarda, il nostro stato attuale è vicino a quello descritto in capitolo X su Yourdon. Scoprilo insieme al capitolo strettamente correlato Y etc ... "

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

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

Meglio per tagliare le perdite e trovare un concerto diverso. Ma rifletti sulla tua esperienza e dai il consiglio di altre risposte su questo thread.

È un serio issue in project management . Sembra che il tuo Project Manager debba funzionare nell'elenco di consegna e assegnare priorità a con il cliente.

La maggior parte importante , il tuo PM should discuss e concorda con il cliente il periodo di tempo (compresa la progettazione e l'analisi del problema / soluzione) nelle tue stime.

Avere clear estimation of your work load e gli elementi consegnabili del progetto ti libereranno dallo stress, così come aggiungerai tranquillità e fiducia nel tuo lavoro.

Prova a utilizzare lo approccio Agile consegnando i tuoi articoli nello sprint (2-3 settimane) ) e facendo UAT (test di accettazione dell'utente) con il cliente. Ricorda, esegui sempre la pianificazione dello sprint prima di iniziare lo sprint.

Modifica: Dai commenti è chiaro che questo è in effetti un errore del tuo project manager . Il non corretto test e / o ambiente di sviluppo impostato per un progetto serio come il tuo è un buco grande per project e per processo SDLC.

Anche se sono d'accordo che si tratta di un errore di gestione, è anche un fallimento da parte vostra. In questa fase sarà molto difficile risolverlo, quindi alcuni di ciò che è necessario per uscire da questo è come gestire i progetti futuri.

Per prima cosa, devi insistere su un documento di base dei requisiti all'inizio del progetto. Non deve essere elegante o formale, ma non è possibile creare correttamente nulla finché il client non specifica ciò che è previsto. Se non lo hai scritto, le probabilità che il cliente sia soddisfatto del risultato finale sono approssimativamente dello 0%. Quindi questo è di fondamentale importanza. È anche il tuo lavoro cercare le ambiguità in questo documento e farle chiarire il prima possibile. 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 alle persone e più incontri e meno codici. Ma ci vuole molto meno tempo per chiarire un requisito poco chiaro piuttosto che codificarlo male e quindi doverlo ricodificare. Inoltre, spesso devi dare loro la ricodifica gratuita e questo non va bene per la compagnia per cui lavori.

Quindi, dite loro quanto tempo ci vuole per fare il lavoro e che fissa la scadenza. Non accetti mai una scadenza che si basi su qualcosa di diverso dalla quantità di ore necessarie per svolgere il lavoro per soddisfare i requisiti. Se lo fai, sarai di nuovo in una marcia della morte. Mostra loro come non è possibile soddisfare la scadenza con una spiegazione dettagliata delle ore che impiegheranno. Non puoi adattare 200 ore di sviluppo in una settimana con un solo sviluppatore, indipendentemente da quanto il cliente lo desideri. A quel punto, quando la scadenza è fissa, chiedi quali oggetti devono 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, distribuzione, documentazione, configurazione fisica di server, workstation, software. Inoltre, nel pianificare la scadenza, puoi solo presumere che hai 6 ore al giorno a disposizione non 8. Questo è per tenere conto di ferie, lutti, tempo di malattia, ritardo inevitabile (come quando dovevi aspettare che ottenessero i permessi sulla rete ecc.), formazione, lavoro non relativo al progetto (schede temporali, riunioni delle risorse umane, ecc.). Uno dei più grandi motivi per cui le persone non rispettano le loro scadenze è che fanno l'ipotesi che faranno solo lo sviluppo e lavoreranno 8 ore su base solida ogni singolo giorno. Questo non è semplicemente un presupposto realistico.

E ogni volta che aggiungono un altro pezzo, digli loro quanto tempo ci vorrà e quanto il lavoro aggiuntivo sposterà la scadenza. Non si chiede di spostare la scadenza, si dice loro che è in movimento a causa del nuovo requisito. Ora dovresti consultare il tuo manager per questo, ma è prima di tutto la tua responsabilità per essere sicuro che il tuo manager sappia ogni volta che viene modificata la richiesta e quanto aggiungerà al progetto. Assicurati che tutto ciò sia scritto, così puoi difenderti se necessario.

Successivamente, non permettere a te stesso di abusare di lavorare nei giorni e nei fine settimana di 11 ore. Questo va bene a brevi intervalli (meno di 1 settimana ogni sei mesi circa), ma a lungo termine questo non è semplicemente accettabile. Il codice di persone stanche rallenta e commettono più errori. Puoi fare di più con una qualità più elevata lavorando regolarmente 8 ore rispetto a 11 ore regolari. e nei fine settimana.

Ho trovato che i diagrammi di Gantt possono essere molto buoni in questo tipo di situazioni. Possono illustrare ai clienti il programma corrente e possono essere utili per illustrare l'effetto dell'aggiunta di nuove funzionalità / modifiche. A volte, dire a un cliente che la funzione x ha effetto sulla consegna entro y giorni non si registra con loro. Facendolo chiaramente su un grafico, riescono a coglierlo meglio.

Idealmente dovrebbe essere fatto dall'inizio del progetto. Potrebbe non essere così utile spiegare i " ritardi " fino a questo punto, ma potrebbe aiutarti a portare avanti il progetto.

Da Wiki :

Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project.