Come comunicare all'interno di un'azienda cosa viene distribuito continuamente

4

Lavoro per una piccola società di sviluppo, in totale 20 persone in tutta l'azienda, 3 in fase di sviluppo effettivo e abbiamo adottato il CD per il nostro commit to trunk, e funziona benissimo, da una gestione del codice e dal lato up-time . Tuttavia, stiamo ricevendo critiche dal nostro personale di supporto e dal reparto marketing che non ritengono di avere tempi di consegna sufficienti per le nuove funzionalità e notifiche sulle correzioni di errori che potrebbero modificare il comportamento. Parte del motivo per cui amiamo il sistema CD è per noi in fase di sviluppo, è veloce, ripariamo il bug, aggiungiamo la funzione rapida, chiudiamo il Bugz e passiamo con il nostro giorno all'elemento successivo.

Tutti i membri della nostra azienda sono ora su HipChat in ogni momento e, quando si verifica una distribuzione, viene inviato un messaggio a una stanza in cui sono presenti tutti i membri dell'azienda, che gli fanno sapere cosa è stato appena distribuito (mostra solo i messaggi di commit dalla punta all'ultima distribuzione registrata). Anche noi in fase di sviluppo stiamo cercando di fare in modo che, quando apportiamo una modifica che modifica l'interfaccia utente o un comportamento pubblico, pubblichiamo uno screenshot nella stanza All Company e spieghiamo qual è il cambiamento di comportamento, alla ricerca di pushback o dubbi. Spesso la risposta è silenzio. A volte, si tratta di alcune domande minori, ma non è necessario che nulla impedisca l'implementazione.

Quello che mi chiedo è come fanno gli altri utenti del metodo CD a gestire le notifiche di nuove funzionalità e modifiche alle aree della società che non sono lo sviluppo e, infine, i clienti nel mondo?

Grazie,
Francis

    
posta Francis Spor 11.09.2012 - 22:37
fonte

2 risposte

0

Il tuo problema non è quello della comunicazione dei cambiamenti e non è una delle cattive esecuzioni di CD, è fondamentalmente un problema dell'attuale struttura della tua azienda, e uno del fanatismo degli sviluppatori.

Organizzazioni simili alla consegna continua

Molto simile alle persone, le aziende possono inclinarsi conservatore e liberale. No, non sto parlando di politica, ma solo di un modo fondamentale in cui le attività quotidiane vengono viste e guardate. Le aziende liberali tendono ad essere aperte alla comunicazione e al flusso di informazioni. Ci prosperano. Sono più entusiasti del cambiamento e vedono l'adattabilità come un'opportunità. Tendono a non curarsi di seguire processi severi e possono soffrire di oscillazioni selvagge in stabilità e solvibilità.

Le aziende che sono più prudenti sono molto brave nell'avere in mente un obiettivo aziendale specifico e nel raggiungere i propri obiettivi in un metodo guidato dal processo metodico attento. Il rapido afflusso di informazioni può essere scoraggiante e talvolta minaccioso. Stabilità e prevedibilità sono più importanti dell'essere all'avanguardia e sperimentare l'ultima e la più grande. Sono bravi a trovare una nicchia e proteggono con tenacia le loro posizioni di mercato. Tendono ad essere più stabili e coerenti nelle prestazioni.

Le aziende liberali come le startup che stanno iniziando a decollare sono molto più interessate alla consegna continua perché dà loro le ultime informazioni sui progressi immediatamente. Non hanno una fonte stabile di finanziamento e una strong concorrenza significa che il tempo può essere ancora più prezioso del denaro. La consegna continua garantisce che non vi siano perdite di tempo dal punto di vista del business quando le opportunità di crescita sono infinite.

Le aziende conservatrici ignoreranno il CD nella migliore delle ipotesi e ne saranno infastiditi o minacciati nel peggiore dei casi. La loro cultura manageriale si è formata come risultato di un'impresa commerciale di successo che garantisce un flusso costante di entrate. Aggrottano le sopracciglia su cambiamenti inutili in quanto potrebbero essere rischiosi, introdurre nuovi bug e talvolta il beneficio può essere nullo. Potrebbe non essere importante se l'utente è più felice con le nuove funzionalità se l'azienda degli utenti è già vincolata a un contratto di servizio o un contratto. Il denaro è separato dalla qualità del software a questo punto.

La tua azienda non sembra capirlo perché forse il loro modello di business e la base di clienti li prestano ad assumere un atteggiamento conservatore e temono il costante cambiamento implicato dal CD.

Lo sviluppatore fanatismo e manca il quadro generale

Potrebbero non capire perché sei persino motivato a raggiungere questo obiettivo e, sinceramente, neanche io.

  • È qualcosa con cui vuoi riempire il tuo CV?

  • È un tentativo errato di modificare organicamente la cultura dell'azienda all'interno?

  • Esiste un malinteso o una tensione specifica tra l'assistenza clienti e lo sviluppo che speri di risolvere?

Questo dovrai capire da solo. In definitiva, tuttavia, giungo a queste conclusioni sulla vostra azienda dal fatto che sembra che il gruppo di sviluppatori della vostra organizzazione abbia bisogno di "convincere" l'assistenza clienti su questa cosa. In un'organizzazione orientata allo sviluppo che è aperta ai cambiamenti, alle opportunità e al miglioramento continuo, il gruppo degli sviluppatori stabilirà le regole e gli standard e l'assistenza clienti dovrà adattarsi a te.

Alla fine non sto dicendo che il CD è una cosa negativa in ogni caso, ma non porterà benefici alla tua organizzazione. Il supporto clienti sarebbe idealmente felice di non fare altro che ordinare correzioni di bug dal gruppo di sviluppatori, come necessario, come il drive-thru in un fast food.

    
risposta data 12.09.2012 - 04:01
fonte
2

Il modo migliore per mantenere tutti nel ciclo è avere un giorno / orario di implementazione della produzione su base ricorrente. Quindi è possibile inviare una notifica a tutti i dipendenti interessati un elenco di tutte le modifiche che saranno implementate con la successiva distribuzione. Questo dovrebbe essere inviato con largo anticipo rispetto alle modifiche che verranno implementate (direi almeno un avviso di 8 ore per le correzioni non di rottura), e preferibilmente allo stesso tempo ogni ciclo in modo che tutti gli utenti sappiano quando devono cercare le modifiche imminenti. Chiedere agli utenti di essere costantemente informati di un messaggio di chat room o di essere sempre aggiornati sulla loro posta elettronica ogni giorno è irragionevole.

Da una nota a margine sembra che non ci sia un passo di staging / QA nel tuo processo, se questo è vero dovresti aggiungerne uno, altrimenti sei seduto su una bomba a tempo.

    
risposta data 11.09.2012 - 23:06
fonte