Una guida pratica per creare strumenti interni aziendali: come individuare il processo che ne ha bisogno, perché la maggior parte degli strumenti interni finisce abbandonata, il percorso da un flusso manuale caotico al software, e come mantenere il controllo invece di aggiungere l'ennesimo strumento che nessuno cura.
Team operativi, office manager, fondatori e aziende in crescita che tengono in piedi un processo critico a forza di passaggi manuali, messaggi in chat e memoria.
- Un metodo per individuare quale processo manuale ha davvero bisogno di uno strumento
- Un percorso di costruzione, dal flusso caotico al software di cui le persone si fidano
- Uno strumento interno che è tuo e puoi modificare, non un'altra voce del backlog
Ogni azienda in crescita si regge su pochi processi che non vivono da nessuna parte: un'approvazione che avviene in chat, un passaggio di consegne tracciato nella testa di qualcuno, uno stato che tutti chiedono perché non è scritto da nessuna parte. È esattamente a questo che servono gli strumenti interni. Se ne nascono così pochi, non è più una questione di costi; è che non sono mai riusciti a salire sopra il backlog degli sviluppatori. Questa guida ti mostra come costruire tu stesso quello giusto, così che veda davvero la luce.
Il processo che ha bisogno di uno strumento è quello su cui le persone continuano a interrogarsi a vicenda, quello in cui il lavoro si blocca in attesa di un passaggio di consegne, e quello che oggi sta in piedi solo grazie ai messaggi in chat e alla memoria. Se nel tuo team torna di continuo una domanda in qualche forma di «a che punto è X?» o «chi ha Y in questo momento?», quella domanda è la specifica: lo strumento esiste per rendere visibile la risposta senza che nessuno debba chiedere.
Gli strumenti interni non servono a sostituire le persone; servono a togliere la tassa di coordinamento che cresce con il team. Un'azienda di cinque persone si coordina a mente. Un'azienda di venti persone che si coordina ancora a mente spende una quota crescente di ogni giornata in aggiornamenti di stato, rincorse alle approvazioni e spiegazioni ripetute su come stanno le cose. È proprio questo carico invisibile che uno strumento interno mirato elimina, ed è per questo che il primo strumento giusto punta al processo che perde più tempo in coordinamento.
Scegli in base al dolore, misurato con onestà. Passa qualche giorno a notare quale processo genera più «domande veloci», più consegne cadute nel vuoto, più «pensavo lo stessi facendo tu». Il vincitore raramente è il processo più complesso; è quello coordinato più spesso.
Gli strumenti interni falliscono per motivi prevedibili, e conoscerli fin dall'inizio è quasi tutto ciò che tiene in vita il tuo.
Uno strumento interno funziona quando usarlo è più facile che non usarlo. Prima di aggiungere qualsiasi funzione, chiediti se rende lo strumento più rapido o più lento da usare. La maggior parte degli strumenti interni abbandonati è morta di buone intenzioni: campi che qualcuno avrebbe potuto volere, passaggi che sembravano accurati, tutte cose che hanno appesantito il percorso quotidiano finché le persone ne sono uscite.
Il passaggio da un processo che vive nella testa delle persone a uno strumento segue una sequenza affidabile. Saltare il primo passo è il motivo per cui così tanti strumenti risolvono il problema sbagliato.
Il processo peggiore di un team logistico era il prestito delle attrezzature: chi ha quale dispositivo, da quando, e se la restituzione è in ritardo, tutto tracciato in un canale di chat e nella memoria di una sola persona. Osservato per una settimana, si è ridotto a quattro cose: attrezzature, persone, prestiti e uno stato restituito/in ritardo. La versione uno permetteva a chiunque di prendere in carico un dispositivo, mostrava lo stato dell'intero parco su un unico schermo e segnalava in automatico i ritardi. La domanda quotidiana «chi ha lo scanner?» è semplicemente cessata, perché lo schermo rispondeva.
La differenza tra uno strumento interno che vive e uno che muore di solito non sta nelle funzioni; sta nel fatto che il team riesca o meno a tenerlo allineato alla realtà. Due cose lo proteggono.
È qui che descrivere il processo e farci costruire lo strumento attorno batte sia un modello rigido sia uno script una tantum di uno sviluppatore che poi passa ad altro. Ottieni un software modellato sul tuo flusso di lavoro reale, che puoi continuare a rimodellare man mano che il flusso evolve, senza rimetterti in coda dagli sviluppatori ogni volta. Lo strumento resta vivo perché le persone che portano avanti il processo possono tenerlo onesto.
Punta al processo su cui le persone continuano a interrogarsi a vicenda e dove il lavoro si blocca sui passaggi di consegne. Passa qualche giorno a notare quale genera più «domande veloci» e consegne cadute nel vuoto; il processo coordinato più spesso, non il più complesso, è quello in cui uno strumento elimina più tempo sprecato.
Perché risolvono una versione ordinata del processo invece di quello reale, perché aggiornarli è più lento del messaggio in chat che sostituiscono, perché non riescono a cambiare quando cambia il processo, o perché diventano un silo di dati. Il rimedio è osservare prima il lavoro reale, rendere lo strumento il percorso più rapido, ed essere in grado di modificarlo tu stesso.
Solo il percorso principale: creare il record, spostarlo tra i suoi stati reali, vederne lo stato e consegnarlo, più i ruoli che decidono chi fa cosa e chi ha solo bisogno di osservare. Aggiungi le eccezioni che hai davvero osservato, non quelle immaginate, e lascia tutto il resto per quando le persone lo staranno già usando.
Non più, e costruirlo tu stesso ha un vantaggio reale: i processi interni cambiano di continuo, quindi uno strumento che puoi modificare man mano che il processo si sposta resta utile, mentre uno che richiede un ticket agli sviluppatori per ogni modifica si disallinea e viene abbandonato. Descrivi il flusso di lavoro e mantieni la capacità di modificarlo.