Também sobre o gerenciamento de planos de projetos

Thread Content

O que Bai Yunfan escreveu por conta própria, para ser discutido com todos. Ontem vi um post no círculo de amigos sobre gestão de planos de projetos. Nele, eram abordados os impactos da gestão de planos de projetos em aspectos como design, aquisições, construção e supervisão, além de serem apresentadas algumas estratégias para lidar com esses desafios. À primeira vista, parece fazer algum sentido. Mas, ao analisar com cuidado, percebe-se que na verdade são apenas desculpas que os planejadores costumam usar quando os planos não são realizados no prazo previsto. Muitas pessoas entendem o planejamento apenas como uma questão relacionada ao triângulo formado por cronograma, qualidade e custo, e acham que isso é a essência da gestão de projetos, falando sobre isso com entusiasmo. Essa compreensão, ao colocar de maneira unilateral e artificial qualidade, prazo e custo em oposição um ao outro, fica apenas na superfície da gestão de projetos. Na minha opinião, um bom plano não só consegue resolver os problemas relacionados ao andamento dos trabalhos, mas também consegue equilibrar as contradições entre qualidade e prazos. Então, o que é, afinal, um plano? Em inglês, plano é “Plan”. E “Plan” não significa apenas plano, mas também solução ou estratégia. Ou seja, o plano não pode ser apenas uma lista simples de prazos; ele deve, e precisa, estar integrado ao projeto como um todo. Um plano que não leva em consideração as soluções práticas é, na verdade, apenas uma hipótese de Goldbach teórica, sem qualquer valor real. Como, afinal, deve-se elaborar um plano? Em muitos livros didáticos do país, é enfatizada a hierarquização dos planos. Geralmente, o plano de nível superior é dividido em planos de nível inferior, e assim por diante, numa estrutura que vai de cima para baixo. Devo dizer que esse tipo de planejamento vai contra os princípios e o propósito do próprio planejamento, o que inevitavelmente leva a planos do tipo da Conjectura de Goldbach. Por quê? A lógica é simples: e se o próprio plano de primeiro nível for irrealista? Ou talvez um dos pontos do seu plano secundário seja, em si mesmo, uma bobagem? No PMP, são apresentados os procedimentos gerais para a elaboração de planos. O trabalho de base para a elaboração do plano é a definição do escopo dos trabalhos, o que se enquadra na área de gestão de custos. O escopo do trabalho deve ser dividido em níveis, de acordo com uma determinada estrutura, e assim formar pacotes de trabalho. É importante ressaltar que o próprio pacote de trabalho deve incluir a gestão do projeto, pois cada pacote de trabalho corresponde a uma conta de controle de custos, que serve como base para o controle dos custos. O pacote de trabalho em si deve servir como base para definir o escopo dos trabalhos e os custos do projeto com o cliente. Com base nos pacotes de trabalho, realiza-se a subdivisão das tarefas; nesse momento, trata-se, na verdade, da fase de detalhamento do plano de implementação. Nesta fase, é necessário realizar uma decomposição detalhada do trabalho contido em cada pacote de tarefas. Da mesma forma, dependendo do tamanho do projeto, pode-se exigir que a granularidade do trabalho a ser realizado não exceda 5 horas-homem, ou 10 horas-homem no máximo. Além disso, de acordo com o plano de execução, os trabalhos detalhados devem ser organizados em sequência. No processo de divisão dos pacotes de trabalho, bem como no processo de detalhamento das tarefas, inevitavelmente haverá algumas coisas incertas. Esses itens devem ser registrados no registro de riscos do projeto, sendo alvo de monitoramento atento durante a elaboração e execução do plano do projeto. Se necessário, devem ser elaboradas alternativas. Após a elaboração do plano de horas trabalhadas, é que o engenheiro de planejamento realmente começa a atuar, fazendo um levantamento das tarefas a serem realizadas, criando um gráfico que mostra as necessidades de mão de obra e discutindo as soluções possíveis para otimizar o fornecimento de recursos humanos. Apenas classificando e resumindo os planos de emissão é que se pode obter a primeira versão do plano de trabalho. Com base nisso, são realizadas discussões e otimizações em relação aos pontos-chave do projeto, e, se necessário, são feitos ajustes nos próprios pontos do projeto. Por fim, com base nas condições reais do projeto, o plano do projeto é otimizado e o cronograma de trabalho é ajustado, resultando em uma versão aprimorada ou no plano final. Como o tempo de trabalho e os materiais necessários para cada um dos planos já estão especificados nos pacotes de trabalho e nas listas de tarefas detalhadas, o plano em si já inclui o controle dos custos. Como o próprio plano já detalhou a gestão do projeto como um pacote de trabalhos, a gestão da qualidade do projeto também foi incluída no plano do projeto, com recursos apropriados sendo alocados para isso. No processo de discussão dos recursos e custos, o plano já foi objeto de análise e definição preliminares, e os riscos foram identificados. Portanto, o próprio processo de elaboração do plano é um processo de controle de riscos. Em vez de realizar uma análise rígida dos riscos do projeto. A lista de condições hipotéticas no processo de elaboração do plano, bem como a abordagem utilizada na própria elaboração do plano, determinam a viabilidade do plano do projeto. Como um plano, uma vez aprovado, o foco do gestor de projetos passa para o controle dos riscos em cada etapa. Na fase de implementação do projeto, por um lado, é necessário controlar com atenção as condições hipotéticas subjacentes à elaboração do plano do projeto, ou seja, os riscos. Por outro lado, deve-se analisar os pontos que ainda não foram concluídos, a fim de fazer os ajustes necessários no plano restante. Sim, o plano deve e precisa ser ajustável. Um plano que não pode ser ajustado só pode ser chamado de bobagem e ostentação. Porque o plano é o guia que cada pessoa utiliza para organizar seu trabalho diário. Mas, quando o seu plano já apresenta desvios significativos e de longo prazo em relação à realidade, como ele pode continuar a orientar a execução do projeto? Na minha opinião, isso é algo muito sério. Um plano que não é sério é um plano sem dignidade; um plano sem dignidade, inevitavelmente, leva a um projeto fracassado. No exterior, existe um processo chamado “Lessons learned”, que na verdade é a implementação e aplicação do PDCA para o controle de qualidade. Isso também se aplica à gestão de planos. Através da análise das situações de desvio, é possível identificar muitos pontos que merecem atenção durante a execução posterior do projeto, visando assim minimizar seus riscos. Do ponto de vista de um estrangeiro, especialmente de um americano, um projeto consiste simplesmente em criar um plano e, em seguida, seguir esse plano passo a passo para implementá-lo. Aqueles que elaboram o plano são as pessoas de alto nível do projeto, enquanto aqueles que o executam parecem não precisar de um QI muito elevado. De repente, senti vontade de escrever algo, então acabei escrevendo tanto, sem parar.