Diversi team di sviluppo si incontrano

Capita sicuramente di non essere in grado di soddisfare tutte le richieste dei clienti nel nostro piccolo, specialmente se siamo un ristretto gruppo di sviluppatori o anche di più nel caso di un freelance (a meno che non siamo uni e trini).
Magari il cliente vuole una cosa particolare, un’effetto strano, una funzionalità molto ricercata, e dobbiamo mandare di fuori il lavoro, oppure ci troviamo nel caso contrario di altri colleghi ce lo passano a noi perché loro non sono in grado.
Ammesso e concesso che ognuno porterà il lavoro a chi conosce e di cui si fida (sarebbe anche illogico fare diversamente), come si può mettere in condizione l’altro/a/altri di fare il loro lavoro al meglio?

Semplice, facendo noi il nostro al meglio, il che sembra banale, ma in realtà non lo è per niente, tanto più quando andiamo a lavorare con persone che non condividono il nostro stesso metodo di lavoro, anche ammesso che noi ne abbiamo uno, e loro ne abbiano uno.
Certo se invece avete lo stesso metodo di sviluppo è tutto più facile, ma diventa un serio problema quando una delle due parti non ha assolutamente metodo, e ti vedi magari consegnare un wireframe che non tiene conto degli obiettivi del sito che magari a sviluppo inoltrato toccherà rifare da capo perché non si è tenuto conto dei bisogni degli utenti o che altro.

Ora, non ho la soluzione magica, se ce l’avessi avuta non la starei certo dicendo a voi ma piuttosto a quelli dell’ESA per sviluppare un nuovo modo di attraccare le navette spaziali all’ISS.
Ho trovato però molto utile la produzione di documentazione scritta, illustrando tutto ciò che potrebbe essere utile a chi metterà mano al sito.

Documentazione

Intendo pdf ovviamente, quando parlo di documenti scritti[[Non Word e non Pages, PDF, solito motivo della compatibilità.]].
Apparte che documentare le varie fasi del progetto serve a voi comunque, e andrebbe fatto a prescindere, per prima cosa questo vi risparmierà interminabili discussioni del tipo: “come devo fare questa cosa?” “a che serve quest’altra?”, stando sempre a spiegare le stesse cose che magari si perdono in una chat o una telefonata.
Non si tratta di sminuire il lavoro degli altri, anche il loro parere conta[[Non sempre.]], non possiamo considerarli solo come manovali muti, ma molto spesso produrre questi documenti evita che i suddetti si cimentino in imprese che non appartengono loro, come ad esempio un programmatore che si mette in testa di fare una data cosa in un certo modo perché secondo lui è quello il modo giusto di usarla, magari andando a ignorare completamente il lavoro di UX fatto precedentemente che dice tutto il contrario di quello che pensa lui, finendo col ritardare il lavoro di giorni se non settimane. O un grafico che fa un sito diverso da come disegnato e progettato nei wireframe, solo perché nei wireframe si sente “costretto”, e lui è un’artista, ogni sito è come un quadro di picasso: bellissime opere d’arte, ma nessuno ci capisce niente.
Dare un parere si, è sempre ben accetto, modificare senza preavviso no, in nessun caso.
Ecco allora che i documenti servono a fissare dei punti fissi ma flessibili, modificabili col gruppo, ma non di testa propria.
Ogni fase del progetto dovrebbe essere documentata attentamente, annotando tutto quello che serve, le modifiche, le richieste del cliente, i risultati dei test, i prototipi, le bozze, tutto. Tutto quello che può servire per ridurre al minimo gli sbagli. Quelli degli altri e perché no, anche i nostri.

Strumenti condivisi

Photoshop, Omnigraffle, Xmind, Coda e più recentemente si è aggiunto xSort, sono praticamente tutti i programmi che uso io nel mio quotidiano. Ma che probabilmente non usate voi. Magari non state neanche sul sistema operativo che uso io e quindi l’uso di questi software vi è precluso del tutto.
L’uso di strumenti condivisi è indispensabile nel lavoro tra colleghi nello stesso team, ma diventa quasi un’ostacolo quando si va di fuori.
Quindi non date per scontato che gli altri usano i vostri stessi programmi. e producete file che siano standard il più possibile, come un PDF, o un foglio HTML, piuttosto che non un foglio di Photoshop o Illustrator, o l’odiato tanto quanto usato evergreen foglio di word.

]]>