Today’s BIG thing

It is great to see that most of the principles and the techniques I use to inspire and drive my customers’ businesses were “Just a crazy idea two years ago, but [they are ] now teached at Stanford, Berkeley, Columbia, Caltech, Princeton and for the National Science Foundation at the University of Michigan and Georgia” Tech” http://bit.ly/QS8551

Many, many thanks to the authors of the Next Startup Weekend http://bit.ly/QS7Ff1 for helping new businesses to suceed.  The other good news is that well established businesses can really take advantage of these principles and techniques. They match the problems I see everyday at my customers’. Even if the many things are still perceived as “crazy” in Italy today, things are changing rapidly. I do love my job.

Annunci

A Market-Driven Manifesto for Product Teams

Indipendentemente dalla metodologia utilizzata per sviluppare prodotti, in particolare hi-tech ma non solo, vi sono dei fattori che non possono essere trascurati per un successo ripetibile del prodotto sul mercato.

Senza entrare nel merito di aree chiave come il management (vedi Management 3.0 di Jurgen Appelo @management30), ecco un manifesto che propongo per l’adesione ai principi di Market-Driven Business – approccio largamente trattato in altri articoli di questo blog.

Perchè scomodare la parola “manifesto”? Perche’ ricorda la nascita di “Agile”, con le dovute proporzioni e differenze. L’intento di questo manifesto e’ creare un esempio di dichiarazione comune di principi, approcci ed intenti ai quali un team intende aderire perche’ ne conosce l’importanza e l’efficacia. Ovviamente deriva dall’ esperienza reale maturata lavorando con teams di prodotto. Qui viene proposto come elemento di discussione, più che di “pubblicazione di un vero manifesto”

A Market-Driven Manifesto for Product Development

Abbiamo valutato e condiviso un approccio e delle metodologie a cui intendiamo aderire in ogni nostra attivita’.
Ascoltare il mercato ed il cliente è una condizione necessaria per il successo di qualsiasi progetto.
Ogni nostra azione è volta alla creazione di valore per il cliente.
Per cui:

  • Non produciamo software senza Requisiti.
  • Non produciamo Requisiti senza Contesto di Business.
  • I Requisiti sono sempre descritti dal punto di vista della “User Persona” e includono sempre il Valore, il Beneficio per il Business:

===

As a (Persona) …I need to ….so that…..(why important, Value)
Acceptance criteria
Priority

===

  • Abbiamo deciso di adottare il metodo dei Requisiti “Diamante” perchè ci permettono di legare il Business con le Specifiche Funzionali:
  • Includono criteri di accettazione, da cui inferire se il requisito è stato soddisfatto.
  • I criteri di accettazione sono sempre nella forma dei Requisiti sopracitata
  • La “User Persona” e le Priorita’ sono derivate dall’interazione costante col cliente, diretta e indiretta.
  • Sappiamo che alcuni requisiti possono cambiare ed è nostro dovere adattarsi.
  • La condivisione di mockups e prototipi  col cliente è il nostro metodo preferito di progettazione e validazione.
  • I dettagli emergono da frequenti interazioni col cliente e dalla profilazione dello User Persona
  • Risolvono un problema end-to-end

===

  • Ascoltiamo sempre il cliente, ma riconosciamo che spesso non sa cosa vuole o che problema ha.
  • È nostro dovere capire il problema che vuole risolvere per poter creare la migliore soluzione ad esso (per cui chiediamo 5 volte “perchè”).
  • Conosciamo la differenza tra “requisiti” e “richieste del cliente” e conosciamo il valore, per un prodotto,  di trovare la soluzione ad un problema pervasivo, invece quello di fare esattamente quello che ci chiede il cliente.

===

  • Ogni meeting inizia con una lista di obiettivi e si conclude con risposte e/o tasks specifici.
  • Anteponiamo sempre meetings in presenza o via voce a discussioni via email.
  • Conduciamo uno standup meeting giornaliero per allinearci e vedere se ci sono elementi bloccanti

Proponenti: (lista)

===

Ora, molti si chiederanno il significato o la definizione di vari termini come “User Persona”, “Diamanti”, tipo di “Requisiti”, etc, e varie domande come “ma chi ce li da ‘sti requisiti? Noi dobbiamo andare avanto col prodotto, non possiamo perdere tempo” oppure “ma chi ci da il contesto di business” etc., etc.

Ma prima di porvi queste domande, provate a vedere se la vostra organizzazione segue questi principi generali. E se avete domande, sono qui per rispondere!

Articoli correlati: