Oi Meu nome é Alexey Pyankov, sou o principal programador da Sportmaster. Eu direi imediatamente que "main" não significa "o mais importante de todos os programadores", não, isso é apenas um nome, uma tradução tão encantadora para "Senior +" ".
Trabalho na Sportmaster desde 2012 e, durante esse período, a equipe de desenvolvimento tomou muitas decisões interessantes do ponto de vista técnico. Hoje, porém, eu gostaria de falar sobre o nosso trabalho, enfatizando mais como raciocinamos em certas situações ambíguas.
Este artigo não terá soluções técnicas específicas (e de fato algo técnico) que devem ser utilizadas e aplicadas em seu projeto. Pelo contrário, é uma reflexão sobre o trabalho realizado. Houve momentos especiais que nos influenciaram como equipe - reunidos, temperados e testados quanto à força. Vou tentar falar sobre esses momentos, sobre a atmosfera do trabalho em equipe, sobre o nosso rake e várias armadilhas psicológicas nas quais às vezes nos metemos.
E vou começar em 2012.
Eu vim em 2012 com o objetivo principal na época - trabalhar em nosso site principal. Naquela época, era um "monstro Frankenstein": uma parte da equipe trabalhava com nosso sistema antigo, que não lidava muito bem com cargas (Bitrix), em outra parte da equipe (onde eu incluí) eles tentaram introduzir um novo sistema, escolhido de acordo com o critério "Uma vez este é o comércio eletrônico mais caro do mundo, nós aceitamos. " Foram eles que “tentaram implementar” - porque o sistema estava resistindo desesperadamente e, a cada momento que acabava sendo resolvido, havia uma “surpresa” em resposta. Eles trabalharam muito, mas avançaram na velocidade de um caracol.
Para mim, pessoalmente, a última gota foi me familiarizar com o código de um método nesse “comércio eletrônico mais caro do mundo”, quando várias horas de trabalho concentrado em um bug complicado levaram ao fato de que o motivo foi encontrado em algum lugar da tag personalizada, que funciona quando geração de html em jsp. A tarefa dessa tag personalizada é exibir a soma de alguns valores. Isso não é ruim; as tags personalizadas destinam-se a isso. Mas a surpresa se escondeu no fato de alguns dados no banco de dados serem alterados, o comportamento nas páginas a seguir está vinculado a ele e, se você pressionar F5, a chamada se repete, isso violará a consistência dos dados. Além disso, violou de tal maneira que apareceu apenas após alguns passos na terceira página da sequência. Não, não me importo que esse "mestre ninja" estivesse na equipe e com seu código apoiasse a atenção dos colegas em boa forma. Mas assim mesmo, no sistema mais caro!
Isso foi sexta-feira. E um colega e eu passamos o sábado e o domingo no escritório para descobrir quais tarefas a empresa realiza para o sistema hoje e quais tarefas ele pode realizar em um ano. Consequentemente, como os resolveríamos, se não fôssemos levados a adotar o sistema mais caro e econômico.
Mal disse o que fez. Fizemos um piloto no qual lançamos as bases para o desenvolvimento do novo site da Sportmaster. Muitas dessas idéias se enraizaram e agora sua continuação está ativamente girando no site.
Fases-piloto e prazos
2 dias Fizemos um microtrotótipo - no fim de semana, estamos ultrapassando nossa base no ElasticSearch, estamos fazendo uma pesquisa por facetas. Woah la! No mesmo sistema adquirido, essa configuração "comeu" 2 semanas. E aqui - em apenas algumas horas! Sim, e funciona mais rápido. E mais rápido por um pedido.
2 semanas. Estamos vendo um protótipo, adicionando funcionalidade para entrega personalizada adequada.
Por exemplo, o usuário tem vários descontos e promoções que são relevantes especificamente para ele - nos resultados da pesquisa dos produtos, você precisa exibir exatamente o preço que pode ser obtido usando todos os pães disponíveis da maneira mais lucrativa.
Com ações, nem tudo é tão simples. Por exemplo, comprei esquis, agora há um desconto de 40% em um chapéu, mas, ao mesmo tempo, um desconto de 10% em todo o pedido é cancelado. Sim, sim, esse é um caso real :) E, para montar essa promoção no sistema de compras, foram realizadas 3 consultas com o fornecedor, como resultado disso temos muitos exemplos de como fazer outras promoções diferentes. Muito diplomático e, dado o custo da consulta, muito economicamente bom.
Mostrou à empresa uma demonstração detalhada. Eles prometeram montar rapidamente o piloto e imediatamente começaram a trabalhar.
2 meses. Projeto piloto - fazemos na forma de um site ao vivo com uma pesquisa de diretório. Pesquise com facetas, resultados de pesquisa - com descontos pessoais, o piloto se parece quase com o site de um Sportmaster e preenchemos os mesmos produtos. Docinho!
Nós adicionamos o "Eloquence: 100" do nosso chefe de departamento, e a apresentação ao negócio ocorre em Hooray! Eles nos dão carta branca para desenvolver a plataforma de comércio eletrônico.
E isso significa: manter, pessoal, equipe, manter, pessoal, orçamento. Legal!
2 anos Retirada do site em produção. Sim, há muito tempo. Tudo o que sabíamos na época, tentamos apenas na escala do protótipo. Duas pessoas formam facilmente uma equipe coesa. E as tarefas que "realizamos" - em geral, eram pequenas dopilas de "Hello World" em novas tecnologias. Geramos facilmente novas hipóteses, as testamos rapidamente, não tivemos tempo de nos apegar e, portanto, sem arrependimentos, elas as "mataram". Quando nos tornamos 10 pessoas, a inércia extrapolou nossa velocidade de trabalho para todos os outros. E eles prometeram prazos para a tarefa, que são iguais à idéia do belo, multiplicado pelo nosso entusiasmo.
Uma situação familiar? :)
Então, você já sabe o que vai acontecer a seguir?
Armadilha No. 1. "Resistente ao extrapolador"
É claro que as novas tecnologias parecem muito legais nas apresentações e mostram excelentes resultados no aplicativo da categoria "Hello World". Mas a realidade geralmente está um pouco mais longe disso.
Então aqui. Pegamos a biblioteca, escrevemos um monte de código de aplicativo. Consideramos os testes de unidade um fardo (somos legais e apostamos em supersônicos aqui, o código é moderno e muito mais). Nós constantemente alteramos e modificamos a API em movimento - bem, que tipo de testes existem, sério. E tudo isso sob a bandeira de "otimizou friamente o processo de desenvolvimento" (sim, agora é assustador descrevê-lo).
E então tudo é bastante óbvio.
Lançamos uma nova compilação no uat. Os caras da empresa alegremente vão testar tudo isso e apertam os botões. Às vezes, eles pressionam de maneira bastante criativa - algo cai. Então vá e descubra o que eles fizeram para isso. Porém, do outro lado do monitor, não há um testador tedioso que apresenta todas as características ambientais para você, levando em consideração o clima da região, mas o cliente está fora do negócio. Ele simplesmente "não funciona". Então, ele está infeliz. Pergunte a ele - e ele ficará terrivelmente infeliz!
Então, para reproduzir o bug, você precisa se esforçar em tudo. Obviamente, não ignoramos uma única reclamação e consertamos tudo. Eles jogaram as tarefas planejadas, mas "apagaram o fogo".
Então nós cavamos o próximo buraco.
Armadilha número 2. "Stakhanovets"
Você não recebeu o bug mais agradável. Você começa a entender. Não dá certo - raiva - uma tentativa de resolver tudo de novo - outra chatice - você especifica tudo o que é possível - mais uma vez não que pense no fato de que você já é velho e que todos têm filhos e uma hipoteca - você tenta novamente - e não novamente. Algumas xícaras de café e tudo se repete. 12-14 horas seguidas é quase a norma. E agora, quando tudo já está no seu limite - bang, inspiração!
Talvez, de fora, a avaliação da eficácia de tal dia seja visível de maneira correta e correta. Mas por dentro - pode ser diferente.
No meu caso, a impressão de que esse trabalho era "terminei, sou legal, saí". Nem sempre conscientemente, mas inconscientemente - sempre!
E sente-se, sem brincadeira. Acontece que as métricas internas do sucesso do movimento são alteradas do resultado para o número de esforços aplicados e o nível do que você realizou, quanto sofreu, tentando resolver o problema.
Esta é provavelmente a pior armadilha.
Além disso, será mais fácil e divertido :)
Armadilha número 3. "O poder do Olá mundo"
Nossa pilha de tecnologia desse período: ElasticSearch, Hazelcast, Pentaho, freemarker (e Java, Spring, Tomcat, nginx comprovados). O Freemarker não relatou mensagens de erro de maneira muito informativa. Mas o ElasticSearch, Hazelcast e Pentaho precisaram ser corrigidos várias vezes - encontramos talentosos casos em que eles não funcionavam conforme especificado na documentação.
O início fácil e o pão rápido do uso de novas tecnologias são bons, mas eles se introduzem na euforia e reduzem o estado de alerta. Como a nova tecnologia contém erros, necessariamente contém erros. E se você ainda não escreveu sobre eles - regozije-se, cabe a você se tornar o pioneiro que pega algo torto de qualquer maneira e acessa o Google ou o SO. Obviamente, o “torto” pode ser encontrado em produtos comprovados, mas em novos é muito mais fácil.
Apesar de todas as dificuldades, entramos em produção. Sim, com atrasos. Sim, não muito estável. Mas em geral - sem desastres.
No total, noto mais uma vez armadilhas nas quais uma percepção saudável do processo de trabalho é distorcida.
- "Resistente ao extrapolador" . Impressionados com os sucessos atuais, extrapolamos com alegria a velocidade do desenvolvimento para os próximos projetos.
- "Stakhanovets" . Trabalhamos para o desgaste, estamos satisfeitos conosco mesmos, mas não percebemos que os problemas que resolvemos são uma consequência de nossos erros / deficiências / negligências pessoais. Trabalhos a não serem feitos.
- "O poder do Olá mundo . " Nós nos apressamos em apresentar todos os novos e mais interessantes na produção.
Por que funcionou
Obviamente, não listei todos os erros que tivemos durante esse período, mas os mais comuns, prováveis para um projeto com detalhes específicos. Essa correção de erros ajuda a evitá-los no futuro.
Um pouco sobre como geralmente conseguimos criar uma mini-startup dentro da empresa e convencer a empresa a mudar do sistema já adquirido para algo de seu próprio tipo.
Condição nº 0 . Clima saudável na empresa. Este não é apenas o "olhar ardente" dos funcionários e a sociabilidade em condições estressantes de extração de biscoitos, não. É sobre todas as interações.
Condição nº 1 . Acredite no que você faz. Sério, não acho que teríamos pelo menos alguma chance de entrar em um piloto sem analisar o sistema comprado "ao extremo" - ou seja, recuar e subconscientemente sabendo que esse sistema é mais frio e ocupado por nós.
O que fizemos: 1) descobrimos o sistema de compras, com ele resolvemos as solicitações básicas do negócio 2) fizemos uma lista de tarefas que não só existem agora, mas estarão no futuro previsível 3) selecionamos uma solução mais adequada. E então, nossa avaliação da decisão - foi uma avaliação de especialistas.
Eles nos dariam alguma coisa se apenas viéssemos dizer: "pessoal, todo esse lixo, não queremos lidar com isso e decidimos fazer nossas coisas do zero"? Dificilmente. E a resposta teria sido recebida de forma bem lembrada :)
Condição nº 2 . O primeiro passo é pequeno. Geramos a primeira hipótese e verificamos. Você pode gastar seu tempo pessoal nisso. Se você não quer perder seu tempo, não deve aceitar nada disso. E se você não deseja testar uma pequena hipótese, mas deseja fazê-la imediatamente de maneira legal e brilhante, fique longe dessas pessoas!
Tivemos sorte e a primeira hipótese funcionou. Mas isso nem sempre acontece. Por exemplo, em um dos seguintes projetos, quando o administrador foi promovido como parte de um piloto semelhante, apenas a 18ª opção funcionou para nós. E as primeiras 17 abordagens do projétil foram desperdiçadas. Aliás, na história com a criação da área administrativa, as reviravoltas na história estavam no nível das séries brasileiras, porque a equipe era formada por caras, na época já veteranos, verdadeiros “kalachs ralados”.
Condição nº 3 . Fazemos MVP e procuramos dor no tomador de decisão. É claro que o horror já se reflete em seu rosto pelo fato de você estar trazendo a ele algum tipo de aventura pela trigésima vez. Mas ainda. E não deixe de mostrar exatamente como resolvemos os problemas dele com nosso produto.
Condição n ° 4 . No joelho, rapidamente criamos um piloto que se parece com o resultado final. Tornar tudo realmente legal é tentador, mas você pode se deparar com o perfeccionismo, pelo que acontece que, em vez de um piloto, você deseja mostrar uma versão piloto de um produto já ideal. Mas eles não existem. Então, basta fazer pelo menos palitos.
Condição n ° 5 . Produto. O projeto está crescendo, obtendo finanças, especialistas vêm com sólida experiência.
E se você é uma startup clássica, é neste exato momento que você precisa culpar com um apito. Porque vôos leves no topo e uma sensação de bondade geral do que está acontecendo são rapidamente dispersos.
Entrar no produto é uma colisão com cargas reais, integração com uma dúzia de sistemas e, quando você cria uma nova funcionalidade, finaliza as versões antigas como parte da manutenção. Todos esses são desafios muito mais sérios do que ter uma idéia e resolver, ainda que bem, mas apenas um problema do cliente.
Estes são desafios e o crescimento de habilidades - ocorre precisamente nesta fase.
Obrigado pela leitura. Feliz novo código!