Como produzir software “coxa”

Acabei de ler um post no blog do Phillip que me lembrou de uma história que eu queria escrever aqui.

A história que você lerá a seguir é uma dramatização do que acontece diariamente no mundo do desenvolvimento de software carinhosamente entitulada Como desenvolver software “coxa”.

Imagine uma empresa que está com necessidades de desenvolver um software. E imagine também que esta empresa (cliente) contratou uma empresa de 3 letras para fazer o trabalho.

Então, o projeto começa com a empresa contratada fazendo uma análise extensa do que será desenvolvido. Caso você não saiba, estas empresas te fazem acreditar que o RUP tem uma fase de análise antes de tudo, quando isso na verdade caracteriza um processo de desenvolvimento waterfall que é bem diferente do processo de desenvolvimento iterativo do RUP.

Depois de analisar exaustivamente tudo que precisa ser feito, eles acham que sabem tudo que o cliente precisa e com isso acham que sabem exatamente quanto tempo irá levar. Baseado nisso é estipulado um prazo de entrega do software para o cliente, assim como é estipulado um preço fixo para o trabalho.

Fechado o contrato, o projeto é iniciado. E quando começa o projeto sempre acontece a mesma coisa: a equipe de desenvolvimento começa a descobrir que certas coisas não são tão simples quanto pareciam ser. A equipe se depara com vários problemas que não haviam aparecido na fase de análise e cada vez fica mais chocada com a quantidade de coisas novas que vão surgindo. Nesse momento a equipe percebe que o projeto, que estimou-se que precisaria de 4 meses para ser desenvolvido, na verdade precisa de 8 meses para ser desenvolvido!

Então alguém surge com a brilhante idéia de contratar mais pessoas para a equipe. Afinal de contas, da mesma forma que nove grávidas conseguem parir um filho em um mês, 20 desenvolvedores conseguem fazer na metade do tempo o trabalho que 10 fariam – parece perfeito!

Mas espera aí, o preço já está combinado com o cliente desde o início. Então contratar mais pessoas é a maior furada, porque o cliente não pagará nada a mais por isso e se o custo do projeto for maior a empresa não terá lucro. Pior ainda, a empresa pode ter prejuízo! Neste momento a empresa decide comuncar ao cliente que o projeto terá que atrasar.

Quando a empresa vai dar a notícia para o cliente o cara normalmente quer matar o gerente do projeto, quer se matar, ou OS DOIS (depende do tamanho do projeto)! Afinal de contas ele pagou 50% adiantado e quer logo o retorno do seu investimento. Se o projeto ia demorar 4 meses e agora vai demorar 8, significa que todo o seu planejamento financeiro e de retorno de investimento do software foram por água a baixo. Nesse momento o cliente bate na mesa com força e diz: “se virem, eu não quero nem saber como vocês vão fazer mas eu quero o meu software na data combinada!”.

Exatamente neste momento foi parido um software “coxa”!

Vou explicar fazendo uma analogia: qualquer criança de 10 anos sabe que não existe “bom, bonito e barato”. Ou é bom, bonito e CARO; ou é RUIM, bonito e barato; ou é bom, FEIO e barato. Não tem jeito, é assim que funciona, não é possível ter tudo ao mesmo tempo.

Com software funciona exatamente da mesma forma. Só o que muda são as dimensões: qualidade, tempo e custo. Da mesma maneira que não existe nada bom, bonito e barato, não existe software “bom, desenvolvido rápido e barato”. Ou é bom, desenvolvido rápido e CARO; ou é bom, DESENVOLVIDO EM MUITO TEMPO e barato; ou é RUIM, desenvolvido rápido e barato.

No caso deste projeto repare que duas das dimensões do software não podem ser alteradas: preço (porque já foi combinado com o cliente e está em contrato) e tempo (porque a data de entrega já está estipulada). Sendo assim, como não dá para ter tudo ao mesmo tempo, a qualidade vai para o brejo. Neste momento é que vem a ordem do gerente de projeto: “gente, faz qualquer coisa aí, o importante é entregar o que foi combinado com o cliente, não importa como, faz tudo nas coxas mesmo!!”. E mais um software “coxa” será entregue.

Se eu contar os softwares “coxa” que eu já ví por aí ninguém acredita. O mais bizarro deles e que não poderia deixar de ser citado tinha o seguinte código na tela de autenticação (PHP):

if (($_REQUEST["login"]  == "admin") && ($_REQUEST["senha"]  == "1234")) {
    header("Location: index_autenticado.php");
} else {
    header("Location: index.php?mensagem=Login%20invalido");
}

No final das contas, quando o projeto é entregue, o cliente vê as telinhas e se as telinhas estiverem aparecendo e estiverem no mínimo bonitinhas ele vai dar pulos de alegria! Eventualmente até irá contratar a empresa para outro projeto ou indicar para amigos e outros projetos dentro da sua empresa. Por baixo dos panos existe esse monte de lixo, mais ou menos como um vulcão que pode entrar em erupção a qualquer momento causando efeitos devatadores! Deixa só alguém pedir para trocar a senha do sistema para ver o que vai acontecer…

Para mim é claro como água: não adianta querer prever tudo que acontecerá no projeto e pré-fixar datas e valores. É receita certa para fazer lixo. Já está mais do que provado que não funciona, porque insistir no mesmo erro?

Se você que está lendo se identificou com a história (o que não é nem um pouco difícil), sugiro fortemente que você leia sobre um modelo de contrato de desenvolvimento de software proposto pelo XP que muito me agrada: o Contrato de Escopo Negociável. O artigo é bem grande mas vale apena ler até o final! Você vai perceber que as coisas não precisam ser assim tão tristes nos projetos de desenvolvimento do software.

Tags: , , , ,

13 Responses to “Como produzir software “coxa””

  1. Fernando Manoel says:

    “…contratou uma empresa de 3 letras para fazer o trabalho…”

    if (($_REQUEST["login"] == “admin”) && ($_REQUEST["senha"] == “1234″)) {
    header(”Location: index_autenticado.php”);
    } else {
    header(”Location: index.php?mensagem=Login%20invalido”);
    }

    O que posso dizer sobre tudo isso ?
    Brilhante esse texto.

  2. O software coxa é resultado do uso de muitas tecnicas POG

  3. Huhahuahuhuahua, é verdade!

  4. Thiago Bertozo says:

    hueheuhue, otimo texto, pura verdade, estou cansado de ver esses tais codigos em alguns projetos.

  5. Rafael Ribeiro says:

    Ótimo texto,
    você tinha me dito ontem ao fim de sua palestra do riojug que tinha escrito exatamente algo que estávamos discutindo, cronogramas e etc. Mas, não pensei que fosse tão foda assim, huaau parabéns ai.
    O grande problema é, se você estiver entre uma dessas empresas, a seguinte: Em quanto tempo sua empresa que diz fazer um software de alta qualidade vai assumir que é um software coxa?
    hehehehe

  6. Adriano José - Adryanoj says:

    Muito bom!
    O texto é uma realidade de muitas empresas de hoje!
    O importante para o cliente e ver funcionando!
    Depois… ver as versões.. 1.0, 1.0.1, 1.0.1.1 …….

    Bom mesmo

  7. [...] Como produzir software “coxa” (Guilherme Chapiewski) [...]

  8. Paulo Júnior says:

    Parabéns. Gostei do texto.

    Só por motivo de curiosidade, vocês sabem como surgiu a expressão “nas coxas”?

    Bom, foi o seguinte. Na época do Brasil colonial, alguns escravos trabalhavam em olarias fazendo telhas de barro para cobrir os telhados das casas de seus senhores.

    As telhas eram feitas, literalmente, nas coxas dos escravos. Logicamente, como o porte físico dos escravos eram distintos, as telhas “saíam de fábrica” com grotescas diferenças de tamanho e, por este motivo, não se encaixavam umas nas outras.

    Daí, surgiu a expressão ainda hoje utilizada: “nas coxas”. Que significa: algo feito de qualquer maneira; sem qualidade.

    Até mais,
    Paulo Júnior.

  9. [...] a maioria dos softwares desenvolvidos aqui no mercado local seguem o processo em cascata, em sua grande maioria, através de fábricas de software. Bem, durante um certo dia na fase de codificação eu acabei [...]

  10. [...] O problema começa no modo como as pessoas projetam o software, dentro de um processo Waterfall, onde cliente não é parte do processo. Neste contexto, o cliente diz o que deseja e depois de 9 meses ele tem um resultado: um software produzido nas “coxas”. [...]

  11. Sempre achei furadas essas técnicas de escopo fixo.
    Particularmente trabalhei em muitos projetos assim, e foram relativamente muito poucos os que não precisei acelerar o desenvolvimento e entregar qualquer coisa.

    A solução proposta é bastante interessante.

    Muito bom, gostei demais desse post.
    Vou citá-lo no meu blog.
    http://blog.genilto.com

    Um Abraço

  12. [...] hoje por email um texto retirado de um post do blog http://gc.blog.br, não preciso fazer nem comentários, o texto é fantástico. Segue parte do [...]

  13. Post antigo mas continua atual.

    Muito bom o artigo. Booooa GC.

    obs: um erro de digitação ae, ta escrito “devatadores!”

Leave a Reply