Conoscenza aziendale in una grande organizzazione finanziaria? [chiuso]

Dovresti fare sul serio sulla conoscenza del dominio / business se vuoi fare qualcosa di buono nell'ambiente che hai descritto. I programmi in genere vengono classificati nelle seguenti categorie.

1. Programmi generali relativi alla ricerca di ordinamento o alcune volte astratti al livello di risoluzione di alcuni tipi di enigmi. In genere specificano la dichiarazione del problema sotto forma di manipolazione dei dati di qualche forma in qualche forma. Questo tipo di programmazione in realtà non si concentra molto sulla fine degli affari. Ma questo tipo di programmi si concentra su altre cose importanti come ad esempio, controllando se una persona può risolvere un problema e pensare analiticamente e scrivere un programma per risolverlo. Risolvere tali problemi richiede generalmente la comprensione di alcuni concetti di base di ordinamento, ricerca, organizzazione delle informazioni e quindi presentazione.

2. I programmi che si trovano nel mezzo, cose come middle wares, compilatori e altri strumenti come IDE rientrano tutti in questa categoria. Questo tipo di problemi si concentra sull'abilitare le cose alle due estremità per incollarle correttamente. Qui è necessario comprendere i problemi e la logica a livello di applicazione. Ad esempio potrebbe essere necessario capire come ottimizzare un'applicazione di caching per lavorare più velocemente se vengono memorizzati solo i dati di testo. Ciò richiede anche capacità di risoluzione dei problemi e di programmazione, ma sono astratti di un livello più alto.

3. Programmi che interagiscono con gli usi finali e svolgono il loro lavoro. Questo è dove sei. Per fornire un buon software agli utenti, dovrai capire quali sono i loro bisogni. Come funzionano? Il loro flusso di lavoro? Problemi che solitamente affrontano e quindi cercano di modellarli nel mondo del programma / software e risolverli. Questi tipi di problemi implicano la comprensione della fine dell'utente delle cose (quali problemi si sta tentando di risolvere) e la programmazione della fine delle cose (quanto bene è possibile risolverli).

Penso che il tuo caso rientri nella terza categoria. Non esagerare e cerca di diventare un esperto totale in quel dominio. Devi capire quanto devi capire per risolvere un particolare problema. In altre parole, è necessario essere chiari sull'affermazione del problema e sui dati disponibili. Sarà meglio se non ti trasformi gradualmente in un brutto uomo d'affari mentre potresti essere un bravo ragazzo tecnico.

Di sicuro, questa è la mia considerazione principale quando si prendono progetti.

Non necessariamente specializzazione nel mio caso. Ho lavorato con scienza dei materiali computazionale, telerilevamento, BI e finanza. Mi piace avere la possibilità di imparare cose nuove e crescere. Ora mi sto specializzando un po ', probabilmente perché ora ho qualche anno di esperienza e sto iniziando ad avere opinioni più definite su quale tipo di software mi piace lavorare.

Sono un po 'agnostico quando si tratta di scelte tecnologiche - finché funziona e non mette il progetto in pericolo lo userò. Cerco di stare al passo con nuove cose come Diamond su Maglev o dovunque. Ma il più delle volte resterò con me ovunque lavori.

Se la tua cosa è finanza potresti voler dare un'occhiata a questo domanda che ho precedentemente chiesto. Ci sono alcune indicazioni sui libri sulla finanza quantitativa e potrebbe interessarti.

Anche per le startup, la conoscenza del dominio è fondamentale, IMHO.

Pensa a come ti sentiresti per l'azienda che costruisce la tua casa se i costruttori dicessero "Voglio lavorare su un progetto in cui inchiodo tavole di pino insieme invece di tavole di quercia" o "Voglio lavorare con i martelli di Artigiano non Home Depot martelli "

Preferisci non voler sentire "Voglio lavorare sulla costruzione di case di alta qualità, utilizzare tecnologie ecologiche ed efficienza energetica"?

Le mie analogie potrebbero essere un po 'deboli perché non sono un falegname, ma i tuoi clienti sono interessati ai risultati, non alle tecnologie con cui puoi giocare. Devi ricordare che sei stato pagato per creare software che parla ai tuoi clienti e che risolve i loro problemi, e questi problemi non possono essere sempre risolti solo sapendo che Hashtables sono thread-safe e HashMaps no.

Per costruire qualcosa per i tuoi clienti, non solo devi sapere come guidare le unghie nel legno, ma devi sapere come farlo in un modo che risolva un problema del mondo reale, come mettere un tetto stabile sopra la testa di qualcuno, non solo inchiodando casualmente pezzi di legno insieme:)

Utilizzato per lavorare in un ambiente simile, scrivendo software per l'analisi dei dati del mercato finanziario.

Senza una certa conoscenza del business (che si è approfondito nel tempo) sarebbe stato impossibile trovare molti dei problemi funzionali più sottili (e alcuni dei più sfacciati) con il software, come una tendenza che va giù guardando il numeri ma il software ha generato una tendenza che si incurva guardando i suoi grafici. Anche la conoscenza delle statistiche e della matematica ha aiutato. Ci ha aiutato a trovare difetti fondamentali in uno degli algoritmi che ci è stato detto di codificare da un analista, per esempio.

Senza tale conoscenza del dominio, avremmo finito con la creazione (a un costo considerevole) di un pezzo di software così fondamentalmente imperfetto che, se avesse superato il reparto test (che a loro volta richiede la conoscenza del dominio per analizzare i risultati del test) potrebbe avere finì per costare ai nostri clienti decine di milioni di dollari al giorno. Posso indovinare stimare le azioni legali che la nostra compagnia avrebbe dovuto affrontare se fosse successo.