Requisitos conflitantes e dilemas no projeto de software

Ah, os trade-offs... Todo projeto nós os encaramos. E temos que tomar decisões. Daquelas importantes, que podem gerar desconforto para algum envolvido.

Antes de mais nada, afinal, o que é esse tal de trade-off? Este termo é utilizado para indicar uma situação que é necessária uma escolha, para resolver um certo conflito. Um exemplo que sempre cito é: um stakeholder solicita que o sistema seja extremamente seguro e quer que seja aplicada uma complexa criptografia em tudo o que se possa imaginar. Legal. Mas outro stakeholder solicita que o software entregue as resposta com o máximo de desempenho possível. Hummm... Aquela criptografia, solicitada pelo primeiro, degrada a performance do sistema. E agora? Eis o tal do trade-off.

Bom, sei que é clichê, mas aqui não tem muito certo ou errado. A dica para lidar com os trade-offs é avaliar cada requisito sob vários aspectos. Julgo que o mais importante é quanto de valor aquele requisito incorpora ao sistema e a quem o solicitou. Quão importante ele é? No exemplo que citei acima, se o sistema fosse acessar uma conta corrente em um banco, acredito que a segurança seja mais importante que o desempenho, desde que o segundo não seja completamente sacrificado.

Outro critério é avaliar quem solicitou o requisito. Pode parecer politicamente incorreto, mas cada stakeholder pode ter um peso na decisão do requisito. Note: não é todo o stakeholder que dá o aceite do projeto. E se o cliente elencou um subconjunto deles para aceitar o sistema, houve certamente um motivo razoável, e a opinião desse grupo deveria pesar mais. Por isso, ao registrar as necessidades do cliente, é importante anotar a origem de cada uma, indicando qual pessoa solicitou aquilo e, recomendo fortemente, registrar a motivação do pedido.

Outro ponto importante: registre formalmente cada trade-off e qual foi o critério para decidir. Registre a decisão e quais foram as opções descartadas, despriorizadas ou ajustadas. Alguém, no futuro, vai perguntar o motivo daquela decisão e, se você tiver isso registrado, vai conseguir resgatar o racional e, o melhor de tudo, mostrar que fez um trabalho profissional. CMMI-DEV chama isso de Decision Analysis and Resolution (DAR).

Costumo dizer que fingir que o problema não existe não o resolve. É preciso deixar tudo claro. A transparência gera confiança dos envolvidos. Não tente descartar os requisitos conflitantes. Registre-os e informe o que será e o que não será feito. Explique os motivos. Chegue a um consenso. Quem faz o levantamento e a análise dos requisitos precisa saber negociar. E buscar o famoso ganha-ganha. Se não conhece o termo, a dica é o livro Como chegar ao sim (Fisher e Ury). Aliás, vamos combinar que trata-se de uma leitura obrigatória.

Provocações finais

No seu projeto, você saberia levantar de onde vieram os requisitos? Quem os pediu e o por quê? Como você lida com os trade-offs? Os esconde e registra na sua planilha de riscos? Espero que não...
Como prioriza os requisitos? Como atribui valor a eles? O seu cliente conhece a curva de valor que o time vem entregando? Você diz que trabalha com ágil e, por isso, não precisa registrar nada, incluindo os trade-offs e as decisões tomadas? Essa desculpa ainda cola?

Comentários

Postagens mais visitadas deste blog

Documento de arquitetura

Levantamento de requisitos