Engenharia de Valor: o perigo do subjetivo e implícito

AGRADEÇA AO AUTOR COMPARTILHE!

Olá, leitores, como estão?

Em alguns artigos, faço breves menções sobre Engenharia de Valor, principalmente relacionados a Desenvolvimento Ágil, para apontar a importância de funcionalidades em um projeto. O objetivo do artigo de hoje é apresentar a definição básica desse conceito e dois aspectos que podem prejudicar o seu propósito. Vamos lá!

Vocês se lembram do aplicativo Wave, que foi uma iniciativa da Google para supostamente substituir o uso de e-mails? Pois é, a ideia não decolou. A empresa investiu tempo e recursos em um projeto que não foi utilizado pelos usuários. Os desenvolvedores que trabalharam nesse projeto talvez tenham ficado desmotivados, afinal, ninguém gosta de produzir algo que não será utilizado, não é?

Imagem via Shutterstock

Imagem via Shutterstock

Isso me faz recordar uma frase de Thomas Edison:

“Não quero inventar nada que não seja vendável. A venda é a prova da utilidade e utilidade é igual ao sucesso.”

O fato é que, semelhante ao Wave, esse tipo de cenário acontece muito em empresas de desenvolvimento de software, principalmente ao implementar funcionalidades que raramente (ou nunca) serão utilizadas pelo cliente. Esse tipo de evento indica que, nessas empresas, a Engenharia de Valor não é praticada.

Bom, acho que já deu para refletir um pouco sobre esse conceito.

A Engenharia de Valor consiste em analisar, sistematicamente, o que realmente irá agregar valor ao usuário final. Quando uso a expressão “agregar valor”, me refiro, especificamente, ao conjunto de funcionalidades que um software proporciona para apoiar o cliente em seus negócios, de modo que traga um maior controle e lucratividade. Na verdade, esse é o interesse na aquisição de um sistema, certo?

Muitas vezes, no entanto, na intenção de entregar algo sofisticado para surpreender as expectativas do cliente, o valor agregado é comprometido, ou seja, o produto oferece recursos em demasia e deixa de proporcionar o que foi originalmente requisitado. É aqui que a Engenharia de Valor falha. Se uma empresa não souber identificar e entregar as funcionalidades que realmente trazem valor para o cliente, o projeto simplesmente não tem qualidade.

Há dois aspectos na Gerência de Projetos que ameaçam o valor agregado: requisitos subjetivos e requisitos implícitos. Quanto menos houverem esses tipos de requisitos, maior será a satisfação na entrega do produto.

O primeiro deles, requisitos subjetivos, se referem às funcionalidades que não fazem sentido para o cliente. Por exemplo, disponibilizar uma tela de previsão do tempo em um software de frente de caixa de um supermercado. Chega a ser cômico, mas acontece. A consequência é clara: a tela nunca será aberta pelos usuários. Mesmo que o desenvolvedor ou a equipe de treinamentos apresente a tela, os usuários não encontrarão utilidade, e com razão.

Mas essa não é a única desvantagem. As funcionalidades subjetivas podem resultar em um software mais pesado, prejudicam a usabilidade (já que será um recurso ignorado na aplicação) e, talvez o pior deles, consomem um tempo desnecessário da equipe de desenvolvimento. Mais uma vez, voltamos à frase no início do artigo: ninguém gosta de produzir algo que não será utilizado.

Só para efeito de comparação, os requisitos subjetivos aparecem bastante em Trabalhos de Conclusão de Curso (TCC), quando o estudante procura implementar uma série de recursos extras, geralmente não contidos na documentação, apenas para impressionar a banca de professores, hahaha!

Os requisitos implícitos, por sua vez, são comparados aos requisitos não-funcionais, mas com uma característica particular: não são documentados e são cobrados pelo cliente como parte da eficiência do software. Por isso recebem este nome. O risco desses requisitos é que, por não existirem na documentação, não são considerados nas fases de projeto e muito menos no desenvolvimento. Por fim, o produto entregue ao cliente não atenderá as expectativas em virtude da ausência desses requisitos.

Por exemplo, considere que, em uma tela de cotação de preços, o cliente deseja que os dados sejam convertidos em uma planilha do Excel para que os usuários possam aplicar algumas fórmulas. Porém, este requisito não foi documentado, pois, para o cliente, estaria “subentendido” pelos Analistas de Sistemas. Resultado? A ausência dessa funcionalidade gera uma insatisfação e será reportada como uma falha. Além disso, um tempo adicional (não estimado) será necessário para incluir este requisito, impactando no prazo das próximas entregas. É uma sucessão de eventos.

Os requisitos implícitos podem ser reduzidos com uma documentação consistente do projeto, oriunda, claro, de um levantamento de requisitos bem eficiente. Dessa forma, os detalhes são observados, por mais evidente que sejam, e as “pontas soltas” são cortadas. Nada de adivinhações, “achismo” ou esquecimentos. O que é documentado, é implementado.

Resumindo, pode-se afirmar que os requisitos subjetivos e implícitos representam, respectivamente, o excesso a inexistência. Melhor ainda, todo esse contexto pode ser traduzido nas seguintes frases:

  • Requisitos subjetivos: “Ah, talvez o cliente use isso um dia…”
  • Requisitos implícitos: “Ué, mas o cliente não disse que precisava disso…”

Use e abuse da Engenharia de Valor para exterminar estes requisitos! :)

Abraços, pessoal!

AGRADEÇA AO AUTOR COMPARTILHE!

André Luis Celestino

Mais artigos deste autor »

Desenvolvedor de software há 7 anos e autor do blog AndreCelestino.com. Graduado em Sistemas de Informação e pós-graduado em Engenharia e Arquitetura de Software com ênfase em Desenvolvimento Ágil. Atualmente trabalha como Analista Implementador Delphi em Florianópolis.


2 Comentários

Fernando RegoFernando Rego
1

Gosto muito da filosofia KISS: Keep It Simple and Stupid (ou Keep It Simple, Stupid), mantendo soluções o mais simples e objetiva possível. Devemos aprender a ser bem remunerados por soluções e inteligência e não por exageros, floreamentos e mais trabalho braçal.

É uma pena que o Analista de Requisitos seja tão pouco valorizado e usado pelo mercado. Ele é responsável direto por custo e lucro; trabalho e retrabalho.

Parabéns mais uma vez.

André Luis Celestino Autor do Post
2

Olá, Fernando!

Concordo com você! Sempre afirmo que um bom levantamento de requisitos se traduz em qualidade do produto, afinal, os requisitos representam o alicerce da implementação. Muitas empresas ainda desconhecem a eficiência da análise de requisitos e desconsideram investimentos nessa área. Mesmo assim, ainda acredito que esse segmento será mais valorizado em um futuro próximo.

Opa, também sou adepto ao KISS, bem como outros princípios, como o YAGNI (You Aren’t Gonna Need It) e o DRY (Don’t Repeat Yourself). São pequenas disciplinas, que, quando combinadas, resultam em uma codificação simples, compreensível e funcional.

Obrigado pelo comentário! Grande abraço!

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="">