Un idea: dalla nascita a online in 3 settimane

Ladies First è un progetto di community orientata alle donne sportive che trova i suoi spazi sia online (attraverso il sito con degli strumenti di networking e comunicazione) che offline attraverso cene, feste ed eventi in occasione di regate. Il progetto è molto particolare poichè cerca di mantenere una community verticale ed esclusiva, attraverso un continuo contatto con gli utenti con continui passaggi on e offline.

Il progetto si è sviluppato con l’imprenditore che ipotizzava inizialmente di creare un sito “patch” per gli eventi di quest’anno nell’arco di tre settimane. In parallelo sviluppare la community completa (ancora tutta da definire e senza nessuna idea realmente stabile) nell’arco di qualche mese. In seguito fare lo switch tra le due.

Dopo una discussione tra i vari team e responsabili Sketchin/Ideato abbiamo lanciato la controproposta, sviluppare il servizio online completamente custom (con symfony) attraverso delle iterazioni agili orientate alla produzione (ciò che avevamo parzialmente comprovato in agile UXD a livello di service design) rilasciando la prima versione produttiva dopo tre settimane.

Tralasciando dettagli operativi di produzione il tempo dato alla progettazione globale è stato di 5 giorni lavorativi di un intero team di 4 persone su tre micro-iterazioni (una per definire cosa, e due per il come funzionale e visuale) mentre lo sviluppo si è mosso su due iterazioni di una settimana l’una.

L’eccezionale risultato ottenuto è che a tre settimane di distanza dalla prima bozza di idea c’era un servizio online basilare ma completamente funzionante ed inoltre avevamo una visibilità di rotta sul come si sarebbe andato a sviluppare nel tempo attraverso le successive iterazioni.

In questo modo si sono potuti osservare istantaneamente i comportamenti degli utenti e la verifica del modello di business del progetto, feedback importantissimi per portare rapidamente adeguamenti ed evitare un fallimento in partenza.

Purtroppo vi sono anche delle note negative che sono emerse da questa estrema efficienza ed efficacia nel progetto, in particolare la capacità e possibilità di includere tutti gli stakeholders a scopo di definizione e review nell’attività di progettazione e produzione non è stato brillante, il che ha portato ad una serie di feedback di cambiamento ad iterazione chiusa.

Altra nota negativa e l’insieme di problematiche di comunicazione e di supporto che si creano a tali ritmi se sussiste una distanza fisica tra i team. Quello che abbiamo vissuto sulla nostra pelle è la dimostrazione che con un tale approccio il team deve essere allocato esclusivamente sul progetto per tutto il periodo dell’iterazione e soprattutto l’importanza di stare nello stesso luogo fisico.

Ultima nota negativa è il livello di pressione e stress che si accumula sul team che al termine dell’iterazione richiede fisicamente un momento di distacco e di relax.

Sulle nuove iterazioni e progetti stiamo apportanto ulteriori modifiche all’approccio per ovviare anche a queste problematiche ma in generale mi sembra di intravvedere una via concreta con cui l’agile si possa incastrare bene tra le esigenze di business, sviluppo e design.

  1. Molto interessante.

    Ho apprezzato soprattutto il fatto che hai evidenziato in modo trasparenze anche gli aspetti negativi.

  2. Claudio sono fondamentali se si vuole riflettere tutti assieme sulle possibili vie per migliorare il processo di design agile

  3. Una domanda Luca, mi sorge sempre, e poche volte vedo la risposta:
    il costo, per il cliente e per voi.

    Perchè allocare 2 team, di 2 aziende diverse per 5/10g su un solo progetto e soprattutto nello steso luogo, ha un impatto considerevole … o mi sbaglio ?

  4. Emaaaa considera che questa volta non abbiamo fatto l’allocazione delle risorse nello stesso luogo (era una delle cose che abbiamo scoperto si sarebbe dovuta fare).

    Dal punto di vista del costo esatto non posso dare delle cifre esatte pubblicamente ma diciamo che sicuramente è sopra il costo medio delle piccole agenzie che fanno siti per 5-10’000 euro ma è ancora in quei termini competitivi che vanno a rappresentare un mercato di alto livello non ancora soggetto a speculazioni varie.

    Come hai notato il costo è alto anche per le due aziende stesse perchè l’allocazione blocca tutte le risorse per più di metà mese e sono risorse che hanno un costo giornaliero interno abbastanza alto.

  5. > @emaaa: Perchè allocare 2 team, di 2 aziende diverse per 5/10g su un solo progetto e soprattutto nello steso luogo, ha un impatto considerevole … o mi sbaglio ?

    Dopo questa esperienza penso che l’allocazione di due team nello stesso luogo sia molto utile nella prima fase di inquadramento del progetto.

    In questo periodo i team creeranno metriche, procedure ed un linguaggio comune a quello del cliente e potranno lavorare, in seguito, più affiatati anche se da lontano. Questo IMHO è indispensabile per progetti di ampio respiro che non finiscono in un sito dopo 1 mese di lavoro, ma che possono prevedere anche piccoli stravolgimenti a causa del cambiamento di mercato o di business del cliente stesso.

    In pratica investi un po’ di più all’inizio per poi avere un team che rende di più nel medio-lungo termine.

  6. clà

    non sottovaluterei l’impatto dello stress sulle persone, perchè il tono di voce dell’intervento POTREBBE sembrare troppo simile a quello di quel gran bastardo di Ardito Desio (scusate la digressione in anticipo) ai tempi dell'”impresa” (sic) del K2: il “materiale umano” (a ri-sic).
    il costo per il SSN E per la persona – di un ictus o di una riabilitazione post infarto miocardico è molto più alto, per dire, di un progetto web pur se innovativo e via dicendo.
    (lo dice il mio capo e se lo dice lui…)
    altra cosa: il codice generato non rende giustizia…

  7. Clà quello è uno degli aspetti che ho delineato nelle note negative, il team brucia mentalmente più risorse in quel periodo e dunque dopo a bisogno di pausa e gratificazione.

    Quello che emerge e che se pur da un piano tecnico tale velocità è possibile dal punto di vista umano lo è meno, e questo deve trovare un compromesso con quello economico che ragiona solo in termine di time to market, costo e concorrenza.

  8. >@clà: non sottovaluterei l’impatto dello stress sulle persone…

    giusto. Motivo per cui è meglio creare dei canoni di lavoro comuni, da subito, la maggior parte dello stress deriva da incomprensioni ed un modo di comunicare che non segue quello del cliente.

  9. La componente fisica è indubbiamente molto importante, ma forse superabile se ci fossero strumenti “più naturali e immediati” rispetto a wiki, chat, reporitory etc etc..

    Molto, ma molto molto, più problematico è il rapporto con i committenti/stakeolder che purtroppo sarà sempre più lento rispetto a quello delle agenzie. A meno che non lavoriate direttamente con il “decisore” rischierete sempre di dover fare delle modifiche a progetto concluso, mentre se lavorate direttamente col responsabile, probabilmente i feedback saranno lentissimi e sommari a causa degli impegni di cui è sovraccarico.

    Purtroppo la dinamica dell’agenzia, tempo=denaro è troppo distante da quella aziendale, nonostante anche lì si vogliano concludere i progetti mediamente prima possibile.

    Il vostro modello, puntando sull’efficienza economica, si scontrerà sempre con le buracrazie e le dinamiche aziendali.
    Ve lo assicuro
    ;-)

  10. Antonio il problema è relativo perchè nell’agile il committente (decisore) deve essere sempre in contatto/presente e disponibile durante l’iterazione, questa è una condizione base per questo tipo di approcci che viene sottoscritta inizialmente.

    Il problema nasce dal fatto che il decisore in prima istanza non conosce perfettamente i suoi stakeholders il che ha portato a dei feedback verso di lui terminata l’iterazione. Questi feedback chiaramente poi vengono integrati in successive iterazioni come nuove storie, ma se il cliente stesso fosse maggiormente agile nel metodo risparmierebbe di sicuro tempo e risorse.

    È chiaro che questo non funziona se il cliente non accetta le regole del gioco :)

  11. Pero Luca, il cliente che ti “paga per fare un lavoro” non vuole (in alcuni casi certo) fare il cliente Agile perchè potrebbe obbiettare: perchè dovrei fare io il uto lavoro ?
    Perche dovrei essere presente nella fase di analisi/refactoring del progetto ?
    Potrebbe obbiettare che è un costo che devi gestire tu esecutore …

    ( Spero di non esser uscito dal seminato )

  12. Eheheh emaaa hai toccato un tasto dolente su cui avrei un’opinione tutta particolare … comunque la persona più adatta a rispondere qui è Jacopo mo lo chiamo :)

  13. Beh, dipende dall’approccio.

    Quando chiedo ad uno studio di architettura di progettarmi una casa è uso per lo studio affiancarsi a me e assorbire le mie esigenze, proprio PER evitare di farmi un lavoro sbagliato e io sono ben contento di farmi fare la casa dei MIEI sogni e non quella dei sogni di qualcun altro. :)
    Per non parlare del rapporto tipico fra proprietario della casa e la ditta di lavori edili incaricata di tirarla su! Sapete quanto spesso accade che i muratori tirino su un pezzo di casa diverso da come lo intendeva il proprietario? Molto, molto spesso… Per questo chi paga ha INTERESSE a essere sempre presente (nei limiti dell’utile, è più che ovvio) sul cantiere.

    Oppure c’è la figura del consulente personale, come il medico, l’avvocato. Conoscete un avvocato difensore che possa lavorare bene senza avere il proprio cliente al proprio fianco? O un medico che non concordi, fra tutte le alternative possibili, la cura migliore per il particolare paziente CON il paziente stesso?

    Oppure c’è il supermercato.
    Vado allo scaffale, mi fido, accetto la produzione studiata peraltro comunque sull’utenza – ma su base statistica e non personale, e torno a casa con un prodotto molto economico ma identico a quelli di centinaia di migliaia di altri clienti.

    Un sito web può MAI permettersi di essere uguale ad altri?
    Il lavoro del medico è quello operativo di farti prendere la medicina tutte le sere o quello consultivo di fare la giusta analisi *in tua presenza* della tua specifica patologia?
    Se investo denaro – quello serio – lo sparo su un missile ‘fire & forget’ o la villetta in cui vorrò passare il resto della mia vita me la curo e coccolo dal primo mattone in su?

    Un’azienda di sviluppo software non è un’azienda di ‘esecutori’. Gli esecutori sono le CPU. Chi fa sviluppo vende analisi e progettazione, da fare al fianco del committente nel SUO STESSO interesse. Lo stesso dicasi per un’azienda che vende user experience.

    Ciao a tutti!

  14. Pingback: Il costo dell’interesse per il cliente in un progetto agile | Sviluppo Agile