“La pandemia ha reso standard una modalità di lavoro, lo smart working, già in voga all’estero e destinata a rimanere anche dopo il Covid”. Ho messo le virgolette perché sto semplicemente citando l’inizio comune di migliaia di articoli scritti sull’argomento. Nel 2019 ante-virus in Italia lavoravano in smart working in 570.000 (Legge n. 81/2017), poi, causa lockdown, i lavoratori da remoto sono divenuti 8 milioni circa: e smart working non è lavorare da casa ovvero telelavoro ma una modalità di realizzare i processi alternativa a quella tradizionale e rispetto a quest’ultima più misurabile. L’Osservatorio del Politecnico di Milano la definisce una “nuova filosofia manageriale fondata su flessibilità, autonomia, fiducia, responsabilizzazione, collaborazione, ottimizzazione degli strumenti e delle tecnologie”.
I principali benefici percepiti, rilevati da PoliMI, sono, dal lato manageriale, il miglioramento dell’equilibrio fra vita professionale e privata (46%) e la crescita della motivazione e del coinvolgimento dei collaboratori (35%). Le criticità: la difficoltà nel gestire le urgenze (per il 34% dei responsabili), utilizzare le tecnologie (32%) e pianificare le attività (26%). Per gli smart worker la prima difficoltà è invece la percezione di isolamento (35%), seguita da distrazioni esterne (21%), problemi di comunicazione e collaborazione virtuale (11%), barriera tecnologica (11%). I relativi problemi di sicurezza informatica su queste colonne sono già stati affrontati qui.
Ma come cambia la gestione dei progetti informatici nella modalità remota? Quando il mondo è sprofondato nel lockdown, molti progetti erano in corso secondo modalità tradizionali in presenza, totale o parziale. Per comprendere che cosa cambia dobbiamo rifarci all’evoluzione storica dell’ICT Project Management. La mia personale esperienza con i progetti internazionali gestiti da remoto data gli anni 90 del secolo scorso. I collegamenti necessitavano di linee punto-punto fornite da big player “di bandiera” quali BT, Deutsche Telekom, gli svedesi, i danesi, e la Telecom provò ad affacciarsi con TMI e alleanze. Collegamenti ATM da 256k – 384k. Il modello era così fortemente “di presenza” che il massimo sforzo si rivolgeva a creare la condizione di simil-presenza (telepresence di Cisco, le Pleiadi italiane). Non era messo in discussione il modello gestionale, di cui si cercavano i surrogati virtuali ma non l’integrazione collaborativa, né si valorizzava l’indipendenza dal fisico come elemento evolutivo e migliorativo. Il remoto era il meno peggio se non si poteva fare il fisico.
All’inizio del millennio, l’arrivo di TCP/IP e degli H32x avanzati ha fornito una base a basso costo e facile accesso, con tutti i limiti più volte sottolineati di sicurezza e di geolocalizzazione. Un fenomeno particolare è arrivato: mentre nella storia l’innovazione tecnologica è andata di pari passo, in un loop positivo, con lo sviluppo economico, in questo ventennio l’avanzamento è stato dettato da catastrofi e dal generale impoverimento socio-economico. Le Torri, la crisi sub-prime, la delocalizzazione dei mercati e delle produzioni, la crisi dei debiti sovrani, la cessione di indipendenza finanziaria degli stati in Europa, il terrorismo ubiquo, ora il Covid. Non viaggiare, non spostarsi è divenuto una necessità al ribasso che ha stimolato la tecnologia agile e remota.
La “PMBOK Guide” sviluppata dal Project Management Institute (PMI) – Sesta Edizione è internazionalmente riconosciuta come standard IEEE e ISO21500:2012 per descrivere i concetti fondamentali del Project Management applicabili a diverse tipologie di progetti. All’interno della guida sono definiti cinque stadi di progetto:
- Avvio
- Pianificazione
- Esecuzione
- Monitoraggio e controllo
- Chiusura
che transitano inalterati dalla modalità di presenza a quella remota.
Sono anche definite le c.d. dieci aree di conoscenza nelle quali, sulla base delle mie esperienze di avere gestito progetti diffusi, in presenza e in remoto, nascono le differenze di approccio al PM:
| Area di conoscenza | PM tradizionale | PM remoto |
| Gestione dell’integrazione | Flessibilità nell’esecuzione dei regression test e nell’integrazione incrementale dei nuovi sviluppi; disponibilità dell’utente più agevole | Ruoli più rigidi e pianificazione dei tempi di integrazione che tengano conto delle modalità in smart dell’utente |
| 2. Gestione dell’ambito | Perimetrizzazione condivisa; meeting di definizione del campo di esistenza del progetto | Perimetrizzazione condivisa; meeting di definizione del campo di esistenza del progetto |
| 3. Gestione dei tempi | Lineare, incrementale; misurabilità spesso empirica | Iterativa, dipendente da qualità dei collegamenti in remoto, pianificazione più “corta” e più efficace; misurabilità esatta |
| 4. Gestione dei costi | Budgeting e reporting dedicato; attenzione agli aspetti di accesso e sostenibilità | Budgeting e reporting dedicato; attenzione agli aspetti di accesso e sostenibilità. Minori costi di spostamento |
| 5. Gestione della qualità | Protocollo di QA / QC dinamico e interattivamente rivisto regolarmente | Protocollo più rigido e meno alterabile dinamicamente |
| 6. Gestione delle risorse umane | Prevalenza del metodo selling; motivation by doing | Prevalenza dele metodo participating; motivation by result. Depersonalizzazione del leader di progetto |
| 7. Gestione delle comunicazioni | Semi-strutturata, complessa, multi-canale, orientata al consenso | Strutturata, efficace, orientata alle decisioni |
| 8. Gestione dei rischi | Mitigazione e off-set del rischio; piano del rischio e della continuity | Gestione dei rischi addizionali e della sicurezza da remoto; gestione della resilienza da crashdell’infrastruttura |
| 9. Gestione dell’approvvigionamento | Gestione semi-formale; relazioni personali | Gestione formale; trust / loyalty come valori aggiunti del fornitore |
| 10. Gestione degli stakeholder | Fondamentale, diretta, multilaterale, multilivello | Complessa e 1:1; maggiore rilevanza del n.1 rispetto alla prima linea; difficile accesso alla proprietà / al board |
È così nata la figura del Remote Project Manager (RPM), per gestire efficacemente in smart working i fornitori esterni e i team interni che si trovano in diversi luoghi e fusi orari (non si sottovaluti quest’ultimo aspetto) e con un uso dell’inglese spesso non omogeneo e talvolta non gradito. La metamorfosi da Project Manager “presente” a Remote Project Manager può causare delle difficoltà di comunicazione e coordinamento. Occorre quindi adottare nuovi strumenti, mentalità e metodologie. Per quanto riguarda gli strumenti, questi si dividono in quattro categorie:
- strumenti di comunicazione (Skype, Zoom, Meet, Teams, etc.)
- strumenti di produzione (Google Suite)
- strumenti di tracking (Toggl, Datastudio)
- strumenti di gestione (Trello, Asana etc).
La mentalità, il mind-set, poggia a mio vedere su tre elementi chiave da tenere sotto governo:
- la motivazione: l’esperienza tende a mostrare che in smart va a decadere se lasciata a se stessa. È fisiologico che il lavoro insieme in un ambiente fisico fornisca molti più spunti di motivazione che stare in casa. Se il lavoro è una learning curve, lo smart working è una DaD.
- Il change management: manca quell’elemento informale e interstiziale che agevola il cambiamento, quella sensazione della velocità ammissibile per l’organizzazione, la direzione e l’intensità del vettore organizzazione – operazioni che ci sposta dallo stato AS IS al TO BE. La figura del Change Manager in smart tende inevitabilmente a scomparire e passa al RPM
- Il recupero degli sfridi: scampoli di tempo, code di attività, attività extra. L’affermazione che lo smart renda il +15% di produttività, oltre che illusoria, manifesta un modo tradizionale e improprio di valutare il remote PM. Uno studio Gartner su 10,000 digital workers americani mostra che il 46% dichiara di non avere avuto incrementi di produttività o di averne persa. Risparmiare tempi e costi non è il driver chiave.
Si passa perciò mentalmente a un concetto di responsabilità distribuita, delicato equilibrio fra competenza professionale e spirito di squadra.
Passando alle metodologie, lo sviluppo agile dei progetti software è di natura incrementale. La sua diffusione risale al Manifesto Agile pubblicato nel 2001, mentre la metodologia Scrum era stata sviluppata già a partire dal 1993. La sigla Scrum deriva dal gioco del rugby dove identifica la mischia. Scrum segue un processo Inspect and Adapt e prevede pochi specifici ruoli, rilasci intermedi e piani chiamati Time Box. Un team Scrum è di solito composto di 5 / 7 persone.
La metodologia si basa sull’idea, che tutti abbiamo sperimentato, che gli utenti quasi certamente cambieranno più volte idee e specifiche durante lo sviluppo; pertanto, i cicli sono brevi e con numerosi rilasci intermedi iterativi, da cui l’incrementalità. Vi sono solo tre ruoli in una squadra di sviluppo: Product Owner, Scrum Master e il Team. Nel Team è normale che i partecipanti cambino spesso cappello e assumano funzione di guida. Scrum è un semplice framework di Project Management e, in quanto agile, rappresenta un’evoluzione della metodologia Waterfall, il tradizionale approccio di Project Management. Si può anche dire che Scrum è un wrapper dei processi, esistenti o ridefiniti a parte, e milita nella categoria pugilistica dei lightweight, basandosi essenzialmente sui concetti di comunicazione, collaborazione e self-organization, molto indicati per i progetti in smart. Per quali motivi il ruolo dello Scrum Master funziona? In primo luogo, è un bulldozer dedicato; infatti, contrariamente ad altri framework, si identifica in lui una persona che deve rimuovere gli ostacoli senza distogliere gli altri del team. È anche il coach dedicato, e anche in questo la sua responsabilità è unica. È imparziale, nel senso che non prende posizione nelle dispute fra utenza e Team.
È qui importante un concetto tutt’altro che intuitivo: Scrum si concentra sul framework non sul rilascio, del quale non ha responsabilità diretta. Inoltre, il distacco dello Scrum Master dal Team fa sì che possa lasciare il progetto ed essere sostituito senza mettere in crisi il Team. Più tradizionale è il ruolo del Product Owner, a cui si richiede di definire le priorità e farle rispettare, formalizzare i requisiti e i loro eventuali cambi, mantenere l’allineamento fra sviluppo software e-business. Se guardiamo invece il Team, esso deve contenere esperti dedicati ma al tempo stesso flessibili alle esigenze e ai requisiti. La metodologia agile è anche definita lean e infatti i Team sono piccoli per minimizzare il costo. Conseguenze sono un minore bisogno di management e la eventuale scalabilità al crescere dei requisiti.
Ovviamente non sempre va così per i motivi più disparati, da strutturali a contingentali. Una cosa che però frequentemente si riscontra negli sviluppi informatici condotti con metodologie agili è che viene trascurata la parte di Software Engineering (la Continuous Integration e il Test Driven Development) senza le quale metodologia agile lavora più velocemente ma a scapito della qualità. Per essere concreti, stiamo parlando di integrazione continua quando ad ogni parte nuova introdotta si procede alla sua piena integrazione con l’esistente e al testing del nuovo assemblaggio complessivo (incremental integration testing), intuitivamente più lungo come tempi.
Cercheremo in un successivo intervento di entrare più in dettaglio su come funziona Scrum, evidenziandone i benefici di agilità e le differenze rispetto ad altre metodologie agili quali Six Sigma o Lean o come avanguardie resource-based come Critical Chain Management.
