Processos e Metodologias não vão te Ajudar

Original de 3/4/2011: Gestão 2.0

Depois de tanto tempo falando de metodologias, processos e procedimentos, existe uma coisa que já deveria ser óbvia mas que a maioria das empresas ignora: metodologias nunca vão substituir bons profissionais.

Se eu disser isso a qualquer um, todos vão dizer: “mas isso é óbvio”. E minha vontade é retrucar: “então por que diabos você está tentando implantar essa metodologia?”

Antes de mais nada, vamos a algumas definições:

• Metodologia: um sistema de métodos usados em uma área particular de estudo ou atividade.
• Processos: uma série de ações ou passos tomados para atingir um determinado objetivo.
• Procedimento: uma maneira estabelecida ou oficial de se fazer alguma coisa.

Notem que em desenvolvimento de software sempre falamos em processos ou metodologias, nunca em procedimentos. Isso porque não existe uma maneira estabelecida ou oficial de se fazer software. O problema é que a maioria das pessoas confunde processos e metodologias com procedimentos e tenta aplicá-los como se fossem a maneira “oficial” de fazer software. E não são.

Por isso mesmo, disputas do tipo Ágil vs PMI não fazem sentido. O PMI chama seu conjunto de processos de PMBOK, onde BOK significa Body of Knowledge, ou “Corpo de Conhecimento”, justamente porque não é um procedimento. É apenas um conjunto de conhecimento que pode ou não ser útil dependendo do seu setor de atividade. Ágil não é diferente disso: um conjunto de metodologias e técnicas que pode ou não ser útil na sua empresa. Nenhuma delas, e nenhuma das outras, é procedimento. Entenda isso primeiro.

Entendido isso, vem o segundo erro. Quem não pratica desenvolvimento de software identifica que o software gerado é de baixa qualidade. Os indicadores são óbvios: reclamações de clientes, reclamações internas, percepção de demora excessiva para concluir qualquer trabalho de software, e assim por diante.

Vendo isso, a primeira conclusão a que chegam é: “faltam procedimentos”. E começa a procura pelo elo perdido. Encontram vários processos e metodologias e tentam institucionalizá-los. Por um pequeno período parece que o resultado é o esperado, mas não demora para ver que as coisas não mudaram tanto assim. Então culpam as metodologias por “não funcionarem”.

Desenvolvimento de software é uma atividade de “prática”. E cuidado: “praticar” e “ser prático” não são a mesma coisa. Cabe mais uma definição:

Prática: 1. a aplicação ou uso real de uma ideia, crença, ou método em oposição a teorias sobre sua aplicação ou uso. 2. exercício repetitivo em ou performar em uma atividade ou capacidade de forma a adquirir ou manter proficiência nisso. (Leia definição mais apurada na Wikipedia.)

Repitam comigo: se você não pratica software, você não entende software. É como dizer que você era bom de futebol 10 anos atrás, mas não pratica mais e mesmo assim quer acreditar que continua bom. Se você não pratica há 10 anos, você é ruim há 10 anos, e não há o que discutir.

Em software, não praticar continuamente, diariamente, deliberadamente, há 5 anos é o mesmo que um engenheiro civil dizer que não pratica engenharia há 50 anos. 5 anos em idade de software é uma eternidade.

E se você não pratica software, você não tem nada a dizer a respeito, por definição. Então vai a dica: processos e metodologias não vão ajudá-lo, justamente porque não são procedimentos.

Se software tivesse procedimento, não seria uma prática. Bastaria seguir mecanicamente a série de passos e, no fim, se teria software de qualidade. Mais que isso: se fosse procedimento, já seria possível ter software que gera software sozinho, sem nenhuma ajuda humana. Mas isso não existe, e nem vai existir.

Se um restaurante tem comida ruim, processos não vão ajudá-lo; trocar de cozinheiro sim. Se sua orquestra toca mal, processos não vão ajudá-la; trocar os músicos sim. Se seu time de futebol joga mal, processos não vão ajudá-lo; trocar os jogadores sim.

Trocar talvez seja drástico. Antes disso, eu diria que “praticar” e “treinar” certamente vão ajudar. Mas aí é que está: se seu jogador de futebol acredita que só precisa jogar depois de bater o cartão de entrada, e pode parar quando bate o cartão de saída, ele não é um bom jogador. Então forçá-los a treinar não vai ajudar e, por consequência, processos e metodologias definitivamente não vão ajudá-lo.

Com um bom programador é a mesma coisa. Você não precisa obrigá-lo a colocar seu código num repositório versionado: ele mesmo vai sentir falta disso e resolver. Você não precisa obrigá-lo a testar seu código: ele mesmo vai sentir falta e resolver. Você não precisa obrigá-lo a refatorar: ele mesmo vai perceber que está ruim e resolver.

Um bom profissional de prática não precisa que outros lhe digam o que fazer. Ele sabe o que constitui um bom trabalho e vai executá-lo de acordo, ou vai procurar o que lhe falta e treinar até se tornar proficiente nisso.

Um bom profissional de prática vive com a ideia de que precisa ser hoje melhor do que era ontem, e manter esse ritmo todos os dias. Um profissional de procedimento sabe que seu trabalho de hoje é igual ao de ontem.

Essa é a diferença. Se sua empresa fabrica parafusos, ela segue procedimentos. Hoje existem pessoas montando esses parafusos, seguindo procedimentos; amanhã você provavelmente as substituirá por máquinas que farão o mesmo trabalho melhor e mais rápido. É o destino de todo profissional de procedimento.

Se sua empresa é da área de gastronomia, música, esporte, literatura, arte ou software, você quer profissionais de prática. Caso não tenha, lembre-se: processos e metodologias não são procedimentos. Processos e metodologias não podem ser instalados como procedimentos. Processos e metodologias nunca vão transformar pessoas com mentalidade de procedimento em profissionais de prática. E sem profissionais de prática, seu resultado sempre será ruim.

Nós desenvolvemos software faz mais de 70 anos. Se a solução fosse tão simples assim, não acham que todo mundo já teria feito dessa forma décadas atrás, com resultados de excelência continuados por décadas? Não seja ingênuo achando que encontrou o “elo perdido”: ele não existe.

A única coisa que podemos fazer, sempre, é tentar amanhã ser melhor do que hoje. Mas isso não se faz com reuniões, comitês, procedimentos, receitas mágicas, gurus ou palestras. Se faz com prática. Quer ser melhor em software? Pratique software.

Agora, você tem uma boa equipe, bons profissionais que realmente se importam com a prática? Aí sim, refinar os processos e aplicar boas técnicas e táticas vai melhorar ainda mais. Mas a ordem é esta: bons profissionais primeiro, depois boas metodologias. Repetindo: boas metodologias não criam bons profissionais, mas bons profissionais com certeza saberão tirar vantagem de boas metodologias.