Priorizando Backlog com a Técnica MoSCoW

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 no Brasil… (protocolos e blá blá blás cumpridos, vamos ao que interessa)

Prezado leitor, se você me dissesse que está pensando em dar um upgrade na carreira; investindo num treinamento para se tornar um Product Owner, e gostaria, com base na minha experiência, que eu definisse com apenas 3 verbos, o que faz (ou pelo menos deveria fazer) um PO. A resposta de bate pronto seria:

  • Dividir
  • Priorizar
  • Descartar

Como eu sei que estes três verbos soltos não seriam suficientes, farei a seguir uma breve explanação sobre eles. Vejamos:

Dividir: Product Owners eficientes precisam saber como dividir as estórias do Product Backlog. Precisam saber fatiar as estórias, para que elas fiquem pequenas o suficiente a ponto de reduzir, consideravelmente, sua complexidade. (o time tem o dever de ajudá-los nesta tarefa)

Priorizar: Product Owners focados na entrega de valor, precisam categoricamente, priorizar as estórias do Product Backlog. Esta não é uma tarefa trivial. POs precisam estar muito próximos do time e, ao mesmo tempo, muito próximos do negócio (cliente) para que suas decisões sejam cada vez mais assertivas.

Descartar: Product Owners habilidosos devem conhecer o negócio como um especialista. Precisam ter habilidades para negociar com os clientes, features que não são necessárias no momento. POs precisam ser visionários e bons negociadores, a fim de reduzir ao máximo o que costumo chamar de escopo inchado.

Nota: Escopo inchado é aquele escopo em que o cliente solicita funcionalidades, mais ou menos, com a mesma fúria e apetite com que um esfomeado chega à um restaurante do tipo “sirva-se à vontade apenas uma vez…” – manja? – O cabra com medo de ter que pagar duas vezes, vem equilibrando num prato raso, 27 tipos de comidas diferentes… em épocas natalinas, cheguei a ver pratos com “tecos” de panetone enfiados no meio do feijão. 😕 #FomeZeroModeON

Contextualmente em ambientes de projetos, sabemos que alguns clientes (ou vários) se comportam desta mesma maneira (esfomeados); solicitam escopo com um zilhão de funcionalidades, dentre as quais, muitas são funcionalidades exóticas, que além de serem, na maioria das vezes, desnecessárias… custam muito dinheiro. Em situações como esta, somente a astúcia e a poder de negociação de um PO, dirão quais dessas funcionalidades são presente ou serão futuro… ou quem sabe nunca serão… nunca… nunca! #CapitãoNascimentoFeelings

Explicadas e consolidadas as três principais ações que um PO deve fazer, imagino que você meu caro leitor, um eterno curioso como sei que o é, esteja alimentando a dúvida 2.0. Qual seja: “Óh my Lord… um PO deve saber fazer tudo isso, e tudo isso não é fácil fazer… será que em meio a este mundaréu de técnicas, ferramentas e processos, que o mercado adora inventar, não há nada que possa auxiliar um PO a implementar estas hercúleas ações?”

FAQ da dúvida 2.0: Sim. – Utilizando a Técnica MoSCoW.

Conheci teoricamente a técnica MoSCoW, estudando PRINCE2. (PRoject IN Controled Enviroment) Esta é uma técnica muito utilizada para priorização de escopo, priorização de requisitos, classificação de mudanças e etc… Aplicando esta técnica, consegue-se, por exemplo, classificar e priorizar funcionalidades com base no seu valor de negócio.

Atualmente o Dynamic Systems Development Method (DSDM) Consortium possui os direitos de propriedade intelectual da Técnica MoSCoW, os quais foram doados pelo seu criador Dai Clegg. O PRINCE2, por sua vez, recomenda no livro Gerenciando Projetos de Sucesso com PRINCE2 o uso desta técnica em várias fases de um projeto.

A Técnica

O M do MoSCoW quer dizer Must Have (Deve Ter) – Tudo o que é imprescindível para o escopo do projeto. Aquelas funcionalidades CORE da sua aplicação, que sem elas a aplicação perderia totalmente o sentido.

O S quer dizer Should Have (Deveria Ter) – Tudo o que é importante ter no escopo do projeto, mas que não são imprescindíveis. Funcionalidades que se por ventura não forem desenvolvidas, não farão com que o produto perca o seu valor de negócio.

O C quer dizer Could Have (Poderia Ter) – Tudo o que seria bom ter, mas não são importantes. É mais ou menos como a cerejinha do bolo. Na maioria das vezes, clientes aceitam comer bolo sem cereja, até porque, bolos sem cerejas são mais baratos. :mrgreen:

O W quer dizer Won’t Have for Now (Não Terá por Enquanto) – Tudo o que não será desenvolvido por enquanto, pois as features classificadas com won’t have for now, não geram valor de negócio no momento.

Curiosidade: Já vi alguns backlogs e algumas pessoas estranhamente substituírem o W de Won’t Have for Now por Would Have, o que pra mim não faz o menor sentido. O Could Have existe justamente para isso. Funcionalidades classificadas com Could Have muito provavelmente serão desenvolvidas posteriormente (Would).

Vejamos um exemplo de um Product Backlog priorizado com a técnica MoSCoW (deem uma olhada na beleza e na robustez da bagaça) 😀

Screen Shot 2015-11-08 at 4.24.09 PM

A Técnica e as 3 ações (Dividir, Priorizar e Descartar)

Olhando para Product Backlog acima; todas as estórias que têm valor de negócio Must Have deverão ser refinadas. Elas precisam ser entendidas pelo time, fatiadas, quebradas em estórias menores, caso elas ainda não estejam nesta condição. (DIVIDIR) – No exemplo, um sistema de contas à pagar, que não contemple relatórios de contas à pagar com filtro por data; seria um sistema que geraria valor para um cliente? Eu entendo que não…

Todas as estórias que estiverem com Must Have e Should Have são prioritárias, precisam ser desenvolvidas nesta ou na próxima sprint. (PRIORIZAR)

Todas as estórias que estiverem com Won’t Have for Now devem ser descartadas, pelo menos por enquanto. (DESCARTAR) – Voltando no exemplo do nosso Backlog, acredito que um sistema poderia, inicialmente, sobreviver sem a funcionalidade de enviar email de alerta para os usuários, toda vez que uma conta estiver a 3 dias do seu vencimento, concorda?

Algumas vantagens em utilizar a Técnica MoSCoW

  • Num planejamento da release, um PO poderia tranquilamente decidir que todas as estórias que estão classificadas e priorizadas com Must Have e Should Have deverão ser implementadas até a data da release.
  • Um PO poderia, analisando o avanço do projeto, incluir uma estória no Backlog, classificá-la como sendo Could Have e definir que todas as estórias classificadas com este valor de negócio, deverão ser discutidas previamente com o cliente.
  • Um PO empoderado não terá maiores dificuldades em demonstrar redução nos custos do projeto, caso ele tenha classificado algumas estórias como Won’t Have for Now, e tais estórias, posteriormente, se fizeram de fato desnecessárias.

Enfim… existem N benefícios em gerenciar um Product Backlog utilizando-se da Técnica MoSCoW. Certamente esta importante ferramenta facilitará, e muito, a vida e o dia a dia dos nossos POs.

Em tempo: achei interessante uma técnica criada por americanos capitalistas, ser batizada com o nome da capital de um país (Rússia) com tradições e estigmas socialistas. 🙄

Saudações. Ψ

2 comentários em “Priorizando Backlog com a Técnica MoSCoW

  1. Olá Marcos,

    Obrigado pelo feedback. Começar na área é fácil a parte difícil você já fez. Estudar. Sugiro que você analise o que o mercado está pedindo, busque conhecer teoricamente e seja transparente. Tenho certeza que com isso, você entrará rapidamente na área.

    Conte comigo. Abraço!

    Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: