Muito se fala do processo de desenvolvimento tradicional. Normalmente no  contexto de introdução do processo ágil ou do processo clássico. Contudo não é possível reconhecer as diferenças entre clássico e tradicional ou ágil sem saber o que cada um é e como se distingue dos outros. O processo clássico é o processo baseado em regras e métodos testados e publicados em literatura especializada até meados dos anos 90. Digamos que é o processo acadêmico levado à prática embora não existe um processo formal ou acadêmico per se. Vários autores seguem esta linha. Estes autores explicam-lhe como realizar levantamento de requisitos, projetar software e construir projetos que sejam compatíveis com estas duas áreas. O processo ágil é seguido por uma nova onda de autores a partir dos anos 90 em diante. O processo tradicional é a forma politicamente correta de se referir a todos aqueles que não seguem nenhum processo, um processo ad doc (ou seja, inventado por eles e sem base na literatura) ou um processo que sendo baseado na literatura é mal implementado.

O processo tradicional normalmente começa com transformas prospects (clientes em potencial) em clientes. Para isso o departamento comercial faz o seguinte. Começa por se aproximar do cliente para saber o que ele quer. Normalmente a resposta é vaga. Algo como “precisamos de um sistema de XPTO porque o nosso tem alguns problemas”. O departamento comercial vê isto como uma oportunidade e faz uma oferta direta de negócio se oferecendo para fazer o software. Por meio de licitação ou por conversação direta o departamento comercial só precisa estabelecer dois parâmetros de forma a convencer. O prazo e o preço. O departamento comercial, sem nenhuma noção do que o software será, como será, qual a equipe, qual a tecnologia, qual a complexidade, etc… simplesmente prometa ao cliente algo como “Podemos fazer um sistema de XPTO para si em N meses por P reais”. Normalmente estas variáveis são tunadas para agradar ao cliente. Por exemplo, se o cliente diz que quer o software para o natal e falta 3 meses para o natal, o prazo será  – você adivinhou – 3 meses. Independentemente se é possível ou não. O departamento comercial é sempre otimista porque depois de fechar o contrato não é da sua responsabilidade que ele se cumpra. Se algo der para o torto, o problema é do departamento de projetos e desenvolvimento. Nunca do comercial. O comercial também gosta de jogar com o  dinheiro. Se a empresa cliente é grande, inchamos o preço – a chamada gordura – ( que é diferente do conceito de lucro)  , se o cliente é modesto o preço é mais baixo. Mais uma vez o custo do projeto é irrelevante. Nem sequer se toma em consideração quantas pessoas estarão na equipe, por quanto tempo e quanto cada uma ganhará.

Algumas empresas tentam fugir deste modelo. Elas acham que se tiverem uma estimativa isso torna as coisas mais cientificas. Assim, o departamento comercial fala com o departamento de projetos. Normalmente um dos gerentes de projetos , e pede para que ele faça a estimativa. Mas já lhe fala que o prazo é N meses e o custo é C. Perante isto o gerente simplesmente criar um grant chart no projet que mostra como as pseudo-fases do projeto encaixam nesses meses. Normalmente as fases são : Levantamento, Analise ,  Desenvolvimento, Teste , Homologação. O gerente então adoça o caldo prometendo que no fim de cada faze um conjunto de artefactos será entregue ao cliente em troca de pagamento. Isto basicamente significa que – sem nenhuma noção se vai dar certo ou não  – o gerente compromete uma equipe que ainda não existe em entregar artefatos ( documentos,  diagramas, codigo, entregáveis de qualquer especie) que ele desconhece num prazo que ele não sabe se é suficiente. A desculpa é : depois arranjamos um cara que possa fazer isso no tempo que nós queremos. E se ele não for capaz, pressionamos.

O departamento comercial fica maravilhado com isto porque suas estimativas de preço e prazo estavam certas (uau!). Afinal o gerente não falou nada que estamos enganados, nem que prometemos mundos e fundos. Aliás ele ainda prometeu mais coisas e se ele fez isso é porque está confiante com o preço e prazo que inventamos. Confiante sim. Certo não.

Sendo assim o departamento comercial fica ousado e jura de pés juntos que o prazo e o preço serão cumpridos e por isso propõe o desafio de um prémio. Se o software for entregue na data prevista ou antes, o prêmio será X. Com um decaimento progressivo se entregue depois. É obvio que esta estrutura de pensamento em que ninguém se dá ao trabalho de saber o que afinal irá ser feito e como, está voltada ao fracasso.

Sabendo disto as chamadas fábricas de software apelam para o que chamam de “Definição de escopo”. Afinal isso é a única variável no processo já que o prazo e o custo são chutes do comercial e não baseados no custo e esforço. “Sistema de XPTO” não é suficiente para estas empresas. Eles querem saber, o que compõe um sistema de XPTO. O cliente responde que é o conjunto do modulo A com o B e o C. A empresa pergunta o que é o A , o B e o C. O ciente responde que dará mais detalhes durante a fase de levantamento.Isto é um  artificio do cliente. Na cabeça do cliente está se passando um filme diferente. Na cabeça dele a empresa que constroi o software é de um de dois tipos. Ou é uma empresa que contrata adivinhos e portanto sabe o que ele quer, ou tem gente experiente trabalhando nela e portanto essas pessoas sabem o que o cliente quer. Ter que responder o que elas já sabem é inutil e aliás demonstra que a empesa não é tão boa como diz. A empresa também acha que perguntar de mais é sinal de fraqueza e que pode levá-lo a perder a paciência e a cancelar o projeto. Então, “vamos fazer a estimativa com o que sabemos e por alguma margem de erro em cima” – diz alguém no departamento comercial , de projetos ou até mesmo da diretoria quando algum gerente mais preocupado está tentando avisar que o barco está afundando antes de ir para o mar.

Assim se faz. uma micro-levantamento que foi possivel executar com 5 ou 6 bullet points é apresentado em um power -point ao cliente, com o gráfico do project o preço e o custo que o comercial havia decidido.

Se a sorte quiser, o cliente aceitará a proposta. Entenda que tudo está nas mãos da sorte, não da capacidade ou da competência dos envolvidos, já que ninguém sequer ousou olhar para o software que irão produzir. Aqui começa o problema do processo tradicional. Promete-se tudo de olho no dinheiro e num conceito chamado “por o pé na porta” que significa que tudo é menos importante que tornar um prospect em um cliente e isso deve ser conseguido custe o que custar. Não importa se dentro de N meses quando o software explodir o prazo e o orçamento a imagem da empresa vai para o buraco. Porque nesse ponto o departamento comercial irá chantagear o departamento de projetos para fazer algum milagre para por as coisas nos eixos. Normalmente estamos falando de horas extra. Afinal é a única coisas que estas sabem que existe num projeto: tempo.

Veja que isto poderia ser um projeto de qualquer tipo de área. A estas pessoas tanto faz se é um software ou uma horticultura que estão construindo. Porque na cabeça delas basta arranjar um profissional que saiba fazer o que eles prometeram. E a arrogância nãos lhes permite enxergar que o que prometeram era completamente irrealista.

O processo tradicional começa com promessas irrealistas, mas o descalabro não acaba aqui. O próximo passo é montar a equipe.

Aqui começar contas interessantes. O gerente do projeto chuta que com R recursos ( não pessoas, recursos) sendo 98% juniors 1% plenos e 1% séniors dará para realizar o projeto no prazo e no custo. em outras palavras : contratamentos um bando de mão de obra barata e alguns sêniors para serem o culpados de tudo e alguns plenos para realmente fazerem alguma coisa funcionar. Isto porque um sênior que é sênior não vai tolerar certas coisas e acabará saindo do projeto quando poder. O pleno foi instigado pelo gerente que tem potencial para ser sênior e se ele o demonstrar será aumentado. Veja, um pleno é um cara que tem capacidade tecnica quase como um sênior para ainda pensa como um junior. Por isso é facilmente seduzido pelas artimanhas da gerencia.  Lembrar que no processo tradicional todas as promessas são irrealistas. Inclusive as que dizem respeito aos “recursos”. Tudo não passa de um tecnica de manipulação. A velha cenoura que você nunca comerá. Isto faz dos “recursos” burros.

Obviamente com uma equipe meia boca o projeto só tem um fim possivel : desastre. A fase de levantamento é engolida pela fase de negociação ( que todo o mundo no processo tradicional esquece) , a fase de analise é regida por um cronograma em vez de um risco do desconhecido e chegamos no desenvolvimento. AH! afinal o que interessa é programar o software. Esta atividade também é regida pelo cronograma em vez do estado de conclusão das tarefas e passamos aos testes. Aqui uma equipe chamada de QA (Quality Assurance – Assertividade de Qualidade)  é chamada para verificar que o software funciona. Aqui as coisas mais engraçadas acontecem. Por exemplo, a equipe de QA não sabe como o sistema deveria funcionar e testa no feeling. Não ha documentação que diga o que o sistema tinha que fazer ou como reagir em certos casos. Todas as mensagens em tela são considerados erros e impedivos para continuar testando embora a mensagem apenas informa que o usuário fez merda ao imputar certo dado … etc… Enfim, o QA sempre é uma piada. O que deixa os desenvolvedores putos da vida porque do ponto de vista deles, eles é que sabem como o sistema funciona, mas a gerencia só observa a palavra dos testers. E claro, além disso tudo ha a correção de bugs.

Afinal uma equipe medíocre, cujo objetivo nisto tudo é apenas o dinheiro no fim do mês e uma promessa de promoção, mas que sofre para caramba e trabalha 3 vezes mais que todo o resto da empresa sofre muita pressão e por consequência, se engana muito. Dai os bugs. É certo responsabilizar o júnior pela sua falta de competência ? Não. É certo culpar o Sênior por não ter treinado o junior ? Não. Primeiro porque ha juniors que se acham os donos do pedaço e  segundo porque ninguem paga ao sênior para treinar ninguem. Treinar é coisa de Coach, e isso é outra função e outro salário.

Mas assim é tudo uma zona. Como será possível uma empresa trabalhando assim chegar a algum resultado ? Não é. Só que todos se enganam mutuamente de uma forma tão bem orquestrada que tudo continua na mesma. O rei vai nu. Todo o mundo sabe, mas ninguém tem coragem para fazer nada. Isto significa que as pessoas acabam vivendo descontentes e acabam abandonando a empresa por outra, na esperança que a próxima será diferente. Não nunca é.

Porque você acha que em software todo o mundo é PJ ? Porque a rotatividade é enorme, e a empresa sabe disso. Logo ela diminui os custos de rotatividade ( contratação/ despedimento) usando o mecanismo de PJ. O que isto diz sobre as empresas ? Elas são ruins e sabem disso.  Uma empresa que acha que vai manter seus funcionários (nao “recursos”) aposta neles. Treina. Cumpre o que promete. Ouve. Muda. E com isso mantém o nivel de descontentamento baixo e a moral alta.  Como disse o fundador da Honda :”As pessoas não vêm para o trabalho para trabalhar, elas vêm para se satisfazerem”. Isto é especialmente verdade em trabalhos intelectuais como é a construção de um software. É bem diferente do trabalhador que trabalha para comer.

O processo tradicional é, portanto, marcado pelos seguintes aspetos:

• Falta e estimativas com base em dados relativos ao sistema que será realizado
• Incorreto conhecimento sobre as fases do projeto de software. Ignorância de processos, regras, resultados, estudos , etc … publicados em livros ou outros meios da comunidade de software (os gerentes leêm revistas de negócios, não de software)
• Promessas irrealistas a todos. Sejam clientes, funcionários, chefes ou subordinados
• Falta de compromisso com as necessidades do cliente.  Não importa o que ele quer. Importa quanto queremos receber dele e quando.
• Conhecimento que o escopo irá aumentar, mas insistência teimosa em adotar um modelo de escopo fixo.
• Falta de conhecimento de como funciona uma equipe de software e achar que qualquer bando de pessoas é uma equipe
• Falta de controle ao longo do processo para saber se realmente chegaremos na meta e preferencia por enganar todo o mundo a pensar que vai dar certo. Parecem desconhecer o ditado que “se pode enganar a todos a algum tempo, e a alguns todo o tempo, mas não a todos todo o tempo”. Os gerentes são mestres a enganar poucos todo o tempo porque apenas se reportam a 1 ou 2 pessoas acima deles e quando chega a hora da verdade a culpa é da equipe que era ruim. Mas lembrar que a qualidade da equipe nunca foi medida, nunca foi um fator.
• Falta de respeito pelos profissionais de desenvolvimento que são tratados como gado e não como pessoas inteligentes com capacidades intelectuais especificas como abstração espacial e matemática .
• Total descaso se alguém tentar provar que o rei vai nu. Isso é já sabido e incômodo de ser comentado.

 

Com certeza você já participou de um algum projeto em alguma empresa que trabalha assim. Aliás , quando é que você trabalhou em uma empresa que não trabalha assim. No Brasil este modelo é tão comum que é um vírus. O único antidoto seriam empresas novas, adotando outros processos que pudessem levam estas à extinção.  O problema é que: 1) sempre existirão desenvolvedores de péssima qualidade posando como sêniors, sempre existirão plenos mercenários que só estão ali pelo dinheiro e juniores crédulos e ingênuos. Isto que a comunidade de desenvolvedores não tem uma sólida e firme base moral  e ética de valores que lhes permita distinguir o certo do errado, o abuso da necessidade; 2) as empresas não querem treinar ninguém. Querem mão de obra que faça o que eles pedem, nas condições que eles pedem, por muito absurdas e imbecis que sejam; 3) clientes que não enxergam que estão sendo enganados.

Em processo tradicional a empresa acha que está tirando vantagem tanto do cliente como dos fornecedores ( desenvolvedores). Mas na realidade, os desenvolvedores juniros estão de passagem, fazendo curriculum para a próxima entrevistas. Os sêniors estão de saco cheio de tanta imbecilidade e falta de profissionalismo de todos os envolvidos que fazem orelhas moucas e os plenos ainda se enganam a si mesmos com um ideal e uma promoção. No dia que cai a fixa, eles vazam. O cliente por outro lado está tirando vantajem da empresa pagando muito menos do que deveria como conseguiu colocar uma corda no pescoço da empresa e é só apertar um pouquinho que a empresa faz qualquer coisa, de graça. Quem está parasitando quem neste modelo ? É na realidade uma simbiose de parasitas num ciclo de vida complexo em que todos acham que ganham, mas todos realmente perdem.

Agora imagine quanto perder o usuário do software que sai de um processo destes. E se num hospital o paciente é a prioridade, em software é o usuário.

Da próxima falarei do processo clássico. Até lá.