O projeto está “concluído” e a dificuldade em fazer o cliente assinar o famigerado termo de aceite está enorme. Os testes de validação são realizados em meio às atividades caóticas do dia a dia e inúmeras “estranhezas” são detectadas no produto final.

“Mas não foi bem isto o que eu pedi” parece ser o lema e o bordão dos trabalhos. Para piorar, surgem defeitos que motivam a interrupção dos testes. Após cada ciclo de correções, a coragem de validar formalmente o produto diminui. “Ninguém é louco” de assinar um papel dizendo que o produto está “aceito”.

Para fazer frente a esta situação, o gerente do projeto apela para os documentos de escopo. Não são grande coisa, mas são as únicas tábuas de salvação a esta altura. Quando as discussões sobre escopo ficam acaloradas, alguém do lado do cliente dispara : “e este número enorme de defeitos, estava no escopo?”

Pela quinta vez, é dado um novo prazo para conclusão da validação. O prazo expira e os usuários finais declaram : “não terminamos pois havia muitos defeitos, o que motivou uma série de reentregas e novos retestes – isto causou o atraso”.

O pobre gerente do projeto, acuado pela situação, argumenta que “todo projeto tem de ter data para terminar e todo produto humano sempre vai ter defeitos”. Prolongar mais e mais a validação é “dar manutenção ao produto antes do mesmo ser aceito e pago, o que é uma injustiça”. O cliente por sua vez não concorda em dar o aceite até que os defeitos desapareçam. “Não é justo aceitar algo com defeitos e, enquanto houver um deles, não assinaremos coisa alguma nem pagaremos a última parcela”. A justiça está de todos os lados...

A corrida em círculos prossegue. Quando são consertados os cinco “últimos” defeitos, o gerente corre com o termo de aceite e uma caneta na mão. Um defeitinho novo então é anunciado no momento em que tudo parecia ter chegado ao fim. Para piorar, cada acerto acaba gerando novos defeitos, pois não há controle total sobre a configuração do produto (e muito menos sobre o código).

Quando, para alívio do gerente do projeto, o cliente resolve pagar a última parcela (sem todavia assinar nada, pois, como sabemos, “ninguém é louco”), os usuários finais começam a se debruçar e espernenar sobre as mais inusitadas questões: o produto é “difícil de usar”, “não está de acordo com uma necessidade-chave”, “possui aspectos deselegantes que incomodam muito”, “não é prático”, “introduz mais trabalho” etc.

Acabam então chovendo telefonemas e emails que vão parar nos altos escalões. O presidente da empresa fornecedora é questionado. Tem de ouvir que “o cliente já pagou e ainda não recebeu o produto completamente em ordem”. Reúne então a equipe e exige providências para “resolver de uma vez por todas os problemas deste projeto e tirar este assunto da frente”. Sacrificando mais ainda o resultado financeiro do projeto, o gerente resolve compor uma lista de verificação, ou um conjunto de cenários de teste, “a quatro mãos”, clamando pelo compromisso de que “quando todos os pontos da lista passarem e estiverem OK, o produto seja considerado aceito”.

Ao passar a lista, novos defeitos aparecem, e o conserto deles gera mais alguns, como sempre. Afinal, “mexer no que está funcionando é sempre arriscado e complicado”. O tempo se arrasta e não se chega ao final da lista de verificação. O medo de aceitar o produto é cada vez maior por parte do cliente, até porque neste meio tempo algumas regras já mudaram – aquele produto já começou a “caducar”, não fazendo mais muito sentido “aceitá-lo”. O tormento parece não ter fim, para todos os lados.

Alguém já viu algo assim? Parece familiar? E por que isto acontece?

Poderíamos fazer uma lista enorme de fatores, muitos já bem conhecidos (e parece que de nada adianta conhecê-los). Achar problemas em projetos é tarefa fácil. “Investir em qualidade é a solução” – garantiriam alguns, até com razão, mas... Como? O que exatamente deve ser feito, o que exatamente significa investir em qualidade? Criar mais células de testes? Planejar mais peer-reviews? Rever o processo? Ou seguir o processo já existente com mais diligência? Qual o ganho marginal?

Outros poderiam apontar (com razão até) o despreparo das equipes de desenvolvimento. De fato, a palavra de ordem de muitas fábricas de programação e congêneres é “reduzir custos” (entenda-se: contratar os recusos mais baratos possíveis, sem investir um centavo em treinamento). O resto da história é bem conhecido.

A lista de argumentações poderia facilmente atingir dez ou vinte itens. Mas, uma que é rara e que gostaria de lançar ao cenário é a seguinte: se os usuários finais se sentissem e tivessem atuado como efetivos membros da equipe de desenvolvimento do produto, o drama relatado poderia ser menos intenso.

Afogados nas suas áreas funcionais, estes usuários participam dos “levantamentos” das regras de negócio em ritmo de trabalho adicional. Conhecem o seu trabalho, mas não tem noção de como isto pode se transformar em requisitos de sistemas. Muitas vezes, os analistas também não têm muito tal noção! Perguntam o essencial e colocam sua criatividade (e seus paradigmas) para fazer o resto. Então, algum tempo depois, os usuários são novamente visitados, desta vez sendo presenteados com grossos documentos de análise funcional para “serem validados”.

Quando isto acontece, os gerentes das áreas usuárias podem “rebater” a enfadonha (e perigosa) missão com argumentações de diferentes níveis de astúcia. Os mais rústicos dizem que simplesmente que “não têm tempo para validar nada nem acham necessário, pois tudo o que foi perguntado já foi respondido, já foi passado nas custosas reuniões que foram feitas”. Os mais articulados aproveitam-se de um “esquecimento” mais ou menos comum dos gerentes de projetos e saem-se com esta: “mas estas atividades de validação, com toda a carga que representam, não estavam no cronograma e, por isto, não tive como me planejar – faltou visão, prevenção, planejamento e comunicação por parte do gestor, que me vem agora com um calhamaço de papéis para minha equipe ler”. Bingo para a área usuária!

Mais tarde, na entrega, o usuário deve “dar o aceite” no produto final... Uma vez comentei com uma pessoa completamente leiga no assunto, da área de artes plásticas, sobre este problema e ela me fez uma colocação genial : “Como assim aceitar? Construiram um negócio para ver depois se o cliente aceita?”

Este é o ponto, meus amigos: o produto já deveria nascer aceito. E para tal os usuários finais deveriam ter sido “envolvidos”, ou melhor, “comprometidos” com a coisa. Quem participa da gestação, aceita o filho assim que ele nasce. Quem tem de adotar depois, pode aceitar ou não uma criança candidata.

A inserção dos usuários finais nas equipes de desenvolvimento, de maneira efetiva e constante, não somente em entrevistas rápidas e milestones, contribui para gerar as seguintes convicções, muito importantes para a adequação do produto.

Para isto, os usuários finais e todos os demais interlocutores com as equipes de desenvolvimento ou com fornecedores de tecnologia deveriam receber uma formação, ainda que básica, sobre o processo de produção. Nem sempre vamos conseguir que o pessoal de linha de frente discuta calorosamente a cardinalidade de uma classe ou um algoritmo, mas uma boa noção dos elementos em jogo na “mágica” da transposição dos requisitos de negócio para um sistema ajudaria até a entender quais são as dificuldades e riscos da empreitada, além de criar uma noção mais clara do que precisa acontecer. Explicar a um paciente como vai ser feito um exame ajuda na colaboração e no sucesso do mesmo. E muito do medo de voar diminui quando um passageiro temeroso é levado à cabine de comando da aeronave e lhe é explicado o que está acontecendo, como os sistemas estão normais e que procedimentos estão sendo adotados naquele minuto.

Além de conhecer os fundamentos do processo de análise de sistemas, o usuários precisariam sentir e participar mais do esforço de organização das idéias para a modelagem. Algumas metodologias que conheci prevêem que os próprios usuários escrevam, em fichas, regras de negócio, mexam bastante nos protótipos e, ao final da etapa de definições funcionais, eles próprios apresentem em uma sessão o mapeamento dos requisitos, expressando o escopo da solução e variados detalhes.

Metodologias ditas ágeis de desenvolvimento de sistemas preconizam a entrega de versões do sistema em horizontes curtos, iterativos, de tal forma que os usuários acompanhem todo o crescimento do produto. Pode ser um caminho. Um ponto de atenção é fazer estimativas de prazo e custo para este tipo de projeto, para que ele não se torne uma espiral fora de controle, uma vez que abre muitas brechas para ajustes e melhorias (o que não é ruim do ponto de vista funcional, mas pode ser um desastre no plano orçamentário). Um dos grandes desafios dos projetos de TI para os próximos anos é precisamente este: adotar abordagens ágeis de maneira adequada, pois o horizonte apresentado pelas metodologias ágeis - não se enganem os mais incautos - exige uma grande dose da boa e velha... disciplina. Além disto, devemos mudar o modo de pensar o sucesso dos projetos: de “não estouro de orçamentos” para “maximização de valor”. Mas isto é um assunto complexo, que vale um artigo à parte ou um livro inteiro.

Autor: Roberto Pina Rizzo, MSc, PMP - Diretor Executivo - Verx Consulting

Se desejar entrar em contato com o autor, escreva para:  O endereço de e-mail address está sendo protegido de spambots. Você precisa ativar o JavaScript enabled para vê-lo.