Sicuramente visualizzazione e categorizzazione delle dipendenze sono passi preliminari e fondamentali: come dico sempre, l'organizzazione la tocchi come ultima cosa (e nessun team in natura è davvero cross-funzionale e autonomo...quindi le dipendenze da qualche parte le hai sempre).
Sulla visualizzazione spesso ho usato dependency spider …
Sicuramente visualizzazione e categorizzazione delle dipendenze sono passi preliminari e fondamentali: come dico sempre, l'organizzazione la tocchi come ultima cosa (e nessun team in natura è davvero cross-funzionale e autonomo...quindi le dipendenze da qualche parte le hai sempre).
Sulla visualizzazione spesso ho usato dependency spider (https://medium.com/@businessanalysishub/spider-dependency-17b5a63116b0) o dependency matrix: quest'ultima può essere usato sia per dipendenze tra diversi team che tra team e componenti di un prodotto/servizio/piattaforma (parlo sempre di realtà grandi, ovviamente). Lo spider si presta anche a situazioni più semplici.
Sulla dependency matrix ti condivido alcune varianti e anche una idea di "strategia" per la risoluzione delle dipendenze (nel mio esempio categorizzate in dipendenze da risorse - es. ci mancano persone o non abbiamo le persone con le competenze necessarie - oppure è una interdipendenza operativa - es. siamo bloccati se team X o fornitore Y non fa certe cose).[https://www.dropbox.com/s/o3u0uqxnmuhyp3c/Dependency%20Matrix.pdf?dl=0]
I modi per risolvere queste dipendenze variano da "hard" a "soft": il primo step è sempre mapparle e categorizzarle, per poi magari avere una board dedicata alla risoluzione delle dipendenze che viene aggiornata settimanalmente.
Le soluzioni poi possono andare verso l'hard e stabile (cambiamo l'organizzazione) o restare sul soft e temporanea (un comitato di risoluzione dipendenze).
Esternalizzare la risoluzione dei colli di bottiglia con un tool è sicuramente una opzione che definirei "medium-hard": occhio a non trasformare il debito tecnico in debito organizzativo 🙂
Sicuramente visualizzazione e categorizzazione delle dipendenze sono passi preliminari e fondamentali: come dico sempre, l'organizzazione la tocchi come ultima cosa (e nessun team in natura è davvero cross-funzionale e autonomo...quindi le dipendenze da qualche parte le hai sempre).
Sulla visualizzazione spesso ho usato dependency spider (https://medium.com/@businessanalysishub/spider-dependency-17b5a63116b0) o dependency matrix: quest'ultima può essere usato sia per dipendenze tra diversi team che tra team e componenti di un prodotto/servizio/piattaforma (parlo sempre di realtà grandi, ovviamente). Lo spider si presta anche a situazioni più semplici.
Sulla dependency matrix ti condivido alcune varianti e anche una idea di "strategia" per la risoluzione delle dipendenze (nel mio esempio categorizzate in dipendenze da risorse - es. ci mancano persone o non abbiamo le persone con le competenze necessarie - oppure è una interdipendenza operativa - es. siamo bloccati se team X o fornitore Y non fa certe cose).[https://www.dropbox.com/s/o3u0uqxnmuhyp3c/Dependency%20Matrix.pdf?dl=0]
I modi per risolvere queste dipendenze variano da "hard" a "soft": il primo step è sempre mapparle e categorizzarle, per poi magari avere una board dedicata alla risoluzione delle dipendenze che viene aggiornata settimanalmente.
Le soluzioni poi possono andare verso l'hard e stabile (cambiamo l'organizzazione) o restare sul soft e temporanea (un comitato di risoluzione dipendenze).
Esternalizzare la risoluzione dei colli di bottiglia con un tool è sicuramente una opzione che definirei "medium-hard": occhio a non trasformare il debito tecnico in debito organizzativo 🙂