Yammer: A estrutura tradicional de empresas de desenvolvimento está morta

Kris Gale, Vice President of Engineering na Yammer, afirma que equipes pequenas são a chave para o desenvolvimento rápido de produtos em empresas maiores. Ele explora as nuances da construção de organizações no desenvolvimento de produtos e explica como tomar decisões conscientes durante uma fase de crescimento pode garantir que as coisas que tornam uma startup única e especial não se percam. No final das contas, é tarefa de um diretor técnico pensar em como organizar e otimizar o desenvolvimento de software.

Equipes menores entregam mais rápido

Inicialmente, a equipe da Yammer seguiu uma abordagem bastante simples. O foco principal era o produto em si, sem se preocupar muito com a estrutura de pessoal durante o crescimento da organização. À medida que a empresa crescia, no entanto, perceberam que o aumento marginal de produtividade com cada novo desenvolvedor diminuía devido ao maior esforço de coordenação.

Ao mesmo tempo, o resto do mundo percebeu que a Yammer estava criando algo grande. Por toda parte, startups tentavam copiar o produto, e até grandes empresas lançavam produtos concorrentes. Na Yammer, sabiam que só poderia haver uma empresa dominante no mercado, e que seria outra se não fossem ágeis o suficiente. Aplicações web modernas precisam ser ágeis e adaptáveis.

Para entregar mais rápido, a Yammer adotou a abordagem de trabalhar com equipes pequenas. Mas isso significa mais do que apenas dividir uma empresa em pequenas equipes. Se essas equipes estiverem de alguma forma limitadas na implementação de código, são inúteis. Elas precisam ter a liberdade de resolver coisas também fora da organização.

Especialização em equipes pequenas

No início, os novos recursos na Yammer eram divididos entre os três desenvolvedores de acordo com sua especialização. Não havia muita rigidez nisso. Então, se houvesse muito trabalho com Rails, Gale poderia ajudar um pouco, mesmo que Rails não fosse seu ponto forte. O objetivo deve ser criar grupos similares que sejam pequenos e especializados, mas que não sejam silos puros, porque diferentes problemas exigem diferentes competências (e diferentes experiências).

Processos seriais e grandes empresas de tecnologia

Essa abordagem funcionou muito bem com três desenvolvedores. Mas quando a equipe da Yammer cresceu, migraram para um modelo mais tradicional de organizações de desenvolvimento de software, com divisão por habilidades técnicas. Havia então uma equipe de back-end, uma equipe de front-end, uma equipe mobile, etc. No final de 2010, não eram mais apenas três desenvolvedores trabalhando em recursos, mas cerca de 30. Mas eram dez vezes mais rápidos? Não.

De acordo com a Lei de Amdahl sobre a execução paralela de programas, o ganho de velocidade de um programa ao usar múltiplos processadores é limitado principalmente pela parte sequencial do problema [já que seu tempo de execução não pode ser reduzido pela paralelização]. Exemplo: Se você tem um programa do qual só pode paralelizar metade, poderia no máximo dobrar a velocidade mesmo com 100 processadores. Com mais 100 processadores, isso não mudaria muito. O tempo para a parte serial do esforço total permanece sempre o mesmo.

As pessoas assumem erroneamente que no desenvolvimento de software o código é escrito com base em especificações – mas isso não é verdade. As decisões técnicas também são muito importantes – e ninguém pode construir uma empresa de desenvolvimento se acreditar nisso.

Em uma organização de desenvolvimento de software de médio a grande porte típica, você pode ter uma equipe de front-end, uma equipe de back-end e possivelmente uma equipe de middleware. Essas equipes têm sua própria base de código e um gerente próprio que reporta a um superior. O ponto é que a organização e a arquitetura do código devem combinar.

Antes que os líderes possam dividir e delegar o trabalho, eles precisam primeiro decidir o que exatamente deve ser construído. Então surgem perguntas como: "No que a equipe de back-end vai trabalhar?" e "Como isso se conecta com a equipe de front-end?"

Quando o trabalho é dividido e delegado pelos níveis superiores de gestão, como acabamos de descrever, está errado. Pense nisso. Se a pessoa que vai implementar o código encontra um problema nas especificações, ela precisa enviar uma sugestão de melhoria para cima, para o nível de gestão, que então precisa ser passada de volta para baixo. Esse processo desacelera um produto e, no final, o leva à estagnação. Além disso, os desenvolvedores em outras partes da organização veem isso como uma perturbação, já que não trabalham de perto com o desenvolvedor que propôs a mudança. Eles simplesmente não entendem o motivo da mudança.

A Yammer não queria isso.

A gestão não deveria tomar decisões de desenvolvimento

Você deve sempre contratar pessoas melhores e mais inteligentes do que você. Se seguir esse conselho, não deveria então confiar a essas pessoas as decisões que você mesmo teria que tomar? No final, é tarefa do líder técnico construir e desenvolver uma organização. Você provavelmente precisará, mais cedo do que pensa, parar de focar apenas em escrever código e direcionar seu foco para a organização em si.

Não acho que você deveria construir um produto. Acho que você deveria construir uma organização que construa um produto.

Seja extremamente cuidadoso ao confiar em gerentes para decisões de desenvolvimento. Na verdade, você deveria passar todas essas decisões para as pessoas que precisam implementá-las. É um claro sinal de alerta quando os gerentes são os únicos tomando decisões para mais de 30-40 pessoas.

Então, como você deveria construir recursos?

Quando um recurso é construído na Yammer, ele deve sempre melhorar uma das três principais métricas:

• Viralidade
• Engajamento
• Monetização

Basicamente, a Yammer quer construir recursos que atraiam clientes, os retenham e sejam comprados por eles. Mesmo que suas principais métricas sejam diferentes, você definitivamente deveria começar a comunicar alguns objetivos principais em toda a organização. Caso contrário, você não pode capacitar todos os funcionários da sua empresa a tomar boas decisões.

Em organizações tradicionais, os gerentes de projeto escrevem as especificações de acordo com suas ideias. Na Yammer é diferente. Em vez de escrever uma especificação rígida sobre o que deve ser construído, uma especificação é vista como ponto de partida para uma equipe multifuncional, que pode então desenvolver a especificação. Se a especificação já for muito longa ou prescrever demais, você deve ter cuidado. Os desenvolvedores envolvidos devem entender as decisões para um recurso, para que possam implementar o código da maneira mais eficiente e eficaz.

A regra "dois e dez"

A regra mais importante na Yammer é: duas a dez pessoas, duas a dez semanas. Então, basicamente não existem projetos maiores ou mais complicados. Existe uma relação não linear entre a complexidade de um projeto e a fase final de integração. Para tudo que dura mais de dez semanas, a duração da fase final se torna desproporcional.

Seguir essa regra também obriga você a lançar com mais frequência, testar suposições e não se preocupar demais com erros. É similar ao Lean Startup e, se quiser experimentar, você precisa codificar isso na sua empresa.

Você precisa desenvolver um senso de urgência. Projetos muito longos são frequentemente culpados quando os desenvolvedores perdem de vista o objetivo real. É como fazer uma trilha. Quando você começa, ainda está cheio de energia, animado com a caminhada e avança bastante rápido. Com o tempo, seu corpo fica cansado e você não consegue mais ver onde começou ou para onde está indo. Quando chega a esse ponto, precisa de muita força de vontade para se motivar a continuar. Infelizmente, muitas organizações colocaram seus desenvolvedores exatamente nessa fase intermediária na maioria de suas tarefas.

No final da trilha, porém, você consegue ver seu destino novamente e a motivação retorna. A cada passo, o objetivo fica um pouco mais perto. É importante que seus desenvolvedores estejam nessa fase, onde podem medir e visualizar seu progresso. Só assim é possível manter a urgência e a moral do trabalho.

Code Ownership

Cuidado com Code Ownership – quando as pessoas têm sua própria base de código, isso pode criar muitos incentivos errados que devem ser evitados. Na Yammer, a organização é dividida em áreas de especialização. Os desenvolvedores são realmente inteligentes e motivados, e quando podem se orientar pelo objetivo da empresa, podem realizar coisas incríveis (e até completamente de forma independente).

Definir como deve ser uma equipe de trabalho

Antes de uma equipe de produto ser criada para um recurso, a especificação é analisada cuidadosamente. Mais especificamente, tenta-se estimar o esforço para o recurso.

Vamos pegar o Produto X. É um recurso imaginário que aumenta a viralidade ao permitir convidar amigos durante o processo de registro. Neste exemplo, o foco está no front-end, o que significa que você pode precisar de duas pessoas para a interface do usuário. E como você provavelmente também precisará mudar algo no processo de registro, certamente precisará de alguém da equipe Rails para escrever o código para isso.

Uma vez que a equipe de produto concordou com uma prioridade para o projeto, você só precisa esperar que os desenvolvedores estejam disponíveis (neste caso, dois para o front-end e um para Rails). Na Yammer existe um grande quadro branco com grade, chamado „Big Board". De um lado, os projetos são listados, do outro, todos os desenvolvedores que trabalham em recursos. Naturalmente, um desenvolvedor só pode trabalhar em um projeto por vez. O Big Board também cria boa transparência sobre as prioridades. Tudo o que é feito durante o desenvolvimento é mencionado ali, e assim o CEO pode dar uma olhada a qualquer momento e constatar: "Então é nisso que os desenvolvedores estão trabalhando."

Se você conseguir garantir o foco para um único projeto, sua empresa já será significativamente mais rápida. É incrível que ninguém estabeleça isso como condição em sua organização – embora basicamente todos saibam o quão caro é uma mudança de contexto. Com foco absoluto, você constrói uma coisa, a entrega e depois pode se dedicar a outra.

Mas quem cuida dos bugs então?

Se todos estão trabalhando em recursos, quem cuida dos bugs? Na Yammer, existem simplesmente várias equipes multifuncionais. Você pega algumas pessoas da equipe Rails, da equipe de front-end e da equipe mobile, etc., e diz a elas: "Seu trabalho é corrigir os bugs e trabalhar na nossa lista." Isso é apenas temporário (como todos os grupos orientados a projetos) e as pessoas se revezam. Essa estrutura organizacional possibilita cuidar do suporte sem afetar o desenvolvimento dos recursos.

Além disso, não se cria uma segunda classe de desenvolvedores. Aqui não são simplesmente alguns desenvolvedores juniores designados para corrigir bugs; desenvolvedores seniores também são incluídos. E isso é intencional, porque quando bugs devem ser corrigidos, você não quer encobri-los, mas corrigir a causa. Pessoas mais experientes devem ter permissão para refatorar o código, se necessário. Esse sistema também cria um ciclo de feedback entre aqueles que constroem os recursos e aqueles que corrigem os bugs. Conhecer a frequência e o tipo de bugs são informações importantes para decisões que podem impulsionar o desenvolvimento do produto.

Este texto é do blog da First Round e foi traduzido por nós para o alemão.