Priorização de Requisitos

Priorização de Requisitos
Só não há a necessidade de realizar a Priorização de 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.

Em projetos em que se acredita que sim, todos tem a mesma prioridade, observe e verá que a probabilidade de sucesso é muito baixa.

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)

Obs.: para entender a diferença entre requisito e regra de negócio, veja este post).

A grosso modo, vamos entender como requisito tudo aquilo que deve ser feito no sistema, que compõe o escopo do sistema. Se quiser saber mais sobre Requisito de Software, veja mais aqui.

/* 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 infra-estrutura, 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”. */

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 (veja aqui sobre o Cone da Incerteza) nos explica isso melhor, 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.

Priorização de Requisitos - eBook sobre Requisitos de Software

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 é validado. Na hora da “materialização” dos requisitos (leia-se projeto, construção, testes etc.) 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 um sistema é um processo de criação constante; ocorrem definições, revisões e ajustes de escopo a todo momento. Mas dificilmente isso é 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, da volatilidade do escopo, usuários tendem a pedir mudanças frequentemente, com o projeto em execução, geralmente não percebendo om 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

Priorização de Requisitos - Kanban Todos nós deveríamos refletir muito sobre a palavra priorização.

Considerando que na vida os recursos mais necessários são escassos, é fundamental priorizarmos as coisas.

Exemplos facilmente perceptíveis de escassez de recursos 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 é importante.

Mas 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. Após a priorização, é importante definir uma ordem de execução para os requisitos com a mesma prioridade.

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 Desejável. A seguir, o que significa cada um destes.

Essencial

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

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. Pode ser simplesmente postergado para pós-implantação, ou ser atendido temporariamente por soluções de contorno ou paliativos.

Desejável

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 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.

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. 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.

Se você quiser tornar-se um Expert em Engenharia de Requisitos e sair na frente no mercado, conheça nosso curso on-line super diferenciado!

Priorização de Requisitos - Curso e Engenharia de Requisitos

Grande abraço!

priorização de requisitos