FlowSharp

Il processo diventa un documento

Arrivano Flussogramma e PDF del processo. Tra un hotfix e una guida rimasta indietro, il lavoro sulla documentazione diventa parte del rilascio.

FlowSharp: Il processo diventa un documento. Illustrazione editoriale del Diario.

Il designer mi piace: nodi, collegamenti, configurazioni. Ci passo molto tempo e ormai mi orienta.

Questo non significa che sia il modo giusto per spiegare un processo a chi lo deve usare. Questa settimana sono partito da quella differenza.

Il Flussogramma legge lo stesso flusso e lo presenta come un documento: fasi, attività, responsabili e risultati attesi. Nessun secondo disegno da aggiornare a mano.

Un processo che si possa portare in riunione

Posso scegliere la sequenza, le corsie per responsabile o una vista che affianca ordine e responsabilità. L’«Output atteso» aiuta a dire che cosa dovrebbe uscire da ogni attività.

Quando il sistema ricava quell’informazione dalla configurazione, la distingue da ciò che una persona ha scritto. Se manca, lo segnala. Non vorrei che una pagina ben impaginata facesse sembrare completa una descrizione ancora incerta.

Con la v0.85.2 è arrivato il PDF. Mi interessa perché si può leggere insieme, allegare a un manuale o usare per spiegare il lavoro a chi arriva in azienda.

Il PDF attuale usa immagini impaginate. Il testo selezionabile e un’impaginazione nativa sono ancora da fare: li ho annotati, senza presentarli come già disponibili.

L’AI può aiutare a scrivere, senza inventare il processo

Il pulsante «Procedura» propone un testo organizzato per fasi. La struttura deriva dal flusso salvato; l’AI lavora sulle parole. La proposta si rivede capitolo per capitolo.

È una distinzione a cui tengo. Vorrei usare l’assistente per spiegare meglio quello che esiste, non per riempire con fasi plausibili ciò che non abbiamo definito.

Ho dovuto pubblicare subito anche un hotfix: il nuovo campo «Output atteso» non veniva riconosciuto dal validatore. Lo avevamo aggiunto da una parte senza completare il percorso.

Le raccomandazioni lasciate in attesa

La ricognizione della guida ha fatto emergere circa centocinquanta rilievi. Nove delle tredici raccomandazioni di fine luglio non erano state recepite.

Questo mi ha messo più a disagio del singolo bug. I problemi erano già stati individuati.

La guida API descriveva circa cinquantacinque endpoint, contro i trecentonovanta presenti nel codice. Ho dedicato un rilascio alla documentazione, includendo tutti i venticinque strumenti MCP e le correzioni ai capitoli.

Centottantacinque commit nella settimana, centosette soltanto domenica. Nel bilancio mi segno anche questo: finire una funzione deve includere aggiornare ciò che serve agli altri per capirla.

Argomentibuild-in-publicflowsharpflussogrammadocumentazionepdf