Evoluindo ‘time’ de uma pessoa para vários squads independentes
Quando iniciamos o time de Produto (leia-se eu!), o grande objetivo inicial foi projetar e lançar uma nova versão do cliente web do Olist (app.olist.com) com prazo já definido. Além disso, toda a plataforma, que é o coração do sistema, seria reconstruída no modelo de micro serviços e disponibilizada via API para consumo do novo cliente web. Um grande desafio de responsabilidade compartilhada comigo e com o Osvaldo Santana (osantana), nosso CTO.
Nós entendemos que a equipe de produto é responsável por compreender claramente (e priorizar) quais problemas ou oportunidades queremos focar para descrever e guiar o que deve ser feito. Nesse período que trabalhamos em 2016 que vai do início da área (bem no comecinho do ano) até a entrega da API e novo cliente web, participamos de todo o processo de descoberta e construção do produto com o foco nas entregas de valor.
O meio de registrar e documentar o que deve ser feito é chamado de estória. As estórias são documentos técnicos que descrevem com detalhes o que precisa ser feito levando em consideração os pontos de vista da missão da empresa, do momento do negócio atual e das necessidades dos clientes para propor um novo desenvolvimento e mudanças em APIs e/ou telas, até, finalmente, convergir para o que significa a entrega daquela tarefa.
Como todo começo de uma empreitada desse tamanho, precisava ter clara nossa entrega mínima. Foi aqui que um quadro como esse ao lado tomou forma. Com ele, nosso objetivo poderia ser consultado a qualquer momento, por qualquer pessoa do time. É claro que, até a entrega dos novos produtos, fizemos algumas modificações para viabilizar o prazo.
Mesmo com a existência de uma agenda apertada, quase todos os meses, o time de desenvolvimento foi recebendo novos funcionários que aprendiam organicamente nossos objetivos, nossos processos e participando da construção desses novos produtos de software do Olist. Conforme a equipe de desenvolvedores crescia, nossos rituais de documentação, revisão e outras cerimônias que envolviam o time de produto foram se consolidando a partir de acertos, erros e feedbacks.
Durante esse período, o Jonatas Azzolini, nosso designer de produto, que participou até da aceleração do Olist na 500 (#500 STRONG) e que também desenhou todas as telas da primeira versão do cliente web teve um papel fundamental: ele nos ajudou no reconhecimento, aprendizado e documentação de correções de percurso a partir de feedbacks recebidos do cliente web antigo. O aprendizado dele foi levado em conta para que pudesse ser aplicado nas novas telas e casos de uso levantados. Gostamos tanto desse fluxo que hoje ele integra o time de produto e aprendemos juntos todos os dias. :)
Em algum momento desse processo, começou a ficar claro que era necessário pensar na modificação da nossa estrutura de time para atacar demandas em paralelo e planejar as entregas. Precisaríamos também de novos integrantes no time de produto. Isso ficava claro sempre que o número de desenvolvedores crescia: cada vez mais se tornava essencial separar e quebrar as atividades (para viabilizar a paralelização) e priorizar esforços de desenvolvimento mantendo o padrão de excelência das nossas estórias técnicas.
Chegou a um ponto onde já estávamos com as entregas da plataforma bastante avançadas. Decidimos fazer um teste e convidar alguns desenvolvedores para integrar um ‘squad’ meio beta meio ‘equipe de developers’ para desenvolver a integração com um de nossos parceiros de marketplace. No nosso planejamento já sonhávamos com a possibilidade real de implantar os famosos squads num futuro próximo. Até chegamos a usar um modelo de labels do JIRA para separar as demandas por ‘time’.
Aprendemos algumas coisas:
- Uma equipe sem objetivos de negócio não pode ser considerada como squad. Principalmente se ela não tiver certa independência para priorizar as demandas que tem internamente.
- Métricas claras para guiar nossa priorização, que vem dos OKRs da empresa, faziam muita falta.
- Todas as cerimônias e os rituais não deveriam continuar acontecendo juntos. O lado negativo disso foi o tempo elevado que começamos a investir em reuniões cada vez mais longas e cansativas.
Felizmente conseguimos entregar as demandas daquela equipe/squad. Nós ficamos satisfeitos com os resultados e, principalmente, aprendizados que tivemos. Essa experiência mais tarde serviria de grande inspiração para os nossos squads.
Lançamentos e planejamentos desses momentos são parte fundamental do trabalho aqui em produto: fizemos diversas reuniões com representantes de todas as equipes da start-up semana após semana, onde:
- Apresentamos entregas e priorização das estórias.
- Estudamos riscos antes, durante e após entrega das novas versões.
- Levantamos documentos, tutoriais e conteúdo necessário para treinamento dos nossos clientes.
- Organizamos evento de preview da nova plataforma.
Conseguimos aprender muito durante essas reuniões a partir da troca de preocupações e percepções de cada um dos convidados.
Foi uma iniciativa que rendeu bons frutos e ajudou a compartilhar nossas dificuldades e conquistas.
Apesar de toda a nossa preparação, erros e falhas aconteceram. A tela ao lado não é de uma situação real, mas tivemos diversas instabilidades durante e logo após o lançamentos. Foi gratificante ver como o time se ajudava para conseguir resolver as demandas mais urgentes e garantir que tudo estivesse up and running o mais rápido possível. Crescemos bastante com esse processo e amadurecemos nossos relacionamentos dentro do Olist.
Seguindo as melhores práticas, fizemos questão de nos reunir (algumas vezes) para ruminar os nossos aprendizados e erros de forma que não sejam cometidos novamente e sejam compartilhados.
Apesar das dificuldades, viramos essa página com a certeza que cada um da equipe fez o seu melhor e entregamos uma plataforma robusta, estável, alinhada com as dores e necessidades dos nossos clientes e preparada para os próximos anos de crescimento do nosso negócio.
No último mês de 2016, realizamos a primeira contratação do time. Uhulll! Foi o último desafio do ano. Encontramos um candidato que se destacou nas entrevistas e na apresentação que nos enviou como parte do processo seletivo (sério, ficou impressionante ;). O Igor Matsuchita seria o very first na empresa a experimentar um job rotation interno acelerado no primeiro mês dele. Seguindo alguns playbooks famosos para new hires de produto, ele recebeu o desafio de entender mais sobre o nosso produto de uso interno e seus clientes: o olist Admin.
A proposta era simples: o Igor tinha o desafio de percorrer todas as áreas que tínhamos (em dezembro/2016) conhecendo o papel de cada posição, vestindo os sapatos, e trabalhando um pouco como se fosse funcionário daquele time.
Com o time de vendas, fazer contatos com potenciais clientes, no time de CS participar do onboarding e acompanhamento dos clientes, no time financeiro entender exatamente como repasses são processados e assim se seguiu.
No final, ele conseguiu agrupar dores, oportunidades e principais tarefas realizadas por cada time, no modelo do value proposition canvas. O resultado seguiu conforme o quadro ao lado.
Em 2017 começamos nosso trabalho com boas novidades: aplicamos OKRs para planejar nossos primeiros squads para o primeiro trimestre. E começamos o ano com dois: um time focado no cadastro e publicação de produtos e um outro direcionado ao ciclo de pedidos e fulfillment. As metas ficaram bem definidas e alinhadas com a visão estratégica da empresa. Conseguimos atingir parcialmente as entregas planejadas. Também tivemos aprendizados importantes.
Tivemos sucesso na implantação desse primeiro modelo ‘beta’, e saímos com lições bem claras:
- A construção dos Key Results deveria contar com a participação do squad inteiro. Já fizemos isso no Q1, mas percebemos que um ritual focado na participação e co-criação facilitaria uma compreensão melhor da visão do negócio e dos Objectives.
- As estórias poderiam ganhar um framework de escrita que tornaria problema, solução e implementação mais destacadas e aprofundadas no documento.
- Nossos Objectives seriam propostos pelo C-Level como 100 % alcançáveis e pensados a partir da visão da companhia. Os Key Results propostos deveriam considerar métricas de entrega de valor, impacto e esforço.
- Não iríamos abrir mão da qualidade do código entregue. Mas podemos restringir os casos de usos atendidos para aqueles com maior impacto alinhado com os Objectives.
No segundo trimestre, já iniciamos o período com 5 squads bem definidos que puderam ser planejados com a antecedência de mais de um mês do seu início. Cada time participou ativamente da proposta dos Key Results que se comprometeriam a atingir a partir do Objective proposto. Nunca antes tivemos tanta participação de cada integrante dos times. O feedback foi sensacional. Todos conseguem hoje perceber mais claramente onde a sua participação contribui para o sucesso do negócio.
Hoje o time de produto possui no total 5 pessoas. Um crescimento marcado por desafios e aprendizados diariamente. Fizemos o movimento interno de um colaborador que se destacou na área dele e contratamos mais um engenheiro para integrar o time além do designer de produto.
Para os próximos meses temos alguns desafios bem claros. Continuar contratando e estabelecendo um time de excelência na entrega de novas funcionalidades e novos produtos. O aprendizado é king. Ele faz parte do nosso DNA no Olist e o time de produto não poderia ser diferente. Toda semana compartilhamos em apresentações curtas dentro do time.
Além disso não podemos perder nossa visão de longo prazo enquanto reconstruímos rituais e processos que vão sendo aperfeiçoados conforme amadurecemos em conjunto. Hoje todos que entram no time tem seu espaço bem definido e um plano de treinamento e desenvolvimento acompanhado de perto por mim.
Você leu até aqui e ficou com um gostinho de conhecer mais sobre nosso time, modelo de gestão de produto e o que fazemos? Fico a disposição para ajudar. Espero seu contato.
Caso queira enviar seu currículo pra gente. Fica meu convite para participar do time: clique aqui!
