A promessa do gerenciamento de requisitos
A gestão de requisitos é descrita como chave para diversas
disciplinas: Engenharia de Software, Arquitetura Corporativa, Maturidade de
Processos e Análise de Negócios. Todos tentam implementa-la, mas raros são os
casos de êxito.
Muitas organizações por onde passei como consultor ou
instrutor sonham com uma gestão de requisitos eficiente e bem estruturada. Vi
diversas iniciativas sendo executadas para elaborar templates de artefatos
detalhados que fossem capazes de armazenar todas as informações relevantes a
uma empreitada e com isso diminuir conflitos entre clientes e fornecedores e
evitar o retrabalho.
As principais expectativas das organizações que investem em
gerenciamento de requisitos é o alcance desses 4 objetivos:
1.
Garantia
de retorno sobre investimentos através de um processo de validação prévia
das iniciativas a serem realizadas com objetivos mensuráveis e bem definidos
que possam ser perseguidos durante e aferidos ao final dos projetos.
2.
Retenção
do conhecimento do negócio em uma base de conhecimento que permita que a
equipe cliente não fique dependente dos fornecedores que construíram a solução,
nem precise fazer engenharia reversa de código fonte para poder entender quais
são as regras de negócio vigentes ou como o fluxo de atividades acontece de
fato no processo.
3.
Definição
clara do escopo dos projetos gerando acordos inequívocos entre clientes e
fornecedores para reduzir o desgaste nas etapas avançadas dos projetos,
garantir o cumprimento de prazo e permitir o controle de qualidade.
4.
Análise do
impacto de cada mudança sobre os ativos de processos organizacionais
atuais, identificando inclusive quais novos ativos precisarão ser criados,
quais podem ser reaproveitados e quais precisam ser modificados. Esta análise
permite acelerar bastante os projetos de manutenção eliminando o trabalho de reespecificar
algo que já existe, apenas sendo necessário descrever as mudanças necessárias em
uma nova versão.
Gerenciamento de Requisitos no Guia BABOK
Para alcançar estas expectativas, um conjunto de 5 tarefas é
descrito no Guia BABOK® v3 na área de conhecimento “Gerenciamento do Ciclo de
Vida dos Requisitos”:
· Manter Requisitos
· Priorizar requisitos
· Avaliar mudanças de requisitos
· Aprovar requisitos
A realização dessas tarefas sobre um repositório
centralizado de requisitos, com acesso a todos os envolvidos deveria ser capaz
de cumprir as promessas do gerenciamento de requisitos e atender às
expectativas descritas anteriormente.
Todavia, a maior parte das organizações que enveredam nesta
empreitada tem resultados bem aquém do esperado.
Erros mais comuns
Existe uma tendência a focar todos os esforços da gestão de
requisitos na especificação e manutenção de requisitos funcionais e não
funcionais em projetos de desenvolvimento ou manutenção de sistemas de TI. Este
foco auxilia no alcance de sucesso no objetivo 3 (Definição clara do escopo),
mas em geral falha nos outros 3. O motivo está em um entendimento equivocado
sobre o que são requisitos e na forma de organizar seus repositórios para a
gestão.
Há diferentes formatos de requisitos e estes devem ser
mapeados e armazenados de forma diferente. O foco excessivo nos requisitos funcionais
e não funcionais, com uma perspectiva exclusiva de TI, deixa indefinido o
modelo de negócio, seus processos, definições e regras, que normalmente só
existem na cabeça de alguns poucos privilegiados, e muitas vezes há uma inconsistência
tremenda sobre o entendimento de cada um.
O modelo padrão para a especificação dos requisitos,
normalmente definido em um template, abrange apenas um subconjunto dos tipos e
formas de mapeamento de requisitos. Processos de garantia da qualidade obrigam
os analistas a documentarem sempre da mesma forma, mesmo que a documentação não
agregue nenhum valor. Formas alternativas de documentação são raramente
avaliadas.
A forma de trabalho mais comum é pensar na gestão de
requisitos apenas considerando o ciclo de vida dos projetos. Mesmo que exista
um repositório representando o produto (Em vez de “produto” sua empresa pode
usar outro termo como solução de negócio, processo, serviço, capacidade ou
sistema. Por favor, generalize.), a cada projeto de evolução neste produto uma
nova especificação é gerada contendo apenas as mudanças envolvidas no projeto.
Esta especificação é adicionada ao repositório do produto a fim de “reter o
conhecimento” agregado. Contudo o resultado deste esforço não é uma documentação
completa e atualizada do produto, mas sim uma infinidade de documentações de
projetos inútil para o entendimento do todo.
Algumas empresas se propõem a manter uma documentação
atualizada dos produtos, mas esta atualização só é realizada nos projetos grandes.
Pequenos ajustes ou manutenções evolutivas ficam de fora desta obrigação. Mesmo
as mudanças negociadas durante o desenrolar de um projeto não são atualizadas
na documentação. Com isso, a documentação fica sempre desatualizada e cai no
descrédito.
Dimensões do gerenciamento de requisitos
Para conquistar os diferentes objetivos do gerenciamento de
requisitos é essencial classificar os requisitos sobre duas diferentes
dimensões:
· Dimensão 2: Necessidade x Solução
Dimensão 1: Projeto x Produto
Projetos e Produtos possuem Ciclos de Vida diferentes.
Projeto, como você já sabe, é um empreendimento temporário que mobiliza
recursos para criar um resultado exclusivo. Este resultado pode ser a criação
de um novo produto ou a modificação em um produto já existente. Veja que, um
produto sofre evolução a partir de diversos projetos durante o seu ciclo de
vida.
Quando um requisito é especificado, ele pode ser feito no
contexto de um projeto, ou no contexto de um produto. Veja os exemplos:
· Contexto de produto: “Cadastrar clientes com nome, telefone, data de nascimento e email.”
No primeiro caso, o verbo incluir indica uma ação que deverá ser realizada uma única vez pela
equipe do projeto, durante o tempo de vida do projeto, provavelmente uma
melhoria em um produto atual que é algo que faz parte do escopo desta
iniciativa.
No segundo caso, o verbo cadastrar refere-se a uma função presente no produto, que é
executada por um usuário ou sistema automatizado e que será realizada várias
vezes enquanto este produto existir.
O exemplo que usei aqui é bastante simples pois o objetivo
disso é ser didático. Poderia dar outros exemplos em outros níveis de
requisitos ou utilizando técnicas mais elaboradas de modelagem, mas o
importante é que você entenda que há duas formas de se escrever requisitos e as
duas são importantes. Uma delas orienta a equipe do projeto a saber o que precisa ser feito. A outra orienta a equipe
de operação e retém o conhecimento sobre o produto.
Dimensão 2: Necessidade x Solução
Projetos e Produtos são criados e mantidos para atender
necessidades de negócio. Entenda necessidade
como um problema a ser resolvido ou uma oportunidade a ser explorada. Uma solução é uma maneira específica de
atender a uma ou mais necessidades dentro de um contexto.
Idealmente iniciamos um projeto pelo entendimento das
necessidades e, a partir delas, identificamos diferentes alternativas de
solução. Em seguida detalhamos aquela solução que melhor atende às necessidades
considerando todas as restrições do contexto atual. Eu disse “idealmente”
porque (quem tem um pouco de experiência sabe disso) grande parte dos projetos
são criados para desenvolver uma solução já pré-definida em algum processo
difuso de análise de negócios não documentado e que supostamente já ocorreu “em
algum lugar do passado”.
Projetos criados desta forma não descrevem objetivos com
ênfase no atendimento de necessidades, mas sim no desenvolvimento de soluções.
Exemplo de objetivo
com ênfase na solução: “Criar sistema XPTO”.
Quais foram as necessidades que demandaram este sistema?
Ninguém sabe. Ou sabe, mas não está escrito em lugar nenhum. O fato desta
informação não estar disponível impede aos envolvidos no projeto de fazer as
seguintes perguntas:
– “Este sistema que
estamos desenvolvendo atende às necessidades que o criaram?”
– “Esta é a melhor
forma de atender a estas necessidades?”
No contexto do Gerenciamento de Requisitos, considere que
requisitos englobam tanto a representação de necessidades quanto de soluções
(design). Ambas podem ser identificadas e mantidas pois ambas podem agregar
valor.
A representação das necessidades dá o entendimento do que de
fato representa valor aos clientes. Permite avaliar diferentes formas de
solução alternativas e identificar oportunidades de melhoria.
A representação da solução permite analisar mais claramente
a forma como trabalhamos e entender os detalhes de como serão (ou foram)
implementados processos, regras ou sistemas de TI.
Objetivos x Dimensões
Cada requisito pode ser classificado simultaneamente de
acordo com as 2 dimensões apresentadas anteriormente. Como cada dimensão possui
2 diferentes visões, um requisito pode ser classificado em um dos 4 quadrantes
a seguir:
Dimensão 2 |
Necessidade |
Quadrante
I Necessidades atendidas pelo Projeto |
Quadrante
II Necessidade atendidas pelo Produto |
Solução |
Quadrante
III Solução desenvolvida pelo Projeto |
Quadrante
IV Especificação do produto |
|
|
|
Projeto |
Produto |
|
|
Dimensão 1 |
Quadrantes dos
requisitos sob as dimensões
Enquanto os quadrantes I e III descrevem requisitos de forma
temporária, para serem consumidos pelo projeto, os quadrantes II e IV descrevem
requisitos que serão mantidos e versionados a cada projeto que trata de
evoluções do produto.
Enquanto os requisitos dos quadrantes I e II utilizam termos
específicos das comunidades de negócio (ou usuários), os dos quadrantes III e
IV tendem a utilizar uma linguagem mais voltada a comunidade técnica (ou TI).
Se sua organização está investindo em uma iniciativa para
gerenciar requisitos, é importante primeiro definir de quais requisitos estamos
falando. Cada quadrante exige formato de especificação e processo de
gerenciamento diferenciados. Os requisitos de um quadrante serão lidos e
validados por um grupo de stakeholders diferentes dos requisitos de outro
quadrante. A rastreabilidade é o recurso que manterá a consistência entre eles.
Não existe um formato único que descreva requisitos num único repositório e
preencha todas essas dimensões.
E por fim, você se lembra daqueles 4 objetivos que
descrevemos no início deste artigo como sendo a grande expectativa com a gestão
de requisitos? Pois bem, agora vem a parte bacana: cada quadrante foca em
apenas um deles. Veja no quadro a seguir e reflita sobre ele alguns segundos
que você irá perceber a relação.
Dimensão 2 |
Necessidade |
1. Garantia de retorno sobre investimentos |
2. Retenção do conhecimento do negócio |
Solução |
3. Definição clara do escopo dos projetos |
4. Análise do impacto |
|
|
|
Projeto |
Produto |
|
|
Dimensão 1 |
Quadrantes dos objetivos
atendidos em cada quadrante
Para alcançar apenas um destes objetivos, não é necessário
manter requisitos no formato de outro quadrante que não ao associado ao
objetivo desejado.
Conclusão
Requisitos podem ser descritos e geridos de 4 diferentes
formas baseadas em 2 diferentes dimensões (Projeto x Produto e Necessidade x
Solução). Cada uma dessas formas de especificação e gestão permite o alcance de
diferentes objetivos.
Se sua organização tem prioridade em algum destes objetivos
em detrimento dos demais, não tenha pudor em focar seus esforços apenas nele e
deixar de lado as outras formas de documentação e gestão de requisitos que não
irão lhe agregar valor.
Se todos estes objetivos lhe são importantes, você precisará
gerenciar requisitos em todos os quadrantes. Mas defina seus processos e
estruturas de maneira clara para cobrir todo este escopo e evite misturar
requisitos de quadrantes diferentes num mesmo artefato ou repositório.
BA Day 2016
Venha ouvir mais detalhes sobre este e outro assuntos no dia 05/12/2016 no evento organizado pelo IIBA SP onde estarei presente ministrando a palestra “Por que a gestão de requisitos não funcionou?”. (http://iibasp2016.yubi.me/)
por Fabrício Laguna em 16/11/2016