Priorização de Requisitos

Priorizar é uma questão de viabilizar as coisas - o que prioritário vem primeiro, o que não é, espera

Compartilhe!

Priorização de RequisitosProjetos 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.

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

prioridade de requisitos

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

Se você quiser tornar-se um Expert em Engenharia de Requisitos e entender tudo de priorização de requisitos, conheça nosso curso online super diferenciado!

curso-engenharia-requisitos-desconto-200-reais-vagas

Grande abraço!

priorização de requisitos