Impostare aspettative realistiche per le scadenze

Devi davvero parlare con il tuo capo di questo e impostare alcune regole fondamentali:

• Una scadenza non è una scadenza a meno che non ti impegni a farlo.
• Una stima non è una stima a meno che tu non la dessi, e quindi è una "stima" non una dura scadenza.

Clean Coder di Robert Martin ha un capitolo davvero buono su come comunicare queste cose al tuo capo. Non è colpa tua se il team di vendita sta prendendo impegni impossibili.

Quando ottieni una nuova funzione, la stimerai e utilizzerai PERT in modo da avere una distribuzione di probabilità. "Dovrei farlo in 4 giorni ma potrebbe richiedere fino a 8". Sopportare la tua terra. Non negoziare MAI un preventivo con un venditore, finirai per commettere l'impossibile.

Dopo alcune iterazioni di questo, il venditore si spera sarà stuzzicato per sembrare stupido e adatterà il comportamento a "Verificherò con il team di sviluppo e vedremo quando possiamo farlo" piuttosto che una promessa che finisci per rompere.

Have you guys been in similar situations? What has/hasn't worked for you?

Principalmente ciò che funziona è parlare di verità al potere.

Raccogli i fatti. Presenta i fatti. Lascia che il cliente impari (o non impari) al proprio ritmo.

My team is blamed, feels discouraged and there's an overall atmosphere of defeat.

Perché la tua squadra è a conoscenza della colpa? Se il cliente ti sta bypassando e parla direttamente con il team, sei reso inefficace e devi capire perché.

La tua squadra dovrebbe ignorare la "colpa" o la mancanza di responsabilità. Dovrebbero semplicemente creare software e dovresti semplicemente comunicare al cliente cosa stai facendo e quando lo stai facendo.

Il cliente dovrebbe --- eventualmente --- crescere per comprendere il processo. Ci vuole una grande quantità di ripetizioni per rompere le cattive abitudini. Un ottimo affare.

Sono stato in questa esatta situazione e non è stato piacevole. Tuttavia, un approccio che ho fatto è stato quello di mantenere meticolosamente un record di lavoro che è attualmente in fase di sviluppo. Quando i compiti arrivano, ricordi al cliente, alla direzione o al project manager che l'altro lavoro scivolerà mentre questa è diventata la loro priorità (a volte può farli indovinare e poi continuare a spingere per allungare la scadenza).

Altrimenti, suppongo che tu debba cercare di continuare a martellare quel cesello nel muro di pietra che è il project manager / cliente liason / management / venditore che sta trattando con il cliente e accettando queste scadenze. Ho spesso martellato il fatto che se sono d'accordo che ci vorranno 5 giorni per fare qualcosa, allora ovviamente stanno parlando di 5 giorni di sviluppo, il che significa che ci vogliono 5 giorni per ottenerlo (non quando riagganciano insieme e poi spendono i prossimi due giorni a redigere una fantasia parola doc).

Tuttavia, dal momento che sei il responsabile dello sviluppo, qualsiasi decisione come questa è irrilevante se non ti viene consultata in primo luogo.

Devi anche cercare di proteggere la tua squadra da questo il più possibile. Sebbene sia difficile, devono essere tenuti al di fuori della politica del cliente / gestione quanto più possono. Se questo non è il caso, è necessario più martellamento della testa.

Fondamentalmente, non mi è piaciuto e non importa quanto duramente ho battuto il processo non è diventato perfetto. Comunque sono riuscito a migliorare un po 'le cose.

L'unica cosa che probabilmente puoi fare è parlare con il cliente. Descrivi cosa succede mentre lo vedi, descrivi tutti i rischi e così via. Ho avuto una situazione simile ed ero davvero arrabbiato. Anche adesso, quando sono responsabile di tutte le stime tecniche, sento spesso - lo vogliamo lunedì. Dico solo che non lo capirai, discutiamo di cosa ti piacerebbe avere lunedì, e poi spesso sembra che tutte le caratteristiche critiche siano abbastanza facili da implementare e il lunedì va assolutamente bene. Tutte le altre funzionalità sono quindi pianificate per le versioni successive.

Il problema è che il cliente per lo più conosce il valore commerciale della funzione, ma non si rende conto della sua complessità. Discuti e chiarisci. Sempre.

Correggi il flusso di informazioni.

• Se devi comunicare con il cliente, forza tutte le parti interessate del progetto (incluso il client) a interfacciarti direttamente con te, sempre .

Purtroppo, il potere è per lo più preso da te piuttosto che concesso dagli altri.

One of the major tasks on my plate is communicating with the client. One thing I find particularly difficult is dealing with deadlines because they are mandated by the client and I'm frequently not consulted.

Se dovresti essere responsabile della comunicazione con il cliente, perché non sei consultato sulla pianificazione (e sul budget) in modo da poter comunicare queste informazioni tra le persone responsabili per loro all'interno della tua organizzazione e le loro controparti dal lato del cliente? Penso che risolvere questo problema sarà un enorme vantaggio per te, il tuo team e il tuo progetto.

The client comes up with a feature they want to add, Feature X. Feature X would look good in the next week's app release that is about 6 business days away. At this point, the feature request needs to go through approval and there are frequently other dependencies that need to be deal with. Eventually, N days later, the feature request trickles down to my team. Even if the original dead line (that was set by a non-developer manager) was achievable it no longer is.

Questo sistema per la pianificazione sembra strano, a dir poco.

Nelle mie esperienze, il cliente firma per una particolare versione. Potrebbero inviare un elenco di funzionalità e modifiche che desiderano e quando lo desiderano, quindi negoziare con il team che crea il software. Oppure potrebbero fornire un elenco di funzionalità prioritarie al team di sviluppo e il team di sviluppo fornisce stime su quando possono spedire varie serie di funzionalità. Ci sono anche altre varianti.

Ma una cosa che non ho mai visto è che un cliente sia in grado di cambiare il rilascio fino a tardi nel gioco, specialmente non a una settimana dalla pubblicazione. Non sembra giusto mettere i progettisti, gli sviluppatori e i tester sotto questo tipo di pressione. Se stai facendo uno sviluppo iterativo, se si tratta di una funzionalità con priorità alta, assicurati di aggiungerlo al modulo di backlog e prenderlo il prima possibile. Se non è una funzione con priorità alta, sicuramente non ne ha bisogno durante questa versione e può aspettare fino al prossimo.

Raccomando di impostare alcune regole di base che soddisfino i team di progettazione, sviluppo, collaudo e consegna nonché i clienti in merito alla funzionalità di blocco, blocco dei codici e consegne. Mettili per iscritto, prendi l'impegno di tutti e atteniti ad esso. Se ti sposti una volta, dovrai piegarti di più e perderai il controllo del processo.

Unfortunately, there's not much I can do because I'm not in a position of power here.

Potresti non esserlo, da solo. Ma sembra che i tuoi progettisti e / o sviluppatori e / o tester siano sottoposti a molta pressione per rispettare gli orari. Dovresti sederti con i tuoi superiori come una squadra e spiegare la situazione. Innanzitutto, fai in modo che la tua organizzazione si impegni a migliorare il processo, quindi collabora con il cliente per ottenere il suo consenso su come le cose funzioneranno.

This feels a lot like I am making excuses though.

Quando inizi a scusarti, potrebbe essere il momento di fare una Conversazione difficile o un Conversazione cruciale . Consiglierei uno di quei due libri. La loro lettura ha contribuito a migliorare le mie capacità comunicative, soprattutto quando devi affrontare una situazione difficile in cui le tensioni sono alte su tutti i lati.

Per indirizzare alcune delle altre risposte.

Sadly, power is mostly taken by yourself rather than granted to you by others.

Non so dove andrà Andrea con questo. Sì, è necessario correggere il flusso di informazioni. Ma è necessario lavorare con i PM e il cliente per assicurarsi che tutti sappiano cosa è stato (presumo comunque) concordato all'inizio del progetto. Se l'accordo, per qualsiasi motivo, non funziona, rivisitalo e ridistribuisci lavoro e ruoli per le persone più adatte a loro.

Non prendi il potere o combatti il potere, ma lavori con esso, cercando di domarlo e farlo funzionare per tutti.

The problem is - customer mostly know business value for the feature, but don't realize its complexity. Just discuss and clarify. Always.

Questa citazione da loki2302 è praticamente azzeccata . Uno dei tuoi compiti come ingegnere del software è quello di assicurarti che le persone giuste sappiano cose come quanto sia difficile un compito, quanto tempo ci vorrà, e quali tipi di opzioni e rischi esistono nel fare qualcosa. In qualità di comunicatore principale per il tuo team, trasmettere queste informazioni dalla tua organizzazione al tuo cliente è, in teoria, il tuo lavoro.

Trova un forum per avvicinarti a chiunque stia fissando queste scadenze. Fai sapere loro che possono consultarsi con te e presentare qualcosa di più realistico. Le alternative sono: puoi dire al cliente che non succederà o che possono dirlo al cliente.

Puoi presentarlo come puoi farlo in X numero di giorni dopo che la tua squadra ha iniziato a lavorarci. Forse quella era la confusione? È un errore onesto a meno che non accada più e più volte. Quindi è solo negligenza.

Immagino che la tua squadra abbia rispettato queste scadenze in passato.

Sfortunatamente è endemico nel nostro settore, così tante agenzie digitali / software non sanno nulla del funzionamento interno o delle esigenze della loro azienda. Molti si preoccupano solo di denaro contante. Come molti hanno detto prima, se non si forniscono le stime o le scadenze, informare la direzione. Come è possibile consegnare un pezzo tecnico di lavoro x volta senza una stima da parte di una persona tecnica che è a conoscenza del programma del team di sviluppo.

Se tutto il resto fallisce, vattene.

È un buon inizio che stai ricordando al cliente che la tua data di inizio è successiva alla data in cui richiedono la funzione. Devi anche parlare con chiunque parli con il cliente per ottenere dettagli sulla funzione in modo che possano dire al cliente in quel momento quale sarebbe una scadenza migliore. Visto che sei già in comunicazione con il cliente, potresti semplicemente dire "chi è stato nel dipartimento Y che ha accettato questa scadenza?"

Se non ti lasciano entrare nelle trattative o ti dicono di essere tranquillo e prendi le scadenze che accettano, puoi ricordare loro che sarebbe meglio per l'intera azienda se il tuo team era in orario e il modo per ottenere ciò è ottenere il tuo input sulle scadenze.

Fornisci al Project Manager / Boss / Cliente le tue stime e i tuoi orari realizzabili, chiedigli di confermare il tuo piano o risolvi ciò che vuole che lavori prima, poi vai via - non ingaggiarlo o intrattenerlo in alcun modo .
Se torna con un piano di progetto che non riflette le tue stime, restituiscilo a lui, con una dichiarazione: "Non nego le stime". e andare via.

Assicurati di avere un sacco di documentazione CYA. Fai capire a tutti i partecipanti che stai conservando questi documenti. Ho inviato per email tali documenti al mio indirizzo e-mail personale e ho contattato il mio capo, che ha avuto molto successo.

Ecco un approccio che dovrebbe apparire costruttivo anziché puntare il dito. Non ti sto accusando di questo, solo dicendo che non funziona bene per avere una scusa con qualcun altro in colpa indipendentemente dalla verità dell'accusa.

Dopo questo, fai un post mortem per calcolare quanto tempo è effettivamente occorso per completare il progetto, o lo avresti se avessi finito. Calcola quindi quante ore di risorse hai a disposizione dal momento in cui disponi di informazioni sufficienti e il semaforo verde su cui lavorare. Converti questi numeri in quanti programmatori aggiuntivi avrebbe impiegato per rispettare la scadenza.

Ora conversa con il tuo capo seguendo queste linee:

We had X available man hours between project start date Y and deadline Z.
The project required X+C man hours to complete.
There have been similar turnaround requirements on other projects.
We will need Q additional programmers to reach the capacity needed to meet expectations.
...of course, if budgets are tight, maybe we could work with the Project Managers to build more time into their estimates so we can under-promise and over-deliver (be sure to use trite management speak)