Quando uma empresa precisa de Research Ops? O caso da Estratégia Educacional
O [bom] problema
A ideia inicial era fazer um artigo falando sobre como implementamos o Research Ops no Coruja Labs, a área de tecnologia e inovação da holding Estratégia Educacional. Mas, ao começar a escrever, percebi que estava gastando espaço demais contando sobre o que antecedeu essa decisão. Então vi que precisava dar um passo atrás e começar do começo. Ou, como diria Simon Sinek, começar pelo porquê.
Por que, então, a Estratégia passou a precisar, urgentemente, de Research Ops?
O motivo principal é que os researchers alocados nas squads, atendendo cada um a dois times, não estavam dando conta de todas as pesquisas de tecnologia que precisavam ser feitas.
No começo de 2021, o trabalho nas squads passou a contar com um fluxo de upstream bem desenhado, que poderia incluir ou não pesquisa na esteira de Design. Dessa forma, sempre que fosse necessário fazer um teste de usabilidade ou uma survey, por exemplo, o Researcher da squad tocava esse trabalho com a participação nem sempre tão próxima do Product Design e do Product Manager.
O problema é que essas pesquisas de Design não eram as únicas realizadas pelos Researchers. Além das squads, que atuam em áreas específicas da plataforma da Estratégia, nós temos as verticais de negócios que demandam estudos específicos. Dessa forma, as pesquisas de Design competiam com as pesquisas de negócio, o que acabou gerando uma sobrecarga de trabalho nas três pesquisadoras do Coruja Labs.
Lançando um olhar mais superficial, seria possível dizer que a solução para esse problema seria, simplesmente, contratar mais pesquisadores. Essa possibilidade, porém, foi logo descartada, por dois motivos. Embora a demanda de pesquisa tenha crescido substancialmente, aquilo que eu chamo de bom problema, ela não era igualmente grande em todos os meses ou semanas, o que dificultava justificar, financeiramente, a necessidade de aumentar a equipe. O outro motivo para não contratar mais gente se deu pela percepção da falta de um processo de pesquisa bem desenhado e alinhado às necessidades da empresa. Essa organização era mais urgente do que qualquer outra possibilidade de solução.
A [promessa] de solução
Foi nesse contexto de aumento da demanda e de ausência de um padrão no processo de pesquisa que a ideia do Research Ops começou a fazer sentido. Nós, do time de Design, já havíamos falado superficialmente do movimento que algumas empresas do mercado, como Microsoft e Spotify, vinham fazendo nesse sentido, mas não tínhamos ainda conhecimento suficiente do conteúdo para tomar alguma decisão. Sabíamos que o Ops tinha a mesma lógica presente no Design Ops, que já estava mais amadurecido internamente, mas ninguém era especialista ainda em Research Ops.
Depois de algumas conversas com gestores de Design e Produto da Estratégia, decidimos preparar a casa para fazer a mudança que alterou completamente nosso dia a dia quanto à maneira de fazer pesquisa na Estratégia. Preparamos, durante um quarter, todo o processo de pesquisa, a documentação, os treinamentos e conteúdos que permitiram ao time de Research virar, de fato, uma equipe e ganhar autonomia na empresa.
Entender o Research Ops como um mecanismo que coloca a pesquisa em movimento dentro da empresa a partir da oferta de “funções, ferramentas e processos necessários para auxiliar pesquisadores a entregar e escalar o impacto deste ofício pela organização” (Research Ops Community) foi fundamental no desenho da estratégia de implantação dessa iniciativa.
Primeiro, desenhamos o processo de pesquisa com base na nossa realidade, como ilustra a imagem com as etapas da pesquisa:
Em seguida, foram criados conteúdos educativos, templates e exemplos para cada uma dessas etapas. O briefing de pesquisa, por exemplo, só foi implementado quando passamos a usar o Research Ops. Antes de realmente colocá-lo para rodar, ele foi testado em alguns projetos, melhorado e, em seguida, incluído na documentação com sucesso. Atualmente, é impensável imaginar uma pesquisa que não comece pelo briefing (imagem 2), que pode ser iniciado pela área demandante e continuado pela equipe de pesquisa, que não passe por uma critique de pesquisa e pela avaliação com todas as áreas envolvidas e que não termine com a pesquisa catalogada em nosso Repositório.
Além de desenhar os processos e preparar a documentação, outra etapa fundamental de implementação do Research Ops foi a dos workshops com as áreas de interesse. Foram feitos encontros mais teóricos e conceituais com o time de Design e de PMs, e sessões práticas com a dupla de Product Designers e Product Managers das squads. Ao final do Workshop teórico, foi realizado um quiz com a ferramenta Kahoot para avaliar a retenção de conhecimento adquirido durante o encontro, além de reforçar conceitos vistos durante o dia. O vencedor do quiz ganhou o livro “O Teste da Mãe”. Regras de ouro para conversar com potenciais consumidores”, de Rob Fitzpatrick, para ajudar ainda mais no amadurecimento de competências de pesquisa.
Os [tão sonhados] resultados iniciais
Depois de todas as etapas descritas acima, o verdadeiro desafio era fazer o Research Ops rodar internamente. Combinamos com o time de Produto que, a partir da implementação do Re+Ops, o time de Research deixaria de executar pesquisas de baixa e de média complexidade, atuando apenas na mentoria dos Product Designers.
Algumas das etapas do processo precisavam passar pelo especialista, que é o pesquisador, para que decisões de metodologia, público e desenho do estudo fossem realizadas sem perder a qualidade e a especificidade que só um especialista pode oferecer. O desafio, porém, era não nos tornarmos gargalos no processo. Por isso, além de tudo que já foi descrito, passamos a utilizar também o Maze para realização de testes não moderados (vamos ter um artigo para falar especificamente disso), que passaram a ser feitos pelos PDs.
Todo esse trabalho já apresentou um resultado significativamente satisfatório em poucos meses. Apenas no primeiro trimestre de implementação, 7 pesquisas foram iniciadas pelo Re+Ops, tocadas por Product Designers e com mentoria das researchers do time. Além de eliminar as demandas do nosso backlog, acelerando o processo de realização das pesquisas mais simples e, claro, do processo de tomada de decisão, nós pudemos voltar nossos esforços para demandas mais complexas e estratégicas.
Temos visto que um processo bem desenhado e uma equipe alinhada que participa do desenho da solução e que aprende junto, somados a ferramentas que permitem acelerar e a escalar o trabalho, têm sido o segredo dos resultados positivos que estamos colhendo com este trabalho. Se a equipe aumentar daqui a algum tempo, o que acreditamos que irá acontecer, isso acontecerá pelo amadurecimento da empresa com relação à importância de decisões orientadas pela experiência dos nossos usuários, não pela falta de um processo de pesquisa padronizado.
“A implementação do Research Ops trouxe processos que facilitaram muito o dia a dia da área e também ajudaram a dar visibilidade do trabalho para resto da empresa, tornando mais clara as formas de atuação e apoio de research para áreas estratégicas. Além de possibilitar a agilidade dos projetos, o Research Ops foi essencial para que as entregas continuassem sendo feitas com qualidade, democratizando e comunicando o conhecimento do time com o resto da empresa”. Júlia Crespo, UXR da equipe.
“Por meio da preparação de guias, documentações, templates e orientações por escrito, o time conseguiu escalar as atividades de pesquisa, pois isso deu mais autonomia aos gerentes de produto e designers para executar pesquisas menores em seus times. Além disso, os designers conseguiram aprender bem mais sobre pesquisa dessa forma, tendo acesso a documentações de pesquisas já feitas — isso também evitava a execução de pesquisas duplicadas entre os times”. Gio Tagliaro, PD da equipe.
