Na minha opinião não há desculpa para criar um software com má qualidade. Mesmo com prazo curto e orçamento apertado sempre é possivel fazer um software de boa qualidade compatível com esses fatores. Claro,  o primeiro desafio é saber como fazer isto e o segundo é  fazer!

As pessoas se esquecem que todos os projetos, de qualquer tipo que sejam, estão sob a regência do Triângulo de Projeto e sua Regra de Ouro. Se o bombeiro se esquecer do Triângulo de Fogo pessoas podem morrer, inclusive ele próprio; mas se a equipe, e especialmente a gerência e o cliente, se esquecem do Triângulo de Projeto o que acontece é a falha do projeto. Incrivelmente se perguntar a um gerente de projeto de software quantos dos seus projetos falharam, ele dirá que nenhum.  Isso porque ele considera falha a não entrega do software,  quando não é esse o critério usado pelo  resto do mundo. Esta auto-negação é fruto do medo de ser demitido; talvez, mas pode bem ser porque ele realmente acredita nisso.

Se não ha entrega o projeto falha inegávelmente, mas o projeto  de software falha se falhar o prazo para a entrega acima da incerteza prevista.  Além disso, o projeto também falha se o orçamento original é excedido.  E o projeto falha  se o que é entregue não é o que foi pedido. Contudo o projeto também falha se não foi entregue com a qualidade técnica desejável. E isto, ao contrário do que a maioria pensa, é muito perigoso.  Tudo bem que dificilmente pessoas podem morrer por um software sem qualidade – embora seja possivel se for um software de apoio à vida – mas empresas podem. sucumbir. Em particular a empresa cliente que precisa do software para alavancar seus negócios, e até mesmo, a empresa produtora do software que corre o risco de nunca mais ter projetos devido à sua falta de mérito.

Triangulo de Projeto

O Triângulo do Projeto é a relação entre o custo, o prazo e a qualidade. Cada um destes fatores ocupa um lado do triângulo.

A regra d’ ouro associada ao triangulo é muito simples: só é possível otimizar dois lados simultaneamente.

Por exemplo, se queremos um projeto rápido e barato, automaticamente ele será de qualidade inferior. Se quisermos um projeto bom e barato, automaticamente será demorado.  Se quisermos um projeto de boa qualidade e rápido, ele será caro.

O cliente sempre tentará quebrar a regra do triangulo, ele vai querer bom,barato e rápido.  Ele não vai assumir que quer bom, apenas num prazo e orçamento estipulado porque ele assume que a empresa entregará com boa qualidade.

A empresa, por seu lado para cumprir o prazo e o orçamento não conseguirá colocar essa qualidade no produto final. Ela não poderá fugir deste fato. A força vinculante do triangulo é uma realidade. Assim ela sacrifica, às vezes sem se dar conta, a qualidade para “agradar” ao cliente. O que está acontecendo de facto é que ela está apenas cumprindo dois terços das espectativas do cliente. O problema é que o terço que sobra é aquele que ninguem esquece.

Existem vários fatores que levam à desilusão do cliente, mas a principal é o seu desconhecimento das opções que existem e a irresponsabilidade de mediadores da empresas de software que escondem essas opções, a maioria das vezes por a desconhecerem também, e algumas vezes porque acham que isso é uma boa forma de negócio.  Basicamente eles têm medo de ofender ou ferir de alguma forma o cliente, e que, dessa forma, o cliente fuja para a concorrência.A realidade é que os clientes se aproveitam dessa fraqueza. Porque a empresa não tem confiança em si mesma e no seu trabalho e fica mendigando projetos de clientes em vez de estabelecer padrões de qualidade e ser paga por isso.

Os clientes não fazem por malicia. Afinal eles estão protegendo os seus interesses. Acontece apenas que a maioria das vezes eles estão se enganando a si mesmos. Um software feito rápidamente e barato não tem qualidade. E isso significa, entre outra coisas, que trará problemas , não será flexivel e no final das contas custará ainda mais para o arranjar. Será pior a emenda que o soneto.

Qualidade deve ser um pilar fixo. A base do Triangulo. Inabalável e inegociável. São os outros dois fatores que formam o projeto.

Em principio isto é muito bom e bonito. O problema é que não existe uma forma imparcial de medir a qualidade de um software.  Porque ela não existe os clientes não têm como comparar ofertas de empresas e as empresas não têm como demonstrar que são melhores que a concorrência.

Desde a qualidade do código até à qualidade do produto ou so serviço oferecido pelo software, passando pela qualidade do atendimento e do processo de desenvolvimento até à qualidade subjetiva da experiencia de uso. São demasiados fatores e as empresas de software não param para pensar neles. As empresas clientes não param para se preocupar com eles.

Auditoria ? Vistoria ? Revisão por terceiros ? Nada disso é equacionado pelo cliente quando contrata um empresa para criar um novo software.

Cultura da Qualidade é algo bem difícil de ensinar e aprender. É algo que tem que ser assimilado. Mas para isso a sociedade tem que ser exposta aos perigos da má qualidade e aos méritos da boa.

Escolhendo o Prazo

Se o cliente escolher um prazo fixo – pela razões que sejam – o projeto tem que ser organizado em torno dessa data. A qualidade está fixada assim como o prazo, então o que nos resta é o custo. O custo é a variável livre. A software house tem que estar preparada para competir neste custo com a concorrência sem abrir mão da qualidade. Não adianta dizer que vai colocar o triplo de desenvolvedores e assim o projeto sai no prazo pedido. Isso é irreal. Colocar mais pessoas não apenas não é solução como pode ainda atrapalhar mais. A forma de competir nesta forma de contratação é ter uma plataforma de aplicação flexível que rapidamente permite alcançar o objetivo.  Um investimento que muitas software houses não entendem e, por conseguinte, não podem oferecer competividade nesta categoria. A saida comum é contratar mais pessoas, estagiários preferencialmente por serem descartáveis.  Isso é um duplo erro. Primeiro porque mais pessoas não fazem ser mais rápido e segundo porque o tempo da equipe será consumido agora para ensinar os estagiários que rendem menos que um membro da equipa. O resultado é o caos e o  fracasso do projeto.

Escolhendo o Custo

Se o cliente escolher um custo fixo, então o prazo é a variável livre. O cliente não apenas não pode impor um prazo como não pode esperar por um prazo. Estará pronto quando estiver. Ele terá a certeza de que receberá um software que faz o que ele quer e custa o quanto ele está disposto a pagar, mas não terá ideia de quando. O prazo “não está escrito na pedra”.

Obviamente isto não interessa ao cliente porque ele teme que nunca receba o software ( por isso o contrato de prazo fixo é mais comum).

Claro que, do ponto de vista da software house, o custo fixo impõe muito mais disciplina no desenvolvimento já que quanto maior for o tempo gasto no desevolvimento do software, e mesmo não havendo um limite para a entrega, existe um limite de fluxo de caixa. Considerando todos os gastos do projeto por mês (desde o cafezinho aos salários e tributos) e o preço que o cliente pagou, sabemos que só poderemos trabalhar nesse projeto durante um certo tempo. Este limite crítico, em que os recursos injetados no projeto advém exclusivamente do cliente desse projeto, impõe um prazo artificial não contratado com o cliente, mas real para a saúde financeira da empresa.

É fácil entender que quanto mais depressa o software for entregue, mais depressa teremos lucro, pois não mais estaremos gastando os recursos do projeto. Isto só pode ser alcançado com uma equipe bem treinada, entrosada, e com uma plataforma de aplicação que possa suprir as demandas mais comuns permitindo à equipe se concentrar apenas naquilo que é diferente de projeto anteriores. Como isso não é uma realidade na maioria dos projetos eles falham redondamente.  O dinheiro acaba e com ele a vontade de terminar o software. O cliente se chateia, abandona a empresa e procura a concorrência. Pior que isso, a empresa está agora na lista negra.

O Quarto Elemento

Poderíamos pensar que existe uma quarta variável. Uma variável escondida: o Escopo do Projeto. Ele está implicito da variável livre. O tamanho do escopo irá afetar proporcionalmente a variável livre do triangulo, mas terá efeitos incontroláveis se afetar todos os lados do triangulo.  É por isto que a alteração do escopo tem que acompanhar a alteração da variável livre.

Este diabinho que fica nos detalhes tende naturalmente a destruir o projeto por dentro.

Escopo fixo é um mito aceite pelos ingénuos e acreditado pelos novatos. Tal como os unicórnios ; não existe. A única forma segura de trabalhar é deixar o escopo ser variável depois de fixar os  lados do triangulo.

Custo-Hora

É comum que um projeto de software seja cotado em custo-hora. Isto significa nada mais e nada menos que amarrar dois lados do triangulo , ou seja, implicitamente escolher custo e prazo e deixando a qualidade sofrer.

Processa-se assim: Um escopo é escolhido.Ele e dimensionado pelo numero de horas que a equipa demora para o executar. Essa dimensão vira o Prazo. O numero de horas é multiplicado por um fator numérico de custo por hora e obtém-se o Custo. Muitas vezes esse fator incluir considerações de lucro e outras e na realidade o numero obtido é um Preço.

Entenda que Escopo , Prazo e Custo são funções uns dos outros neste modelo já que a diferença entre eles é apenas um fator multiplicativo.  Isto obriga, seguindo a Regra d’Ouro do Triangulo de Projeto a uma péssima qualidade.  Custo e Prazo são amarrados e escolhidos sem latitude. Não apenas isso, mas a variável livre, a Qualidade, que deveria ser o pilar fixo , passou a mero figurante. Pior é que o fator livre , sendo uma função do escopo, tenderá a ficar ainda pior quando o escopo aumentar. Sim, porque nesta lógica ele sempre aumenta. As empresas acham até bom porque isso corresponde a mais trabalho e portanto mais custo e portanto mais dinheiro entrando.

Só que, na maioria das vezes o cliente aumenta o escopo por baixo dos panos inchando funcionalidades do escopo original com mais detalhes sem os quais o cliente diz viver e sem os quais o software é inutil. As empresas compram este bluff e caem no erro de agradar ao cliente levando prejuizo ou mal-negociando os adendos.

Não jogue contra as regras

O triangulo de projeto nos dá uma forma simples de entender porque os projetos falham e ao mesmo tempo nos dá pistas do que é necessário para que eles não falhem.

1. Qualidade é inegociável.
2. Fixe prazo ou custo, não ambos.
3. Avariável livre depende do escopo.

Qualidade é o primeiro lado do triangulo a ser escolhido e é escolhido implicitamente.  Se você tem uma empresa de software, explicite isso ao cliente. Se ele quiser mudar isso, mande-o procurar a concorrencia ( afinal eles irão afundar a concorrencia e isso será bom para si). Se você é cliente e a empresa deixa que a qualidade seja manipulada, desconfie. Isso só lhe dará dor de cabeça depois. Procure outros.

Sabendo que o software terá qualidade escolha entre prazo e custo. Quer barato ou quer rápido ? Ambos não é possivel. Convença-se disso. Não lute contra moinhos de vento achando que pode dobrar a Regra d’ Ouro.

Lembre-se que a variável que sobrar depende do escopo. Quanto maior o escopo pior essa variável desempenhará. Mantenha o escopo sempre no mesmo tamanho. Manter o tamanho não significa manter as mesmas coisas e esse é que é o segredo. Re-priorize os seus requisitos quando novos forem adicionados e abandone os que saem fora do tamanho originalmente acordado.

Projetos de prazo fixo e  custo fixo estão vinculados a falhar porque desmerecem a qualidade. Como eles são a maioria é de prever que a maioria dos projetos de software sejam fracassos.

Você quer ter um fracasso nas mãos ? Não ? Então não tente ser mais esperto que a sabedoria da Regra d’ Outro  do Triangulo de Projeto. Se tentar, vai-se arrepender.