ReOps do 0 | Refinando hipóteses
Uma série de posts contando iniciativas de implantação de uma operação de pesquisa na unico
Antes de começarmos, um pouco de contexto.
A unico é uma IDTech brasileira que oferece soluções de reconhecimento facial, assinatura eletrônica e admissão digital. Com clientes de segmentos diversos, já somos quase 600 seres organizados em uma estrutura em expansão de 4 tribos e mais de uma dezena de squads.
Outro ponto importante para quem pretende acompanhar essa série de posts. Vou assumir como referência os pilares de ReOps definidos pelo NNGroup, se você ainda não conhece, vale a leitura antes de seguir ;)
Hipóteses pra que te quero
Acredito que pesquisadores de experiência são contratados por empresas que já fazem pesquisa nas suas rotinas de construção de produto.
Segundo o IBGedson, são raros os casos em que você será contratado para fazer as primeiras pesquisas de experiência de um produto ou serviço. Apesar de ser o primeiro UXR da firma, quando embarquei no foguete aqui ninguém estava parado esperando um UX Researcher para atuar, todos os times já estavam a mil, disparando questionários e entrevistando clientes nos seus processos de discovery. Isso é mercado Brasil, real oficial.
Assumindo essa minha hipótese como confirmada, desde o início da minha jornada por aqui, vi no onboarding e nas trocas com o time a oportunidade de construir percepções e ideias para gerar valor aos produtos e aos processos.
Sem dúvida, a primeira atividade de fato de quem tem o ownership sobre o projeto de ReOps é de organizar e priorizar as iniciativas de acordo com o contexto percebido, afinal, não se cola soluções e processos de uma empresa na outra sem compreender com profundidade os cenários.
Esta etapa me ajudou a ter um diagnostico que somado às trocas com o time, me permitiu definir por onde começar. E começamos pelo pilar de competency, mais especificamente a definição de um processo para refinar e potencializar as hipóteses de estudos que estavam sendo planejadas.
ReOps | Competency = conjunto de iniciativas com objetivo de capacitar e orientar o time a realizar pesquisas do planejamento a análise. Materiais, workshops, interações individuais ou em grupo são exemplos de atividades possíveis.
Isso porque, com o time "a milhão", rodando pesquisas e testes em todas as squads, foi possível identificar a possibilidade de refinar melhor as hipóteses que estavam sendo testadas.
Muitas perguntas e pesquisas que estavam rodando poderiam ser mais eficientes e acabavam respondendo parte ou mais do que era necessário para que os discoverys de problemas e soluções fossem efetivos.
E apesar do viés inconsciente, antes uma pesquisa que nada, conseguimos destacar a criticidade deste tema para garantir a qualidade dos estudos.
Então como fizemos…
Nada se cria, tudo se aprende, experimenta e itera
Ninguém precisa inventar a roda, existem muitas soluções para os problemas que enfrentamos nas nossas rotinas e, para melhorar a qualidade de pesquisas, não é diferente.
São muitas ideias, sugestões, métodos, cases, etc. Mas acho sempre importante pontuar que a experimentação de métodos tem de levar em conta o processo de aprendizagem e isso implica em fazer a execução "by the book" para depois evoluir com iterações.
Se você tem dúvidas sobre isso, recomendo esse post sobre Shu-Ha-Ri, uma filosofia marcial sobre processo de aprendizagem.
Assumindo isso, definimos o using test card da Strategyzer nas nossas rotinas de discovery. Método super simples e poderoso, e eu não me atrevo a explicar melhor que os autores no vídeo a seguir.
As minhas primeiras experiências refletindo hipóteses com os cards foram muito positivas e, compartilhando isso com os times, fica cada vez mais evidente o valor que este framework gera quando pensamos em qualidade de pesquisa.
Na prática como aconteceu esse processo:
1- Criação do template do card no miro
Para cada uma das tribos disponibilizamos, um board com o template do card para que elas desenvolvessem suas hipóteses a partir de épicos de discovery já priorizados.
2- Exercício prático 1–1
A partir de agendas individuais, fomos criando hipóteses com o test card sobre temas que os designers já tinham em backlog. Colaborativamente testando ferramenta e teoria, tema a tema.
3- Adoção e processo
Uma vez que os designers já tinham treinado o preenchimento e feito reflexões sobre os testes, novos discoverys eram iniciados e aos poucos o using test card foi incorporado ao processo.
Não precisei por aqui, mas não hesite contar com apoio de um sponsor e/ou pedir feedback para o time/pessoa que tiver mais resistência a aderir ao exercício. Avalie o melhor caminho de acordo com a sua realidade.
4- Pé na mesa?
Pobre Alice… tiro, porrada, bomba e correria happens. Como uma área de ReOps, temos o objetivo de não deixar passar nenhum estudo sem teste card feito, mas isso acontece e faz parte, por isso tratamos.
Em uma empresa crescendo exponencialmente, isso vai continuar acontecendo e vamos tratar estes fluxos de exceção fazendo o test card reverso para documentar e trazer clareza sobre a eficiência e eficácia da hipótese planejada. Esse processo também gera aprendizados e na prática se prova apontando possíveis oportunidades não atacadas pela não execução.
E quais foram os resultados até aqui.
Em 3 meses desde a definição dos nossos boards, tivemos:
72 test cards de hipóteses desenhadas por Product Designers, Product Owners e Product Marketings de diferentes tribos e squads.
43 test cards executados gerando fatos e insights que apoiaram discoverys e impactaram de alguma maneira os objetivos e krs dos times.
Até parar para escrever aqui não tinha me dado conta desse volume, é incrível! Como Research, eu não escrevi nenhum destes 72 cards. Temos um time fora da curva que abraçou a ideia e refinou suas hipóteses. Tenho de fazer menção aqui ao Bruno Arruda, Fernanda Romera e Renato Kassabian que fizeram da teoria a prática e experimentaram novos resultados nos seus discoverys.
Faço ainda um registro qualitativo da nossa vivência. Em N seções de refinamento, nosso time chegou para conversas com "quase certezas" de que iriam ter de desenvolver um formulário ou um teste de usabilidade. Depois dos exercícios, mais de uma vez, nos convencemos que o método para validar as hipóteses com maior confiabilidade eram outros, ainda não considerados, e que exigiam esforços e custos menores.
É isso! E ai, curtiu o tema? Vou deixar aqui nosso board V.0 que tem funcionado como um kanban de hipóteses organizado por trimestre.
Espero ter ajudado de alguma forma. Até o próximo post #ReOpsdo0
