Blog de Marketing Digital de Resultados

Como estruturar o crescimento de um time de desenvolvedores [Palestra de Bruno Ghisi no RD Summit 2015]

Assista à palestra de Bruno Ghisi no RD Summit 2015 e saiba como você pode estruturar uma equipe de produto de forma escalável e focada em resultados

Oferecer um bom produto no mercado é o objetivo de qualquer empresa que queira crescer e gerar resultados – tanto para si mesma quanto para seus clientes.

E, para chegar a um produto de qualidade, que seja referência em sua área de atuação, há muito por trás: uma infraestrutura consistente, atender às dores dos clientes e, é claro, um time competente capaz de desenvolvê-lo.

Mas, então, como encontrar as pessoas certas para integrarem essa equipe, como fazê-la trabalhar de forma produtiva, focada em resultados e com processos escaláveis?

Para responder a essas perguntas, Bruno Ghisi, cofundador e CTO da Resultados Digitais, palestrou no RD Summit 2015, nosso evento de Marketing Digital e Vendas que acontece anualmente.

Assista abaixo ao vídeo da apresentação:

Esse post foi baseado na própria palestra de Bruno Ghisi.

Hoje vamos contar a história de como escalamos a RD sob o ângulo do time de produto. Esperamos trazer insights para empresas que estão em alguma das fases que falaremos a seguir ou alguma boa prática para outras que já passaram por isso. Também vamos compartilhar com nosso clientes um pouco da nossa história, para que conheçam mais sobre a RD.

Em outubro de 2015, a Resultados Digitais tinha mais de 3 mil clientes e continuava crescendo em um ritmo acelerado, com 230 RDoers. Em dezembro, fechamos o ano com 270 pessoas. E destas 230 pessoas, 58 eram da área de produto, de um dos 7 times de desenvolvimento que a empresa tinha na época.

Essa equipe fazia, em média, 1 commit a cada 5 minutos – ou seja, a cada 5 minutos havia uma pequena mudança no RD Station. Isso gerava em torno de 12 pull requests por dia, o que significa que 12 melhorias de funcionalidade, correção de bugs, ajustes e novas features entravam no RD Station diariamente.

Além disso, também trabalhávamos – e continuamos trabalhando! – com um volume de dados grande, e o RD Station tem cada vez mais integrado tudo isso para trazer informação.

Na época, disparávamos algo em torno de 120 milhões de emails por mês. Desses emails, eram gerados eventos de email (abriu, clicou etc.) que, em 2015, somavam 2 bilhões. Além disso, em 2015 tínhamos uma base de dados com mais de 2 terabytes.

Mas nada disso poderia ser alcançado se não houvesse uma equipe por trás. Uma equipe que cresceu muito desde que começamos. Para se ter uma ideia, abaixo temos a nossa curva de colaboradores ao longo do tempo.

Como se pode ver no gráfico, demoramos até tracionar. A grande virada só aconteceu no terceiro ano dos quase 5 de estrada que tínhamos em 2015. Em 2014 e 2015 crescemos bastante, sendo que, neste último, o número de pessoas na empresa duplicou.

Com isso, acumulamos diversos aprendizados, que vamos contar agora, ano a ano.

2011

Em 2011, constituímos nosso primeiro escritório. Nessa época a equipe era formada apenas pelos fundadores. O RD Station, por si só, tem uma complexidade de gestão de produto, é como se tivéssemos vários produtos em um só, o que tornava mais complexo o seu desenvolvimento. Competimos em cada vertical – por exemplo, Email Marketing – e ao mesmo tempo temos que ter um produto integrado para competir em Inbound Marketing também.

Por isso, enquanto não finalizávamos o produto, o foco era prover valor para os clientes enquanto desenvolvíamos o produto que iríamos escalar. Para isso, precisávamos sair do nada e criar algo vendável. Assim, o grande valor que acabamos gerando foi vender consultoria. Fechamos o ano com 7 clientes, entre eles Beefpoint e Soap.

Ninguém conhecia o produto ainda, mas estávamos o desenvolvendo em paralelo.

Mechanical Turk

Mechanical Turk é uma tarefa realizada de forma manual; é uma forma de testar uma solução antes de implementá-la. Nessa época, fazíamos muita coisa manual, tínhamos que provar o valor, mas não tínhamos software. Se um cliente pedia um blog ou uma Landing Page, tínhamos que fazer “na mão”. Era a visão do que o produto iria fazer, mas nós fazíamos manualmente, para ver se iria funcionar.

Uma curiosidade: nossa primeira feature foi esta:

Era um relatório diário criado com dados do Analytics, mas sem a grande quantidade de informações que temos hoje.

Tudo na cloud

Nossa empresa é totalmente na nuvem. Nosso foco é fazer software de Marketing Digital e Vendas. Somos bons nisso, fazemos isso bem.

Assim, como tínhamos – e ainda temos – que andar rápido, e era muito custoso e menos efetivo fazer tudo dentro de casa, terceirizamos algumas features. Hoje, trabalhamos com Heroku, Amazon, Sendgrid, Good Data, entre outros, como features de apoio.

Metodologia XP

XP (Extreme Programming) é uma metodologia ágil de desenvolvimento na qual, desde o início, nos baseamos. Ela possui 3 conceitos interessantes: TDD (test-driven development), Pair Programming (programação em dupla) e Integração Contínua (toda a vez que você muda um código, rodam todos os testes).

Consideramos muito estratégica a parte de testes: fazemos muito TDD – naquela época, o RD Station possuía cerca de 120 mil linhas de código e 95% dessas linhas possuíam teste automatizado.

Isso para nós é muito importante, pois a visão do produto, o modelo de dados e outros aspectos evoluem. Então “testes amarrados” permitem que a gente saiba quando a gente errou propositadamente para arrumar, ou quando erramos sem querer – e aí arrumamos também para não causar problemas.

Consideramos isso tudo muito estratégico para permitir o crescimento, tracionando e escalando de uma forma que evita muitos problemas no futuro.

2012

Em 2012, mudamos de escritório. Agora, tínhamos 5 devs e muito mais espaço. Tínhamos como foco desenvolver o produto para começar a virar a chave, vendendo mais produto e menos consultoria. Afinal de contas, o produto iria automatizar e trazer o valor que estávamos oferecendo na consultoria.

Finalmente, no final daquele ano, viramos a chave, e lançamos publicamente o RD Station.

Nesta época, nossa base de Leads era muito pequena (acabamos o ano com 70-80 clientes), e muitos dos nossos primeiros clientes “sofreram” com a plataforma. Mas nosso compromisso era investir para deixar a usabilidade cada vez melhor.

Abaixo um exemplo da nossa feature de Email Marketing: eram 6 passos e 4 templates. No menu, tudo dizia “em breve”.

A partir daí, começamos a estruturar uma dinâmica, além de todo o list com XP. Começamos a usar o Scrum Master, ter planejamento semanal, papéis de SM e PO. Até hoje, fazemos um evento mensal para apresentar os resultados de todos para toda a equipe macro. Os lançamentos eram rápidos e constantes. Quando se é pequeno e com poucos clientes, não há grandes barreiras, então deve-se aproveitar isso. E deve-se também ser lean, ou seja, buscar melhoria contínua.

Estruture um suporte

Falando do nosso suporte, no início era apenas um email; depois, virou o Zendesk. Além disso, o foco passou a ser cada vez mais Customer First. Todos os devs falam com o cliente, eles devem sair do isolamento.

Monitore a operação

Nesse ponto, precisávamos monitorar nosso crescimento e constantemente aprimorar a performance e a arquitetura, para não travarmos nossa operação.

2013

Como mostramos no gráfico “Número de RDoers x Tempo”, os últimos dois anos (2014 e 2015) foram de muito crescimento para a RD – não à toa, a empresa duplicou.

Mas foi em 2013 que começamos a arrumar os processos para esse crescimento ocorrer – na época, tínhamos 10 devs. Foi nesse ponto que recebemos nosso primeiro aporte de investimento.

Escale o produto

Aqui, começamos a enfrentar um dilema: nós da área de dev não éramos tão grandes ainda para sermos dois times e nem tão pequenos para sermos um. Mas era hora de fazer a primeira quebra. Já tínhamos dois SM, mas, mesmo assim ,eu ainda participava das reuniões.

Com essa divisão, tínhamos uma primeira coisa a fazer: dar poder às pessoas. Elas precisavam ter esse poder para que pudéssemos descentralizar as decisões. Para isso, precisávamos contextualizar, explicar problemas KPIs etc.: assim, elas tomariam as melhores decisões a partir dessas informações.

Além disso, precisou-se estabelecer processos: sem processos, as pessoas estão muito mais suscetíveis a cometerem erros. E o segredo para criar esses processos é ter um setup inical para coisas recorrentes e visão de melhoria contínua.

2014

Evolua o produto

Em 2014, chegamos aos 20 devs. Era hora de evoluir o produto. Como um de nosso valores é ser data driven, precisávamos tomar decisões baseadas nisso: o que fazer, o que acompanhar etc.

Assim, criamos um Kanban de produto com uma série de fases para lidar com os processos e muitos dados que tínhamos.

Comunicação e Cultura

A empresa crescia e continua crescendo, e é sempre muito importante manter a comunicação clara, desde os altos executivos aos desenvolvedores que vão executar as ações. Para evitar problemas com isso, reforçamos a importância dessa comunicação constantemente em nosso culture code.

Você vai parar de programar – mas não no final de semana

Essa é uma dica para os CTOs. Eventualmente, vocè precisará parar de programar para fazer crescer a empresa – afinal, você tomará as funções mais gerenciais e estratégicas.

Mas quando dizemos que você não vai parar aos finais de semana, significa que o papel de CTO é se manter atualizado, e vez ou outra você terá que “colocar a mão na massa”.

Desenvolva lideranças

No início, pensávamos muito no SM como líder técnico. Hoje, achamos que ele tem um papel fundamental em desenvolver as pessoas. Se ele impactar em 10% de cada um, já aumentamos a entrega, e tornamos algo escalável.

Assim, dividimos as lideranças em duas frentes: líderes de time (desenvolvimento e estratégia) e líderes técnicos (horizontais). Nesse contexto, coaching e programas de liderança são processos muito úteis.

Recrutamento

Como dissemos antes, você eventualmente vai parar de programar. Mas o grande objetivo de parar de programar é porque é importante focar em outras coisas, como recrutamento. É claro que o RH vai ajudar você neste processo, mas a estratégia de recrutamento precisa vir da área técnica para gerar contratações assertivas.

Além disso, é preciso utilizar as técnicas de Inbound Marketing para contratação de devs, tanto para atração (ser referência, e por isso atrair bons talentos) como para retenção (reter os colaboradores pelo fato de trabalharem em uma boa empresa).

Também é preciso gerar engajamento com os colaboradores: nós, por exemplo, temos o blog de desenvolvimento, o Ship It!, no qual todos escrevem, e no qual publicamos 2 vezes por semana.

2015

Em 2015, a RD recebeu novo aporte; o foco continuou sendo em evoluir o produto. Assim, como a RD é um produto complexo, com várias features em uma, os times de desenvolvimento foram se especializando por áreas de produto, para chegarem a um próximo nível. Agora, são os times que controlam os KPIs; eles não respondem apenas pela execução, e sim por entregas com sucesso.

Aprenda a fazer lançamentos

Mais do que fazer entregas, é importante aprender a fazer o lançamento das novidades do seu produto, tanto externa quanto internamente. Afinal de contas, só criar features não serve para nada. Não adianta o time de desenvolvimento “cuspir” features. O que precisamos é “cuspir” melhorias em números de negócios. Por isso, alinhar o lançamento para impactar clientes e vendas é importante.

Melhore a qualidade

À medida que sua empresa cresce, um pequeno problema já não é apenas um pequeno problema: ele tem um enorme impacto na sua base. Para se ter uma ideia, fazemos hoje em torno de 15 mudanças diárias. Porque mesmo que um erro afete apenas 2% dos PR, se ocorrer um incidente por semana, quantos clientes isso pode afetar?

Por isso, temos que melhorar a qualidade quando especificamos a história, durante e quando lançamos, de forma controlada. Qualidade não é apenas testar.

Seja mais que uma família

Gostamos de pensar na RD que somos uma família, mas na verdade somos mais do que isso: somos um time de esporte PRO, atletas de elite prontos para ganhar o campeonato.

Assim, mais do que sermos um suporte para o desenvolvimento dos colaboradores, É preciso estimular as pessoas a chegarem à sua melhor performance, e acompanhar o desempenho de cada um, de cada time, entender o histórico etc.

Treinamento e Onboarding

Nesta etapa, é preciso evoluir nos treinamentos e nas contratações: é melhor contratar novos talentos com sangue no olho do que gente experiente apática. Por isso, é necessário treinamento e playbook claro do que fazer. Durante a entrada dos contratados, também é importante um processo de onboarding, para a evolução dos novos colaboradores.

Minha grande lição para continuarmos o crescimento

Por fim, chegamos a uma grande lição para estruturar o crescimento do time de desenvolvimento: Estude, converse e pense full time em como escalar.

 

Se você quer saber mais estratégias para montar o seu time de produto, leia também Generalistas ou especialistas em seu time de produto? e Time de Produto no suporte técnico: estratégias e resultados.

E se você não quer perder o RD Summit 2016, acesse agora o site do evento e garanta sua inscrição.

Veja como foi em 2015:

Marcadores:

Deixe seu comentário