Grazie mille per la tua guida @tobiaseigen riguardo a Discourse for Teams. Inoltre, queste sono ottime notizie @david! Gestire il lavoro in sospeso sarà ancora più semplice ora. Vorrei usare questo post per raccontarvi quali sono state le funzionalità chiave che ci hanno spinto a passare a Discourse.
Contesto
Siamo un team di sviluppatori software, analisti funzionali e amministratori di sistema dedicati alla creazione di soluzioni di gestione aziendale per il mercato colombiano; tuttavia, il mondo intero è nella nostra roadmap ;). Sviluppiamo software personalizzato per i nostri clienti e abbiamo anche i nostri prodotti originali, ma attualmente la nostra attività principale consiste nel fornire servizi ed estensioni basati su Odoo ERP. Tra tutte le applicazioni incluse in Odoo, ci siamo specializzati nella gestione della contabilità, dell’inventario e delle risorse umane. Come potete immaginare, utilizziamo Odoo in modo estensivo e, sin dalla nostra fondazione nel 2015, la sua applicazione di gestione progetti è stata la nostra migliore alleata. Grazie alla sua interfaccia Kanban (alla Trello), il nostro team riesce a gestire il flusso di lavoro delle attività concordate per ciascun progetto di implementazione. Tuttavia, l’implementazione di un progetto è solo l’inizio della relazione con un’azienda cliente, ed è durante il periodo di manutenzione che le cose possono complicarsi se non viene fornita una gestione efficiente e una comunicazione rivolta all’esterno. Ma Odoo dispone di un’applicazione Helpdesk che permette di gestire una comunicazione basata su ticket con gli utenti del proprio software tramite email e, naturalmente, anche noi abbiamo sempre utilizzato questa funzionalità per erogare i nostri servizi di supporto. Rispondere rapidamente a domande funzionali è stato semplice grazie a questo strumento, ma quando arriva un rapporto di bug complesso, è necessario generare un documento separato per agevolare il processo di sviluppo. In questi casi abbiamo utilizzato Gitlab e Github Issues, e persino file restructuredtext controllati tramite versioning personalizzati (analizzati con strumenti Python sviluppati internamente) per definire un formato di segnalazione dei problemi indipendente dal fornitore. Alla fine, ci siamo trovati nella situazione in cui il lavoro da svolgere doveva essere cercato in almeno tre posti diversi, utilizzando interfacce e flussi di lavoro differenti. Sia la comunicazione esterna che quella interna, necessarie per svolgere le nostre attività quotidiane, erano a rischio, e questo ci ha spinti a cercare processi e strumenti alternativi, anche se ciò significava fratturare il nostro “odoo-centrismo”. Discourse è famoso come software per forum da molti anni, ma abbiamo conosciuto le sue funzionalità di gestione del lavoro solo molto recentemente, dopo aver condotto alcune ricerche. Ciò che ci ha spinto a provarlo sono stati tre elementi: comunicazione asincrona, omogeneizzazione della definizione del lavoro e controllo del lavoro in corso (WIP).
Comunicazione Asincrona
I post di Discourse sono come le email, ma migliori. In un mondo fatto di Whatsapp, Slack, Messenger, Mattermost, Odoo Chat e molti altri, ci siamo abituati a essere sempre in “modalità allerta”. Poiché tutto sembra urgente, si viene spinti a rispondere con risposte brevi, veloci e superficiali. Nessun tempo per pensare, nessun tempo per correggere. Basta scrivere e inviare. Scrivere questo post, ad esempio, mi ha richiesto molto più tempo di quanto avrei previsto, ma lo sto facendo dopo aver completato altri compiti più urgenti, così posso concentrarmi nel fornire il mio feedback più sincero e dettagliato (il minimo che posso fare per uno strumento così eccellente come Discourse). Scrivere un post è come inviare un’email, ma leggerlo è tutta un’altra storia. Una molto migliore. I post sono centralizzati e condivisi tra tutti i membri di un team (o quelli autorizzati). Possono essere cercati per contenuto o posizione (ad esempio, argomenti e categorie) e persino essere accessibili a utenti esterni o membri dello staff che non hanno partecipato alla conversazione originale, il che è ottimo per conservare la traccia storica di come vengono prese le decisioni e qual è stato il loro contesto. Nota rapida: osservare come python.org abbia adottato Discourse come applicazione di gestione della comunità, invece delle mailing list o di altre soluzioni basate su Python, dimostra che ciò che abbiamo qui è davvero eccezionale in termini di idoneità, prestazioni e accessibilità.
Omogeneizzazione della Definizione del Lavoro
Questa è la ragione principale per cui stiamo passando a Discourse. Dal contesto fornito in precedenza, potreste aver immaginato un ambiente di lavoro molto colorato e intricato. Sono stato certamente un po’ troppo drammatico, perché abbiamo effettivamente avuto processi documentati e strumenti digitali per gestire le nostre attività fin dalla nostra fondazione. Ma ciò che ci è accaduto col passare del tempo è che non siamo riusciti ad avere una rappresentazione unica del lavoro all’interno dell’azienda. Sì, avevamo attività per le attività di consulenza e ticket per il supporto. Lo sviluppo era guidato da requisiti documentati in testo semplice o dai ben noti issue legati a Git. Non si trattava di una mancanza, ma al contrario, di un eccesso. C’erano troppe fonti di informazioni e persino all’interno di un’applicazione comune (ad esempio Odoo) esistevano molteplici formati (ad esempio Task, Ticket, Issue). Naturalmente avremmo potuto decidere di scegliere uno degli strumenti sopra menzionati come unica fonte di verità, ma nessuno di essi ci forniva un elemento cruciale: il feedback esterno integrato. Con solo un mese di utilizzo di Discourse, finalmente sentiamo di essere in contatto con gli utenti dei nostri prodotti. Non c’è distinzione tra loro e noi, poiché tutti utilizziamo la stessa interfaccia. Tuttavia, non dobbiamo rinunciare al controllo su come gestiamo il nostro lavoro, poiché alcune aree e funzionalità possono essere limitate. Ma la cosa migliore di tutte è che, attraverso gli Argomenti di Discourse, quegli stessi elementi, simili a commenti di blog o ticket di helpdesk, che stiamo utilizzando per comprendere le esigenze dei nostri clienti, possono essere utilizzati da noi in categorie interne private per rappresentare attività pianificate da svolgere, problemi da affrontare o attività operative da eseguire. Per noi, un argomento ha molti sinonimi, tutti validi a seconda del contesto: Issue, Task, Ticket, Activity, Checklist, ecc. Una forma omogenea del lavoro, aperta, accessibile e gestita centralmente. Ho letto che con Discourse for Teams state pianificando di rilasciare un prodotto separato, diverso dal forum Discourse, o in altre parole, che Discourse (Forum) e Discourse for Teams sono destinati a essere distribuiti come due istanze diverse. Vi consiglio di pensarci con pazienza, perché tale design fratterà inevitabilmente l’integrazione attualmente fornita tra le parti esterne e interne di un’organizzazione.
Controllo del WIP
Infine, una delle migliori sorprese che abbiamo avuto grazie all’uso di Discourse è che possiamo finalmente stabilire un controllo sul lavoro in corso nell’organizzazione. Poiché il lavoro da svolgere ha tutti la stessa “forma”, è facile definire politiche per limitare la quantità di lavoro che l’organizzazione dovrebbe avere in qualsiasi momento. Tramite il plugin Assign, alle attività viene assegnato un unico responsabile che deve cercare aiuto se necessario (che è un ‘@’ a distanza) e poi, utilizzando un’interfaccia unificata (trovabile in ‘/g/staff/assigned/everyone’), è possibile controllare la quantità di attività in corso (cioè WIP) in tutto il sistema. Al momento, ad esempio, stiamo iterando con un WIP per persona di 5 attività/argomenti/issues. Essendo in 14, ciò significa che la nostra capacità massima come team dovrebbe essere 70. Questo è molto importante per noi perché aiuta a fornire stabilità a una delle imprese più difficili della vita: la stima. Secondo la Legge di Little (Little's law - Wikipedia), il numero medio a lungo termine di elementi in una coda è uguale al suo tasso medio di arrivo o throughput, moltiplicato per il tempo medio di attesa che ciascuno di quegli elementi trascorre nel sistema. Quindi, con un WIP vincolato di 70 elementi, se riceviamo 140 ticket a settimana, questi saranno completati in media in 0,5 settimane, e sarebbe di 0,33 settimane in media se ricevessimo 210. Questo presuppone, naturalmente, che il sistema sia in uno stato stabile e che il backlog non cresca indefinitamente, quindi una corretta calibrazione del WIP deve essere condotta in modo iterativo. Abbiamo ancora (e avremo sempre) quantità minori di tipi di lavoro che non potranno essere rappresentati in Discourse, come la gestione dei nostri messaggi email o del nostro pipeline CRM, ma poiché la maggior parte del nostro lavoro da svolgere ha ora una forma unica come gli Argomenti di Discourse, l’implementazione di pratiche Kanban e Agile, come il vincolo del WIP, sarà molto più semplice. Per questo motivo vi consiglio che, se Discourse for Teams è destinato a essere un’istanza separata di Discourse Forum, sarebbe un peccato non avere almeno un modo federato per mantenere una visione centralizzata e composta del WIP in entrambi i sistemi.
Spero che questo post contribuisca a migliorare Discourse come piattaforma di comunicazione e costruzione della comunità. Ancora una volta, grazie mille e vi auguro il meglio!
displays search with “Search posts by @tobiaseigen” tickbox. It would make more sense to see “Search assigned to @tobiaseigen”.
