Show More
Menu
Image
Hi there! I am Federico Trotta

Technical Writer

Release Notes: Come Implementarle in un Ambiente a Rilasci Frequenti

15/01/2024
By Federico
0 Comments
Post Image

NOTA: puoi leggere questo articolo in inglese qui.

Quando si crea la documentazione legata al software e al prodotto, le release notes sembrano facili da implementare: quasi una banalità.

La verità è che dipende dall’ambiente in cui stiamo lavorando.

C’è molta differenza tra essere un Technical Writer in un’azienda grande e strutturata ed in un’azienda di piccole dimensioni, come magari una startup.

Inoltre, c’è una grande differenza tra lavorare in un ambiente in cui gli sviluppatori rilasciano in produzione una volta ogni due mesi e uno in cui rilasciano ogni due settimane.

In questo articolo, mostrerò come possiamo implementare le release notes in un ambiente di consegna rapida.


Ciao, sono Federico e sono un Technical Writer:

Federico Trotta
Federico Trotta

Vuoi collaborare con me? Contattami!


Step 1: dì che esisti

La prima cosa che un’azienda di software deve capire è che i Technical Writer esistono e devono completare i loro compiti in determinate tempistiche, esattamente come le altre persone in azienda. 🙂

Se la tua azienda decide che gli sviluppatori devono rilasciare i contenuti ogni due settimane, le release notes devono essere pronte prima del rilascio.

Ciò significa che hai bisogno di tutte le informazioni di cui hai bisogno, devi testare il software (per provare eventuali nuove funzionalità) e devi aver scritto la documentazione prima del rilascio.

Per farlo, la prima cosa da fare è dire ai tuoi colleghi che esisti e che hai bisogno di tempistiche, così da inserirti nella pipeline e decidere con loro il processo e di cosa hai bisogno.

Step 2: decidi il process

Ora che sanno che esisti, sai anche che avrai tempistiche strette per svolgere il tuo lavoro perché i rilasci sono in un periodo di tempo breve, quindi devi sentirti a tuo agio con le nuove funzionalità in tempi rapidi, per documentare in tempo.

In ogni caso, è necessario stabilire un processo con sviluppatori e prodotto, perché il software non può uscire se la documentazione non è stata completata.

Idealmente, dovresti implementare un processo come questo:

  • Gli sviluppatori impiegano “y” giorni per sviluppare nuove funzionalità, correggere bug e fare il loro lavoro.
  • I tester si prendono il tempo necessario per testare il software.
  • Uno Scrum Master, un project manager, un product owner (o chi per loro) ti avvisa che le funzionalità sono state testate, in modo che tu possa iniziare a creare i documenti.
  • Fai i tuoi test, scrivi i documenti e le note di rilascio.
  • Qualcuno approva le release notes.

In questo scenario, ovviamente, un PM (o chi per esso) ha creato una tabella di marcia per stimare il lavoro di tutti, in modo che:

  • Tu abbia una idea delle features che saranno presenti per la prossima release.
  • Quando gli sviluppatori hanno completato le loro attività, iniziano a lavorare sulla versione successiva, su un branch di sviluppo. In questo modo, i tempi per le diverse figure in gioco (sviluppatori, tester, tech writer) non si sovrappongono, ma il programma prevede comunque il rilascio ogni “x” settimane, e questo rimane lo stesso per il prodotto.

È davvero importante avere qualcuno che possa approvare le release notes in modo che sia chiaro che non hai frainteso qualcosa. Inoltre, alcune cose potrebbero non essere rese disponibili ai clienti pubblicamente, e questo deve essere discusso.

Un peoduct owner può essere un’ottima figura da scegliere per approvare le release notes che sono state preparate in una bozza. Ad ogni modo, segui il mio consiglio: snellisci il processo di approvazione e non farlo dipendere da una sola persona. Cosa succede se l’unico approvatore si ammala il giorno in cui dovrebbe approvare, proprio prima del rilascio???

Step 3: pubblica le release notes

Idealmente, dovresti pubblicare le note di rilascio (e tutta la documentazione) insieme al prodotto.

Questo non è sempre possibile, però per diversi motivi, a seconda del software utilizzato per gestire la documentatione, e per molti altri.

Quindi, la soluzione potrebbe essere quella di pubblicare le note di rilascio prima che il software venga distribuito e scrivere che le nuove funzionalità (e i bug risolti!) saranno disponibili in una certa data, in un intervallo di ore preciso, in modo che i clienti sappiano quando il software sarà aggiornato.


Conslusioni

Implementare un processo di release notes in un ambiente a rilasci frequenti non è facile, ma queste idee ti aiuteranno a impostare un processo. Poi, il processo può cambiare nel tempo, ed è giusto così. Ma l’importante è partire, stabilendone uno.

Ricorda: rendi il processo il più snello possibile, con tutti i controlli che ti servono. E se hai bisogno di aiuto o di una consulenza su come implementare tale processo, contattami.

Federico Trotta

Technical Writer: I document digital products and write articles about AI & Python programming.

Leave a reply