Uno dei grossi problemi che rischia di colpire le organizzazioni che sviluppano software (e anche altre, a dire il vero) è il micro-management. Come diceva Bertard Russell, in “Elogio dell’ozio”, al mondo ci sono due tipi di lavoratori: quelli che fanno le cose e quelli che dicono ad altri di farle. E il manager ricade in questa seconda categoria. Però mentre un manager attento non ricade nel micro-management, altri invece sì.
Alcuni segni del micro-management sono:
- Il micro-manager non è mai soddisfatto di ciò che gli/le viene consegnato, e continua a pensare (e talvolta a dire) che avrebbe risparmiato tempo e fatica se avesse fatto lui/lei quella cosa.
- Va dritto su certi dettagli ed è contento di poter applicare delle correzioni, e far vedere al mondo che è il più bravo.
- Vuole costantemente essere in controllo di dove sono i suoi collaboratori e cosa stanno facendo. Questo perché presume che stiano perdendo tempo, e solo col suo costante pungolare questi riescano a fare quanto assegnato loro. Ad es. vuol essere messo in CC su tutte le email.
- Il micro-manager attua questo comportamento indistintamente dalle attività, che siano importanti e critiche, o di dettaglio, l’atteggiamento è lo stesso. Probabilmente lo fa perché ritiene che solo così possa giustificare il proprio lavoro; in poche parole, ritiene di venir pagato proprio per questa ragione.
- Spesso il micro-manager organizza il suo lavoro su un piano di esecuzione, molto dettagliato, che non ha negoziato con i suoi collaboratori, ma che viene loro imposto.
In generale il micro-management è dannoso perché crea frustrazione in chi ne è soggetto, demoralizza, demotiva. Ma soprattutto esso è possibile solo quando il manager è a stretto contatto con i suoi collaboratori. A distanza, e con tempi contingentati come sono quelli scanditi dalle videoconferenze, il micro-management non può aver luogo. Da micro-manager, non posso sorvegliare, monitorare, controllare di continuo qualcuno che è a casa sua per tutto il giorno. Il tempo che perdo per allestire e partecipare a tutte le varie videoconferenze è troppo elevato; non posso permettermelo. Facendo questo, il micro-manager assume di disporre di tutte le informazioni che servono per coordinare e dirigere i suoi collaboratori e vuole fungere da nodo centrale attraverso il quale le info devono viaggiare: sia quelle che arrivano dal basso, che quelle che arrivano dall’alto.
Quindi, forzare uno stile di micro-management con il telelavoro porta a un notevole rallentamento dato che le occasioni di scambio di informazioni al fine di supervisionare il comportamento dei collaboratori sono molto meno frequenti e costano molto più tempo.
Come venirne fuori?
Cambiando atteggiamento, delegando responsabilità ai collaboratori e dando loro autonomia.
Delegare la responsabilità significa che occorre allineare i collaboratori rispetto al risultato atteso, alle sue caratteristiche desiderate, prevedendo dei gradi di libertà. Il manager non deve supervisionare il comportamento del collaboratore, quanto invece verificare la qualità del risultato del lavoro e casomai aiutare il collaboratore ad arrivare in fondo.
Siccome nel software la quantità di dettagli che occorre gestire rende impossibile la definizione completa di cosa occorre fare (questo vale sia a livello macroscopico di prodotto, che a livello microscopico di modifica di una classe), occorre fare in modo di poter delineare le caratteristiche di ciò che si vuole. Ad es. indicando quale sia lo scopo di una certa “cosa” da fare, quali siano gli effetti che si desidera ottenere una volta che essa venga messa in produzione. E periodicamente assicurarsi che ci sia progresso.
Per poter delegare le responsabilità occorre anche essersi accordati sul modo di lavorare. Ad es. ci si deve essere messi d’accordo che i test del software vanno fatti in un certo modo e in una certa qualità. E che si facciano vari commit all’ora, e si facciano dei merge request più volte alla settimana.
Infine i collaboratori devono essere consapevoli del proprio ruolo e di cosa il manager e i colleghi si aspettano da ciascuno.
Se si delega responsabilità bisogna anche accordare autonomia, in modo che il collaboratore sia libero di poter scegliere, all’interno di paletti chiari e condivisi, come risolvere le varie questioni. Questo implica che da manager non posso più pretendere che solo la mia idea di come risolvere un problema sia quella giusta. Persone diverse produrranno soluzioni diverse e io dovrò accettarle, se le soluzioni soddisfano i criteri concordati.
L’accordare autonomia implica anche che il collaboratore possa sbagliare, e che quindi abbia bisogno di tempo per farlo e per rimediare. Questo è particolarmente vero nello sviluppo del software, dove ciascun refactoring è in pratica causato da errori fatti in precedenza. E gli errori sono la molla per imparare cose nuove, attività fondamentale in chiunque sviluppi software.
Ad es. nel progetto SKA, che viene gestito in maniera agile secondo il framework SAFe, la delega avviene a vari livelli e di continuo. A livello di team il Product Owner delega ai collaboratori le decisioni su come fare una certa cosa. Quello che il PO non delega sono decisioni su cosa è più urgente fare, o su come decidere se una certa cosa è fatta. Il PO non fa micro-management perché non è in contatto continuo col team (essendo spesso sparpagliato) e perché sa di poter contare su persone responsabili e capaci. Lo Scrum Master analogamente non ha modo di fare micro-management, in parte perché non è detto che ne sappia di ciò che il team deve realizzare e in parte perché non è chiamato a farlo. A livello di iterazioni trimestrali (Program level), il Program Manager non fa micro-management dato che non è in contatto frequente con il team (lo sente/vede forse 1-2 volte al mese). Il PM però deve verificare che il team abbia compreso quali caratteristiche di una “feature” sono importanti e devono essere realizzare alla fine. E deve verificare che alla fine del trimestre le feature siano soddisfacenti rispetto a queste caratteristiche.
Si noti che non ho menzionato la parola “progetto” – perché si tratta di un concetto non utilizzato.
