Existem muitas circunstâncias que podem ser catalisadoras para a criação de software ruim: as ferramentas utilizadas, a qualidade da comunicação em uma equipe, as qualidades pessoais dos desenvolvedores, metodologias etc. E há uma coisa entre eles que é a raiz de quase todos os outros: problemas imaginários.
A maioria dos softwares complexos ou zagabovannoy não foi planejada para ser complexa e, mais ainda, zagabovannoy. Foi simplesmente criado para executar não as tarefas que estão na base do plano original.
História do Podcast
Vamos imaginar que você esteja gravando um podcast popular e, em algum momento, esteja pensando em criar seu próprio site - bem, com informações sobre o seu podcast, registros de edições anteriores, artigos e talvez alguma publicidade. De fato, quanto você pode compartilhar o lucro com alguns editores externos?
E assim você decide contratar pessoas que criarão este site para você. Você escreve requisitos absolutamente claros para eles:
- Carregamento rápido do site na América do Norte
- Suporte para download de versões anteriores de podcasts e transmissão ao vivo das atualizações atuais
- A transmissão não deve cair ou congelar durante os primeiros 15 minutos para 99,99% dos usuários. Nunca desejável, mas mesmo assim.
- Integração com o Google Adwords (e no futuro, possivelmente com análogos)
- Integração com as transmissões do Facebook, porque você gasta suas transmissões. Se você pode criar uma solução alternativa que permita transmitir de forma mais conveniente - ainda melhor.
Você fornece esses requisitos aos desenvolvedores e, talvez, se comunique um pouco com eles. 2 meses se passam. Eles mostram uma demonstração e você está coberto de manchas vermelhas. Fica claro que você jogou US $ 15.000 no abismo. O que eles mostraram a você é completamente inaceitável de qualquer lado, apenas um monte de lixo. Você quer seu dinheiro de volta, mas o trem já foi embora.
Ficar bravo com a visão de um site demonstrado é muito simples. Na primeira abertura, tudo congelou. Pareceu funcionar e você perguntou como alterar o tipo de publicidade que será exibida no site. Eles mostraram uma interface de torção e bicicleta para isso, que é simplesmente irrealista dominar por conta própria. Os fluxos do Facebook são lentos. Tudo é terrível.
Mas a equipe de desenvolvimento não entende por que você está chateado. Do ponto de vista deles, eles conseguiram um feito, tendo fabricado um produto tão complexo em apenas 2 meses. Eles colocaram todo o seu talento nele, toda a sua alma. Julgue por si mesmo quais recursos maravilhosos eles adicionaram a ele:
- Sistema de recomendação incrível
- Algoritmo de reconhecimento de fala que exibe legendas sob sua transmissão EM TEMPO REAL !!!
- A página principal do site carrega 200 ms em qualquer lugar do mundo
- O protocolo de transmissão e o cliente são escritos do zero, e o Facebook foi adicionado por um plugin. Você pode adicionar plugins para outras plataformas a qualquer momento!
- É possível integrar com 20 plataformas de publicidade diferentes
Você já vê qual é o problema, certo? Você solicitou um produto muito específico e altamente especializado, com alguns recursos adicionais necessários. A equipe de desenvolvimento ouviu de forma diferente. Para eles, todos os seus "desejáveis", "mais convenientes" e "no futuro" se transformaram em uma tarefa emocionante para desenvolver um produto comum, expansível, escalável e suplementado de enormes proporções, durante a implementação da qual você pode heroicamente resolver vários problemas interessantes. Bem, e, é claro, não há nada para se distrair com pequenas coisas, como polir e trazer ao ideal a funcionalidade básica do produto - temos qual escala, não há tempo para trocá-lo agora!
Outro problema é que você provavelmente não se comunicou diretamente com os desenvolvedores diretos do sistema. Você tocou um telefone mimado: conversou com um vendedor que entregou tarefas a alguém da gerência intermediária de sua empresa, escreveu especificações de negócios lá, entregou-as ao gerente de projeto, ele escreveu especificações técnicas e entregou-as ao líder da equipe, que as dividiu em tarefas e entregue aos desenvolvedores. Bem, cada um dos desenvolvedores também entendeu e realizou suas tarefas no contexto de seu entendimento.
Mecanismo de prevenção da realidade
Problemas imaginários são mais interessantes de resolver do que problemas reais. Pessoas muito inteligentes jogam jogos complexos, resolvem problemas de matemática, escrevem livros sobre tópicos abstratos - de graça ou quase de graça. Ao mesmo tempo, o programador de classe média de um aplicativo móvel bastante padrão definirá uma conta muito substancial. Isso não ocorre porque um programador comum é mais difícil de encontrar do que um gênio. Isso ocorre porque é fácil e agradável realizar tarefas interessantes, mas não uma rotina.
A maioria dos programadores deseja trabalhar em tarefas interessantes e obter um bom dinheiro por isso. Isso é difícil de conseguir. Claro, você pode especular sobre o que é um "problema interessante", mas para a maioria dos desenvolvedores é algo muito próximo da fronteira do campo de problemas teoricamente solucionáveis. Algo difícil de alcançar, mas possível.
Dê a uma pessoa racional muitas tarefas rotineiras e não automatizadas e, mais cedo ou mais tarde, você a trará ao controle. O cérebro humano, no entanto, após milhões de anos de evolução, desenvolveu alguns truques diferentes para se manter em um estado adequado. Como as vítimas de violência são capazes de escapar para o mundo de suas fantasias, tão inocentemente condenadas a anos de desenvolvimento empresarial ou freelancer na Web ao longo do tempo encontram salvação na solução de problemas imaginários.
O número e a complexidade dos problemas inventados são funções do nível de imaginação do programador e da complexidade de suas tarefas reais. Deve-se notar que essa abordagem em si não é exclusiva dos desenvolvedores de software. Gerentes, vendedores, RH, suporte, advogados e contadores encontram suas próprias maneiras de criar e superar heroicamente problemas inexistentes. Eles se envolvem em decisões que estão além de sua competência, falam em reuniões em que sua presença é pura formalidade e assim por diante. Eles também superestimam a escala dos problemas e seu papel na solução deles ("Nosso novo aplicativo Doggy Diary deve ser 101% compatível com o GDPR desde o primeiro dia! Não podemos esperar que o cliente reclame!"). Eles inflam a equipe para criar a aparência da importância do trabalho de sua equipe e, em seguida, lidam com os problemas de crescimento, escala e logística (e sempre haverá esses problemas em uma equipe grande).
Muitos dos desenvolvedores são inteligentes, mas muitas de suas tarefas são bem idiotas. Essa contradição força as pessoas inteligentes a pensar em outras, embora não existam na realidade, mas em tarefas interessantes.
Arquitetura de telefone mimada
Às vezes, problemas imaginários não são o resultado das fantasias de desenvolvedores entediados. Às vezes, este é o resultado de um "telefone quebrado".
Eu trabalho freelance às vezes. Quando eu comecei, eu não tinha dinheiro para resolver os clientes. Isso significava a necessidade de levar todos em fila e observar de todas as cores as mais diversas manifestações de desvios da psique humana. Eu vi cadeias de centenas de letras sobre o assunto de detalhes de protótipo completamente imateriais. Vi pessoas mudando absolutamente todos os parágrafos da especificação toda semana. Eu tive clientes que, para projetos de alguns sites triviais, perguntaram sobre a oportunidade de sair imediatamente com eles para a OIC ou vincular inteligência artificial a eles.
Havia clientes bastante sensatos que, no entanto, careciam de conhecimento (ou vocabulário?) Para expressar todos os seus requisitos em formulações compreensíveis. Isso por si só não é um problema. Parte do trabalho dos desenvolvedores de software é precisamente a coleta de requisitos e a redação de especificações. É para isso que pagamos, incluindo dinheiro, e esse trabalho pode ser feito mais ou menos normalmente se você tiver acesso normal ao cliente e tempo suficiente. O problema é que às vezes esse acesso não é e existem vários intermediários entre você.
A maioria das empresas gosta de ter "vendedores" em posts separados. São pessoas especiais que procuram clientes em potencial, discutindo tarefas, prazos e preços com eles. São essas pessoas que podem descobrir as mais úteis e fazer mais perguntas. Mas essas não são as pessoas que escreverão este projeto. Entre vendedores e programadores, existem 2, 3, 4 ou mais camadas de gerentes, arquitetos, analistas e líderes de equipes de nível médio e baixo. Sim, podem ser pessoas muito qualificadas. Mas ainda assim - essas são camadas adicionais. Não importa o quanto tentem, as informações que passam por eles mudarão. Alguém descartará algo (em sua opinião) que não é importante, outro esclarecerá algo não especificado, mas (em sua opinião) óbvio, o terceiro substituirá a expressão estúpida pelo termo correto (como ele tem certeza) - e agora a tarefa inicial não poderá mais ser reconhecida. Um vendedor pode lançar uma frase para o cliente como "mas por 39.999 também podemos fazer isso na blockchain". Se o cliente morder, a equipe de desenvolvimento terá que quebrar o cérebro em dois níveis abaixo, mas como isso pode ser feito no blockchain. Mas já é vendido e pago, vamos fazer.
Assim, o problema original se perde na especulação e no repensar. Os hiatos entre os novos problemas inventados (se eles nem sequer existiam) e há pessoas que desejam preenchê-los com seus próprios problemas imaginários e suas soluções brilhantes. Porque ainda é liberdade, não rotina.
Complexidade artificial e seleção natural
Muitas vezes, há um lado ainda mais sombrio. Inventar problemas e métodos imaginários para resolvê-los pode se tornar o motor do crescimento da empresa e, no futuro, talvez seu principal negócio, a parte mais importante de sua existência, que não pode ser abandonada.
“Pessoas selecionadas para resolver problemas complexos não têm incentivo para resolver problemas simples” - Taleb
Você já ouviu falar dos três principais engenheiros que subitamente descobriram que o banco on-line é, em geral, uma coisa bastante simples? Eles criaram software simples e, portanto, sem problemas, usaram as técnicas e linguagens de programação corretas e depois transferiram todos os principais bancos para sua plataforma.
Não, não ouviu? Isso é porque não era. Mas o que aconteceu, é e será - equipes separadas de milhares de programadores que trabalham para bancos diferentes e, durante alguns anos, literalmente, meio ano, capazes de usar toda a equipe para implementar um recurso como "transação de reversão". É assim que o software bancário é escrito, sim.
E isso, é claro, não é porque mover um número de uma coluna para outra é tão difícil, não. Não é difícil. Aqui, indexe toda a Internet e exiba resultados relevantes de pesquisa em uma fração de segundo - isso é difícil. No entanto, dois caras na garagem fizeram isso. E para a reversão da transação, são necessárias 1000 pessoas e seis meses.
O problema aqui é que o ecossistema bancário é incrivelmente bom em sua principal tarefa - apoiar o ecossistema bancário. As rodas estão girando, os papéis estão farfalhando e amanhã tudo será o mesmo de ontem. Tudo tem inércia. E, se estivermos trabalhando em um problema imaginário nos últimos 5 anos, também trabalharemos amanhã.
“É difícil fazer uma pessoa entender alguma coisa se receber o salário por não entender.” - Upton Sinclair
E todo mundo continua trabalhando em tarefas fictícias, porque se parar por um momento e olhar para as reais, ficará claro que todo o sistema está quebrado. De repente, pode acontecer que Vasya, sentado naquele canto, tenha monitorado o status do farm de servidores interno nos últimos 10 anos, cuja migração para a AWS ocorreu com sucesso há 5 anos. De repente, verifica-se que todo o trabalho de Masha é enviar os relatórios de Dasha a alguém. Essa consciência é muito difícil e as pessoas tentam inconscientemente evitar situações nas quais elas podem ser feitas acidentalmente.
E continuamos a resolver problemas imaginários.