Quanto custa abrir mão da Engenharia de Requisitos?

AGRADEÇA AO AUTOR COMPARTILHE!

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

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!

AGRADEÇA AO AUTOR COMPARTILHE!

Carolina Souza

Mais artigos deste autor »

Especialista em Gestão de Carreira Empresarial, em Gerenciamento de Projetos [PMP] e Engenharia de Requisitos [CPRE-FL] com 15 anos de vivência no mundo corporativo. Atua como coach, consultora, palestrante e mentora nas áreas de gestão, liderança, processos operacionais e desempenho de equipes. Colunista de revista e site especializados em TI.


9 Comentários

João Almeida
2

Olá, excelente artigo, sem duvida custa muito para a empresa pois não saberá o que deve-se entregar e para o cliente que não sabe o que vai receber .

Marília Balbé
3

Carolina,

Baita artigo!

As questões que tu sugeriu já estão com o time de levantamento de requisitos para serem utilizados nos próximos projetos.

Depois te conto como foi e se mudou algo.

Abração!

Bruno Zago
6

Carolina,

Parabéns pelo artigo. Concordo com você, em número, gênero e grau.

Apenas uma observação, quando você escreve “Você não precisa seguir uma metodologia rígida como o Processo Unificado (UP)…”.

Aos iniciantes na área e que não possuem muita experiência e contato com processo de desenvolvimento de software, num primeiro momento, vão pensar que o modelo de processo “UP” é rígido ou engessado. Dando uma sensação de complexo e de difícil aplicação.

O processo unificado é iterativo e incremental, ou seja, permite adaptar o trabalho de um projeto em várias entregas (iterações) cobrindo a especificação (requisitos), desenvolvimento (código-fonte e teste unitário) e teste funcional. Tudo isso com o conceito de garantia de qualidade. Isso permite evoluir o sistema a partir de incrementos (entregas das iterações) até chegar no produto final. O processo unificado possui uma dinâmica prática e flexível e consegue ter uma abordagem ágil.
Mas isso vai depender de como a equipe do projeto irá escolher e utilizar as práticas, recomendações, fases e disciplinas do processo unificado. Concordo que ele de ponta-a- ponta abrange muitos aspectos, mas é flexível (e não rígido) o bastante para se adaptar ao projeto. Assim como posso utilizar todos os diagramas da UML em um projeto, eu também posso documentar apenas os diagramas mais relevantes ou importantes para o projeto. Isso é relativo aos aspectos do projeto, cultura da empresa e entre outros fatores.

Sou bastante flexível e tolerante a qualquer modelo, processo ou prática que agregue valor ao time, e não sou defensor que um modelo ou processo seja melhor que o outro.

Caso alguém tenha interesse em aprofundar um pouco mais sobre o processo unificado e sua abordagem prática e ágil, recomendo o livro “Utilizando UML e Padrões – Uma Introdução à análise e projeto orientados a objetos e ao desenvolvimento iterativo” – Autor: Craig Larman.

Obrigado.

Carolina SouzaCarolina Souza Autor do Post
8

Olá Bruno,

Obrigada por compartilhar sua experiência conosco. A troca de experiência e de perspectiva ajudam a enriquecer nosso conhecimento e aprimorar nosso trabalho.

Abraços.

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">