Tra i principi che più ci sono di ispirazione nel lavorare in BIM, ho sempre trovato vincente l’idea di accostare il BIM Manager al Product Owner, per motivi che ho già illustrato più volte.
Il primo principio, che è bene ricordare sempre, è che il Product Owner non è un Project Manager. La responsabilità della consegna del prodotto è infatti scaricata direttamente sul team, mentre suo compito è occuparsi di massimizzare il valore percepito presso gli stakeholder. Quante volte si opera all’interno di processi BIM che il cliente non comprende e quanto spesso vengono fatti sforzi enormi per consegnare modelli infomativi di cui il cliente non percepisce il valore? In questo senso, il ruolo del BIM manager è quello di comunicatore, di sponsor del metodo presso la committenza. Se manca questa attività, se le richieste vengono poste in modo non consapevole, il processo non ha valore anche laddove non dovessero venire assolte in modo altrettanto superficiale, come purtroppo spesso capita.
La pillola di oggi si concentra su dieci buoni principi di gestione del prodotto da parte del Product Owner, e sul perché è rilevante considerarli anche nelle attività che un BIM manager potrebbe doversi trovare a gestire sui progetti di cui detiene la supervisione alta.
1. comportarsi da product leader e non da Agile Project Manager (qualunque cosa sia).
Non è compito del BIM manager andare a fare le pulci sugli script del suo BIM coordinator o sugli attributi scelti dal suo team di sviluppo: deve conoscerli solo per poterli difendere e promuovere di fronte al cliente.
2. Spiegare il framework agli stakeholder.
Come cambiano ruoli e responsabilità lavorando in BIM?
3. Rimanere orientati al prodotto anziché al progetto.
Come ciò che stiamo sviluppando per questo progetto andrà ad arricchire l’infrastruttura aziendale anche solo in termini di procedure, esperienze e conoscenze?
4. Migliorare il time-to-learn.
Uno dei miei principi preferiti. Consegnare frettolosamente non è l’obiettivo: l’obiettivo è effettuare consegne di valore che ci consentano di ricevere e implementare il prima possibile dei feedback da parte del cliente.
5. Assumersi la responsabilità del sucesso del prodotto
Una croce che, in Scrum, condivide con lo Scrum Master: la difficile arte di assumersi la responsabilità delle azioni del team e, contemporaneamente, di non interferire nelle decisioni di sviluppo.
6. Bandire il waterfall (e, nel nostro caso, tutti i vecchi metodi)
Sono certa ricordiate la curva del panico di Jared Banks e ciò che accade quando un progetto si fa prendere dall’isteria e ritorna in CAD, senza bisogno che io ve la riporti nuovamente. Una volta sbarcati nel Nuovo Mondo, è necessario bruciare le barche. Non c’è possibilità di tornare indietro.
7. Una maggiore analisi non rende necessariamente migliore il prodotto
Allo stesso modo, una documentazione onnicomprensiva non è necessariamente un bene, anzi, spesso non lo è.
8. Il product owner deve fare ricerca
Con il resto del team impegnato a sviluppare, e il product owner che spesso ha la possibilità di seguire più di un team, è una figura chiave per ampliare gli orizzonti di chi si trova a testa bassa tutto il giorno.
9. Concentrarsi sull’aumento di valore e non sull’aumento della rapidità di produzione.
Abbiamo già visto spesso la differenza tra output e outcome, che nel nostro caso è fondamentale: perdere di vista l’outcome porta alla produzione di modelli inutili.
10. Rimanere in vista
L’obiettivo di ogni metodo collaborativo è inseguire i feedback, sempre e in qualunque momento.
No Comments