Algumas questões semprem rondam projetos de diversas naturezas, uma delas é sobre a dosagem de várias técnicas, práticas, formalismos, documentações ou outras ferramentas. Entre outras palavras, até que ponto a formalidade traduzida em documentos do projeto, por exemplo, ajudam na resolução de problemas e no gerenciamento do projeto em si, e a partir de qual ponto esta formalidade se torna excessiva e passa a atrapalhar e prejudicar o projeto?
Se nos colocarmos no lugar de um médico, apenas para ilustrar é claro, podemos pensar nos remédios.
Por exemplo, quando um médico receita:
- Medicamento: Paracetamol 750mg
- Posologia: 1 comprimido por vez, de 3 a 5 vezes ao dia
- Indicação: Enquanto houver dores ou febre.
Este medicamento agirá como remédio aliviando os sintomas e gerando um bem estar se consumido conforme a receita. Porém, normalmente o médico dirá ao final da receita: “Não tome mais que 5 comprimidos ao dia“. Isso significa que se o paciente exceder este limite o medicamento agirá de forma maléfica ao organismo, podendo causar uma intoxicação, ou envenenamento, e dependendo da dosagem, até a morte.
É assim com os projetos, uma técnica pode trazer benefícios ou levar um projeto ao fracasso, justamente porque as vezes não se entende ou não se avalia a seguinte questão: Remédio ou Veneno?
Um dos temas mais polêmicos ainda é referente a documentações ou formalizações. Principalmente porque atualmente há uma certa concorrência entre modelos tradicionais e ágeis de gerenciamento de projetos, onde algumas pessoas interpretam o tradicional como excesso de documentos, e o ágil como ausência de documentos. O que não é verdade!
Acredito que o raciocínio seja exatamente o do remédio ou veneno. As documentações não são o problema, ou não é o processo de documentar que causa um fracasso de um projeto. Para se desenvolver um sistema de computador, por exemplo, é preciso se entender o negócio que será atendido pelo sistema, e uma documentação mínima precisa ser construída, como por exemplo especificações de regra de negócio e protótipos de tela.
Se um gerente precisa comunicar a equipe do projeto, principalmente à gerência sênior do cliente ou da sua própria empresa, ele precisará fazer frequentemente relatórios da situação do projeto para que todos os interessados saibam como está o projeto. Isso não é burocracia ou formalização excessiva, é necessidade de comunicação de cada projeto (segundo receita), e precisa ser feita com frequência (vide bula de cada projeto).
No entanto, se as especificações tomam o lugar da construção do produto do projeto, e ao final de 2 anos só há documentos e nada construído, com certeza haverá problemas. Mesmo porque depois de poucos meses aquele documento feito lá no início provavelmente precisará ser modificado ou ajustado porque o negócio evoluí, o mercado se modifica e não se pode ficar trabalhando apenas em documentação.
O mesmo ocorre com o tal Status Report do gerente, se ele fizer um relatório deste a cada 2 semanas, ou dependendo do projeto, a cada mês, tudo ótimo. Agora se ele fizer um relatório deste por dia, provavelmente ele deixará de trabalhar em pró do projeto e ficará só fazendo relatórios e enviando-os. Com certeza o projeto estará sendo comunicado, porém os resultados finais com certeza serão falhos, porque a preocupação com “posicionar” tomou o lugar do ato de executar.
Quem acompanha e aplica modelos ágeis de gerenciamento de projetos, é justamente isso que a maioria deles defende, a documentação e a formalização precisa existir e é necessária, porém o seu excesso causa prejuízos, e somente o necessário deve ser documentado.
Ao mesmo tempo várias das boas práticas de gerenciamento de projetos tradicionais, como por exemplo o Guia PMBOK®, sugere diversos documentos e técnicas de formalização de processos, e este também é um ótimo caso para reflexão. Em resumo, se um gerente simplesmente quiser aplicar todo o Guia PMBOK® em um projeto, as chances de dar errado serão grandes, por outro lado se ele simplesmente não usar nada, ou se todas as boas práticas forem ignoradas, com certeza as chances de fracasso também serão grandes.
Então, este é o recado que eu gostaria de deixar aqui. Se um projeto está doente e o gerente não aplicar nenhum medicamento a ele, provavelmente o projeto morrerá, porém se o gerente simplesmente der uma super dosagem de remédios ao projeto, irá envenená-lo, levando-o a morte também.
Faça o bom uso de práticas tradicionais, ágeis, misture, adapte, mas sempre tenha em mente que cada projeto é um projeto, assim como cada doença é uma doença diferente.
Estas dicas não valem só para projetos já “doentes”, assim como na medicina, sempre é melhor prevenir do que remediar. Sendo assim, da mesma forma que prevenimos doenças futuras com vitaminas, suplementos, alimentos balanceados e esporte, o mesmo vale para os projetos, a aplicação preventiva de boas práticas previne futuras “doenças” nos projetos, ou em linguagem técnica, elimina ou mitiga riscos.
E não esqueça: A ausência de vitaminas causa doença, e o excesso também, porém o segredo está na quantidade certa.
