Come comunichiamo il rilascio delle versioni definitive

Driftrock è una piccola azienda che negli ultimi nove mesi è passata da 8 a 18 dipendenti. Non si tratta di una crescita eccessiva, ma ha comunque messo in discussione alcuni dei nostri metodi di comunicazione. Uno di questi riguardava il modo in cui comunicavamo le nuove funzionalità appena lanciate: a un certo punto abbiamo smesso di farlo.

Shhh! Stiamo rilasciando un software

In passato, quando implementavamo una modifica a una delle nostre applicazioni, non ne parlavamo con nessuno a meno che non risolvesse un problema specifico di un cliente. Di conseguenza, non ricevevamo molti riscontri sulle nuove funzionalità e il resto dell’azienda non era quasi mai a conoscenza dei progressi e delle attività del team. Considerando che il nostro software viene utilizzato sempre più spesso a livello interno, ci sembrava davvero un’occasione persa.

Inserisci il granchio

Ora disponiamo di un canale Slack dedicato per annunciare internamente il rilascio di nuove funzionalità, correzioni di bug e altre modifiche. L'annuncio viene solitamente effettuato da uno sviluppatore dopo aver implementato le modifiche in produzione, poiché è lui a conoscere meglio il contesto. Adottiamo però un approccio pragmatico e non annunciamo ogni minima modifica; ad esempio, potremmo aspettare di aver completato una serie di implementazioni rapide. Tuttavia, attribuiamo grande importanza al feedback, pertanto annunciamo regolarmente gli aggiornamenti.

Ecco un esempio di alcune modifiche che saranno implementate su Create (un'applicazione per creare rapidamente annunci su Facebook):

(Da notare l'emoji del granchio: ormai è diventata sinonimo di annunci di lancio)

Sembra un'aggiunta semplice e scontata a un'implementazione in produzione, ma ha avuto un impatto sorprendente; ecco alcuni dei miglioramenti che ha apportato:

• Un ciclo di feedback più stretto: maggiore comunicazione tra il team di sviluppo prodotti (noi) e gli altri team di Driftrock: Performance Marketing (utenti interni), Vendite e Soluzioni per i clienti.
• Maggiore responsabilità e coinvolgimento: potremmo automatizzare queste note di rilascio, ma il tocco personale aggiunge un elemento di responsabilità, offrendo ai lettori un punto di riferimento a cui rivolgersi per eventuali feedback. Pertanto, l'autore deve comprendere quali novità vengono pubblicate e (se necessario) cosa sta accadendo all'interno del team. Raccogliere queste informazioni è fondamentale per aiutare l'autore a sintetizzare l'annuncio in modo semplice e conciso.
• Mantiene le distribuzioni di dimensioni ridotte: allo stesso modo, quel minimo sforzo manuale richiesto all'autore ci offre un motivo in più per mantenere ridotte le dimensioni dei batch di distribuzione e garantire che il software venga rilasciato in anticipo e con frequenza.

Prossime uscite

Ci stiamo ancora abituando a questo processo, che sicuramente è destinato a evolversi. Tra le prime idee su cui lavorare figurano l'automazione delle note di rilascio basate sui messaggi di commit e la ricerca di un modo per fornire ai nostri clienti una versione simile, magari rendendola anche pubblica.

‍