👥 🎲 🈲 Como evitar a indignação da programação? Dicas do integrador 🚆 🎍 ⏏️

Em um artigo anterior sobre os problemas da introdução do ERP em empresas industriais como um estudo de caso, um dos pontos foi levado ao "caos programático".

Temos um cliente cujos funcionários agora, enviando-nos requisitos duvidosos, especificam se isso é uma ilegalidade programática. E alguns não especificam, mas criam.

O tópico é relevante e decidi escrever um artigo separado sobre ele.

O que é isso?

Que tipo de pintura sua imaginação pinta quando você ouve a frase “ilegalidade programática”?

Um homem barbudo, com um olhar inteligente e pensativo, bate no contador-chefe choroso com um volume de Knut, dizendo: "Kopek, você diz que não concordou com a fatura? O destinatário não cabe na célula? Agora vamos carimbar com um livro e tudo vai dar certo! ”

, - . , : « 10 , ? ? , ?» — , - … : « – : , . : … …»

Esse fenômeno é menos colorido do que você pode imaginar, mas mais terrível. No final, o contador-chefe pode se acalmar, enxugar as lágrimas e enviar para um psicólogo, os mestres podem ser desamarrados de uma cadeira e enviados para o trabalho. Mas as curvas de lançamento no InventTrans e quebradas devido a erros de cálculo na arquitetura da solução e melhorias desnecessárias, o psicólogo não corrigirá o planejamento resumido.

A ilegalidade programática é uma situação em que, como resultado da programação, cujo objetivo era resolver certos problemas de uma empresa, outros problemas, muitas vezes mais sérios, são criados.

Deixe-me dar alguns exemplos:

, , . - , .
. , , «» . . , , .

Eu queria nomear o artigo “Caos do programador. Crying integrator ”, mas percebeu que ninguém se importa com as nossas lágrimas. Mas dicas sobre como evitar tais situações podem ser úteis.

Vou tentar delinear os limites das minhas recomendações com antecedência - estamos falando sobre:

programadores envolvidos na implementação ou manutenção de sistemas ERP. Eu acho que eles têm requisitos ligeiramente diferentes dos que, por exemplo, os desenvolvedores de um novo produto ou tecnologia;
programadores que trabalham com o cliente. Os desenvolvedores do integrador são menos propensos a "indignação".

Então, quais são as causas desse fenômeno e o que pode ser feito sobre isso?

Relutância ou incapacidade de olhar para a essência do processo

Costumo ver isso com analistas e programadores iniciantes. Eles simplesmente respondem à pergunta que o cliente lhes fez. Eles não pensam sobre isso - por que ele perguntou sobre isso, ele realmente precisa? Com o tempo, isso passa, mas no começo você precisa entender e explicar.

"E você pode aumentar o número de casas decimais para esse coeficiente para 4?" - "Claro". Mas nada que esse coeficiente seja usado para indexar o parâmetro, que tem uma precisão de 1 casa decimal, e os valores não excedem 50? Toda a precisão do coeficiente será arredondada. Então talvez seja melhor não fazer isso?

“Adicione um novo campo desse tipo à referência da nomenclatura” - “Bom. A complexidade de 15 minutos. " Então, por que você precisa desse campo nas nomenclaturas? Essa é uma característica que varia de uma parte para outra. Talvez seja melhor adicionar este campo ao diretório de partes?

Um desenvolvedor de ERP não precisa ser apenas um implementador das alterações que os usuários fazem. Ele precisa entender a lógica do sistema e agir como seu protetor contra todo absurdo. Para fazer isso, seria bom entender os processos de negócios, pelo menos no nível do senso comum, e poder fazer perguntas desconfortáveis aos usuários.

Portanto, se um dos usuários nunca recorreu a você com reclamações sobre a insolência de um programador que se recusou a implementar sua lista de desejos, esse desenvolvedor deve examinar mais de perto. Talvez ele apenas faça o que eles dizem. E isso raramente termina com algo bom.

Falta de resistência na luta contra o desejo de deixar tudo do jeito antigo

Este é o caso quando a bagunça do programador não é criada pelos desenvolvedores, mas com sua conivência.

Qualquer produto sério possui não apenas um conjunto de determinadas funções, mas também uma ideologia, melhores práticas. E as pessoas querem trabalhar da maneira antiga. E eles pressionam o programador para oferecer a ele essa oportunidade. E se ele não pudesse provar que isso não deveria ser feito, tudo poderia acabar tristemente.

, , , . . : « 1974 , , ». , , , , . « , , – ». , , , . , . , , . : , , - , . : «».

O que pode ser feito com isso? Para começar, não subordine o programador a serviços econômicos. Ele deve trabalhar em outra unidade e ter alguma independência do gerenciamento de departamentos cujo trabalho é automatizado.

Seria bom acrescentar mais um link a essa cadeia: quaisquer melhorias sérias devem ser aprovadas não apenas pelo contratado, mas também por alguém que entenda os negócios da empresa como um todo e tenha poder. Essa pessoa pode definitivamente dizer: "Não".

O hábito de resolver todos os problemas através da programação

O amor pela automação leva ao progresso, mas às vezes prejudica. Testemunhei como, em vez de instruir as pessoas a inserir manualmente dados no sistema, essa entrada foi automatizada. Automatizado, esquecendo alguns detalhes ou recursos que seriam necessariamente notados, discutidos e provavelmente corrigidos com a entrada manual. E assim - todos têm certeza de que não há erros, mas depois de um tempo as consequências surgem em massa, o que já é muito mais difícil de corrigir do que a causa raiz.

, , . , , , . . , . , , . : .

Portanto, quando um programador é solicitado a escrever um script para corrigir 200 erros que surgiram devido ao fato de os usuários não funcionarem de acordo com as instruções, ele não deve se precipitar no teclado. Precisamos estimar quanto tempo leva para corrigir um erro manualmente, e se o tempo para corrigir todos os erros manualmente não exceder a complexidade de escrever um script por uma ordem de magnitude, peça aos usuários que corrijam esses erros por conta própria: há mais chances de que eles funcionem de acordo com as instruções no futuro. Isso deve ser introduzido como regra, pendurado na parede perto do programador para que ele possa colocar todos os visitantes nesse pedaço de papel.

Além disso, por algum motivo, pensamos que, se as pessoas se libertarem do trabalho de rotina devido à automação, elas farão algo útil: começarão a oferecer idéias para melhorar os processos de negócios, otimizar os relatórios e treinar colegas menos experientes. Mas provavelmente eles simplesmente terão mais tempo para tomar chá, parar de fumar e a Internet no trabalho. Então isso vale a pena?

Auto confiança

Há uma funcionalidade que não deve ser modificada. No Axapt, isso é, por exemplo, planejamento mestre. Na minha memória, tocamos nele apenas duas vezes. E cada vez que ele não estava incorporado no código, mas um tipo de "mancha" - funções executadas antes ou depois do planejamento consolidado. E mesmo assim, recordo essas melhorias com saudade.

Existem lugares menos óbvios onde você não deve subir. E uma ótima maneira de distinguir um programador experiente de um iniciante é oferecer refinar essa funcionalidade: um experiente será surpreendido e recusará, poderá aconselhar a otimização do processo de negócios e o iniciante dirá: "Vamos lá".

Aqui, uma coisa pode ser aconselhada: contratar pessoas com experiência que, já de outros clientes ou em outros projetos, tenham todos os obstáculos que, em princípio, poderiam ser preenchidos.

Falta de regulamentos de desenvolvimento

Quando tomamos um projeto para suporte, um dos primeiros documentos que solicitamos ao cliente são os regulamentos de desenvolvimento que descrevem o ambiente de desenvolvimento, regras para nomear objetos, proibições e restrições. O mais estranho é que às vezes isso não acontece. E este é um sinal claro - haverá lixo no código: a partir da clássica falta de comentários e terminando com situações em que valores específicos de diretórios para diferentes ramos do algoritmo foram escritos diretamente no texto. E o lixo no código é o primeiro passo para problemas com os negócios.

Portanto, não fale sobre o fato de que “programar é uma arte. Não é regulado "," mas e o ágil? " e isso é tudo. Se você está desenvolvendo, deve haver um regulamento. E isso não é de 3 pontos:

o desenvolvimento é realizado no aplicativo dev;
o teste é realizado no aplicativo de teste;
O código deve ter comentários.

Este deve ser um documento completo com dez páginas e seções:

Requisitos para aplicativos de desenvolvimento.
Requisitos para escrever a declaração do problema.
Requisitos para escrever código.
Requisitos de teste.
Requisitos de migração entre aplicativos.

Como regra, todo o código rígido é feito de acordo com o princípio "Vamos fazê-lo rapidamente e depois normalmente". É feito rapidamente, e depois é esquecido ... E quando há um documento assinado que afirma que isso não pode ser feito, você sempre pode cutucá-lo e dizer ao usuário: "Não vai dar certo rapidamente, é proibido trabalhar assim. Desculpe, Alevtina Svetozarovna, ficarei feliz em comentar todas as verificações diretamente no trabalhador, mas elas vão me demitir. ”

Solidão e falta de controle

Um programador solitário é mau. Sempre deve haver alguém que diga: "Bem, o que você, tolo, fez?" - Caso contrário, o desenvolvedor relaxa, esquece as regras, esquece a responsabilidade. É aí que o código rígido começa, decisões arquitetônicas dúbias, erros que afetam os negócios.

De uma maneira inteligente, isso é chamado de "revisão de código" e isso é algo que deve sempre acompanhar os regulamentos de desenvolvimento. Após cada revisão, antes de testá-la, deve-se verificar a conformidade do código com os regulamentos de desenvolvimento e as melhores práticas. Uma revisão de código permitirá:

controlar a qualidade do desenvolvimento;
treinar programadores menos experientes.

Portanto, os desenvolvedores devem ter pelo menos três partes (duas sempre concordam que você não pode fazer nada, uma terceira parte do sistema reduzirá significativamente a probabilidade de conluio). E eles devem funcionar de acordo com os regulamentos internos, um dos pontos principais dos quais é a revisão obrigatória de código.

Conclusão

Portanto, para reduzir a probabilidade de "ilegalidade programática", é necessário formar seu próprio departamento de desenvolvimento interno de acordo com as seguintes regras:

Deve ser uma equipe de pelo menos 3 pessoas.
Pelo menos um membro dessa equipe deve ter experiência na implementação ou manutenção de um sistema ERP; esse deve ser o seu nono projeto, em que n> 3.
Idealmente, o departamento de desenvolvimento deve se reportar diretamente ao CEO.
Às vezes, os usuários finais devem reclamar que os programadores se recusam a implementar alguns de seus requisitos.
Mesmo para um departamento tão pequeno, é necessário desenvolver regulamentos, cuja violação deve ser punida.

Naturalmente, esta é a minha visão. Pode-se argumentar que, para cada um desses pontos, até eu posso dar contra-exemplos da minha experiência quando o requisito não foi atendido, mas tudo estava perfeito. Mas essas recomendações podem ser usadas como ponto de partida para a formação de seus princípios de combate à ilegalidade programática.

Como evitar a indignação da programação? Dicas do integrador