Como programador, como posso acelerar minha adoção e entendimento das regras de negócios?

Sou desenvolvedor há um tempo. Estou longe do melhor por aí. (Enquanto me sento sozinho nesta sala, me pergunto se sou o melhor aqui.) No entanto, cheguei a entender minhas ferramentas e a confiar em minha capacidade de raciocinar e aprender.

Ao iniciar um novo trabalho, sempre acredito que posso aprender a base de código se for um idioma que eu conheço. Se não é uma linguagem ou estrutura que eu conheço, acredito que posso entender os conceitos o suficiente para aprender (e apenas ler a documentação). Isso faz parte do nosso conjunto de habilidades como programadores e estou orgulhoso de poder cumprir esse padrão.

Por tudo isso, no entanto - uma das minhas principais fraquezas é aprender e internalizar regras de negócios para o cliente para o qual estou trabalhando rapidamente - seja um funcionário remunerado ou um contratado. Estou bem com as bases de código, mas as regras e os processos de negócios para um negócio específico sempre parecem levar um tempo para serem compreendidos. (Por exemplo, isso pode ser uma falha ao reescrever aplicativos corporativos.)

Como desenvolvedor, qual é a melhor maneira de assimilar regras e processos de negócios de maneira rápida e eficiente? É possível sem ser um especialista no assunto ou simplesmente ter anos de experiência com o cliente, empresa ou negócio?

Para mim, é lendo e compreendendo as bases de código.

Eu digo isso por duas razões principais:

1. As pessoas são péssimas. Ah, não deliberadamente (normalmente), mas nos negócios descobri que as pessoas geralmente têm um entendimento sutilmente diferente das regras de negócios. E todo mundo tem seu próprio modelo mental que, por sua vez, perde a fidelidade enquanto tenta comunicá-lo a você. Mas o código não mente. As pessoas podem pensar o que querem sobre como as coisas devem funcionar, mas o código está correto.

2. Construa uma fundação primeiro. Portanto, se todos têm seu próprio modelo mental de quais são esses termos e processos específicos da empresa, como você constrói o seu? Para mim, e espero para muitos programadores, eu construo meus modelos mentais da melhor maneira possível. O código possui padrões. O código possui abstrações. Tenho muita experiência em pegar código e construir um modelo mental a partir dele. Assim que eu tiver, pelo menos, uma forma vaga do que as coisas existem e como eles se relacionam, em seguida, eu posso falar com as pessoas de negócios. Então eu posso fazer as perguntas certas e encaixar melhor suas respostas no quebra-cabeça.

Não seja muito duro consigo mesmo. Às vezes eu me pergunto por que eles se incomodam em chamá-los de "regras" de negócios, mas acho que chamá-los de "maneiras como fazemos as coisas, a menos que existam outras coisas que se aplicam e depois as fazemos de maneira diferente" provavelmente as insultariam. Os negócios estão confusos. Eles atendem às necessidades de clientes, órgãos legais, contabilidade, regulamentos, fornecedores, funcionários, gerentes e governo local. Eles nem sempre têm um motivo.

Acho que a melhor maneira é garantir que você gaste tempo com o maior número possível de pessoas de negócios. Isso pode ser difícil para algumas pessoas em posições técnicas.

1. Planeje seu tempo e respeite o dele, mas consiga o máximo que puder.
2. Você precisará fazer perguntas. Eles não pensam como programadores, dividem tudo e têm um entendimento completo de como as informações se relacionam.
3. Não finja como você entende. Se você soubesse tanto quanto as outras pessoas de negócios, elas o obrigariam a fazer os dois trabalhos. Veja o item 2.
4. Não espere documentação. Ofereça muitos elogios, se você conseguir algum.
5. Aguarde críticas. Os processos e procedimentos podem ter redundâncias e outras possíveis eficiências de pousadas, mas pode haver uma razão para isso. Saiba o porquê, mas não fique chocado ao dizer: "Sempre fizemos dessa maneira".
6. Seja cortês, gentil e compartilhe seus lanches. Você está lidando com pessoas. Diga olá. Pergunte como eles estão. Pergunte por que eles entraram no setor, há quanto tempo estão na empresa.

Você não é um vazio chamado programador, é uma pessoa. Diga a eles que você está lá para facilitar o trabalho deles. Infelizmente, você pode ser o herói ou a cabra. É a natureza do nosso negócio.

Eu recomendaria a leitura de um livro chamado The 5 Elements of Effective Thinking, de Edward Burger e Michael P. Starbird. Está relacionado à compreensão de novos conceitos em geral, mas acho que se aplica a essa situação.

Aqui estão alguns pontos interessantes do livro:

Domine o básico

Se você não souber o básico, estará construindo seu entendimento sobre uma base instável. Então, você precisa fazer essas perguntas estúpidas que ninguém mais faz.

Deixe os erros serem o seu guia

Às vezes, ajuda a fazer perguntas claramente erradas, para que você possa descobrir sua falta de entendimento. (Ex: você quer dizer que os administradores têm acesso a todos os documentos? Ah. Por quê?)

Ensine ou explique a outras pessoas

Quando você tenta ensiná-lo a outra pessoa, começa a descobrir onde tem problemas para entender.

Espero que ajude!

Como desenvolvedor, percebi que traduzo diretamente o negócio em código, estruturas de dados, possíveis classes, etc ... Eu vou de algo abstrato e, muitas vezes, indefinido para algo específico, algo com "forma". Começo a codificar imediatamente e, a falta de informações , me leva a freqüentes refatores. Todo refatorador me faz pensar que existem muitas lacunas na minha compreensão dos negócios .

Como eu comecei a resolver isso?

Eu me forço a ler todos os documentos feitos durante a análise funcional e as fases anteriores. Eu tento fazer isso como se eu fosse o cliente ou o usuário final . Preciso entender o que o cliente está procurando com esse aplicativo e requisitos. Mas preciso ficar longe do dev sou.

Nosso trabalho nos fornece uma grande habilidade que os clientes não possuem. Pensamos em estruturas condicionais de uma maneira que os outros não. Então começo a confrontar requisitos. Procurando contradições ou incoerências . Um pouco de cérebro invadindo o que eu entendi. Formulação de cenários hipotéticos.

Isso me levou a perguntas e dúvidas. Eu digito todos eles e finalmente marquei uma reunião com quem puder resolver minhas dúvidas.

Resumindo, mudo meu ponto de vista. Eu tento olhar para o problema de outra perspectiva. Mas eu coloquei algumas habilidades de desenvolvedor no processo. O que acaba em um bom monte de perguntas e dúvidas a serem resolvidas. Uma vez resolvido, meu entendimento do negócio é mais profundo.

Estudo> Dúvidas> Perguntas> Respostas> Compreensão (repita o ciclo repetidamente)