Quanto è importante la conoscenza del dominio rispetto alla conoscenza tecnica?

Sto lavorando a un'applicazione di Trading e Risk Management e sebbene da un background C #, mi è stato chiesto di lavorare su pacchetti SSIS. Ora posso conviverci. Il punto dolente è che c'è troppa enfasi sulla comprensione del business. Il trading (Energy Trading per l'esattezza) è un'area ENORME e comprenderne ogni piccola parte è travolgente. Ma negli ultimi due mesi ho lavorato sulla comprensione dei termini commerciali: Mark To Market, Risk Metrics, Positions, PnL, Greeks, Instruments, Book Structure ... ogni piccolo dettaglio (ottieni il punto). Ora IMHO, questo è il lavoro di un BA. Certo è molto importante per gli sviluppatori capire il business, ma dove si disegna la linea?

Quando ne ho parlato con il mio manager, mi ha quasi deriso dicendo che chiunque può imparare una tecnologia in una settimana. È l'attività più difficile. La mia aspirazione a lungo termine è di rimanere dal lato tecnico, probabilmente diventare un architetto (se possibile). Se avessi voluto concentrarmi così tanto sul business, avrei perseguito un MBA!

Voglio sapere se ho torto o troppo ingenuo nel comprendere l'importanza del business o la mia frustrazione è giustificata?

Il lavoro di un programmatore sta traducendo i requisiti di linguaggio naturale in implementazioni di linguaggio macchina. Non puoi farlo efficacemente se sei fluente solo da una parte o dall'altra. A meno che tu non stia scrivendo compilatori o software di controllo della versione, praticamente ogni lavoro di programmazione richiederà una notevole quantità di conoscenze di non programmazione.

Benjol e il tuo manager hanno ragione, ma lasciami elaborare:

apprendere il dominio aziendale è come aggiungere valore al processo e aumentare il valore per l'azienda

questa è la differenza tra un programmatore di codici scimmia e uno sviluppatore

C'è un detto che è venuto dal dipartimento di informatica della mia università:

Se vuoi creare software per geologi, devi prima capire la geologia. Se vuoi creare software per i fisici, devi prima dilettarti in Fisica. Se vuoi capire gli affari, allora prima devi imparare a parlare di affari.

Sento sempre gente qui dire che lo sviluppo del software è un campo creativo. Credo che ciò sia vero fino a un certo punto. Implica la creatività in quanto bisogna essere in grado di vedere fuori dagli schemi per risolvere una serie di problemi.

Ciò che non significa è che puoi semplicemente sederti e costruire in modo creativo tutto ciò che vuoi. Questa non è una lezione d'arte, è ingegneria, e i tuoi clienti e le parti interessate si aspetteranno che tu crei qualcosa che risolva i loro problemi, non qualcosa che sia semplicemente "bello".

Per risolvere un problema, devi prima capire il problema. Devi entrare nella testa dei tuoi utenti e capire come pensano.

Che tu stia costruendo software per la finanza, il marketing, le vendite, la geologia, la fisica o qualunque altro campo il software supporti, devi diventare parte di quel campo.

È per questo motivo che, oltre alla mia laurea in Informatica, ho anche conseguito una laurea in Economia aziendale; ha avuto un impatto enorme sulla mia capacità di comunicare potenziali soluzioni e fornire prodotti di successo.

Se vuoi saperne di più su ciò che vorrei cercare quando assumo un ingegnere del software aziendale, dai un'occhiata a questo esempio di annuncio di lavoro di ingegnere aziendale che ho scritto come risposta a un'altra domanda.

Potresti sopravvivere senza molta conoscenza del dominio o contatto con i clienti come programmatore di basso livello, ma un architetto del software è qualcuno che ha molta familiarità con il dominio e comunica attivamente con tutte le parti interessate.

Secondo me, ti sbagli e sei troppo ingenuo.

Come ha detto il tuo manager (leggermente perplesso), chiunque può imparare una tecnologia in una settimana. L'unica cosa che ti segnerà e ti renderà utile alla tua azienda è la tua conoscenza del business. E più è difficile, più ne vali la pena.

Ovviamente, se scopri che questa particolare attività è noiosamente noiosa, puoi cercare qualcosa di diverso. Ma se la tua idea di paradiso è l'hacking insieme a piccoli siti Web PHP, fai attenzione: ci saranno migliaia di script kiddie che lo stanno facendo anche loro.

Scherzi a parte, "Sono solo un programmatore, non confondermi con i fatti" semplicemente non lo taglierò.

Lavoro anche nel settore dell'energia. Conoscenza aziendale è il 90% del lavoro. Non puoi evitarlo - è un affare complicato.

Se almeno non capisci le basi del trading e i mercati in cui stai lavorando, dovrai lottare, non importa quanto sei bravo a programmare.

Lavoro con alcuni BA che non riescono a soddisfare i requisiti. Devo fare affidamento sulle mie capacità analitiche e sulla comprensione delle conoscenze aziendali per svolgere il lavoro.

Penso che se lavori in un negozio che vende software di trading di energia, la tua esperienza potrebbe essere diversa, ma nel trading di energia IT aziendale l'attenzione è focalizzata sulla comprensione del mercato e su come il software può fornire prima soluzioni ai problemi del business.

Le attuali tecnologie utilizzate e l'implementazione arrivano al secondo posto.

Il ragazzo sopra che ha fatto il commento di Excel non sa quanto sia appropriato il suo commento. I trader spesso creano le loro piccole app di trading in Excel / VBA (questo è tutto quello che sanno) e quindi l'IT finisce per ereditare questi pasticci di programmi.

Mi piacerebbe ricostruire alcune di queste app in un linguaggio "corretto", ma non è sempre una priorità.

Se stai sviluppando per un'azienda, finirai per avere un'idea più chiara e dettagliata delle regole aziendali rispetto a chiunque altro nell'azienda. Questo non è necessariamente perché sei più intelligente di tutti, ma perché è l'unico modo in cui puoi fare il lavoro.

La tua reazione potrebbe essere "Ma cosa fanno gli analisti aziendali?"

Gli analisti aziendali siedono in lunghi incontri con i clienti cercando di ottenere da essi requisiti sufficientemente chiari per consentire a uno sviluppatore di lavorare. Guardo il modo in cui hanno a che fare con i clienti e sono grato di non doverlo fare.

Mi piace disegnare analogie tra sviluppo software e architettura. Entrambe sono arti applicate. Entrambi richiedono modelli elaborati all'interno della propria mente. L'aspetto che si applica a questa domanda è che scrivere software senza conoscenza del business è come progettare un edificio senza capire lo stile di vita e le esigenze degli abitanti. Penso che molti di noi abbiano visto (o persino vissuto / lavorato) edifici che possono sembrare belli e moderni e quantunque dall'esterno, semplicemente non utilizzabili dall'interno. (Nel peggiore dei casi, non sono nemmeno belli: - ((()

Aggiornare

Il commento di Gaurav:

ciò di cui sono curioso è fino a che punto uno sviluppatore dovrebbe sforzarsi di comprendere il dominio aziendale. Dovrebbe andare fino in fondo, o c'è qualche linea da tracciare.

Non penso che tu possa tracciare una linea ovunque in generale. A meno che non vi siano parti dell'app / del dominio che non è necessario toccare (quindi comprendere) mai. Il che è IMHO molto raro nella vita reale, a lungo termine. Qualsiasi parte di un'app in uso riceverà segnalazioni di bug e richieste di funzionalità. Anche i domini cambiano, come cambiano la legislazione, le regole fiscali, le politiche, le abitudini corrispondenti - in breve, il mondo reale. Questo deve essere seguito anche nel software.

Ma anche senza richieste esterne di modifiche, il test unitario e il refactoring del codice legacy richiedono anche la comprensione delle aree di dominio rilevanti. Altrimenti basta "bloccare" il comportamento corrente dell'app, senza sapere se è effettivamente corretto.

Update2

cosa succede se lo [...] sviluppatore cambia frequentemente il dominio aziendale su cui sta lavorando?

Ciò ovviamente significa che gran parte dell'investimento (del tuo tempo e del denaro del tuo datore di lavoro) per acquisire le tue conoscenze aziendali viene perso :-( Se sai che accadrà, ovviamente potrebbe non valere la pena scavare troppo in profondità un dominio specifico. Tieni presente, tuttavia, che i domini non sono totalmente diversi, esistono fondamenti che possono essere riutilizzati tra domini diversi. E, soprattutto, l' approccio alla progettazione guidata dal dominio che ottieni è riutilizzabile.

Lavoro nel settore bancario da oltre dieci anni sviluppando applicazioni di trading e sono d'accordo sul fatto che è importante che gli sviluppatori comprendano bene il business. Ma di volta in volta, durante i processi di intervista, se la persona non ha una buona conoscenza del business, non riesce ad entrare.

Ciò ha portato allo sviluppo di un numero considerevole di applicazioni e sistemi critici da parte di queste persone con una forte conoscenza del business ma competenze tecniche medio-basse. Questi sistemi finiscono sempre per essere progettati male che si bloccano costantemente, crivellati di bug, non si ridimensionano, quasi impossibile da riparare senza rompere qualcosa, ed è così che il progetto non finisce per essere annullato a causa di un'abilità tecnica insufficiente per ottenerlo effettivamente in produzione.