Projetos são empreendimentos com recursos limitados. Em função disso, sempre é necessário priorizar onde os recursos serão empregados.
No contexto de produção de software, só não há a necessidade de realizar a priorização dos requisitos em projetos onde os recursos são ilimitados.
Mas projetos com recursos ilimitados existem?
Não, obviamente.
E por esta realidade que precisamos escolher o que será “feito primeiro” e o que será “feito depois”.
Não é possível todos os requisitos terem a mesma prioridade. Lembre-se, recursos finitos! 😉
Em projetos em que se acredita que sim, que todas necessidades tem a mesma prioridade, o alto desperdício ou o total desperdício, é uma realidade.
Requisitos e Escopo
Quando falamos em escopo do sistema (não escopo do projeto), estamos falando de requisitos (tanto funcionais quanto não funcionais, e também regras de negócio).
Podemos tratar requisitos com estórias de usuário, requisitos de software, casos de uso etc. Independente do formato, o conceito de priorização se aplica.
A grosso modo, vamos entender como requisito tudo aquilo que deve ser feito no sistema, que compõe o escopo do sistema.
/* Escopo do projeto é algo diferente de escopo do sistema, em projetos de desenvolvimento de software. No escopo do projeto geralmente temos mais coisas além do sistema em si – atividades de infraestrutura, gestão, configuração etc., por exemplo. No escopo do sistema, “que é parte” do escopo do projeto, como citado no parágrafo inicial deste post, o que temos são requisitos, basicamente. Na literatura de Gestão de Projetos, o escopo do sistema é chamado de “Escopo do Produto”, em contextos ágeis, geralmente chama-se “Product Backlog”, ou backlog do produto. */
E escopo, na minha opinião, é disparado o maior desafio nos projetos de software (descobri-lo, priorizá-lo, planejá-lo, executá-lo e controlá-lo).
O Cone da Incerteza nos explica isso melhor (o desafio citado0, mas outros fatores também contribuem para a problemática do escopo; abaixo alguns para exemplo:
Requisitos mal especificados
No início do projeto geralmente os requisitos tem um nível de detalhe muito alto, muito macro.
A partir do início do projeto, à medida que os requisitos vão sendo detalhados, sendo decompostos, o escopo “de verdade” vai aparecendo, e na maioria das vezes não ha tempo de replanejar/recombinar as coisas quando o tempo já passou.
Informações faltantes
Durante a especificação a equipe faz reunião com os usuários, obtêm leis, normas, e-mails etc.
Após a conclusão da especificação, ocorre a validação, e após algumas idas e vindas, o escopo (seja escopo do Sprint, da Iteração ou do Projeto) é validado.
Na hora da “materialização” dos requisitos (quando os software é construído) começa o “puxa, esqueci, tinha isso também” e o “puxa, isso aqui é um pouco diferente do que tínhamos pensado”.
“Dinamismo” dos usuários
Usuários mudam de ideia muito rápido, e gestores geralmente tem dificuldades em dizer não a usuários.
Definir conceitualmente, ou conceber um sistema, é um processo de criação constante; ocorrem definições, revisões e ajustes de escopo a todo momento.
Mas difilmente este mindset (essa mentalidade sobre processo criativo, idas e vindas etc.) é previamente alinhado com o cliente, não há um trabalho de aculturamento do cliente neste sentido (no sentido de que, se mudar toda hora, nunca fica pronto).
Em função dessa característica (volatilidade do escopo) usuários tendem a pedir mudanças frequentemente, com o projeto em execução, geralmente não percebendo o impacto que isso gera.
Gestão e controle inadequados do escopo
Controlar o escopo de um projeto é algo muito difícil, pela própria complexidade inerente.
Soma-se a isso o fato de que gerentes de projeto e analistas sempre estão envolvidos em vários projetos/demandas ao mesmo tempo – o que dificulta muito focar numa única coisa, e pressões externas e internas que sempre existem em qualquer empresa/mercado dificultam ainda mais o foco.
E nesse ambiente desafiador, a ausência de critérios na gestão do escopo do sistema tornam as coisas ainda mais complicadas. Uma forma de diminuir este problema, dando um pouco mais de ordem ao caos, é utilizar a Priorização de Requisitos.
O que é mais importante vem primeiro
Todos nós deveríamos refletir muito sobre a palavra priorização.
Considerando que na vida os recursos são escassos, é fundamental priorizarmos as coisas.
Exemplos facilmente perceptíveis de recursos escassos são dinheiro, tempo e saúde.
E na vida, geralmente fazemos aquilo que queremos, e não aquilo que devemos fazer.
Se analisássemos o que realmente é importante/urgente, com certeza viveríamos melhor, pois faríamos primeiro aquilo que realmente é prioritário.
Se não houvesse limitação/escassez de recurso, todos iriam querer tudo! 🙂
Para muitos profissionais envolvidos em projetos de software – tanto fornecedores quanto clientes – quando o assunto é escopo, não há limitação/escassez de recurso, eles querem tudo… 🙁
Mas não dá para fazer tudo em um projeto.
E para decidir o que deve ser feito com os recursos que sem tem, uma das melhores formas para isso é priorizar os requisitos.
Em termos de método aplicado, a “grosso modo”, estamos falando de criar uma lista com os requisitos, definir uma prioridade para cada um, e os mais prioritários vão para o início da lista, os menos prioritários, para o fim da fila.
Com base na ordem estabelecida, os requisitos vão sendo construídos no sistema.
Priorização dos Requisitos
As prioridades podem ter nomes diferentes conforme a literatura consultada, mas geralmente quando falamos de priorização de requisitos, são utilizados os termos Essencial, Importante e Desejável.
A seguir, o que significa cada um dos termos.
Essencial
Um requisito que realmente é fundamental para o sistema, sem o qual o sistema não pode ser dado como “completo”, ou “apto para produção”.
São requisitos que se não são implementados impedem uma implantação ou a conclusão do sistema.
São compulsórios, não sendo possível aplicar soluções de contorno ou paliativos para eles.
Importante
Um requisito que deve ser parte do escopo, mas não bloqueia o sistema a entrar em produção.
É como se o sistema ficasse com uma “pendência” de escopo – criando débito técnico – que será atendido em momento oportuno.
Sem um requisito importante, o sistema poderá rodar, funcionar, ser utilizado.
Um requisito priorizado com importante pode ser postergado para pós-implantação, ou ser atendido temporariamente por soluções de contorno ou paliativos.
Desejável
Um requisito que não é indispensável para o sistema estar completo, para entrar em produção. Também não é algo que, mesmo postergado, deverá ser feito obrigatoriamente.
Sem um requisito desejável o sistema deve funcionar de maneira satisfatória, atendendo completamente seu objetivo.
Por ser algo que não precisa ser feito para que o sistema esteja completo, é a menor das prioridades, e deve ser postergado para, se for possível, ser viabilizado no futuro.
Quando priorizar os requisitos?
A priorização dos requisitos deve ocorrer, no mínimo, durante a definição do escopo do sistema.
Isso é o mínimo mesmo.
Começar o desenvolvimento com o escopo definido, mas não priorizado, torna fatal a ocorrência de problemas diversos no projeto.
Em projetos ágeis isso deve ocorrer a todo momento, atemporal, na gestão do product backlog.
Em projetos não ágeis, waterfall ou não, a priorização deve ocorrer sempre antes de cada fase, iteração ou slot de tempo semelhante.
Mas priorizar os requisitos apenas no início do projeto não é boa prática.
Sabemos que em projetos de software o escopo é volátil, e muito dessa volatilidade origina-se nos desejos/percepção de valor dos usuários, sentimentos que são descobertos/mudam ha todo momento.
Em função disso, a prioridade dos requisitos também pode mudar. Por isso a necessidade de priorização constante, ou repriorização.
Em projetos baseados em ciclo de vida em cascata (waterfall), colocar marcos no planejamento para revisão da priorização dos requisitos é uma forma útil para manter o escopo mais aderente à realidade do negócio.
Excetuam-se os requisitos que já foram implementados, ou seja, a “repriorização” ocorrerá somente nos requisitos ainda não implementados (requisitos ainda contidos no backlog do projeto).
Salvo raras exceções, não é recomendada a utilização de ciclo de vida em cascata em projetos de software, a abordagem deve ser iterativa e incremental (atualmente com foco em agilidade, geralmente utilizando Scrum).
Em projetos onde o ciclo de vida se baseia neste modelo (iterativo e incremental) a priorização também deve ocorrer no início do projeto (no backlog do produto/lista de requisitos) e também sempre no início de cada iteração, para “repriorização”.
/* Por iteração entenda-se fase, pacote, Sprint ou qualquer outro rótulo empregado a uma iteração de projeto. */
Em projetos onde o ciclo de vida utiliza Scrum, por exemplo, é muito útil nas reuniões de Sprint Planning haver revisão do backlog – onde são avaliados/reavaliados tanto os itens do backlog, quanto o esforço para produção e a priorização definida para cada item.
De um modo geral, é fundamental revisitar as prioridades aplicadas aos requisitos. As coisas mudam muito rápido.
Grande abraço!