Come ho accennato qui, oggi parliamo di come il mestiere del DevOps Officer abbia molte analogie con quello del Project Manager, analogie che sono direttamente riscontrabili all’interno del corpus di conoscenze universalmente ritenuto necessario per praticare correttamente “l’arte” del Project Management, ovvero il PMBOK (con una O sola), acronimo che sta per Project Management Body of Knowledge, “edito” dal Project Management Institute e ormai arrivato alla sesta edizione.
La mia recente certificazione PMP mi ha dato modo di fare un bel ripasso del tutto, per cui, nel pieno spirito di condivisione della conoscenza del DevOps, ho pensato di sfruttare il lavoro fatto per rivedere con voi quali, sempre secondo me, siano i tool a disposizione del PM che potrebbero far molto comodo anche ad un buon DOO (ma vale un po’ per tutti i DevOpper secondo me).
Prima di cominciare, un po’ delle solite avvertenze:
- Lo so che parlando di DevOps sembrerebbe più naturale associarlo alla certificazione PMI Agile Certified Practitioner, ma continuo ad essere dell’idea (che vi ho spiegato qui) che per certe cose sono necessarie delle basi metodologiche più ampie, quindi gli strumenti contenuti nel PMBOK mi sembrano un ottimo punto di partenza. E comunque “l’anima Agile” del PM è ormai così presente che il éMO ha ,essp “in coda” alla sesta edizione della PMBOK Guide la Agile Practice Guide, sotto forma di allegato dedicato (solo nella versione inglese per ora).
- Per ovvi motivi di spazio (e tempo) non potrò approfondire più di tanto i numerosi concetti che descriverò, per cui prendete questo articolo come una “direzione di studio” da cui partire per approfondire i temi che vi sembreranno più interessanti.
- Come capita spesso in queste occasioni, per molte cose vi sembrerà che si abbia la tendenza a sottolineare l’ovvio, ma non so voi, ma io ho sempre vissuto i workshop e le sessioni di training sul PM che ho fatto nel corso degli anni come delle grosse sedute di autocoscienza, in cui la gente si riconosce nella parte dei “buoni” e tende a pensare, condividendolo con i presenti:”Anch’io avrei fatto così, ma nella mia azienda/gruppo di lavoro/organizzazione non c’è mai il tempo di fare le cose con metodo”. Insomma, siamo spesso nell’ambito delle “regole del buon senso”.
- Ricordo a tutti, ove ve ne fosse il bisogno, che il DevOps Officer non si sovrappone al PM, figura che ha il compito di portare un progetto a compimento, ma lo affianca per rendere più fluide ed efficaci le interazioni tra il gruppo di Progetto (Software nel nostro caso) e quello di Esercizio, gruppo che gestisce il Day by Day dell’IT aziendale e per il quale, nella maggioranza dei casi, il progetto in questione è solo “uno dei tanti” che hanno visto passare “lungo il fiume”.
Detto questo, direi che possiamo procedere.
Le Conoscenze del Project Manager utili al DevOps Officer
Anche senza entrare troppo nel merito dei fondamenti del PMBOK, vi devo ricordare che lo stesso è basato su cinque gruppi di processi: Initiating, Planning, Executing, Monitoring e Controlling, Closing; distribuiti in 10 aree di conoscenza per la gestione (il Management) del Progetto: 4 – Integration, 5- Scope, 6 – Schedule, 7- Cost, 8 – Quality, 9 – Resource,10 – Communications,11 – Risk, 12 – Procurement, 13 – Stakeholder (si, nel PMI si comincia a contare da 4). La particolarità è che tutto il lavoro “pratico” del progetto, lo sviluppo del prodotto, si fa in un unico processo, il 4.3, denominato Direct and Manage Project Work.
La complessità della cosa può spaventare, ma in realtà il tutto si basa su un processo a quattro passi conosciuto come Ciclo di Deming ( PDCA, che vedete riprodotto in figura):
- Plan – pianifica ciò che vuoi fare,
- Do – fai ciò che hai pianificato,
- Check – verifica quello che hai fatto rispetto all’atteso e al pianificato
- Act – migliora il processo correggendo quanto non in linea con le attese e… riparti dal via (Plan);
Il Ciclo di Deming che è anche alla base delle moderne metodologie di Assicurazione della Qualità (da non confondere con il Controllo Qualità, che si occupa di prodotti, mentre la Quality Assurance si occupa di processi, ma sto divagando).
Va da se che, sia che si percorra la “strada lunga” delle aree di conoscenza, sia che si prenda la scorciatoia del Ciclo di Deming, anche solo “per assonanza” termini quali Integration, Communication, Stakeholder ad esempio, sono estremamente vicini a quanto attiene al lavoro di un buon DevOps Officer e una conoscenza di base di cosa realmente voglia dire Plan e quale sia la corretta sequenza su come identificare le cose da fare, ordinarle per priorità e ipotizzarne risorse, tempi e costi, male non farebbe, anche per evitare le storture e gli svarioni che mi capita di vedere in certi posti, quando si parla di fare check di avanzamento mensile di progetto senza aver prima neanche creato una WBS (ma sto divagando di nuovo).
Ergo, secondo me “una letta” della Guida farebbe bene a tutti a prescindere del “grado di DevOppesità” che si ha.
Visto che però di tutto non vi posso parlare, cercherò di concentrarmi su alcune delle cose che ritengo essenziali (e qui mi sto ripetendo, ma temo sia l’età).
Leadership
Una delle cose che ho reputato interessanti della trattazione che fa il PMI della figura del Project Manager è l’indicazione della Leadership come una delle caratteristiche principali del PM stesso, tanto da posizionarla su uno dei lati del PMI Talent Triangle.
Permettetemi di citare il passo della Guida che parla delle Doti di Leadership:
“Le doti di leadership riguardano la capacità di guidare, motivare e dirigere un gruppo. Queste doti possono comprendere la dimostrazione di capacità essenziali quali negoziazione, resilienza, comunicazione, risoluzione dei problemi, pensiero critico e capacità interpersonali.”
Vi ricorda qualcuno? Non ha caso alla Leadership ho dedicato un articolo a tema.
Va ricordato che per il PMI un PM dovrebbe essere sia un Leader (colui che “fa le cose giuste”, che guida e influenza), in particolare all’inizio del progetto quando si crea il gruppo di lavoro, che un Manager (colui che “fa le cose bene”, che dirige), quando i lavori del progetto sono avviati e vanno costantemente monitorati e gestiti.
Ma il PMI non si limita ad enunciare le doti tipiche di un leader, ma ne declina anche i possibili stili; tra questi, ve n’è uno in particolare di cui abbiamo già parlato nell’articolo citato, il Servant Leader (scusate ma non ce la faccio a dirlo in italiano), cioè il tipo di Leader che (cito ancora):
“… dimostra impegno a servire e mettere le altre persone al primo posto; si concentra sulla crescita, l’apprendimento, lo sviluppo, l’autonomia e il benessere degli altri; si concentra su relazioni, comunità e collaborazione; la leadership è secondaria ed emerge dopo il servizio”
In pratica la tipologia di Leadership che, a mio parere, più delle altre è importante quando si è un DevOps Officer.
Altro argomento ampiamente descritto e richiamato all’interno del PMBOK è quello della
Comunicazione
Il PMBOK ci dice che la caratteristica principale di un buon PM è la Comunicazione, dedicando molti dei sui capitoli (e processi) alla gestione efficace della stessa e alle varie sfaccettature che può assumere, dedicandovi un’intera area di conoscenza (la 10), rimarcando “la potenza” della comunicazione non verbale e accennando agli studi e alle teorie più conosciute sull’argomento.
Se avete letto qualcun’altro dei miei articoli, probabilmente saprete che la capacità di comunicazione è una delle caratteristiche che ritengo indispensabile per qualsiasi DevOpper.
Stakeholder
Come ho già scritto poco tempo fa, un buon DevOpper non può avere nemici, poiché è suo preciso dovere comunicare con tutti gli attori coinvolti senza “favoritismi” e superando le difficoltà interpersonali. Questo è un concetto espresso in modo molto chiaro all’interno del PMBOK, tanto da avere (anche qui) un’area di conoscenza dedicata alla gestione degli Stakeholder, siano essi a favore o ostili al progetto.
Ciò si può riassumere con una frase che, per quanto mi riguarda, è stata una folgorazione:
“Gli Stakeholder non si possono selezionare. ma solo identificare“
Ergo, non possiamo scegliere con chi avere a che fare in un progetto, ma dobbiamo interagire al meglio con tutti.
Conclusioni
Potrei continuare a enunciare similitudini e citare esempi di parti di conoscenza del PMBOK utili per il DevOps Officer, ma penso di aver reso l’idea.
Vi lascio ribadendo il suggerimento di approfondire l’argomento direttamente sui “testi sacri” del PMI o sulle ottime guide che ci sono in giro sull’argomento.
Se chiedete a me, un’altra area in cui potrete trovare parecchi spunti è quella della Qualità, in particolare nell’ambito degli strumenti di gestione (che sono 7) e di controllo (che sono sempre 7) e in particolare ai richiami continui al Principio di Pareto (la legge dell’80/20), che mi sto convincendo sempre di più essere:
“L’amor che move il sole e l’altre stelle”.
Alla prossima.