Profissionais TI - Pra quem respira informação

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 é?

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!