7 Dimensões do Produto: uma forma eficiente de escrever User Stories

Olá Pessoas,

Antes de mais nada eu gostaria de agradecer o WordPress, por ceder este espaço para que a gente possa, em alto nível, discutir a gestão de projetos (e demais assuntos) no Brasil… (protocolos e blá blá blás cumpridos, vamos ao que interessa)

Recentemente tive o privilégio de receber da consultoria a qual trabalho, mais uma empolgante e desafiadora missão: gerenciar — com Scrum (e demais métodos ágeis) —um “novo” projeto de TI de alta complexidade em uma grande multinacional norte-americana (um de nossos clientes).

O projeto já havia passado do feasibility (análise de viabilidade) quando começamos, uma Product Owner e eu, a tomar conhecimento do escopo macro do projeto. Já na fase de iniciação, entrevistamos algumas pessoas da área de negócio, para entendimento e possível extração de alguns épicos e requisitos que serviriam para criação do Product Backlog, norteando, inclusive, o planejamento da primeira release.

Para se ter dimensão da complexidade da “brincadeira”, o escopo deste projeto contempla desde a criação de novas aplicações para interfacear a comunicação e troca de arquivos entre duas empresas, até a restruturação de sistemas legados e mainframes… além do redesenho de vários processos incluindo uma robusta ferramenta de BPM. Para atender as demandas de negócio, criamos 6 Product Backlogs diferentes, sendo 6 áreas da empresa impactadas diretamente pelo projeto. Está previsto ainda a formação de 3 Times de Desenvolvimento trabalhando nesses PBs ao longo de todo o projeto. Frise-se que a elevada complexidade fez com que este projeto, num passado não muito distante — utilizando-se de uma abordagem “tradicional” (waterfall) — fosse cancelado após 6 meses de execução por estouro de budget. Este fatídico episódio, por si só, faz com que a carga de expectativas colocada sobre a costas do time atual do projeto e o desafio, aumentem ainda mais. Por outro lado, porém, temos a nosso favor importantes e valiosas lições aprendidas.

Dada a já exposta complexidade do projeto, o tamanho do escopo e a quantidade de pessoas que de certa forma seriam necessárias para iniciar a escrita de user stories, decidimos que seria mais produtivo — ao invés de workshops de escrita de user stories — utilizarmos uma técnica mais estruturada para este fim; conhecida como 7 Dimensões do Produto.

Conheci as 7 Dimensões do Produto em uma apresentação organizada pelo Jeff Sutherland, sendo ele mesmo quem apresentara o funcionamento da técnica. Posteriormente pude comprovar sua eficiência, ao aplicá-la na criação de um Product Backlog inicial de um projeto de desenvolvimento de um aplicativo móvel que participei.

A Técnica

Basicamente esta técnica tem como objetivo, facilitar o levantamento de informações fundamentais para a criação de um produto, analisando-o sob 7 dimensões (aspectos) diferentes, a saber:

1. Atores
2. Interfaces
3. Ações 
4. Dados
5. Regra de Negócio
6. Ambiente 
7. Qualidade

A seguir, vamos entender o que quer dizer cada uma dessas dimensões:

Nota: Utilizarei como exemplo, a construção de um aplicativo móvel para ler um jornal digital. 

Atores

Atores (personas) são todos os usuários que de alguma forma interagem com o produto. Exemplo:

• Leitores de jornal digital para tablets. 

Nota: Dependendo da sua necessidade, um usuário pode ser um sistema que interaja com a tua aplicação.

Interfaces

Interfaces são todas as telas, fluxos ou aplicações que precisam ser construídas para atender a uma necessidade de negócio. Exemplo:

• Interface contendo uma biblioteca atualizada com as edições de um jornal digital.
• Interface para comprar uma assinatura de um jornal digital 

Ações

Ações (verbos) são tudo o que os usuários desejam fazer ao interagir com a aplicação. Exemplo:

• Comprar uma edição do jornal digital
• Comprar assinatura mensal do jornal digital

Note que neste momento, já podemos dar forma a algumas user stories ou épicos… por exemplo:

Dados

Dados são qualquer input, arquivos, dados da base e etc… que são fundamentais para o funcionamento da aplicação. Exemplo:

• Jornal digital (PDF, HTML)
• Banner informativo
• Dados de pagamento (cartão de crédito)

Regra de Negócio

Regras de negócio servem para suportar as necessidades de negócio… elas devem ser implementadas na aplicação. Exemplo:

• As edições avulsas só poderão ser compradas via cartão de crédito 
• Os assinantes do jornal digital, só poderão ter acesso às edições posteriores à data da adesão.
• Os assinantes que completarem 1 ano de assinatura, ganharão 1 mês de isenção da mensalidade.

Ambiente

Ambiente é (ou são) todas as plataformas, ou sistemas que serão utilizados para suportar a aplicação. Exemplo:

• Aplicação WEB com suporte para flash
• Android 
• iOS

Qualidade

Qualidade é (ou são) todos os requisitos que precisam ser contemplados em uma aplicação, para atender as necessidades dos usuários. Exemplo:

• A leitura do jornal poderá ser feita offline. 
• O leitor poderá escrever anotações nas matérias. 
• O leitor poderá incluir uma matéria, ou edição nos seus favoritos. 
• O zoom será de 4x o tamanho original
• O tempo máximo de download de uma edição é de 5 segundos.

Com estas 7 dimensões mapeadas já podemos, por exemplo, extrair requisitos funcionais e não funcionais:

Com as informações levantadas em cada dimensão, clientes, negócio e TI poderão escrever poderosas user stories, além de definir importantes critérios de aceitação:

Enfim esta é uma técnica que facilita, e muito, a vida de um Product Owner que deseja gerenciar o seu Product Backlog e se comunicar de forma produtiva com os clientes e com o Time de Desenvolvimento… recomendo fortemente o seu uso pois, todas as vezes que a utilizei, tive como saída, excelentes user stories e feedbacks bastante positivos dos envolvidos. 🙂

Espero ter ajudado…

Saudações. Ψ

Foto com a técnica implementada no projeto que mencionei no post… 🙂

Referências:

Scruminc.: Writing Better User Stories

Blog ebg: Requirements to the Rescue: How the 7 Product Dimensions Saved our eBooks