Comments on: Definire le priorità di un progetto

By: LA GESTIONE DELLE EMERGENZE : WOLM – Be a King

LA GESTIONE DELLE EMERGENZE : WOLM – Be a King — Mon, 17 Oct 2011 19:16:42 +0000

[...] riconoscerle ed abbandonare gli schemi usuali per concentrarsi totalmente sull’emergenza. La priorità ed il proprio tempo deve essere dedicato alla gestione della situazione di emergenza. Regole [...]

By: Client Scenarios e agile UX - Alberto Mucignat

Client Scenarios e agile UX - Alberto Mucignat — Tue, 21 Dec 2010 17:14:11 +0000

[...] di molto simile l’ho trattato parlando di come impostare inizialmente un progetto e di come definire le priorità di un progetto. Poi ci sono altri miei post sul tema [...]

By: Social usability: una checklist (e le mie osservazioni) - Alberto Mucignat

Social usability: una checklist (e le mie osservazioni) - Alberto Mucignat — Wed, 10 Mar 2010 20:24:42 +0000

[...] Il design di un’applicazione prevede che si facciano delle scelte sulle funzionalità che potranno avere gli utenti. La strategia di design -lo dico da tempo- per me è prima di tutto scegliere cosa non fare. [...]

By: Alberto

Alberto — Thu, 15 Jan 2009 10:24:51 +0000

ah grazie interessante…

By: fullo

fullo — Thu, 15 Jan 2009 08:29:31 +0000

sai che ti sei perso le immagini del post?

By: Alberto Mucignat

Alberto Mucignat — Wed, 16 Jul 2008 15:03:08 +0000

Flow Interactive ha scritto un post su come raccogliere le priorità di un progetto web con le Scorecards.

Il post è molto interessante e, tra le altre cose, utilizzano la matrice di priorità che ho descritto in un precedente post.

By: Alberto

Alberto — Thu, 15 May 2008 14:07:49 +0000

certo, per prima cosa abbiamo una questione di chiarezza nei confronti del cliente. questo diventa un problema quando il cliente realizza che le cose non verranno fatte comunque. quindi: meglio dirlo subito e affrontare il problema.

(cmq secondo me il fatto che un progetto web non risponda a tutte le specifiche esigenze dell’utenza deve essere visto come un valore, non come un limite)

personalmente credo che procedendo per iterazioni, una feature a priorità bassa possa diventare importante in una successiva iterazione, perchè il feedback degli utenti cambia con l’uso del software.

se invece abbiamo un processo waterfall, non ci sono molte speranze: posticipare una feature equivale sostanzialmente a non farla.

By: Marco Balzerani

Marco Balzerani — Wed, 14 May 2008 21:53:31 +0000

Capire cosa non fare (le funzionalità a basso valore e alto effort) è sempre molto importante, ma di solito si preferisce dire al cliente “questa funzione la rimandiamo in una futura Fase 2 ”