Ho imparato che durante le fasi di sviluppo di un progetto, i quattro aspetti che entrano in gioco sono il budget, il tempo, la qualità e lo scopo la portata (n.d.r.: corretto dopo il commento di Jacopo e comprensione in progress :P). Sono tutte variabili, ma è più comune che budget e tempo rimangano fissi. Lavorando in team, occorre trovare un linguaggio comune per definire i termini della qualità che si vuole, si può oppure ha senso offrire, non solo dal punto di vista tecnologico. Anche questo è un punto su cui ho trovato spesso difficoltà perché, di fronte a un bivio, si preferisce un’applicazione funzionante che una grafica bella (semplifico, per ora). Anche questo sembra ovvio, ma non lo è: funzionante, per uno sviluppatore, potrebbe essere non solo un blocco del sistema ma anche la pulizia del codice, l’accessibilità e non so cos’altro. Spesso mi trovo a “combattere” contro questo approccio talebano sul software. Su questo punto vorrei cercare di alzare lo sguardo andando per un attimo oltre le metodologie.

Terza lezione: la qualità va definita secondo i valori giusti da apportare al progetto

Dato che non sono sviluppatrice, mi fido del fatto che chi scrive codice stia facendo un buon lavoro. Ma a volte temo che ci sia uno sbilanciamento quasi nerd su questo punto, che però l’utente non percepirà mai come valore aggiunto. E magari si chiede all’interaction designer o al grafico di risparmiare sull’interfaccia o sulla presentazione. Basta che funzioni, insomma. Quando questo accade, significa che è di nuovo mancato il dialogo nel team, cioè la definizione della qualità e innovazione giusti da offrire per un determinato progetto. Quando si pianifica, uno degli obiettivi è di far emergere il sapere tacito del cliente ma anche del team. È così che si definiscono chiaramente requisiti e funzioni. O almeno, è la strada giusta per farlo.

Una necessaria conseguenza: anche la comunicazione e grafica vanno assorbite dal team

È ormai chiaro per tutti che lo studio dell’interfaccia è un tesoro per il progetto. Ma dove sono la comunicazione e la grafica? Quando lavoriamo su progetti fortemente orientati alla comunicazione, è d’obbligo mettersi d’accordo con il team per fare in modo che gli sviluppatori non si limitino ai soli aspetti tecnologici. Può sembrare che si chieda di lavorare offrendo una qualità inferiore, ma in realtà si chiede di lavorare offrendo una qualità bilanciata e più opportuna, perché la presentazione impatta sull’emozione e il gradimento visivo o esperienziale di un utente e quindi contribuisce a far funzionare il sistema.

Sono tutti aspetti da chiarire in fase di definizione di un progetto: se si parla di un software, il sistema deve funzionare perfettamente e l’utente deve riuscire a usarlo senza difficoltà; ma su molti progetti web pubblici (e penso anche a molte applicazioni per smartphone), lo scopo (il ROI) non è solo l’esperienza dell’utente ma anche l’obiettivo di business che l’azienda vuole raggiungere, attraverso uno studio accurato della comunicazione.

Riguardando il grafico di Jacopo, noto immediatamente l’assenza dei loop legati al progetto grafico o all’aumento di fedeltà dell’interfaccia: (dalla ux al visual). Il wireframe ha un piccolo loop iniziale e poi vedo molti loop di sviluppo. Io credo che un flusso del genere funzioni molto bene quando si parla di software o comunque di applicazioni molto tecniche. Ma i progetti sui quali lavoro io stanno quasi sempre a metà strada tra la comunicazione e lo sviluppo. La sfida, per me, sarà trovare il modo di integrare il flusso individuato da Jacopo con il mio flusso di lavoro. Cioè come inserire il discorso “comunicazione” (quando c’è) in tutto questo sistema. Questo punto è fortemente sentito dal team con cui lavoro e stiamo cercando di capire come risolverlo.

Non vorrei che l’agile diventasse un rigido paravento di pratiche dietro cui lo sviluppatore si può trincerare, perdendo di vista l’opportunità richiesta dal progetto.

La metodologia agile secondo me ci aiuta a costruire questo terreno comune di fiducia reciproca, avendo rispetto dei nostri ruoli e bilanciandoli in base alle opportunità. In pratica, mi sembra un buon sistema per arrivare insieme a un approccio più maturo sul nostro lavoro. Vorrei che gli sviluppatori smettessero di guardare i visual designer come a fighetti che aggiungono fighetterie inutili. E io non voglio più vedere alcuni sviluppatori come nerd concentrati esclusivamente sul codice.

Breve nota: in questo paragrafo ho volutamente usato il termine “processo” (forse impropriamente) e non metodologia. Mi sembra però che questo territorio sia piuttosto nuovo e quindi non so se esistano parole più corrette. Ad ogni modo processo mi piace, perché mi ricorda un bel commento di Cristiano.

Dopo il CSMA10

Inizio a tirare qualche filo di una ricerca che ho iniziato appena ho potuto muovermi da libera professionista. Non intendo dire che ho trovato il modo giusto di fare le cose, ma penso di aver iniziato a vedere e capire (uso intenzionalmente questi due verbi) quali sono le attività che devo svolgere per portare un valore sensibile al team di sviluppo. È curioso ed è anche un grande classico: nel momento in cui ho iniziato a capire, mi sono chiesta come mai non riuscissi a vedere prima determinate situazioni. Credo che sia dovuto a un insieme di fattori che a un certo punto, semplicemente, maturano. Diventa più chiara la comunicazione con gli altri, al punto che all’improvviso sembra di parlare tutti la stessa lingua. Diventa spontaneo il tentativo di visualizzare o verbalizzare le criticità, guardandole nelle loro componenti atomiche. Perché è lì, quando le spezzetti, le mostri, le avvicini tra loro e chiedi “intendevi fare una cosa del genere?” che ci si accorge che forse manca una parte o avevi dimenticato o valutato male un aspetto. Capisco quanto mi stanno tornando utili tutte le discussioni a cui ho partecipato nell’ultimo anno. Dall’Agile Day 2009, all’IA Summit di Pisa, dal Whymca allo Experience Camp di Lugano fino al seminario DotNet. Sarà che ho iniziato a scrivere questi post mentre sono ancora pervasa dall’atmosfera che si è creata al CSMA10, però provo un sincero senso di gratitudine verso tutte le persone che negli ultimi mesi hanno condiviso tante delle loro esperienze, conoscenze e punti di vista. Mi hanno scritto in privato, mi hanno fatto riflettere prima, durante e dopo un evento, hanno scritto un post sui loro blog.

Abbiamo bisogno gli uni degli altri. Suona banale, ma è così. Mai come quest’anno, da quando parlo direttamente con gli attori che lavorano su un progetto, ho potuto sentire una voglia reale di spiegare le esigenze e risolvere i problemi. E tutto il gruppo esce vincente, Cliente compreso. :)