A partir de amanhã, começamos a viver de uma nova maneira. Teremos Scrum e haverá felicidade. Democracia completa: sem chefes, a equipe decide o que fazer, a burocracia é cancelada, o principal é fazer o bem ao cliente.
Um treinador veio e nos ensinou o básico. Ele falou sobre o sucesso iminente, sobre eficiência e foco no cliente, sobre a flexibilidade e importância sem precedentes de envolver um cliente no processo de desenvolvimento e sobre as naves espaciais que aravam o Teatro Bolshoi.
Bem, bem. Espere e veja.
Começamos um novo projeto. Bem, graças a Deus!
E então eu já cobri musgo por me sentar acima do código Legado. Minha força não existe mais, não consigo lidar com esse grande monstro de massas. De alguma forma, tentei mover o botão no formulário de logon, para obter erros no módulo de email. Pense sobre onde está a conexão ...
Eles nos apresentaram a um novo funcionário, teremos um Dono do Produto ou, em russo, um representante do cliente. Meu nome é Rita. Mulher encantadora. Adora conversar.
Faça uma pergunta simples, para que ela comece um discurso por meia hora. Você olha para ela e pensa: "Uh, você não entende nada!"
Cinco minutos depois, você começa a duvidar: "Não, é o que está dizendo".
No final, você percebe que não recebeu uma resposta para sua pergunta. Então você sai.
O principal é interrompê-lo, não há como. Tentando equilibrar e direcionar o fluxo verbal na direção certa, mas onde lá, ela sabe que é derramada e novamente fala sobre os navios e o Teatro Bolshoi.
Já tínhamos medo de lhe fazer perguntas simples. Você pode obter uma resposta, mas pode se afogar no oceano verbal.
Sim, a burocracia de fato se tornou menor. Porque todo mundo marcou na documentação em geral. Agora as informações são transmitidas principalmente pelo boca a boca. Claro, eu entendo tudo, somos muito ágeis, mas não na mesma medida ...
Dada a tarefa: desenvolver no gateway a capacidade do cliente receber dados para exibir o gráfico. Você precisa ir ao serviço, obter os dados brutos, recontá-los e entregá-los ao cliente. Não há especificação do que e como contar - ninguém sabe. Existe apenas o nome do gráfico. Bem, como devo fazer isso, eu me pergunto?
Ok, procurei em algum lugar em nossos projetos antigos algo semelhante, fiz um padrão. Não há certeza de que é isso que é necessário, não. Estranho, mas ninguém realmente se importa. O principal é que introduzimos novas funcionalidades com sucesso em uma demonstração.
Hoje trabalho aqui, as testadoras de meninas cercaram nosso mestre de Scrum Kolya, e elas exigem que lhes explique como a nova funcionalidade funciona. Kolya olha com olhos de lata para o monitor e murmura algo sobre os modelos e sobre as mudanças nos requisitos.
Você pode entender Kolya: você mudou algo há um mês e é difícil lembrar exatamente o que é, não há documentação. Mas as meninas não são açucaradas: foram instruídas a testar alguma coisa, não sei o quê.
Eu os encontrei no corredor meia hora depois: Kolya estava andando, as meninas o seguiam e todos estavam gargalhando: “Novo modelo ... modelo antigo ... requisitos do cliente ...”.
Os pobres ...
Recebeu um pedido de revisão. Erro ao exportar o gráfico: as proporções de altura e largura são diferentes da original. É estranho, porque certa vez resolvi esse problema e cuidei de todas as proporções ... O problema foi resolvido de uma maneira original: um colega simplesmente multiplicou a altura por 1,25.
Eu pergunto a ele:
- O que esse coeficiente significa?
"E isso", ele diz, "eu peguei." Agora tudo ficará bem.
A que horas Ele atendeu ... E o que acontecerá com a exportação de outros gráficos? Eles começaram a entender, mas você acabou de mudar um pouco a sequência de chamadas. Em alguns casos muito raros, suas configurações de tela são usadas e é necessário recalcular as proporções depois disso.
Parece que, às vezes, é importante que as pessoas relatem o trabalho realizado por qualquer meio, e o resultado final realmente não as incomoda ...
Hoje, Rita disse que decidiu usar a rolagem infinita ao exibir uma lista de documentos. Tentei convencê-la de que a situação no serviço REST está mudando constantemente: alguns usuários adicionam documentos, outros excluem. Como resultado, elementos extras aparecerão no formulário ou desaparecerão, portanto, é melhor usar a boa velhice. Ao que me disseram que tal situação é rara, e a rolagem sem fim é elegante e sexy, os usuários ficarão felizes.
Você está satisfeito? Hmm ... eu ficaria chateado se descobrisse que a lista não corresponde ao estado atual ...
Não entendo como é possível construir um edifício com merda e paus, sem fundamento, começando ao mesmo tempo em quatro ângulos simultaneamente. Às vezes acho que se aviões, barcos a vapor e arranha-céus fossem projetados da mesma maneira que o software moderno, então os aviões caíam imediatamente, os navios viravam de cabeça para baixo e nossas cidades estariam em ruínas. É claro que nosso preço de erro é muito menor. No final, não criamos software médico ou espacial. Mas nosso software é complicado, usa muitos microsserviços. É necessário prestar atenção ao estudo preliminar dos detalhes!
É bom que não construamos aviões ...
Ele olhou para o departamento vizinho e, no limiar, sentiu que algo estava errado. Todo mundo está sentado, batendo furiosamente nos teclados, e no ar há uma espécie de sentimento de infelicidade geral.
De repente, seu mestre de scrum Vitya pula e como gritar para alguém:
- O que você está escrevendo para mim! Diga isso oralmente!
E então eles romperam. De repente, ficou tonto. Por via oral. O barulho aumentou extraordinariamente.
Eu fiquei por um minuto, tossi, todo mundo ficou em silêncio e olhou para mim. De repente, me senti desconfortável.
Victor diz:
- Você mudou a autorização no serviço?
"Sim", respondo, "mudou". Agora usuários sem direitos não podem ler o recurso. É necessário usar uma maneira diferente.
- Então você mudou - ele diz - e agora o aplicativo parou de funcionar para nós.
Ele ficou em silêncio por um tempo e acrescentou:
- Você fez tudo certo, este é o nosso cant. Mas nós, você sabe, precisamos lançar a versão após três horas e não podemos corrigir o erro tão rapidamente.
Eu queria dizer a eles: “Bem, diabos, você nunca fez os testes, porque a semana já passou!”, Mas olhou para os rostos deles, virou-se e foi fazer uma reversão no serviço.
O chefe nos reuniu hoje e diz:
- Nós devemos ter um épico. Queremos introduzir o aprendizado de máquina para personalizar os resultados da pesquisa.
As pessoas, é claro, estão interessadas no que se entende e se existe uma descrição do problema.
- Ainda não existe uma descrição completa, vou lhe dar links para o que é. Pense por enquanto - respostas. E saiu.
Então olhei para a página pelo link: cabeçalho e dois parágrafos. E como você acha que deve pedir, se não está claro o que pensar?
O que acontece com eles, porque havia pessoas técnicas, elas surgiram de desenvolvedores simples e agora é como se elas tivessem degenerado em clientes. Ouvi em algum lugar que a inteligência artificial está na moda e é legal, e vamos começar um épico. Nem uma tarefa para concretizar, nem uma especificação exata para escrever, tudo é matéria e naves espaciais com teatros ...
Encontro Vitya hoje no corredor e pergunto:
"Bem, você encontrou um erro?" Um mês se passou. Seria necessário restaurar a autorização no serviço, caso contrário, vivemos com um buraco.
Vitya desvia o olhar e diz:
- Não, ainda não encontrado. Não há tempo suficiente ...
Bem, aqui está você. Durante um mês, as pessoas não conseguem encontrar um local onde o ponto de extremidade errado é usado. Aparentemente, eles já abandonaram isso e estão envolvidos nos assuntos atuais. É estranho, porque o programa, de fato, usa dados incorretos ...
Sim, aqui nosso novo portal se transformou em uma bola apertada de macarrão e já é impossível encontrar os fins. Rapidamente, conseguimos!
Estou tentando convencer meus colegas a conversar com meus superiores sobre o estado atual das coisas. Do meu ponto de vista, o projeto está em um estado deplorável: equipes diferentes, resolvendo suas tarefas, fazem edições que aumentam o caos, a entropia está crescendo. Cada vez, resolver problemas se torna cada vez mais complicado.
Os caras concordam comigo, mas minhas iniciativas são legais. E eles podem ser entendidos: todo mundo tem tarefas atuais que devem ser resolvidas durante o sprint. Não depende de filosofar, as coisas devem ser feitas ...
Eu admito: eu inventei este diário. Todos os personagens são fictícios, as coincidências são aleatórias. Isso é só uma piada.
Às vezes acontece que o gerenciamento percebe o Agile um tanto vulgar: basta esboçar um pouco a tarefa e uma boa equipe lida com todos os problemas arquitetônicos e conceituais por si só. Muitas vezes, esquecem a necessidade de documentação completa, embora o uso do Agile não signifique absolutamente uma rejeição da documentação.
No entanto, não queria falar sobre tecnologias ágeis ou de desenvolvimento. Quero especular sobre a qualidade do software que criamos e como as más decisões podem destruir esse software.
Conflito de interesse
Você é um desenvolvedor. O projeto ou parte do projeto em que você está trabalhando é seu filho favorito. Você o cria e nutre, quer ter uma criação perfeita. Para que seus colegas e usuários possam dizer: "Sim, isso é legal!".
Mas você trabalha para o negócio que o contratou. Os negócios não estão interessados em suas ambições. O principal objetivo de uma empresa é o lucro, e com razão. Aqui você está ao mesmo tempo com a empresa, porque deseja que o maior número possível de pessoas use seu projeto?
Mas, por um motivo ou outro, uma empresa pode tomar decisões que violam a harmonia do seu projeto. Digamos que você precise apertar algo muito rapidamente, caso contrário o cliente sairá. Não há tempo para resolver o problema corretamente.
O que fazer?
Provavelmente, você terá que se quebrar, esperando que as muletas atuais possam ser removidas mais tarde ...
No entanto, nem tudo é tão triste. A longo prazo, os negócios são seus aliados na luta pela qualidade, a menos que, é claro, ele seja um inimigo de si mesmo.
No entanto, eu tive que criar uma abordagem que a elaboração cuidadosa de detalhes e análises às vezes pudesse ser negligenciada, uma vez que a satisfação rápida e barata do cliente é mais importante. O sucesso é possível neste caso?
O sucesso é possível?
O paradoxo é que esses produtos podem ter sucesso comercial, pelo menos no primeiro estágio. Os clientes, é claro, ficam aborrecidos com muitas deficiências e inconsistências no sistema, mas, em geral, o produto resolve seus problemas.
Os clientes estão satisfeitos com o nível de suporte: estão atentos às suas necessidades e tentam atender rapidamente a novas necessidades. É verdade que alguns deles, com o tempo, percebem que o sistema está se tornando cada vez mais inconsistente e imprevisível no comportamento, a interface está se tornando mais complicada, está se tornando cada vez mais difícil entender o que está acontecendo lá dentro, como resolver um problema específico corretamente, há problemas com o tempo de resposta e assim por diante. Mas isso acontece gradualmente e a princípio imperceptivelmente.
Ninguém suspeita que o projeto esteja condenado. Em breve ele inevitavelmente entrará em colapso devido à severidade de todas as extensões que lhe são anexadas às pressas.
Quão conectada está a harmonia interna do produto com suas qualidades de consumidor? Muitas vezes acontece que os desenvolvedores estão em estado de horror permanente do estado interno do sistema, enquanto os clientes estão aparentemente satisfeitos. Mas pode um avião feio ser bom? E a harmonia interna de um produto não deve se refletir em suas qualidades de consumidor?
Não é nenhum segredo que muitas vezes o interior obsceno está escondido atrás de uma bela fachada, e isso se aplica não apenas às pequenas empresas, mas também aos gigantes da indústria de software. Aqui está apenas um
exemplo .
As empresas de monstros podem se dar ao luxo de contratar milhares de programadores para apoiar o gigantesco prato de espaguete em que seu produto se transformou ao longo dos anos e décadas, mas para pequenas empresas essa é uma maneira matadora. A propósito, mesmo para monstros, a baixa qualidade do código não passa sem deixar rasto e se transforma em um aumento exponencial do tempo de desenvolvimento e implementação de cada novo recurso, um processo mais caro e uma qualidade de suporte em constante diminuição.
O que é mais importante: qualidade do produto ou habilidades de vendas?
Um produto de qualidade, infelizmente, não é uma garantia de sucesso.
Na prática, tive um caso em que um programa altamente especializado que funcionou bem na Rússia teve que ser promovido ao mercado europeu. O programa usava seu próprio formato de dados, e a conversão dos dados de clientes disponíveis naquele momento não era particularmente difícil. Se conseguíssemos celebrar contratos, nos tornaríamos monopolistas na Europa por um tempo. Parece que tudo está do nosso lado: a demanda no mercado é grande, até agora ninguém pode oferecer algo completo e realmente funcionando, exceto para nós, o programa já está trabalhando em centenas de empregos na Rússia, os clientes russos respondem positivamente sobre o produto.
E então, conseguimos? Infelizmente, não. O concurso foi ganho por uma empresa europeia que já trabalhou com clientes em outras áreas. Eles estavam naquele momento apenas no começo do caminho que já tínhamos percorrido, mas conseguiram nos derrotar. Infelizmente, não tínhamos bons especialistas em promoção e vendas e não conseguimos convencer as pessoas a fazer uma escolha em favor de nossa empresa. Depois de algum tempo, foi muito decepcionante ver nossas conquistas na organização da interface do usuário em seu novo produto ...
Más decisões
Um produto de alta qualidade é uma meta estratégica, e um negócio inteligente estará sempre do lado do desenvolvedor, buscando a excelência. Mas manter a harmonia interna do produto não é fácil. Com o desenvolvimento do produto, surgem novos requisitos que podem destruir a harmonia original dos conceitos. As decisões tomadas neste caso desempenham um papel decisivo no destino futuro do produto.
Ninguém está a salvo de más decisões. Se uma decisão estratégica é tomada no estágio de design e, com o tempo, fica claro que estava errado, isso leva à morte do projeto. Mas, muitas vezes, são tomadas más decisões durante o desenvolvimento, quando novas funcionalidades são adicionadas. Tudo depende, em primeiro lugar, da globalidade das decisões tomadas, ou seja, do grau de sua influência no sistema como um todo e, em segundo lugar, do número de más decisões. Quando o número de más decisões e o grau de influência excedem um certo limiar, uma longa e dolorosa agonia começa.
Gostaria de compartilhar com você alguns exemplos de más decisões da minha própria experiência. Certamente, esses exemplos de forma alguma reivindicam amplitude e sistematização acadêmica.
Regras relaxadas
Às vezes, parece-nos que, para a conveniência do usuário, as regras devem ser flexíveis.
Por exemplo, seu sistema trabalha com diferentes tipos de hierarquias criadas pelos usuários. Você decide que, para um dos tipos, a chave do nó é exclusiva apenas no nível e não em toda a hierarquia. Isso parece conveniente, pois o usuário carrega a hierarquia em níveis.
Consequências: agora, os programadores em todo o código terão que cuidar da preparação da chave composta, e isso geralmente levará a erros. Se os usuários tiverem acesso a sites por chave, isso também será uma dor de cabeça para eles.
Talvez valha a pena considerar regras mais rígidas e exigir a exclusividade de uma chave em toda a hierarquia. Isso beneficiará desenvolvedores e usuários.
Violação das regras
Você tem uma hierarquia complexa de objetos criados pelo usuário. Cada objeto contém a propriedade Name, que é a chave, e o Title com texto arbitrário. Há um conjunto de regras formais para um nome, por exemplo, o nome não deve conter espaços ou caracteres especiais. Em algum momento, surge a tarefa de gerar automaticamente objetos de um tipo a partir de outro. O nome deve ser baseado no título e ser reconhecível. Você decide violar as regras e usa o título como um nome: parece-lhe que será mais conveniente para os usuários.
Prepare-se para problemas no seu sistema que ocorrerão em locais inesperados.
Configurações de complexidade
Você insere configurações válidas apenas sob certas condições. Quando algumas instalações operam sob a condição de outras serem incluídas, essa é uma situação bastante comum. Mas se você possui uma hierarquia complexa de atitudes, algumas das quais funcionam quando outras são ativadas e outras, por sua vez, são condicionais, esse é o caminho para o caos. A experiência mostra que, nesse caso, ninguém está pronto para prever como a mudança em uma instalação específica afetará o comportamento: nem usuários nem desenvolvedores. O sistema de configurações deve ser claro, o mais óbvio possível e cuidadosamente pensado. Você deve se esforçar para reduzir as dependências de algumas configurações em outras.
Falta de análise do problema
Seu sistema permite que o usuário crie relatórios com base em DSL. Foi decidido inicialmente que o DSL contém todas as propriedades do relatório. Após algum tempo, um dos clientes solicita que você adicione a capacidade de armazenar parte das instalações separadamente - isso é necessário para resolver alguns problemas internos do cliente. Iniciar uma tarefa em "Adicionar configurações externas" de Jira sem antes analisar o problema é um erro. Antes de tudo, é necessário responder à pergunta: por que foi necessário? Pode acontecer que o cliente queira ocultar parte das configurações de alguns usuários. Talvez você deva considerar dividir o DSL em partes com autorização dessas partes? A decisão não é tão rápida, mas talvez estrategicamente correta.
Decisões políticas
Às vezes, as decisões são tomadas por razões organizacionais. Por exemplo, certos recursos são armazenados em um microsserviço especialmente projetado para isso. Vários tipos de recursos semelhantes são necessários. Uma equipe está envolvida no serviço, e novos tipos de recursos são necessários por outras. Para compartilhar a responsabilidade, é tomada a decisão de adicionar novos tipos não ao serviço original, mas aos serviços executados por outras equipes.
O problema é que o serviço não apenas armazenou dados, mas também forneceu autorização. Agora você precisa reutilizar o código. Mas isso não é o principal. O principal é que agora não é óbvio qual serviço deve ser usado para obter os dados necessários.
A evidência interna da construção de um sistema é sacrificada por motivos organizacionais ou políticos.Conclusão
Como desenvolvedor, quero me orgulhar dos resultados do meu trabalho. Para mim, a beleza interior, a elegância e a harmonia do projeto são importantes. Mas não menos importante é a demanda. Não quero trabalhar para a cesta, quero que o maior número possível de pessoas use o produto e fique satisfeito. Entendo que, às vezes, você precisa arcar com os custos e estragar um pouco a harmonia interior para agradar os interesses de cada cliente. Mas estou convencido de que por trás da bela fachada não deve haver desgraça, interiores feios mais cedo ou mais tarde sairão, não importa se isso é uma confusão externa de conceitos ou um tempo de resposta cada vez maior aos problemas do cliente.A beleza e harmonia do produto é mais importante. Sim, às vezes somos forçados a fazer concessões no interesse dos negócios e estamos prontos para obscurecer a clareza das abordagens no interesse de um cliente em particular, especialmente se for um cliente muito importante, mas essa é uma ladeira escorregadia.Mais de uma vez eu tive que observar a extinção gradual e a morte dos projetos, quando as pessoas não se preocupavam em estudar cuidadosamente os detalhes e introduziram novas funcionalidades sem pensar, sem se importar com as inconsistências no produto e sem prestar atenção ao surgimento de novas e desnecessárias conexões entre os módulos. Isso sempre leva à confusão, quando fica cada vez mais difícil corrigir o erro mais simples, pois não há certeza de que essa correção não terá um efeito inesperado em componentes e partes completamente estranhos do sistema.Quero desejar uma vida longa aos seus projetos!