“Le guerre si vincono con l’esercito che hai non quello che vorresti” (cit. Napoleone Bonaparte)

Se il problema dell’esternalità dei contributi è vero… beh…. cambia collaboratori!!!

Scherzo. Sono _io_ un tuo collaboratore!

Scherzi a parte, mi chiedo solo che danno farebbe agli utenti “cliente” se solo gli utenti “sviluppatore” vedessero qualche tab in più nel menu di navigazione di Basecamp (per esempio)? Quello che non vedi esistere di fatto… non esiste! E quindi verrebbe rispettato il Principio del Minimo Set di Funzionalità.

Ciao ciao.

il problema non è quello di avere o no delle features, di potere o meno configurare un software come si vuole. questo è possibile farlo da tempo immemore su moltissimi sw. il problema semmai è di avere qualcosa di orientato agli utenti che lo utilizzano. e non è solo un fatto di usabilità, ma di “strategia del sw” che, mi rendo conto, è un concetto sfuggente, ma importante.

la soluzione ipotizzata (duplicazione dei sw) è appunto a favore di due esigenze degli utenti: quella di gestire la comunicazione tra team e cliente e quella di gestire la comunicazione all’interno del team di sviluppo. se ci fosse la possibilità di avere tutto in un’unica piattaforma con una “strategia sw” intelligente, ti direi che va bene, ma oggi non c’è. e siccome viviamo in un mondo reale dobbiamo essere pragmatici.

il mio consiglio in questo caso è: siccome un software omnicomprensivo alla fine rischia di riportare la comunicazione alle email (!), preferisco utilizzare 2 software, anche se il team deve fare uno sforzetto. per me, in questo caso, vince il cliente, perchè un errore di comunicazione all’interno del team è facilmente risolvibile, mentre un errore di comunicazione (o di percezione) col cliente può portare a problemi irreparabili.

ripeto: non sono convinto che sia una soluzione giusta: anche per me sarebbe importante avere un unico “punto di comunicazione”, ma se alla fine il risultato è che l’utente più importante non lo utilizza, allora io sono per cambiare strumento.

sul team unico, in un’unica stanza, tutti assieme dall’inizio alla fine, sono daccordo in linea di massima, ma fino a un certo punto:
1. un esterno, spesso e volentieri, porta un punto di vista diverso, più “fresco”, che non solo è importante, ma è NECESSARIO per la salute di un progetto
2. non viviamo in un mondo ideale, quindi se la realtà sono i team distribuiti non possiamo prescindere da questo, anzi diventa una “condizione di contorno” che quindi dobbiamo affrontare non dicendo “vorrei il mondo ideale”, ma chiedendoci: “come la gestisco?” (era questo il senso della mia domanda).

cmq è sempre un piacere discutere con te, magari anche dal vivo, se la prossima volta arrivi puntuale (ok ok, non te lo dico più

Ho visto il video e ho solo un paio di considerazioni, da aggiungere alle mille già fatte insieme e alle tremila che faremo in futuro:

- la questione sui software di gestione progetto credo sia… come dire… una falsa questione: nei sistemi di gestione progetto seri io posso dare visibilità diverse ad artefatti diversi per ogni diverso utente, quindi chi non ha bisogno di – per esempio – svn non lo vedrà e chi ne avrà bisogno lo vedrà. E così per tutte le altre features. Quindi non accolgo con favore la duplicazione dell’ambiente di gestione, che sto peraltro sperimentando su un progetto in questo momento e trovo davvero fastidiosa (“dove stava quella info? di qua? di là? boh”) oltre che in opposizione ad uno dei miei principali valori di progetto: la trasversalità dell’informazione. Che poi basecamp in quel poco che fa sia certamente il migliore, è un altro discorso… al limite allora: cosa aspettano a farne uno strumento completo???

- il team separato e distribuito è un’aberrazione dei nostri tempi, sempre e cmq. Il fatto che si siano individuati strumenti anche molto potenti per mitigarne gli effetti negativi sulla vita di un progetto – e sai quanto io stesso li usi – non toglie nulla ad uno dei pochi valori positivi che decenni di industria della proprietà intellettuale ci hanno insegnato: tutti insieme, al limite separati solo da un muro fra due stanze diverse, è meglio. Sempre.

In entrambi i casi lo spirito è lo stesso: comunicare, comunicare, comunicare; feedback, feedback, feedback.

Ciao!

oggi infatti non si tratta (solo) di sviluppare software, ma anche di riuscire a rendere visivamente delle operazioni spesso complesse, per questo sono nate discipline come l’architettura dell’informazione, l’interaction design, il visual design, etc.

agile ux cerca di mettere assieme le due discipline, ovvero il design e lo sviluppo, che prevedono appunto competenze e attività diverse.

ti faccio una domanda che avrei voluto fare se fossi stato li ad ascoltare il tuo intervento.

Che differenza c’è tra l’AGILE UX e l’extreme programming (XP). 2 comandamenti dell’XP recitano che bisogna sviluppare insieme al cliente e rilasciare molti prototipi dell’applicazione. In sostanza è la stessa cosa che afferma l’AGILE UX!?

Ciao,
Paolo