Profissionais TI - Pra quem respira informação

Bem, não sei responder o valor monetário exato, mas, posso lhe dizer com segurança que é caro, muito caro!

Em mais de uma década de carreira posso dizer que ainda me surpreendo em ver tantas empresas abrindo mão dessa disciplina da Engenharia de Software de forma tão costumeira. E, o que mais me deixa indignada, essas empresas identificam que o problema está na falta de entendimento, documentação e gerência dos requisitos, porém, continuam no mesmo processo caótico. Como podem!?

Como Engenheira de Requisitos, costumo ouvir de muitas pessoas – que não são deste segmento – os mesmos argumentos: é muito burocrático, requer muito tempo, gera uma documentação excessiva, ninguém lê caso de uso e tantas outras desculpas para tentar justificar o injustificável.

Imagem via Shutterstock

Deparei-me com esse problema em empresas pequenas, grandes consultorias, no setor público e privado, e todas, isso mesmo, todas elas obtiveram o mesmo resultado catastrófico: o excesso de retrabalho.

O que considero um péssimo resultado para qualquer projeto, pois, se o retrabalho já é caro e desgastante, o que dirá o excesso deste! Sempre ao me deparar com esse cenário problemático mostro à alta gerência que a falha do processo ocorre lá no início dos projetos, quando as necessidades do cliente não são elicitadas de forma adequada, não são compreendidas, analisadas, documentadas, validadas e gerenciadas durante o projeto. Simplesmente uma ideia central é captada, um Termo de Abertura do Projeto é rapidamente elaborado, um contrato gerado e o acordo firmado. Pronto! Aloquem os recursos, montem o cronograma, estimem o custo e vamos construir o software! Sigam em frente (se possível, sem olhar para trás)!!!!

Resultado disso? Planejamento falido, equipe perdida, requisitos soltos, incompreensão geral sobre o projeto e o produto.

Por isso, geralmente, na segunda release já começamos a nos deparar com inconformidades durante as homologações. O que acho totalmente compreensível, tendo em vista que se nem os requisitos funcionais (o mais básico para iniciar qualquer projeto) foram devidamente construídos, o que dirá os de qualidade – estes sequer são mencionados durante a fase de Elaboração, sendo lembrados somente quando o cliente vê o produto entregue e não o aceita.

Eu quero deixar uma mensagem a todos os gerentes que se encontram em Organizações que não possuem essa disciplina em seu processo de desenvolvimento de software:

Elicite seus requisitos funcionais e de qualidade – não abra mão disso.

Você não precisa seguir uma metodologia rígida como o Processo Unificado (UP) e nem todas as recomendações das práticas ágeis, basta abrir um .doc ou excel e anotar as respostas dos seus usuários para as seguintes perguntas:

1. O que motivou você a solicitar esse sistema (seja novo ou uma melhoria evolutiva/adaptativa)?
2. Qual o objetivo que você espera alcançar em seu negócio após a entrega deste sistema?
3. Como você espera que o sistema se comporte para atender sua solicitação?
4. Quais as interações que você imagina realizar com o sistema?
5. Quais critérios você consideraria para dizer que o sistema tem qualidade e atende ao que você espera obter?
6. O que o sistema não pode fazer, que impactaria negativamente o seu negócio?
7. Por quanto tempo você imagina que o sistema suportará atender seu negócio?
8. Existe alguma limitação política da sua Organização que o sistema deva atender? [Caso ele não saiba responder, pergunte a qual departamento você poderia consultar.]

Com essas perguntas você conseguirá mapear o núcleo que o seu cliente (ou usuário-chave) espera do sistema a ser projetado. Além disso, a resposta a essas perguntas poderá ajudar sua equipe a ter uma orientação sobre o que motivou a solicitação, com o que eles precisam se preocupar, o que o cliente espera receber ao final do desenvolvimento. Sem dúvida, outros questionamentos surgirão por parte da equipe, o que é ótimo, pois, você conseguirá integrar as expectativas da equipe e do cliente de forma não burocrática, mas, objetiva e direta.

Refina naturalmente o entendimento de cada requisito funcional identificado.

Tente no próximo sprint, release ou projeto. E não esqueça de me contar o que mudou.

Boa Sorte!