O que acontece durante a automação normal? Uma tarefa técnica, requisitos funcionais, arquitetura e vários outros pedaços de papel são elaborados. Descreve todas as condições, limitações, algoritmos de trabalho, dependendo do ambiente, aparência de formulários, validação de dados, etc. Muitas vezes, o design e a coordenação desses pedaços de papel levam mais tempo que a própria automação.
Um projeto aparece, um cronograma, uma decomposição de tarefas, um determinado gerente de projeto ou até vários. As formalidades assumem o controle, ou seja, forma, não conteúdo.
É claro que, em algumas situações, esse é o caminho para agir. Por exemplo, se uma empresa externa estiver envolvida em automação, ela não sobreviverá sem esses documentos. ele só perseguirá depois de atingir os requisitos de fuga. Os papéis garantem estabilidade, previsibilidade de pagamentos e entrega do trabalho. Mas para o cliente, esses pedaços de papel garantem apenas uma coisa - um projeto longo e chato que não trará nenhum benefício.
Na programação de negócios, essa abordagem não é adequada. Deixe-me lembrá-lo de que a programação de negócios é uma mudança complexa, ao mesmo tempo para processos, motivação, objetivos, sistema de gerenciamento, suportado pela automação.
Por exemplo, você decide alterar o processo. Ninguém que afeta mil pessoas - não há solução para você. O processo, por exemplo, envolve cinco pessoas de um departamento. Todas essas pessoas, como seu líder, estão sentadas ao seu lado - aqui estão elas, a uma distância de um braço. E você decidiu, junto com eles, mudar o processo. Eles se sentaram, conversaram, descobriram, pensaram e decidiram. Por exemplo, você levou um dia para alterar o processo.
Na maioria dos casos, após alterar o processo, você precisa de automação - é necessário fazer alterações no sistema de informações. Se você diz - precisa de uma tarefa técnica, um cronograma, um projeto com um líder, curador e patrocinador, então é tudo. É aqui que suas alterações terminam. Um longo projeto de automação com formalidades negará a alteração do processo.
O que é especialmente importante: mudanças nos processos são experimentos. Você, mesmo sendo um programador de negócios sofisticado, não pode ter certeza se sua alteração funcionará ou não. O método escolhido pode se mostrar bem em outro processo, ou mesmo exatamente no mesmo, mas em uma empresa diferente, mas, nesse contexto, pode se mostrar inoperante.
Por se tratar de um experimento, possui prazos - hoje foi pensado, foi lançado amanhã, analisamos por uma semana e tomamos uma decisão. Se tudo estiver bem, vá embora. Caso contrário, pensamos melhor - cancele a alteração ou refine e melhore.
O que acontecerá com a automação nesta semana? Se você escolher o caminho tradicional, em uma semana você terá apenas a tarefa técnica e, na melhor das hipóteses. Dessa forma, a implementação das alterações deverá ser feita manualmente, sem automação. Bem, se você fizer alterações que não exijam automação - poderá verificar "a olho nu". E se não?
É aqui que o princípio da automação rápida é necessário. Na verdade, sua essência está no nome - as alterações no sistema devem ser feitas rapidamente, sem coordenação e requisitos, exatamente na medida necessária para testar a principal hipótese que você propõe, alterando o processo.
Você não precisa se preocupar muito com a interface, verificando os dados de entrada, a otimização do código, a estrutura de dados e outros pilares da automação "correta". Sua tarefa é oferecer suporte rápido à automação de alterações no processo para verificar se elas funcionam ou não.
O princípio da automação rápida é conhecido por todos os programadores. Só eles sabem disso não como um princípio, mas como um grande mal - acredita-se que a ignorância, a mediocridade e os iniciantes estão envolvidos em tal automação.
Em parte, os programadores estão certos. Mas eles têm um contexto fundamentalmente diferente. Geralmente, afinal, como é feito. Existem alguns "trapaceiros" - analistas de negócios, usuários e seus líderes. Eles criaram algo lá e dizem - então, rapidamente me faça uma forma / campo / janela. O que, como, por que, por que - não explique. Ainda acrescente - vamos lá, botas. O que resta para o programador? Se houver uma oportunidade, ele começará a se mexer - diga que é impossível que você precise de uma tarefa técnica, arquitetura cuidadosa, refatoração etc. Mas, como regra, não há possibilidade de trapacear, e o programador simplesmente faz isso rapidamente, "de joelhos", no modo de programação extremo.
Bem, mais ou menos, para o inferno com ele, certo? Eu propus exatamente isso - rapidamente, sem problemas, se ao menos funcionasse?
Um momento chave surge quando os “traidores” veem a falta de sentido da mudança. O programador de negócios simplesmente cancela essas alterações e pede ao programador para excluir os trechos de código introduzidos. E o "trapaceiro"? Ou, mais precisamente, "trapaceiro da tristeza"?
Ele não cancelará nada. Apenas deixe como está e, na melhor das hipóteses, continue fazendo as alterações. Você entende? Sem cancelar os anteriores, os novos serão encerrados cada vez mais.
Há um momento político, especialmente se o chefe do departamento tiver apresentado as mudanças. É extremamente importante para ele não parecer estúpido, portanto, não importa que bobagem ele tenha inventado, ele não a cancelará. Além disso, se você empurrá-lo contra a parede, ele protegerá suas alterações.
Na maioria das vezes acontece que ninguém usará as alterações feitas. Se você é um programador, essa situação pode ser familiar para você. Eles pediram, ordenaram, exigiram criar algum tipo de sistema e depois não o usaram. Pode até ser feito não "no joelho", mas normalmente, em conformidade com todos os requisitos e condições da automação "correta", mas ainda assim eles não a usam. Agora você sabe o porquê. E por que ninguém remove essa funcionalidade do sistema - você também sabe agora.
É assim que as tortas em camadas de automação sem sentido e retalhos se desenvolvem. Os programadores riem, mas fazem o que dizem. Estrume, não otimização, estrutura de curvas e arquitetura crescem como uma bola de neve. E quanto mais longe, mais difícil será parar esse processo e revertê-lo.
Outro problema é a falta de sentido das mudanças propostas como um todo.
Na programação de negócios, qualquer mudança tem um objetivo que todos os participantes entendam. O processo deve se tornar mais rápido, mais confiável ou mais controlado. Portanto, o objetivo das mudanças e os critérios para avaliar sua eficácia são sempre claros.
Mas quando as alterações são feitas “exatamente assim”, ou “para torná-lo mais conveniente para mim”, ou “bem, tão bem!”, É impossível avaliar o resultado. Portanto, as mudanças, não importa quão sem sentido elas sejam, permanecem vivas - tanto no processo quanto na automação.
Agora você entende qual é o problema - a lacuna entre mudança de processo e automação. Quando algumas pessoas apresentam alterações no processo e depois definem tarefas de automação para outras pessoas, sem explicar o significado e a essência, obtemos uma bagunça comum que não beneficia ninguém.
Pelos padrões da programação de negócios, o trabalho é realizado em uma equipe - existem pessoas de processos e pessoas de automação. Melhor ainda, quando esse trabalho é liderado por uma pessoa - um programador de negócios. Ainda melhor quando ele mesmo faz a automação.
Nesse caso, entendemos e gerenciamos o ciclo de vida das mudanças temporárias - por que elas são feitas, quando começam e, o mais importante, quando e sob quais condições elas terminam.
Suponha que as mudanças estejam erradas - isso é normal, não há nada errado com isso. Em seguida, os programadores têm um trabalho incomum - excluir alterações no sistema. Obviamente, eles mesmos fazem esse trabalho - refatoração, por exemplo. Mas no caso da programação de negócios, esse trabalho deve ser realizado periodicamente.
E se as mudanças estavam corretas? Então, todas as habilidades da automação "certa" entram em jogo, das quais os programadores se orgulham. Você precisa estimar a arquitetura, estrutura de dados, algoritmos, verificação dos dados inseridos, interface, etc. Mas qual é a diferença, veja?
A diferença na forma da declaração do problema. Geralmente, essa é uma tarefa técnica, isto é, um pedaço de papel. No nosso caso, a tarefa é um protótipo. Um trabalhador que demonstrou sua utilidade e eficácia, testado, por assim dizer, em batalha. Só é necessário lembrá-lo. Você realmente não precisa coordenar e discutir nada - basta pegar e criar um sistema de acordo com as regras e padrões do ambiente em que o programa é criado.
Se você se engajar em programação rápida o tempo todo, adquirirá rapidamente a habilidade - faça-a imediatamente para corrigi-la mais tarde. Aqui, a “preguiça certa” do programador estará presente em nossas mãos - ele não estará disposto a resolver o mesmo problema duas vezes e descobrirá como criar rapidamente um protótipo e transformá-lo em uma solução completa com o mínimo de esforço. Embora, na programação de negócios, é claro, não haja soluções completas.
Agora, tornou-se prática comum, como prototipagem e modelagem, quando antes de iniciar um grande projeto de automação, rapidamente, com o mínimo de esforço, sem problemas com a interface, eles criam um certo protótipo do sistema futuro. Como você sabe, isso é muito semelhante ao princípio da automação rápida, embora o ponto, é claro, não seja como o protótipo foi criado, mas como ele se adaptará a um ambiente em mudança.
Se a prototipagem é apenas uma jogada de marketing de uma empresa integradora e, de qualquer maneira, um grande pedaço de papel aparece, como uma tarefa técnica, isso é apenas um truque. Cria a ilusão do cliente de que "tudo será como eu preciso", mas, infelizmente, não será assim na vida. O protótipo não terá vida longa e desaparecerá na obscuridade.
E agora você entende o porquê. A automação é quase sempre uma carroça, não um cavalo. O cavalo é uma mudança de processos e a carroça segue. Mas só cavalga se estiver preso a um cavalo.
O cavalo virou, a carroça o seguiu. Com um atraso, com folgas e desvios, mas virou-se. E se cada cavalo e carroça vivem suas próprias vidas, então o carro deve ser carregado por programadores infelizes. Um grande protótipo de um grande sistema criado antes de um grande projeto de automação é um instantâneo, um instantâneo de um cavalo preso a uma carroça. Tudo é lindo, todo mundo fica feliz, todo mundo gosta, mas passa um dia, uma semana ou até um mês, e o cavalo joga a carroça e vai para onde precisa. E o carrinho é bonito, elegante, feito de acordo com todos os cânones, resta permanecer sozinho no campo.
Portanto, a prototipagem “grande” não vale a pena. Assim como a "grande" automação. Para iniciar e executar um grande projeto de automação, é preciso ter uma mente extraordinária, previsão e talento incrível em gerenciamento. Se essas palavras são sobre você, eu sinceramente os parabenizo e desejo a você todo sucesso.
Eu recomendo o resto para usar o princípio da automação rápida.
E, mais uma vez, lembro: a automação acompanha a mudança de processos. Não antes de uma mudança, não em vez de uma mudança, não separado da mudança. Eles mudaram o processo, rapidamente automatizados, analisaram o resultado. Bom - lembre-se rapidamente. Não é bom - jogue fora.