Como organizamos e documentamos o trabalho de Produto e Design no iFood

Usando Confluence e Jira para organizar e coordenar o trabalho de três tribos com centenas de pessoas.

Em Março, o iFood inteiro virou uma empresa 100% remota da noite para o dia. E isso aconteceu sem nenhuma planejamento, é claro. Ninguém esperava uma pandemia que nos forçaria a fazer essa mudança tão rápido.

Assim como muitos lugares, o iFood tinha uma cultura presencial. Você quer saber sobre cardápio? Vai até a mesa de tal pessoa e pergunta. Aquisição, ah, isso é com aquela outra pessoa. O trabalho remoto deixou nossos vícios presenciais muito aparentes, entulhando o Slack e as caixas de e-mail com dezenas de mensagens, sem contar os incontáveis documentos com os títulos Status atual ou Estratégia e próximos passos voando pelo espaço cibernético. Você se identificou um pouco com isso? Complicado, né, minha filha?

Imagine: 3 tribos, mais de 50 designers, 50 PMs e centenas de pessoas engenheiras trabalhando juntos em um contexto completamente novo. O que já era desafiador presencialmente ficou ainda mais difícil de se fazer com pessoas que estão a um modem de distância. Se nosso objetivo é ser uma das melhores empresas para se trabalhar remoto, precisávamos começar uma mudança estrutural. Bora lá!

Qual a dose certa de processo?

Eu sei que organização é uma das chaves pra resolver esse problema, mas a grande dúvida é: quanto? Em um lugar tão dinâmico quanto o iFood, a palavra processo dá calafrios em quem ouve, e com razão. Isso não é pra gente! Ou é?

Como o Fabrício, nosso CEO, sempre fala, o que a gente não quer é processo burro. Vamos rasgar todos os processo que não funcionam e reescrevê-los (tomara que esse não seja rasgado tão cedo 😅).

Processos são um idioma. Imagine um lugar onde cada squad fala uma língua diferente. O squad A fala japonês, B fala alemão, C fala francês e, por algum motivo bizarro, D fala esperanto. O trânsito de informação entre esses times fica cada vez mais difícil. E é exatamente isso que acontece quando cada time tem um jeito diferente de trabalhar.

O que um chama de hipótese, o outro chama de oportunidade. O que um chama de estória, o outro chama de task. As validações que um fazem, são ignoradas pelo outro. O que é necessário pra um, é opcional para o outro. E sempre que a informação precisa transitar entre os squads, é preciso codificar e decodificar, o que cria muito ruído. E assim, pouco a pouco, o caos se instaura.

A evolução dos processos, de acordo com a complexidade. Eu vi essa imagem uma vez mas nunca mais consegui achar a fonte para dar os créditos. Alguém fez isso, só desenhei de novo do que eu lembro.

O importante não é definir todos os processos, mas definir processos suficientes para resolver o problema. Os problemas são, em ordem:

1. Informação sempre disponível. Para isso, criamos uma wiki;
2. Linguagem comum para os times de produto, facilitando o intercâmbio de informação. Para isso, definimos uma ferramenta única e um jeito de usá-la;
3. Minimizar o retrabalho na hora de comunicar. Para isso, usamos integrações e processos simples.

Disclaimer: A maioria dos dados aqui é fictício, exceto uma coisa ou outra. Essas são informações estratégicas que eu não poderia compartilhar, mas fiz meu melhor para criar simulações que chegam perto da nossa realidade.

1. Criando a nossa wiki

Eu aposto que hoje, no seu dia-a-dia, existem várias apresentações e documentos espalhados. É assim que a maioria dos times se organiza: documentos de visão estratégica, planos e estrutura. E aí vem alguém (eu era o campeão em fazer isso) e cria um documento na mesma pasta para o planejamento do próximo ciclo, e ninguém mais sabe qual é a versão certa.

Isso não é muito eficiente porque:

• Esses documentos são difíceis de entender. Geralmente são apresentações com muitas imagens e têm informações pela metade;
• Não existe um índice. Boa sorte ao tentar encontrar as últimas versões das coisas mais importantes;
• Ficam desatualizados. Um documento serve seu propósito, e então as pessoas param de atualizá-lo.

Alguém já resolveu isso, não? É claro, uma wiki! É um lugar colaborativo e vivo, que resolve (quase) todos esses problemas. E é assim que começamos. Ah, e é claro que nada disso está pronto, ou vai estar algum dia. A wiki é viva e reflete como estamos trabalhando hoje.

A página da tribo

Cada tribo tem uma página que fala sobre a missão da tribo, as squads e a estrutura. A ideia é que qualquer um possa entrar nesta página, entender como estamos organizados e encontrar mais informações sobre qualquer assunto.

A página do squad

Cada squad tem a sua página, onde aparece: objetivo, principais indicadores, roadmaps, membros e links para saber mais sobre aquela squad. O importante aqui é minimizar o retrabalho. Quanto mais pudermos pegar informações do Jira em tempo real, ou colocar links para outras informações como apresentações ou documentos de texto, melhor.

Essa página geralmente tem um roadmap ou issues do Jira no corpo, mas não consegui criar um roadmap fictício pra colocar aqui.

A página dos produtos

Cada produto tem sua página, com várias informações. Desde como funciona a parte de engenharia de um sistema específico, até porquê tomamos as decisões de design e produto em uma funcionalidade.

A página dos chapters

Existem informações importantes de cada chapter que precisam ser documentadas. Por exemplo, é no chapter de design que documentamos coisas como nossa organização do Figma, política de acessos, quais ferramentas estão disponíveis e quando usar cada uma delas.

O que mais cada time achar que faz sentido

Cada squad vai encontrar mais e mais jeitos de usar a wiki a seu favor, e isso é demais! A única coisa esperada é que cada uma faça no mínimo a documentação básica. Além disso, é deixar que elas tenham liberdade para trabalhar como acharem melhor.

2. Organizando o trabalho no Jira

Cada squad sempre conseguiu se organizar bem para trabalhar individualmente, e isso não era um problema. As coisas começam a ficar mais complicadas quando também é muito importante mostrar o que está sendo feito, coordenar com outros squads e priorizar levando diversas perspectivas em consideração.

Então é importante que a ferramenta:

• Funcione para o squad. Não dá pra atrapalhar o que já funciona bem;
• Seja flexível;
• Seja acessível para a empresa toda, sem barreiras;
• Seja fácil de entender, até mesmo pra quem não está acostumado com processos de discovery e delivery;
• Possibilite a conexão entre vários assuntos.

E pra isso escolhemos o Jira Next-Gen, que nos dá todas essas ferramentas e já era uma ferramenta padrão do iFood. Assim, escrevemos um guia sobre como cada time de produto deveria usá-lo.

Organizando o trabalho de produto

Fizemos uma divisão simples:

• Épicos são o nível macro de organização. São, basicamente, as oportunidades que estamos trabalhando — elas podem ter três tipos de filhos: hipóteses, features e tasks;
• Hipóteses representam a maior parte do trabalho e tem uma lista pré-definida de critérios mínimos que precisa preencher;
• Features representam a exceção. É algo que que temos que fazer, mesmo que não tenha uma hipótese clara;
• Tasks são coisas mais práticas, como análises e pesquisas, que não precisam estar ligadas a nenhuma hipótese e geralmente são exploratórias ou de manutenção.

Fica tudo organizado no Roadmap do squad. Qualquer pessoa deveria conseguir entrar e entender quais são as prioridades.

É claro que isso é uma imagem fictícia, mas representa bem as coisas que um squad poderia estar fazendo.

Se a pessoa quiser se aprofundar em alguma coisa específica, é só expandir aquele épico para ver quais hipótese ou features estão sendo trabalhadas.

É claro que isso é uma imagem fantasiosa, mas representa bem as coisas que um squad poderia estar fazendo.

A anatomia de uma hipótese

Uma hipótese é uma aposta que o time de produto tem para resolver um problema e que precisa validar. Ela tem:

• Objetivo. Uma frase simplese explicando o problema que estamos resolvendo;
• Hipótese. Uma explicação completa, com racional, contexto e indicadores;
• Análises e contexto. Links para informações importantes relacionadas, como estudos, levantamentos e análises;
• Resultado. Quando uma hipótese termina, ela precisa de um documento de resultados explicando o que aprendemos e se ela foi um sucesso ou uma falha.

Essa é uma hipótese real, com os números e informações sensíveis removidos. Os restaurante já usam isso há alguns meses e a hipótese foi um sucesso.

Progredindo — Sub-tarefas

Alguns times preferem usar sub-tarefas para progredir no trabalho, separando cada parte que precisa ser feita. Geralmente há uma sub-tarefa para cada coisa, como análises preliminares, criação de dashboards, desenho do fluxo, review com o time e etc.

Nesse caso o board fica organizado por sub-tarefas, e cada pessoa fica responsável pela sua parte. Isso é bom porque deixa claro o que está sendo feito e por quem.

Com sub-tarefas fica claro quais são as tarefas que estão sendo feitas, mas tem mais coisas no board ao mesmo tempo.

Progredindo — Movimentando as hipóteses

Outros times preferem movimentar as hipóteses em si no board, sem criar as sub-tarefas. Esse caso é interessante porque a tarefa vira uma grande discussão, onde vários aspectos são discutidos e iterados. Ler os comentários em ordem cronológica ajuda a entender exatamente como certas decisões foram tomadas.

Isso é bom porque o board fica simples e mostra apenas o progresso em alto nível, e cada hipótese tem um histórico mais coeso e detalhado.

Em um board só é possível ver todas as hipóteses que o squad está trabalhando, e em que estágio cada uma está.

Relacionando as coisas

Também é importante saber, dentro do todo, o que está relacionado. Temos algumas iniciativas que estão distribuídas entre squads de três tribos diferentes, por exemplo. Pra manter isso em controle, fazemos três coisas.

• Relacionamos hipóteses que caminham juntas. Assim, por exemplo, dá pra acompanhar coisas que precisam estar prontas em mais de um produto para poderem ser lançadas;
• Relacionamos as estórias de desenvolvimento com a hipótese que ela está implementando. Assim é só abrir a hipótese e olhar qual o status das tarefas de desenvolvimento para ter uma ideia de quando algo vai estar pronto;

Aqui dá pra ver as sub-tarefas da hipótese, as tarefas de delivery em “is implemented by” e outras hipóteses de produto relacionadas em “relates to”.

• E, por último, temos um projeto específico para criar épicos para as principais iniciativas da empresa. Existe um lugar único que qualquer um pode abrir para entender o que está sendo feito com relação a uma coisa em específica, como por exemplo, a iniciativa de catálogo.

3. Fazendo o delivery

Até agora falamos de como os times fazem o discovery dos seus produtos. Mas como desenvolver e escalar isso, agora que sabemos que é o certo a fazer? (Vale voltar e lembrar o que é discovery e delivery).

Cada squad pode escolher como fazer. A recomendação é ter projetos separados no Jira, um para discovery e outro para delivery porque ajuda o designer e o PM a se desassociarem das rotinas de desenvolvimento. Nem sempre o melhor jeito de trabalhar discovery é com sprints, que é como a maioria dos times de desenvolvimento fazem.

Mas essa é mais uma preferência do squad do que uma regra, e eles podem escolher o que funciona melhor.

Fluxo saudável entre discovery e delivery

É importante que a track de discovery consiga entregar trabalho suficiente para que sempre haja um backlog de delivery. A métrica mais importante para isso é o número de pontos (ou qualquer outra métrica de estimativa) do backlog. Ele deve sempre se manter estável ou crescer ao longo do tempo com o que sai do discovery.

Em problemas mais complexos pode ser difícil manter esse fluxo de hipóteses validadas fluindo. É importante ficar de olho nesse número e, sempre que ele ficar menor do que o time consegue entregar no próximo sprint, pense em alternativas para suprir esta demanda.

Uma ideia é aproveitar esse momento para resolver bugs ou refatorar algum pedaço do software — o time sempre tem algo que gostaria de refazer. Outra ideia é aproveitar esse tempo para que o time de desenvolvimento possa ajudar em outras iniciativas, enquanto a track de discovery valida mais hipóteses e cria um backlog maior.

4. Integrando e dando visibilidade

Uma vantagem de ter um sistema organizado e funcionando bem é eliminar retrabalho. Isso geralmente leva a informação a fluir de maneira mais natural — não precisa lembrar de atualizar 3 apresentações e 2 planilhas. É só manter o trabalho atualizado na ferramenta e o resto acontece automaticamente. Vou dar alguns exemplos.

Notificando sempre que algum fluxo está pronto para ser revisado

Sempre que uma issue com a tag design muda para para o status under review, ela é automaticamente postada no nosso canal do Slack para design reviews. Assim todos os designers sabem que tem algo disponível para ser revisado e comentado.

Automatizando páginas de iniciativas no Confluence

Outra coisa legal é misturar Confluence e Jira para criar páginas que fazem duas coisas: explicar um projeto e ao mesmo tempo mostrar em que pé as coisas estão. Dá pra usar o corpo da página para explicar um projeto ou iniciativa, e então incorporar roadmaps e buscas do Jira para mostrar o que está sendo feito e quando serão as próximas releases.

Dicas pra começar

Se a ideia de organizar o seu time parece legal, existem algumas coisas que deixam esse caminho mais fácil:

• Use as ferramentas que estão ao seu alcance. Quanto menos ferramentas novas você introduzir, melhor. O Jira e o Confluence já faziam parte do nosso pacote de ferramentas e foi mais fácil por conta disso;
• Dê um passo de cada vez. Não tente criar todos os processos e mudar tudo de uma vez. Resolva um problema de cada vez, e em alguns meses você estará muito melhor;
• Encontre os seus campeões. Busque as pessoas que estão com vontade de mudar, e comece por elas. Quanto mais gente está usando e colaborando, mais fácil fica para novas pessoas participarem.

Isso não está pronto e nunca vai estar

Isso é como nos organizamos hoje, e estamos num processo constante de mudar e melhorar. O que você achou? Você faz alguma coisa legal que a gente poderia fazer também? Conta aí!

Agradecimentos aos nossos champions Vânia, Fê Lopes e Capeleiro pela ajuda na construção disso. Também ao Nery, Mariote e Mauro pela força para fazermos a mudança. E pra todo mundo que teve que migrar (ou está migrando) as coisas de ferramenta e encarou isso com bom humor.

Quer receber conteúdos exclusivos criados pelos nossos times de tecnologia? Inscreva-se.