Transformação de produtos na Delivery Club Tech

Olá, Habr! Como prometi no post anterior , continuo apresentando o Delivery Club Tech. Hoje vamos falar sobre transformação de produtos.



Coincidentemente, minha chegada em DC em outubro de 2018 foi marcada por uma reestruturação total de todos os processos da equipe. Naquele momento, o departamento de TI, e sim toda a empresa, enfrentou novos desafios. Estava claro que os processos antigos não atendiam aos novos requisitos. Eles se referiam principalmente ao declínio do Tempo de chegada ao mercado.



É sobre essas mudanças, novos desafios, uma nova estrutura de equipe, como trabalhamos sem gerentes de projeto e analistas técnicos e as abordagens para o desenvolvimento de produtos que quero contar a vocês hoje.



Em outubro de 2018, assumi o cargo de Chefe do Consumidor. Este foi o início de minha jornada para o Delivery Club. Era necessário montar equipes de produto dentro da direção, descrever os processos, formalizá-los e dimensioná-los para todas as outras áreas. Além disso, a tarefa era derivar métricas de desempenho para equipes e desenvolver uma estrutura de recrutamento do zero.

Recursos da equipe

O desafio mais importante foi conseguir previsibilidade e transparência no processo de desenvolvimento. A situação era complicada pelo fato de não haver métricas de desempenho naquela época. Mas o que era certo: os lançamentos não aconteciam periodicamente, e sua composição era clara apenas na hora do lançamento em si.



Outro problema é que as equipes não foram formadas em torno do produto. Essa comunicação complicada com o negócio, uma vez que o mesmo desenvolvedor poderia participar de projetos completamente diferentes, não havia um foco claro em uma tarefa específica. Portanto, inicialmente decidiu-se reconstruir a estrutura do departamento de TI e passar das equipes de plataforma para as equipes de produto.



Com a abordagem de plataforma, as pessoas de back-end sentavam-se separadamente, os front-endrs sentavam-se separadamente e cada equipe tinha um líder de equipe que distribuía as tarefas. As deficiências óbvias dessa estrutura: os desenvolvedores não estavam imersos no processo e no produto, não estavam interessados ​​no objetivo comum, as equipes tinham enfoque diferente e também não havia recursos dedicados para o produto. Como resultado, o desenvolvedor foi desfocado, os objetivos permaneceram inatingíveis. Mesmo que por algum milagre fosse possível atingir a meta, devido à falta de comunicação entre os gerentes de produto e as partes interessadas, muitas vezes não era o que estava planejado originalmente.







A primeira coisa que decidimos fazer: uma equipe - um produto. Os recursos são alocados, ou seja, a equipe realiza tarefas apenas para este produto e nenhum outro. As equipes que trabalham em produtos semelhantes formam a direção do desenvolvimento. A primeira transformação resultou em 4 direções:

1. Consumidor
2. Logística
3. Fornecedor
4. interno

A segunda coisa que decidimos fazer: designar um gerente de produto para cada equipe. Ele também faz parte da equipe. O gerente de produto desenvolve uma estratégia para mudanças no produto, forma as métricas do produto nas quais a equipe se concentra e define metas para o sprint.



Como resultado, obtivemos a seguinte célula: "Product Manager - Team Lead - Dev - QA". Incluímos desenvolvedores de back-end e front-end como desenvolvedores, mas também existem equipes sem frentes. Os frontenders são Web Angular e JS ou iOS / Android.



Agora, cada equipe tem em média 5 ± duas pessoas. Por que é que? Não chegamos a essa fórmula imediatamente. Nossas estatísticas mostram que esta é a composição da equipe que permite alcançar o resultado mais previsível. Ou seja, a equipe é capaz de assumir recursos suficientes para fazer mudanças significativas no produto, mas ao mesmo tempo a complexidade do planejamento permanece menor do que seria com mais pessoas. Ou seja, o erro de planejamento torna-se mínimo.



Por um tempo, experimentamos funções dentro da equipe, tínhamos líderes de equipe de desenvolvimento móvel (iOS / Android) e um líder de equipe de back-end. Mas acabamos com uma estrutura matricial:

• Um líder de equipe (como regra, alguém do back-end), ele tem gerentes de controle de qualidade, back-end e front-end diretamente sob sua supervisão.
• product- « — — QA».
• — . . , QA- , CI/CD, QA- .
• - , .
• .

Outra característica nossa: não contamos com gerentes de projetos e analistas técnicos. Esse era originalmente o caso no Delivery Club, e decidimos que não o mudaríamos. Lembra que tivemos um problema com as equipes se concentrando no produto? Então, por que criar intermediários entre a equipe e o gerente de produto? É importante para nós que as equipes, em primeiro lugar, se preocupem em como seus recursos afetam o usuário final, e não apenas fechem os tickets no Jira. Para fazer isso, as pessoas precisam mergulhar no contexto, domínio, negócios e até mesmo nas métricas de produto e financeiras.



Como resultado, o diálogo entre a equipe de desenvolvimento e o gerente de produto é contínuo. Os desenvolvedores não apenas pegam uma lista de tarefas do gerente de produto e partem para desenvolver tudo isso, mas podem vir até ele em algumas horas e dizer, por exemplo, "Ouça, podemos deixar o botão aqui um pouco mais simples, mas uma semana mais rápido", mostre nos números, e o gerente de produto dirá OK.



Assim, a equipe técnica realiza a tarefa de análise técnica, avaliação e decomposição de forma independente e, a seguir, planeja um sprint com o gerente de produto. Para que isso funcione, começamos o sprint, por assim dizer, uma semana antes de começar. Esta é a próxima seção.

Desenvolvimento e planejamento de sprint

Pré-planejamento

Uma semana antes do início do sprint, o gerente de produto traz casos e design e responde à pergunta "O que precisa ser feito?" A equipe técnica decide como vai fazer e quando tudo estará pronto.



Para fazer isso, a equipe tem uma semana, durante a qual o líder da equipe, os desenvolvedores e o controle de qualidade se reúnem, discutem detalhes técnicos, realizam a decomposição e reiniciam o pôquer de planejamento para avaliação. Durante esse período, o QA faz uma lista de casos de teste, que serão testados.

Planejamento

Uma vez que a equipe tenha feito a decomposição e avaliação, o planejamento começa. Todas as tarefas são divididas em 8 horas. Para contar o número de tarefas em um sprint, multiplicamos o número de funcionários por 80 horas de uma iteração de duas semanas, multiplicando o resultado por um fator de foco de 0,8.



Outras tarefas são realizadas em baldes, existem apenas três delas:

1. Produto 60%
2. Dívida de tecnologia 20%
3. Suporte 20%.

Deixe-me lhe dar um exemplo. Temos uma equipe de 3 backenders. Isso é 80 * 3 * 0,8 = 192 horas úteis. Gastaremos 116 horas (60%) no desenvolvimento de produtos, 38 horas no débito técnico (20%) e 38 horas no suporte (20%).

Grooming

Na segunda-feira agendamos tarefas, e no meio do sprint, ou seja, uma semana depois, acontece o aliciamento. Grooming é a análise dos resultados da primeira semana e a tomada de decisão se temos tempo para atingir a meta do sprint ou algo deve ser interrompido. Se a meta for alcançada, o gerente de produto apresenta planos para o próximo sprint na mesma reunião e todo o ciclo se repete.

Demo

A conclusão lógica do sprint é a Demo, onde convidamos todas as equipes de desenvolvimento, stakeholders, colegas de trabalho e até o chefe do Delivery Club.



Os colegas responsáveis ​​pelo lançamento preparam apresentações, falam sobre as conquistas do sprint e as dificuldades que foram superadas. Compartilhamos uma história de produto e ideias sobre como os novos recursos beneficiarão o usuário.



Este é um dia importante para toda a equipe!

Retro

Para nós, retro é uma forma de melhorar a eficiência. Em primeiro lugar, olhamos para as métricas de desempenho da equipe, o quão bem-sucedido fechamos o sprint. Verificamos a proporção de tarefas no status realizadas em relação àquelas realizadas no início da iteração e corrigimos esses dados por intervalo.



Por exemplo, em Produto pegamos 20 problemas e concluímos 17. Portanto, a taxa de sucesso para este balde é de 85%. Um bom progresso no desenvolvimento de produtos para nós é um indicador de 90% ou mais. Se for menor, discutimos na Retro como podemos melhorar essa métrica.

Trabalho de sprint

Frequentemente somos questionados sobre revisão de código e como funcionam os testes. Tudo é bastante normal aqui.



O dia começa com um stand-up. Por 15 minutos, a equipe discute o que fez ontem e o que fará hoje.



Usamos Jira Flow e Git Flow para trabalhar em tarefas, temos uma pilha Atlassian. Há também um quadro Scrum com colunas para fazer - em andamento - pronto para revisão de código - pronto para QA - pronto para a vida - pronto.



Quando o desenvolvedor prepara o código, ele faz um branch com o número do problema atual no Jira - este é um branch de recurso. Ele também o envia para uma solicitação pull no Bitbucket. O desenvolvedor precisa de pelo menos duas aprovações. Também temos integração com Jenkins, se a construção for verde, então você pode fundir. O líder técnico e o líder da equipe têm o direito de se fundir. Às vezes, você precisa preparar um teste de unidade para uma solicitação de pull. E às vezes não os escrevemos deliberadamente se sabemos que se trata de áreas de negócios não críticas, um domínio acrítico ou um recurso experimental, e podemos então eliminá-lo.



Quando tudo está perfeito, enviamos para teste. Um engenheiro de teste escreve autotestes ou executa casos de teste manualmente. Depende novamente de quão crítico é o domínio. E então implante.



Podemos dizer que esse processo funciona como um relógio. Mas de fato, neste momento existe uma comunicação constante dentro das equipes. O foco principal é o objetivo do sprint e a liberação no tempo. Para atingir o objetivo, podemos discutir as alterações do produto ou revisar a implementação técnica. Tudo isso acontece durante o trabalho em tarefas - é sempre um diálogo entre desenvolvedores, líder de equipe, gerente de produto e QA.

Diretrizes de desenvolvimento e estrutura do departamento de TI

No processo de transformação, chegamos a uma nova estrutura de direções de desenvolvimento. Como você se lembra, logo no início escrevemos cerca de quatro. Além disso, ficou claro que, para a implementação oportuna e de alta qualidade das metas, duas outras áreas precisam ser identificadas. Assim, agora existem 6 deles:

• O consumidor tem tudo a ver com produtos personalizados: sites e aplicativos móveis.
• Logística - sobre logísticos, correios e entrega.
• Vendor - sobre integração com nossos parceiros (restaurantes / lojas).
• Interno - central de atendimento e suporte.
• P&D - resolva tarefas intensivas em ciência.
• Plataforma - melhorando a arquitetura e a plataforma como um todo.

Cada direção tem sua própria gama de tarefas e suas próprias dificuldades.

Consumidor

A prioridade dessa direção é a felicidade do usuário. As principais métricas do produto estão aqui: retenção, taxa de conversão de pedido, NPS do consumidor. Do ponto de vista técnico, é importante para nós que todos os dados sejam enviados rapidamente. Nesse sentido, talvez, o maior highload, já que estamos trabalhando diretamente com o usuário final. E também há um grande número de microsserviços, a maioria deles aqui.



Os principais produtos são um site, incluindo uma versão mobile, além de aplicativos para iOS e Android. Os dois principais fluxos são entrega de alimentos e entrega de restaurante. Pilha tecnológica mais ou menos como em qualquer outro lugar: PHP, Go, Postgres, Redis e Memcache para cache, Kafka para comunicação assíncrona.

Logística

A tarefa dessa direção é garantir a entrega rápida de um pedido a um usuário faminto. Além disso, estamos desenvolvendo uma interface para despachantes que, se necessário, auxiliam os entregadores no controle manual.



Um dos principais desafios da logística surge quando aumenta o número de pedidos e, com isso, a carga no sistema. Para lidar com as cargas, você precisa fazer alterações de qualidade na arquitetura. Além disso, a entrega de comida é muito diferente da entrega, por exemplo, de material de escritório, roupas, livros e muito mais. Lá é tudo um pouco mais simples: fizemos um roteiro, planejamos e fomos.



Com a entrega de comida, esse número não funcionará. Estamos todos sob demanda, a situação muda a cada 5-15 minutos. Quando começa a chover ou nevar, a demanda sempre aumenta. E quando está ensolarado lá fora e você não quer ficar em casa, a demanda diminui. Nos feriados e finais de semana, o perfil da demanda difere dos dias de semana. A situação do trânsito e o congestionamento também fazem seus próprios ajustes, especialmente nas áreas onde prevalecem os entregadores de automóveis / motocicletas. Os horários da manhã, tarde e noite apresentam perfis de demanda distintos.



Essa migração de demanda é monitorada por nossos monitores. Se a demanda diminuiu, mudamos os resultados da pesquisa, damos ofertas mais relevantes na seção "Promoções". Para aumentar a relevância, incluímos modelos de ML que tornam a classificação personalizada tanto para o usuário quanto para a zona logística em que estamos observando uma mudança.



Um dos principais aplicativos que está sendo trabalhado na logística é o App Rider. É uma aplicação Android em que os transportadores veem onde retirar uma encomenda e onde deve ser entregue.

Fornecedor

Essa área trabalha com nossos parceiros internos: restaurantes e lojas. Ou melhor, com seus gerentes, que gerenciam o menu por meio de sua conta pessoal e reagem às estatísticas nos resultados da pesquisa.



Graças aos dados recolhidos e às estatísticas de encomendas, temos uma boa compreensão do público-alvo e das características dos restaurantes. Trabalhamos com eles em parceria e fornecemos uma ferramenta que os ajuda a entender melhor quem são seus clientes e viabilizar mecanismos de marketing. Também ajudamos os restaurantes a desenvolver modelos de otimização de preços, entender quais pratos são melhores para expor em que momento e em que sequência.



Outro produto que está sendo trabalhado na direção do Vendedor é um painel no qual caem os pedidos para a cozinha. A cozinha aceita a encomenda, vê a sua composição, determina como a prepara e, de facto, a prepara. Quando o pedido é preparado, a cozinha confirma no aplicativo e transfere o pedido para o courier. E então o mensageiro trabalha com o aplicativo Rider.

interno

Esta área é responsável pelas ferramentas do nosso call-center, que oferece suporte ao usuário. Na verdade, esta é a "área administrativa" para tudo relacionado a pedidos. A operadora pode ajudar o cliente, dar informações adicionais sobre o estado atual do pedido, fazer ajustes no pedido antes de enviá-lo ao restaurante.



O desafio dessa direção é fazer tal sistema, que seja, em primeiro lugar, conveniente e atenda todas as necessidades do operador e, em segundo lugar, rápido, pois o cliente precisa ser atendido o mais rápido possível. Além da tarefa fundamental, a galera da Interna está trabalhando para diminuir o tempo de processamento de um problema pela operadora e diminuir o número de ligações.

P&D

Quando você precisa mudar um processo de negócio e ao mesmo tempo entender como essas mudanças afetarão toda a plataforma como um todo, está envolvida a Pesquisa e Desenvolvimento. Os caras realizam experimentos, constroem modelos, contam e pesam. Eles também interagem mais intimamente com o departamento de BI, onde trabalham com big data, modelos de ML, redes neurais de design e previsão de demanda. Nesse sentido, o BI ajuda a P&D com pesquisas e ferramentas.



A pesquisa trata principalmente de trabalhar com dados. Por exemplo, como o sistema se comportará se você alterar algum fator. A maioria das tarefas de P&D agora vem da logística, já que essa área tem o maior nível de incerteza.

Plataforma

Esta é uma direção técnica. Em primeiro lugar, o objetivo é melhorar o núcleo do sistema, refatorando o processamento de pedidos e decompondo nosso monólito. Este não é um desenvolvimento de produto no sentido clássico, mas todas as melhorias são de uma forma ou de outra visando tornar mais conveniente e fácil para os usuários interagirem com o aplicativo Delivery Club: reduzir o tempo de resposta para que as páginas abram mais rápido, aumentar a capacidade da plataforma para que mais usuários possam fazer ordem e ao mesmo tempo a experiência de uso foi tão agradável quanto possível.

Resultados de transformação e novos desafios

Nossa tarefa era construir um processo de desenvolvimento que atendesse a todos os requisitos de uma empresa em crescimento: as equipes estão envolvidas no negócio, se comunicam muito, são responsáveis ​​pelos prazos que elas mesmas estabelecem e entendem como seu trabalho afeta o usuário final. O processo deve ser transparente, mensurável e, o mais importante, escalonável.



Após fazer uma transformação do produto e otimizar o processo de desenvolvimento, chegamos à conclusão de que cada um de nossos lançamentos se tornou previsível. A princípio sabíamos com uma precisão de 80% quando e em qual composição os lançamentos seriam lançados. Agora, o indicador de desempenho médio em todas as equipes do departamento cresceu para 90%. O envolvimento das equipes, ou seja, a motivação dos caras, aumentou muito, eles entendem o que estão fazendo e porque, para quem é importante.



O processo inclui a capacidade de responder às tarefas o mais rápido possível sem prejudicar o desenvolvimento do produto, há pontos de comunicação suficientes para estimar com flexibilidade os custos de mão de obra e responder em tempo hábil às mudanças nos requisitos do gerente de produto. Na prática, garantimos que o processo fosse escalonável: conseguimos passar de 40 pessoas para 170 com o mesmo processo de desenvolvimento e sem perder performance.



Ao mesmo tempo, não paramos e acreditamos que a transformação do produto ainda está em andamento. No final de 2019, começamos a pensar em como as equipes poderiam influenciar ainda mais os negócios. As equipes têm muito conhecimento do produto, parece que dá para usar, chegar a uma espécie de simbiose de Tecnologia e Negócios. Além disso, precisávamos criar um mecanismo para verificar as hipóteses do produto. Ou seja, controlar o valor das tarefas que fazem parte do nosso desenvolvimento. Para fazer isso, descrevemos o processo GIST - uma estrutura para verificar as hipóteses do produto, que discutiremos em um dos artigos a seguir.



Obrigado por ler!