Archivi tag: diamanti

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?

Good Requirements Relate to Business

Why Requirements are so critical in the software product and project business. How do they relate with the business case?

Have you ever heard of:

  • A Developer complains: “I cannot program to these requirements!”
  • The Product Manager says: “Our developers wrote features that didn’t do what the customer needs!”
  • Developer: “don’t tell me how to do my job”
  • Developer: “This is NOT A REQUIREMENT!”
  • ALL: how much detail is needed?
  • ALL: when do I know when I am done?
  • Who writes Requirements?
  • Who writes specs? What’s the difference?
  • Tech. acct. manager: “It is not my responsibility to write requirements. I am just communicating what the customer told me!”
  • Customer: “this is not what I needed!”

This causes a number of issues:

  • Friction between people, teams and functions make everything harder. When the project is critical and the pressure is very high things often get out of control.
  • Different ways to see the product or the feature objectives and priorities. Misalignment
  • Bad requirements lead to bad prioritization and wrong or very (unnecessarily) risky decisions.
  • Lack of common vocabulary or methodology take the organization to non repeatable success or most often to unsuccessful products.

Examples of why this happens:

  • Requirements are not actionable. Developers have to guess
  • Requirements are too detailed. Developers are told the solution to build (it’s their job and they are they are good at building solutions to problems). But there is no such a thing as a document with all details covered.
  • Developers lack the understanding of the customers need…which makes it harder for them to make informed decisions in building the solution
  • The customer tells the dev team what the solution should be. But Problem Solving is not for them. Explaining us the problem is. We are the experts for finding a solution to the problem (for N customers if you mean to build  a product that sells to a given  market)

The Value of Good Requirements

  • Are actionable
  • Provide a common language for everybody (from dev to customer)
  • Are easier to prioritize (pain, severity, importance etc)
  • Are easier to agree upon when we discuss what we need to do
  • Are easier to compare with others (patterns, use cases)
  • Are easier to analyze and design for
  • Are easier for providing better and faster estimates
  • Reduce the risk of rework (you may not even get to have another shot at it)
  • Are connected to the business

Yes, connected to the business! This is the critical, essential part of all this. What is the impact on business that every technical decision related to the software can have. How to relate a major release success criteria with software engineering tasks and vice versa.

If you are able to master it you will be successful. Making sure you have Good Requirements means you have done most of the work to get to a successful (business) outcome.