Da un paio d’anni, insieme a e-xtrategy e a Jacopo Romei, ho iniziato a essere considerata parte integrante del team di sviluppo di un progetto (web o mobile). Do il mio contributo nella scrittura delle storie, partecipo a quasi tutti gli iteration meeting, faccio planning game ecc. ecc. Insomma, mi impegno :)

Prima di dire qual è la mia più grossa difficoltà oggi, devo scrivere nero su bianco, una volta per tutte, quali sono i benefici più rilevanti che ho trovato finora nel cambiare metodo di lavoro:

• migliore comunicazione in tutto il team (cliente incluso)
• grande predisposizione al cambio di rotta o a successivi incrementi
• migliore comprensione del progetto a monte, discutendo prima obiettivi e richieste.

Scusate se è poco.

Quest’anno, in particolare, ho messo le mani su due lavori che dovevano essere fatti così, non c’era un’altra strada.
Il primo progetto partiva da una richiesta generica del cliente: il classico “abbiamo visto che su iPhone si possono fare queste cose. Vorremmo farlo anche noi, vanno tutti lì. Come possiamo fare?”. Il cliente ha accettato di andare avanti per piccoli incrementi e ora siamo arrivati a consegnare una demo funzionante di un qualcosa che doveva essere il 100% iPhone, e ora è altro (diciamo un 35% iPhone un 65% webapp). Il cliente userà questa demo per tastare il terreno con tutta la sua filiera e cercherà di capire come andare avanti (business plan, test, investimenti ecc. ecc.). A me un risultato del genere sembra un indubbio successo, anche nel caso in cui il cliente decidesse di non proseguire.
Il secondo progetto ci vede al lavoro con un’azienda che sta vivendo un cambio generazionale e un momento di forte rilancio sul mercato. I nostri interlocutori sono in perenne spostamento per promuovere la nuova linea e i nuovi prodotti ed è difficilissimo trovare un momento di incontro con loro. La nostra fortuna è che su web partivano quasi da zero, quindi consegnare poco era comunque un di più. Ora abbiamo prodotto un sito al quale aggiungeremo un pezzetto alla volta. Il nostro interlocutore non sa che stiamo lavorando con un approccio agile, ma vede ugualmente il beneficio di poter chiedere l’aggiunta di un pezzo nuovo o di ripensare in toto a una sezione che avevamo lasciato in attesa.

Quello che sto per scrivere sul problema di calendarizzazione e organizzazione non mi fa avere nessun ripensamento sulla bontà del metodo, voglio essere chiara. È solo un’autentica ammissione di attuale incapacità nel gestire il calendario. E la devo risolvere.

I problemi sono due.

• continuerò ad avere clienti per i quali l’approccio agile non funziona. Almeno per me. Per usare la metafora di Jacopo, non tutti i progetti sono fluidi come un progetto di sviluppo software. Nel mio caso, per esempio: un logo è un logo, per farla breve. Non posso fare oggi un lettering e domani aggiungere a matita un’idea che tra un anno il cliente può cambiare. Una fiera è una fiera, una modifica a un progetto web non agile ha i suoi tempi e così via… ci sono consegne che non possono non essere finite. La disciplina e limpidezza di un approccio agile (per lo meno così come l’ho vista impostare da Lorenzo), prevede un tot di lavoro a settimana, oltre al quale più di quello non posso dare. Il cliente chiede di più o vuole avere le cose? Significa che bisogna aumentare le forze (cioè il tempo dedicato o le persone). È qui viene il primo problema: trovare altro tempo, lo sappiamo tutti, non è affatto semplice. Trovare altre persone immediatamente assorbibili nel progetto è cosa davvero rara. È molto difficile far combaciare la fluidità di un progetto con il tempo (che è per definizione finito) o le persone.
• mi è cambiato totalmente il rapporto riunioni tempo (prima ero a un 30 % – 70%, ora è esattamente il contrario). Ma non è tanto questo cambio di rapporto che mi ha sconvolto, quanto l’impossibilità di fare un calendario reale dei lavori. Quando sono su un progetto non agile, devo “fisicamente produrre cose” e devo farlo entro un certo tempo. Se un cliente mi dice che tra 2 mesi ha una fiera e io ho 2/3 settimane di lavori da fare per lui unite a varie urgenze, giuro che non capisco come posso incastrare le cose.
  In un progetto agile ho spesso dei momenti di stand-by (non devo fare niente, ma devo partecipare a tutto). Poi arriva un momento in cui devo fare di più ed è una legge di Murphy che questo momento si incastri con le fasi più acute o urgenti degli altri progetti non agili.

Finora mi sembra che per risolvere questi punti sia importante lavorare con un network con competenze molto simili, capace di lavorare nello stesso modo fluido con cui ha lavorato il team. Ma il rischio è di sentirsi rispondere “picche”.

Il risultato è che…

…invece che fare le mie 8 ore di lavoro utopistiche, mi è letteralmente esploso il calendario (ovvio che ne sono contenta, ma così non è sostenibile). E dato che i progetti di sviluppo sono potenzialmente infiniti, questa cosa mi sta bloccando. Non riesco a vedere una soluzione realistica a questo problema. A oggi, sto dicendo di no a quasi tutti i nuovi progetti.

PS1: non attaccatevi al “quasi”, il mio discorso vuole essere pragmatico. Ci sono partner o clienti a cui semplicemente non puoi dire no.
PS2: non vorrei ridurre le risposte a un semplice “significa che le cose ti vanno bene, che ti lamenti? basta che scegli”. Non la farei così semplice, non è questo il punto del mio post e spero che si sia capito. Devo capire se questo è un primo segnale di un ripensamento più importante, cioè di nuove scelte.