Stabilire aspettative realistiche per le scadenze


15

Sono un capo tecnologico per una piccola squadra. Uno dei compiti principali sul mio piatto è la comunicazione con il cliente. Una cosa che trovo particolarmente difficile è gestire le scadenze perché sono obbligate dal cliente e spesso non sono consultato.

Di solito, l'interazione segue il seguente schema. Il client presenta una funzionalità che desidera aggiungere, la funzione X. La funzione X apparirebbe bene nella versione dell'app della prossima settimana che è di circa 6 giorni lavorativi. A questo punto, la richiesta di funzionalità deve essere approvata e spesso ci sono altre dipendenze che devono essere gestite. Alla fine, N giorni dopo, la richiesta di funzionalità arriva alla mia squadra. Anche se la scadenza originale (stabilita da un gestore non sviluppatore) era raggiungibile, non lo è più. La mia squadra è incolpata, si sente scoraggiata e c'è un'atmosfera generale di sconfitta , mi sento scoraggiata e sconfitta.

Chiaramente l'intero processo è interrotto. Sfortunatamente, non c'è molto che posso fare perché non sono in una posizione di potere qui. Il mio approccio attuale è di ricordare delicatamente al cliente la nostra data di inizio rispetto alla scadenza, alla portata della Funzione, ecc. Mi sembra molto come se stessi inventando delle scuse.

Siete stati in situazioni simili? Cosa ha funzionato / non ha funzionato per te?


13
Partire. Non puoi vincere. Il tuo management non ti protegge, quindi a loro non importa di te. Partire.
Christopher Mahan,

4
"Mi sembra molto come se stessi inventando delle scuse". Perché? I fatti sono fatti. Cosa stai "scusando"?
S.Lott

Non lavoriamo in una blackbox. Quando il team è disfunzionale, c'è solo molto che uno sviluppatore modesto impotente può fare.
P.Brian.Mackey,

2
@EightyEight: la tecnica "line-out" non chiarisce nulla. O tu o la squadra (o forse entrambi). Ma un line-out non aiuta chiunque a capire che cosa il vostro domanda è . Va bene rimuovere cose che non sono vere o non rilevanti.
S.Lott

Risposte:


13

Devi davvero parlarne con il tuo capo e impostare alcune regole di base:

  • Una scadenza non è una scadenza a meno che tu non ti impegni.
  • Una stima non è una stima a meno che non venga fornita, quindi è una "stima" non una scadenza rigida.

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

Quando ottieni una nuova funzionalità, la stimi e usi PERT in modo da avere una distribuzione di probabilità. "Dovrei farlo in 4 giorni, ma potrebbero essere necessari fino a 8". Sopportare la tua terra. MAI negoziare un preventivo con un venditore, finirai per impegnarti nell'impossibile.

Dopo alcune iterazioni, il venditore si spera che sia stufo di sembrare sciocco e adeguerà il comportamento a "Verificherò con il team di sviluppo e vedrò quando potremo farlo" piuttosto che una promessa che tu finisca rompersi.


1
+1 - sviluppatori / persone che sanno cosa è effettivamente coinvolto non essere coinvolto nelle stime urla pazzo pazzo pazzo: /
elwyn

2
"... una promessa che finirai per rompere." - Non dimenticare mai e ricorda regolarmente alle persone che non puoi mantenere una promessa che non fai, compresi quelli fatti per tuo conto.
Mattnz,

"Una scadenza non è una scadenza a meno che tu non ti impegni." Mi è piaciuto così tanto che l'ho solo twittato. ;)
Bob Horn,

10

Siete stati in situazioni simili? Cosa ha funzionato / non ha funzionato per te?

Principalmente ciò che funziona è dire la verità al potere.

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

La mia squadra è incolpata, si sente scoraggiata e c'è un'atmosfera generale di sconfitta.

Perché la tua squadra è consapevole della colpa? Se il cliente ti sta bypassando e sta parlando direttamente con il team, stai diventando inefficace e devi capire perché.

La tua squadra dovrebbe ignorare la "colpa" o la mancanza di colpa. 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 molta ripetizione per rompere le cattive abitudini. Molto.


+1 "dire la verità al potere". Puoi chiarire per favore? Mi piace la frase "ignorante di" colpa ". Vorrei poter trovare una compagnia che fermasse tutto il dito insensato che puntava.
P.Brian.Mackey,

"Raccogli i fatti. Presenta i fatti". Ho pensato che fosse chiaro. Cosa si può dire di più?
S.Lott

Penso di averlo capito adesso. Non ho mai sentito quel termine prima.
P.Brian.Mackey,

3
"fermato tutto il dito insensato che punta". Non può essere fermato. Ma il ruolo di un caposquadra è quello di proteggere la squadra dal peggio.
S.Lott

Il cliente non parla direttamente con i membri del mio team, ma l'insoddisfazione per il proprio lavoro tende a filtrare, qualunque cosa accada. Forse dovrei sostituire "I" con la "squadra". Sembra che io sia sulla strada giusta. Grazie per i tuoi commenti
Ottanta,

5

Sono stato in questa situazione esatta e non è stato piacevole. Tuttavia, un approccio che ho seguito è stato quello di tenere meticolosamente un registro dei lavori attualmente in fase di sviluppo. Quando le attività si presentano, ricordi al cliente, al management o al project manager che altri lavori scivoleranno perché questa è diventata la loro priorità (a volte ciò può farli indovinare e poi continuare a spingere per allungare la scadenza).

Altrimenti, immagino che tu debba provare a continuare a martellare quel cesello nel muro di pietra che è il project manager / cliente / gestione / venditore che si occupa del cliente e accetta queste scadenze. Ho spesso martellato il fatto che se sono d'accordo che ci vorranno 5 giorni per fare qualcosa, ovviamente stanno parlando di 5 giorni di sviluppo, il che significa che ci vogliono 5 giorni da quando lo ricevi (non quando riagganciano il telefono insieme e poi trascorrono i prossimi due giorni redigendo una parola elaborata doc).

Tuttavia, poiché tu sei il responsabile dello sviluppo, qualsiasi decisione come questa è irrilevante se non consultata con te in primo luogo.

Devi anche cercare di proteggere il tuo team da questo il più possibile. Sebbene sia difficile, devono essere tenuti fuori dalle politiche del cliente / di gestione il più possibile. In caso contrario, è necessario un martellamento maggiore.

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


3

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

Il problema è che il cliente conosce principalmente il valore commerciale per la funzionalità, ma non si rende conto della sua complessità. Discutere e chiarire. Sempre.


Non accettare mai una scadenza "... entro lunedì". Ciò significa solo che gli sviluppatori passeranno il fine settimana codificando se la merda colpisce il fan. Usa venerdì come scadenza o, meglio ancora, mercoledì.
sabato

2

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

Se non ti lasciano entrare nei colloqui o ti dicono di tacere e di rispettare le scadenze concordate, puoi ricordare loro che sarebbe meglio per l'intera azienda se la tua squadra fosse puntuale, e il modo in cui per ottenere questo è ottenere il tuo contributo alle scadenze.


2

Correggi il flusso di informazioni.

  • Se devi comunicare con il cliente, imponi a tutte le parti interessate del progetto (incluso il cliente) di interfacciarsi direttamente con te, sempre .

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


1
Sì, come se succedesse. Anche se, se lo facessi, probabilmente verrai licenziato e guadagnerai un sacco di rispetto da alcune delle persone con cui lavori e da alcuni dei clienti (che probabilmente sono anche stanchi della gestione della tua azienda).
Christopher Mahan,

2

Uno dei compiti principali sul mio piatto è la comunicazione con il cliente. Una cosa che trovo particolarmente difficile è gestire le scadenze perché sono obbligate dal cliente e spesso non sono consultato.

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 all'interno della tua organizzazione e le loro controparti a fianco del cliente? Penso che risolvere questo problema sarà un enorme vantaggio per te, il tuo team e il tuo progetto.

Il cliente presenta una funzione che desidera aggiungere, la funzione X. La funzione X sarebbe bella nella prossima versione dell'app che è di circa 6 giorni lavorativi. A questo punto, la richiesta di funzionalità deve essere approvata e spesso ci sono altre dipendenze che devono essere gestite. Alla fine, N giorni dopo, la richiesta di funzionalità arriva alla mia squadra. Anche se la scadenza originale (stabilita da un gestore non sviluppatore) era raggiungibile, non lo è più.

Questo sistema per la pianificazione sembra strano, per non dire altro.

Nelle mie esperienze, il cliente accede per una versione particolare. Potrebbero inviare un elenco di funzionalità e modifiche che desiderano e quando le desiderano, quindi negoziare con il team che sviluppa il software. Oppure potrebbero fornire un elenco prioritario di funzionalità al team di sviluppo e il team di sviluppo fornisce stime su quando possono spedire vari set di funzionalità. Ci sono anche altre varianti.

Ma una cosa che non ho mai visto è consentita è che un cliente è in grado di modificare il rilascio così tardi nel gioco, soprattutto a una settimana di distanza dal rilascio. Non sembra giusto mettere i progettisti, gli sviluppatori e i tester sotto quel tipo di pressione. Se stai eseguendo uno sviluppo iterativo, se si tratta di una funzionalità ad alta priorità, assicurati di aggiungerlo alla forma di backlog e prenderlo il più presto possibile. Se non è una funzionalità ad alta priorità, sicuramente non ne hanno bisogno durante questa versione e possono aspettare fino alla prossima.

Consiglierei di impostare alcune regole di base che soddisfino i vostri team di progettazione, sviluppo, test e consegna, nonché i vostri clienti in merito a blocchi, blocchi di codice e consegne. Metti questi per iscritto, ottieni impegno da tutti e mantienilo. Se ti muovi una volta, dovresti piegarti di più e perderai il controllo del processo.

Sfortunatamente, non c'è molto che posso fare perché non sono in una posizione di potere qui.

Potresti non essere, da solo. Ma sembra che i vostri progettisti e / o sviluppatori e / o tester abbiano molta pressione per rispettare i programmi. Dovresti sederti con i tuoi superiori come una squadra e spiegare la situazione. Per prima cosa, 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 funzioneranno le cose.

Mi sembra un po 'come se stessi inventando delle scuse.

Quando inizi a trovare delle scuse, potrebbe essere il momento di avere una conversazione difficile o una conversazione cruciale . Consiglierei uno di quei due libri. La loro lettura mi ha aiutato a migliorare le mie capacità comunicative, soprattutto quando devi affrontare una situazione difficile in cui le tensioni sono elevate da tutti i lati.


Per rispondere ad alcune delle altre risposte.

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

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

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

Il problema è che il cliente conosce principalmente il valore commerciale per la funzionalità, ma non si rende conto della sua complessità. Discutere e chiarire. Sempre.

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


2

Trova un forum per avvicinare chiunque stabilisca queste scadenze. Fai sapere loro che possono consultare te e presentare qualcosa di più realistico. Le alternative sono: puoi dire al cliente che non accadrà o possono dirlo al cliente.

Puoi presentarlo come puoi farlo in X numero di giorni una volta che il tuo team ha iniziato a lavorarci. Forse quella era la confusione? È un errore onesto a meno che non accada più e più volte. Quindi è solo abbandono.

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


2

Purtroppo è endemico nel nostro settore, quindi molte agenzie digitali / software non sanno nulla del funzionamento interno o dei requisiti della loro azienda. Molti si occupano solo di contanti veloci. Come molti hanno già detto se non si forniscono stime o scadenze, informarne la direzione. Come è possibile fornire un lavoro tecnico entro il tempo x senza una stima da una persona tecnica che è a conoscenza del programma del team di sviluppo.

Se tutto il resto fallisce, vattene.


1

Fornisci al Project Manager / Boss / Client le stime e i programmi realizzabili, chiedigli di confermare il tuo piano o di capire su cosa vuole che tu lavori prima, poi vai via - non coinvolgerlo o intrattenerlo in alcun modo.
Se torna con un piano di progetto che non riflette le tue stime, rispondi a lui, con una dichiarazione, "Non negoziare le stime". e vai via.

Assicurati di avere molta documentazione del CYA. Rendi chiaro a tutti i soggetti coinvolti che stai conservando questi documenti. Ho inviato per e-mail tali record al mio indirizzo e-mail personale e CC'd il mio capo, che ha avuto molto successo.


1

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

Dopo che ciò accade, esegui un post mortem per calcolare il tempo effettivamente impiegato per completare il progetto o se lo avessi completato. Quindi calcola quante ore di risorse hai avuto da quando hai avuto abbastanza informazioni e il via libera per lavorarci su. Converti questi numeri in quanti programmatori aggiuntivi ci sarebbero voluti per rispettare la scadenza.

Adesso parla con il tuo capo in questo modo:

Avevamo X ore uomo disponibili tra la data di inizio del progetto Y e la scadenza Z.
Il progetto richiedeva ore uomo X + C per il completamento.
Vi sono stati requisiti di inversione simili per altri progetti.
Avremo bisogno di ulteriori programmatori Q per raggiungere la capacità necessaria per soddisfare le aspettative.
... ovviamente, se i budget sono limitati, forse potremmo collaborare con i Project Manager per aumentare il tempo nelle loro stime in modo da poter promettere poco e consegnare troppo (assicurati di usare la gestione della trite)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.