Come posso sostenere un programma di rilascio semi-rigoroso in un ambiente avverso al rischio?

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

Ora, naturalmente, il prossimo passo è mettere il software in servizio. Fino a quando la tua azienda non sceglie di farlo, non c'è modo per loro di ottenere un rendimento dal loro investimento di capitale. Il software seduto sullo scaffale pronto per la distribuzione è un po 'come l'inventario nel magazzino: i costi sono affondati, i soldi del capitale dell'azienda sono già spesi. 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 seduto sullo scaffale è un po 'come il valore di una cassa di formaggio seduto nel frigo di un ristorante: lentamente marcisce. Il suo valore diminuisce perché i concorrenti raggiungono. Inoltre, diminuisce perché diventa sempre più difficile mettere in servizio un nuovo software mentre i suoi sviluppatori passano ad altro. Dopo un paio di anni sullo scaffale, potrebbe essere davvero inutile. In tal caso, la tua azienda ha scelto di scartare il capitale investito per svilupparlo. È possibile che i proprietari dell'azienda - gli azionisti - siano contrariati per questo.

C'è una cosa che tu, come sviluppatore, devi capire. Il tuo software è davvero, veramente, pronto per essere distribuito alla fine del ciclo di rilascio che stai proponendo? È pronto per andare, o c'è ancora un sacco di lavoro da fare e soldi da spendere mentre la tua azienda lo mette in produzione? La tua azienda possiede i server e le licenze software necessari per implementare il tuo software? Il tuo prodotto di lavoro include un piano di implementazione? Gli utenti finali sono stati addestrati? I dati di produzione sono stati convertiti? Se il tuo nuovo software comporta un cambiamento nel modo in cui la tua azienda opera, la società è pronta a fare quel cambiamento? Hai elaborato uno schema per far funzionare le cose in parallelo, per assicurarti che le nuove cose funzionino bene come le vecchie cose?

Tutti questi costi di rollout possono facilmente far sminuire il costo dello sviluppo del software. Un team di project management saggio fa del suo meglio per pianificare, pianificare e pianificare tutte queste cose. Hai fatto quel lavoro? Lo hai messo in chiaro alla direzione? In caso contrario, è possibile che sia saggio rallentare il lancio.

È possibile che un programma di implementazione software moderno e flessibile non sia sincronizzato con il ritmo di cambiamento che il resto della tua azienda si aspetta. I tuoi utenti finali - i tuoi stakeholder - potrebbero non essere in grado di assorbire i cambiamenti al ritmo con cui la tua squadra può produrli.

È anche possibile che il tuo team di gestione sia disfunzionale. La tua squadra ha sviluppato qualcosa che il resto della compagnia non vuole? Le tue nuove cose minacciano il tuo team di vendita o di produzione? Se è così, alcuni dirigenti potrebbero ammazzarlo dicendo che è troppo rischioso per uscire. Non c'è niente che puoi fare a meno che tu non sia il CEO.

Hai chiesto argomenti convincenti per l'implementazione tempestiva del software. C'è un argomento davvero convincente: il ritorno sull'investimento. La società ha scelto di investire in questo software, e ora sta scegliendo di sprecare l'investimento mentre il software si sposta lentamente sullo scaffale.

Un argomento secondario per implementazioni tempestive è il morale della tua squadra. Hurry-up-and-wait non è un buon modo per motivare gli sviluppatori creativi a fare un buon lavoro. Potresti perdere la tua squadra se non ottiene la soddisfazione di vedere il loro lavoro andare in servizio.

Per prima cosa guarda questo video:

link

Riepilogo esecutivo:

The way you ship on time and on budget is this: when you run out of time or run out of money, you ship. That's it.

The reason most projects don't ship on time is because someone comes along with "just one more feature or fix" to insert into the release, right before you're ready to ship, at a time in the development cycle when your resources are most scarce, and now you have to scramble. This is called thrashing, and it happens because as long as you don't ship, you don't have to worry about people telling you your product sucks.

The way you cure thrashing is by forcing people to do it at the beginning of the product development cycle, not at the end.

Apportare modifiche ai prodotti nelle settimane precedenti la data di rilascio è molto dirompente, per ovvi motivi. Questo è vero se la modifica è una nuova funzionalità, una modifica al processo di sviluppo del software o un tentativo di correggere un errore di vecchia data che non è incluso nella pianificazione dello sviluppo.

Quando qualcuno viene da me per una correzione o cambia in ritardo nel ciclo di sviluppo, gli chiedo sempre questo: "Che cosa vuoi che non venga fatto in modo che io possa fare il tuo lavoro?"

Se hai bisogno di un motivatore di soldi, è questo: gli studi dimostrano che più tardi attendi nel ciclo di vita del software per implementare una funzionalità o una soluzione, più è costoso. Esponenziale. Non è difficile provarlo.

Hai chiaramente descritto i problemi che stai affrontando, ma non so in che modo i gestori si comportano in questo modo. Puoi chiarire? Ad esempio, ritieni che sia pronto per la distribuzione, qualcuno non è d'accordo, in tal caso, chi e perché? Sono ex governanti beaurocrati

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

Hai bisogno di scoprire perché manca il desiderio - è la ragione del marketing (mantienila per un altro anno mentre noi mungiamo la vecchia versione per un po 'di più), è paura / fiducia (se ha dei bug, farà noi ci guardiamo male, ci costano soldi ...., mancanza di risorse (non può permettersi il costo di spedizione / imballaggio / roba PR), è commerciale dove i tuoi oscuri affondano a profitti in eccesso poveri e non ti vogliono fare soldi (non è così sciocco come sembra).

Sospetto anche che ci sia un minimo di rispetto tra le parti coinvolte, pertanto non si verificano discussioni ragionevoli per adulti.

Scusa - non la risposta specifica che hai chiesto, magari un paio di cose a cui pensare.

Per prima cosa, assicurati che le tue pubblicazioni non siano ad alto rischio .

Idealmente, le tue richieste di modifica dovrebbero avere una sezione chiamata Mitigazione del rischio , contenente istruzioni su come eseguire il rollback alla versione precedente se le cose vanno male. Per quanto riguarda il rischio, nessun test preliminare può sostituire una semplice opzione per il rollback del cambiamento.

• ^{In un ambiente avverso al rischio, non riesco a immaginare un modo per rendere indolori irreversibili . Se molti / molti dei tuoi rilasci rientrano in questa categoria, potresti voler riconsiderare la tua architettura.}

Il rischio di NON rilascio deve essere esposto, se vuoi che la pianificazione del team di sviluppo venga trattata seriamente.

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

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

• In parole povere, i ragazzi che bloccano il tuo rilascio XX devono essere consapevoli non solo che corrono il rischio di avere N tipi di problemi di produzione per rimanere irrisolti, ma anche quella settimana (o mese) più tardi, avranno rilascia XX+1 nella loro coda di approvazione, il blocco che incorrerà nel rischio di N+M i tipi di problemi di produzione rimangono irrisolti - e questo sarà anche il caso con XX+2 e ulteriori release "interni" forniti dal team di sviluppo.

La modalità sopra descritta rende essenzialmente più stretta e più 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 . È possibile utilizzarli come opportunità per promuovere la visione di aggiornamenti programmati più rigidi. Potresti addirittura attivare alcune escalation per accelerare il processo di adozione del tuo approccio desiderato.

• <sup>"... consiglia di considerare l'aggiornamento dell'applicazione alla versione più recente ( XX o successivo). Quello attualmente distribuito nel tuo ambiente ( XX-2 ) è severamente obsoleto - due versioni principali Dietro l'attuale base di codice, i dettagli di tali semplici errori sono profondamente nascosti nei registri e l'immondizia indecifrabile viene segnalata dall'applicazione ai client invece delle descrizioni chiare degli errori, il che fa sì che gli utenti e il supporto perdano tempo a indagare su problemi davvero semplici "
  
  Sopra c'è un commento che ho aggiunto qualche tempo fa nel supporto del tracker degli errori per il ticket relativo a particolari incidenti di produzione. Subito dopo, le "parti interessate" hanno contattato il team di sviluppo chiedendo come tenere traccia delle nostre pubblicazioni e in che modo possono contribuire alla distribuzione nel loro ambiente. Oh e anche loro sono stati rapidamente aggiornati dalla versione XX-2 . :)</sup>

Quando accade l'escalation della produzione, è meglio essere preparati a presentare la tua visione in modo rapido e chiaro.

Una cosa che troverai utile è selezionare e monitorare chi è responsabile per un particolare slittamento delle versioni. Fondamentalmente, è necessario essere in grado di rispondere rapidamente e chiaramente a domande come "chi è responsabile per il fatto che la versione pianificata non è avvenuta?" Se non sei pronto, potrebbero scegliere la via di minor resistenza e dare la colpa a te. Come sottolineato in commenti a un'altra risposta ," Potresti metterti in acqua calda che la tua gestione sta cercando di proteggerti. "

L'ultimo ma non meno importante,

ci vorrà del tempo

(probabilmente lo sai già, ma vale la pena dichiararlo esplicitamente)

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

C'è un grosso punto interrogativo 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 elevate altezze manageriali. Quindi la mia domanda è: "Ti sei seduto con il tuo capo e gli hai chiesto perché la versione del prodotto è stata bloccata?".

C'è una grande differenza tra la gestione del rischio e l'evitamento. Potrebbero esserci motivi legali o di marketing per ritardare la pubblicazione di un prodotto. Potrebbe trattarsi di problemi di fiducia tra la direzione e il team di sviluppo. Il prodotto potrebbe non soddisfare le esigenze del cliente, anche se è esattamente ciò che il cliente ha richiesto mesi fa. Potrebbe anche essere il caso di qualcuno che si occupa seriamente del management mentre cerca di spostare la colpa per il ritardo altrove, o addirittura un ritardo da parte di una terza parte che è tenuta a completare qualcosa prima che il prodotto venga spedito. Potrei inventarmi dozzine di scenari. Molto spesso lo sviluppatore assume l'avversione al rischio senza capire l'altro aspetto dell'equazione che non è stato reso evidente. Il rovescio della medaglia, può essere semplicemente compiacimento, conflitto tra individui all'interno di un'azienda, o anche il timore che il prodotto fallirà nel mercato per qualche motivo che si traduce in ritardi apparentemente ridicoli.

In tutti i casi, è importante avere maggiori informazioni sui motivi dei ritardi nel rilascio del prodotto e utilizzare tali informazioni per creare una causa per il rilascio del prodotto non appena possibile. Sì, può essere molto frustrante, ma ci sono altri modi per affrontare queste situazioni senza mettere a rischio il confronto con i tuoi capi o il burnout. In situazioni simili, io stesso ho raccolto informazioni, documentato qualsiasi progresso avessi fatto, e poi, se peggio è successo, ho semplicemente accantonato il progetto e spostato su qualcos'altro. Dove sono stato in grado di ottenere un progetto di nuovo in pista per il rilascio di solito è stato il risultato di fare un buon caso di business sulla base delle 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 come un caso di progetto finito e in attesa di approvazione da parte della direzione. Poi mi assicuro che il mio manager firmi il mio documento come accettato e compreso dal management in modo tale che il mio culo sia coperto se dovessero tentare di incolparmi in seguito per un mancato rilascio.

Devi sempre puntare i tuoi I e Cross T per evitare di ritardare i ritardi che ti vengono in seguito incolpati (non importa quanto ingiustamente), ed è anche importante evitare di essere troppo emotivamente legati a tali problemi a meno che non ti piaccia l'idea di un pozzo ha guadagnato l'ulcera. Osservando la tua situazione con un certo distacco professionale, potresti trovare una soluzione che si presenta perché ti sei posizionato efficacemente a una "distanza" maggiore rispetto al problema. Se non riesci a creare il tuo caso, potrebbe essere necessario lasciarlo scorrere per un po ', ma per fare il tuo caso in primo luogo, devi sembrare professionalmente distaccato e avere argomenti basati su informazioni che sono intimamente connesse la tua azienda e il suo funzionamento interno.

Qualcos'altro su cui ho appena pensato quale potrebbe esserti di aiuto, forse leggi Lean Software Development , e vedere se c'è qualcosa di prezioso che possa riguardare la situazione della tua azienda, in particolare nei primi capitoli. Penso che sia stato il capitolo 4 a discutere la questione della consegna il più rapidamente possibile e che abbia qualcosa a che fare con i costi di ritardo.

Direi che il modo più semplice / più efficace per vendere una versione è di abbassare gli strumenti per un po 'quando è pronto. Fai qualcos'altro, inizia un nuovo progetto, lavora sui bug per il progetto esistente. Non fare più niente fino a quando non viene spedito fuori dalla porta - dopotutto, perché preoccuparsi di farlo se non se ne va quando è pronto.

ma nel mondo reale, l'attuale rilascio è il problema di qualcun altro, dovresti spedirlo a loro e poi trattarlo come una versione. Una volta uscito dalla tua porta, è stato spedito. Se ci si siede sopra, non è un problema (anzi, è fantastico, non vengono segnalati bug! W00t! Bonus per una versione priva di bug a tutto tondo;))

Quindi è necessario un sistema di controllo delle modifiche in atto e un gestore di rilascio. Quindi è tutto facile (eccetto che devi gestire il controllo delle modifiche, quindi il controllo del codice sorgente e le build di distribuzione sono molto necessarie. Richiede l'organizzazione, ma se sei organizzato, è facile).

Non riesco ad immaginare che mettere il team Dev in testa al business nel modo in cui descrivi sia una "buona cosa" Potrebbe mascherare il vero problema, ma a meno che il team di sviluppo non sia nella posizione giusta per valutare gli input da vendite, marketing, ecc. ecc., rischi di liberarti per le ragioni sbagliate (e potenzialmente cattive).

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

Hai provato:

1. Chiedere al management di un cliente o di un gruppo di clienti di agire come stakeholder durante lo sviluppo? Di solito puoi trovare un cliente per prendere versioni intermedie e dare un feedback. Possono essere grandi sostenitori quando è il momento di rilasciare. Anche una "versione limitata" a un cliente potrebbe essere sufficiente per aiutare la gestione degli ondeggiamenti
2. Creazione di un piano di rilascio con rilasci di punti. Cioè, oggi puoi rilasciare 3.4 perché la versione 3.4.1 è prevista per oggi + 1 mese. Questo insieme alla buona idea hai già detto che una cadenza di rilascio aiuta questo messaggio.
3. Ottieni supporto, vendite o marketing dalla tua parte. Costruisci delle correzioni che risolvono le 3 richieste di supporto principali e puoi ottenere un alleato da un altro dipartimento. Se non riesci a ottenere un partecipante al cliente come in # 1, provalo con alcune persone addette alle vendite. Offrire di essere disponibile per le riunioni di vendita e portare con sé il prodotto. Quando sei in viaggio, mostra al venditore che sei con il prodotto (in qualunque stato si trovi) facendoli tirare per te.

Per rispondere alla tua altra domanda su "perché la dirigenza dovrebbe sedersi su un rilascio?" Le aziende lo fanno sempre nei campi non SW e non penso che sia senza precedenti. Ad esempio, hai una nuova versione pronta per l'uso, testata e eseguita. Ma la vecchia versione non è ancora stata rimpiazzata dalla concorrenza. Una volta che la competizione ha rilasciato un prodotto concorrente sulla vecchia versione, il management rilascia la versione in attesa sullo scaffale e sconvolge il mercato, arretra la concorrenza e mantiene le vendite e la reputazione di leader del mercato. Rilasciando troppo presto punta la mano verso i concorrenti che potrebbero avere un'idea migliore della tua roadmap e cercare di batterti fino alla fine del gioco.

Con tutto ciò che ha detto ... Il rasoio di Hanlon è probabilmente la risposta giusta: -)

Vai lontano da quella società, non capiscono il software. Ma seriamente, il software è ciò che fa funzionare il sistema, immagina se stavi facendo automobili, le fabbriche di automobili sono lente? aspettano le uscite delle auto? Sono incrementali e burocratici? No, cercano di fare le cose nel modo più veloce e pulito possibile. Hai un problema di gestione e dovresti lavorarci su come conflitto di gestione, prova a parlarne nei termini. Chiedi quale rischio significa per loro, quindi cerca di minimizzarlo. Anche i sentimenti dei tuoi sviluppatori sono importanti, poiché devono far fronte alle decisioni che verranno prese dal tuo intervento. Saranno felici facendo tutte le notti a spedire in tempo? Quali sarebbero i premi / penalizzazioni? Eccetera. Ora ti darò un approccio pratico a questo problema, un po 'estremo, ma chiedi un controllo. Questo ti darà gli strumenti per parlare con la direzione dei problemi che vedi, ma da un punto di vista esterno, e migliorerà anche la tua immagine con loro.