Qual a importância do conhecimento do domínio versus do conhecimento técnico?

Estou trabalhando em um aplicativo de negociação e gerenciamento de riscos e, embora com experiência em C #, fui solicitado a trabalhar em pacotes SSIS. Agora eu posso viver com isso. O ponto negativo é que há muita ênfase no entendimento dos negócios. Negociação (Energy Trading, para ser exato) é uma área ENORME e a compreensão de cada parte é esmagadora. Mas, nos últimos dois meses, tenho trabalhado na compreensão dos termos de negócios - Mark To Market, Métricas de Risco, Posições, PnL, Gregos, Instrumentos, Estrutura de Livros ... todos os pequenos detalhes (você entendeu bem). Agora IMHO, este é o trabalho de um BA. Claro que é muito importante que os desenvolvedores entendam o negócio, mas onde você desenha a linha?

Quando conversei com meu gerente sobre isso, ele quase zombou de mim dizendo que qualquer um pode aprender uma tecnologia em uma semana. É o negócio mais difícil. Minha aspiração a longo prazo é permanecer no lado técnico, provavelmente me tornar um arquiteto (se possível). Se eu quisesse me concentrar tanto nos negócios, teria feito um MBA!

Quero saber se estou errado ou ingênuo ao entender a importância do negócio ou se minha frustração é justificada?

O trabalho de um programador é traduzir os requisitos de linguagem natural em implementações de linguagem de máquina. Você não pode fazer isso efetivamente se for apenas fluente de um lado ou de outro. A menos que você esteja escrevendo compiladores ou software de controle de versão, praticamente todos os trabalhos de programação exigirão uma quantidade significativa de conhecimento que não é de programação.

Benjol e seu gerente estão certos, mas deixe-me detalhar:

aprender o domínio do negócio é como você agrega valor ao processo e aumenta seu valor ao negócio

esta é a diferença entre um programador de código de macaco e um desenvolvedor

Há um ditado que veio do Departamento de Ciência da Computação da minha universidade:

Se você deseja criar um software para geólogos, primeiro precisa entender geologia. Se você deseja criar um software para físicos, você deve primeiro se interessar por física. Se você quer entender negócios, primeiro precisa aprender a falar de negócios.

Eu ouço pessoas aqui o tempo todo dizendo que o desenvolvimento de software é um campo criativo. Eu acredito que isso é verdade até certo ponto. Envolve criatividade, pois é preciso ser capaz de enxergar fora da caixa para resolver uma série de problemas.

O que isso não significa é que você pode simplesmente se sentar e, de forma criativa, construir o que quiser. Isso não é aula de arte, é engenharia, e seus clientes e partes interessadas esperam que você crie algo que resolva os problemas deles , e não algo que seja "legal".

Para resolver um problema, você deve primeiro entender o problema. Você precisa entrar na cabeça dos usuários e entender como eles pensam.

Esteja você criando software para finanças, marketing, vendas, geologia, física ou qualquer outro campo que o software suporte, você deve se tornar parte desse campo.

É por essa razão que, além do meu diploma em Ciência da Computação, também me formei em Administração; isso causou um enorme impacto na minha capacidade de comunicar possíveis soluções e fornecer produtos de sucesso.

Se você quiser saber mais sobre o que eu procuraria ao contratar um engenheiro de software de negócios, consulte este Exemplo de anúncio de emprego de engenheiro de negócios que escrevi como resposta a outra pergunta.

Você pode sobreviver sem muito conhecimento do domínio ou contato do cliente como codificador de baixo nível, mas um arquiteto de software é alguém que está muito familiarizado com o domínio e se comunica ativamente com todas as partes interessadas.

Na minha opinião, você está errado e ingênuo demais.

Como seu gerente disse (levemente), qualquer um pode aprender uma tecnologia em uma semana. A única coisa que vai marcá-lo e torná-lo útil para sua empresa é o seu conhecimento comercial. E quanto mais difícil, mais valerá a pena.

Obviamente, se você achar que esse negócio em particular é incrivelmente entediante, pode procurar algo diferente. Mas se sua idéia do paraíso é invadir pequenos sites php, cuidado: haverá milhares de crianças que também estão fazendo isso.

Sério, "eu sou apenas um programador, não me confunda com os fatos" simplesmente não serve.

Eu também trabalho no comércio de energia. Conhecimento de negócios é 90% do trabalho. Você não pode contornar isso - é um negócio complicado.

Se você não entender pelo menos o básico da negociação e os mercados em que está trabalhando, terá dificuldades, não importa quão bom seja um programador.

Eu trabalho com alguns bacharéis que simplesmente não conseguem atender corretamente aos requisitos. Eu preciso confiar em minhas próprias habilidades analíticas e compreensão do conhecimento de negócios para fazer o trabalho.

Acho que se você estiver trabalhando para uma loja que vende software de negociação de energia, sua experiência pode ser diferente - mas no comércio corporativo de energia de TI o foco está diretamente na compreensão do mercado e em como o software pode fornecer soluções para os problemas da empresa primeiro.

As tecnologias atuais usadas e a implementação chegam em um segundo distante.

O cara acima que fez o comentário do Excel não sabe o quão adequado é o comentário dele. Os traders geralmente criam seus próprios aplicativos comerciais em Excel / VBA (isso é tudo o que sabem) e, em seguida, a TI acaba herdando essas bagunças de programas.

Adoraria reconstruir alguns desses aplicativos em um idioma "adequado", mas isso nem sempre é uma prioridade.

Se você está desenvolvendo um negócio, terá uma ideia mais clara e detalhada das regras de negócio do que qualquer outra pessoa na empresa. Isso não é necessariamente porque você é mais esperto do que todo mundo, é porque é a única maneira de fazer o trabalho.

Sua reação pode ser "Mas o que os analistas de negócios fazem?"

Os analistas de negócios mantêm longas reuniões com os clientes, tentando obter requisitos claros o suficiente para que um desenvolvedor trabalhe. Observo a maneira como eles têm que lidar com os clientes e me sinto grato por não ter que fazer isso.

Eu gosto de fazer analogias entre desenvolvimento de software e arquitetura. Ambos são artes aplicadas. Ambos exigem modelagem elaborada dentro da mente. O aspecto que se aplica a essa pergunta é que escrever software sem conhecimento de negócios é como projetar um prédio sem entender o estilo de vida e as necessidades dos habitantes. Eu acho que muitos de nós já vimos (ou mesmo moramos / trabalhamos) em edifícios que podem parecer bonitos e modernos e outros enfeites do lado de fora, apenas não são utilizáveis por dentro. (Na pior das hipóteses, eles nem são legais: - ((())

Atualizar

Comentário de Gaurav:

O que me interessa é até que ponto um desenvolvedor deve se esforçar para entender o domínio comercial. Ele deve percorrer todo o caminho, ou há alguma linha a ser traçada.

Eu não acho que você pode desenhar uma linha em qualquer lugar em geral. A menos que haja partes do aplicativo / domínio que você não precise tocar (portanto, entenda). O que é IMHO muito raro na vida real, a longo prazo. Qualquer parte de um aplicativo que esteja em uso ativo receberá relatórios de erros e solicitações de recursos. Os domínios também mudam, à medida que a legislação, regras tributárias, políticas, hábitos correspondentes - em resumo, o mundo real - mudam. Isso também deve ser seguido no software.

Porém, mesmo sem solicitações externas de alterações, o teste de unidade e a refatoração do código legado também exigem a compreensão das áreas de domínio relevantes. Caso contrário, você apenas "congelará" o comportamento atual do aplicativo, sem saber se ele está realmente correto.

Update2

e se o [...] desenvolvedor muda frequentemente o domínio comercial em que está trabalhando?

É claro que isso significa que grande parte do investimento (do seu tempo e do dinheiro do seu empregador) para obter conhecimento de negócios é perdida :-( Se você sabe que isso vai acontecer, é claro que pode não valer a pena aprofundar muito. um domínio específico.Tenha em atenção que os domínios não são totalmente diferentes, existem fundamentos que podem ser reutilizados entre domínios diferentes e, o mais importante, a abordagem de design orientada a domínio obtida é reutilizável.

Trabalho no setor bancário há mais de dez anos desenvolvendo aplicativos de negociação e concordando que é importante que os desenvolvedores entendam bem os negócios. Mas, repetidamente, durante os processos de entrevista, se a pessoa não tem um bom conhecimento do negócio, ela não entra pela porta.

Isso levou a um número substancial de aplicativos e sistemas críticos sendo desenvolvidos por essas pessoas com forte conhecimento comercial, mas habilidades técnicas de nível médio a baixo. Esses sistemas sempre acabam sendo mal projetados, que constantemente travam, repletos de bugs, não são escaláveis, quase impossíveis de corrigir sem quebrar alguma coisa, e isso é se o projeto não acabar sendo cancelado devido à habilidade técnica insuficiente para obtê-lo. em produção.