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

Engenharia de Valor: o perigo do subjetivo e implícitoOlá, leitores, como estão?
Em alguns artigos, sobre Desenvolvimento Ágil em especial, faço breves menções sobre Engenharia de Valor 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 é? 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 terá 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!


Compartilhe!
Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on PinterestEmail this to someone

2 comentários

  1. Boa Trade, André.

    Parabéns mais um bom e útil artigo.
    Realmente criar funções, consultas, estatísticas, relatórios que poucos usam é desanimador.
    A maioria dos clientes ñ usa 60% das funcionalidades que meu software oferece.
    Alguns nem controle de estoque, poucos Contas a pagar e receber, as vezes nem o controle do caixa, mas acho que isso pode ser falta de orientação e/ou preparo do Cliente na Administração de Empresas.
    Essa orientação em como gerir o negocio ñ acho que faz parte da Venda do software, mas poderia(com custo adicional), no caso da NF-e, orientar como identificar, classificar a parte tributaria dos produtos da trabalho, tem que ensinar o que as vezes o cliente ñ quer aprender e/ou ñ concorda com as normas.
    A parametrização como você apresentou em outro artigo, resolve em parte o excesso ou ausência de funcionalidades.
    Via de regra, implemento tudo que acho necessário e útil, um dia alguém vai precisar, mas só habilito e/ou explico para quem vai usar.
    Quanto a Documentação do software, ainda ñ consegui criar um manual, é muita coisa, vou orientando conforme as necessidades do cliente.

    Desculpe pela extensão do comentário, mas artigos como este merecem atenção, juntar a orientação técnica, as experiências vividas pode ser bom.
    Abraços.

    1. Olá, Gerson!
      Isso mesmo! Um agilista chamado Vinicius Teles fez uma pesquisa há alguns anos e chegou à conclusão de que, em média, 64% das funcionalidades do software não são utilizadas. O custo dessa estatística é o tamanho e a performance do software, além da maior tendência em surgir bugs.
      Quando há várias funcionalidades dentro dessa porcentagem, ocorre uma inversão na Engenharia de Valor, causada por um fraco levantamento de requisitos. Na minha opinião, as funcionalidades implementadas são oriundas dos requisitos elencados, e ponto final. Por isso que a Engenharia de Requisitos é muito importante no início de um projeto.

Deixe uma resposta

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

Preencha o campo abaixo * Time limit is exhausted. Please reload CAPTCHA.