//
você está lendo...
Gerais

Remédio ou Veneno?

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?

Série americana "Dr. House"

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.

Sobre Fábio Cruz

Fábio Cruz tem mais de 24 anos de experiência na área de TI, trabalhando em diferentes papéis no desenvolvimento de produtos e no gerenciamento de ciclo de vida de aplicação (ALM), com histórico comprovado como desenvolvedor, arquiteto de aplicação, líder técnico, analista de negócios e gerente de projetos. Nos últimos 10 anos tem apoiado equipes na construção e entrega de soluções tecnológicas em diferentes nichos como educação, varejo, financeiro, energia, ecommerce (b2c, b2g, b2b), entre outros, em empresas nacionais e internacionais incluindo times remotos ao redor do mundo. Também tem atuado como autor, trainer, palestrante, empreendedor e acumulei experiência como voluntário. É sócio e fundador da FabioCruz.com, no qual tem se apresentado como Enterprise e Agile Coach atuando como agente de mudança nos últimos 6 anos, implementando ágil e conduzindo transformações organizacionais, ajudando na melhoria do processo de desenvolvimento de software, ensinando e capacitando novos Scrum Masters, Agile Coaches, Product Owners e Times de Desenvolvimento sobre como construir e entregar software de forma mais rápida, com eficiência e efetividade usando boas práticas ágeis como Alto Valor Agregado, Desenvolvimento Iterativo, Integração Contínua, Automatização de Testes, Melhoria Contínua, Clean Code, Refatoração, Code Review, TDD e BDD, além de Scrum, Nexus, XP e Lean.

Discussão

Nenhum comentário ainda.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

fabio cruz no twitter

Categorias

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Junte-se a 10 outros seguidores

%d blogueiros gostam disto: