No artigo anterior, falei sobre a importância da Inception para as demais fases do projeto. Agora é hora de entender como ela funciona e quais as ferramentas utilizamos para conduzir o método, extraindo o máximo de informações que servirão para nortear as próximas fases.

Neste artigo, você verá o passo a passo de como o Scrum Master da upFlow.me conduz a reunião, empregando ferramentas do Design Thinking, Brainstorming, Product Management, Coaching, entre outras.

Sabemos que o tempo é valioso, portanto, tentamos extrair valor de forma rápida. As reuniões duram aproximadamente um dia, e ser for necessário, estende-se para mais um.

• Agenda lean

Segue abaixo um exemplo simples da agenda Inception que normalmente adotamos por aqui:

09:00 Abertura/Apresentações
09:30 Visão do Produto (Elevator Pitch)
10:00 É, não é, faz, não faz
11:00 Map. Do processo (Timeline)
12:30 Almoço
14:00 Mapa de empatia
16:00 Matriz Impacto x Esforço
17:00 Encerramento do dia

• Apresentação

Pode parecer clichê, mas o time que participará durante todo o evento precisa se sentir à vontade desde o início, portanto, a ideia é quebrar um pouco do gelo entre os participantes do cliente e os facilitadores da upFlow.me, sempre de forma descontraída.

É importante que todos falem, pois, isso auxilia os participantes mais tímidos para que não se sintam reprimidos pela presença de seus gestores ou pessoas desconhecidas. O time bem entrosado e participativo ajuda a garantir um evento produtivo!

• Visão do produto

A dinâmica da Visão do Produto (baseada na atividade Elevator Pitch) busca promover o alinhamento de toda a equipe em relação a solução/projeto que será trabalhado. Respondendo à algumas perguntas simples é possível ter o direcionamento sobre:

• Quem é o principal beneficiado da solução?
• Quais os principais problemas atuais?
• Qual será o tipo/categoria da solução?
• Qual o benefício que a solução irá proporcionar?
• Qual o método utilizado atualmente e que será substituído pela nova solução?
• Qual é o principal diferencial competitivo que essa solução irá proporcionar a empresa?

Com estas respostas é possível formular uma única sentença, que resume todo o projeto. Ela se torna a referência para as decisões que serão tomadas em relação ao escopo e funcionalidades da solução.

 

Como a definição do Elevator Pitch, conseguimos uma frase pra contar rapidamente para alguém no elevador sobre o que estamos trabalhando.

• É, não é, faz, não faz…

 

É muito importante que o escopo do projeto seja conhecido pelos participantes. Essa ferramenta auxilia na definição do que podemos chamar de “limites” do projeto.

 

De maneira natural, sempre falamos do que a solução faz, como ela irá funcionar, etc. Mas quase nunca discutimos sobre o que ela não será capaz de fazer. E é justamente aí que se encontra o grande problema da gestão do escopo. Não existe nada óbvio. É necessário restringir também as funcionalidades que não serão cobertas pelo escopo.

 

Aqui temos muita discussão entre o time. Muitas definições de negócio são necessárias e também as premissas técnicas que devem ser seguidas.

 

• Map. do Processo (Timeline)

O mapeamento do processo consiste em construir um desenho do fluxo do processo para orientar as discussões sobre as atividades e as personas envolvidas no processo. É importante entender todas as interações e possibilidades que serão consideradas na solução. Estabelecer o início e o fim do fluxo também são pontos cruciais para alinhar as expectativas de todos os envolvidos.

Nessa fase começam a surgir as primeiras discussões sobre protótipos de telas, relatórios e outras ferramentas que os usuários irão interagir na solução. É a hora em que a criatividade começa a aparecer.

• Mapa de Empatia

Praticar a empatia é algo difícil, porém necessário. Principalmente nessa fase.

Utilizamos essa ferramenta para avaliar as expectativas de cada persona envolvida no processo. Entendemos para cada um deles quais são suas dores diárias (principais problemas) e os ganhos (melhorias) esperados.

Após isso fazemos a relação entre os artefatos do sistema que serão propostos na solução e se esses serão adequados para solucionar os problemas.

Finalizamos esse momento com a construção das estórias de usuário. São frases que contam sobre cada interação de cada persona com o sistema, escritas em formato de uma ‘estória’. Isso orienta o time técnico sobre qual a expectativa que cada usuário (persona) terá ao utilizar o sistema e as suas ações possíveis.

• Matriz Impacto x Esforço

O conceito de MVP (Produto Mínimo Viável) é importante para orientar o time durante essa etapa. É ter a clareza de que poucas atividades bem priorizadas já podem começar a resolver os principais problemas dos usuários.

Com isso utilizamos a matriz de impacto versus esforço para auxiliar nessa decisão. Consideramos as atividades mais prioritárias aquelas que possuem alto impacto em relação a Visão do Produto (definida anteriormente) ao mesmo tempo que demandam baixo esforço (técnico, investimento, tempo, etc.). Essas devem ser as primeiras estórias que serão desenvolvidas nas sprints.

A partir disso seguimos a priorização pelas estórias que também possuem alto impacto, entretanto demandam alto esforço para execução. Na sequência as estórias de baixo impacto, começando pelo baixo esforço e finalizando pelas estórias de alto esforço.

A priorização de cada uma dessas atividades pode ser alterada futuramente, conforme a necessidade do projeto.

• Critérios de Sucesso

Obviamente existe muita expectativa em relação ao resultado que o projeto trará. Mas como é possível medir esse sucesso?

O time precisa definir qual será a métrica utilizada para assegurar que a solução obteve êxito. Ter uma meta SMART (específica, mensurável, atingível, relevante e com prazo) desafia a todos não só executarem o projeto, mas também garantirem a implementação e sustentação após o desenvolvimento da solução.

• Encerramento do dia

É o momento de ter o retorno dos participantes sobre toda a dinâmica construída ao longo do dia. O time precisa sair do evento Inception confiante de que a solução construída conseguirá atender as expectativas de todos os envolvidos.

Ufa! O dia é longo, não é mesmo? Porém, determinante para desenvolvimento da solução. A experiência colaborativa começa desde o início e não é diferente nas demais fases de projeto.

Artigo escrito por: Dyego Lemos e Lorrayne Chacon

Leia Também: Como evitar que seus Projetos Software vire uma Bomba Relógio