Archivi tag: requisiti

“Request” and “Requirement” – the difference

Sometimes a customer requests a functionality. As an example, because she runs into a problem while interacting with the product. This is more serious when it happens often, when it prevents to accomplish critical or important tasks or when it forces time-consuming and error-prone workarounds.

In this case we are talking about a CRM-Like software, that is a software that every sales people and customer support org uses every day. It could be any enterprise software.

The customer says:

¨I want to sort alerts by sender.  I need to sort by attributes.  Sender must be the first column. How is it possible you cannot sort alerts?
We understand what she says because we know well our product. What we don’t understand however, is WHY that is such a big deal for her. WHAT is the problem she wants to solve in its essence.
Then we interview the customer and we get a totally different perspective
¨Tina gets many alerts but she only needs to know about the ones requiring action on her part so that she does not miss important ones by browsing among hundreds of them, every time”
Can you see the difference?
So, what does this example tell us?
  1. Customer was telling us the solution – We are the experts of the solution, not them.
  2. There could be many possible solutions , some much better than others for both us and the customer.
  3. Customer is the expert of what’s the problem he needs to solve. We need to capture that.
  4. Customer often has a narrow perspective, focused on his problem in a specific day on a specific scenario. It’s normal. We should *never* expect they write requirements for us. They are simply not good at that.
  5. We need to elicit the root cause of the problem. This may require meaningful interviewing skills/methods.

If we don’t do so, let’s not be surprised if we hear things like “The customer said that the feature does not resolve his problem. But we did what he asked for!”

Il CEO e i suoi Diamanti

Un giorno il CEO entra in ufficio tutto spedito e trafelato e dice:

Bisogna sviluppare questo nuovo set di  funzionalita’

altrimenti si continua a soccombere alla concorrenza.

Ora, senza entrare nel merito di tale decisione (che sembra reattiva, guidata dallo stress dei venditori,  che forse ha poco a che fare con la differenziazione, e questi sono tutti cattivi indicatori) supponiamo che sia la cosa giusta da fare. Del resto il CEO e’ il CEO. Vede cose che non tutti vedono, e’ pagato per quello, ci mette la sua reputazione ogni giorno, quindi tanto di cappello, si fa come dice il CEO.

(In questo esempio potrebbe anche essere un COO, CTO, CMO, VP of Marketing, VP of engineering, VP of sales etc.  Beh se e’ il VP of sales e’ un altro brutto segno)

L’input che viene dall’alto e’:

“il prodotto deve far questo e quest’altro.

Basta guardare cosa fa la concorrenza”

Il tutto viene messo un una paginetta o in una breve email. Cosa ci aspettiamo che il CEO ci scriva i requisiti?

Vengono chieste spiegazioni, ma le risposte sono poco utili a comprendere meglio il contesto, o, meglio, il problema da risolvere e per chi. Chi deve sviluppare soluzioni, cioe’ il “come”  si trova spesso a dover indovinare la soluzione giusta. Talvolta ci sorprendiamo a dire  “senti, questo e’ quello che il capo ha chesto, facciamolo cosi’ come e’ scritto, se poi non va peggio per lui!” (se io fossi il CEO diventerei viola a sentire tali pensieri malsani).

Che cosa possiamo fare?

Soluzione (1) Essere persistenti, uscire dall’ufficio e (2) Cristallizzare requisiti a prova di bomba

Il metodo che adotto io in questi casi per (2) e che io chiamo col nome di Diamond Requirements e’ un modo di risolvere il problema in modo completo e finale. Non solo, ma se ci sono errori di visione o di interpretazione, questi tendono a venir fuori in un ambito meno “politico” e piu’ “costruttivo”.

Definizione di Diamond Requirements: uno strato di requisiti ad alto livello, indipendenti dall’implementazione (soluzione, tecnologia, prodotti esistenti) che collega il business ai requisiti funzionali.

Caratteristiche:

  • Solution-free. Esprimono il cosa ed il perche’, non il come
  • Legano il business case con le specifiche funzionali
  • Forzano a chiarire il business case e il perche’ il progetto e’ importante, critico, urgente
  • Forniscono contesto a chi li deve utilizzare (dal posizionamento al test)
  • Dicono cosa fare in modo chiaro ed incontrovertibile
  • Forniscono a tutti un linguaggio comune – dal cliente al venditore
  • Sono piu’ semplici da comunicare, prioritizzare, rendendo ogni decisione piu’ semplice
  • Sono semplici da analizzare per creare soluzioni
  • Sono in grado di fornire stime ragionevolmente accurate (dipende dal progetto)
  • E’ piu facile compararli ad altri requisiti diamanti (magari di un progetto parallelo)
  • Riducono enormememnte il rischio di dover rifare tutto o parti del prodotto

Come si “cristallizzano”? Certo non con la magia o “col tempo”. Gli ingredienti principali sono:

(1) Avere un business case decente

(2) Interviste, Interviste, Interviste (non lunghi meetings interni per dibattere cose che gia’ sappiamo)

  • Intervistare potenziali clienti dell’applicazione (Funzionalita).
  • Chiedere a chi l’ha gia’ se e’ soddisfatto di come e’ fatta (perche’ noi vogliamo farlo 5X meglio della concorrenza!!! Anche se il CEO non ce l’ha detto! Sempre!)
  • Ciiedere che problema risolve e quanto pesa
  • Perche’ e’ importante averla. Che succede se manca.
  • Chiedere alle vendite quanto sono disposte a mettere in piu’ sul forecast se tale funzionalita’ viene messa sul mercato in data X. Se la risposta e’ vaga parlatene col CEO (e’ lui che la chiede per aumentare le vendite).

(2) Sintetizzare in una forma tale che:

  • I requisiti siano descritti dal punto di vista dello “User Persona” (archetipo di utente) e Buyer Persona ove necessario (business case)
  • Includano il beneficio per il business
  • Enfatizzino Intento e Beneficio invece di postulati senza contesto
  • Includono criteri di accettazione, dai cui si capisce facilmente quando il requisito e’ stato soddisfatto

Non e’ facile, anzi, richiede esperienza e “manico” ma risolve tanti problemi in una volta e porta al successo commerciale dell’iniziativa.

Non e’ quello che il CEO voleva?Anzi, se lo facciamo siamo andati anche oltre!!

P.S. Questo e’ esattamente uno dei compiti chiave di un buon Product Manager.

Articoli correlati:   Good Requirements Relate to Business, What is a Requirement?

What is a Requirement?

What is a Requirement?

check this out at http://bit.ly/q2cyZz

Requirement Describe a user (persona) interacting with a product to resolve a problem. The following format has been proven to be very intuitive and effective:

As a <Persona> I want to <Intent> so that <Valuable>

Example 1

Todd wants to share his design (in form of a sub assembly) with suppliers for a prototype run. He need to generate automatically specific file formats (PDF and IGES) from his many 3D CAD models so that he can save time and distraction from his core engineering tasks.

Example 2

As a technical reviewer I want to access the information I am asked to review in an univalent manner. I don’t want to fish for the files need every time, So that I have the required time to review them before submission and save costly errors

Related articles:

Good Requirements Relate to Business

Il CEO ed i suoi diamanti