7 Product Dimensions Pratice
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 e na Empresa… (protocolos e blá blá blás cumpridos, vamos ao que interessa)
Recentemente tive o privilégio de receber na empresa a qual trabalhei, mais uma empolgante e desafiadora missão: passar o time por uma transformação ágil — com Scrum e Kanban (e demais métodos ágeis) — um “novo” projeto de TI de alta complexidade em uma grande multinacional ao qual expandir seus negócios para toda América latina (clientes e funcionários interagindo em várias línguas e metodologias distintas).
O projeto já havia passado da análise de viabilidade quando começamos, onde uma Product Owner, nós do time de desenvolvimento(Engenheros de Software) tomamos 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, SAP, etc. 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 pos venda 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:
- Atores
- Interfaces
- Ações
- Dados
- Regra de Negócio
- Ambiente
- 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. Ψ
Referências:
Scruminc.: Writing Better User Stories
Blog ebg: Requirements to the Rescue: How the 7 Product Dimensions Saved our eBooks
