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

Ieri ho avuto una discussione con uno dei miei colleghi. Lui (un analista aziendale, in precedenza un programmatore) pensa che dovrebbe essere consapevole della tecnologia utilizzata per implementare il sistema, in modo da poter prendere migliori decisioni di progettazione. Secondo me (sono un programmatore), un'analisi non dovrebbe essere accoppiata in alcun modo alla tecnologia e credo che un buon analista possa realizzare un ottimo design senza preoccuparsi dei dettagli di implementazione.

Ho ragione a pensare in quel modo? Ci sono dei motivi per cui un analista aziendale dovrebbe conoscere la tecnologia utilizzata per implementare il sistema?

EDIT: credo di aver usato il termine sbagliato nel dire business analyst. Forse intendevo architetto o analista di sistema. Non sono abituato a questi termini. Volevo dire qualcosa come architetto o analista di sistema, se preferisci.

Grazie a tutti per le vostre fantastiche risposte! Non ho ancora molta esperienza e sono felice che tu abbia aperto gli occhi su questo.

Vi sono certamente casi in cui ha senso per un analista di business comprendere la tecnologia almeno abbastanza bene da capire dove sia logico interrogare un utente di business su quanto sia importante una particolare funzionalità. Ad esempio, se l'azienda è abituata al comportamento di un'applicazione client fat mentre la nuova applicazione sarà basata sul web, è probabile che ci saranno molti "requisiti" che sarebbero banali in un client fat ma relativamente difficili con un'applicazione basata sul web. Se l'analista aziendale capisce se una richiesta dell'azienda sarà banale per il team di sviluppo o se coinvolgerà 20 ore di sviluppo AJAX,

Per ogni dato progetto, esiste probabilmente un gran numero di requisiti che in realtà soddisferebbero il business effettuando vari tipi di compromessi. Maggiore è la comprensione dell'analista aziendale in merito ai compromessi che stanno effettuando, maggiore è la probabilità che offrano una serie di requisiti che massimizzano i vantaggi per l'azienda, riducendo al minimo i costi.

Avendo lavorato su entrambi i lati della questione, sono d'accordo con l'analista. Ho visto alcuni progetti incredibilmente poveri derivanti dalla mancanza di comprensione delle capacità della tecnologia. In alcuni casi, è stato il risultato del prendere l'hype di marketing come verità. In generale, il problema ha generato specifiche che non corrispondono alle capacità tecniche.

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

Spingere i confini può aumentare i costi in diversi 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;
• Potrebbe essere necessario acquisire nuovi dipendenti o consulenti con conoscenze specialistiche;
• Potrebbe essere necessaria una formazione sulla nuova tecnologia;
• Lo sviluppo tende ad essere più lento e il tasso di bug più elevato; e
• Ulteriori sforzi possono ritardare 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 progetto. Tecnologie diverse fanno le cose diversamente e un progetto che non tiene conto di tali differenze avrà problemi.

Tuttavia, gli analisti aziendali non dovrebbero preoccuparsi della tecnologia utilizzata, il loro compito è quello di raccogliere le regole aziendali e renderle comprensibili al team tecnico. Gli analisti / architetti / progettisti di sistemi o qualsiasi altro nome che potrebbe essere loro assegnato dovrebbero conoscere le tecnologie utilizzate e progettare intorno a loro perché dovrebbero essere quelli che stanno progettando, non gli analisti aziendali.

Credo che ci sia un punto tra le due linee di pensiero che è probabilmente più realistico. Mentre una progettazione di alto livello potrebbe essere la migliore se mantenuta indipendente dalla tecnologia, ci deve essere una considerazione dei vincoli e dei requisiti del mondo reale noti che dovrebbero essere incorporati nella progettazione. A che livello è questo design? Hai requisiti sufficienti? Quanto è flessibile l'ambiente? Il management è investito in una direzione tecnica specifica?

Non ci sono parametri operativi che ti guidano in una direzione specifica? Hai 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 definitivamente se la tecnologia dovrebbe far parte dell'equazione o se il design debba guidare la selezione della tecnologia.

Dato nessun vincolo ed essendo un progetto di altissimo livello, potrei essere d'accordo con il tuo pensiero che il design sia veramente agnostico. Tuttavia, nei miei oltre 20 anni di esperienza, raramente mi sono trovato in una situazione in cui non c'erano vincoli che limitavano le mie scelte e che spingevano il mio design verso specifiche tecnologie o famiglie tecnologiche.

L' interfaccia utente ideale sarebbe quella in cui l'utente pensa un pensiero e ciò che voleva fare è semplicemente fatto. Qualunque cosa a parte questo è paralizzata dalle limitazioni tecnologiche che abbiamo a nostra disposizione, quindi ovviamente il BA deve capire in quale contesto può progettare il sistema.

Tecnologie diverse possono avere strutture di costo ed efficienza molto diverse per risolvere un determinato problema. Tali costi possono includere costi di assunzione nell'area locale, costi energetici e di raffreddamento per sistemi specifici, codice esistente e possibilità di riutilizzo di apparecchiature esistenti, ecc. Ecc. Quindi, sì, forse si possono ignorare queste contraddizioni e i dettagli di tecnologie specifiche se si sta lavorando a un progetto in cui costi ed efficienza non sono per nulla 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 direzione potrebbe occuparsi della struttura dei costi delle potenziali soluzioni rispetto ai vantaggi dell'implementazione del sistema.

L'analista aziendale dovrebbe sapere che tipo di applicazione stiamo sviluppando come * Applicazione Web / Applicazione console / Applicazione mobile / Applicazione di reportistica ecc. * In modo che possa meglio presentare un bel set di funzionalità per l'applicazione o rinviare l'utente su aspettative impossibili come il drag and drop annidato di terzo livello (ad es.).

Lui / Lei non ha bisogno di essere consapevoli di quali tecnologie come Java / C # / Python / SQL , ecc

Il processo di analisi stesso deve essere totalmente 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 all'analista viene spesso chiesto di fornire raccomandazioni e potrebbe anche essere richiesto di gestire anche l'architettura di sistema. Questo è un aspetto completamente diverso del ruolo in cui una comprensione più ampia delle tecnologie disponibili è cruciale, in quanto può fare una grande differenza per il cliente non solo in termini di capacità di far decollare un progetto, ma anche in termini delle esigenze a lungo termine del cliente e della sostenibilità del progetto stesso.

Mentre è 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 della piattaforma possono influenzare le scelte di lingua e API, mentre la disponibilità di esperienza, supporto e persino i costi avranno un impatto 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 vincoli, quindi ha senso per un analista considerare tali limiti. D'altra parte, un analista che conosce bene .net, ma non vede Java dalla fine degli anni Novanta, molto probabilmente progetterà una soluzione .net - usando la terminologia .net e i modelli di progettazione - anche se Java (o RoR ecc.) sarebbe meglio adattarsi al problema. È relativamente difficile implementare un tale progetto in un'altra tecnologia in seguito.

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