Os desenvolvedores precisam entender o domínio comercial ou a especificação deve ser suficiente?

51

Eu trabalho para uma empresa para a qual o domínio é realmente difícil de entender porque é de alta tecnologia em eletrônica, mas isso é aplicável a qualquer desenvolvimento de software em um domínio complexo.

O aplicativo em que estou trabalhando exibe muitas informações, gráficos e métricas que são difíceis de entender sem experiência no domínio. O desenvolvedor usa uma especificação para descrever o que o software deve fazer, como especificar que um determinado gráfico deve exibir esse tipo de métrica e essa métrica é a seguinte fórmula aritmética.

Dessa forma, o desenvolvedor não entende realmente o negócio e o que / por que ele está fazendo essa tarefa. Isso pode ser OK se a especificação for realmente detalhada, mas quando não é ou quando o autor esqueceu um caso de uso, isso é muito difícil para o desenvolvedor encontrar uma solução.

Por outro lado, treinar todos os desenvolvedores para todos os aspectos do negócio pode ser muito longo e difícil.

Devemos dar mais importância à especificação detalhada (mas, como sabemos, a especificação perfeita não existe) ou deveríamos treinar todos os desenvolvedores para entender o domínio do negócio?

EDIT: tenha em mente em sua resposta que a empresa poderia usar desenvolvedores externos e que uma formação para todo o domínio pode ser de cerca de 2 semanas

    
por Jerome C. 05.10.2014 / 23:09
fonte

20 respostas

112

A especificação é praticamente nunca suficiente. Desenvolvedores que não possuem conhecimento de domínio não podem apontar quando a especificação está com erro (uma ocorrência freqüente na maioria dos lugares) e fazem escolhas ruins de design.

    
por 05.04.2012 / 21:58
fonte
63

Na minha experiência, tendo trabalhado em três setores muito diferentes agora, você pode começar não sabendo muito sobre o domínio, mas você precisará aprendê-lo eventualmente e alguém terá que entendê-lo em um grau detalhado.

O problema essencial é a impedância do desenvolvedor do cliente: eles querem algo, mas só o saberão quando o virem e você quiser resolver o problema deles, mas nem sempre terá uma idéia clara do problema. Quanto mais conhecimento de domínio da sua indústria (do cliente) você (o desenvolvedor) pode trazer, mais fácil você pode traduzir "desejos" vagos em "problemas" concretos e resolvê-los.

Como exemplo anedótico, meu trabalho anterior foi na indústria química envolvendo software de gerenciamento de plantas. Comecei com um conhecimento efetivamente zero do domínio, mas consegui implementar o código necessário para resolver os sub-problemas que o desenvolvedor sênior e os clientes me apresentaram. Com o tempo, fiz o esforço de aprender a indústria, para poder me comunicar mais prontamente no nível do cliente. Quando entendi sua indústria, comecei a entender quais eram os problemas reais. Quando eles dizem coisas como "precisamos rastrear todos os valores de dados neste módulo", posso traduzir isso para o que eles realmente querem dizer, que é "precisamos manter um registro histórico de cada valor gerado por esse sensor, armazenado por X dias de retenção, mas sempre avaliada com base na leitura mais recente desse sensor. " Muitos problemas de domínio têm regras ocultas (como períodos de retenção nos dados) que os clientes internalizaram, mas você precisa explicitar.

Então, sim, alguém precisa de conhecimento de domínio e, de preferência, de um desenvolvedor, porque problemas de domínio não são problemas de código e a tradução entre os dois não é trivial. Eventualmente, qualquer desenvolvedor que valha a pena manter em seu time deve pegar o domínio, para que eles possam fazer escolhas mais informadas sobre as nuances de seu código.

    
por 02.04.2012 / 17:05
fonte
16

ALGUÉM no projeto precisa ter conhecimento de domínio bastante completo. Essa pessoa pode ou não ser o desenvolvedor.

Nos projetos Agile, o proprietário do projeto do cliente é essa pessoa e eles estão trabalhando de forma colaborativa e próxima à equipe. Em projetos não ágeis, alguém na equipe precisa adquirir esse conhecimento, mas geralmente não, o que é uma das razões pelas quais os projetos não-ágeis são tão propensos a falhas.

    
por 02.04.2012 / 16:56
fonte
11

Existem muitas respostas excelentes. Eu adiciono o meu próprio porque depois de lê-los e procurar, descobri que ninguém menciona um problema chave: bugs .

Se a equipe não tiver pessoas suficientes com autoridade e domínio suficientes, mais cedo ou mais tarde os bugs surgirão inevitavelmente. Dado o conhecimento do domínio, existem valores / resultados / relações impossíveis ou não sensitivos. Pode-se esperar que uma especificação explicitamente os aponte, mas na realidade o melhor que você pode alcançar é evitar os mais óbvios (avisar-me se as taxas de juros ficarem negativas, ou coisas assim - isso poderia ser ou não um erro, mas é estranho o suficiente para ser digno de nota).

Isso está strongmente relacionado à compreensão das razões das escolhas e, nos melhores casos, também leva a um software melhor (porque, se alguém realmente sabe o motivo de uma solicitação, é capaz de pensar a respeito, em vez de aceitá-la como um dado).

Lembre-se que Einstein disse Mas pensamento e idéias, não fórmulas, são o começo de toda teoria física. ", é isso que se pensa não em termos de fórmulas abstratas, mas de idéias ...

    
por 02.04.2012 / 18:17
fonte
10

Se você colocar uma pessoa que saiba apenas inglês e uma pessoa que saiba apenas japonês em uma sala, ela não poderá traduzir do japonês para o inglês, apesar de ser especialista em seus respectivos idiomas. Pela mesma razão, mesmo programadores especialistas sem conhecimento de domínio são incapazes de descobrir o que precisam construir, mesmo quando têm acesso 24x7 ao melhor especialista de domínio que também não é especialista em desenvolvimento de software.

Uma especificação é uma tentativa de traduzir "japonês" dos requisitos de domínio para o "inglês" dos requisitos de programação. Quando você obtém uma qualidade de tradução comparável à do Google translate, esse é seu dia de sorte; Na maioria das vezes, a qualidade simplesmente não existe, então você não tem como adquirir pelo menos algum conhecimento de domínio. Com alguma persistência, faz de você um "tradutor" decente até o final do projeto, então seu valor para sua empresa cresce significativamente. Na maioria das vezes, você também se diverte muito no processo, por isso é uma situação ganha-ganha.

    
por 02.04.2012 / 18:07
fonte
8

Sem algum aspecto de conhecimento de negócios, você acaba com desenvolvedores que não fazem perguntas e codificam sem pensar o que as especificações dizem. Eu acredito que é preciso "Pensadores" para fazer um bom software, não apenas pessoas que podem bater em um teclado. Entender não apenas "O que" você está fazendo, mas "Por que" e como ele se encaixa no quadro maior ajuda a proporcionar maior satisfação para a equipe de desenvolvimento.

    
por 02.04.2012 / 18:15
fonte
6

Acho que você deve tentar obter o conhecimento do domínio. As especificações são uma lista de verificação que diz o que o produto final deve fazer e é necessário para a validação de seu produto. Como desenvolvedor, você deve sempre tentar entender qual é o problema real que você está tentando resolver. Obter o conhecimento do domínio ajudará você a entender isso.

Ele ajudará você a criar e codificar facilmente, pois entenderá o que está alterando as partes (digamos, conjunto de regras) e as colocará separadamente. Você não precisa ser um mestre nisso, mas seria capaz de falar com um usuário final em seu idioma .

Você pode dirigir um carro com conhecimento básico dele; mas no caso de você querer aproveitar o passeio, você precisa aprender mais sobre como usá-lo exatamente. Como com outras negociações, não é obrigatório entender o domínio, mas é divertido quando você o faz .

    
por 02.04.2012 / 16:59
fonte
4

Acho que um desenvolvedor que conhece o negócio vale seu peso em ouro.

Em um cenário "tradicional" em que a empresa tem alguns requisitos e alguns analistas de negócios os traduzem em requisitos técnicos, a empresa desenvolvedor trabalha fora daqueles que você inevitavelmente tem duas coisas que podem acontecer:

  1. Você tem vários pontos de falha. O analista de negócios pode não ter obtido todos os requisitos de negócios traduzidos com perfeição e / ou o desenvolvedor pode não traduzi-los em uma especificação técnica perfeitamente. Uma variante no cenário "segredo ao redor da sala". Apenas as exigências de comunicação.

  2. Um ou todos os proprietários de empresas, analistas de negócios ou desenvolvedores são novos o suficiente para a organização perder os itens principais que eles não pensariam normalmente. O desenvolvedor experiente que conhece bem o negócio pode ajudar a educar as pessoas nesses outros papéis para tornar o produto mais completo.

por 05.04.2012 / 22:18
fonte
3

Quase sempre há compensações a serem feitas entre o valor de cada recurso na especificação, o quanto a especificação deve ser implementada para valiosa e o custo de atender a qualquer combinação de recursos de especificação. Muitas vezes, boas compensações só podem ser feitas quando o conhecimento para fazer tudo o que foi mencionado acima existe em uma pessoa, ou em uma equipe de trabalho próxima, incluindo o arquiteto e / ou programador de software.

Sem esse conhecimento extremamente localizado e, possivelmente, até com intuição, o resultado pode facilmente acabar como um produto quase inútil e caro que atende muito de perto a especificação escrita.

O custo de criar uma especificação que não tenha os problemas acima pode ser maior do que treinar o arquiteto e / ou codificadores para ter conhecimento de domínio suficiente para trabalhar com uma especificação menos detalhada (assumindo que os contratos de negócios e legalidades permitem isso ).

    
por 02.04.2012 / 23:25
fonte
2
Quanto mais um desenvolvedor se torna e mais sênior no negócio, mais importante se torna ter pelo menos o conhecimento de domínio de nível médio ou as áreas mais diferenciadas da indústria que podem ser críticas não serão entendidas pelo equipe de desenvolvedores.

No entanto, uma especificação deve ser suficiente para tarefas de nível inferior. Em suma, é melhor treinar sua força de trabalho para um nível inferior. Eles podem ser os melhores programadores poliglotas do mundo, mas se não conseguirem entender a questão de maneira profunda, estarão sempre fadados ao fracasso ou à programação da marcha da morte.

    
por 05.04.2012 / 22:07
fonte
1

Sim, os desenvolvedores precisam conhecer os negócios de certa forma. Eles não precisam saber todos os mínimos detalhes, mas devem ter uma compreensão básica de qual relatório X é usado e como é usado no processo de negócios. Quanto mais seus desenvolvedores entenderem sobre o negócio, melhor será a solução que eles podem oferecer.

    
por 02.04.2012 / 16:57
fonte
1

Deve haver sempre alguma alguma especificação - você não pode esperar que todos os desenvolvedores se tornem especialistas em domínio. Ao mesmo tempo, se os desenvolvedores seguem cegamente uma especificação sem realmente entender para que servem, o resultado pode não ser realmente o que os clientes querem. Acontece com frequência que, quando um desenvolvedor tem um nível de entendimento decente (mas não especializado), ele pode detectar erros e omissões nas especificações. Eles também podem contribuir e dar feedback ao processo, o que pode tornar o produto final muito melhor.

Pode valer a pena contratar alguns especialistas de domínio cujo trabalho é estabelecer uma ligação entre os clientes e os desenvolvedores para ajudar a dar aos desenvolvedores uma melhor compreensão e também para ajudar a escrever as especificações.

    
por 02.04.2012 / 16:57
fonte
1

Acho difícil dar uma resposta de qualquer forma.

É difícil ver como, digamos, um desenvolvedor freelancer pode entender o negócio (ou a ciência) por trás de cada aplicativo que eles desenvolvem. Nessa situação, acho que é mais importante que o desenvolvedor saiba fazer as perguntas certas sobre a especificação ou o modelo de negócios do que realmente entender o próprio negócio.

Um desenvolvedor corporativo, por outro lado, supondo que eles estivessem no mesmo negócio por um tempo, realmente deveria ter aprendido como o negócio funciona depois de alguns meses (ou talvez anos). Em grande equipe, você também pode ter um arquiteto que entende o negócio com mais clareza do que os desenvolvedores.

Em PMEs com desenvolvedores solitários, é importante que o desenvolvedor tenha discussões freqüentes com os proprietários / gerentes para evitar sair e implementar a coisa errada.

Portanto, existem muitas maneiras possíveis de pensar sobre isso, mas a chave é a mesma em todos os casos: comunicação .

    
por 02.04.2012 / 16:59
fonte
1

O desenvolvimento de software é a única profissão que conheço que exige que você não apenas seja proficiente em sua profissão, mas tenha uma compreensão básica da profissão em que está trabalhando. É importante ter compreensão suficiente do domínio para se comunicar. com clientes e outros desenvolvedores no idioma do cliente. Como desenvolvedor, nem sempre é possível confiar nos outros para treiná-lo. Às vezes você tem que se esforçar com pesquisa pessoal, muitas vezes fora do horário normal de trabalho.

    
por 02.04.2012 / 16:59
fonte
1

Com base na minha experiência *, um indivíduo com bom conhecimento do domínio do problema e bom conhecimento do desenvolvimento de software tem maior probabilidade de encontrar a solução ideal para um problema do que dois indivíduos, um com excelente conhecimento do domínio do problema e um com excelentes conhecimentos de desenvolvimento de software, trabalhando juntos.

Acho que se trata do simples fato de que a comunicação que acontece no cérebro de um único indivíduo é muitas vezes mais rápida e melhor do que a comunicação entre os indivíduos.

* A principal experiência que estou usando para responder a essa pergunta é de mais de 10 anos gastos no desenvolvimento de um pacote de software de contabilidade (do início ao 'modo de manutenção'). Embora meu conhecimento em desenvolvimento de software tenha sido muito bom, comparado a meus colegas, muitas vezes me senti prejudicado pela falta de compreensão do domínio do problema.

    
por 02.04.2012 / 17:35
fonte
1

Eu gostaria de responder como alguém vindo do lado dos negócios, que trabalha com desenvolvedores que mostram pouco interesse em aprender o básico do comércio, às vezes até parece estar orgulhoso de não ter que saber sobre o básico: o problema é que os desenvolvedores não conseguirão ver erros no resultado à primeira vista (resultados impronunciáveis, sinais errados e assim por diante), o que requer casos de teste detalhados (que não desenvolvemos até recentemente), ou supervisão constante do resultados. Na medida em que estou disposto a aprender os fundamentos do desenvolvimento de software para facilitar a comunicação, gostaria de instar os desenvolvedores a fazer o mesmo.

    
por 03.04.2012 / 13:27
fonte
1

Você não precisa, mas por que você não quer?

Eu ficaria preocupado com qualquer programador que estivesse relutante e especialmente incapaz de aprender o domínio em algum grau. É importante sair da "torre do código de marfim" de vez em quando.

Escrever código sem ter ideia de como é usado e com que propósito soa como um trabalho terrível. Quem quer apenas quebrar tijolos quando você poderia construir catedrais?

    
por 03.04.2012 / 14:26
fonte
1

Eu realmente entendo o que você quer dizer com isso porque nós, como empresa em uma indústria de turismo, enfrentamos o mesmo problema. Quando eu era um desenvolvedor júnior, também estudava turismo em uma faculdade. Então, você pode imaginar que eu não estou vindo de uma formação em ciência da computação, mas meu conhecimento sobre turismo é alto.

Nós estávamos construindo produtos em relação a outras empresas de software na época, mas o conhecimento específico do domínio estava faltando muito. Como você descreveu, é realmente difícil acertar se você está construindo um produto na indústria do turismo, pois há muitas preocupações transversais, etc.

Então, esse movimento deu muitos resultados ruins a longo prazo. Então, demos um grande passo à frente e comecei a me concentrar apenas no desenvolvimento e não na parte de negócios do projeto. Como tenho conhecimento industrial e conhecimento de programação, o projeto se torna mais eficiente do que nunca. Para não mencionar, podemos então tomar decisões mais rapidamente desde que eu tenha a experiência em ambos os lados da moeda.

Como resposta concreta à sua pergunta, certamente é sim na minha opinião pessoal. Se o projeto em que sua equipe está trabalhando for um projeto de longo prazo, siga o caminho difícil e treine sua equipe em fundamentos e detalhes específicos de domínio.

    
por 05.04.2012 / 22:14
fonte
1

Se um desenvolvedor permanecer em uma empresa / indústria por um longo período de tempo, ele aprenderá "o negócio" lenta mas seguramente.

Algumas empresas reconhecem e fornecem treinamento em "negócios". As empresas financeiras são um bom exemplo disso.

Quanto mais você aprender o negócio, mais fácil será conversar com seus usuários. Eles vão sentir mais confiança em você. Você compreenderá mais prontamente as peculiaridades de onde um sistema pode dar errado se ele não funcionar como esperado para o usuário.

Para responder à sua pergunta, a especificação NUNCA é suficiente na minha experiência. O problema comum é que eles geralmente não contêm informações suficientes e ficam desatualizados rapidamente.

A experiência do domínio comercial pode ser obrigatória para algumas empresas. Eles procuram desenvolvedores com experiência no domínio ao contratar. Algumas empresas até colocam isso acima das habilidades técnicas atuais. (Sem experiência financeira, sem entrevista é muito comum, certamente aqui no Reino Unido).

    
por 05.04.2012 / 22:20
fonte
0

A partir da experiência pessoal, a especificação é suficiente, desde que você tenha alguém na equipe que trabalhe com você e que possua o conhecimento do domínio.

Eu trabalho em uma indústria muito especializada: fazemos softwares para transmissão de mídia. Eu mal sei nada sobre radiodifusão, mas conheço código e conheço dados, e tenho boas pessoas na equipe de gerenciamento de projetos que entendem de radiodifusão. Essa fórmula tem sido boa o suficiente nos últimos anos para que eu tenha uma boa funcionalidade que os clientes gostem.

    
por 05.04.2012 / 22:15
fonte