Comprendere le sfumature dei diversi ruoli di delivery è fondamentale quando si valuta il tipo di esperienza che l’organizzazione ha e/o ha bisogno. Questo può diventare piuttosto complicato quando le responsabilità si sovrappongono e le definizioni dei ruoli differiscono tra reparti e aziende. Ad esempio, le aspettative possono diventare piuttosto complesse quando si confrontano i ruoli di gestione del programma, del progetto e del prodotto, come un Technical Program manager (TPM) vs un product manager o un Technical Product manager.
Innanzitutto, analizziamo i tratti generali e le responsabilità di TPMS e product manager:
Product Manager:
- Business focused
- Forti capacità di gestione di progetti e programmi
- Aiuta a creare la visione per i prodotti
- Gestisce i dati finanziari e la pianificazione aziendali relativi ai prodotti
- Funzione Drives prioritization
- Gestisce i loop di feedback dei clienti, nonché le prove e gli eventi della customer experience.
- Possono avere proprietari di prodotti sotto di loro che sono responsabili per i flussi di lavoro di ingegneria. Ad esempio, un product manager potrebbe essere responsabile della Xbox di prossima generazione, mentre i proprietari dei prodotti si concentrerebbero su componenti più piccoli come Xbox Live, il controller, il networking, ecc.
- Nota-I product manager tecnici o i proprietari di prodotti tecnici svolgono un ruolo simile a quello sopra elencato ma per prodotti altamente tecnici.
Responsabili dei programmi tecnici:
- Focalizzato sull’esecuzione, la pianificazione e la progettazione ingegneristica
- Di solito un ex ingegnere del software
- Spesso lavora a stretto contatto con gli sviluppatori
- Può essere più allineato al lato business del flusso di valore a seconda di quanto sia tecnicamente esperto il TPM e quale sia la necessità di consegna.
- Responsabile della gestione di tutti gli aspetti di delivery di uno o più progetti tecnici per la propria organizzazione
- Lavora tipicamente con aziende tecniche che hanno adottato tecnologie SOA (service-oriented architecture) e microservices architecture.
- Responsabile per i programmi di guida, a seguito di progresso, e di fornire supporto in caso di problemi
- spesso unità tecnica di dipendenze che devono apportare modifiche per il loro progetto(s) per il lancio di
- Spesso il lavoro dell’intero ciclo di vita dei progetti, dall’idea di generazione in generazione attraverso la distribuzione e ottimizzare la versione completa del flusso di valore
- Può aiutare a stabilire le tecnologie, gli strumenti, e processi in grado di spostare di un’organizzazione verso di Continuous Integration e Deployment e DevOps modello operativo.
- Spesso coinvolto in aspetti non funzionali della distribuzione del software come la telemetria delle applicazioni, le prestazioni, l’affidabilità, la resilienza, la sicurezza e la conformità.
Per visualizzare la differenza tra i ruoli nella consegna del prodotto, valutiamo lo schema seguente:
Come si può vedere, ogni ruolo occupa diversi punti all’interno del flusso di valore – i passi che un’idea di prodotto prende per progredire attraverso un’organizzazione da ideazione, o concetto, attraverso lo sviluppo del prodotto, e l’esecuzione tecnica. I product manager tendono ad essere molto più vicini al lato concettuale e commerciale del flusso di valore, mentre i TPM generalmente lavorano più a stretto contatto con gli ingegneri e la fine dell’esecuzione del flusso di valore. Questo coincide con il loro livello di competenza tecnica, dal momento che i TPMS saranno più coinvolti nelle conversazioni di architettura e potrebbero persino codificare se l’organizzazione ne ha bisogno.
Un altro livello da considerare è la profondità tecnica necessaria per spostare un prodotto attraverso il flusso di valore. Ci piace pensare a questo in termini di un po ‘di’ t ‘in TPM che significa meno esperienza tecnica e un grande’ T ‘ TPM che significa che portano molta esperienza tecnica. Questo intervallo consente una certa sovrapposizione tra i ruoli sopra. Ad esempio, se il responsabile del programma tecnico ha meno competenze tecniche ed è più di un TPM, probabilmente lavorerà più a stretto contatto con il lato business dello sviluppo e della gestione del prodotto. Se sono più forti tecnicamente, possono essere meno focalizzati sul lato del prodotto o del business e essere pesantemente coinvolti nell’ingegneria. Un buon modo per immaginare questo è facendo scorrere il cerchio del gestore del programma tecnico nel diagramma a sinistra oa destra in base alla loro attitudine ingegneristica.
In definitiva, qualsiasi sovrapposizione di responsabilità dipende da ciò di cui l’organizzazione ha bisogno. Questo è il motivo per cui la pratica di leadership di consegna di AIM Consulting enfatizza l’avere una gamma di TPM con competenze tecniche da moderate a profonde per soddisfare le diverse esigenze del cliente.
La tua organizzazione ha bisogno di assistenza per la consegna dei progetti? Parlaci della tua sfida.