Come posso sostenere un programma di rilascio semirigido in un ambiente avverso al rischio?

Recentemente sono stato sempre più afflitto da quella che avrei dovuto descrivere come una delle mie esperienze più frustranti e che uccidono il morale in questa professione: doversi sedere su un rilascio che è stato testato, riprovato, messo in scena e a tutti gli effetti e scopi è pronto per la spedizione / distribuzione .

In quanto ragazzo di soluzioni complete e non solo programmatore hardcore, capisco e ho persino sostenuto la necessità di un adeguato controllo delle modifiche. Ma ultimamente, il tenue equilibrio tra la copertura delle nostre basi e la spedizione in tempo è andato tutto sbilenco, e non ho avuto quasi nessun successo nel ripristinarlo a qualcosa di sano.

Sto cercando argomenti convincenti per aiutare a convincere la gestione avversa al rischio che:

1. Il team di sviluppo dovrebbe (o deve) essere in grado di impostare il proprio programma di rilascio - entro limiti ragionevoli (1-3 mesi dovrebbero essere abbastanza conservativi per tutti tranne le più grandi società Fortune 500);

2. Le versioni del software sono pietre miliari importanti e non devono essere trattate in modo spericolato; in altre parole, ritardi / interruzioni inutili sono altamente distruttivi e dovrebbero essere considerati solo come ultima risorsa per alcuni problemi aziendali critici; e

3. Entità esterne (non sviluppatore / non IT) che desiderano (o esigono) di essere coinvolte poiché le parti interessate hanno la responsabilità di cooperare con il team di sviluppo al fine di rispettare il programma di rilascio, in particolare nell'ultima settimana circa prima della nave pianificata data (es. test / messa in scena dell'utente).

Quanto sopra sono affermazioni che suonano vere per me sulla base dell'esperienza, ma sembra che ora sono nella posizione di doverlo provare - quindi sto chiedendo qualcosa di un po 'più qui, se esiste una cosa del genere.

Qualcuno che ha dovuto "vendere" al management l'idea di un ciclo di rilascio fisso (o forse semi-flessibile) può fornire alcuni suggerimenti su quali argomenti / strategie sono efficaci o persuasivi e cosa no? A parte l'ovvia contesa sulla pianificazione e i costi sommersi, ci sono dati / prove concreti che potrebbero essere utili nel rendere il caso che la spedizione è effettivamente importante, anche in un ambiente "aziendale"?

In alternativa, sono aperto a sentire argomentazioni costruttive sul perché la flessibilità del programma (anche per un periodo di settimane / mesi) è più importante della spedizione nei tempi previsti; è difficile per me credere in questo momento, ma forse sanno qualcosa che io non so.

_{Nota che abbiamo messo in scena le versioni e questo ha attraversato tutte le fasi tranne la produzione. I problemi vengono rilevati utilizzando un bug tracker commerciale e ogni problema - il 100% di essi - assegnato a questa versione è stato chiuso. Mi rendo conto che è difficile da credere e questo è esattamente il punto: non ha senso che una versione al 100%, completa di funzionalità, completamente testata e approvata dagli stakeholder venga ritardata dalla direzione per motivi inspiegabili, ma è quello che è successo, è quello che sta succedendo, questo è il problema da risolvere.}

Joel Spolsky afferma che un team di sviluppo software è uno schema per convertire capitale (denaro) in software funzionante. Onestamente, dalla tua domanda, sembra che il tuo team sia bravo in questo: stai ottenendo un software decente per una ragionevole quantità di denaro investito.

Ora, ovviamente, il prossimo passo è mettere in servizio il software. Fino a quando la tua azienda non decide di farlo, non c'è modo per loro di ottenere un ritorno sul proprio investimento di capitale. Il software seduto sullo scaffale pronto per essere distribuito è un po 'come l'inventario in magazzino: i costi sono affondati, il capitale dell'azienda è già speso. C'è anche un costo opportunità: il tuo gruppo ha scelto di fare questo progetto piuttosto che qualcos'altro.

Inoltre, il valore del software di nuova concezione che si trova sullo scaffale è un po 'come il valore di una cassa di formaggio che si trova nel frigorifero di un ristorante: lentamente marcisce. Il suo valore diminuisce perché i tuoi concorrenti raggiungono. Rifiuta anche perché diventa più difficile e rischioso mettere in servizio il nuovo software man mano che i suoi sviluppatori passano ad altre cose. Dopo un paio d'anni sullo scaffale, in realtà potrebbe essere inutile. In tal caso, la tua azienda ha scelto di scartare il capitale che ha investito nello sviluppo. È possibile che i proprietari dell'azienda - gli azionisti - non siano contenti di questo.

C'è una cosa che tu, come sviluppatore, devi capire. Il tuo software è davvero pronto per essere distribuito alla fine del ciclo di rilascio che stai proponendo? È pronto per partire o c'è ancora molto lavoro da fare e denaro da spendere mentre la tua azienda lo mette in produzione? La tua azienda possiede i server e le licenze software necessarie per implementare il tuo software? Il tuo prodotto di lavoro include un piano di implementazione? Gli utenti finali sono stati formati? I dati di produzione sono stati convertiti? Se il tuo nuovo software comporta un cambiamento nel modo in cui la tua azienda fa affari, è l'azienda pronta a fare quel cambiamento? Hai elaborato uno schema per eseguire le cose in parallelo, per assicurarti che le nuove cose funzionino così come quelle vecchie?

Tutti questi costi di implementazione possono facilmente ridurre il costo dello sviluppo del software. Un saggio team di gestione del progetto fa del suo meglio per pianificare, pianificare e pianificare tutta quella roba. Hai fatto quel lavoro? Hai reso chiaro al management? Altrimenti, è possibile che siano saggi andare lenti sui tuoi lanci.

È possibile che un programma di distribuzione del software agile moderno non sia sincronizzato con il ritmo del cambiamento che il resto della tua azienda si aspetta. I vostri utenti finali - i vostri stakeholder - potrebbero semplicemente non essere in grado di assorbire il cambiamento alla velocità con cui il vostro team può produrlo.

È anche possibile che il tuo team di gestione sia disfunzionale. Il tuo team ha sviluppato qualcosa che il resto dell'azienda non vuole? Le tue nuove cose minacciano il tuo team di vendita o produzione? In tal caso, alcuni dirigenti potrebbero essere siluri dicendo che è troppo rischioso per essere lanciato. Non c'è niente che tu possa fare al riguardo a meno che tu non sia il CEO.

Hai chiesto argomenti convincenti per l'implementazione tempestiva del software. C'è un argomento davvero convincente: ritorno sull'investimento. La società ha scelto di investire in questo software e ora stanno scegliendo di sprecare l'investimento mentre il software lentamente marcisce sugli scaffali.

Un argomento secondario per lanci tempestivi è il morale della tua squadra. Sbrigarsi non è un buon modo per motivare gli sviluppatori creativi a fare un buon lavoro. Potresti perdere la tua squadra se non ottengono la soddisfazione di vedere il loro lavoro andare in servizio.

Innanzitutto, guarda questo video:

http://the99percent.com/videos/5822/Seth-Godin-Quieting-the-Lizard-Brain

Sintesi:

Il modo in cui spedisci in tempo e con il budget è questo: quando esaurisci il tempo o esaurisci il denaro, spedisci. Questo è tutto.

Il motivo per cui la maggior parte dei progetti non viene spedito in tempo è perché qualcuno arriva con "solo un'altra funzionalità o correzione" da inserire nel rilascio, proprio prima che tu sia pronto per la spedizione, in un momento nel ciclo di sviluppo in cui le risorse sono molto scarso, e ora devi arrampicarti. Questo si chiama thrashing e succede perché finché non spedisci, non devi preoccuparti che le persone ti dicano che il tuo prodotto fa schifo.

Il modo in cui curare il thrashing è costringere le persone a farlo all'inizio del ciclo di sviluppo del prodotto , non alla fine.

Apportare modifiche al prodotto nelle settimane immediatamente precedenti la data di rilascio è molto dirompente, per ovvie ragioni. Questo è vero se la modifica è una nuova funzionalità, una modifica al processo di sviluppo del software o un tentativo di correggere un bug di vecchia data che non è nel programma di sviluppo.

Quando qualcuno viene da me per una correzione o una modifica in ritardo nel ciclo di sviluppo, chiedo sempre questo: "Cosa vuoi che non venga fatto in modo da poter fare le tue cose?"

Se hai bisogno di un motivatore di denaro, è questo: gli studi dimostrano che più tardi attendi nel ciclo di vita del software per implementare una funzionalità o correzione, più è costoso. In modo esponenziale. Non è difficile dimostrarlo.

Hai descritto chiaramente i problemi che stai affrontando, tuttavia cosa non sono chiaro sul perché i gestori si comportino in questo modo. Puoi chiarire? Ad esempio, ritieni che sia pronto per essere distribuito, qualcuno non è d'accordo, in caso affermativo chi e perché? Sono ex beaurocrati governativi

Questo suona molto come un problema di allineamento tra capacità e desiderio, hai il desiderio di rilasciare, ma non la capacità (autorità), quelli con l'autorità non hanno il desiderio.

Devi scoprire perché non hanno il desiderio - è una ragione di marketing (conservala per un altro anno mentre mungiamo la versione precedente per un po 'di più), è paura / fiducia (se ha bug, ci farà sembrare cattivi , ci costano soldi ...., mancanza di risorse (non possono permettersi i costi di spedizione / imballaggio / roba PR), è commerciale dove i tuoi oscuri affondano a scarsi profitti in eccesso e non vogliono che tu faccia soldi ( Non così sciocco come sembra).

Ho anche il sospetto che ci sia un po 'di rispetto tra le parti coinvolte, quindi non si stanno verificando discussioni ragionevoli con gli adulti.

Siamo spiacenti, non è la risposta specifica che hai chiesto, si spera un paio di cose a cui pensare però.

La prima cosa da considerare è assicurarsi che le tue versioni non siano ad alto rischio .

Idealmente, le tue richieste di modifica dovrebbero avere una sezione chiamata come Mitigazione del rischio , contenente istruzioni su come tornare alla versione precedente se le cose vanno male. Dal punto di vista del rischio, nessuna quantità di test precedenti può sostituire una semplice opzione per il rollback della modifica.

• ^{In un ambiente avverso al rischio, non riesco a immaginare un modo per rendere indolori i cambiamenti irreversibili .
  Se molte / la maggior parte delle tue versioni rientrano in questa categoria, potresti voler riconsiderare la tua architettura.}

Il rischio di NON rilasciare deve essere esposto, se si desidera che il programma del team di sviluppo venga trattato seriamente.

Se le tue versioni forniscono correzioni per problemi di produzione / supporto e interruzioni, questo è abbastanza facile da fare semplicemente elencandole e sottolineando che la produzione è a rischio di ripeterle a meno che non sia aggiornata.

Una misura davvero efficace a disposizione del team di sviluppo per combattere il rilascio lo fa scivolare per assicurarsi che il rischio di non rilasciare aumenti nel tempo . Ciò può essere ottenuto con versioni interne in esecuzione a programma fisso, fornendo un elenco "cumulativo" di soluzioni ai problemi di produzione.

• In parole povere, i ragazzi che bloccano il tuo rilascio XXdevono essere consapevoli non solo che corrono il rischio di avere Nproblemi di produzione per rimanere irrisolti, ma anche quella settimana (o mese) dopo, avranno il rilascio XX+1nella loro coda di approvazione, bloccando che comportare il rischio che N+Mtipi di problemi di produzione rimangano irrisolti, e che ciò accadrà anche con XX+2ulteriori rilasci "interni" forniti dal team di sviluppo.

Il modo sopra descritto rende sostanzialmente più stretta ed esplicita la connessione tra gli aggiornamenti dell'applicazione e i problemi di produzione.

Per questo motivo, potresti aspettarti un maggiore coinvolgimento nelle escalation dei problemi di produzione . Puoi utilizzarli come opportunità per promuovere la tua visione di aggiornamenti programmati più severi. Puoi anche innescare alcune escalation per accelerare il processo di adozione dell'approccio desiderato.

• ^{"... consiglia di considerare di aggiornare l'applicazione alla versione più recente ( XXo successiva). Quella che è attualmente distribuita nel tuo ambiente ( XX-2) è gravemente obsoleta - due importanti versioni dietro l'attuale base di codice. Di conseguenza, i dettagli per tali semplici errori sono profondamente nascosto nei registri e immondizia indecifrabile viene segnalato dall'applicazione ai client invece di chiare descrizioni degli errori, causando agli utenti e al supporto la perdita di tempo nell'indagare su problemi che sono davvero abbastanza semplici "
   
  Sopra un commento che ho aggiunto qualche tempo fa nel tracker dei problemi di supporto per il ticket in relazione a un particolare incidente di produzione. Poco dopo, gli "stakeholder" hanno contattato il team di sviluppo chiedendo come tenere traccia delle nostre versioni e come possono aiutare a implementare il proprio ambiente. Oh, e anche rapidamente aggiornati daXX-2anche la versione. :)}

Quando si verifica l'escalation della produzione, è meglio essere pronti a presentare la propria visione in modo rapido e chiaro.

Una cosa che troverai utile è scegliere e rintracciare chi è responsabile di un particolare slippage di rilascio. Fondamentalmente, devi essere in grado di rispondere rapidamente e chiaramente a domande del tipo "chi ha la responsabilità del fatto che il rilascio pianificato non è avvenuto?" Se non sei pronto, possono scegliere il percorso di minor resistenza e dare la colpa a te. Come sottolineato nei commenti a un'altra risposta , "Potresti metterti in acqua calda da cui la tua direzione sta cercando di proteggerti."

L'ultimo ma non meno importante,

ci vorrà del tempo

(probabilmente lo sai già ma sembra che valga la pena dichiararlo esplicitamente)

Ciò che cerchi può essere descritto come cambiamento di atteggiamento, da "è rischioso rilasciare " a "è rischioso NON rilasciarlo ". I cambiamenti di atteggiamento raramente si verificano durante la notte, potrebbe essere necessaria la pazienza per completare il turno.

C'è un grande punto interrogativo sospeso sopra la tua domanda, ed è per questo che la tua azienda non desidera rilasciare il software. Non è sempre solo un semplice caso di avversione al rischio. Spesso ci sono altre cause sottostanti che spesso non vengono tramandate dalle altezze manageriali elevate. Quindi la mia domanda è: "Ti sei seduto con il tuo capo e gli hai chiesto perché la versione del prodotto è stata trattenuta?".

C'è una grande differenza tra gestire il rischio ed evitarlo. Potrebbero esserci motivi legali o di marketing per ritardare il rilascio di un prodotto. Potrebbe trattarsi di problemi di fiducia tra il management e il team di sviluppo. Il prodotto potrebbe non soddisfare le esigenze del cliente, anche se è esattamente ciò che il cliente ha chiesto mesi fa. Potrebbe anche essere un caso di qualcuno nella gestione che copre seriamente il culo mentre cerca di spostare la colpa per un ritardo altrove, o addirittura un ritardo da parte di terzi che è necessario per completare qualcosa prima che il prodotto venga spedito. Potrei inventare decine di scenari. Abbastanza spesso lo sviluppatore assume l'avversione al rischio senza capire l'altro lato dell'equazione che non è stato reso evidente. D'altro canto, potrebbe essere semplicemente compiacenza, conflitto tra persone all'interno di un'azienda,

In tutti i casi, è importante disporre di ulteriori informazioni sui motivi dei ritardi nel rilascio del prodotto e di utilizzare tali informazioni per creare un caso di rilascio del prodotto non appena possibile. Sì, può essere molto frustrante, ma ci sono altri modi per affrontare queste situazioni senza rischiare il confronto con i tuoi capi o un esaurimento. In situazioni simili, io stesso ho raccolto informazioni, documentato qualsiasi progresso avessi fatto e, se il peggio fosse peggiorato, ho semplicemente accantonato il progetto e sono passato a qualcos'altro. Laddove sono stato in grado di riportare in pista un progetto per il rilascio, di solito è stato il risultato della creazione di un valido caso commerciale basato sulle informazioni che ho ricevuto come feedback alle domande che ho sollevato. Laddove non sono stato in grado di convincere la direzione che il prodotto deve essere spedito, Ho documentato la riluttanza a spedire semplicemente come un caso di progetto finito e in attesa dell'approvazione del rilascio da parte della direzione. Mi assicuro quindi che il mio manager firmi il mio documento come accettato e compreso dalla direzione in modo che il mio culo sia coperto se dovessero tentare di incolpare me in seguito per un non-rilascio.

Hai sempre bisogno di punteggiare i tuoi I e attraversare le T per evitare che i ritardi di spedizione vengano successivamente biasimati su di te (non importa quanto ingiustamente), ed è anche importante evitare di diventare troppo emotivamente legati a tali problemi a meno che non ti piaccia l'idea di un'ulcera ben guadagnata. Osservando la propria situazione con un certo distacco professionale, è possibile che si presenti una soluzione perché ci si è effettivamente posizionati a una "distanza" maggiore, com'era dal problema. Se non riesci a presentare il tuo caso, potrebbe essere necessario lasciarlo scorrere per un po ', ma per rendere il tuo caso in primo luogo, devi sembrare distaccato professionalmente e avere argomenti basati su informazioni intimamente connesse la tua azienda e i suoi meccanismi interni.

Qualcos'altro a cui ho appena pensato, che potrebbe esserti di aiuto, è forse leggere Lean Software Development e vedere se c'è qualcosa di prezioso che potrebbe riguardare la situazione della tua azienda, in particolare nei primi capitoli. Penso che sia stato il capitolo 4 che discute della questione della consegna il più rapidamente possibile e ha qualcosa relativo ai costi di ritardo.

Direi che il modo più semplice / efficace per vendere un rilascio è quello di scaricare gli strumenti per un po 'quando è pronto per l'uso. Fai qualcos'altro, avvia un nuovo progetto, lavora sui bug per il progetto esistente. Non fare altro per questo fino a quando non viene inviato fuori dalla porta - dopo tutto, perché preoccuparsi di farlo se non va quando è pronto.

ma nel mondo reale, la versione attuale è un problema di qualcun altro, dovresti spedirla a loro e trattarla come una versione. Una volta uscito di casa, è stato spedito. Se siedono semplicemente su di esso, non è un tuo problema (in effetti, è fantastico, nessun bug viene segnalato su di esso! W00t! Bonus per una versione senza bug a tutto tondo;))

Quindi è comunque necessario un sistema di controllo delle modifiche e un gestore delle versioni. Quindi è tutto semplice (tranne che è necessario gestire il controllo delle modifiche, quindi il controllo del codice sorgente e le build di distribuzione sono molto necessarie. Richiede organizzazione, ma se sei organizzato, è facile).

Non riesco a immaginare che affidare il team Dev al business come descrivi sia una "buona cosa". Potrebbe mascherare il vero problema, ma a meno che il team Dev non sia nella posizione giusta per valutare gli input delle vendite, del marketing ecc. ecc. si rischia di rilasciare per motivi errati (e potenzialmente negativi).

Se capisco il tuo problema, hai completato il progetto e hai un prodotto che non puoi mostrare a nessuno al di fuori della tua azienda. (Spero che questo lo riassuma, ho letto l'intero thread e sto avendo problemi a metterci il dito sopra)

Hai provato:

1. Chiedere alla direzione di un cliente o un insieme di clienti di agire come parti interessate durante lo sviluppo? Di solito è possibile trovare un cliente che accetta rilasci intermedi e fornisce feedback. Possono essere grandi sostenitori quando è il momento di rilasciare. Anche una "versione limitata" per un cliente potrebbe essere sufficiente per aiutare a influenzare la gestione
2. Creazione di un piano di rilascio che include rilasci puntuali. Cioè, è possibile rilasciare 3.4 oggi perché la versione 3.4.1 è prevista per oggi + 1 mese. Questo insieme alla buona idea che hai già menzionato che una cadenza di rilascio aiuta questo messaggio.
3. Ottieni supporto, vendite o marketing dalla tua parte. Costruisci le correzioni che risolvono le 3 principali richieste di supporto e puoi ottenere un alleato da un altro dipartimento. Se non riesci a ottenere un stakeholder del cliente come nel n. 1, provalo con alcuni addetti alle vendite. Offri di essere disponibile per riunioni di vendita e portare con te il prodotto. Quando sei in viaggio, mostra all'addetto alle vendite che sei con il prodotto (in qualunque stato si trovi) falli tirare per te.

Per rispondere alla tua altra domanda sul "perché la gestione dovrebbe stare su una versione?" Le aziende lo fanno sempre in campi non SW e non credo che sia senza precedenti. Ad esempio, hai una nuova versione pronta all'uso, tutta testata e fatta. Ma la vecchia versione non è stata ancora sostituita dalla concorrenza. Una volta che la concorrenza rilascia un prodotto concorrente nella versione precedente, la direzione rilascia la versione in attesa sugli scaffali e sconvolge il mercato, arretrando la concorrenza e mantenendo le vendite e la reputazione di leader di mercato. Rilasciare troppo presto punta la mano ai concorrenti che potrebbero avere un'idea migliore della tua tabella di marcia e provare a batterti fino alla fine del gioco.

Con tutto ciò che ha detto ... Hanlon's Razor è probabilmente la risposta giusta :-)

Allontanati da quella compagnia, non capiscono il software. Ma seriamente, il software è ciò che fa funzionare il sistema, immagina se stavi costruendo auto, le fabbriche di auto sono lente? aspettano il rilascio di auto? Sono incrementali e burocratici? No, provano a fare le cose nel modo più veloce e pulito possibile. Hai un problema di gestione e dovresti lavorarci su come un conflitto di gestione, prova a parlarne nei termini. Chiedi cosa significa il rischio per loro, quindi cerca di minimizzarlo. Anche i sentimenti dei tuoi sviluppatori sono importanti, poiché devono far fronte alle decisioni che saranno prese dal tuo intervento. Saranno felici facendo tutti i night per spedire in tempo? Quali sarebbero i premi / penalità? Ecc. Ora ti darò un approccio pratico a questo problema, un po 'estremo, ma chiederò un audit.