Estrutura Horizontal na Prática
Como passamos de uma estrutura hierárquica para uma estrutura 100% horizontal.
Nesse primeiro post, vou explicar como funciona a metodologia de trabalho e a estrutura organizacional que desenvolvemos para a nossa empresa. Para tentar ser o mais sucinto possível, vou deixar de fora detalhes de como foi o processo de criação, motivações por trás dessa mudança e resultados obtidos que provavelmente abordarei em detalhes em outros posts no caso de haver interesse no assunto. Vamos lá então.
Crenças e costumes formam a base de qualquer cultura. E a cultura de uma empresa não poderia ser diferente. Na nossa empresa, desenvolvemos algumas fortes crenças ao longo dos anos, como por exemplo:
“o usuário deve ser o centro de tudo o que fazemos”
Tudo o que fazemos é feito para ele e por causa dele. Não para nós e por nossa causa. Sendo assim, as demandas devem partir sempre de necessidades do ponto de vista do usuário.
“somos apaixonados pelo problema, não pela solução”
Quem nunca defendeu com unhas e dentes uma ideia “muito boa” que teve? O problema é que com alguma frequência, soluções (ideias muito boas) são criadas para problemas que não existem, ou para sintomas de problemas que não são o problema de fato. Então antes de começar a criar qualquer solução sempre investimos muito tempo na descoberta real do problema para então partir para o design da solução.
“as soluções são tão boas quanto a média das pessoas que as desenvolvem”
Acreditamos que um copy writer pode ser também um bom designer, da mesma forma que um system admin pode ser também um bom programador, ou seja, acreditamos que as pessoas podem ter talento em diferentes áreas. Aliás, a tendência para o futuro do trabalho é que o que hoje conhecemos como “profissão” acabe se tornando uma das várias “competências” de uma pessoa, mas isso é assunto para outro post. O ponto é que as empresas podem se beneficiar muito de profissionais com conhecimentos de diversas áreas, já que as soluções tendem a ser melhor desenhadas quando há a união de diferentes áreas de conhecimento na definição da solução. No entanto, as estruturas organizacionais formais tendem a formar silos a partir da concentração de conhecimento em departamentos. Isso dificulta a troca de conhecimento entre as áreas e por consequência acaba limitando o potencial de crescimento das pessoas em habilidades que não são comuns ao seu departamento.
“uma tarefa não deveria ser feita manualmente mais do que uma vez”
Se uma tarefa específica é feita de forma recorrente, ela deveria ser automatizada. Pois a tendência natural é que novas tarefas manuais surjam com o passar do tempo, e se não forem automatizadas, a empresa acaba encontrando dificuldade para escalar a sua operação com a grande quantidade de processos manuais a serem executados.
Temos outras crenças além dessas que foram citadas, mas para não estender muito, creio que essas servirão para a contextualização do nosso modelo de trabalho.
Temos então o usuário que é o nosso sol, o centro do nosso universo. Todo o resto orbita em torno dele.
O usuário nos dirige a trabalhar em uma direção ou outra conforme a necessidade.
Então temos o que chamamos de drivers enumerados da seguinte forma:
- Retention: Ajuda a manter os usuários, reduz a taxa de churn;
- Referral: Ajuda os usuários a compartilharem o produto com mais usuários;
- Revenue: Aumenta a média de valor gasto por usuário, ou aumenta margem de lucro;
- Conversion: Faz com que mais usuários convertam para clientes pagantes;
- Frequency: Faz com que o usuário se engaje conosco;
- Adoption: Atinge aqueles que não usam a plataforma/feature ainda;
- Core Experience: Torna a nossa experiência core melhor;
- Activation: Ajuda os usuários a chegarem no “AHA moment”;
- Acquisition: Faz mais usuários assinarem;
- Awareness: Ajuda mais usuários a nos encontrar, saber que existimos.
Esses drivers podem ser adequados a realidade de cada empresa. Podem ser mais específicos (ex: “Reduzir atrito”, “reduzir churn”, “aumentar ARPU”, etc) ou mais genéricos (como no nosso caso), mas o importante para nós no final das contas, é entendermos a coisa toda do ponto de vista do usuário.
Se pegarmos o caso do driver “acquisition” por exemplo, à primeira vista, parece ser algo com o qual o usuário não está muito preocupado e sim a empresa. No entanto, o que a gente deve se questionar é “por qual motivo menos usuários assinaram no último trimestre?”. Essa inversão, e a resposta embasada em dados qualitativos e/ou quantitativos para essa pergunta, e não no “achômetro” é o que fará toda a diferença. No fim, a gente pode acabar descobrindo que a solução não será tão simples quanto criar uma nova versão daquela landing page, como a gente queria acreditar que fosse.
Esses drivers, portanto, nos ajudam a priorizar os problemas que devem ser trabalhados. Esses problemas são armazenados no que chamamos de pools.
Voltaremos a falar dos pools logo mais.
Áreas de conhecimento
Toda empresa precisa de conhecimento em algumas áreas específicas para tornar possível a sua operação. Na maior parte das empresas, o conhecimento fica represado em departamentos. Portanto, se você é de um departamento, significa que não precisa saber fazer o trabalho relacionado a outro departamento. Em algumas empresas essa divisão é tamanha que um departamento as vezes nem sabe dizer o que o outro departamento faz. Nessas empresas, geralmente a única forma de alguém crescer na carreira é ajudando o seu chefe a trocar de empresa, já que ele ou ela provavelmente não vai dar o lugar para você. Isso é o que as pessoas costumam pensar.
Para resolver esse e outros problemas, criamos o conceito de áreas de conhecimento e mentores. Cada pessoa é encorajada a evoluir o seu conhecimento em outras áreas da qual não é a sua especialidade. Cada pessoa também escolhe alguém para ser o seu mentor ou mentora. Como o mentor e mentora são escolhidos e não impostos, as lideranças emergem naturalmente e não de forma artificial a partir da escolha do superior, como geralmente acontece em estruturas hierárquicas.
Os mentores são responsáveis por ajudar os mentoriados a aumentar o seu conhecimento em determinada área na qual o mentor tenha uma habilidade maior. Os mentores também escolhem outras pessoas para receber mentoria dessa forma todos estão em pé de igualdade, a única coisa que difere uma pessoa da outra é o seu nível de conhecimento e habilidades nas áreas de conhecimento da empresa.
O ego, porém, costuma ser um grande inimigo desse tipo de estrutura, já que aquelas pessoas que antes tinham um rótulo para chamar de seu, não mais o tem. Por outro lado, aqueles que não tinham o rótulo, mas mereciam, passam a receber um maior destaque.
Pools
Voltando aos pools… Neles mantemos os backlogs categorizados da seguinte forma:
💩 Problemas: O nosso backlog é enumerado em termos de problemas dos usuários. Não usamos estórias do usuário, job story, épicos, features, ou qualquer coisa do tipo. Os problemas são a nossa fonte primária do trabalho, e todas as pessoas da empresa (não apenas o PO, aliás, ele não existe) têm a responsabilidade de levantar e detalhar esses problemas.
🐒 Trabalhos de macaco: São todos os tipos de tarefas que poderiam ser executados por um primata. É um termo um tanto quanto pejorativo, mas é essa mesma a ideia. Não queremos fazer trabalho repetitivo de forma manual, ponto. Tudo o que puder ser automatizado, será. Sendo assim, quando uma pessoa no seu cotidiano identifica uma tarefa manual que ela faz de forma repetitiva, ela adiciona nesse pool para ser trabalhado por ela mesma ou outras pessoas conforme as habilidades necessárias para a automação daquela tarefa.
🐛 Bugs: Não existe uma solução no mundo que não tenha bugs. Por melhor que seja o seu processo de teste e homologação, algum bug ou outro sempre passará desapercebido. O fato é que trabalhar na correção de bugs não costuma ser a tarefa preferida dos desenvolvedores, e também não costuma ter prioridade frente aquela feature super legal que está lá no backlog. Por isso temos uma fila prioritária especial para eles.
💸 Débitos técnicos: Quem nunca foi pressionado a postergar aquela refatoração ou documentação importante para depois do lançamento? O problema é que geralmente não voltamos para refatorar ou documentar aquele débito que ficou para trás. Esse padrão se repetindo a cada iteração de desenvolvimento gera um problemão lá no futuro. Por outro lado, débitos técnicos são o tipo do problema que só são importantes para os mais técnicos e por conta disso nunca são priorizados pelo pessoal de negócio (o PO nesse caso).
Cada pessoa da empresa tem a responsabilidade de alimentar os pools. E temos uma pessoa que fica responsável por priorizar os itens e colocá-los no que chamamos de ciclos de desenvolvimento.
Ciclos de desenvolvimento
O ciclo é um período de 6 semanas dedicadas ao refinamento de um problema, design e desenvolvimento da solução mínima viável.
Durante o ciclo temos algumas cerimônias:
- Bug Killing Day: É um dia onde toda a empresa para o que está fazendo e foca na solução de algum bug.
- Monkey Hunting Day: É o dia em que nos debruçamos sobre os trabalhos braçais e cada pessoa da empresa pega um desses trabalhos braçais para automatizar ou resolver de outra forma.
- Debit Payment Day: É o dia em que pagamos as nossas dívidas. Cada pessoa da empresa escolhe um débito técnico que queira resolver.
- Big Day: Esse é o dia mais importante do ciclo. É um dia, onde todos os times fazem uma demo das entregas que fizeram e por consequência é um momento de troca de informação entre os diversos times e de alinhamento da estratégia para os ciclos futuros. Nesse dia também fazemos um ritual para a melhoria do processo onde cada pessoa expõe um problema do processo com uma sugestão de solução para esse problema. Dessa forma o processo passa por mudanças a cada ciclo e assim um problema na forma de trabalhar não persiste mais do que 6 semanas. No final desse dia são expostos os novos problemas nos quais trabalharemos no próximo ciclo, e as pessoas se candidatam para trabalhar em determinados problemas com os quais elas mais se identificam. Assim, uma pessoa sempre vai trabalhar na coisa que realmente acredita que seja a mais importante, e novos times se formam a cada ciclo. O dia termina com comes e bebes e um novo ciclo se inicia na semana seguinte.
A troca frequente de times contribui para o compartilhamento de conhecimento entre as pessoas e a aproximação entre ela, quebrando assim, as panelinhas que se formam naturalmente quando se trabalha em departamentos. Outro benefício é que ninguém é obrigado a trabalhar com aquele ou aquela mala sem alça por mais do que um ciclo 😄.
Conclusão
Desenvolvemos um modelo próprio baseando-se em crenças que fazem sentido para o nosso contexto de negócio. Esse modelo foi composto por práticas de outras empresas e pelo aprendizado empírico da nossa própria história enquanto empresa.
Definitivamente, não é a bala de prata, não é perfeito, mas resolveu uma série de problemas que tínhamos antes de desenvolver esse método de trabalho. Naturalmente, outros problemas surgiram, e o principal deles com o qual estamos lidando no momento é o equilíbrio entre projetos e processos. Essa forma de trabalhar tende a dar uma maior enfase em projetos e os processos acabam ficando em segundo plano, o que gera outros problemas.
O que é interessante notar é que, no final das contas, a coisa que realmente definirá se a sua empresa terá ou não sucesso são as pessoas. São elas que sabem ou não fazer a coisa acontecer, são elas que tem as habilidades necessárias para criar algo incrível ou algo mediano. E é com elas em mente, que o seu processo deve ser desenhado e adaptado. Por que como diz o ditado, “a cultura come a estratégia no café da manhã”.
Quer saber mais sobre como esse processo foi desenhado e os prós e contras que aprendemos depois da implantação? Deixe o seu comentário 😉.
