Início > Agile, Idéias, Metodologias, UERJ > Errando logo no início com as famosas RFP´s

Errando logo no início com as famosas RFP´s


Enquanto curtia a pequena folga de carnaval (trabalharei segunda e quarta-feira – arghhhh)  parei para conferir os e-mails e li este post:

Primeiro passo para um projeto de software falhar: a RFP

A questão levantada pelo autor é bastante interessante e é uma grande realidade em diversas empresas.

– Vamos desenvolver um projeto? Então, escreveremos uma RFP, a entregaremos a algumas empresas e contrataremos a que melhor nos atender (a partir daí, “a que melhor nos atender” pode significar diversas coisas e até, simplesmente, a mais barata).

O problema é que estão negando um princípio muito importante da construção de softwares: Não sabemos o que queremos no início (vide cone da incerteza). Daí, especificamos, no início, algo que pode não ser o mais interessante no final e exigimos que seja feito exatamente daquele jeito.

Em contrapartida, o fornecedor incluirá cláusulas contratuais que bloqueiem (ou ao menos dificultem) qualquer alteração no escopo do projeto, sob pena de multas contratuais. Assim, fazem com que sejam fixados preço, prazo e escopo (logo, a única coisa que pode e vai variar será a QUALIDADE) e, o pior, geralmente não definimos o que será considerado como software de qualidade, no início.

Por exemplo, no que se refere a mudanças no escopo, imagine o impacto que a seguinte frase pode causar no sucesso de um projeto de software (falando de funcionalidades que atendem de forma eficiente e eficaz as necessidades dos usuários e não simplesmente de entregar dentro do prazo e custo definidos – aliás, entregar com prazo e custo dentro do estimado no início é o mais difícil de acontecer):

“Quaisquer alterações no escopo deverão ser apresentadas com no mínimo 30 dias de antecedência e estarão sujeitas a análise do fornecedor”.

Claro que, geralmente, estas alterações serão aceitas pelo fornecedor, desde que o cliente aceite pagar (bem) mais por isso. Afinal, já existem dezenas de documentos definindo o que será feito e tudo deverá ser alterado…

É incrível como, apesar de tanto movimento a favor de melhores práticas e métodos, ainda encontramos diversas empresas com modelos de contratação que não favorecem o sucesso dos projetos de software.

Logo de início, exige-se zilhões de entregáveis que devem ser entregues antes que qualquer linha de código tenha sido escrita. Daí, o que vemos no final são pilhas de documentos mortos desatualizados (ou raramente/precariamente atualizados) e software que não é compatível com o que foi escrito…

De qualquer maneira, alguns pontos que precisamos levantar são:

Estariam os fornecedores preparados/receptíveis para contratos ágeis?

Estariam os clientes e fornecedores preparados para compartilharem os riscos nos projetos de software ao invés de continuarem no “jogo de empurra” onde um quer deixar a culpa para o outro?

É…, sei não viu…

A[]´s e até mais.

  1. 15/02/2010 às 14:12

    Olá Marcelo,

    Em primeiro lugar, obrigado pela visita ao blog e pela citação aqui no seu🙂

    “Estariam os fornecedores preparados/receptíveis para contratos ágeis?”

    Contrato ágil para um fornecedor (se eles estiver trabalhando com metodologia ágil), é sempre mais negócio, porque o risco está compartilhado com o cliente.

    O que vejo no mercado é que os cliente não estão preparados para trabalhar com contratos de escopo variável porque não querem assumir parte do risco.

    A questão é que o mercado está cheio de fornecedores de software e quando alguma coisa dá errado é só culpar o fornecedor atual e troca-lo. Desde que ele não participe da culpa do negócio ter dado errado.

    Enquanto o cliente pensar assim, vamos continuar tento muito mais fracassos do que sucessos no desenvolvimento de projetos de software.

    Abs

    André Nascimento

    • 16/02/2010 às 14:09

      Valeu pelo comentário, André…

      Concordo contigo e gostaria de acrescentar algo ao trecho: “Contrato ágil para um fornecedor (se eles estiver trabalhando com metodologia ágil), é sempre mais negócio, porque o risco está compartilhado com o cliente.”

      Há bastantes fornecedores querendo continuar com contratos não ágeis simplesmente para continuar ganhando com as gorduras adicionadas aos contratos, geralmente atribuídas aos riscos do projeto…

      Aliás, deixando tudo amarrado, há uma boa porta para se ganhar ainda mais com as mudanças (que são inerentes a projetos de software, mas ainda há quem continue cego com relação a isso).

      Mas, enfim, vida que segue e “vamo que vamo”.

      A[]´s

  1. No trackbacks yet.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: