Artigo do BLOG

Co-Creation PDD (Product Discovery & Design)

O “Co-Creation PDD” (Product Discovery & Design) é um conjunto de técnicas que compreende a execução sequencial das seguintes etapas, num modelo de imersão junto aos usuários-chave de negócio e equipe técnica:

  • Concepção – Lean Inception (1 semana)
  • Preparação (1 semana)

Na etapa de Concepção, realiza-se um workshop de descoberta de escopo chamado “Lean Inception” (descrito por Paulo Caroli), uma abordagem em constante utilização no mercado para contextos de inovação em software ou desenvolvimento e evolução de novos produtos. Esta alternativa é frequentemente utilizada com o intuito de prover as “funcionalidades certas” sendo “concebidas para o momento certo” (quando efetivamente se mostram necessárias) e “pensadas/ desenvolvidas pelas pessoas certas” (ou seja, por quem realmente entende as questões de negócio e técnicas envolvidas).

Guiado por uma sequência de dinâmicas que combinam práticas enxutas e ágeis, além de Design Thinking, o resultado final da Concepção frequentemente é descrito como algo surpreendente, rico e valoroso.

Abaixo, ilustramos algumas atividades da Lean Inception, para que você entenda um pouco melhor como funciona a sua aplicação e quais são os seus principais benefícios:

  • Problemas, Oportunidades e Expectativas: atividade de “KickOff” que visa o alinhamento e o foco dos envolvidos a respeito dos problemas e oportunidades a serem tratados, desdobrando-os em expectativas antes de efetivamente iniciarem os trabalhos (Figura 1).
Figura 1 – Dinâmica “Problemas e Oportunidades => Expectativas”

  • É/ Não É, Faz/ Não Faz: atividade de brainstorming e expansão do pensamento sistêmico a respeito “do quê” o produto vislumbrado “é”, o que ele “não é”, o que ele “faz” e o que ele “não faz”, propiciando assim, uma visão clara e alinhada de “escopo” e “não-escopo” do projeto logo no início do mesmo (Figura 2).
Figura 2 – Dinâmica “É/ Não É – Faz/ Não Faz”
  • Visão do Produto: simples e ao mesmo tempo “desafiadora” e importante, esta atividade orienta a estratégia do produto e serve de referencial para qualquer coisa que se pretende derivar ou fazer no mesmo (Figura 3).
Figura 3 – Dinâmica “Visão de Produto”

  • Objetivos: o foco é fundamental para a priorização e também para o sucesso de um produto de software, logo, nada mais certo do que focar nos objetivos pelos quais os usuários utilizam a aplicação antes de sairmos desenhando funcionalidades que talvez nunca sejam utilizadas por eles (Figura 4).
Figura 4 – Dinâmica “Objetivos”

  • Personas: pensar em quem vai efetivamente usar a aplicação (seus principais usuários) é um fator determinante para o design e o sucesso de qualquer produto, e por isso, é uma prática comum avaliarmos a experiência do usuário na perspectiva de empatia e juízo de valor (Figura 5).

Envolvendo estereótipos, frequentemente esta é uma atividade útil, divertida e esclarecedora…

Figura 5 – Dinâmica “Personas”

  • Features: neste ponto, passamos por um ponto óbvio, mas normalmente relegado à segundo plano no contexto de desenvolvimento tradicional de produtos: “pessoas utilizam funcionalidades com objetivos específicos, os quais devem estar alinhados com a visão e propósito do produto” (Figura 6). Lembrando apenas que o conceito de feature aqui demonstrado é de “necessidade” ou “recurso” (algo como “funcionalidade em alto nível”).

Engloba outras duas dinâmicas não detalhadas aqui, que servem para validar a proposição de valor e esforço, e a certeza de negócio e técnica (ou seja, que se tem do quê e como fazer).

Figura 6 – Dinâmica “Features”

  • Jornadas: a melhor forma de fazermos a “prova-real” do trabalho realizado é verificar os objetivos versus personas, ou seja, as jornadas, em relação às features mapeadas (Figura 7). Desta forma, conseguimos validar se o fluxo e as funcionalidades atendem satisfatoriamente as expectativas de negócio e a “Visão de Produto”.

Novas features podem ser descobertas ou features antes levantadas podem ser descartadas, uma revisão que garante que o produto terá somente funcionalidades úteis ao negócio.

Figura 7 – Dinâmica “Jornadas”

  • Sequenciador de Features: chamada assim devido à distribuição de features em ondas (as quais não necessariamente representam iterações, já que não estamos assumindo que a execução será agile, Scrum, Kanban ou tradicional), sua função é priorizar o Backlog e definir porções de valor e esforço “balanceadas” ao longo do desenvolvimento do projeto de software (Figura 8). Desta forma, a “Visão de Produto” se cumpre ao longo do tempo, em porções de valor graduais e constantes, iniciando pelo que agrega valor e avançando em pacotes de entrega passíveis de demonstração e validação. Estes pacotes são chamados MVPs (Minimum Viable Product), conceito herdado do Lean Startup e que remete a execução de ciclos de construção, validação e aprendizado constante.
Figura 8 – Dinâmica “Sequenciador de Features”

  • Trade-Offs: já que pensamos nos requisitos funcionais, é importante também atuar na perspectiva dos requisitos não funcionais alinhados com a “Visão de Produto” delineada, e para isso, a dinâmica “Trade-Offs” acaba por ser muito útil, pois os principais requisitos não-funcionais são discutidos, alinhados e priorizados, servindo assim também, como norteadores do desenvolvimento da solução (Figura 9).
 Figura 9– Dinâmica “Trade-Offs”

A sequência de atividades acima detalhadas fornece uma visão completa do que se requer de um produto de valor e de vida longa, tipicamente, numa visão de desenvolvimento que cobre projetos entre 3 e 8 meses de execução. A própria execução da dinâmica, e também, a expertise do facilitador destacado, têm papéis fundamentais neste direcionamento, visto que eles mitigam riscos relacionados ao desperdício, seja de planejar demais antes de iniciar ou de planejar algo que está muito além do que pode ser visualizado ou deveria ser vislumbrado no momento (já que as organizações e o mercado são dinâmicos).

Pode ser útil gravar um vídeo-resumo do workshop, como documentação do escopo que pode ficar acessível para consultas futuras.

Ao final da Concepção, executa-se a atividade denominada “Show Case”, para apresentação e validação de todo o trabalho realizado pelos envolvidos e encaminhamento dos próximos passos, fechando assim, a sequência de 5 dias dedicados ao workshop.

Diferentemente da abordagem padrão da Lean Inception, que envolve todo o time técnico, em algumas situações específicas, como da montagem do time (onde as tecnologias envolvidas no produto podem depender das features mapeadas), pode ser mais viável considerar apenas a presença de alguns perfis-chave da equipe técnica, como por exemplo, um facilitador, um arquiteto, o PO e um profissional de UX.

Por sua vez, a etapa de Preparação (Planejamento), que é sequencial à primeira, contempla, idealmente, a realização das seguintes atividades (que podem ser executadas em paralelo):

  • Arquitetura
    • Definir arquitetura técnica (contexto e tecnologias, além do direcionamento para ambientes)
  • Funcionalidades
    • Elaborar protótipo funcional/ wireframe

É importante citar que são realizadas nesta etapa também, as seguintes atividades:

  • “Facilitar e gerir entregas”, sob responsabilidade do Facilitador
  • “Organizar conteúdo da Inception“, sob responsabilidade do Facilitador
  • Show Case” (para nova confirmação dos resultados, com base nos novos direcionamentos)

Aqui encerram-se as atividades de co-criação que dão início ao projeto ou produto e inicia-se a sua execução, onde o time técnico e o negócio continuarão colaborando em ciclos de construção, feedback e aprendizado.

Num próximo artigo, irei mostrar como realizar a etapa de Execução, MVP por MVP, feature por feature… espero que tenham gostado deste artigo!

Share on linkedin
LinkedIn
Share on facebook
Facebook
Share on whatsapp
WhatsApp
Share on email
Email
Nossos Colunistas