Como superamos as incertezas no Delivery Club

Amigos, olá a todos! Meu nome é Kolya Arkhipov, sou responsável por Pesquisa e Desenvolvimento no Delivery Club.



Nossa equipe resolve tarefas intensivas em ciência na plataforma FoodTech: desenvolvemos componentes baseados em algoritmos e dados, muitos dos quais na plataforma DC. No processo de resolução, enfrentamos muitas incertezas, tanto do lado comercial quanto do desenvolvimento.



O material acabou sendo volumoso e, espero, útil para você. Portanto, eu recomendo colocar em um bule e preparar um café delicioso, eu mesmo fiz isso enquanto trabalhava neste artigo.



Hoje vou lhes contar sobre a corrida que nossa equipe passou no ano passado. A analogia surgiu por si mesma - trabalhamos em uma empresa muito dinâmica, a líder de mercado FoodTech na Rússia. Estamos desenvolvendo rapidamente diferentes áreas de negócios e isso realmente impulsiona! Não apenas chegamos à linha de chegada com sucesso, mas também obtivemos muitos insights sobre a corrida. Isso é o que quero compartilhar com você.

O artigo apareceu após o relatório na conferência RIT ++ 2020 . Para quem adora vídeo, procure no final do artigo.

A chaleira já está fervendo? Super! Então, o que será discutido hoje:

1. P&D e incerteza. O que enfrentamos.
2. Experimentos. Como e por que os conduzimos na batalha.
3. Mensurabilidade. Vamos discutir a escolha de métricas e trabalhar com riscos.
4. Autonomia. Como nós da DC Tech adaptamos a estrutura GIST e a abordagem Inner Source.

Luz verde, embreagem, primeiro - vamos lá.

P&D e incerteza

Em algumas empresas, a equipe de P&D está envolvida na pesquisa fundamental de novas tecnologias. O objetivo dessa pesquisa pode ser o desenvolvimento de processos atuais e verticais de negócios completamente novos. Por exemplo, o blockchain era uma tecnologia assim há alguns anos.



Imediatamente, queremos dizer outra coisa. A P&D no Delivery Club trata da solução de problemas aplicados. Nosso negócio está crescendo rapidamente, o número de pedidos está crescendo e a maioria de nossos processos internos é baseada em dados e algoritmos. Com um aumento na quantidade de dados de entrada, alguns algoritmos deixam de ser eficazes, e aqueles componentes que nos serviam completamente ontem, hoje frequentemente consideramos inoperantes.



Como você deve ter adivinhado, esses problemas costumam ser fracamente determinísticos e, como resultado, são acompanhados por muitas incertezas de todos os lados. Vamos destacar os principais:





Vamos examinar mais de perto o que estamos enfrentando e se essas são realmente dificuldades.



Como alcançar o objetivo



Sempre entendemos claramente o objetivo do negócio - em que direção planejamos seguir, para onde devemos ir. Mas nem sempre está imediatamente claro como abordar esse objetivo quando se trata de tarefas de pesquisa. Qual estratégia adotar: por meio de experimentos ou um grande lançamento do recurso imediatamente? Construir ambientes com simulação ou experimento em combate? A escolha é grande - os olhos se erguem.



O que exatamente vale a pena fazer



Ok, entendemos o objetivo do negócio e concordamos em qual estratégia seguiremos. É hora de decidir sobre um conjunto específico de recursos que usaremos para funcionar. Como escolhê-los, o que incluir no backlog, em que ordem: você precisa determinar não apenas "o que exatamente vale a pena fazer", mas também quem terá o máximo de expertise em nossa área.



Quando podemos alcançar nosso objetivo



O momento certo é certamente muito importante para os negócios. Pesquisar é legal e divertido, você pode procurar novos recursos nos dados, pesquisar algoritmos, ler notas interessantes de nossos colegas em outros países. Mas é importante para as empresas entender quando a meta será alcançada, porque um recurso lançado na hora errada muitas vezes simplesmente não é necessário - o mercado FoodTech é tão dinâmico agora.



Por que alguém precisa do meu código?



A incerteza final, mas longe de ser significativa, é uma questão de motivar os desenvolvedores. P&D é em grande parte um desenvolvimento experimental, como resultado, nosso código nem sempre cria raízes na produção. A princípio ficamos muito chateados porque não entendíamos porque fizemos o recurso, e de todo o coração, e o negócio decide que não funciona e precisa ser serrado. Perguntas - por que estou fazendo isso? Por que alguém precisaria do meu código? - apareceu conosco com bastante frequência. No processo, percebemos como podemos e devemos trabalhar com isso, e agora temos a certeza de que essa é uma das incertezas mais críticas que precisa ser superada antes de tudo.



E assim, tendo preenchido um monte de saliências tão decente, reunimos todos os nossos problemas em um só lugar e percebemos que, para a felicidade, faltam três processos na intersecção dessas incertezas.

1. , , .
2. . , , . , - , , .
3. , , - . . IT- ( ), , , , 2-3 . — , .

Esquematicamente na imagem abaixo.



Os experimentos responderão às questões de como atingir os objetivos e o que exatamente fazer. As métricas permitirão que você responda de forma muito clara e transparente à pergunta se esse código deve realmente permanecer em produção. A autonomia total ajudará a avaliar e cumprir os prazos.



Nós não paramos. Embreagem, segunda marcha, estamos ganhando impulso rapidamente.

Experimentos

Considere uma plataforma de atribuição automática de correio personalizado. Ela tem uma tarefa bastante simples - reunir três participantes do mercado: nossos parceiros, logísticos (ou seja, seus entregadores) e clientes, de modo que todos os participantes fiquem satisfeitos. Ou seja, quando chega um pedido, devemos escolher um courier que chegará ao restaurante exatamente no momento em que o restaurante terminar de preparar o prato, rapidamente o pega e entrega ao cliente quente e saboroso na hora que prometemos.



Parece bastante simples, e aqui você pode dizer - teoria suficiente! É hora de avançar para lançamentos reais.



Concordo com você, mas ainda vamos nos alongar um pouco no processo de experimentos. Vamos dar uma olhada em todo o quadro.

1. - — . — , , .
2. — . . — , .
3. — Just In Time. , : , , . , , , . , FoodTech- : , . , .

Vamos dar uma olhada em qual processo está sob o capô do incremento do produto.







3.1 Hipótese. Pode ser formulado em palavras ou mostrado esquematicamente. O principal é justificar claramente porque deve funcionar. Ou seja, o experimento deve ter treinamento teórico.



3.14 Desenvolvimento. Não vou me alongar aqui, mais detalhes sobre nosso desenvolvimento são descritos neste artigo . Usamos Scrum, iterações de duas semanas com todas as atividades necessárias.



3.2 Preparação. Em seguida, você precisa preparar um experimento. Ou seja, precisamos decidir sobre o geossegmento ou público com o qual queremos nos comunicar durante este experimento. E também selecione o segmento com o qual iremos comparar os resultados.



3.3 Experimento. Em seguida, iniciamos o próprio experimento. Um ponto importante: antes mesmo do início, concordamos com as métricas de negócios que iremos monitorar. Vamos sair hoje da discussão das métricas técnicas, que nos dizem que o experimento está lançado e tecnicamente estável, vamos falar mais sobre indicadores de negócios. Definitivamente corrigiremos os sinais de alerta - esses são alguns valores de limite que não devemos ultrapassar durante nosso experimento.



3.4 Análise. Acumulamos muitos dados interessantes e únicos que só nós temos. Seria estranho não extrair deles informações úteis, ou seja, tirar conclusões razoáveis ​​sobre a validade da hipótese que está sendo testada, bem como enfatizar coisas novas sobre o público de nosso serviço.



3.5 Conclusão.Provavelmente o ponto mais importante neste processo. Em nosso caso, a saída está sempre pressionando três botões:

• lançar o experimento ainda mais, para a próxima geografia ou para o próximo segmento do público;
• reverter se algo der errado;
• continuar. Há casos em que vemos a influência de fatores de terceiros, os quais não levamos em consideração e, como resultado, não podemos tirar uma conclusão inequívoca. Nestes casos, decidimos continuar.

Experimento real

Finalmente é hora de ver como isso funciona com um exemplo do mundo real. Você já está cansado? A diversão começa.



De volta à plataforma de atribuição automática. Antes disso, sugerimos que a abordagem Just In Time seria muito legal para nós reduzirmos o tempo de entrega. Vamos compará-la com a estratégia de atribuição atual, que denotamos como um algoritmo guloso.



Para começar, vamos justificar a hipótese.

Algoritmo ganancioso

Sua principal característica é prescrever imediatamente. Assim que a encomenda chegar à plataforma, procuramos o correio do nosso parceiro mais adequado para esta encomenda, marcamos sem demora e informamos o transportador sobre esta encomenda. Como resultado, otimizaremos o tempo gasto na procura de um mensageiro. Mas essa abordagem nem sempre é eficaz, porque em um minuto a situação pode mudar: um novo pedido chega ou outro mensageiro é liberado. O algoritmo não reage mais a isso. Abaixo está uma ilustração.





Neste exemplo, temos um total de 45 minutos para escolher dois pedidos. Parece que podemos fazer melhor.

Na hora certa

A tarefa desse algoritmo é escolher exatamente o courier que chegará ao restaurante exatamente no momento em que o pedido estiver pronto. O que isso vai nos dar? Em última análise, reduzirá o tempo de entrega devido ao fato de que:

• o mensageiro passará menos tempo no restaurante;
• vamos escolher o correio de forma mais otimizada.

Tecnicamente, isso é muito simples de implementar. Quando uma encomenda é recebida, escolhemos imediatamente um transportador, mas não lhe comunicamos a encomenda, marcando assim um “encontro virtual” e dando-nos tempo para alterar a nossa escolha. E finalmente decidiremos (se transferimos o pedido para o courier) apenas quando o caminho para o restaurante for igual ao tempo restante para a preparação do pedido. Esquematicamente - na ilustração abaixo.







Como resultado, selecionamos os pedidos em apenas 30 minutos, o que é um terço a menos que no caso anterior.



Na minha opinião, a hipótese é justificada, estamos levando-a para o desenvolvimento. Conforme acordado, não consideraremos o processo de desenvolvimento em detalhes.

Vamos prosseguir com a preparação do experimento

O que precisa ser preparado no nosso caso? Nem tanto: o período do teste A / B, a geografia do experimento e aquele com o qual iremos comparar. Estabelecemos uma cidade específica, selecionamos as condições de forma a minimizar o impacto de uma estratégia de consulta na segunda.



Definitivamente negociaremos com a empresa sobre bandeiras vermelhas e reações a elas. As bandeiras vermelhas são limites de métricas de negócios que não queremos cruzar durante o experimento. Se cruzado, no número esmagador de experimentos isso é reversão. Mas há exceções quando sabemos com certeza que o cruzamento não aconteceu por nossa causa, mas foi resultado de outros fatores. Nesse caso, às vezes podemos decidir continuar o experimento.



O que mais precisa ser preparado? Combine com nossos colegas da sala de controle, que observam em tempo real que está tudo bem com pedidos. Para eles, nossa mudança será visível, pois antes de atribuirmos um pedido para o courier imediatamente, mas agora que não fazemos isso, nos damos um tempo para mudar de ideia. É por isso que os colegas devem ser alertados sobre os experimentos planejados.



Ok, vamos em frente. Preparou um experimento, conduziu e obteve os resultados. E aí vem a parte divertida - a análise.

Análise Experimental

Concordamos em melhorar o tempo total de entrega e, de repente, havia quatro programações. Vale a pena explicar aqui. Ao iniciar um experimento, é importante olhar não para uma métrica principal, mas para vários indicadores de negócios que são críticos para o negócio - neste caso, podemos reduzir significativamente os riscos de uma hipótese de fracasso afetando processos reais na plataforma. Sejamos honestos, cometemos esses erros no início de nossos experimentos e às vezes eles levavam a consequências realmente desagradáveis. Mas erros são bons, aprendemos com eles.



Vamos dar uma olhada nos resultados. Mostraremos os gráficos sem valores específicos, pois o objetivo do artigo não é uma análise detalhada da eficiência do algoritmo Just In Time. Queremos nos concentrar mais em nossa abordagem ao conduzir experimentos. Pelo mesmo motivo, não vamos nos alongar sobre a teoria da realização de testes A / B e determinação da significância estatística dos resultados, este é um assunto extenso para a próxima publicação, e talvez até mesmo para todo o ciclo.

• « ». , , . , . , — , . , . , , . , . , , (/), — , , . -, .
• « ». . , , , . , . , .
• « » « ». : . .

Como resultado, temos uma diminuição na métrica principal (1), uma diminuição em uma métrica muito importante (2), valores estáveis ​​de duas outras métricas principais (3, 4), as bandeiras vermelhas não estão acesas. Isso nos permite concluir sobre o sucesso do experimento e a validade da hipótese que está sendo testada.



Classe! Você correu para a próxima hipótese? É fantasticamente divertido e projetado para melhorar a vida de todos! Mas não, isso não é tudo. Resta, talvez, um dos passos mais importantes, que não devemos esquecer. Isso é para pressionar um dos três botões:

1. Sair da cama
2. Rollback
3. Continuar

No processo de experimentos, a equipe deve ter um colega cuja função é ficar totalmente responsável pelo recurso, que pressionará um desses três botões. No início, tivemos casos em que nos esquecemos desta etapa, como resultado, recebemos várias dezenas de experimentos lançados simultaneamente sem um status compreensível para cada um deles. Eles deram resultados positivos, mas não foram totalmente implementados, o que é ineficaz para os negócios. Além disso, tivemos que gastar recursos significativos apenas para lembrar os detalhes e colocar as coisas em ordem. Mas, novamente, aprendemos com os erros.

Experimentos do mundo real

Detenhamo-nos brevemente em por que experimentamos imediatamente na batalha. Essa abordagem costuma ser contrariada por ambientes de simulação analítica, que, com base em dados históricos, podem, com certa precisão, responder o que “seria” se implementássemos tal recurso.



Por que escolhemos a primeira abordagem para nós mesmos? Duas razões.

• -, .
  
  , , . , - , , . — .
  
  
  
  . .
  
  
  
  ? , , , — . , , , , , . , .
  
  
  
  Vale a pena ser honesto aqui, que esta é uma abordagem bastante arriscada. O risco de decepcionar o público, os clientes, os negócios. Este artigo é amplamente dedicado a como reduzir esses riscos: selecione com cuidado e precisão as métricas (várias) e monitore-as em tempo real. Caso algo dê errado, simplesmente desligamos o experimento imediatamente.

• O segundo é, obviamente, a velocidade. Experimentos em condições de combate mostrarão resultados com muito mais precisão e rapidez.

Antes de prosseguirmos, vamos consertar algumas pequenas vitórias.





Um processo de experimentação transparente nos dá a resposta à pergunta de como atingir um objetivo. E ao conduzir testes imediatamente em condições reais, começamos a entender melhor nosso público. Como resultado, a equipe de desenvolvimento tem conhecimento suficiente para propor recursos específicos que resolvam um problema de negócios.



Não é ruim, mas não é tudo. Agora é a hora de falar mais sobre mensurabilidade. E enquanto isso ligamos o terceiro, gás para o chão, o vento assobia.

Mensurabilidade

Por que precisamos de métricas? Principalmente para confirmar uma hipótese ou reduzir o impacto de uma hipótese falhada. Hipóteses, mesmo bem fundamentadas em teoria, nem sempre disparam. E quando atiram, às vezes no joelho.

• -, FoodTech, : , , , .
• -, , , . , , , . ! , , , . , , -.

Nossa experiência mostra que uma boa receita é quando existem várias métricas. Uma métrica de destino - melhorando-a; e alguns mais importantes - não devemos abandoná-los.



Apresente um espaço de monitoramento unificado para o qual os negócios e o desenvolvimento olham. Não precisa ser uma ferramenta, usamos duas: Metabase e Grafana, mas no futuro planejamos escolher uma delas. Mais importante ainda, deve haver um único espaço onde os colegas de negócios e de desenvolvimento irão olhar. E certifique-se de identificar bandeiras vermelhas.

bandeiras vermelhas

Sim, esses são alguns valores-limite de métricas que não devemos cruzar durante o experimento. Vale a pena concordar com a empresa sobre as reações, se cruzaram, e postar alertas sobre elas.



E mais uma pequena vitória: respondemos à pergunta “Por que alguém precisa do meu código?”. Não vamos nos esquecer dela!





Gostaria de lembrar que essa incerteza por parte do desenvolvimento é que nem sempre entendíamos por que nosso código não permanecia em produção e, francamente, ficamos tristes com isso. Ao adotar uma abordagem de imersão ponto a ponto, desde o desenvolvimento até as métricas de negócios, não apenas melhoramos nosso entendimento das soluções para o cliente, mas também nos proporcionamos uma dose de impulso na resolução de problemas de negócios com foco no resultado final.



Ok, descobrimos experimentos e processos transparentes, métricas e mensurabilidade. À frente está a linha de chegada, viramos na quarta, e em velocidade máxima até a vitória.

Autonomia

Todas as opções acima funcionam tão bem quanto possível somente quando nos tornamos autônomos tanto do lado comercial quanto do desenvolvimento.

ESSÊNCIA

Aqui, por autonomia, queremos dizer a dependência mínima na hora de tomar uma decisão. O que fizemos no lado comercial para tomar decisões rapidamente e não nos afogar em processos de aprovação? Implementamos a estrutura GIST.





Esta abordagem é Objetivos, Idéias, Projetos de Etapa, Tarefas. A empresa tem objetivos de negócios claros que a administração comunica de forma transparente a todos os funcionários. Para atingir esses objetivos, os funcionários lançam ideias. Pode haver uma dúzia ou uma ideias. É importante que uma ideia ainda não seja um projeto. Essas são algumas das abordagens que gostaria de implementar. Step-project - já são projetos: recursos bastante grandes que implementam essas ideias. Em nosso exemplo Just In Time, o destino é exatamente o Step-project. No último nível estão as tarefas a que estamos acostumados - este é um projeto em etapas decomposto, estimado em custos de mão de obra.



Então, como a abordagem o ajuda a alcançar autonomia? Quando nos propomos a fazer esse recurso (Just In Time), a empresa vê com transparência:

1. O tamanho e o custo de implementação do recurso.
2. Que ideia ele está implementando.
3. Qual é o objetivo específico da empresa (impacto).

Então, só precisamos compará-lo com o projeto Step vizinho de acordo com os mesmos critérios: custo, impacto. Fazemos uma reunião (eles são regulares conosco), discutimos, priorizamos e tomamos uma decisão.



Parece muito simples e direto. No nosso caso é, e funciona: o negócio toma decisões rapidamente, estamos felizes. Mas este é apenas o primeiro passo para a autonomia, porque do lado do desenvolvimento também não devemos ser bloqueados.

Fonte Interna

É como código aberto, apenas dentro da empresa. A arquitetura do Delivery Club é composta por microsserviços, agora são mais de uma centena. Muitas vezes, para fazer um recurso, é necessário modificar não apenas os componentes pelos quais nossa equipe é responsável, mas também os serviços vizinhos. E aqui temos duas maneiras:

1. Coloque melhorias no backlog das outras equipes, concorde que os caras as farão.
2. Faça Você Mesmo.

Em nossa adaptação, o processo funciona da seguinte maneira. Há um grande recurso Just In Time que afeta três grupos de serviços:

• uma plataforma de atribuição automática pela qual R&D é responsável,
• plataforma de logística,
• componentes de interação com parceiros (restaurantes e lojas).

Nós fazemos isso:

1. coletar todas as tarefas na carteira da equipe de P&D;
2. priorizamos e distribuímos dentro da equipe qual dos caras vai refinar qual dos componentes;
3. concordamos com os líderes técnicos das equipes de logística e áreas parceiras sobre as nuances de implementação;
4. nós nos desenvolvemos, os colegas fazem uma revisão;
5. então nós nos testamos;
6. Já estamos dando aos proprietários de serviço para iniciar a produção.

Depois de entrarem em produção, essas melhorias ficam a cargo das equipes proprietárias desses serviços.



Para ser absolutamente honesto, a abordagem não é perfeita e apresenta riscos. O principal é o tempo. Na maioria das vezes, modificamos os componentes de 2 a 2,5 vezes mais do que os proprietários do serviço teriam feito.



Mas o benefício também é óbvio, supera em muito o pequeno atraso na implementação - é previsível. É importante notar aqui que outras equipes têm suas próprias pendências, suas próprias prioridades e, na maioria das vezes, não podem realizar nossas tarefas “com urgência”. Portanto, nosso prazo de negócios é realista, não será afetado por possíveis mudanças de prioridades em outras equipes.



Então, parabéns - termine, vitória!





Implementamos a estrutura GIST para uma tomada de decisão rápida e transparente e a abordagem Inner Source para autonomia no desenvolvimento e agora todas as peças do quebra-cabeça estão montadas. É hora de encerrarmos, foi uma corrida interessante, obrigada pela participação! Vamos resumir.

conclusões

• Um experimento é uma ferramenta transparente e eficaz para atingir um objetivo.
• Fazendo isso em um ambiente real, estudamos nosso público, o que nos permite fazer mudanças cada vez mais úteis, e também entender porque nem todos os recursos devem permanecer em produção.
• Mas para evitar o caos, você precisa de um processo claro, a distribuição de funções e a nomeação de uma pessoa responsável.
• Na fase ativa do experimento e durante a análise, vale a pena monitorar várias métricas-chave ao mesmo tempo e não se esquecer de tirar uma conclusão (no nosso caso, pressione um dos três botões).
• Tomar decisões rápidas e com autonomia no desenvolvimento ajuda a alcançar resultados e a manter a equipe motivada.

Gravação de vídeo do relatório da conferência RIT ++ 2020 .





Isso é tudo, obrigado por estar comigo nesta corrida. Tenho certeza de que estamos no começo e que grandes desafios ainda estão por vir. Terei prazer em compartilhá-los, até breve!