Un'analisi dovrebbe essere indipendente dalla tecnologia? [chiuso]

Ci sono certamente casi in cui è logico che un analista aziendale comprenda la tecnologia almeno abbastanza bene da capire dove ha senso interrogare un utente aziendale su quanto sia importante una particolare caratteristica. Ad esempio, se l'azienda è abituata al comportamento di un'applicazione fat client mentre la nuova applicazione sarà basata sul web, è probabile che ci saranno molti "requisiti" che sarebbero banali in un client grasso ma relativamente difficili con un'applicazione web-based. Se l'analista aziendale comprende se una richiesta da parte dell'azienda sarà banale per il team di sviluppo o se coinvolgerà 20 ore di sviluppo AJAX, potrà capire se ha senso annotare semplicemente il requisito o se ha senso impegnare il business nell'esplorazione di alternative.

Per ogni progetto, ci sono probabilmente un gran numero di insiemi di requisiti che in realtà soddisfano il business effettuando vari tipi di compromessi. Maggiore è la comprensione dell'analista aziendale in merito ai compromessi che stanno facendo, maggiore è la probabilità che offrano una serie di requisiti che massimizzino i benefici per l'azienda riducendo al minimo i costi.

Avendo lavorato su entrambi i lati di questo problema, sono d'accordo con l'Analista. Ho visto alcuni disegni spettacolarmente poveri derivanti dalla mancanza di comprensione delle capacità della tecnologia. In alcuni casi, è stato il risultato di prendere il marketing hype come verità. In generale, il problema è stato la generazione di specifiche che non corrispondono alle capacità tecniche.

L'analista dovrebbe specificare che cosa deve essere fatto, quando e da chi. Dovrebbero sapere perché è stato fatto. La priorità di sviluppo dovrebbe essere più dipendente dal Why che dagli altri fattori. Il team di progettazione e sviluppo deve gestire il come. Al fine di sviluppare sistemi economicamente efficaci, gli analisti devono specificare cosa deve essere fatto in termini che non spingano i limiti della tecnologia disponibile.

Spingere i limiti può aumentare i costi in vari modi, ma in alcuni casi può avere un ritorno significativo. Alcuni dei fattori di costo sono:

• Potrebbe essere necessaria la sperimentazione per sviluppare una soluzione di lavoro;
• Potrebbero essere necessari nuovi dipendenti o consulenti con conoscenze specialistiche;
• Potrebbe essere necessario un addestramento sulla nuova tecnologia;
• Lo sviluppo tende ad essere più lento e le percentuali dei bug più elevate; e
• Sforzi supplementari possono ritardare le soluzioni più semplici che hanno un valore più immediato.

Se la tecnologia che verrà utilizzata è nota, dovrebbe essere presa in considerazione dagli analisti durante la creazione del design. Diverse tecnologie fanno le cose in modo diverso e un progetto che non tiene conto di tali differenze avrà problemi.

Tuttavia, gli analisti di business non dovrebbero preoccuparsi di quale tecnologia viene utilizzata, il loro compito è quello di raccogliere le regole aziendali e renderle comprensibili per il team tecnico. Analisti di sistemi / architetti / designer o qualsiasi altro nome che possono essere dati dovrebbero conoscere le tecnologie utilizzate e progettare attorno a loro perché dovrebbero essere quelli che fanno il vero design, non gli analisti di business.

Credo che ci sia un punto tra le due linee di pensiero che è probabilmente più realistico. Mentre un design di alto livello potrebbe essere la soluzione migliore quando si mantiene agnostica la tecnologia, ci deve essere una considerazione dei vincoli e dei requisiti noti del mondo reale che dovrebbero essere incorporati nel progetto. Che livello è questo design? Hai requisiti sufficienti? Quanto è flessibile l'ambiente? La direzione investe in una specifica direzione tecnica?

Non ci sono parametri operativi che ti guidano in una direzione specifica? Avete una vasta gamma di risorse in grado di implementare una soluzione in qualsiasi stack tecnologico? Ci sono problemi di interoperabilità che richiedono l'accesso ad altri sistemi?

Le risposte a queste domande sono necessarie prima di poter dire in via definitiva se la tecnologia debba far parte dell'equazione o se il design debba guidare la selezione della tecnologia.

Non avendo alcun vincolo ed essendo un progetto di altissimo livello, potrei essere d'accordo con il tuo pensiero sul fatto che il design sia veramente agnostico. Tuttavia, nei miei oltre 20 anni di esperienza, raramente mi trovavo in una situazione in cui non c'erano vincoli che limitassero le mie scelte - e che ha guidato il mio progetto verso tecnologie specifiche o famiglie di tecnologie.

L' interfaccia utente ideale sarebbe dove l'utente pensa a un pensiero e ciò che volevano fare è semplicemente fatto. Tutto ciò a parte questo è paralizzato dalle limitazioni tecnologiche che abbiamo a nostra disposizione, quindi ovviamente il BA deve capire in che contesto è possibile progettare il sistema.

Diverse tecnologie possono avere strutture di costo ed efficienza molto diverse per risolvere un determinato problema. Questi costi possono includere costi di noleggio nella zona, costi di energia e raffreddamento per sistemi specifici, codice esistente e possibilità di riutilizzo delle attrezzature esistenti, ecc. Quindi, sì, forse uno può ignorare questi contrappesi e dettagli di tecnologie specifiche se si sta lavorando a un progetto in cui i costi e l'efficienza non sono affatto importanti quanto altre considerazioni (come la sicurezza aerea, il controllo delle centrali nucleari, gli impianti medici, ecc.). Ma per la maggior parte delle situazioni aziendali, la gestione potrebbe interessarsi alla struttura dei costi delle potenziali soluzioni rispetto ai benefici dell'implementazione del sistema.

L'analista di business dovrebbe sapere quale tipo di applicazione stiamo sviluppando come * Applicazione Web / Applicazione console / Applicazione mobile / Applicazione di reporting ecc * in modo che possa trovare una bella serie di funzioni per l'applicazione o respingere l'utente su aspettative impossibili come il trascinamento nidificato di 3 ° livello (ad esempio).

He / She non deve essere consapevole di quale tecnologia come Java / C # / Python / SQL ecc.

Il processo di analisi stesso deve essere completamente indipendente dalla tecnologia. Quando stai ricercando il cliente e le sue esigenze, devi farlo con una mente completamente aperta. L'altro lato della medaglia, tuttavia, è che spesso all'analista viene chiesto di fornire raccomandazioni e può anche essere richiesto di gestire anche l'architettura del sistema. Questo è un aspetto completamente diverso del ruolo in cui una più ampia comprensione delle tecnologie disponibili è fondamentale, in quanto può fare una grande differenza per il cliente non solo in termini di capacità di realizzare un progetto, ma anche in termini dei bisogni a lungo termine del cliente e della sostenibilità del progetto stesso.

Anche se è vero che la maggior parte del software di progettazione è essenzialmente la stessa indipendentemente dalla tecnologia utilizzata, ci sono sempre aree in cui il design sarà influenzato dalla scelta della tecnologia. Le scelte di piattaforma possono influenzare le scelte linguistiche e API, mentre la disponibilità di esperienza, supporto e anche i costi avranno un impatto anche sulle scelte fatte. Quindi, da una prospettiva, parte della tua posizione è giustificata dal fatto che l'analisi effettiva dovrebbe essere condotta senza l'influenza di alcuna tecnologia specifica, tuttavia l'utilizzo dell'analisi per determinare un progetto richiederà sempre una conoscenza più ampia della tecnologia, in modo che l'analista possa formulare raccomandazioni che consentirà l'applicazione di progetti destinati a soddisfare le esigenze del cliente.

Ogni tecnologia ha limiti e limiti, quindi ha senso per un analista considerare questi limiti. D'altra parte, un analista che conosce bene, ma non ha visto Java dalla fine degli anni '90, molto probabilmente progetterà una soluzione .net - usando la terminologia .net e gli schemi di progettazione - anche se Java (o RoR ecc.) sarebbe meglio adattarsi al problema. È relativamente difficile implementare un progetto simile in un'altra tecnologia più tardi.

Pertanto, penso che un analista dovrebbe essere agnostico quando la tecnologia non è ancora stata selezionata, ma sperimentata in quei casi in cui la scelta è già stata fatta.