Voglio aprire una riflessione basata su una mia esperienza:
Pochi giorni fa parlavo con una innovatrice, fortemente motivata, di formazione iniziale tecnica che (come spesso accade) ha modificato il proprio ruolo da “developer & architect” a Project Manager.
Il PM conosce le norme, ascolta e intravede i bisogni, effettua proposte per migliorare, redige capitolati e tra le varie cose guida anche un gruppo di “marziani” (coloro che fanno coding).
Il mio intento era illustrare la potenzialità di uno strumento come GIT anche per il capoprogetto.
GIT non è uno strumento nato solo per le pull request (questa è roba da programmatori “marziani”), ma ha l’ambizione di soddisfare anche le necessità del PM, degli utenti, di chi scrive documentazione.
Le issue, il wiki, la gestione dei progetti sono strumenti che possono essere aiutare il lavoro di un PM.
La reazione è stata di stupore e di perplessità: pareva strano che potesse esistere uno strumento che mettesse insieme i “marziani” e le persone normali.
Credo quindi che occorra veicolare cosa di un GIT anche a chi non scrive più codice e che spesso ha il ruolo di decisore.
Un’opera di formazione/informazione che stia a metà tra il project managing ed la trasmissione di competenze digitali di base come gli strumenti per lavoro collaborativo .
Solo una precisazione: GIT in sè è solo il software di gestione del codice, issue / wiki ed altri strumenti di project management (kanban, gantt) sono aggiunti a contorno dalle varie piattaforme…
Si potrebbero individuare gli strumenti più adatti a seconda delle richieste, software open source dedicati ce ne sono per tutti i gusti.
Le piattaforme Git nascono come strumenti per gestire progetti di sviluppo software.
Grazie alla comunità di Open Data Sicilia ho scoperto la possibilità di utilizzare queste piattaforme anche per progetti che non siano software.
Ad esempio, l’organizzazione di un evento come ods16
Così come d’altronde Git viene utilizzato dal Team Digitale per l’esposizione ed il miglioramento del piano triennale, che certamente non è un progetto software “puro”.
Personalmente, consiglierei di dare un’occhiata a GitLab, una piattaforma Git che oltre all’hosting sui loro server rilascia il codice open source per creare una installazione sul proprio server personale.
Ed un’occhiata ad Atom, un editor di testo anche lui open source che permette l’integrazione con gli strumenti Git
Per la formazione “pura” sul sistema di versionamento di Git, io ho imparato grazie a questo libro gratuito
Ringrazio @sabas e @marcofromsicily per la precisazione ed il contributo.
Rimane tuttavia un fatto: chi sviluppa software opera a contatto e all’interno di un gruppo di lavoro dalle competenze più varie e il PM è un ruolo chiave, è poiil PM a contattare i decisori, a dettare i tempi e a dare l’ok per il delivery.
Per essere maggiormente incisivi, per portare a bordo sempre più developers a mio avviso occorre anche il supporto dei PM.
Quindi rilancio la domanda formulata in modo migliore:
“Credo quindi che occorra veicolare cosa di un approccio collaborativo ed aperto (basato su GIT, issue, wiki ecc) anche a chi non scrive più codice e che spesso ha il ruolo di decisore.
Un’opera di formazione/informazione che stia a metà tra il project managing ed la trasmissione di competenze digitali di base come gli strumenti per lavoro collaborativo .
Pensate che sia cosa utile? quanto? perchè?”
C’e questo bel libro che spiega il punto http://www.apress.com/us/book/9781430259329
Io l’ho preso tempo fà ma il project management ha lo scopo di tracciare cosa avviene e dare una direzione oltre che essere di riferimento. Naturale quindi l’utilizzo di software per Kanban (io ne uso diversi più una a post it nel mio ufficio), essere aggiornati sulle tecnologie e sapere cosa succede.
Spesso quando questi punti non ci sono c’è il patatrac, centra poco da quale background si viene se questi tre punti non sono seguiti. Il background serve a dare un imprinting al progetto stesso e al modo di fare e chi sviluppa ha un modo tutto suo di fare che però rientra in questa metodologia visto che è la “bassa manovalanza” del digitale.
Git è solo l’esempio di come fare ma che io ritengo non idoneo per certe tipologie di dati come file binari (assets grafici) per motivi tecnici e di gestione visto che git è nato per lavorare con dati di testo puro.
In conclusione i PM che non sono aggiornati non conoscono questi strumenti e probabilmente neanche li usano rendendoli non dei buoni PM quindi il dubbio è su come si passa allo scalino successivo? Per me un PM che non usa questi metodi o approcci rende tutto più complicato e ci sono passato.
Un esempio per farvi capire: PM che viene dal mondo microsoft ci manda un file XLS con colonne per segnare lo stato e riga per riga i vari task e noi dovevamo scambiarci questo file via email per segnare le cose. Ho caricato su GDrive per poter evitare questo passaggio e modificare in tempo reale ma alla fine siamo passati a Trello solo che lui lo apre una volta a settimana rendendo il progetto non lento, di più.
Per risolvere il problema ci sono varie strategie:
1-cercare di cambiare PM
2-cercare di permettere al PM di cambiare in meglio (coinvolgendolo e fornendogli spunti)
3-cercare cambiare l’organizzazione e eliminare tutti i PM
La 1 non credo sia nel nostro potere, ovviamente la 3 è una piccola provocazione…
rimane la 2 o altre strategie che non vedo.
La problematica che ho enunciato è che c’è troppa distanza dal modo di lavorare dei developers e quella di molti PM (inclusi i migliori)
La mia proposta è:
Secondo me un PM deve avere già queste conoscenze altrimenti non è un PM quindi sta a lui formarsi su questo.
Su quelli che sono PM oggi e non hanno queste conoscenze devono essere aggiornati e nell’AMA di ieri del team si è parlato spesso di problemi di management.
Solo che qui il problema è le competenze dei PM quali devono essere per lavorare nella PA italiane?
Dopo questo si può parlare di formazione su questi punti per chi non ce l’ha ma i nuovi devono essere già a conoscenza altrimenti si entra nel circolo vizioso che è lo stato a dover formare i PM invece di avere persone formate (e sappiamo cosa significa la formazione nelle PA, persone che timbrano il cartellino e ciao).
“persone che timbrano il cartellino e ciao” è una frase non accettabile.
Perdonate la schiettezza in questo modo si squalifica il forum oltre che offendere chi lavora.
Ergo suggerisco prima di procedere di riflettere bene prima di lasciarsi andare con Delle parole in libertà scritte con forse troppa leggerezza.
Caro @Luca_Bonuccelli, ho letto la tua proposta e spero di non andare OT ( è il mio primo post qua)
Ma volevo segnalare 2 cose:
all’interno di troppe PA non esiste il PM, troppo spesso è una sorta d’identità “tricefala” composta da “Funzionario Operatore Informatico della PA” - " Dirigente di riferimento della PA" - “assessore o referente politico”. Ovviamente questo porta a difficoltà lapalissiane
Indubbiamente concordo con l’approccio formativo, accettando però un feedback dei workflow di lavoro delle PA. MI spiego meglio, ovviamente ci sono strumenti e obblighi che devono passare tra un workflow tecnico, ci sono metodologie che se cambiano il workflow delle PA ne guadagnano tutti ( es alcune PA ancora stampano le PEC, una cosa che non esiste e non deve esistere), ma poi ad esempio se vogliono iniziare implementare PagoPA partendo dalle mense, aspettare 3 mesi e poi vedere come funziona, invece di “spingerli” ad applicare più servizi di PagoPA ( come farei io), accettare il loro input e magari poi accompagnarli ad accorciare i tempi.
come fare? questo è il dubbio più importante, e ovviamente non ho ancora una proposta immediata.
ma nei prossimi giorni posterei qua alcune proposte, per capire quali siano la tua e le altrui opinioni al riguardo.
