Quando iniciei minha carreira profissional e a faculdade de computação eu acreditava que para se ter um projeto de sucesso era necessário bons técnicos, e isto por sí já bastava. Com o passar do tempo, observador como sempre fui desde criança, fui vendo que minha visão estava um pouco limitada sobre este assunto. Passei a estudar e observar mais sobre os aspectos gerenciais e humanos que estão por trás de uma equipe vencedora.
Foi quando esta semana iniciou-se uma discussão na lista CMM-Brasil (o acesso a esta mensagem deve ser restrito a assinantes da lista ou do Yahoo!, não sei ao certo) onde foi postado um link para um post no site linha de código. Desde a primeira mensagem postada com isto iniciou-se uma discussão enorme a respeito do assunto (quem quiser acompanhar sugiro entrar lá no grupo para ver).
Particularmente achei que o artigo confunde um pouco modelos de maturidade com obrigação de burocracia nos processos. Quero deixar claro que nunca tive a felicidade de participar da definição e implantação de processos para passarem por um appraisal formal de um modelo como o CMM, CMMI ou MPS.BR, porém pelo que estudo sobre o assunto não acredito que para se obter sucesso numa avaliação desta precise-se ter processos pessados e burocráticos. Acredito que um dos grandes fatores que diferenciam projetos bem sucedidos dos mal sucedidos é o sistema de comunicação eficiente. E efeiciente não significa que ele é 100% completo mas que é efetivo, ou seja, provavelmente ele é fácil de ser usado. O exemplo utilizado pelo colega Mateus do gerente que tinha um projeto grande e cheio de riscos que o deixavam com enormes chances de dar errado é uma prova disto, ele utilizava um quadro com post it, e este quadro não deveria ter tanta informação assim mas o suficiente para que todos os envolvidos no projeto tivessem uma visão geral do andamento do mesmo. Não adianta ter um super sistema de informações que diz até o quanto de pó de café que foi gasto para realizar o projeto até o memento se ele não é simples de ser preencido, e principalmente não é simples de ser consultado. Não conheço a fundo o projeto dado de exemplo porém pelo que foi descrito nada impediria este projeto de ser certificado em um modelo de maturidade.
Minha visão atual sobre processos é que eles devem ser os mais simples possíveis, e caso se levante necessidades ir rebuscando o mesmo com o passar do tempo. Sei que com isto o processo não vai cobrir todas as possibilidades de falhas que podem acontecer no dia-a-dia, mas acredito que o custo de ser ter um processo burocrático e lento não compensa o prejuízo diário em tempo e em satisfação da equipe com o processo. Uma coisa que aprendi na prática é que o trabalho de desenvolvimento de software é muito mais de criatividade do que de repetição, e que desenvolvedores (engenheiros ou analista, como queiram chamar) não gostam de perder mais tempo documentando e preenchendo interminaveis planilhas do que criando programas em si. Não sou contra a necessidade de se documentar o que se programa, mas isto e assunto de um outro post.
