Fare software: il disallineamento tra ciò che il Cliente chiede e ciò che vuole veramente…

Prendo spunto da un Post vecchio di qualche anno scritto da Joel Sposky sul proprio blog “Joel on Software”.

Il problema più annoso per chi scrive software su commessa è il disallineamento tra ciò che il Cliente chiede e ciò di cui ha bisogno veramente; più è significativo il divario, maggiori saranno i ritardi, le ri-scritture di codice e la frustrazione sia lato-Cliente, sia lato-Fornitore.

Possiamo fare una analisi dei requisiti dettagliatissima, documentata nero su bianco e firmata con il sangue, possiamo incontrarci con il Committente enne-mila volte prima e durante lo sviluppo – nonostante tutto questo (e tanta pazienza da parte nostra), arriveremo alla conclusione che nel bene o nel male il Cliente (accidenti a lui !) non sa ciò che vuole.

Per cercare di ridurre questo fenomeno e di prevenire fastidiose incavolature, i capi progetto più esperti si avvalgono dei Prototipi, preparano cioè le schermate dell’applicazione che si andrà a costruire (utilizzando Visual Basic, PowerPoint e chi più ne ha, più ne metta).

L’idea, meno ingenua di quello che potrebbe sembrare, prevede che le funzionalità verranno poi realizzate in funzione dell’interfaccia utente.

Questo approccio, dicevo, non è affatto male, ma può comunque produrre degli effetti collaterali piuttosto dannosi per il successo del progetto; mi riferisco al fatto che il prototipo non deve essere né troppo bello, né troppo rudimentale.

Se il prototipo è troppo attraente, il Committente dà erroneamente per scontato che l’applicazione sia praticamente pronta. Sentirete affermazioni del tipo: “Bravi ! Ormai il grosso è fatto, ci vediamo lunedì per la consegna dell’applicazione finita…”, e sarà praticamente impossibile convincere il Cliente che servono parecchi altri mesi per realizzare tutte le funzionalità. Se ci provate, darete l’impressione di metterci apposta più tempo per guadagnare di più (anche se il contratto è un “Chiavi in mano”) oppure di essere degli incapaci.

Se invece il prototipo è esteticamente poco curato (dopotutto è solo un prototipo, deve solo rendere l’idea – i font giusti ed i colori accattivanti li lasciamo come ultima cosa, no ?), il Committente maturerà la convinzione che non siete all’altezza di realizzare l’applicazione e che, se anche ci riuscirete, sarà “brutta” (qualsiasi sia il significato di questo termine applicato all’Informatica…).

L’ideale è quindi stare nel mezzo, con un prototipo carino, sufficientemente curato, ma che dia comunque l’idea di essere solo un prototipo – non sottovalutate il fatto di disegnarlo su carta con pennarelli e Post-it.

Un consiglio in più: il prototipo in realtà non deve essere uno solo, perché il Cliente vuole poterci mettere del proprio. Realizzate quindi due o tre demo in cui ciò che cambia non è la sostanza, ma solo all’estetica; in pratica i prototipi si differenziano solo per la disposizione dei bottoni, per il tipo di font utilizzato, per i colori, eccetera. Tutte cose che si possono cambiare nel giro di mezz’ora di lavoro – e che fanno sentire “coinvolto” il Cliente.

Andy Cavallini (andy.cavallini@tin.it)

Una risposta a “Fare software: il disallineamento tra ciò che il Cliente chiede e ciò che vuole veramente…

  1. Michele F.:
    Non è l’unico problema. Spesso l’errore nella cattura delle specifiche inizia a livello di job description e di HR e prosegue a livello di definizione dell’architettura.
    Quasi sempre l’architettura viene scelta in base alla moda del momento, raramente è “progettata” in base ai requisiti, ed è proprio il cliente a congelare l’architettura nelle primissime fasi, di solito dando indicazioni pessime.
    L’architettura viene spesso indicata con un approccio Ivory Tower: una serie di preconcetti idealizzati che qualcun altro dovrà tradurre in risultati.
    Basta richiedere una ottima conoscenza del framework tal dei tali, senza mai chiedersi se il framework tal dei tali sia una scelta valida, ne’ di validare sperimentalmente una scelta. Di performance non si parla quasi mai, se non in rari progetti “illuminati”, e non quando è troppo tardi. Le risorse vengono selezionate quasi esclusivamente sulla base del costo. Alcune soluzioni tecniche viene il dubbio che vengano scelte proprio perché pessime. Sono esempi da manuale molti framework popolari.
    Allo sviluppatore troppo spesso si chiede compliance e troppo raramente di pensare.
    Una volta fatta una scelta strategica a livello architetturale sbagliata, questa si trascina spesso per un decennio di rabberciamenti costosi e frustranti.

    Sergio R.:
    Caro Michele… sante parole! Descrivi una situazione abbastanza comune. Speriamo che presto le scelte dei clienti cambino e diventino più oculate per fare in modo che si debba sempre meno correre in soccorso per riparare, in un tempo infinitesimale, a situazioni disastrose nella speranza di salvare il progetto dall’affondamento.

    Andy C (il sottoscritto):
    Dai Vs. commenti, capisco ancora di più che la problematica che ho affrontato è proprio famigerata…!
    “Deliverare” un’applicazione software dovrebbe essere (teoricamente) molto più semplice che sviluppare/ingegnerizzare un prodotto: non ci sono stampi da rifare venti volte, gli algoritmi hanno comportamenti più prevedibili di molti materiali, la documentazione è piuttosto agevole, ecc., ecc.
    Eppure, quando va bene, si sfora sempre nei tempi e nei costi – quando va male, si butta tutto via e si tira l’acqua…

    Sergio R.:
    La mia esperienza è anche che molti cercano di reinventare la ruota mentre, ad esempio, pochi prendono in considerazione prodotti open già esistenti che richiederebbero solo un certo numero di personalizzazioni per adeguarli alle proprie esigenze.
    Riguardo alle risorse scelte solo in base a considerazioni economiche, questo è assolutamente vero e molto spesso vengo interpellato per chiudere falle causate da questi fantasmagorici guru a basso costo. I clienti dovrebbero capire che il costo di una risorsa è legato anche all’impegno e al lavoro di crescita professionale personale che ogni consulente che crede nel suo lavoro deve fare e questo è giusto che venga riconosciuto. I guru a basso costo non esistono e un curriculum ricco ad un costo basso inevitabilmente dovrebbe fare nascere qualche domanda e mettere sull’attenti. Ma, soprattutto di questi tempi, questo dettaglio non viene considerato.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...