Specificare e applicare ampie modifiche a un programma

Naviga le tue risposte
1

Come gestisci richieste di funzionalità incomplete, quando quelle che chiedono la funzione non possono scrivere una richiesta completa?

Considera una situazione immaginaria. Sei un capo tecnologico che lavora su un software che ruota attorno ai profili di gestione (forse sono contatti in un'applicazione di tipo CRM, o impiegati in un'applicazione HR), con molte operazioni eseguite direttamente o indirettamente su quei profili - modifica campi, aggiungere commenti, allegare documenti, inviare e-mail ...

I superiori decidono che è necessario aggiungere una funzionalità blocco in modo che un profilo possa essere bloccato per impedire a chiunque altro di eseguire operazioni su di esso fino a quando non viene sbloccato - questa funzione verrà utilizzata dagli agenti di sicurezza per impedire a chiunque di toccare un profilo in attesa di un controllo di sicurezza.

Ovviamente, tale funzione interagisce con molte altre funzionalità esistenti relative ai profili. Ad esempio:

  • Si può aggiungere un commento a un profilo bloccato?
  • Si possono vedere le e-mail inviate dal sistema al proprietario di un profilo bloccato?
  • Si può vedere chi ha recentemente modificato un profilo bloccato?
  • Se un messaggio di posta elettronica era in fase di invio quando è avvenuto il blocco, l'invio di e-mail è stato annullato, ritardato o eseguito come se nulla fosse accaduto?
  • Se ho appena modificato un profilo e clicco sul link "cancella" sulla conferma, il blocco impedisce l'annullamento o continua ancora?
  • In tutti questi casi, come faccio a dire all'utente che è presente un lucchetto?

A seconda del software, potrebbero esserci centinaia di tali interazioni, e ogni interazione richiede una decisione: il blocco verrà applicato e se lo fa, come verrà visualizzato all'utente? E i più esperti che chiedono la funzione probabilmente vedranno solo una piccola parte di questi, quindi probabilmente avrai un sacco di domande in arrivo mentre lavori sulla funzione.

Come gestireste voi e il vostro team?

  • Vorresti che i superiori venissero a trovare una descrizione completa di tutti i casi in cui il blocco dovesse applicarsi (e come) e trattare tutti gli altri casi come se il blocco non esistesse?
  • Vorresti provare a determinare tutte le potenziali interazioni basate su specifiche e codici esistenti, elencali e chiedi ai superiori di prendere una decisione su tutti quelli in cui la decisione non è ovvia?
  • Inizieresti a lavorare e fare domande non appena si presenteranno?
  • Vorresti cambiare idea e sistemarti su una funzione più facilmente descritta con effetti simili?

Le informazioni sulle funzionalità esistenti sono, a quanto ho capito, nel codice: come si fa a colmare il divario tra i responsabili delle decisioni e le informazioni a cui non possono accedere?

    
posta Victor Nicollet 27.02.2011 - 05:08
fonte

2 risposte

3

La seconda opzione: "cercare di determinare tutte le potenziali interazioni basate su specifiche e codici esistenti, elencarle e chiedere ai superiori di prendere una decisione su tutti quelli in cui la decisione non è ovvia?" è vicino a quello che vorrei fare. Potrei doverli scoprire lavorando con il codice, quindi anche la terza opzione è parzialmente in gioco.

Gli utenti devono essere informati su tutte le interazioni perché gli utenti non [di solito] pensano a tutti gli scenari possibili, mentre i programmatori fanno (o tentano di farlo).

Sembra che tutte le potenziali operazioni debbano essere enumerate e inserite in un file di configurazione o in una tabella, con l'operazione in una colonna e se permetterle su entità bloccate in un'altra colonna. In questo modo potrebbero essere modificati in futuro, se necessario.

(Modifica: Ovviamente non è possibile utilizzare una tabella per elencare centinaia di interazioni, ma suppongo che quelle centinaia di interazioni possano incanalare verso un numero gestibile di operazioni specifiche.)

    
risposta data 27.02.2011 - 05:55
fonte
1

Se il tuo cliente non è in grado di esprimere i requisiti di business in termini appropriati (una situazione piuttosto comune) e lo sviluppatore non può indovinare e leggere correttamente tra le righe (di nuovo, abbastanza normale), è necessario che qualcuno colga il divario.

Questa persona di solito è una persona tecnica con una solida conoscenza aziendale. Se quella persona non esiste allora è necessario avere una sessione di jam aperta con gli uomini d'affari fino a trovare i modi per comunicare l'intento reciproco, registrarlo in un modo che abbia senso per entrambe le parti e soprattutto assicurarsi di capire la stessa cosa. Questo può essere fatto attraverso disegni, diagrammi, linguaggio semplice, risultati attesi, input previsti, benefici attesi ... in altre parole è necessario acquisire le storie di business (casi d'uso) che guideranno il set di funzionalità.

Se non funziona ancora, allora sei sotto processo ed errore. Questo è il momento per prove di concetto, prototipi, prototipi, qualsiasi cosa sia economica, sporca, al punto, aiutare a colmare il divario tra tecnici e uomini d'affari e soprattutto tutto ciò che può essere utilizzato per avere un miglioramento iterativo a doppio senso processo per arrivare in modo efficiente al punto (raccolta dei requisiti).

Se ciò non è ancora fattibile (indipendentemente dal costo, dal tempo, dall'esperienza o dai motivi operativi), la tua ultima risorsa è provare qualcosa, la tua ipotesi migliore, creare un contingente significativo, assicurarti di adottare un approccio graduale può risalire da un costo minimo (suggerirei di iniziare con gli articoli più rischiosi, ma non è necessariamente l'approccio migliore) e creare molti punti di controllo con il cliente in modo che possano interagire con esso e valutare cosa fa per loro. / p>

HTH

    
risposta data 27.02.2011 - 07:49
fonte

Leggi altre domande sui tag

Passaggio da CMS basato su Oracle a CMS basato su MySQL Come mantenere le dimensioni dell'applicazione in esaurimento (utilizzo della memoria e dimensioni della memoria fisica)?