Olá! Meu nome é Alexey Pyankov, sou o programador chefe da empresa Sportmaster. Deixe-me dizer, "chefe" não significa "o mais importante de todos os programadores"; não, é apenas um título, uma tradução charmosa para "Senior+".
Trabalho na Sportmaster desde 2012, e durante esse tempo, a equipe de desenvolvimento fez muitas soluções que são interessantes do ponto de vista técnico. Mas hoje eu gostaria de falar sobre nosso trabalho, com foco em como pensamos em certas situações ambíguas.
Neste artigo, não haverá soluções técnicas concretas (nem nada realmente técnico) que você deva pegar e aplicar em seu projeto. Em vez disso, é uma reflexão sobre o trabalho realizado. Houve momentos especiais que nos impactaram como equipe - nos unindo, fortalecendo e testando nossa resistência. Sobre esses momentos, sobre a atmosfera de trabalho em equipe, sobre nossos tropeços e várias armadilhas psicológicas que às vezes nos impomos, é sobre isso que tentarei falar hoje.
E começarei exatamente em 2012.
Entrei em 2012 com o principal objetivo na época - trabalhar em nosso site principal. Naquele tempo, era um "monstro de Frankenstein": parte da equipe trabalhava com nosso antigo sistema, que lidava com as cargas de forma não muito eficaz (Bitrix), enquanto outra parte da equipe (onde eu estava incluído) tentava implementar um novo sistema, que foi escolhido pelo critério "Como é o e-commerce mais caro do mundo, vamos adotá-lo". Especialmente "tentando implementar" - porque o sistema resistia ferozmente e a cada situação em que conseguíamos resolver algo, sempre surgia uma "surpresa" em resposta. Trabalhamos muito, mas progredimos na velocidade de uma lesma.
Para mim, a gota d'água foi o conhecimento do código de um método nesta "e-commerce mais cara do mundo", quando várias horas de trabalho concentrado em um bug complicado resultaram na descoberta de que a causa estava em algum custom-tag que é acionado durante a geração de HTML em JSP. A tarefa desse custom-tag é exibir a soma de certos valores. Isso é útil, já que é para isso que os custom-tags servem. Mas a surpresa estava no fato de que, durante isso, certos dados no banco de dados eram alterados, o que afeta o comportamento nas páginas seguintes, e se você pressionar F5 — a chamada se repetia, isso prejudicava a consistência dos dados. Além disso, isso ocorria de tal forma que se manifestava apenas após vários passos, na terceira página da sequência. Não que eu seja contra ter um "mestre ninja" na equipe, que mantenha a atenção dos colegas com seu código. Mas assim, na biblioteca do sistema mais caro!
Era uma sexta-feira. E no sábado e domingo, meu colega e eu passamos na empresa para entender quais tarefas o negócio impõe ao sistema hoje e quais problemas podemos imaginar para daqui a um ano. Assim, como resolveríamos esses problemas se não estivéssemos presos a esta cara e irritante sistema.
Dito e feito. Fizemos um piloto, no qual fundamentamos o desenvolvimento do novo site da Sportmaster. Muitas dessas ideias foram adotadas e agora estão sendo implementadas ativamente no site.
Etapas do piloto e prazos
2 dias. Criamos um microprotótipo — durante o fim de semana, transferimos nosso banco de dados para o ElasticSearch e implementamos a busca facetada. Voilà! Nesse sistema comprado, essa configuração levou 2 semanas. Aqui — literalmente algumas horas! E ainda funciona mais rápido. De fato, a velocidade é incomparável.
2 semanas. Estamos "desenvolvendo" um protótipo, adicionando funcionalidade para uma entrega personalizada adequada.
Por exemplo, se o usuário tem vários descontos e promoções que são válidos apenas para ele — então, nos resultados da busca de produtos, é necessário exibir exatamente o preço que pode ser obtido utilizando todos os benefícios disponíveis da maneira mais vantajosa.
As promoções não são tão simples. Por exemplo, comprei esquis e agora tenho 40% de desconto na touca, mas isso cancela o desconto de boas-vindas de 10% em todo o pedido. Sim, isso é um caso real 🙂 E para configurar essa promoção no sistema de compras, pagamos por 3 consultas com o fornecedor, das quais obtivemos muitos exemplos de como fazer outras promoções. Muito diplomático e, considerando o custo das consultas, foi uma boa economia.
Mostramos uma demonstração detalhada para o negócio. Prometemos montar rapidamente um piloto e começamos a trabalhar.
2 meses. O projeto piloto é feito como um site real com busca em catálogo. Busca com facetas, resultados de busca com descontos pessoais, o piloto parece quase com o site do Sportmaster, e os produtos que subimos são os mesmos. Um verdadeiro sucesso!
Adicionamos "Rhetoric:100" do nosso chefe de departamento e a apresentação para o negócio é um sucesso! Recebemos carta branca para desenvolver a plataforma de eCommerce nós mesmos.
E isso significa, fiquem atentos, pessoal, a equipe, fiquem atentos, pessoal, ao orçamento. Muito legal!
2 anos. Colocação do site em produção. Sim, demorou. Tudo o que sabíamos fazer, testamos apenas em escala de protótipo. Duas pessoas facilmente formam uma equipe coesa. E as tarefas que "cumpríamos" eram, na verdade, pequenas melhorias no "Hello World" com novas tecnologias. Gerávamos novas hipóteses facilmente, testávamos rapidamente, não nos apegávamos e, portanto, as "eliminávamos" sem remorsos. Quando chegamos a 10 pessoas, extrapolamos nossa velocidade de trabalho para todos os outros. E prometemos prazos de entrega que eram iguais à nossa visão do que seria ideal multiplicado pelo nosso entusiasmo.
Situação familiar? 🙂
Então, vocês já sabem o que vai acontecer a seguir?
Armadilha nº 1. "Extrapolador legal"
É claro que novas tecnologias parecem incríveis em apresentações e se saem bem em casos do tipo "Hello World". Mas a realidade geralmente está um pouco mais distante disso.
Então. Pegamos a biblioteca, escrevemos um monte de código de aplicação. Consideramos os testes unitários um fardo (somos legais e trabalhamos em hipersônico aqui, código moderno e tal). Mudamos e aprimoramos a API em tempo real — que testes, sério. E tudo isso sob a bandeira de "otimizamos muito o processo de desenvolvimento" (sim, é assustador até descrevê-lo agora).
E então tudo é bastante óbvio.
Estamos lançando uma nova versão no uat. A equipe de negócios está testando tudo com entusiasmo e pressionando os botões. Às vezes, eles clicam de maneira um tanto criativa — algumas coisas acabam não funcionando. Aqui, seria bom descobrir o que foi feito para corrigir isso. Mas do outro lado do monitor não está um tester focado, que lhe daria todas as características do ambiente considerando o clima na região, mas sim um cliente do negócio. Para ele, simplesmente "não funciona". Isso significa que ele está insatisfeito. Pergunte a ele — e ele vai ficar muito insatisfeito!
Então, para reproduzir o bug, é preciso ir e testar tudo em sequência. Claro, não deixamos nenhuma reclamação sem resposta e corrigimos tudo. Abandonamos tarefas planejadas, mas estávamos "apagando incêndios".
Assim, encontramos o nosso próximo problema.
Armadilha nº 2. "O estakhanovista"
Chegou até você um bug nada agradável. Você começa a investigar. Não dá certo — raiva — uma nova tentativa de descobrir — mais uma decepção — você verifica tudo o que pode — ainda não está certo — pensa que já está velho e que todos têm filhos e hipoteca — tenta novamente — de novo não funciona. Algumas xícaras de café depois, e tudo se repete. 12-14 horas de trabalho sem parar — quase como uma norma. E então, quando tudo já está no limite — de repente, uma epifania!
Talvez, de fora, a avaliação da eficácia de um dia assim pareça boa e certa. Mas por dentro — pode variar bastante.
No meu caso, a impressão de tal trabalho continha "Eu sou ótimo, eu sou incrível, eu resolvi". Não sempre de maneira consciente, mas inconscientemente — sempre!
E você acaba se viciando nisso, sem brincadeira. Assim, as métricas internas de sucesso se deslocam do resultado para a quantidade de esforços despendidos e o nível de feitos que você alcançou, quão intensamente você sofreu tentando resolver o problema.
Provavelmente, essa é a armadilha mais aterrorizante.
A partir daqui, ficará mais fácil e divertido 🙂
Armadilha nº 3. "O poder do Hello world"
Nossa pilha de tecnologias naquela época: ElasticSearch, Hazelcast, Pentaho, freemarker (junto com Java, Spring, Tomcat, nginx). O freemarker não fornecia mensagens de erro muito informativas. Já o ElasticSearch, Hazelcast e Pentaho precisaram de várias correções — nós talentosamente encontrávamos situações em que eles não funcionavam conforme a documentação.
Um início fácil e os rápidos resultados da utilização de uma nova tecnologia são bons, mas eles podem criar uma euforia que diminui a vigilância. Porque uma nova tecnologia contém falhas, definitivamente contém falhas. E se ainda não escreveram sobre elas — alegre-se, você será o pioneiro que, de qualquer forma, encontrará algo errado e irá buscar no Google ou no SO. Claro, algo “errado” pode ser encontrado em produtos estabelecidos, mas é muito mais fácil em novos.
Apesar de todas as dificuldades, conseguimos ir para a produção. Sim, com atrasos. Sim, não muito estável. Mas, no geral, sem catástrofes.
Portanto, mais uma vez, destacarei as armadilhas nas quais a percepção saudável do processo de trabalho é distorcida.
- «Extrapolador imbatível». Impressionados com os sucessos atuais, seguimos em frente e extrapolamos alegremente a velocidade de desenvolvimento para os projetos futuros.
- «Trabajador incansável». Trabalhamos arduamente, estamos satisfeitos conosco, mas não percebemos que os problemas que estamos resolvendo são consequências de nossos erros/pontos fracos/descuido pessoais. Trabalhos não realizados.
- «Força do Hello World». Apressamos-nos para implementar em produção tudo o que é mais novo e interessante.
Por que tudo deu certo
Claro, eu não mencionei todos os erros que tivemos durante esse tempo, mas os mais comuns, prováveis para projetos de qualquer especificidade. Essa fixação de erros ajuda a evitá-los no futuro.
Um pouco sobre como conseguimos criar essa mini-startup dentro da empresa e convencer o negócio a sair do sistema já adquirido para algo feito sob medida.
Condição nº 0. Um clima saudável na empresa. Não se trata apenas de “olhos brilhantes” dos funcionários e da comunicação em condições estressantes de coleta de cookies, não. Trata-se de todas as interações.
Condição nº 1. Acreditar no que você faz. Sério, eu não acho que teríamos qualquer chance se nos ocupássemos do piloto, sem analisar o sistema comprado “até o parafuso” — ou seja, recuando e, subconscientemente, sabendo que esse sistema é melhor e nos superará.
O que fizemos: 1) entendemos o sistema comprado, com ele resolvemos as principais demandas do negócio 2) fizemos uma lista de tarefas que não só existem agora, mas que também aparecerão em um futuro próximo 3) escolhemos a solução que se encaixa melhor. E então, nossa avaliação da solução foi uma avaliação de especialistas.
Eles nos daria alguma coisa se simplesmente fôssemos até eles e disséssemos, tipo, "pessoal, tudo isso é uma bobagem, não queremos lidar com isso e decidimos fazer nosso próprio a partir do zero"? Dificilmente. E a resposta viria de uma forma que ficaria bem marcada 🙂
Condição nº 2. O primeiro passo é pequeno. Geramos a primeira hipótese e verificamos. Pode-se gastar seu próprio tempo para isso. Se você não quer gastar seu tempo — então, realmente, não vale a pena se envolver nesse tipo de coisa. E se não quiser verificar uma pequena hipótese, mas desejar fazer algo incrível de imediato — mantenha distância de tais pessoas!
Tivemos sorte, e a primeira hipótese funcionou. Mas isso nem sempre acontece. Por exemplo, em um dos projetos seguintes, quando promovemos a interface administrativa dentro de um piloto semelhante, só o 18º modelo funcionou. E as 17 primeiras abordagens foram em vão. A propósito, na história da criação da interface, as reviravoltas eram dignas de novelas brasileiras, porque a equipe era composta por rapazes que já eram veteranos, verdadeiros "experientes no assunto".
Condição nº 3. Criamos um MVP e buscamos as dores do decisor. Claro, pode haver um horror estampado no rosto dele já pelo fato de que você está apresentando alguma ideia pela trigésima vez. Mas, ainda assim, é importante mostrar como exatamente resolvemos seus problemas com nosso produto.
Condição nº 4. Rapidinho, fazemos um piloto que parece mais ou menos com o resultado final. Fazer tudo de forma absolutamente incrível é tentador, mas você pode acabar se prendendo ao perfeccionismo, fazendo com que, em vez de um piloto, você queira mostrar uma versão de piloto de um produto já ideal. E isso não existe. Portanto, faça pelo menos algo improvisado.
Condição nº 5. Produto. O projeto cresce, recebe financiamento, e especialistas com vasta experiência aparecem.
E se você é um típico empreendedor de startup, esse é o momento certo para sair rapidamente. Porque voar leve nas alturas e sentir uma atmosfera geral de bem-estar se dissipa rapidamente.
O lançamento em produção é um confronto com cargas reais, integração com dezenas de sistemas, e ao criar um novo funcionalidade, você ao mesmo tempo atualiza versões antigas no suporte. Todos esses desafios são muito mais sérios do que apenas inventar uma ideia e resolver, mesmo que bem, um único problema do cliente.
Esses desafios e o crescimento das habilidades ocorrem exatamente nesta fase.
Obrigado por ler. Feliz Novo Código!
Fonte: habr.com
