Project Process: Como a organização impacta no desenvolvimento de projetos

Published in

luizalabs

9 min readNov 8, 2022

Fala meu povo, de buenas?

Há pouco mais de 2 anos e meio, comecei minha “especialização” em UX Research. Trabalhar com inovação abriu meus olhos sobre o que de fato eu queria me aprofundar dentro do universo centrado no usuário que conhecemos comumente como UX.

Traduzindo de forma bem simples do inglês User Experience, UX é o profissional que lida com a experiência do usuário. Isso sendo um produto, uma feature, uma marca, uma pesquisa, etc. As possibilidade são finitas mas bastante abrangentes, tanto que quem faz parte da guilda de UX, sabe que ano após ano nasce uma nova vertente dentro do “Guarda-chuva de UX”, como:

CX (Content Experience),

UI (User Interface),

UXR (User Experience Research),

UXW (User Experience Writing),

UXB (User Experience Behavioral),

UXS (User Experience Strategy),

Entre outros.

UXR como o próprio nome diz, tem foco em conceber, diagnosticar, compreender e analisar o Como, Onde e Por quê, antes de pôr em prática um insight, um update ou um produto do 0.

E o que eu quero dizer com isso?

Research significa Buscar, investigar algo, apurar dados, organizá-los e assim criar uma espécie de agrupamento comprobatório de informações. Quando pesquisamos e apuramos algo, diminuímos potencialmente o risco de que futuramente aquilo que necessitou de uma pesquisa aprofundada, dê errado (Ou ao menos evitar isso).

Eu por exemplo, sou uma pessoa que antes de comprar qualquer coisa na internet ou fisicamente, pesquiso de cabo a rabo. Para tudo eu crio um checklist e normalmente é assim:

Qual a minha principal necessidade?
Por que e pra que preciso (É para curto, médio ou longo prazo?)
O quanto isso impacta no meu orçamento mensal?
Quantos e quais produtos similares existem?
Qual a faixa de preço e quanto estou disposta a pagar?

Depois que defino isso tudo, começo a pesquisar, salvar os links por grau de afinidade, apurá-los mediantes meu gosto e necessidade e depois compro.

Em média, isso demora bastante haha. Sou bem meticulosa, raramente faço algo por impulso.

E por que tô falando sobre isso tudo?

Por quê pensa comigo: Se é interessante e super viável fazer isso para algo tão trivial como uma compra, o quanto uma pesquisa bem definida e aprofundada impacta na criação e desenvolvimento de um produto ou nova ferramenta?

Antes de compreender o seu público alvo, é necessário descobrir se de fato faz sentido ir pra frente com essa concepção. Não se pode se basear em achismos e sim confirmações.

Pesquisas de profundidade, Benchmark, Desk research, entrevistas, formulário, faz tudo parte desse universo de investigativo e dia-a-dia de um Researcher.

E foi aí que surgiu a minha ideia de criar um fluxo de processo para identificar onde, como, porquê e quando usar uma ferramenta ou metodologia no Product Definition dentro do workflow de uma empresa, time de Agilidade, Inovação, Negócio & Produtos.

Concebendo a ideia

Antes de vir pro Luiza Labs e de fato atuar na cadeira de Researcher, trabalhei em um ICT (Centro de inovação e tecnologia) e lá lidei principalmente com a criação de novos serviços e negócios para o mercado de inovação. E quando digo inovação, é tudo que está atrelado com tecnologia, dispositivos, aplicativos, novos produtos e etc. Existem verticais de negócios para a idéias serem direcionadas, como Agro, Saúde, Educação, Indústria, TI e Jogos. Para submeter as ideias, cada Product Owner (ou conhecido comumente como Dono do produto/Gestor), submete esses insights por meio de um documento chamado Business Case, que em outras palavras é: Um TCC de negócio (sem zueira);

Sua ideia precisa passar por um filtro de aprovação e o BC agrupa todos os pontos importantes, como: De onde veio a ideia, Como o mercado enxerga isso, Se existem concorrentes, Como ela funcionaria na prática, O quanto ganhamos com essa ideia, Qual o público atacamos e etc.

Tendo isso tudo bem organizado, transformamos em um storytelling para apresentar.

Sendo aprovado, temos outras três fases:

Testar (MVP ou Mínimo produto viável)
Desenvolver (para o Mercado)
Lançar

Isso é o básico, pois dentro de cada um desses épicos (ou principais processos) existem sub-tarefas que precisam ser feitas antes de dar um checkout de etapa concluída.

E foi assim que eu senti a famosa lâmpadazinha de desenho animado se acender bem acima da minha cabeça: Eu precisava criar um fluxo organizacional para desenvolvimento de produto.

Simples assim (só que não tão simples).

Então como todo UX, eu rascunhei um esqueleto do que poderia ser num futuro próximo o Product Process e comecei a entrevistar alguns P.O’s para validar minhas hipóteses.

Nisso, descobri outras dores:

Para novos P.O’s, ainda não estava claro o que era BC ou BP e qual a necessidade disso ser feito;
Quais áreas/etapas eram fixas e cross para apoiá-los no processo de desenvolvimento
Quais ferramentas poderiam ser usadas;
Que pontos de contatos poderiam ser acionados durante cada fase;
Qual o tempo de concepção de cada fase;
Onde encontrar o acervo de projetos aprovados e lançados;
O que era obrigatório ou não;

E assim notei que estava mapeando apenas a ponta do iceberg. Não era simplesmente um processo de workflow que eu precisava criar, mas sim um onboarding acessível que estivesse ligado com o processo principal e como cada área lida com esse fluxo.

Nessa época, eu nem sabia da existência de repositórios, publicações ou qualquer coisa referente a Research Ops ou como fazer isso. Tive que ir em busca de fontes, como:

Empresas com guildas de UX bem estruturadas (com líderes, metodologias);
Compreender como funciona times heterogêneos com multi metodologias aplicadas;
Kanban ou Scrum: Qual fazia mais sentido pra manter esse processo atualizado?
Como engajar não só o time, mas a empresa na utilização desse framework definido como ágil?
Qual metodologia usar para definir o framework e se é de fácil manipulação;

E a questão mais importante: Onde eu desenvolveria isso?

Até o MVP desse framework, demorei 7 meses maturando a ideia, recolhendo insumos, modificando e testando com meu Chapter (a guilda de design de experiência);

Produzindo

Três meses depois de começar o planejamento, compartilhando meus aprendizados com um dos P.O’s que trabalhava comigo, finalmente defini a ferramenta para criar o Product Process versão Omega: Miro.

Para quem não conhece o Miro, é uma ferramenta de criação, gestão e planejamento. Pense em um quadro branco, do qual usava na escola. Pensou? O Miro é a versão digital dele, comumente usado para planejamento de tarefas, mapas mentais, criação de wireframes, eventos de ideação, brainstorming e várias outras coisas.

Vale ressaltar que o Miro foi escolhido por outros fatores além do objetivo de criação do do Product process: Todos os Scrum usavam a ferramenta, logo, ela possuía uma lincença que permitia uma personalização maior do que a oferecida na modalidade Free.

Com a ferramenta definida e a ideia mapeada, o próximo passo era escolher a metodologia de desenvolvimento do framework. Na empresa, não tínhamos auto-gerenciamento, mas sim micro-gerenciamento, já que o detentor disso eram os Scrum alocados por Tribos.

Assim, depois de verificar com cada Scrum e P.O o uso do Miro para desenvolver o Product Process, desenhei o Ômega baseado no Double Diamond, com etapas On Going — Done baseadas no Kanban.

Para quem não conhece, o Double Diamond é uma metodologia usada no Design Thinking destinada para o funcionamento e desenvolvimento de tarefas. Ela possui dois losangos (diamantes) que são divididos em duas etapas cada: O primeiro, Descobrir e Definir; E o segundo, Desenvolver e Entregar. O que fiz foi adicionar para cada etapa, legendas de acompanhamento semelhantes às que são utilizadas no Kanban (Não iniciado, Em andamento e Concluído).

Definir quais eram as seções preenchíveis:

Iniciado por
Nome do projeto
P.O responsável

E cada linha tem uma cor para identificar visualmente a que etapa se refere:

Amarelo para BC (Business Case)
Verde escuro para POC (Teste)
Verde água para MVP
Azul ciano para BP (Business Plan)
Azul marinho para Internalização
Turquesa para Lançamento

Depois de apurar o feedback dos primeiros testes com P.O’s e Scrum’s, percebi que tinha redundâncias de informações e muita segmentação, dando assim origem ao Product Process Alpha:

A diferença desse para o anterior foi o agrupamento das micro etapas em duas grandes: Processo de desenvolvimento - com BC, MVP (unifiquei POC e MVP) e BP em um único bloco; E Processo de Lançamento/Escala - com Internalização e Escala.

Além disso, percebi que seria interessante ter uma nova seção de legendas para a atuação dos capítulos e assim facilitar onde cada cadeira/função poderia ser acionada por demanda.

Não passou muito tempo para que a versão Alpha se tornasse a Beta, com ligeiras atualizações (organização ou adicionar demandas padronizadas) e pronta para se tornar um MVP.

Aqui, organizei melhor as demandas por cada etapa e adicionei uma nova coluna chamada Cross na fase de Desenvolvimento, para alocar aquelas demandas que respingam ou continuam durante toda a fase em um único lugar. Por exemplo: Se a criação e formatação de uma persona fica durante toda a fase de BC e MVP, ao invés de se repetir nas duas fases, ela fica fixa na coluna Cross.

Com isso testado, bem definido e organizado, direcionei minha atenção para a formatação do Onboarding e painel do Product Process no Miro (apresentado na imagem abaixo):

O Product Process tem outras ferramentas alocadas dentro dele e por isso o painel não poderia ser simplesmente um Board avulso.

Por isso a versão final do Product Process Beta é maior, com informações adicionais e principalmente documentações de Onboarding.

Para o onboarding do Product Process, além do PDF com boas práticas, FAQ e explicação de uso (passo-a-passo), criei dois meios de suporte: trilha de vídeos para os P.O’s (Loom) e trilha de mediação para novos Scrum’s (Scribe How);

Atualmente

A pouco mais de alguns meses resolvi revisitar o Product Process e adaptá-lo para uso comum, em uma comunidade aberta, a qual eu escolhi a do Figma.

E por qual motivo, Rai?

Para os Devs, é comum e normal submeter um projeto para acesso comunitário ou colaborativo por meio do Github ou plataformas similares, no mais, o Product Process não é uma interface, mas sim um framework.

E meu público-alvo são Scrum, P.O’s, P.M’s e outros UX.

Eu poderia continuar no Miro mas para compartilhamento e alcance, o Figma é mais inclusivo.

A reestruturação e migração do Framework não foi demorada. O que tive que fazer foi detalhar menos, direcionar mais e mudei o nome de Product Process para Project Process.

Soa até melhor, né? haha.

No Figjam diferente do Miro, ponho um exercício mental para ser feito antes de iniciar o workflow de processos, com uma checklist direcionada especificamente para Project Definition. Esse mapa funciona com perguntas-chaves que ajudam a definir o que precisa ser feito, em que fase precisa ser feito e quais ferramentas é possível utilizar para colher respostas. Além do mais, enxuguei o que antes eram 4 grandes épicos em cinco fases de desenvolvimento. Cada fase possui uma parte dedicada para mensurar possíveis Erros e Acertos, otimizando o agrupamento de feedback por seção, demanda ou ferramenta.

O mais engraçado é que quando imaginei o Product Process, lá no início, ele se parecia muito mais com o do Figjam do que o criado inicialmente no Miro.

Evolução é isso, né?

Objetivo concluído?

Não. Ainda tenho muito a aprimorar e aprender, mas esse Framework me fez perceber o quão bom e necessário foi direcionar uma parte do meu tempo de aprendizado em criação.

Por a mão na prática, errar, aprender, corrigir, receber feedbacks, me fez aprender muito mais em 7 meses do que em 3 anos de migração de carreira de Dev para UX.

Num futuro próximo, imagino o Product Process sendo algo colaborativo e espero que quando esse momento chegar, possa contar com você.

Então, me segue nas redes sociais e dá uma força no Project Process clonando no Figma (link aqui) e até breve!