Joel on Software

Joel on Software   Joel sul software

 

Altri articoli da "Joel on Software" in italiano

Altri articoli da "Joel on Software" in inglese

Scrivi all'autore (solo in inglese)

JOEL E IL SOFTWARE

 

Il segreto dell'Iceberg, Rivelato


Di Joel Spolsky
Tradotto da Marco Menardi
Redatto da Fernando Marotta
13 Febbraio 2002

"Non capisco cosa vi sia che non va nella mia squadra di sviluppatori", pensa fra sé e sé il presidente dell'azienda. "Le cose andavano così bene quando abbiamo iniziato questo progetto. Per le prime due settimane, lavoravano coma matti e hanno prodotto un ottimo prototipo funzionante. Ma da allora le cose sembrano essere rallentate fino ad avere un passo da lumaca. Non stanno più lavorando intensamente." Sceglie tra le sue mazze da golf un Driver Callaway Titanium; ordina al cameriere una limonata fresca. "Forse se licenzio un paio di lumaconi fra loro questo metterà agli altri il fuoco!"

Nel frattempo, naturalmente, la squadra di sviluppo non ha affatto idea che qualcosa vada storto. Ed in effetti, nulla sta andando storto. Essi sono allineati con i tempi previsti nel calendario di sviluppo.

Non fate che questo vi accada! Sto per svelarvi un piccolo segreto sul modo di pensare di chi fa parte del management non tecnico che ti renderà la vita molto più facile. In verità è una cosa assai semplice. Una volta che conoscerete il mio segreto, non avrete più problemi a lavorare con i manager non tecnici (a meno che non vi mettiate a discutere sul coefficiente di restituzione delle loro mazze da golf).

E' piuttosto evidente che i programmatori parlano una lingua, e i manager un'altra. Ho riflettuto sui problemi di comunicazione nella gestione del software per molto tempo, perché mi è assai chiaro che il potere e i benefici arrivano a quei rari individui che sanno come far comunicare fra loro i Programmatori ed i Manager.

[Image]

Sin da quando ho iniziato a lavorare nell'industria del software, quasi tutto il software sul quale ho lavorato è stato quello che può essere definito software "speculativo". Il che significa che il software non viene realizzato per un cliente in particolare -- viene realizzato nella speranza che milioni di persone lo compreranno. Ma molti sviluppatori di software non hanno questo lusso. Può trattarsi di consulenti che sviluppano un progetto per un singolo cliente, o possono essere programmatori dipendenti che lavorano su un complicato aggeggio aziendale per la Contabilità (o qualunque cosa voi programmatori interni facciate; per me è un grosso mistero).

Avete mai notato che in questi progetti fatti su misura, la singola causa di ritardo, fallimento, e generale depressione che si ritrova più comunemente può essere ricondotta, generalmente, a: "il (inserire un'imprecazione qui) cliente non sapeva bene quello che voleva"?

Qui riporto tre versioni della stessa patologia:

  1. "Lo stramaledetto cliente continuava a cambiare idea. All'inizio voleva una soluzione Client/Server. Dopo ha letto qualcosa sull'XML nella rivista omaggio "Vola con la Delta Airlines" e ha deciso che doveva avere l'XML. Ora stiamo riscrivendo tutto in modo da poter usare una flotta di piccoli Lego Mindstorms Robot."

  2. "L'avevamo realizzato esattamente come lo volevano. Il contratto specificava tutto fino nei minimi dettagli. Abbiamo consegnato esattamente quello che c'era scritto nel contratto. Ma quando lo abbiamo consegnato, sono sembrati alquanto delusi"

  3. "In nostro miserabile addetto alle vendita si è accordato su un contratto a prezzo fisso per realizzare quello che era semplicemente non specificato, e l'avvocato del cliente è stato abbastanza accorto per inserire una clausola nel contratto per la quale non erano tenuti a pagarci fino a quando il prodotto non fosse 'accettabile per il cliente', così abbiamo dovuto dedicare a quel progetto una squadra di nove sviluppatori per due anni e siamo stati pagati solo 800 dollari."

Se c'è una cosa che ogni consulente alle prime armi deve avere conficcato bene in testa con un martello pneumatico è proprio questa: I Clienti Non Sanno Quello che Vogliono. Smettetela di Aspettarvi che i Clienti Sappiano quello che Vogliono . Semplicemente non accadrà mai. Rinunciateci.

Invece, presupponete di dover realizzare qualcosa in ogni caso, e che al cliente dovrà piacere, ma che sarà anche un po' meravigliato. VOI dovete fare la ricerca. VOI dovete immaginare una soluzione che risolva in un modo gradevole il problema del cliente.

Mettitevi nei suoi panni. Immaginate di aver guadagnato 100.000.000 di Dollari vendendo la vostra ditta a Yahoo!, e di aver deciso che è venuto il tempo di rinnovare la cucina. Quindi assumete un architetto esperto con l'incarico di realizzarla "fantastica come quella del cuoco Vissani". Non avete la minima idea di come farlo. Non sapete di volere un fornello Viking e un frigorifero Subzero – queste non sono parole del vostro vocabolario. Volete che l'architetto realizzi qualcosa di bello, ed è per questo che l'avete assunto.

I fautori dell'Extreme Programming sostengono che la soluzione a questo è di portare il cliente nella stanza e coinvolgerlo nella progettazione per ogni passo dello sviluppo, come fosse un membro egli stesso della squadra degli sviluppatori. Questo è, credo, un po' troppo "estremo". E' come se il mio architetto mi avesse mostrato il progetto della mia cucina mentre lo realizzava e mi avesse chiesto di fornirgli indicazioni per ogni piccolo dettaglio. Per me questo è assai noioso, e se avessi voluto essere un architetto lo sarei diventato.

In ogni caso, in realtà non volete un cliente nella squadra, o no? Il dipendente che verrà incaricato dall'azienda di lavorare con i programmatori è assai probabile si riveli essere qualche povero membro del reparto "conti pagabili", mandato da voi in quanto il lavoratore più lento in assoluto e la cui assenza verrà a stento notata. E passerete tutto il vostro tempo di progettazione spiegandovi mediante l'uso di parole con una sola sillaba.

Presupponete che i vostri clienti non sappiano quello che vogliono. Progettatelo da solo, basandovi sulla vostra comprensione del dominio del problema. Se avete bisogno di passare del tempo imparando qualcosa sul dominio del problema, o se avete bisogno di un esperto in quel campo specifico, va bene, ma la progettazione del software è compito vostro. Se vi documentate bene sul problema e realizzate una buona interfaccia utente, il cliente sarà soddisfatto.

Ora, avevo promesso di svelarvi un segreto sulla traduzione fra il linguaggio dei clienti del tuo programma (o dei manager non tecnici) e quello dei programmatori.

Sapete che un iceberg è sommerso per il 90%? Bene, la maggior parte del software è così – c'è una graziosa interfaccia utente che prende circa il 10% del lavoro, ed il 90% del lavoro di programmazione è nascosto. E se consideriamo che almeno metà del tempo è impiegato nel rimuovere bug, l'interfaccia utente prende solo il 5% del lavoro complessivo. E se ci limitiamo alla parte visuale dell'interfaccia utente, i pixel, quello che si vede in PowerPoint, allora bisogna stimare qualcosa meno dell'1%.

Questo non è il segreto. Il segreto è che le Persone che Non Sono Programmatori Questo Non lo Capiscono.

Ci sono alcuni corollari al Segreto dell'Iceberg molto, molto importanti.

Corollario Improtante Uno. Se mostrate ad un non-programmatore una schermata che è il 90% peggiore, egli penserà che il programma sia il 90% peggiore.

Imparai questa lezione come consulente, quando feci una demo di un importante progetto basato sul web al gruppo esecutivo di un cliente. Il progetto aveva quasi il 100% del codice completo. Eravamo ancora in attesa che chi si occupava dell'aspetto grafico decidesse il font ed il colore da usare, e disegnasse delle belle tab 3-D. Nell'attesa, avevamo usato del font semplicissimo ed il bianco e nero, c'erano dei brutti spazi inutilizzati nella schermata, insomma li tutto non si presentava molto bene. Ma il 100% della funzionalità era stata realizzata e faceva alcune cose davvero sorprendenti.
Cosa accadde durante la dimostrazione? Il cliente passò l'intero incontro brontolando sull'aspetto grafico della schermata. Non parlavano nemmeno dell'interfaccia utente. Semplicemente l'aspetto grafico. "semplicemente non sembra scorrevole", si lamentò il project manager. Questo è tutto quanto poterono pensare sull'argomento. Noi non riuscimmo a portarli a pensare alla funzionalità del prodotto. Naturalmente, sistemare l'aspetto grafico prese circa un giorno. Fu per lo più come se essi avessero pensato di aver assunto dei pittori.

Corollario Importante Due. Se fate vedere ad un non-programmatore una schermata che ha un'interfaccia utente che è perfetta quasi al 100%, egli crederà che il programma sia per lo più terminato.

Le persone che non sono programmatori semplicemente guardano lo schermo e vedono alcuni pixel. E sei i pixel appaiono come propri di un programma che fa qualcosa, essi pensano "o caspita, quanto impegno ci dovrà mai essere per farlo davvero funzionare?"
Il grande rischio qui è che se prototipate prima l'interfaccia utente, presumibilmente potrete avere qualche incontro con il cliente per mostrargliela, e dopo tutti penseranno che il lavoro è quasi completato. E poi, quando passerete l'anno seguente lavorando "a quello che sta sotto", per dirla in questi termini, nessuno davvero vedrà quello che state facendo e penseranno che non stiate facendo niente.

Corollario Importante Tre. La dotcom che ha il sito web bello e luccicante e circa quattro pagine di contenuto riceverà una valutazione maggiore della dotcom con una funzionalità altissima e con 3700 anni di archivio in linea ma con uno sfondo grigio

Oh, aspettate, ora le dotcom non valgono più nulla. Non importa.

Corollario Importante Quattro. Quando motivi politici richiedono che vari manager non tecnici o clienti "sottoscrivano" un progetto, date loro alcune versioni della parte grafica fra cui scegliere.

Cambiate il posizionamento di alcune cose, cambiate il look and feel e i font, spostate il logo e ingranditelo o rimpicciolitelo. Fateli sentire importanti impegnandoli in aspetti non cruciali di semplice cosmesi. Qui non possono fare molto danno sul vostro calendario di sviluppo. Un buon arredatore dà costantemente ai suoi clienti campioni, strisce di colore e altre cose fra le quali scegliere. Ma egli non si metterà mai a discutere con il cliente la collocazione della lavastoviglie. Va vicino al lavello, non importa cosa voglia il cliente. Non ha senso sprecare tempo argomentando sul dove vada la lavastoviglie, deve andare vicino al lavandino, non si solleva nemmeno l'argomento, si lascia che i clienti usino la loro indole di progettisti per fare alcune cose innocue come cambiare idea 200 volte se usare per il piano da lavoro Granito Italiano o Mattonelle Messicane o Legno Norvegese per tavole da macellaio.
Corollario Importante Cinque. Quando fate una demo, l'unica cosa che davvero conta sono le videate. Fate che siano fantastiche al 100%.
Non pensate, nemmeno per un istante, che potete evitare ciò chiedendo a chiunque vi capiti davanti di immaginare quanto bello apparirà poi. Non crediate che guardino alla funzionalità. Non lo fanno. Vogliono vedere bei pixel.
Steve Jobs lo sa. Oh ragazzi se lo sa. I progettisti alla Apple hanno imparato a fare le cose per ottenere meravigliose videate, come le meravigliose nuove icone 1024x1024 nella barra delle applicazioni, anche se sprecano risorse preziose. E la folla di desktop per Linux impazzisce per cose come finestre xterm semitrasparenti, che vanno benissimo per belle schermate ma sono spesso fastidiose nell'uso. Ogniqualvolta Gnome o KDE annunciano una nuova release, io vado direttamente alle videate ed esclamo: "oh, hanno cambiato il pianeta dello sfondo da Giove a Saturno. Fantastico!". Non importa cosa abbiano davvero fatto.

Ricordate il presidente dell'azienda all'inizio di questo articolo? Era insoddisfatto perché il suo team gli aveva fatto subito vedere fantastiche videate fatte con PowerPoint -- simulazioni, create con Photoshop, nemmeno con il VB. Ed ora che stanno effettivamente realizzando l'applicazione che sta dietro la facciata, sembra che non stiano facendo nulla.

Cosa si può fare per questa situazione? Una volta che avete capito il Segreto dell'Iceberg, è facile capire come cavarsela. Fate vostro il concetto che ogni demo che fate in una stanza buia con un proiettore non sarà altro che a proposito dei pixels. Se potete, realizzate l'interfaccia utente in modo tale che le parti incomplete appaiano incomplete. Per esempio, usate scarabocchi per le icone della toolbar fino a quando la funzionalità non sia effettivamente implementata. Se state realizzando il vostro servizio web, potrete voler considerare perfino di lasciare fuori dalla home page certe funzionalità fino a quando non siano realizzate. In questo modo la gente può osservare la home page passare da 3 a 20 comandi man nano che più cose sono realizzate.

Più importante ancora, accertatevi di controllare cosa pensa la gente sul calendario di sviluppo. Rendete disponibile un calendario di sviluppo dettagliato in formato Excel. Ogni settimana, spedite e-mail di auto-congratulazione a proposito di come vi siete spostati dal 32% di progetto completato al 35% e che siete in orario per consegnare il 25 Dicembre. Accertatevi che i fatti concreti prevalgano su ogni pensiero che ponga in discussione se il progetto sta procedendo alla giusta velocità. E non permettete al vostro capo di usare Driver Callaway Titanium, non mi interessa quanto volete che vinca, la USGA le ha bandite e non è corretto usarle.



Traduzione dell'articolo originale inglese dal titolo The Iceberg Secret, Revealed  

Joel Spolsky è il fondatore della Fog Creek Software, una piccola ditta di software a New York. Laureato alla Università di Yale, ha lavorato come programmatore e manager presso Microsoft, Viacom e Juno.


I contenuti di queste pagine esprimono opinioni personali dell'autore.
I contenuti sono Copyright  ©1999-2005 di Joel Spolsky. Tutti i diritti riservati.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky