Il Product Manager Agile

Questo articolo, come altri che seguiranno, riportano tradotti un insieme di post di Atlassian riguardanti la gestione e lo sviluppo in chiave Agile, raccolti nella pagina “Camminando sulla corda da funambolo del Product Management in un mondo Agile” (Walking the product management tightrope in an agile world)

In un ambiente Agile, prodotti e features devono essere fluidi. Non come l’acqua sporca dei piatti che si trascina via i ricordi del pranzo…che orrore..! Più simile a una di quelle lampade in cui si muove un magma fluo: in costante, visibile evoluzione. Ma ciò che differenzia l’evoluzione del software da quello di queste lampade da comodino è la strategia.
Ed ecco dove entrano in gioco i Product Manager.
Una delle cose incredibili che ho l’opportunità di fare come Product Manager per Confluence, il software wiki di Atlassian, è parlare con molti clienti. Ascolto che cosa funziona o meno per loro e le sfide che i team affrontano, durante la loro mission di realizzare ottimi prodotti.

Uno degli ostacoli che spesso si presenta è la tensione che le squadre si trovano ad affrontare quando si parla di requisiti. Quale è il modo migliore per gestirli? Come deve apparire il PRD (documento dei requisiti di prodotto) per un team agile? Perlomeno “esiste” ancora? Queste preoccupazioni sono comprensibili, ma se si resta troppo ripiegati su se stessi a pensare alla documentazione, si perderà di vista un punto molto più grande e più importante:

L’Agile Product Management è tutto comprendere i problemi dei clienti. Con ogni mezzo necessario.

Va bene, quasi ogni mezzo. Sicuramente non suggeriamo di fare nulla illegale. O di spaventoso. Ad ogni modo, dov’eravamo rimasti…?

Che cosa significa definire i problemi del cliente, in un mondo Agile? Il manifesto Agile ci ricorda che non dobbiamo sempre farlo in modo “ortodosso”. In quanto Product Manager, dobbiamo fare tutto ciò che è necessario per individuare la giusta customer story. Provate cose diverse: sperimentare, esplorare, quindi fate quello che funziona meglio per voi e il vostro team nel contesto in cui potreste lavorare. Cosa intendo con questo?

• Se significa che avete modo di dibattere molto, e disegnare qualcosa su pezzi di carta – allora fatelo
• Cosa succederebbe se poteste riunire tutti (compreso il cliente) in una stanza e fare un esercizio di mappatura della user story? Se questo riesce a comunicare bene i problemi, allora non avete bisogno di cercare molto altro.
• Oppure se faceste visita al cliente e lo vedeste utilizzare il prodotto nel suo contesto? Potreste far sedere i vostri tecnici e progettisti accanto al cliente per ascoltare e osservare i loro problemi?
• Equipaggiare ulteriormente il tuo prodotto con agganci agli analytics ti fornisce dati aggregati e concreti su come i clienti in generale utilizzano il tuo prodotto.
  Un’altra opzione potrebbe essere quella di “prendere” la triade responsabile del prodotto (un manager, un ingegnere e un designer) per un rapido stand-up per disegnare, discutere e prendere delle decisioni veloci lì sul momento.
• Hai bisogno di esplorare di più? Prova con l’organizzare un workshop dove raccogliere gli stakeholders principali e riempire tante e tante whiteboards, o addirittura fogli di prototipazione per immergersi profondamente nel comprendere i problemi che si sta cercando di risolvere e come risolvere questi problemi.

Ti sei fatto un’idea. In passato il product management e la documentazioni dei requisiti sono stati quasi sinonimi. E non ci sorprende! Scrivere 20, 50 e persino 100 pagine di PRD avrebbe inevitabilmente soggiogato il tuo intero orario lavorativo. Ma nel mondo agile, è importante considerare la scrittura di un documento di requisiti solo uno dei molti modi in cui possiamo contribuire a definire e comunicare i problemi dei clienti.

Gli articoli di approfondimento su l’Agile Management continueranno nelle prossime settimane, sempre sul blog di GetConnected.

di Sherif Mansour – Principal Product Manager, Confluence
Traduzione di Silvia Mantovani