segunda-feira, 15 de abril de 2013

Requisitos tóxicos - a responsabilidade é do time de TI

Referência: www.pc1news.com
Os requisitos tóxicos (toxic requirements) são requisitos captados na fase de desenho de um produto de software que comprometerão posteriormente o funcionamento correto do software. O comprometimento pode ser parcial, como uma degradação na performance de uso, ou total, impendido que o software cumpra o seu objetivo.

O exemplo clássico é o bug do ano 2000. Uma definição de armazenar datas com apenas duas posições para o ano, que parecia lógica e bastante razoável até o final dos anos 1980, era, na verdade, um requisito tóxico esperando para dar problema na virada do milênio.

Recentemente fui confrontado com uma situação onde o requisito era a transmissão de imagens em tempo real em um software que seria usado remoto sobre uma infraestrutura extremamente limitada. Esse seria um requisito tóxico em potencial, mas fomos capazes de convencer o cliente da limitação e o requisito não foi incluído. Neste exemplo havia uma boa relação de confiança entre o time técnico e o time de negócios, o que facilitou a discussão, mas, e quando isso não acontece?

Todos nós temos exemplos de requisitos tóxicos que não foram apontados. Seja por falta de força política do time técnico, seja por questões comerciais. E todos já vimos como essa história termina.

A responsabilidade de apontar e remover o requisito tóxico é do time técnico: do gerente do projeto, analista de requisitos, engenheiro de software, etc, e deve ser levada adiante por mais antipática que pareça aos olhos do cliente final. A alternativa é muito pior: seguir todo o projeto e entregar um software ao final que funciona parcialmente ou não funciona. Situação que termina em sérios problemas de desconfiança entre empresas e times, desentendimentos comerciais e, não raro, litígios.

Nenhum comentário:

Postar um comentário