Processo de Software Tradicional 

Feb/12
6

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á.

 

 

3 comentários para “Processo de Software Tradicional”

  1. Falou-se que o processo tradicional √© marcado por um processo “inventado”. Concordo, e o que tenho a dizer √© que ele dar√° certo, dependendo de QUEM o inventou. No exemplo citado foi o departamento comercial, mas poderia ter sido tamb√©m um departamento de projetos competente. E por competente entenda-se n√£o ser submisso como o exemplo citou. O departamento de projetos tem que se impor sobre o comercial na defini√ß√£o de prazos e impactos, afinal isso n√£o √© competencia do comercial. Portanto o erro est√° a√≠, e n√£o no fato de se “inventar” um processo.

    A √ļnica diferen√ßa dos processos burocr√°ticos NA PRATICA √© que o burocr√°tico demora mais. No fim das contas as coisas precisam ser din√Ęmicas de qualquer jeito, sen√£o o projeto n√£o sai. √Č imposs√≠vel seguir uma metodologia burocr√°tica √† risca, em desenvolvimento de software.

    O que realmente faz a diferença entre ser melhor ou pior é a COMPETENCIA, e esta nenhuma metodologia jamais irá substituir.

  2. […] post anterior falei de como se sabe se um processo √© tradicional ou n√£o.¬† Hoje falarei do processo […]

  3. […] posts anteriores falei de como se sabe se um processo √© tradicional ou n√£o e como se define o processo cl√°ssico.¬† Hoje falarei do processo […]

Comente

Artigos