Um dos grandes desafios de qualquer project manager ou até mesmo, de um Product Manager
Todo desenvolvimento ágil, seja realizado como projeto ou como produto, tem seus desafios diários. Um dos que sinto, diariamente, como um dos maiores é gerenciar o escopo. Antes de começar, vamos inicar citando as diferenças entre o escopo de produto e escopo de projeto. Qualquer confusão é compreensível, principalmente porque o escopo do projeto e o escopo do produto trabalham juntos de algumas maneiras.
Disclaimer: Como citei no artigo anterior, que você pode conferir clicando aqui, “mesmo o gerente de projeto mais empolgado vai reconhecer que fixar o orçamento, o escopo e a data de entrega de um projeto é uma abordagem muuuuuito otimista para o cenário complexo que ele possivelmente representa”
Escopo: projeto x produto
O escopo do projeto foca no trabalho para entregar um produto ou serviço. No escopo que se define claramente o que está e o que não está incluído no projeto. Basicamente, refere-se a tudo o que é necessário para organizar a produção ou implementação de um bem ou serviço.
Podemos imaginar que o escopo do projeto contém o trabalho necessário para chegar a um produto final. Não inclui como o produto real funciona, mas sim quais ferramentas, equipamentos ou processos serão necessários para os gerentes entregarem o produto. Nesse sentido, o escopo do projeto e o escopo do produto estão vinculados um ao outro: você não pode considerar as entregas do produto (escopo do produto) sem considerar as várias tarefas ou etapas necessárias para chegar a esse ponto (escopo do projeto).
Já no escopo de produto, podemos encontrar um conjunto de características e funções que descrevem um produto, serviço ou resultado. Seja considerando design, função ou componentes, o principal a se considerar é que o escopo do produto se refere ao produto tangível real.
Um exemplo de escopo do produto seria: Em um projeto para construir um novo aplicativo de software, o escopo do produto é “um novo aplicativo que atende aos requisitos de nossos clientes internos e externos”. Para determinar se o projeto atingiu com sucesso o escopo do produto, comparamos a aplicação resultante com o documento de requisitos e a declaração do escopo do projeto.
O desafio começa aqui
Ao construir software, há sempre o desejo de querer mais. Seja um melhor desempenho, mais recursos do produto ou qualquer outra coisa que se desvie do roadmap original, o escopo do projeto original será colocado na mesa e diretaente encuralado. A introdução de qualquer um deles após a criação de um backlog inicial pode fazer com que um projeto ultrapasse o orçamento e/ou além do prazo inicial, se não for gerenciado adequadamente.
As alterações em seu backlog ou roadmap em si não são necessariamente ruins. Ágil suporta mudanças. Se os dados(o principal fator, lembra disso) ou o feedback do cliente (importante? sim! mas pessoas também mentem né?!) agora mostrarem que novos recursos são mais importantes para implementar do que outros, eles devem ser implementados. Mas isso também significa que é preciso ter uma conversa difícil. Outros recursos devem ser aprimorados, os cronogramas devem ser alterados ou a alocação de recursos pode precisar ser alterada.
E assim, todos os papéis envolvidos diretamente no desenvolvimento vão precisar ir além. Seja o Product Owner, para alinhamento e formalização do trabalho, juntamente com a priorização. Os desenvolvedores, executando mais trabalho. O time de QA aumentando testes e validações. Enfim, a cadeia de profissionais é diretamente “afetada” com certas decisões.
Como minimizo os efeitos disso?
Vamos imaginar uma situação extremamente hipotética, que dificilmente (cof!) acontece ou vai acontecer na sua empresa: Topdown!
Alguém, área comercial, operação, diretoria, enfim, alguém pediu uma feature urgente que precisa necessáriamente entrar na próxima sprint (se você usar sprints). Você, responsável pela gestão do time, absorve e avalia a informação junto ao time. O time já esta limitado pelo WIP com muitas demandas ao mesmo tempo.
Qual a solução? Simples: cancelar algo em desenvolvimento e incluir a nova.
Raramente a solução é essa né? a solução simples.
Como você pode evitar que isso aconteça? Como você pode evitar que esses pequenos passos na direção errada resultem em uma situação que sobrecarrega sua equipe e retarda o progresso do seu produto?
Roadmap público
Podemos citar que a transparência (salve scrum) pode ser vantajosa. O roadmap do seu produto refletirá tanto seu plano estratégico para o produto quanto as realidades em que sua equipe trabalhará em termos de recursos, orçamento e restrições de tempo. Quando todos em sua equipe multifuncional puderem ver essa visão de alto nível dos planos, prioridades e pensamento estratégico do seu produto, eles estarão mais propensos a entender como uma solicitação para o que pode parecer um pequeno adicional de funcionalidade terá, na realidade, que interromper alguma outra parte do progresso do produto. Portanto, quanto mais frequentemente você compartilhar seu roadmap de produto com sua organização, mais claro será para todos que seus recursos para este projeto não podem permitir o aumento do escopo.
Caracterize e defina o que pode ser considerado
Existem tipos óbvios e fáceis de detectar. Uma ideia leva a outra, e outra, e outra. Você não pode desenvolver todas essas features, nem no tempo que tem ou com o número de recursos da sua equipe. Mesmo que algumas pessoas ainda tentem te persuadir para se envolver nisso. Mas existem formas mais sutis de evitar o aumento de escopo. Uma das maneiras mais sorrateiras que o aumento do escopo pode entrar no seu processo de desenvolvimento de produto é quando ela vem disfarçada de outra coisa, como “melhorar ou atualizar” algo que você já concordou. Portanto, você precisa definir para sua equipe exatamente o que cada etapa do seu plano inclui. Alguma coisa fora ou além daquele plano original? Você pode tratar como uma solicitação de alteração e revisar o escopo? Mas a menos que você dê a luz verde, seu escopo segue o mesmo.
Monitore constantemente
Perder de vista o seu plano estratégico original e as prioridades que você definiu para o seu produto pode ser a porta de entrada seu escopo sair dos trilhos. Portanto, consulte regularmente o seu plano estratégico. Abra o roadmap do seu produto com frequência e compartilhe com sua equipe, para que todos possam permanecer conectados ao pensamento estratégico original e revisar regularmente o trabalho diário em que estão envolvidos.
Menos é mais
Em um mundo ideal, um mundo sem orçamentos, prazos ou clientes esperando ansiosamente por um produto acabado que eles possam comprar não existe. Infelizmente, porém, você sempre estará trabalhando contra o relógio (e a equipe de vendas/operação/diretoria), então você precisará que seus desenvolvedores não cheguem à perfeição e façam o melhor trabalho que puderem no tempo que eles tiverem. Por mais difícil que possa parecer, às vezes, seu produto precisará ser tão bom quanto sua equipe conseguir antes do lançamento.
Espero que esses pontos possam ajudar você, deliver que acompanhou o post até aqui, a melhorar a gestão do escopo do seu projeto/produto, e no mínimo, desencoragem interferências, no mínimo, inapropriadas.
Referências
https://productschool.com/blog/product-management-2/scope-shaping-principles-product-managers/
https://www.villanovau.com/resources/project-management/product-scope-vs-project-scope/
https://www.mindtheproduct.com/yes-product-managers-should-project-manage/
