Para essa entrega a empresa não tinha definido um OKR específico. Recolhi por conta própria alguns dados que achava importante para me nortear durante e após a entrega.

O objetivo dessa entrega era tornar o sistema de questões um ambiente de fácil comunicação entre alunos e professores, facilitando o entendimento da matéria e assim alcançando um número maior de aprovados nos concursos. Essa taxa de aprovação serviria como base de apoio para campanhas de marketing.

Com base na minha experiência prévia, pude perceber que seria uma entrega bastante extensa e complexa, o que demandaria muito tempo e esforço para entregar os arquivos finais ao downstream. A forma mais eficiente e correta de proceder neste cenário era dividir a tarefa em entregas menores, de forma que todas as partes envolvidas (downstream, upstream e stakeholders, entre outras) pudessem assimilar e avaliar a parte entregue e já sugerir os ajustes necessários enquanto as outras partes estavam em evolução. Dessa forma, evitamos retrabalho do upstream, que pôde fazer correções nas entregas antes de finalizar a tarefa inteira, e aprimoramos alinhamento entre as equipes envolvidas, prevenindo ruídos no processo.

O resultado do primeiro diamante é um conjunto de hipóteses.
Reunir pesquisas de usuários (e outros tipos) serve para formar insights. O valor da percepção é, inicialmente, entender as dores e oportunidades do usuário e se o produto existente está fazendo um bom trabalho.

Com o primeiro mapa de dores e valores já realizado, decidimos que era importante recolher a percepção dos usuários sobre o fluxo de estudo atual. Esse teste de usabilidade trouxe uma nova visão para alguns pontos que não haviam sido mapeados anteriormente.

Outra parte importante no processo era ouvir os professores e assistentes de ensino que operavam o back office. Durante todo o processo foram realizadas dinâmicas para entender as dores, recolher possíveis novas ideias e alinhar as expectativas da entrega.

Como boa prática, foi realizado um benchmark com os principais players. Neste processo enumeramos as melhores e piores práticas das ferramentas disponíveis. Com o resultado dessa tabulação, criamos uma matriz CSD para nortear a entrega, eliminando pontos fracos e priorizando os pontos fortes.

Esses pontos podem se tornar o objeto de trabalho de um Design Sprint.

Uma vez recolhidas as percepções após a primeira etapa do Triplo Diamante, o squad consolida os dados levantados e desenha um novo fluxo, buscando soluções para as dores antigas e incorporando as novas ideias e oportunidades mapeadas, para uma entrega tangível do produto. Nessa etapa, ressaltamos a importância da quebra das tarefas para garantir maior tração ao processo de dual track, assegurando maior entendimento das partes envolvidas e aumentando a visibilidade por parte dos stakeholders, que acompanharão a evolução do produto conforme vai ganhando corpo em ambiente de produção.

Importante destacar que entregas menores facilitam o entendimento das métricas e priorização do backlog.

Junto com Tech Lead e o P.O do squad, realizamos o primeiro refinamento técnico mapeando os débitos técnicos e priorizando a entrega de valores. Chegamos a uma esteira de 6 entregas macros, que no futuro seriam fatiadas novamente em micro tarefas.

Agora olhando isoladamente para a primeira esteira de entrega, realizamos um novo refinamento técnico, dessa vez com toda a equipe de desenvolvimento. O valor desse refinamento era especificar quais partes dentro da esteira macro eram essenciais e deveriam ser priorizadas (MVP) e o que poderia realimentar o backlog como uma futura melhoria.

Ainda no processo de refinamento, é realizado uma dinâmica em que toda a equipe propõe uma estimativa de tempo para cada uma das tarefas. O indicativo na parte superior refere-se à estimativa de tempo em upstream e, a inferior, ao indicativo de downstream.

Com todas as tarefas priorizadas em backlog, começamos a tracionar a entrega em upstream realizando alguns processos. Em casos esporádicos, alguns desses processos não são realizados devido a sua baixa complexidade.

Após a entrega da primeira esteira de tarefas, realizamos dois testes de usabilidade para acompanhar o sucesso da entrega. O primeiro teste foi realizado antes da iniciativa chegar ao ambiente de produção, por meio da validação do protótipo e seu valor para os usuários utilizando a ferramenta Maze. O segundo teste consistiu em perguntas abertas realizadas no Hotjar para uma base segmentada de alunos que usavam com maior frequência o sistema de questões. Ambos os testes trouxeram uma percepção de evolução do produto para os usuários, e algumas das métricas recolhidas via Analytics e Metabase mostraram que houve benefícios secundários, como redução de esforço dos professores para responder aos comentários.