ResearchOps: processos de pesquisas robustos e velocidade são fatores que conseguem andar juntos?

Todo mundo faz pesquisa, mas como adaptar os processos de pesquisa com velocidade mantendo a qualidade da pesquisa para os diferentes contextos da tríade de produto?

Se você está chegando agora, é importante relembrar o que é ResearchOps:

ResearchOps são as pessoas, mecanismos e estratégias que colocam a pesquisa do usuário em movimento. Através desse sistema é possível fornecer as funções, ferramentas e processos necessários para apoiar os pesquisadores na entrega e dimensionamento do impacto da arte em uma organização.

Essa definição é da Kate Towsey, que encontramos na ReOps+ Community também. Então no bom e claro português, o time de Research Ops é responsável por criar processos e projetos que mantenham a pesquisa com usuário rodando com qualidade e de forma escalável.

Quando pensamos em ResearchOps, é essencial termos um olhar holístico e sincero para o cenário que estamos inseridas e ter em mente que não tem receita de bolo. Em um time de produto com centralidade na experiência do usuário, há de se contar nos dedos quem não faz pesquisa — e quem ainda não fez, é apenas uma questão de tempo. Tudo bem, então como escalar processos de pesquisa em um ambiente dinâmico, com contextos diferentes, métodos de pesquisa variados e com pessoas responsáveis pela pesquisa com bagagens distintas?

Nós do time de ResearchOps do QuintoAndar fritamos nossos dias aprofundando essa questão. Encontramos diversos desafios, sem dúvidas nenhuma! Mas vou compartilhar com vocês não só eles, mas também nossos aprendizados!

Só conseguimos adaptar processos se eles estiverem bem definidos

Parece fácil mas não é. Por vezes em um ambiente ágil e com mudanças constantes podemos esquecer que o básico também deve estar claro para todos. Ter um processo de pesquisa funciona não só para a qualidade do time de ResearchOps, como para o restante do time de produto. Por aqui, lideradas pela Dani Matos, levamos em consideração as dores identificadas e analisadas durante seis meses, — sabendo que nosso time sempre fez pesquisas tanto exploratórias como de validação — o quanto teríamos time para suportar e o que era essencial, ou seja, não poderíamos abrir mão de jeito nenhum: saúde do time e qualidade de pesquisa.

No fim, após desenhar etapa por etapa, chegamos com três pautas fundamentais divididas pela semana:

• Recrutamento: olhando o recrutamento de usuários para pesquisa, desde infraestrutura até estratégias de comunicação.
• Consultoria: abrimos algumas tardes semanalmente para marcação de consultoria para o time de produto. Nessa agenda, definimos ações e trocamos conhecimento para melhor construção da pesquisa em parceria com Design, Produto, Data ou Engenharia — não só antes do recrutamento, mas também depois da finalização das moderações com análises e dinâmicas de ideação.
• Projetos estruturantes: Nos projetos estruturantes, olhamos para grandes projetos alinhados as OKRs de ResearchOps — evolução na gestão de conhecimento, definição de treinamentos, aumento de engajamento dos usuários, aumento da taxa de conversão de pesquisa quantitativa…

Ter um processo desenhado não é sinônimo de que tudo sairá conforme o planejado, é preciso resiliência, calma e adaptação. Quando começamos, nem tudo foram flores. Ficamos sobrecarregadas com os prazos e com dúvidas de como atender as novas disciplinas que não tínhamos contato até então. Com o tempo, estamos nos adaptando e identificando pontos de melhoria, e principalmente, buscando estabelecer métricas para nossas ações. O ponto que considero mais positivo aqui: mais tempo para projetos estruturantes e consultoria como um papel definido. Quando a consultoria não era reservada, tínhamos diversas reuniões-consultorias que caiam de paraquedas nas agendas ou no slack, o que não nos dava tempo para nos dedicarmos às outras frentes, como projetos estruturantes.

Alinhar expectativas nunca é demais

Nem todos que vão fazer pesquisas com usuários têm bagagem de pesquisa. E está tudo bem! A pergunta maior era: como o time de ResearchOps poderia dar apoio nesses casos? Até porquê durante muito tempo, ficamos dentro do contexto de Product Design, então tinha uma boa parte do time de Product Management, por exemplo, que não sabia da existência de ResearchOps. Para isso, criamos o Onboarding de Pesquisa. Um projeto que acontece junto aos demais Onboardings, durante as primeiras duas semanas de chegada ao QuintoAndar. Nele deixamos explícito o que fazer quando preciso/quero realizar uma pesquisa? Abordamos pontos como quem é o time de ResearchOps, qual é o escopo, quais ferramentas temos disponíveis, qual é o processo de pesquisa, o que fazer, o que não se deve fazer, LGPD e quais são os papéis das diferentes disciplinas na pesquisa. Começamos com Product Design, adicionamos Product Management e os próximos passos serão trazer os times de Data e Engenharia. Além disso, mensalmente veiculamos a ResearchOps News, nossa newsletter em que debatemos temas quentes de pesquisa no time, sempre entrevistando alguém de Produto e Tecnologia para falar sobre o tema a partir de sua perspectiva.

Ao lado esquerdo, uma imagem do header da newsletter — ResearchOps News — e ao lado direito a captura de tela do Onboarding de Pesquisa.

Unir necessidades faz o processo ser menos burocrático

ResearchOps no QuintoAndar é um time cross. Dificilmente uma dor de um time cross afeta apenas ele. Por exemplo, dificuldade de gestão de conhecimento. Isso era uma dor pra gente que tinha barreiras para entender melhor o contexto e também era um problema para o restante do time de Produto e Tecnologia, que tinha as documentações descentralizadas, não aproveitavam pesquisas feitas anteriormente e também não mantinham as mesmas informações sobre pesquisa.

Para isso, além de termos uma database de pesquisa, desenvolvemos templates orientativos para métodos distintos de pesquisa. Ex: Pesquisas contínuas, pesquisas quantitativas e pesquisas qualitativas. Assim, mantemos informações padrões básicas, encadeamento metodológico que uma pesquisa deve ter, centralizamos as informações do produto e, as pessoas de Produto e Tecnologia, ao abrirem o template, já sabem o que é necessário escrever por lá para conseguirem contornar uma pesquisa.

Observar, testar, acompanhar e medir

Essas são as quatro palavras mães. Tem evidências de que algo pode performar bem? Comece pequeno. Pilote em um recorte menor, acompanhe, tire as métricas e escale. Isso vale para desde recrutamento até projetos estruturantes. Para isso, é fundamental que tenhamos documentações que acompanhem passo a passo de cada teste. Por aqui, temos uma página no Notion apenas com aprendizados dos nossos processos. No nosso contexto, testamos muito no processo de recrutamento — canal, incentivo, tom de comunicação, primeiro ponto de contato, entre outros — e também nos projetos estruturantes, como o Onboarding de Pesquisa.

O mantra aqui é que rapidez não é sinônimo de fazer de qualquer jeito. Podemos ter um processo de pesquisa e sermos rápidos. Para que as pesquisas tenham influência no desenvolvimento de produto, precisamos não só que a rapidez ande junto com critérios de pesquisa, mas também que investiguemos o porquê dessa rapidez constante, para que isso vire oportunidade. Correr com tudo e o tempo todo não é saudável e nem sustentável. É prioridade mesmo ou estamos correndo porque nos acostumamos a isso? O nosso processo de pesquisa surgiu principalmente dessa dor. Como priorizamos pesquisas mantendo a qualidade e rigor metodológico daquilo que estamos desenvolvendo?

Assim como no processo de design, precisamos sempre nos perguntar o porquê as coisas são como são. Tudo bem, precisamos ser mais rápidos no planejamento de pesquisa? Ok, por que estamos demorando? Temos dificuldade de recortar o problema que vamos investigar na pesquisa? Ou será que demoramos na análise dos resultados? E então, sempre questionando, como ResearchOps pode atuar nesse cenário olhando o processo e pilares que temos? Sempre volte no processo e nos pilares do time. Se a solução não for escalável, precisamos ter claro que aquilo é exceção. Logo, ou pensamos em como escalar essa exceção ou guardamos na caixinha de “solução rápida que só deve ser usada em casos de emergência até uma solução ideal”.

Há duas semanas me despedi desse time incrível que fez parte dessa vivência cheia de aprendizados que carrego comigo nessa nova etapa em Product Design. Deixo aqui minha experiência e meu carinho por esse ciclo e por esse time ResearchOps que tive o privilégio de aprender e evoluir em conjunto diariamente — Dani Matos, Lívia Martins, Maria Moraes, Ivethe Albergaria e Alexia Barbieri. Sim, trabalhei em um time de mulheres incríveis demais! 💙

Vamos trocar? Comente aqui ou vamos conversar no LinkedIn! :)