Alberto Mucignat

Negli ultimi giorni sto lavorando a un progetto con Jacopo e stiamo applicando un processo di sviluppo totalmente agile. Abbiamo discusso parecchio su come pianificare le priorità delle cose da fare e abbiamo sostanzialmente evidenziato due modelli che voglio condividere.



In questo modello, vengono fatte per prime le funzionalità ad alto valore e basso effort. Successivamente le funzionalità ad alto valore ed alto effort e per ultime le funzionalità a basso valore e basso effort.

E' utile quando si vogliono rilasciare velocemente delle nuove funzionalità, ma ha il rischio che funzionalità particolarmente complicate (ad alto effort, quindi anche a maggior rischio) comportino problemi quando è troppo tardi per porvi rimedio.

In realtà è più sicuro avere il seguente approccio.



Facendo prima le funzionalità ad alto valore ed alto effort, si scoprono subito i problemi e si lasciano le funzionalità a basso effort per tutta la seconda parte della realizzazione. Come dire: le rogne prima le affronti, meglio è.

Da notare che in entrambi i casi le funzionalità a basso valore e alto effort non dovrebbero essere fatte: non sono essenziali e costano tanto. Un buon motivo che aiuta il cliente a scegliere cosa non fare.

Può sembrare un modello semplice, ma spesso è complicato stabilire le priorità di un progetto e fare una valutazione dell'effort per ogni singola funzionalità.

La mancanza di tempo è la scusa più comune, una giustificazione più che altro verso se stessi. Con le metodologie agili esiste una facile pratica chiamata planning game che aiuta molto.

In alternativa, si rischia di considerare che tutto sia importante e tutto sia facile, mentre non è mai così.

Comunque questo è solo il primo macro-livello del modello di pianificazione che stiamo costruendo, ma fornisce le basi per una discussione iniziale.

Tu cosa ne pensi? Hai mai pianificato il lavoro sulla base del valore e del costo delle feature? Che problemi/benefit hai avuto?

Ne ho scritto già due volte. Oggi segnalo un bel contributo di Sett Gottlieb, che è forse indirizzato a clienti molto enterprise.

Ultimamente avrete capito che mi piace parlare più di content management framework, che un amico ha ribattezzato publishing framework. Però il mercato dei cms non è per niente morto.

Comunque, trovo molto interessanti i punti 6, 7 e 8 di Seth.

Per prima cosa, quando avete fatto una lista di fornitori, ingaggiate una relazione con le aziende, in modo da capire non solo quali feature differenziano i prodotti dagli altri, ma anche come funziona il loro approccio. Non accontentatevi di documenti descrittivi, insomma, parlate con le aziende e cercate di capire come lavorano, come sviluppano, ecc. Soprattutto, cercate di capire se la metodologia va bene per voi.

Inoltre, fatevi fare dei prototipi e testateli, perchè non è detto che una soluzione ultra-professionale si adatti a quello che serve a voi. Questa cosa è molto intelligente, specie se pensiamo che molti prodotti vengono comparati solo in base a funzionalità e prezzo, ma poi vengono presi un po' a scatola chiusa.

Infine, provate a progettare un'implementazione. Serve per molte ottime ragioni, tra cui aggiungo il fatto di capire qual'è la portata dei cambiamenti, cosa comportano, come affrontarli, ecc.

Lettura utile per tutti, anche se credo che questi consigli vadano bene per progetti la cui scelta di un cms sia strategica per l'impegno economico e gestionale che richiede. Penso probabilmente a grossi progetti come mega-portali istituzionali, grosse intranet o portali di turismo con budget milionario...

Mi ero quasi perso questa perla di Keith Robertson, che vale la pena leggere anche perchè è applicabile a qualunque progetto.

Tra le altre, trovo infinitamente giusta la frase:

The “problems” with almost any process start and end with people.

Ogni volta che mi sono trovato davanti ad un problema, spesso si trattava di un problema relativo alle persone. Una delle seguenti:
- alcuni non si parlavano
- altri si parlavano, ma non si capivano
- molte volte non avevano chiari in mente gli obiettivi
- non erano abbastanza invogliati a prendere iniziative
- non si sentivano responsabilizzati
- ecc

Morale: quando ti trovi di fronte a un problema, non chiederti cosa hai sbagliato. Chiediti chi non sta facendo la cosa giusta e perchè.

Certo, potresti anche scoprire che il problema sei tu. Cosa fare in questi casi? Ne avevo già parlato "anni fa" in un post molto zen. Credo si debba cercare di "spersonalizzarsi" e fare un passo indietro. Ci vuole umiltà, insomma. Eggià.

Magnifico keynote finale di Rashmi Sinha all'IA Summit di Las Vegas, in cui parla di come lo sviluppo di SlideShare sia stato fatto utilizzando una metodologia agile anzichè il tradizionale modello UX.

Mostrare i primi prototipi dell'applicazione agli utenti non mi dice niente sulla "sociabilità". Quindi, l'unico modo per sapere esattamente se SlideShare stava effettivamente catturando gli utenti e il loro interesse era di mettere online una prima versione e lasciare che le persone ci interagissero.

Riassumo anche i punti chiave della sua presentazione, con un mio breve commento (mutuato dalle slide di Rashni), anche perchè molte di queste cose le ho sperimentate di persona.

1. L'alpha è la prima reazione

Le versioni alpha vengono solitamente rilasciate a un gruppo ristretto di amici, esperti, ecc. Serve a tastare il polso del mercato, a fiutare se l'embrione dell'idea che abbiamo in mente è la scelta giusta.

2. La beta è il sondaggio di mercato

Si inizia ad allargare la base utenti e a raccogliere un feedback più strutturato che serva a dare direzione allo sviluppo.

3. Non hai bisogno dei personaggi, entra in conversazione con gli utenti

La UX tradizionale vuole che si creino dei profili di utenti (chiamati personas o personaggi), che servono come utente-tipo del nostro sistema. È come immaginarsi gli utenti che lo utilizzeranno e cercare di pensare cosa vogliono.
In questo caso invece, gli utenti li conosciamo per nome e cognome, perchè ci scrivono ogni giorno e vorrebbero visitare il nostro ufficio. A me capitava realmente, ai tempi di studenti.it.
Bisogna quindi cercare di conversare con questi utenti, rispondendo personalmente alle email (a conferma di questo, posso dire che Rashmi ha risposto di persona ad una mia mail di feedback su SlideShare). Monitorare i blog e sottoscrivere gli rss. Il servizio clienti può essere usato per le ricerche sugli utenti.

4. Lancia prima, rifinisci dopo

Non fare troppa analisi. Prendi gli esempi migliori e usa l'intuizione. Anche la fantasia è importante. Rilascia, rispondi, rifinisci.

5. Ha qualcosa a che fare con i siti sociali

Il "design sociale" è diverso dal fare design per il singolo individuo. Bisogna far interagire le persone, dargli modo di seguirsi a vicenda. Bisogna usare una sensibilità verso le funzioni sociali, piuttosto che verso le singole esigenze.

6. Utilizza una shadow app

È importante avere una dashboard per controllare "come va il sistema". Quanti utenti si sono iscritti, ma non hanno mai utilizzato il sistema? Quanti sono attivi, quanti passivi? Quanti hanno completato le loro informazioni? Ci sono molte altre metriche che si possono tenere sotto controllo. Questo è più facile dei log e più semplice dei test con gli utenti. Soprattutto, tutto il team fa riferimento a queste metriche nel valutare il lavoro complessivo.

7. È cruciale il ruolo di sviluppatore-designer

Credo che Rashmi abbia suggerito il fatto di utilizzare degli sviluppatori che abbiano anche una sensibilità al design. Questa cosa è molto importante, poichè consente di avere un design grezzo che è comunque accettabile. Un messaggio agli sviluppatori: cercate di aumentare la vostra sensibilità al design.

8. Non investire troppo in visual design

Lascia che gli utenti personalizzino il loro spazio. Il look grezzo va bene, anche perchè lascia agli utenti un margine di personalizzazione. Se pensate a come vengono personalizzati i temi dei blog, i menù laterali, ecc, capite quello che significa. Ricordo che nei blog di giovani.it, come per myspace, gli utenti cercavano sempre di distinguere il loro spazio da quello degli altri. Specialmente i giovani hanno molto bisogno di distinguersi dagli altri.

9. Presta attenzione alla semplicità tecnica

Credo che la semplicità tecnica sia una regola zen. I sistemi devono essere a prova di newbie. Secondo me, il massimo della complicatezza deve essere il copia&incolla.

10. Rendi l'applicazione più veloce

Non si parla solo di velocità dell'applicazione. Rendi veloce la registrazione, il primo utilizzo del sistema. Rendi veloci i passaggi di configurazione, snellisci le procedure quanto puoi. Refactoring di usabilità, per velocizzare l'utilizzo del sistema.

Conclusioni

Credo che questa esperienza sia importante per tutti noi che spesso ci troviamo a sviluppare applicazioni web sociali. E siamo quindi di fronte anche ad una approccio diverso dalle classiche metodologie di progettazione. Non si parla di utente ma di utenti al plurale. Non si progettano solo interazioni col sistema, ma interazioni tra utenti.

Grazie al link del post precedente, scopro anche questo Collaborative game manifesto for software development:

Lo sviluppo software è una serie di giochi cooperativi di invenzione e comunicazione, con risorse limitate e finalizzati ad un obiettivo. L'obiettivo primario di ogni gioco è la produzione e la consegna di un sistema software; ciò che rimane alla fine del gioco è un insieme di note, utilizzabili per assistere i giocatori del gioco successivo. Le persone utilizzano note e appunti per ricordare, trarre indicazioni e comunicare tra loro, allo scopo di passare alla mossa successiva del gioco. Il gioco successivo è la variazione del sistema, oppure la creazione di un sistema contiguo. Ogni gioco ha quindi come obiettivo secondario quello di conseguire una posizione vantaggiosa per il gioco successivo. Poiché ogni gioco si svolge a risorse limitate, l'obiettivo primario e quello secondario competono tra loro per le risorse disponibili.

Utile, in generale, anche per altri tipi di progetti. Deliverables è la parola chiave del gioco. Come strumenti, vedo bene il wiki. Prima o poi dovrei provare a impostarlo in questo modo.

Questa cosa del gioco, poi, viene fuori spesso ultimamente. Ne parlano continuamente gli anglofoni quando si tratta di fare focus group o altre ammucchiate lavorative.

Se ci penso, durante un recente card sorting estenuante mi sono ritrovato a dire ai partecipanti che dovevano pensare che era un gioco, cercare di pensarlo come uno svago dal loro solito tran-tran quotidiano. E ha funzionato, nonstante lo stress.

Lavorare giocando, lavorare divertendosi. Proviamoci tutti un pochino, dai.

Sembra la storia della mia vita. Ma Software projects as rock climbing non l'avevo mai pensato, a dire il vero. Per me, che l'arrampicata è una metafora che si può applicare a tutte le cose della vita. Solo un piccolo appunto:

Rock climbers are fond of saying that climbing, done properly, is less dangerous than driving a car.

Io dico invece che si rischia di più andare con lo scooter in tangenziale

Grazie a Ludo per il link.

Da qualche tempo sto testando ActiveCollab, un software web per la gestione di progetti, scritto in PHP. Interfaccia pulita e chiara, facile da usare e abbastanza completo. Unica pecca, è comunque un software ancora troppo feature-based, piuttosto che user-based.

Ultimamente c'è stata parecchia discussione sulle future features, a cui ho partecipato entusiasta, proprio perchè ritengo che la base di partenza sia molto interessante per fare qualcosa di bello.

Forse a causa di questo palpabile interesse da parte di molti, lo sviluppatore a capo del progetto ha deciso di dare una sterzata commerciale non da poco:

activeCollab 1.0 and future core development will be developed exclusively by company that I started and community will be able to contribute by developing plugins, themes and translations

Copione già visto. È sucecsso senza problemi anche per molti altri progetti (lo stesso linguaggio PHP, ad esempio). Però qualche dubbio è lecito, specie dopo le repliche alle critiche della community. Alcune strane risposte mi hanno infatti alzato un warning istintivo.

Sicuramente questi modelli di business sono delicati da gestire, soprattutto all'inizio.

Nel posto più cool del pianeta si è appena concluso il MXSF 2007 e Peter ha sintetizzato il tutto in due frasi.

Leggendo anche gli altri interventi su MX, mi rendo conto che il managing experience è la cosa più vicina al lavoro che sto facendo oggi. Mi sento sulla strada giusta, ma il cammino è ancora lungo.

Ok, non sono Picasso, ma nei miei prossimi preventivi inserirò questa piccola postilla:

Legend has it that Pablo Picasso was sketching in the park when a bold woman approached him.
"It's you -- Picasso, the great artist! Oh, you must sketch my portrait! I insist."
So Picasso agreed to sketch her. After studying her for a moment, he used a single pencil stroke to create her portrait. He handed the women his work of art.
"It's perfect!" she gushed. "You managed to capture my essence with one stroke, in one moment. Thank you! How much do I owe you?"
"Five thousand dollars," the artist replied.
"B-b-but, what?" the woman sputtered. "How could you want so much money for this picture? It only took you a second to draw it!"
To which Picasso responded, "Madame, it took me my entire life."

Da leggere anche l'articolo a monte, che confronta le due filosofie di quotazione di un progetto (a ore o a progetto):

- Charging by the hour is a good option for short-term projects with specific goals.
- When you're offered a long-term project with clearly defined goals, you should charge by the project.

(Via PV)

Ieri sono arrivato al classico problema: come posso strutturare la navigazione conoscendo poco o niente i contenuti?

La risposta, manco a dirlo, viene dal solito polarbear: contenuti e architettura evolvono assieme, man mano che la fase di ricerca e analisi procedono a iterazioni.

Come dire che -in generale- quando vi trovate ad affrontare un problema di questo tipo, la risposta è: ricerca, analisi, iterazione. Piano piano ti trovi l'uovo e la gallina pronti sul piatto.

Certo, non è facile la visualizzazione di un percorso così poco lineare, ma questo è il punto: anche le "metodologie lineari" hanno delle fasi di iterazione (le cosiddette sovrapposizioni tra due diverse fasi sequenziali), altrimenti non funzionano.