Come facciamo gli annunci di rilascio della produzione

In Driftrock siamo una piccola azienda che è passata da 8 a 18 persone negli ultimi 9 mesi. Non è una cifra eccessiva, ma ha comunque messo in discussione alcuni metodi di comunicazione esistenti. Uno di questi è stato il modo in cui comunichiamo le nuove funzionalità che sono state rese disponibili di recente: da qualche parte lungo il percorso abbiamo smesso di farlo.

Shhh! Stiamo rilasciando un software

In precedenza, implementavamo una modifica a una delle nostre applicazioni e non la comunicavamo a nessuno, a meno che non risolvesse un particolare problema del cliente. Questo significava che non cercavamo molti feedback sulle nuove funzionalità e che i progressi e le attività del team erano in gran parte invisibili al resto dell'azienda. Considerando che il nostro software è sempre più utilizzato internamente, questa ci è sembrata una vera e propria occasione persa.

Immettere il rilascio del granchio

Ora abbiamo un canale Slack dedicato per annunciare internamente il rilascio di nuove funzionalità, correzioni di bug e altre modifiche. In genere l'annuncio viene fatto da uno sviluppatore dopo aver spinto le sue modifiche in produzione, in quanto ha un contesto più ampio. Ma siamo pragmatici e non annunciamo ogni piccola modifica, ad esempio potremmo aspettare di aver completato una sequenza di implementazioni rapide. Tuttavia, apprezziamo il feedback e quindi annunciamo regolarmente gli aggiornamenti.

Ecco un esempio di alcuni cambiamenti in corso per Create (un'applicazione per creare rapidamente annunci su Facebook):

(Si noti l'emoji del granchio, che ora è sinonimo di annunci di rilascio).

Sembra un'aggiunta semplice e ovvia a un'installazione di produzione, ma ha avuto un impatto sorprendente: ecco alcuni miglioramenti apportati:

• Ciclo di feedback più stretto: maggiore comunicazione tra il team di sviluppo del prodotto (noi) e gli altri team di Driftrock - Performance Marketing (utenti interni), Vendite e Soluzioni per i clienti.
• Maggiore responsabilità e proprietà: potremmo automatizzare queste note di rilascio, ma il tocco personale aggiunge un elemento di responsabilità, dando ai lettori un punto di contatto per raccogliere qualsiasi feedback. Pertanto, l'autore deve capire cosa sta succedendo e (se necessario) cosa sta succedendo nel team. La raccolta di queste informazioni è necessaria per aiutare l'autore a distillare l'annuncio in qualcosa di semplice e conciso.
• Mantiene le distribuzioni piccole - Allo stesso modo, questa piccola quantità di spese manuali per l'autore ci dà un'altra ragione per mantenere piccole le dimensioni del batch di una distribuzione e assicurarci di rilasciare il software presto e spesso.

Uscite future

Ci stiamo ancora abituando a questo processo e sicuramente si evolverà. Tra le prime idee per sviluppare questo processo c'è l'automatizzazione delle note di rilascio basate sui messaggi di commit e la ricerca di un modo per fornire ai nostri clienti una versione simile, eventualmente rendendola pubblica.

‍