Eu sempre quero inventar algo novo e necessário em meu serviço. Especialmente se os usuários gostarem deste serviço. Mas de onde você tira as idéias? Como priorizar? E como trazer rapidamente uma ideia a um produto sem perder nada importante ao longo do caminho?
Meu nome é Alexander, lidero um dos grupos de desenvolvimento de interfaces no Yandex.Market. Hoje vou contar aos leitores de Habr sobre a nossa experiência na solução desses problemas. Também consideramos um exemplo de entrega de recursos à produção.
A equipe
O Yandex.Market é o maior recurso da Rússia para selecionar mercadorias e comparar preços. Todos os dias, 3,5 milhões de pessoas o usam - planejam suas futuras compras aqui, discutem produtos e ajudam outras pessoas a fazer a escolha certa.
Agora, o Yandex.Market emprega 40 desenvolvedores de front-end e seu número está crescendo. Sim, 40 pessoas - este é apenas o frontend do mercado, e também existem frentes de nossos outros dois projetos - os mercados de Beru e Bringly. Em 2005, havia apenas 5 desenvolvedores no mercado, imagine?
Ideias nascem em nossos circuitos. Por isso, chamamos equipes compostas por diferentes especialistas. Normalmente, um circuito inclui: um projeto (também conhecido como engenheiro de produto), back-end, front-end, análises, designers e testadores. Essa equipe pode desenvolver algo de forma independente no serviço e resolver problemas de qualquer complexidade. Além disso, cada circuito tem um claro perímetro de responsabilidade - um certo "circuito funcional" no produto em que trabalha.
Temos, por exemplo:
- loop de conversão - lida com UX, ferramentas de pesquisa, filtragem e classificação;
- circuito de comunicações - funciona em boletins e promoções para nossos usuários;
- contorno dos benefícios - trata de descontos, reembolso, códigos promocionais;
- Circuito comunitário - responsável por análises, análises, discussões, realizações, mecânica de jogos e outros UGC.
Idéias
Qualquer membro de um circuito pode oferecer uma ideia. Congratulamo-nos com todas as opções, mesmo triviais ou absolutamente loucas. Geralmente, os caras geram idéias nas assembléias gerais - isso cobra toda a equipe para trabalhar.
Para não perder nada, colocamos todos os nossos pensamentos em um turno separado no Tracker - nosso banco de idéias. As idéias coletadas são avaliadas de acordo com a estrutura GIST + ICE. Avaliamos o potencial de cada ideia e os custos trabalhistas da implementação para decidir o que vale a pena levar em primeiro lugar. Mais detalhes sobre esse método foram
informados pelo meu colega.
As idéias que marcaram mais pontos se transformam em projetos com o cliente e os artistas. Um enorme conjunto de tarefas de design aparece no Tracker. As tarefas são distribuídas pelo líder da equipe para os sprints e entram na equipe.
O ponto importante é que a idéia seja implementada pelo circuito que a sugeriu. Ou seja, os autores da ideia também são seus artistas. Tente trabalhar em sua tarefa, e não em uma tarefa iniciada de cima - a diferença será fácil de sentir.
O processo
Suponha que decidimos desenvolver um carrossel de mercadorias para o usuário, levando em consideração seus interesses.
Suponha que os backenders de loop já tenham feito seu trabalho, a rede neural esteja treinada, a API esteja pronta, testada e implantada em um ambiente de teste. Os layouts do designer de contorno são recebidos e têm a seguinte aparência:
Resta fazer o trabalho no front-end e entregar nosso carrossel ao usuário.
O Frontend of the Market é um cliente da Web e um servidor NodeJS sem estado, por trás do qual existem dezenas de outros back-ends: pesquisa, serviços de consultoria, análise, conteúdo UGC e muito mais. O frontend vive nas nuvens Yandex em vários CDs. O aplicativo NodeJS é executado em contêineres e, devido à sua natureza sem estado, pode ser dimensionado horizontalmente conforme necessário:
Os desenvolvedores de front-end do mercado estão desenvolvendo o lado do servidor no NodeJS e o cliente no React + Redux. Desenvolver em um idioma e em um ecossistema é muito eficaz. Se você ainda está pensando em unificar sua pilha de tecnologia entre o servidor e o cliente, tente - isso faz sentido.
Para finalizar o carrossel, precisamos adicionar o código para recebimento de mercadorias no servidor e implementar a parte do cliente. Você pode tornar o carrossel preguiçoso - carregue-o logo antes de aparecer na tela. Para fazer isso, você precisará implementar adicionalmente o terminal na API do cliente.
Quando isso é feito, o desenvolvedor cria uma solicitação de pool e envia seu código para a revisão de código. Nossa revisão de código é uma obrigação. Para que não ocorra, temos até um SLA recomendado para sua implementação. Você pode
ler sobre como aceleramos a revisão de código
aqui .
Estamos desenvolvendo o front-end no GitHub Enterprise, que está disponível apenas na rede interna. Existe um bot no Github que ajuda a organizar revisões de código. O bot em si encontra os revisores, os contata no messenger, os adiciona ao GitHub, controla o status do ticket no Tracker e, se necessário, chama o autor do código.
No momento da criação da solicitação de pool no GitHub, muita coisa está acontecendo: no ambiente de teste, um stand de demonstração com o Market atualizado é gerado e os links de acesso a esse stand são entregues ao ticket de tarefa. Muitas verificações automatizadas são realizadas: linter, formatador, testes de unidade. Os testes E2E são executados, as métricas do aplicativo cliente são analisadas automaticamente. Se alguma degradação for detectada, um relatório detalhado será imediatamente entregue ao ticket da tarefa:
Se todas as verificações tiverem passado normalmente, o ticket será automaticamente transferido para o status "Você pode verificar" e a tarefa aparecerá no painel da equipe de controle de qualidade.
Depois que o engenheiro de controle de qualidade chegou ao ticket de tarefa e certificou-se de que a nova funcionalidade esteja pronta para viagens adicionais, o ticket é marcado com uma etiqueta de liberação. O próximo lançamento incluirá todos os tickets com essa tag.
O mercado é frequentemente lançado, 1-2 vezes por dia, e estamos trabalhando para aumentar a frequência de nossos lançamentos. A pessoa de serviço da equipe de controle de qualidade está envolvida na preparação e liberação da liberação, e o processo de liberação é totalmente automatizado. Anteriormente, o pacote de lançamento era montado manualmente, demorava muito tempo. Agora, os desenvolvedores podem gastar esse tempo desenvolvendo o produto. Isso acelera a entrega de novas funcionalidades aos nossos usuários.
Portanto, nosso carrossel de produtos recomendados será lançado. Como está indo isso?
O engenheiro de controle de qualidade em serviço pressiona o botão de liberação. O pipeline de liberação começa a funcionar. A apresentação do relatório do processo de liberação pode ser vista
aqui . Um ticket de liberação é criado no Rastreador e uma ramificação de liberação no GitHub. Todas as solicitações de pool que passaram nas verificações são automaticamente derramadas nele. Em um ambiente de teste, um suporte com uma nova versão do Market aumenta. Nesse suporte, todas as verificações automatizadas acima são aprovadas, além de várias outras. Por exemplo, carregue o teste com carga constante e aumentando até que o aplicativo de teste seja depurado. Todos os logs de auditoria são analisados em tempo real, são gerados relatórios claros, que são entregues imediatamente ao ticket de liberação:
O engenheiro de controle de qualidade vê todas as etapas, com uma olhada ele pode avaliar os resultados da massa de verificações. No ambiente de teste no estande com a nova versão, o controle de qualidade também passa por testes manuais. Frequentemente, realizamos testes A / B de novas funcionalidades e não escrevemos testes E2E nela.
É assim que o pipeline de lançamento fica (clicável):
Quando a versão passa em todas as verificações no ambiente de teste, ela é entregue ao prestável. Prestável é outro ambiente, mas com back-ends de combate, fechados por visitantes reais do mercado. Algumas empresas chamam isso de preparação. Nesse ambiente, uma série de verificações específicas e testes funcionais manuais também são realizados. Se nenhum problema for encontrado, a nova versão do Market será enviada aos nossos usuários e começará a se desdobrar no cluster de produção.
No momento do layout da batalha, o trabalho dos robôs continua. Eles analisam independentemente os logs do aplicativo, procuram anomalias e degradação no trabalho do serviço e monitoram as métricas do cliente. O monitoramento de logs continua por algum tempo após o lançamento, e a próxima versão do Market já está sendo testada no ambiente de teste.
A saúde do mercado após o lançamento também é monitorada pelo controle de qualidade em serviço. Ele tem um grande número de gráficos à sua disposição - usamos o Graphit e o Grafana. Os gráficos têm tudo: desde o plano geral de 500 k até os erros do aplicativo NodeJS ao se comunicar com vários back-ends discriminados pelo DC. Também temos um grupo separado de pessoas - o grupo de saúde do mercado. Ela monitora as métricas de mercado 24/7.
Se um problema for detectado, a liberação reverte automaticamente do cluster de combate. O problema é desmontado e o lançamento é devolvido à batalha. Se não houver problemas, a liberação será concluída, o código será mesclado no mestre, os tickets entrados na liberação serão fechados e as ramificações do projeto serão excluídas. Tudo isso também acontece automaticamente.
Neste momento, nossos usuários já veem os produtos selecionados para eles e o circuito está trabalhando em uma nova idéia.
Aqui está o nosso carrossel no serviço:
Em vez de uma conclusão
Torne suas equipes flexíveis e independentes, deixe-as gerar idéias, cuide delas, analise-as - definitivamente existem diamantes entre elas. Lembre-se de que a ideia expressa por alguém com uma voz incerta e silenciosa durante uma reunião pode ser a chave do seu produto e de seus usuários.
Deixe seus autores incorporarem idéias o máximo possível - para que o trabalho seja mais rápido e melhor. Automatize a rotina. Reserve um tempo para traduzir idéias em realidade, deixe os robôs fazerem o resto.
Se o leitor estiver interessado em falar sobre algo com mais detalhes, escreva nos comentários, responderei com prazer, ou talvez o descreva em um novo artigo.