Come prendi in considerazione l'usabilità e i requisiti utente per la tua applicazione? [chiuso]

Question

Come prendi in considerazione l'usabilità e i requisiti utente per la tua applicazione? [chiuso]

#1 da (4 voti)

3

Il nostro team supporta l'applicazione BackOffice: un mix di finestre WinForm e WPF. (circa 80 tra finestre di dialogo). Davvero una specie di coltellino svizzero. È usato da sviluppatori, scrittori tecnologici, sviluppatori di sicurezza, tester.

I requisiti per le nuove funzionalità arrivano abbastanza spesso e talvolta giochiamo a Wizard of Oz per decidere quale GUI piace ai nostri utenti. E di solito accade (ammetto che può essere solo la mia interpretazione soggettiva della realtà) che un piccolo dettaglio che dà il sapore di una buona usabilità alla nostra app richiede molto tempo. Questo tempo viene speso per "combattere" con la struttura della GUI rendendolo atto come abbiamo bisogno. Ed è molto difficile fare stime per questo tipo di attività (almeno per me e la maggior parte dei membri del nostro team). Anche lo Scrum poker non è di aiuto.

La gestione considera spesso questo perfezionismo dell'usabilità una perdita di tempo. D'altra parte un effetto cumulativo di caratteristiche in cui ciascuna ha qualche piccolo difetto di usabilità frustra gli utenti. Ma gli stessi utenti vogliono versioni frequenti e correzioni di bug istantanee. Quindi, nessun modo per ottenere il feedback positivo: c'è sempre qualcuno che è sniffato.

Mi sento costantemente in competizione con noi stessi: più funzioni - > più bug / attività / architettura. Stiamo cercando di superare il carrello che stiamo spingendo. Arrivano nuove tecnologie e alcune di esse possono potenzialmente contribuire a migliorare la progettazione o ridurre i tempi di implementazione delle attività, ma queste tecnologie richiedono apprendimento, prototipazione e così via.

Bene, quella era una storia. E ora è la domanda:

Come si bilancia tra pressione del tempo, qualità del prodotto, utenti e soddisfazione del management?
Quando e come decidi di lasciare il problema con non perfetto ma in una certa misura una soluzione accettabile, quanto spesso le fai decisioni?
Come fai con la tua soddisfazione? Quali sono le tue priorità?

P.S. Si prega di tenere a mente, siamo un team di BackOffice, non abbiamo né uno scrittore tecnico dedicato né un designer GUI. Il tester ci ha raggiunto di recente. Abbiamo molto lavoro da fare e molta libertà riguardo al "come". Mi piace perché favorisce la creatività ma non voglio diventare troppo nerd perfezionista.

project-management requirements quality-attributes gui-design

posta Pavel Voronin 12.12.2012 - 22:48

fonte

1 risposta

Leggi altre domande sui tag project-management requirements quality-attributes gui-design

Posso applicare i concetti SOLID a intere progettazioni di soluzioni piuttosto che solo ai componenti interni? Sottolineatura extra spazio MergeSort

score 4 · Accepted Answer

Passaggio 1) È necessario far sì che gli utenti del prodotto chiedano a gran voce alla dirigenza di aver bisogno di più del tempo di sviluppo e in modo che possano modificare l'interfaccia utente nel modo desiderato.

La modifica dell'interfaccia utente a perfection è un'attività notoriamente dispendiosa in termini di tempo e i problemi a questo riguardo sono piuttosto tipici. Ma non è la tua battaglia per giustificare il tempo necessario per la gestione, è il lavoro Utenti a farlo. In sostanza, hanno bisogno di implorare la direzione e convincerli che l'investimento di X time in Y beneficia l'azienda. Non il tuo argomento per fare, è loro .

Suggerimento: Ecco come bilanciare alcune delle pressioni che menzioni nella prima domanda.

Passaggio 2) Inizia il consolidamento / migrazione su meno tecnologie dell'interfaccia utente. La scelta migliore è migrare verso WPF. È più facile ottenere la funzionalità whiz-bang di WPF rispetto a Winforms, e WPF riceverà più aggiornamenti di quanto Winforms abbia mai fatto. No, non hai necessariamente richiesto questa parte, ma devi consolidarla per migliorare la creazione delle tue stime.

Anche una linea nella sabbia di "tutti gli sviluppi futuri devono essere WPF" è un passo nella giusta direzione.

Suggerimento: In questo modo ottieni credibilità con le tue stime che ti aiuteranno a bilanciare pressioni multiple e contrastanti.

Passaggio 3) Impara a negoziare per "abbastanza buono". Vogliamo tutti perfection , ma è uno stato molto costoso da raggiungere. Imparare a cavarsela abbastanza bene è la chiave per la tua seconda domanda. Quanto spesso lo fai? Praticamente ogni singolo requisito ....

La verità è detta, perfection è placcatura in oro. È meraviglioso. È davvero bello e bello da vedere. Ma la maggior parte delle volte? Tu e gli utenti non ne avete bisogno.

Una volta accettata la realtà che c'è più lavoro da compiere rispetto a quello che si può fare, si inizia a riconoscere l'oro-placcatura, er perfection , per il dispendio di tempo che è con un corrispondente basso beneficio allo sforzo payoff.

Passaggio 4) Riconosci che non sei pagato per creare perfection . No, non lo sei davvero. Sei pagato per soddisfare le esigenze dei tuoi utenti. Capire che c'è un punto critico. Inchiodare un requisito davvero, davvero, davvero, davvero bene non è onesto quanto inchiodare quattro requisiti molto bene. Il campo medico usa il termine "triage" per situazioni come questa. Ti occupi prima delle priorità urgenti; stabilizzarli; e passare rapidamente alla priorità successiva più urgente. No, non si ottiene mai un paziente a perfect salute in quella situazione.

C'è una frase (o un Kōan ) che dice "Migliore è il nemico del Bene". E l'interpretazione iniziale su cui lavorare è che è sempre possibile fare una soluzione "migliore". La chiave sta nell'identificare cosa è "abbastanza buono".