Regras de desenvolvimento no Yandex.Health

Parece para muitos que a Yandex é uma grande corporação monolítica com processos estritamente regulamentados, mas não é assim. Estamos constantemente à procura de novos rumos, iniciando novos projetos e experimentando novos mercados. O serviço para consultas on-line com o médico Yandex.Health é uma das startups internas clássicas.

Eu vim para liderar o desenvolvimento do Health em uma época em que o serviço ainda era uma página com um resumo no wiki interno. Neste post, quero compartilhar as abordagens de desenvolvimento que desenvolvemos ao longo de dois anos e meio de trabalho no serviço.

Isenção de responsabilidade:
Uma startup tem suas próprias características. Nossa principal tarefa é realizar o número máximo de experimentos por unidade de tempo e emitir recursos do produto na velocidade mais alta possível. Ao mesmo tempo, devemos manter a qualidade do produto em um nível que não seja uma vergonha para ele. [Um lugar para uma chama sobre a falta de consciência de alguns] . Observo que uma alta velocidade de entrega de recursos implica, entre outras coisas, a manutenção de um código de alta qualidade. Caso contrário, o produto, mais cedo ou mais tarde, engasga.

Todos os pontos abaixo são de uma forma ou de outra sofridos, quase todos têm um caso da vida real.

Código Qualidade e Arquitetura

• Minimizamos o tempo para levar recursos à produção, mantendo uma qualidade aceitável.
• Qualquer tarefa envolve duas soluções: rápida e correta. Para qualquer recurso, pensamos nas duas opções para que seja possível atualizar a solução rápida para a correta, tornando o trabalho desnecessário de “ejeção” mínimo. Tendo implementado uma solução rápida, procuramos por um tempo e entendemos se a solução certa é necessária.
• Criticamente. Freqüentemente, a diferença de tempo entre “resolver a primeira maneira que você consegue marcando uma muleta” e “resolver de maneira bonita e precisa” é de dez minutos. Portanto, sempre pensamos antes de escrever.
• Se houver uma escolha entre otimização menor e legibilidade / arquitetura - escolha a segunda. Dois milissegundos não resolverão nada e, com esse código, ainda temos que viver e manter.
• Estamos pensando no futuro. O futuro próximo é mais importante do que perspectivas distantes. Se a decisão puder ser dificultada (leia-se “longa”) e flexível, ou simples, mas pregada, vale a pena pregar e refatorar conforme necessário. É melhor passar um dia em uma solução simples agora e um mês em uma possível refatoração em um ano, do que duas semanas agora (sim, isso é chamado de dívida técnica). É importante que valha a pena discutir essas decisões com a equipe. Sozinho, você pode avaliar incorretamente a probabilidade de expansão desse recurso em um futuro próximo.

Nova tecnologia

Novas tecnologias são legais, vamos usá-las. Mas nosso produto não é um campo de testes. Se você deseja aplicar um novo algoritmo ou tecnologia, isso pode ser feito nas seguintes condições:

• a tecnologia gera um lucro tangível (otimização, qualidade da arquitetura, código, escalabilidade e tudo isso realmente deve ser necessário, e não rebuscado);
  a tecnologia se encaixa normalmente na pilha atual (você não precisa escrever alguns serviços no Go se todo o código estiver escrito em Python);
• a tecnologia não prejudica a qualidade da arquitetura e a legibilidade do código (isso é subjetivo, portanto, é discutido com a equipe);
• Não é preciso mais tempo para implementar e dar suporte a uma nova tecnologia (incluindo a busca de novos desenvolvedores) do que trabalhar dentro da estrutura da tecnologia atual. Novamente, tudo depende do lucro esperado e é discutido com a equipe;
• qualquer nova tecnologia é discutida com a equipe: se é legal, é correto que todos a usem, se não realmente, uma discussão em grupo permite que você entenda isso rapidamente;
  você não precisa implementar independentemente os algoritmos já implementados em bibliotecas prontas (exceto no caso de se tratar de um pequeno pedaço de uma estrutura enorme e não faz sentido arrastar tudo para uma solução).
• se você fez algo legal e conveniente, compartilhe a solução com a equipe (ou melhor, no Yandex).

Comunicação

• Discutimos a solução juntos. Quanto mais complexa e crítica a funcionalidade, mais importante é essa discussão. Se alguém não gostar da solução, nos convencemos até que seja alcançado um acordo. Ou o tempo de discussão não excederá um tempo razoável.
• Se não foi possível concordar, a última palavra está na cabeça. Temos uma democracia razoável, não o Sejm polonês do século XVII . Ao mesmo tempo, o líder recebe um grande sinal negativo de karma e deve experimentar sofrimento moral. E certamente não usar esse direito com frequência.
• Depois de termos decidido, fazemos o que foi acordado. Mesmo se eu discordo totalmente. Nenhum "Eu sei melhor do que todos esses especialistas em produtos como fazer um serviço, então farei o que achar necessário"
• "Não está no prod - não está feito." Todo mundo segue suas próprias tarefas. Se o recurso estiver pronto para o teste, você precisará garantir que ele seja lançado no teste. Se ela estiver pronta para a liberação, é necessário garantir que ela entre no produto o mais rápido possível. As pessoas responsáveis ​​pela formação do lançamento nem sempre se lembram de todos os recursos. Sinta-se livre para lembrá-la. [Um lugar para uma chama sobre a distribuição de responsabilidades entre as funções de uma equipe.]
• É necessário ligar a cabeça. Se a tarefa parecer estranha, incompreensível ou muito longa, isso deve ser dito clara e em voz alta ao gerente responsável. E faça isso até ter uma compreensão clara do porquê de tudo ser assim. Acontece que as perguntas certas, feitas na hora certa, economizam semanas de desenvolvimento.

Gerenciamento de tempo

• Se a tarefa não se encaixar dentro de um prazo razoável, devemos falar sobre isso em voz alta. Você não deve sentar e cortar a tarefa por vários meses com uma avaliação de três dias. Se ele se arrasta muito, então algo está errado. Talvez haja um mal-entendido na produção ou subestimamos a quantidade de trabalho. De qualquer forma, essas tarefas devem ser discutidas novamente (e, como resultado, algumas vezes adiadas ou até enterradas).
• Os problemas que surgirem devem ser resolvidos independentemente. Mas se estiver claro que o processo está atrasado, não deixe de falar sobre eles e pedir ajuda aos colegas. Permanecer por vários dias no estado "Eu tenho que fazer tudo sozinho e não distrair meus companheiros" é muito ruim.
• Ninguém olha a que horas cada um de nós chega e sai até ter sucesso, e nosso regime não começa a interferir no trabalho da equipe. Mas sentar à noite apenas porque você não tem tempo para fazer algo não é necessário. Se isso se torna um hábito, o problema é mais profundo - no planejamento, na reavaliação das próprias habilidades, etc. Enquanto o desenvolvedor faz horas extras à noite (e, como resultado, tudo está dentro do prazo), as chances de alguém ver e resolver esse problema são bastante reduzidas.
• Acontece que precisamos lançar um recurso importante até a data acordada (ou o mais rápido possível). Nesse caso, vamos trabalhar em horas extras. Além disso, o líder recebe um grande sinal negativo de karma e deve experimentar sofrimento moral. E certamente não usar essa oportunidade com frequência. Essa hora extra é compensada. [Um lugar para uma chama sobre horas extras e compensação] .

Pecados mortais

Esta é uma seção separada. Aqui, tentei listar o que acho errado e prejudicial ao trabalhar em equipe. Cada um dos itens tem seu próprio peso. Alguns falam de problemas muito grandes, outros não são tão críticos. Portanto, o que deve ser evitado por todos os meios:

• Trabalho, sem incluir a cabeça: "Disseram-me para fazer - eu fiz." Cada membro da equipe deve entender a essência do recurso que ele cria e seu impacto no produto.
• Jogue recursos não esvaziados no estímulo com as palavras "eu fiz tudo". O que fazemos deve funcionar na produção. Enquanto o recurso não estiver em prod, ele não está pronto.
• Concorde em fazê-lo de uma maneira e depois faça silenciosamente do seu jeito. Acima já era sobre "Eu sei melhor do que ninguém o que é melhor". Mas mais uma vez lembrar que isso é ruim não vai doer.
• Aperte recursos importantes, aprofundando a discussão de problemas raros e irreais, mas potencialmente possíveis. Se em um tempo razoável você não conseguir descobrir como solucionar um problema menor e raramente reproduzível , simplesmente concordamos em como conviver com ele.
• Não exponha os problemas a tempo, tentando resolver tudo sozinho (geralmente à noite). Esse heroísmo leva apenas ao fracasso dos termos, ao cansaço e a um sentimento de subestimação: "Faço proezas aqui, mas também sou criticado pelo meu trabalho lento!"
• É doloroso reagir às críticas ao código e esclarecer o relacionamento. Mesmo se um colega disser que o código é coprólito, mais ou menos ("vamos reescrever tudo!"), Trate-o com compreensão e discuta por que ele pensa assim. Para você, pessoalmente, isso não é menos útil do que para o serviço como um todo.
• Vá para a pessoa. Criticando um código ou solução, criticamos apenas o código ou a solução, mas em nenhum caso a pessoa que o escreveu ou sugeriu. Dado o parágrafo anterior, não tenha medo de criticar. Melhor um tempo razoável para discutir com os colegas do que enviar uma decisão malsucedida para estimular.

Total

Aqui você pode escrever mais sobre um milhão de coisas. Mas quanto menor o post, mais fácil é lê-lo até o fim , e eu realmente espero que sim. E sim, não recebo críticas dolorosamente (com a condição de que você não seja pessoal;). Então vamos discutir!