Research Ops no Grupo SBF: como começa e onde termina.

O papel de Research Ops no processo de Design de grandes empresas e por onde começar — e talvez terminar.

Antes, um pouco de contexto sobre Design no Grupo SBF

O Grupo SBF nasce no final de 2020 na compra da Nike do Brasil pela Centauro com uma finalidade: ser um ecossistema que apresente íntima relação com a audiência/cliente/usuário do esporte. Na união da maior varejista esportiva do Brasil com uma das marcas mais valiosas do mundo, o ecossistema começa a tomar forma e é consolidado recentemente pela aquisição da NWB, pioneira na produção de conteúdo esportivo para o YouTube e detentora de uma audiência de milhões de visualizações todos os meses na plataforma.

Em meio a todo esse contexto, a Tecnologia desempenha papel protagonista. Design, por consequência, também. Em questão de meses a estrutura de Product Design triplica de tamanho, assim como de UX Research, que cresce cerca de sete vezes.

Com mais de 20 times de produtos diferentes pesquisando simultaneamente e com o desafio de, além de organizar e escalar ainda mais as pesquisas, olhar para o futuro, nasce Research Ops.

Research Ops: é de comer ou passar no cabelo?

Historicamente, o processo de UX Design ganha maturidade a partir do momento que começa ter processos bem definidos e agregar à subjetividade da função ferramentas objetivas. O caminho de maturação trilhado, sai de uma visão focada em criar apenas boas experiências visuais aos usuários e chega até o ponto de impactar na estratégia do negócio, pensando no futuro e conhecendo intimamente o usuário para propor soluções a seus problemas.

A pesquisa necessita de atenção especial, visto que é fundamental para o processo de Design atingir maiores níveis de maturidade. Organizar um repositório de pesquisa, estabelecer governança para ferramentas, otimizar processos e olhar para a segurança de dados são algumas das dores compartilhadas por muitas empresas que possuem uma grande estrutura de UX. A disciplina de Research Ops surge como solução para essas questões e aqui não foi diferente.

Com o aumento do time e com a ambição de Design passar a direcionar a estratégia do negócio, aqui estávamos com algumas necessidades, dentre elas as principais: estruturação de nossos processos de UX Research (para que fossem escaláveis), implementação de um repositório acessível e consumível para os resultados de nossas pesquisas, organização de nossas ferramentas e estudo de novas para suporte à rotina de trabalho, além do cuidado com a governança de dados em atenção à LGPD.

No entanto, esse foco começou a ganhar força recentemente e são ainda poucas as empresas que olham para Research Ops, especialmente aqui no Brasil. As referências são escassas no mercado e a atuação provavelmente ainda fica no plano etéreo para muita gente — inclusive para nós de Ops.

A licença poética de criar

O início do trabalho para alguém nesse contexto é complexo, visto que é fruto de desafios pontuais esparsos, um mar aberto de possibilidades e pouca direção. Muitas pessoas diante disso sentiriam a necessidade de fundamentos teóricos e visão de futuro para conseguirem se situar — e eu sou uma delas.

Assim, peço licença poética para compartilhar um singelo modelo teórico que criei com base em nossa realidade e no Modelo de Maturidade de Design da Invision (Link) e também apresentar como nós desenvolvemos nossa estratégia da área de pesquisa com base nele aqui no Grupo SBF.

A missão de Research Ops é deixar de existir

Aproveitando dessa licença poética, o exercício filosófico que embasou a teoria foi de que a idealização de qualquer trabalho direcionado à mudança cultural e otimização de algo é deixar de existir.

Quando estamos falando de Research Ops, estamos falando de uma função que coordena todo o ambiente de pesquisa, ou seja, que relaciona todos os processos, pessoas e ferramentas para alguma finalidade. Finalidade, essa, que é auxiliar na maturação da cultura de Design dentro de uma organização.

A necessidade de Research Ops emerge da relação entre quantidade de trabalho e esforço necessário para desenvolver o ambiente de pesquisa (e, por conseguinte, de Design) dentro de uma organização.

A régua de esforço (eixo X) necessário para alcançar esse objetivo então foi baseada no Modelo de Maturidade de Design da Invision (Link), buscando entender onde estávamos (fase 2 de maturidade da Invision) e onde queríamos chegar com os processos de Design, com operação estruturada e escalável (fase 3 da Invision e ponto 3 do eixo X), visto como ciência pela organização (fase 4 da Invision e ponto 2 do eixo X) e direcionando a estratégia do negócio (fase 5 da Invision e ponto 1 do eixo X). A quantidade de trabalho (eixo Y) tem suas ações definidas por máximas relacionadas a mudanças culturais em cada uma das fases e a complexidade para atingir cada uma delas.

Da teoria à prática

A partir da teoria, nós (Lideranças de Design, Research Ops e UX Research) começamos a trabalhar na estratégia para irmos do abstrato ao concreto. Demos os seguintes passos:

1) Diagnosticamos as dores de Research e as classificamos dentro do diagrama que representa as variáveis que compõem o ambiente de pesquisa.

Durante esta etapa fizemos o mapeamento síncrono e assíncrono de todas as dores e oportunidades que tínhamos envolvendo UX Research. Todas elas foram categorizadas com relação às quatro variáveis que envolvem o ambiente de Design (e Research): Gestão, Pessoas, Processos e Ferramentas.

No exemplo da imagem, o Post-it “Dificuldade em visualizar todas as pesquisas em andamento” entra na interseção entre Gestão e Ferramentas devido, primeiro, à sua relação com a gestão da rotina de trabalho do time e, também, porque dependia de uma ferramenta de repositório e gestão de tarefas ainda em processo de implementação na estrutura de tecnologia.

2) Estabelecemos o caminho necessário para atingir cada fase de maturidade de Design e reagrupamos as dores.

Nesta etapa, primeiro, eu fiz o desdobramento da régua do eixo X com todos passos que teríamos que dar para chegarmos à primeira fase desejada, a de Design com Operação Estruturada e Escalável. A partir disso, reagrupamos as dores de acordo com os passos necessários, indo de baixo (estado atual da época) para cima (fase desejada).

É extremamente necessário que todo o time entre em consenso sobre essa parte do trabalho. Aqui nós gastamos um bom tempo discutindo em qual passo necessário a dor se encaixava dentro da régua. No caso, o exemplo acima de “Dificuldade em visualizar todas as pesquisas em andamento” se encaixou no passo necessário de “Processo operacional padrão de pesquisa”.

3) Propusemos soluções para cada uma das dores apresentadas

Nesta fase não há muito segredo. É colocar todo o time para pensar em soluções reais para todas as oportunidades que apareceram.

4) Priorizamos as soluções

A priorização das soluções depende muito do contexto onde o time está inserido. A urgência de algumas soluções pode variar de acordo com a empresa. Uma forma que encontramos aqui para alinharmos as expectativas e também identificarmos a real necessidade das ações foi cada pessoa votar (numa escala de 1 a 4) o impacto e o esforço de cada uma das soluções propostas.

Após a votação (que ocorreu às cegas, ou seja, sem vieses compartilhados) nós estabelecemos as médias e distribuímos na matriz de Esforço X Impacto. Ao final, geramos uma lista de tarefas, da mais prioritária para aquela que poderia ficar para depois. É extremamente importante que todo o time tenha visibilidade dessa lista, porque ela irá ditar os próximos passos do time.

Ao final desse trabalho em conjunto nós saímos com alguns ganhos diretos e indiretos, dentre eles:

1. Alinhamento das lideranças de Design e do time de UX Research sobre a estratégia e o trabalho de Research Ops
2. Soluções reais para dores reais
3. Uma direção clara para Research Ops seguir

Além de muito trabalho, é claro!

Enquanto houver pesquisa…

Independente do tamanho da estrutura de UX Design da empresa ou da maturidade dos processos de pesquisa, as pesquisas continuarão existindo e a necessidade de Research Ops aparecerá em forma de responsabilidades divididas entre todo o time, funções em tempo integral ou parte do cargo.

Deixar de existir é um exercício meramente ilustrativo para acompanhar a tendência de diminuição da necessidade de algo a partir da otimização de processos. Caso chegue no ponto de tudo funcionando com autonomia, saberei que cumpri minha missão enquanto Researcher Ops.