No post anterior falei de como se sabe se um processo é tradicional ou não.  Hoje falarei do processo clássico.

O processo clássico se destingue do processo tradicional principalmente pelo compromisso dos intervenientes com aquilo que estão tentando produzir e com a comunidade que produz a mesma coisa. Aprender com as lições dos outros é importante num oficio que tem apenas 50 anos. Ainda ha muito a ser descoberto em termos de saber qual a forma mais eficiente, eficaz e barata de criar um software. Repare que “barato” tem que ver como o custo e não com o preço.

O software tem que ser barato para quem o cria e livre de risco para quem o cria. Não necessáriamente o preço tem que ser pequeno ( Quanto custa o seu preço ?).

Veja que existem muitos pontos em comum entre o processo tradiciona e o clássico. Isto acontece porque quem usa o processo tradicional normalmente acha que está usando o processo clássico. Ou pelo menos essa é a sua intenção.

O processo clássico começa da mesma forma que o tradicional.: transformar 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 propõe que o cliente aceite conversar com alguém da área de projetos.  A area de projeto envia 2 ou mais pessoas com capacidades de Levantamento.  Normalmente um analista e um domain expert.  Não envia apenas uma pessoa. Isso seria um erro. E não envia  mais que 3 pessoas, porque isso seria desperdicio. A equipe é focada em levantar os requisitos macro de forma a que seja possivel estimar o risco do projeto e o tamanho do escopo.

Repare que no tradicional o risco é ignorado e o tamanho do escopo é irrelevanta pois será fixo.

O processo de levantamento leva de 5 a 10 dias de entrevistas com vários stakeholders. O objetivo não é criar codigo, mas saber o que o cliente precisa e não precisa. O que ele quer agora, o que ele não quer agora e o que ele nunca irá querer. Quanto mais as palavras “sempre” e “nunca” são usadas em um requisito maior o risco do requisito.

O risco do requisito é importante para saber o quão estável é aquele requisito.

Daqui a equipe de projeto determina o prazo minimo,  máximo e expectável do projeto ( o mais provável). Determina também quais áreas/requisitos irão precisar de mais detalhamento e em que grau. Por exemplo, um requisito padrão como login, normalmente é estável e precisa de poucas entrevistas. Um requisito como integração com legado é um requisito complexo, de alto risco que precisa de mais entrevistas.

A equipe de projeto detremina também as capacidades que a equipe de execução terá que ter. A tencologia, a estrutrua, a infra-estrutura, o processo usado, a necessidade de comunicação, o nivel de qualidade, o tempo disponivel (baseado no time-to-market) , etc… são constrangimentos ao tipo de equipe necessária. 4 séniors são uma equipe pequena , facil de gerenciar, que produzem boa qualidade e baixo numero de erros, mas mais cara. Uma equipe de 8 juniors é mais barata, mas produz mais erros e é mais dificil de gerenciar face à falta de maturidade.

É vital que o levatamento direcione as perguntas. A conclusão mais importante de todas é saber se o projeto será time-driven, feature-driven ou plan-driven. Em um projeto time-driven existe um requisito temporal que limita o projeto. O chamado time-to-market. Se o cliente precisa do software para uma certa data especifica, como o natal, uma feira , etc.. e se a falha em ter o o software nessa data aborta o projeto. Os projetos tradicionais são todos time-driven, mesmo quando não existe de fato um time-to-market, mas um desejo do cliente em uma data alvo.

Feature -driven acontece quando o tempo não é relevante mais sim as funcionalidades. Aqui se estabelece que o software só está pronto quando tiver as features A, B e C e todos funcionarem sem problemas. Basicamente o que interessa é cumprir o escopo e não nenhum prazo em especifico.

Plan-driven acontece quando o cliente está interessado em determinar um sub-conjunto de features em um certo prazo. O projeto é dividido em releases e cada uma tem um objetivo util e comercial para o cliente. Basicamente o software é feito em forma de upgrades, mas com uma versão 1 que se pode utilizar em produção.

A somar a todas as estimativas ha a consideração do cone de incerteza. Numa fase preliminar como esta e com um cliente com quem nunca se trabalhou, a incerteza é bem grande e deve ser considerada.

Depois de pesar todos estes fatores, determinar o perfil da equipe de execução, o risco e tamanho dos requisitos e o plano de entrega a área de projetos produz um documento de visão acompanhados da proposta de prazo e custo.

O comercial então terá que avaliar a viabilidade deste projeto. Talves não seja rentável executar este projeto. Se não for, uma discussão com o cliente e o departamento de projetos pode levar a uma simplificação do projeto, dos requisitos, uma extenção dos prazos, etc.. de forma a tornar o projeto comercialmente viável.

Feito isto o departamento comercial  propõe ao cliente algo como “Podemos fazer um sistema de XPTO para si entre N e M meses por P reais”. Veja que um prazo máximo e expetável são apresentados e não uma data fixa.

Existem várias formas de escrever um contrato e não necessáriamente os dois limites do prazo vão aparecer explicitamente. Isto porque os clientes ficam confundidos quando veêm duas datas e assumem a menor. Um forma de por isto de uma forma mais digerivel é usar um contrato assim :

“Podemos fazer um sistema de XPTO para si em N meses por P reais. Com um prémio Z que decai até M meses.”

P é o custo do projeto com um lucro embutido. Z é um valor calculado tal que seja igual a P ou maior até um percentual do periodo entre N e M. Este percentual depende do risco e da confiança em N. Ou seja, quanto mais confiante menor este percentual.

Existem muitas formas. O ponto é considerar que a data expectável tem uma probabilidade menor que a data máxima. A empresa e o cliente são recompensados se a data expectável for correta, caso contrário a empresa é penalizada. Este conceito de penalizar a empresa e não o cliente é completamente desconhecido no processo tradicional.
Supondo que o cliente concordou com os termos temos agora um projeto com prazo, preço e escopo definido.

A mudança de escopo é feita segundo um processo de mudança de escopo normalmente recorrendo a um comité e todas as alterações para cima são cobradas pela empresa provedora. As alterações para baixo são colocadas em um “banco” para serem descontadas na seguinte mudança para cima. Isto só acontece porque todo o requisito tem um risco e um tamanho associados.

O próximo passo é detalhar o levantamento já iniciado e em paralelo começar a desenhar uma arquitetura e infra-estrutura.  Nesta fase (analise) o levantamento mais detalhado pode levar a alterações no escopo que podem levar a alterações no resto do projeto.  Todos os requisitos são detalhados e partidos em requisitos menores até que seja possivel transformar o requisito em tarefas de execução.

Durante esta fase de analise os requisitos são também analisados e sentitizados de forma a chegar num numero minimo de requisitos que atendem os requisitos iniciais.Com a arquitetura testada e aprovada e os requisitos detalhados um documento de especificação é produzido.

Em paralelo a equipe de execução é montada e os requisitos são partidos em tarefas, por ela. As tarefas são cotadas com um tamanho por um processo como o Wideband Delphi, por exemplo. A gerencia de projeto usa estes numeros para corrigir a sua estimativa inicial. Se menor, o plano original é mantido. Se maior, o cliente é acionado para modificar a prioridades dos requisitos de foram que se o tempo explodir, apenas as features menos relevantes ficarão de fora.

Passa-se então à execução. Durante a execução, novos requisitos são introduzidos, alterações são necessárias, o comité de mudança é acionado e os requisitos são constantemente analisados e sintetizados. Em paralelo os planos de teste começam a ser construidos.

Passa-se então à execução dos testes. A equipe de QA tem o documento de requisitos e os planos de teste para se guiar e não precisa inventar casos ou cenários que não estejam ali. Contudo, falhas, hiatos funcionais ou de implementação levarão a equipe a recomeçar por analizar os requisitos, modificá-los , modificar o codigo e a documentação.

A taxa de testes com sucesso versus a taxa de bugs são computadas pela gerencia e considerando o cone de incerteza obtemos uma nova estimativa de sucesso ou não do projeto. Novas priorizações são feitas pelo cliente.

Emquanto os testes estão sendo feitos,o cliente revisa os requisitos finais com a equipe de requisitos. Modificações, disparidades, hiatos levarão a equipe a recomeçar por analizar os requisitos, modificá-los , modificar o codigo e a documentação.

No fim deste processo, os testes terão garantido a qualidade tecnica do produto e a revisão dos requisitos terão garantido que o software faz o que o cliente quer. Finalmente temos a fase de homologação em que o cliente usa de fato o software. Quaisquer pedidos de modificação são comparados com os requisitos. Quando o pedido não base com o requisito ele não é realizado. Esta não é uma fase onde o cliente pode inventar coisas novas. Alterações que não sejam devido a bugs serão simplesmente deixadas para outro projeto no futuro.

O processo classico não começa com promessas irrealistas. As coisas são medidas e estimadas by the book ( seguindo os livros). O andar do projeto é medido em certo pontos o cliente faz os ajustes. A empresa nunca prometeu realizar tudo, mas sim cumprir o objetivo inicial ( time-driven, feature-driven ou plan-drive).  Ou seja, a empresa está comprometida em cumprir um plano e não em cumprir o desejo do cliente. O cliente é livre de mudar o plano, basta que pague a diferença.

A equipe é contratada depois que se sabe o que o sistema irá fazer. Os requisitos já estarão detalhados o suficiente para quando a equipe existir ela poder realizar a quebra em tarefas. O risco de escolher uma equipe junior uma sênior, ou um misto é imputado nas estimativas e não é deixado ao acaso. Nada é deixado ao acaso excepto o real andamento do projeto. O projeto é devidamente documentado para que nem o cliente nem a empresa tenham duvidas sobre o que é para fazer e o que não é. O resto é superfluo, não necessário, e relegado para um próximo projeto.

A equipe sabe exactamente o que tem que fazer e pode ser organizada da melhor forma para cumprir esses objetivos no minimo tempo possivel já que o objetivo interno da empresa é alcançar a data expectável (e não a data máxima, que está no contrato). Internamente o projeto é guiado de uma forma e com um objetivo, enquanto que externamente ele é guiado de outra forma com objetivos iguais mas tempos mais dialatados

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

• Não se  faz nada sem estimar antes e as estimativas não são viciadas. Para não viciar as estimativas processos padrão explicitos na literatura são usado.
• As fazes do projeto são respeitadas e executadas à risca: Negociação, Levantamento, Analise, Desenvolvimento, Teste  e Homologação.
• Não são feitas promessas. É estabelecido um contrato, com regras, prazos, coisas a esperar e principalmente coisas a não esperar. Tudo é feito de comum acordo e sem mecanismos de submissão.
• O cliente é respeitado. É informado de todos os problemas e todos os riscos. Todas as suas decisões são guardadas para futuro uso ou confrontamento. Se o cliente se enganar, ele se enganou. Se nós nos enganarmos, nós nos enganámos. Sem problemas.
• O escopo é controlado rigidamente e qualquer desvio afeta o resto do projeto. O plano é modificado e o contrato com ele.
• Conhecimento das capacidades e funções dos membros da equipe. Responsabilização pela equipe que montou.
• Sempre que ha um problema qualquer pessoa pode levantá-lo e alertar.

 

O processo clássico é bem estricto. É um processo Stage-Gate com a possibilidade de em cada gate haver uma avaliação do projeto e novos planos serem feitos e novas direções sendo tomadas. Contudo tudo isto e feito com base em numeros e dados e não em chutes ou promessas.

Este processo é extremamente rígido e para funcionar a contento as pessoas que o usam tem que ter uma certa experiencia. É por isso que é importante seguir o processo by the book. O que acontece na prática é que as pessoas leêm os livros mas logo interpretam ou subjugam o que o livro diz para o seu caso sem nunca ter dado uma chance ao processo canónico. É isto que gera a inventividade dos processos tradicionais. A intenção das pessoas é boa, mas sua arrogância é maior e se acham capazes de desafiar o que os autores levaram anos para descobrir e documentar. O exemplo clássico é desconsiderar o cone de incerteza, ou sequer saber o que ele é. Outro é não forçar um processo de mudança de escopo como deve ser com medo que o cliente se assuste quando a empresa disser que não irá fazer tal coisa e o cliente vá embora.  Os medos e inseguranças das empresas de software levam a que rapidamente alterem o que está escrito e começem o processo tradicional. É um mecanismo semelhante ao que acontece com a biblia. um escrito, mil interpretações.

Por outro lado, seguir as regras by the book não significa que as tenha que seguir mesmo quando estão erradas ou não correspondem com o seu caso. Contudo é preciso ser humilde e disciplinado para apenas mudar a regra quando so dados demonstram que ela não é eficaz no seu caso, e que, por algum motivo, o seu universo amostral é estatisticamente  diferente daquele usado pelo autor do livro.

O processo clássico deixa margem de manobra para alterações, só que ele exige provas de a mudança é necessária. Como a maioria dos gerentes faz um pessimo trabalho coletando dados do projeto nunca ha como provar nada e é aí que entra o chute, a artimanha e a politica. E mais uma vez a porta está aberta para o processo tradicional.

Sendo um processo rigido e dificil de seguir, embora muito simples de entender, o processo classico fácilmente se trasnforma no processo tradicional porque os intervenientes não têm a indole moral ou a retidão necessária para executar o processo como deve ser.  Contudo, se você perguntar, muitos irão dizer que estão usando a tecnica A ou B do autor X ou Y, mas se olhar de perto não estão. Simplesmente porque subverterem o que a tecnica significa e deturparam o seu significado

Se seguir o processo como deve ser, verá que ele é muito lento e burucrático. A burocracia advém do fato de constantemente ter que saber se o requisito A ou B está ou não no escopo e algumas vezes isso é subjetivo. Isto levou algumas pessoas a considerar que se dá muita importancia ao processo e pouca ao interesse do cliente ou da execução do software. Ou seja, o cliente é honorado pelo seu próprio desconhecimento do software que ele quer. mas se o cliente soubesse o que ele quer, ele mesmo teria feito o software sem contratar a empresa.

Daqui nasceram tentativas de melhorar o processo classico deixando o seu core de boas práticas, medições, auferições, mudança de planos mas modificando as regras de forma a que o processo fosse mais simples, menos burucrático, mais ágil.

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