“L’erba del vicino è sempre la più verde.”
A inizio millennio croce e delizia di tanti commerciali del mondo IT era la domanda “Ma il tuo prodotto è Java compliant?”.
La cosa stupefacente non era tanto l’innaturale numero di risposte positive quanto l’eterogeneità dei prodotti ai quali si richiedeva una solida amicizia con l’astro nascente dei linguaggi di programmazione.
Sarebbe bello attribuire tale richiesta alla lungimiranza dei manager o a chiare visioni sul futuro di aziende e prodotti, ma in molti casi si trattò solo di seguire la moda del momento. Si deve infatti ammettere che anche gli uomini (e le donne) in grigio che prendono le decisioni importanti sono influenzati dalle tendenze di settore e dal marketing più o meno occulto.
Purtroppo, quando si tratta del settore IT, il problema con le tendenze innovative e affascinanti è che sono spesso classificabili come “alta moda” perché con essa hanno in comune i costi e la difficoltà nell’uso quotidiano.
Inoltre, oggi, ci sono molte più “cose” con cui si deve essere “compliant”: smartphone e tablet, il web in generale e l’HTML5 in particolare, l’open data, la cooperazione applicativa.
D’altra parte le “cose” di moda sono modelli, tecnologie e standard fondamentali per i software moderni; come si può quindi tentare di etichettarli e gestirli il prima possibile come requisiti copiati dal progetto del vicino?
Alcuni segnali di allarme sono:
- il requisito compare senza preavviso ad analisi inoltrata o a sviluppo iniziato;
- la richiesta è spesso introdotta con le parole “non si potrebbe anche…”;
- il requisito diventa molto importante quando cambia la persona che rappresenta uno degli stakeholder.
Si tratta di segnali di allarme perché, quando considerati dalla giusta prospettiva, i requisiti di moda sono elementi di tipo strategico o architetturale che devono integrarsi coerentemente nel modello di prodotto o servizio da cui è nato il progetto software; conseguentemente non possono venire in mente all’improvviso o essere tolti e aggiunti come caratteristiche ozpionali.
C’è poi il bizzarro caso in cui il requisito deve essere presente per rendere il prodotto appetibile dal punto di vista del marketing. Naturalmente occorre fare buon viso a cattivo gioco e includere la caratteristica richiesta, ma è molto utile ricordare il motivo per cui è stata inserita in modo da controllarne l’influenza sulle altre componenti del progetto.