Alow Brasil !!!

E a pergunta de hoje é: O que está acontecendo com os processos de contratação de software, ou RFP (Request for Proposal)?

Digo isso, pois tenho contato com dezenas de RFPs por mês e estou ficando assustado com o que tenho visto. Os clientes não estão preocupados em conduzir um processo de contratação que os leve a atingir o seu objetivo com o projeto de software, mas sim em se proteger dos riscos e complicações da contratação e não vêem que essa atitude só gera mais riscos e prejudica o seu negócio, acima de tudo.

Antes, um cliente necessitava de um projeto e então abria algumas vagas de “bodyshop” em seu quadro, colocava uns consultores lá e os gerenciava. Com isso, assumia todo o risco pela execução do projeto. Com o tempo, os clientes – principalmente os maiores – viram que a energia gasta neste processo não compensava e que o modelo precisava mudar.

Nisso, veio o que muitos consideraram a solução para o problema: O modelo de contratação como Fábrica de Software. Pessoalmente, eu considero esse um dos maiores erros da indústria moderna de serviços de software, mas isso é assunto para outro post. Com este modelo “mágico”, as consultorias assumiriam todo o risco pelos projetos, pois estavam suportados por modelos de qualidade, processos, métricas, certificações, bla bla bla.

Bom, já vimos que este modelo não funciona, certo? Basta dar uma olhada no gráfico abaixo que representa resumidamente os últimos Chaos Reports , do grupo Standish, sobre projetos de software nos últimos anos.

Chaos Report 2009

Não vamos entrar aqui nos “porquês” desses números, também falamos disso numa outra oportunidade

O fato mais importante aqui é que o cliente procura por um modelo onde ele não tenha tantos riscos para gerenciar e por isso acaba partindo justamente para o modelo que gera esses números (tristes) aí de cima. No final, temos um perfeito ciclo vicioso que tende não cessar nunca.

A partir do momento em que o cliente que quer contratar um serviço de software, passa a tomar algumas dessas ações na RFP, o projeto já está condenado ao fracasso:

1. Fazer a famosa concorrência de preços, sem analisar questões técnicas relevantes (não só se o fornecedor tem CMMi 200, ok?): Quem fizer por menos, leva;
2. Dar um prazo extremamente ridículo para que o fornecedor responda. Afinal, se o departamento de TI com 30 pessoas dele demorou 6 meses para escrever a RFP de 5 páginas, pra quê dar mais de 5 dias para o fornecedor respondê-la, correto?
3. Fixar fatores de produtividade pra todo mundo. O famoso: Tem que fazer tudo em 8 horas por PF (Ponto por função). Ora, ainda nem se conhece a equipe, como vamos saber com qual produtividade vamos trabalhar?
4. E o pior de todos: Esconder informações importantes do fornecedor, induzindo-o ao erro.

Sobre este último item eu gostaria de falar um pouco mais. Chego a ver alguns processos que são baseados em má fé por parte do cliente, buscando esconder informações do fornecedor e induzindo-o a assumir um risco totalmente desnecessário e que no final virará prejuízo, pra TODO MUNDO.

Isso geralmente é feito por áreas internas de TI do cliente que não estão nem um pouco preocupadas com o ROI (Return of Investiment) que aquele projeto trará para a empresa e sim em como livrar a cara deles se alguma coisa der errado no projeto.

Podemos citar alguns dos pontos que identificam claramente quando uma empresa está agindo de má fé no processo de RFP:

1. Vamos contratar apenas a codificação de vocês, logo todo o trabalho de análise e planejamento já foi realizado por nós. Você receberá todos os artefatos funcionais e técnicos e só precisará codificar. Ok, mas quando você pede para ver os artefatos para poder dimensionar o projeto a empresa sabiamente diz: Somente o vencedor da concorrência terá acesso a esses documentos. Ora, qual é o motivo disso? Coloque a cabeça para funcionar…
2. Nossa empresa trabalha com um framework de arquitetura próprio ultramegablasterJAVAplus2011… mas você só conhecerá essa oitava maravilha do mundo quando tiver ganho o contrato (assinado) e não tiver mais como voltar atrás. Aí verá que na verdade, o framework do cliente ainda usa Struts e EJB 2.0 e você não poderá mudar isso;
3. Nós também trabalhamos aqui com um modelo próprio de processo – geralmente algo que ele acha que veio do RUP – com nossos próprios artefatos entregáveis, etc. Mas você também só saberá que são 30 artefatos entregáveis quando já estiver com o contrato assinado

Ok pessoal, poderia dar mais alguns exemplos aqui. Mas acho que esses já são totalmente suficientes e muitos dos que estão lendo este post já viram isso pelo menos uma vez na vida numa RFP, certo? Então fica a pergunta:  Qual é a dos caras ? O que eles ganham com isso ? Será que o cliente ainda não vê que o maior prejudicado nisso no final será ele mesmo, que não receberá um produto bom e com qualidade?

Outros grandes culpados disso são as consultorias e fornecedores de software que visando o maior lucro e portfólio possíveis entram nesses verdadeiros Titanics e não questionam o cliente do porque o processo está sendo conduzido assim. Depois o projeto afunda, entra para as estatísticas do Gartner e Standish e fica todo mundo chorando, querendo saber o que aconteceu errado.

Contratação mal feita !

Isso precisa acabar!!! Enquanto clientes e fornecedores de TI continuarem com esse tipo de relacionamento, a coisa não vai andar.

Então, se você está do lado do cliente e está vendo isso:

1. Tente conduzir um processo de RFP justo e sem armadilhas para o seu fornecedor. Lembre-se, o dinheiro desperdiçado no final está do seu lado também;
2. Procure gerenciar melhor o ciclo de vida da contratação. Não deixe para abrir a concorrência 5 dias antes do seu dead-line de entrega do processo. Você só receberá lixo como propostas e depois não adianta reclamar que o fornecedor não entendeu o que você queria;
3. Exija que o fornecedor sente na mesa para conversar com você e entender de fato o que você quer. De preferência, peça para que ele monte uma apresentação com o que entendeu da solicitação;
4. Dê aos fornecedores toda a documentação e informação que tiver a respeito do projeto. Pra quê esconder informação, se ela só vai melhorar a asservidade que o fornecedor terá ao planejar o seu projeto;
5. Procure fazer a contratação em ciclos menores. Ao invés de contratar um projeto de um ano de uma vez, porque não contratar várias iterações e criar mecanismos de entregas parciais? Você já ouviu falar em SCRUM e contratos ágeis ? Não? Então já está na hora de conhecer

Se você está do outro lado, o do fornecedor. Tente fazer isso:

1. Nunca responda a uma RFP sem ter tido PELO MENOS uma reunião presencial com o cliente. Se ele estiver no Japão, pegue o avião e vá até lá ou faça uma conferência, ao menos;
2. Coloque pessoas capacitadas como responsáveis pelo processo. Se o cliente está pedindo uma solução em Java, não vá colocar o seu analista VB (que é mais baratinho), pra fazer o processo porque você não pode investir em pré-venda no momento. Não participe da concorrência se tiver que fazer isso, pois você está prestando um desserviço para a indústria de software;
3. Não entre em furada. Ora, a sua empresa não é instituição de caridade. Se a RFP apresenta sinais de má fé por parte do cliente, fale isso para ele. Será que o executivo da área usuário sabe o que está sendo feito pelas áreas de compras e de TI. Pois deveria, já que o $$$ sairá do bolso dele depois. Procure saber quem é o cara do $$$ e vá conversar com ele.

Não adianta tentar corrigir somente os processos de software, incrementar a qualidade, tornar o desenvolvedor mais produtivo, se o projeto continua a ser contratado de forma errada!!! Lembre disso: “Um projeto mal contratado já nasce fracassado”.

Abs

André Nascimento