Skip to main content
mito do requisito perfeito nas áreas de Desenvolvimento e TI

O mito do requisito perfeito nas áreas de Desenvolvimento e TI

Existem alguns mitos que se propagam nas áreas de desenvolvimento e TI e com o tempo fica até difícil nos vermos livres deles. Vamos substituí-los por conceitos mais próximos da realidade? Leia o artigo e entenda melhor o assunto!

mito do requisito perfeito nas áreas de Desenvolvimento e TI

Por exemplo, talvez você já tenha ouvido a história de algum Gerente de Projetos reclamando por que seu projeto sofreu mudanças no meio do caminho. Entretanto, a própria disciplina de Gestão de Projetos tem como um de seus processos centrais o Gerenciamento Integrado de Mudanças, exatamente para prever as mudanças, uma constante do Gerenciamento de Projetos.

Assim sendo, reclamar que mudanças ocorrem no curso de projetos e propor um cenário onde estes projetos estejam livres de mudança é apenas uma fantasia.

Mitos do mesmo tipo também podem se propagar no cenário de testes de software, e neste caso vou falar especialmente de um mito relacionado à prestação de serviços de testes terceirizados para clientes de grande porte. O mito seria o seguinte: “Os requisitos devem ser de alta qualidade, e sem eles é impossível realizar um bom trabalho”.

No curso de minha carreira, não raro encontrei analistas que diziam: “Infelizmente, os requisitos do cliente estavam vagos, e POR ISSO não é possível realizar um trabalho decente”. Já vi até desabafos do tipo “Não é justo”.

No entanto, essa queixa não se justifica, pois a própria ideia de que os requisitos devem ser distribuídos de forma perfeita pelo cliente não é realista.

Por que essa expectativa sobre os requisitos do cliente é injustificável?

Antes de entendermos o porquê, temos que entender a essência da dinâmica dos processos corporativos. Alguém só faz um esforço por que é NECESSÁRIO que ele seja feito. Caso contrário, o tempo será melhor focado em outras coisas. Ou seja, o requisito só vai ser escrito de forma impecável se aquele escrevendo o requisito precisar entregá-lo de forma impecável.

Mas essa necessidade só ocorria nos tempos em que não havia terceirização. Muito antes de surgir o termo downsizing, todas as atividades relacionadas a desenvolvimento (incluindo escrita de requisitos funcionais, codificação e testes) eram realizadas de forma internalizada, ao invés de terceirizada.

Isso significa que todas as áreas envolvidas no processo de entrega do software tinham, no fim das contas, o mesmo patrão (enquanto que a relação entre um fornecedor e a empresa é uma relação entre um prestador de serviços e seu cliente).

Ora, nos velhos tempos era muito fácil que a área de Análise & Design afirmasse algo como: “Não é possível fazer a modelagem de dados, pois os requisitos estão incompletos”. E, realmente, isso tendia a surtir efeito, pois tínhamos uma área organizacional que não entregou um artefato suficientemente bom para uma outra. Claramente uma área podia ser culpada pela entrega de má qualidade. Neste caso, a área de requisitos.

Com isso tudo, era de se esperar que os requisitos que saíssem dos profissionais de requisitos fossem entregues tão impecáveis quanto possível.

Contudo, todo esse cenário virou de cabeça para baixo com o advento da terceirização!

Agora podemos ter situações onde um fornecedor recebe os requisitos de negócio e entrega de volta os casos de uso. Assim como um outro fornecedor cuidando da codificação e outro cuidando dos testes.

Eis que alguém poderia objetar: no que isso resulta em requisitos de má qualidade?

O fato é que os fornecedores estão disputando o serviço, e portanto não estão tão preocupados em dizer coisas como “o requisito não é suficientemente bom para eu prosseguir”, mas sim “do jeito que está, é o suficiente para conseguirmos trabalhar”. Alguns deles poderão até afirmar: “podemos até lhe ajudar na elaboração dos requisitos faltantes, fazemos o suficiente para que a entrega seja de alta qualidade”. Tudo isso é consequência da competitividade entre fornecedores. Exigimos menos, e ainda assim buscamos entregar mais.

A própria existência desse cenário mudou o paradigma das grandes organizações: se meus fornecedores conseguem entregar com qualidade, mesmo que meus requisitos não estejam tão detalhados, NÃO HÁ MAIS MOTIVO para entregarmos requisitos perfeitos. Na verdade, a expectativa das empresas mudou. O pensamento tende a ser algo do tipo: “meu fornecedor irá me auxiliar a encontrar os requisitos faltantes”. E, justamente, com o conforto final: “meu fornecedor garante”.

O requisito perfeito hoje é uma ilusão, pois hoje em dia, com a terceirização, os responsáveis por requisitos NÃO PRECISAM escrever requisitos tão detalhados e coesos. Geralmente, apenas um draft incompleto já é suficiente para os fornecedores prosseguirem com o trabalho. No passado, requisitos de qualidade eram uma necessidade, pois os analistas de requisitos estavam em uma situação em que entregavam um produto de trabalho para COLEGAS da mesma organização. Agora, eles enviam esse produto de trabalho para fornecedores.

Tudo isso é motivo para desânimo? Razão para jogar tudo para o alto? Muito pelo contrário!

A constatação de que os requisitos perfeitos hoje não passam de um mito lançam novas oportunidades para alguns analistas se destacarem dos outros, e aqueles times com os melhores analistas se destacarem dentre outros times.

Esses times deixarão de ser aqueles que apenas leem documentos e escrevem cenários e casos de teste, mas passarão agora a serem intérpretes das necessidades do cliente, mesmo que tudo isso não esteja tão claramente documentado.

Novas habilidades terão que ser desenvolvidas, entre as quais comunicação, escuta ativa e raciocínio analítico. Não podemos deixar de esquecer também a necessidade de uma base de conhecimento, que servirá para aumentar o potencial deste time de analistas.

Essa nova perspectiva para os líderes e analistas de testes só será plenamente aceita, em nível consciente, quando entendermos que não adianta mais reclamamos que os requisitos do cliente são ruins. O próprio contexto organizacional atual leva a isso.

Os requisitos não vão melhorar. Podemos até apostar que vão piorar e ficar ainda mais vagos (lembremos da popularização do SCRUM). Mas os analistas de testes, estes sim, podem ficar cada vez melhores.

Leia também: O poder do Não Positivo para Gerenciamento de Projetos de Testes.


Compartilhar Com
Conteúdos que você pode se interessar

Deixe uma resposta

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