Montando uma equipe de dados em uma startup

• Relato de alguém que entrou para ajudar a estruturar uma pequena equipe de dados, de cerca de 4 pessoas, em uma startup Mid-Stage com faturamento anual na casa de 10 bilhões de won

• É um texto metafórico baseado em algumas experiências e pode ser tendencioso*, então leve isso em consideração ao ler

1º de julho: manhã

• Primeiro dia de trabalho como líder da equipe de dados

• Apresentação ao CMO

(O CMO está muito empolgado com a minha chegada e comenta que a empresa de um amigo dele faz segmentação de clientes com IA e isso parece incrível)

(Depois de uma conversa rápida, investigo as práticas de dados da equipe de marketing)

DATA: "Como está o custo de aquisição de clientes (CAC)?"

CMO: "Hum... na verdade está ótimo. Nosso cientista de dados mediu os números e o custo por clique está caindo cada vez mais"

DATA: (Ouvi dizer que todos os cientistas de dados se reportam à equipe de dados, então existe um cientista de dados em outra área?)

CMO: "O problema real é que a equipe de Growth não consegue converter todo o tráfego que trazemos para o site"

DATA: "Existe algum dashboard para ver o funil de conversão?"

CMO: "Converter leads é trabalho da equipe de Growth."

• Conversa com um dos Product Managers

O PM que redesenhou completamente a página inicial estava empolgado porque o número de cadastros de usuários aumentou 14%

DATA: "Essa diferença é estatisticamente significativa?"

PM: "Isso não é meu trabalho, é trabalho da sua equipe"

PM: "Quando perguntamos isso antes, a equipe de dados disse que não tinha os dados e que levaria meses para obtê-los"

PM: "O mais incrível é que não fizemos essa mudança de forma incremental. Decidimos não fazer teste A/B para essa alteração. Às vezes é preciso fazer uma grande aposta para sair de um extremo (Local Maxima)."

PM: "Steve Jobs não fez teste A/B quando lançou o iPhone. Nossa equipe colocou isso no ar faltando 2 dias para o prazo, e isso é o que importa!"

DATA: (Rabisco algo no caderno fingindo que estou ocupado)

• Conversa com os novos membros da equipe

→ A equipe tem 3 pessoas, mas recebeu orçamento para crescer até 10 até o fim do ano

→ Parece que o time ficou animado com a minha chegada

→ Eles me mostram o que já construíram. Há bastante coisa, e parte disso é legal

✓ Rede neural para previsão de churn de usuários

✓ Notebook com implementação de sistema de recomendação de produtos relacionados

→ Muito código começa com uma etapa de pré-processamento extremamente complexa, que precisa buscar dados de vários sistemas

✓ Parece haver vários scripts que precisam ser executados manualmente, na ordem correta, para realizar parte desse trabalho

→ Quando pergunto por que isso não foi colocado em produção

✓ Dizem que os engenheiros falaram que transformar isso em algo em nível de produção seria um projeto muito grande

✓ O Product Manager colocou isso no backlog, mas continua sendo adiado porque outras demandas sempre aparecem

✓ Dizem que é preciso apoio da liderança para isso

1º de julho: tarde

• Conversa com o Head of Supply Chain (ele não parece tão empolgado quanto o CMO)

"Sinceramente, não sei se precisamos da ajuda da equipe de dados"

"Não temos esse tipo de problema. O que precisamos é de analistas de negócio"

"Tenho uma equipe inteira, e eles passam horas todos os dias trabalhando em modelos muito complexos"

"Eles nem têm tempo para responder às perguntas básicas que eu tenho."

"Tenho uma planilha cheia de perguntas para as quais quero respostas"

(Ao olhar a planilha, havia coisas como)

"Comparar a taxa de conversão entre clientes cujo ticket foi aberto e resolvido em até 1 hora e clientes resolvidos depois de 1 hora, segmentando em intervalos de valor de pedido de US$ 100"

(Quando pergunto sobre os modelos)

• Parece que é preciso copiar para a aba certa, no formato correto, em uma planilha do Google composta por inúmeros VLOOKUPs

• Os dados são atualizados diariamente, e as prioridades do time naquele dia são definidas com base na saída do modelo

• Os pagamentos a fornecedores também estão sendo calculados em planilhas

(Vou para casa e sirvo um copo cheio de uísque...)

[ O que aconteceu aqui? ]

• Isso é basicamente uma descrição (um tanto cínica) do que acontece em muitas empresas no início da sua fase de maturidade de dados

• Falta de dados e dados fragmentados

→ Muitas vezes os dados simplesmente não existem desde o início porque o produto não foi devidamente instrumentado

→ Fragmentação do sistema de dados, com dados espalhados por vários sistemas

→ Processos de negócio frágeis, tocados de forma data-driven, mas com pouca ou nenhuma automação

• Expectativas pouco claras sobre qual é o trabalho da equipe de dados

→ Cientistas de dados contratados para fazer P&D e implantar IA, resultando em ausência de objetivos de negócio claros

→ A equipe de dados reclama que é difícil colocar ML em produção, mas a equipe de produto na verdade não liga muito para essas funcionalidades

→ Pessoas que precisam de um "tradutor de English-to-SQL"

• Equipe de produto sem treinamento data-driven

→ Product managers não enxergam dados como uma ferramenta para construir funcionalidades melhores

→ Falta alinhamento entre o que a equipe de produto quer construir e o que a equipe de dados tem

• Uma cultura fundamentalmente em conflito com uma cultura centrada em dados

→ Cultura que celebra colocar coisas no ar (Shipping), e não progresso e aprendizado mensuráveis

→ Mesmo as equipes que de fato usam métricas o fazem de forma inconsistente, com medições inadequadas e, em alguns casos, em conflito com outras equipes

• Ausência de liderança de dados

→ Organização de dados fragmentada, com diferentes profissionais de dados se reportando a várias áreas diferentes

→ Outras áreas, sem receber a ajuda de que precisam, acabam contratando vários analistas em torno da equipe de dados

→ Falta de padronização de toolchain e boas práticas

(Uau, isso é deprimente. O que seria preciso fazer para resolver esse problema?)

8 de julho

• A partir da semana seguinte, começo a definir uma nova direção para a equipe de dados

• Como uma pessoa parece ter experiência com infraestrutura, peço que ela construa um data warehouse centralizado

• Por enquanto, só precisamos do caminho mais rápido para reunir os dados em um só lugar

• O plano é basicamente fazer dump do banco de dados de produção no data warehouse a cada hora

• Também seria possível enviar logs massivos de eventos do framework usado no frontend para tracking de anúncios, mas isso fica registrado como dívida técnica

• Junto com a equipe de recrutamento, defino um cargo generalista de dados

→ Ênfase em fundamentos sólidos de software, mas com postura generalista (faz de tudo) e capacidade de ter profunda empatia pelas necessidades do negócio

→ Por enquanto, removo qualquer menção a inteligência artificial e machine learning

• Passo um tempo com outros profissionais de dados que não se reportam à equipe de dados

→ O cientista de dados da equipe de marketing era jovem. "Sempre quis ser cientista de dados. Quero aprender muito com você"

• Pergunto a um amigo que opera um coding bootcamp se ele conhece algum bom "curso de treinamento em SQL", e como ele conhece, decidimos adotá-lo no fim deste mês

• Preparo uma apresentação para a equipe de produto explicando o que é teste A/B e como ele funciona

→ Mostrando muitos exemplos de testes com resultados inesperados,

→ e montando de forma interativa para que eles possam tentar adivinhar o que venceu

• Encontrar a secretária do CEO e descobrir “quais métricas ele gostaria de receber em relatórios por meio de e-mails enviados automaticamente toda semana”

• Conversando com os analistas de negócios da equipe de Supply Chain, ficou claro que eram pessoas razoáveis, mas que haviam se machucado em interações anteriores com a equipe de dados

• Um deles já tinha usado SQL no passado. Ao ver que ele fazia perguntas sobre taxa de conversão, demos a ele acesso ao data warehouse

• Marcar reuniões 1:1 semanais com pessoas de toda a organização que precisam de dados

→ O ponto principal é encontrar lacunas de dados (gap) e oportunidades e encaminhá-las aos cientistas de dados

→ Os cientistas de dados podem ficar frustrados, já que suas prioridades de pesquisa acabam sendo empurradas para depois

→ Dizemos “vamos focar em entregar valor de negócio o mais rápido possível”, mas também “talvez em breve possamos voltar a trabalhos relacionados a machine learning. Vamos ver primeiro”

1º de setembro: manhã

• Três meses se passaram, e agora dá a sensação de que as coisas estão começando a andar

• Em reuniões 1:1 semanais com várias partes interessadas, continuamos encontrando pontos cegos e oportunidades em que os dados podem gerar mudanças

• Usar o que foi encontrado para forçar avanços no trabalho central de plataforma

• Para criar conjuntos de dados “derivados”, é preciso construir muitos pipelines. O custo inicial é alto, mas depois que o dataset certo está pronto, as análises seguintes ficam muito mais fáceis

• Começar a abrir o acesso ao data warehouse para outros departamentos

• Eles começam a usar SQL diretamente para fazer análises básicas

→ Um caso excelente: uma product manager júnior descobriu que a taxa de conversão no iOS Safari estava horrível. Era um bug de front-end relacionado a local storage, corrigido com uma única linha

• O responsável por Supply Chain envia um e-mail irritado

→ Uma mudança no banco de dados fez uma query de 500 linhas falhar...

→ Passamos a correção para um cientista de dados resmungando e oferecemos outra cenoura: “No fim deste mês eu encontro um problema de machine learning legal para você”

1º de setembro: tarde

• O product manager da equipe de checkout ainda não está fazendo análise de métricas

• Um cientista de dados da equipe de marketing conversa com o gestor e passa a se reportar diretamente a mim

[ O que está acontecendo? ]

• Estamos montando a base do que é mais urgente

→ Tornar os dados importantes consultáveis em um só lugar

→ Abrir o acesso via SQL e fazer com que outras equipes usem isso, eliminando muito trabalho de “tradução para SQL”

• Por outro lado, outras equipes podem querer ir mais longe com essa liberdade. Dá para impedir isso definindo permissões de acesso aos dados, mas as desvantagens são maiores

• A equipe de checkout não fazia análise de dados porque não sabia a quem perguntar

• Isso é principalmente um problema organizacional

→ As equipes não sabem como colaborar com a equipe de dados

→ Elas não percebem, mas a equipe de dados também pode ser um gargalo

• O mais sensato é “centralizar a liderança e descentralizar a gestão do trabalho”

→ Porque isso cria um ciclo de feedback mais próximo entre dados e decisões

→ Permitindo que membros da equipe de dados colaborem com cada equipe e se reportem apenas a mim (líder da equipe de dados)

2 de setembro

• A equipe de dados cresce para 6 pessoas

→ 1 pessoa em infraestrutura de data warehouse

→ 5 pessoas alocadas a equipes específicas: onboarding, Supply Chain, checkout, marketing e suporte ao CEO / preparação de materiais de apresentação para investidores e conselho

• Explicar a mudança para toda a empresa e deixar claro com quem cada um deve trabalhar em demandas de dados

• Mesmo nas próximas contratações de dados, o plano é alocar as pessoas em outras equipes

3 de janeiro

• Um dos cientistas de dados decide sair. Como também não havia muito trabalho que o deixasse feliz, decidimos não tentar segurá-lo

• Há muitas pessoas novas na equipe. Gente com algum conhecimento de engenharia de software, SQL e vontade de encontrar coisas interessantes nos dados

→ Como são pessoas que buscam “furos” nos dados, penso nelas como “jornalistas de dados”

• No caso do membro que trabalha com a equipe de onboarding

→ Ele descobriu que o fluxo de onboarding pedia o endereço do cliente mesmo quando isso não era necessário

→ Remover isso aumentou a taxa de conversão em 21% em um teste A/B

→ Não foi simples, porque era necessário um trabalho de ETL para facilitar a consulta dos dados, mas um pouco de Python ajudou a tornar isso possível

• Reunião trimestral com o CEO

→ O PM da iniciativa de crescimento apresenta o redesign recém-lançado da landing page

→ O PM enfatiza que 20 engenheiros estão fazendo hora extra para cumprir o prazo

→ O CMO também está profundamente envolvido, porque apostou alto em Direct Mail como parte desse redesign

→ Pergunta do CEO: “Como estão as métricas agora? O custo de aquisição de clientes caiu?”

→ (você já esperava que o CEO fizesse esse tipo de pergunta, e sorri quando ela finalmente aparece)

→ O PM mostra os números do apêndice, porque de fato foi feito um teste A/B

→ Algumas métricas subiram, outras caíram, então não há um resultado significativo; o número de custo de aquisição de clientes não parece bom

→ O CMO enfatiza que os números ainda estão sendo construídos e que campanhas assim podem levar alguns meses

[ O que está acontecendo? ]

• A boa notícia é que a equipe de produto começou a fazer testes A/B

• A má notícia é que os resultados são ignorados e os projetos seguem, em grande parte, para atender milestones e deadlines artificiais

• A melhor notícia é que o CEO está pressionando as equipes para que os dados sejam usados como verdade (truth)

• À medida que a organização passa a sofrer mais pressão para se tornar data-driven, a equipe de dados precisa acelerar a forma como colabora com as outras equipes

• Em especial, a alta liderança vai se concentrar cada vez mais em métricas, e é seu trabalho fazer com que a equipe de dados trabalhe sobre essas métricas

• Uma das formas mais simples é garantir que cada equipe tenha dashboards para as métricas que considera importantes

1º de abril

• Os antigos trabalhos de machine learning feitos pela equipe de dados ainda existem

• O cientista de dados que trabalha com a equipe de produto de inventário se interessa por trabalhos anteriores ligados ao sistema de recomendação

• Um dos novos contratados é um generalista, então ele transformou o notebook do sistema de recomendação em um pequeno app Flask e o implantou internamente

• O product manager da equipe de inventário vê isso e gosta: “Como colocamos isso em produção?”

• Uma das principais métricas da equipe de inventário é “valor médio do pedido”, e parece que essa recomendação pode melhorar bastante isso

• Mesmo por uma estimativa rápida, parece difícil fazer um rollout grande, mas surge a ideia: “E se implantarmos isso para apenas 1% dos clientes?”

• “É meio tosco, mas dá para pré-gerar os produtos recomendados com um Cron Job, e acho que dá para fazer em poucos dias”

• Trabalhando com a equipe de Supply Chain, encontramos mais queries SQL gigantes

• Elas continuam quebrando, mas a equipe de dados está convertendo isso em pipelines adequados

• O chefe da equipe de Supply Chain pede a contratação de mais cientistas de dados

[ OK, o que está acontecendo afinal? ]

• Primeiro, surgiu esperança de fazer trabalhos legais de machine learning

• A equipe de produto finalmente está animada para lançar o sistema de recomendação em um teste pequeno

• Antes, isso não era possível porque a equipe de engenharia de produto achava difícil prever esse tipo de trabalho, não queria contribuir diretamente, e a equipe de dados não tinha as habilidades para colocar isso em produção

• O que resolveu esse problema foi a equipe de dados ter realmente construído uma demo. Isso não só aproxima da produção, como também deixa as possibilidades muito mais claras

• Outra coisa é o que está acontecendo na equipe de Supply Chain

→ Ela começou com seus próprios “analistas de negócios”, mas para obter dados precisava que a equipe de dados executasse as queries

→ Com ajuda da equipe de dados, os analistas passaram a executar queries por conta própria

→ Primeiro, começou eliminando a "dívida técnica sombra" (queries SQL monstruosamente grandes) que vinha gerando atrito com a equipe de dados

→ A equipe de dados passou a atuar junto da equipe de cadeia de suprimentos para ajudar

→ Com membros da equipe de dados embedded nas áreas, a necessidade de analistas de negócios diminuiu e o número de cientistas de dados aumentou

• Lembre-se de que, no começo, ao começar a despejar diretamente o banco de dados de produção no data warehouse, você assumiu uma "dívida técnica"

• No início, muitas coisas quebram, mas é preciso adicionar uma camada que permita consultas estáveis. Isso pode dar um trabalhão

1º de julho

• Reunião de planejamento do 3º trimestre

→ Antes, discutia-se em que a empresa apostaria no trimestre seguinte

→ Desta vez, você apresenta as métricas de mais alto nível da empresa, e cada equipe apresenta o detalhamento dessas métricas por meio de submétricas

• O trabalho da equipe de gestão de produto deu resultado

→ O PM justifica o investimento no projeto falando sobre o que aprendeu ao rodar os testes e o que encontrou nos dados

• Um grande resultado foi que a cientista de dados que trabalhava com a equipe de checkout descobriu que, quando o usuário apertava o botão de voltar na página de confirmação, o objeto do carrinho ficava em um estado estranho

→ Ao corrigir esse problema, a taxa de conversão subiu bastante

• Outro insight foi que os tráfegos vindos de diferentes campanhas de anúncios tinham perfis de conversão muito distintos

→ Algumas campanhas tinham custo por clique baixo, mas conversão péssima; outras eram caras, mas tinham conversão muito alta

• Ao rastrear variáveis UTM e conectá-las à criação de contas, passou a ser possível medir a conversão do clique no anúncio até a compra

→ Isso era impossível antes de trazer todos os dados para o mesmo data warehouse e normalizá-los para que fossem facilmente consultáveis

→ Em colaboração com marketing, o principal KPI passou a ser o custo de aquisição de clientes end-to-end, e não o custo por clique

• Outra notícia divertida foi que o teste de 1% do sistema de recomendação teve um sucesso fora do comum

→ Expandir isso para 100% dos usuários é um projeto muito grande, mas o CEO aprovou o projeto

• Nem todos os resultados foram positivos, e muitos testes falharam.

→ Um dos slides explicava um teste em que o frete não era cobrado separadamente, mas incluído no preço

→ O CEO disse: "O que aprendemos aqui?"

→ Isso levou novamente a uma conversa para planejar uma série de experimentos de acompanhamento

(Você vai para casa e estoura o champanhe)

[ O que aconteceu? ]

• Você conseguiu.

• Você transformou a organização em uma verdadeira nativa em dados.

• A equipe de dados trabalha de forma multifuncional com várias partes interessadas.

• Dados e insights são usados no planejamento, e os dados são usados para gerar valor de negócio, não para pesquisas sem objetivos claros.

• A empresa usa ciclos rápidos de feedback orientado por dados para trabalhar de forma iterativa, em vez de um planejamento em grande escala no estilo "waterfall".

• As métricas são definidas de uma forma que permita gerar valor de negócio e assumir responsabilidade por isso.

• A cultura de dados é impulsionada em conjunto de cima (pelo CEO) e de baixo (pelos funcionários).

• Se pelo menos algo foi aprendido, tudo bem falhar.

(Parabéns. Você merece erguer uma taça de champanhe)

[hangnim]

Enquanto lia a parte inicial, achei que fosse a minha empresa,,,, T_T (claro que na nossa nem time de dados existe rs)

[dajoa]

Foi muito divertido de ler. Obrigado~!

[shawn]

Parece um episódio de algum drama sobre startup de tecnologia que engenheiros adorariam assistir. Muito divertido! 👍

[hangnim]

22222

[laeyoung]

Parece ter bastante gente, então esse é o nível de uma empresa em estágio intermediário.

[xguru]

Provavelmente a escala analisada é um pouco diferente da do mercado coreano.

[xguru]

Quanto a opinionated (tendencioso), e9 difedcil traduzir isso de forma precisa, mas eu costumo usar "tendencioso" no sentido de "reflete a prf3pria opinie3o e, por isso, e9 tendencioso".

He1 um texto escrito por outra pessoa sobre isso, ente3o vale consultar:

• O significado de opinionated (tendencioso) como termo de computae7e3o https://www.clien.net/service/board/cm_app/13558026

E o texto original estava escrito de forma mais descritiva, mas eu o reestruturei em um tom mais conversacional para facilitar a leitura.