Il cliente può essere un proprietario del prodotto SCRUM in un progetto?

Ciò che ha descritto @Thomas Owens è una spiegazione comune di PO. Sono d'accordo con essa come una buona teoria, ma la pratica è spesso nella mia esperienza lontana. Perché? Perché:

• Partecipante disponibile - almeno per la durata dell'OP del progetto è un lavoro a tempo pieno. Questo può essere un problema serio per la maggior parte dei clienti. Quando si lavora con 5-7 membri del team, l'OP può passare facilmente mezza giornata discutendo le storie degli utenti attualmente sviluppate dal team (ricorda che la storia degli utenti è solo promessa di comunicazioni future) e mezza giornata mantenendo e perfezionando il backlog del prodotto per definire le storie degli utenti per gli sprint imminenti. IMHO PO dovrebbe anche verificare le storie degli utenti completate durante lo sprint come il passaggio necessario per renderle "fatte" e pronte per la riunione di revisione in cui queste funzionalità completate saranno presentate al cliente e alle parti interessate (non a PO!).
• Inoltre, l'OP può essere considerata una vera posizione di lavoro (nello stesso modo in cui è Scrum Master). In tal caso non puoi aspettarti di ottenere buoni PO qualificati al 99% dei clienti.
• Responsabilità finanziaria - L'OP ha la responsabilità finanziaria del progetto. Anche in Scrum qualcuno ha la responsabilità e poiché di solito non esiste un product manager o un project manager, la responsabilità di solito è nell'OP. Responsabilità finanziaria significa responsabilità per il successo del progetto, per la corretta implementazione e comprensione delle esigenze, aspettative e requisiti del cliente. Questo può sembrare una situazione ideale per l'OP dal lato del cliente, ma l'organizzazione di consegna ha bisogno anche di qualcuno coinvolto nel progetto con responsabilità finanziaria.

Scrum non è un approccio standardizzato: è solo un progetto con molte varianti. Per questo motivo è possibile trovare progetti in cui l'ordine di acquisto proviene dal lato del cliente o in cui l'ordine di acquisto proviene dall'organizzazione di consegna. Una volta che hai l'ordine del cliente, assicurati che faccia davvero il suo lavoro. Ho visto le situazioni in cui la PO ufficiale proveniva dal lato del cliente, ma alla fine era solo un titolo vuoto per soddisfare le aspettative di gestione da parte dell'organizzazione di consegna e la maggior parte del suo lavoro è stata eseguita da qualche membro del team che ha segretamente giocato il suo proxy. Questo era ovviamente negativo perché il risultato dello sprint dipendeva spesso dalla comprensione del proxy per le esigenze aziendali dei clienti!

Dalla mia esperienza con i clienti (questo può essere solo locale) una volta che ogni cliente ha davvero bisogno di avere il proprio PO significa anche che stanno andando a guidare il progetto da soli - non cercano un'organizzazione di consegna per guidare il progetto. Cercano un'organizzazione che possa venderli sviluppatori = non fornire implementazione ma una forza lavoro.

Suggerirei, quando possibile, che il Product Owner fosse un rappresentante del cliente. Il ruolo dell'OP è quello di essere la voce del cliente, per garantire che ciò che il team sta producendo aggiunge valore per il business, e scrive e dà priorità alle storie degli utenti. Chi meglio svolgere questi ruoli rispetto a un partecipante disposto dall'organizzazione del cliente? Le parole chiave sono partecipanti volenterosi: devono essere disposti e in grado di partecipare all'ambiente Scrum se questa è la metodologia di processo utilizzata dal team.

Anche questo non è unico per Scrum. Anche il concetto di rappresentante di un cliente (con un rappresentante in loco spesso favorito) fa parte di Extreme Programming.

Il buon proprietario del prodotto deve rispondere a poche domande fondamentali:

1. Sarò disponibile per il team a sufficienza per la pianificazione e la revisione?
2. Potrò lavorare costantemente alla prossima versione & preparazione sprint?
3. Sarò in grado di approvare abbastanza rapidamente le funzionalità implementate? Nel caso ideale, significa che la funzionalità è stata completata immediatamente.

Nella mia esperienza è meglio avere il proprietario del prodotto che è il TUO membro del team.

• Hai bisogno di qualcuno che capisca cosa dicono gli sviluppatori, ma anche di cosa ha bisogno il cliente.
• il proprietario del prodotto dovrebbe funzionare con la contabilità, la vendita ecc.
• gli sviluppatori devono vedere & ritenga che il proprietario del prodotto sia "sulla stessa barca"
• a volte dovrai dire NO al cliente per aprire la sua mente.

Alcune cose da considerare sul permettere al cliente di essere il PO:

1. Se non sono completamente impegnati, è possibile trovare l'intero processo di sviluppo arrestato. La stragrande maggioranza dei clienti non vuole questo tipo di coinvolgimento, alcuni pensano che lo facciano, ma quando si riduce a questo, la maggior parte in realtà non vuole questo impegno.

2. Prendi un processo che è nel tuo controllo e dai il controllo al cliente. È stata la mia esperienza che non essere nel controllo al 100% di un progetto per un cliente è più pericoloso del rischio di non fornire esattamente quello che chiedono. OTOH se si verifica un mancato requisito, la colpa ricade interamente sul cliente per la mancanza di questo requisito, non possono essere incolpati per questo.

3. Se stai sviluppando un prodotto che tu o la tua organizzazione non avete alcun interesse o diritto a girare e utilizzare o vendere ad altri clienti, allora questo può funzionare. In caso contrario, se stai sviluppando un prodotto per la tua azienda che potresti voler personalizzare e adattare ad altri clienti in futuro, potresti creare una catastrofe per te stesso in futuro. L'OP in questo caso dovrebbe essere qualcuno all'interno della TUA azienda perché stai sviluppando un prodotto che è destinato ad essere riutilizzato per più clienti.