Olá, 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á!
Introdução
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.
Engenharia de Valor
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 há uma falha no emprego da Engenharia de Valor. Se uma empresa não souber identificar e entregar as funcionalidades que realmente trazem valor para o cliente, o projeto dificilmente 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.
Requisitos subjetivos
Estes requisitos 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.
Requisitos implícitos
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 consequências.
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, “achismos” ou esquecimentos. O que é documentado, é implementado.
Resumindo, pode-se afirmar que os requisitos subjetivos e implícitos representam, respectivamente, o excesso e 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!
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.
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.
Ola, André.
Bom, a Engenharia do Valor não falha não… quem falha é quem não sabe realizar de forma correta a Engenharia do Valor (o que confesso ser algo para especialistas na metodologia)… O próprio nome fala, se é para entregar algo de Valor, só tem Valor se tiver Valor.
Não sei onde a pessoa fez o curso de Engenharia do Valor, quantos livros sobre o assunto leu, quantos projetos de Engenharia do Valor realizou… mas considero totalmente inverdade falar que a Engenharia do Valor falhou. Não ha dúvida que quem a aplicou não sabia realmente aplicá-la. Eu sou especialista na Engenharia do Valor, trabalho exclusivamente com ela desde 2007, já realizei mais de 90 capacitações e desenvolvi mais de 80 projetos de Engenharia do Valor em mais de 140 clientes. Tenho suficiente experiência e conhecimento para afirmar que se o projeto deu errado é o porque quem se atreveu a aplicar a Engenharia do Valor era amador na metodologia, embora possa ser um profissional muito bom tecnicamente em programação de sistemas.
Olá, Luiz.
O artigo realmente ficou incorreto ao afirmar que a Engenharia de Valor falha. Já corrigi a frase, esclarecendo que é o profissional quem falha ao aplicá-la.
Sou um grande adepto da Engenharia de Valor e concordo que ela não traz falhas para os projetos. Quem falha é a pessoa que utiliza essa engenharia de forma totalmente errônea. Já encontrei vários casos durante a minha carreira, como documentações de Software elaboradas com valores subjetivos, agregando funcionalidades que não são necessárias para o usuário final.
Abraço, e obrigado pela correção!