Um rápido alinhamento de expectativas
Este artigo está dividido em duas partes. A primeira aborda o conceito de “projeto”, sua estrutura, nuances, desafios e oportunidades, além do modelo de gestão tradicional, “em cascata”; o segundo traz a perspectiva do Agile e algumas considerações finais.
Não fazem parte do escopo deste texto discussões sobre ferramentas nem estratégias sobre gestão propriamente dita, embora façamos diversos comentários sobre pontos de atenção e cuidados a serem tomados.
Antes de falar sobre metodologias, frameworks e formas de gestão, é importante entender o que, exatamente, é um projeto. De acordo com a definição do Guia PMBOK (Project Management Body of Knowledge), projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado único. Projetos são realizados para cumprir objetivos através da produção de entregas (…) tangíveis ou intangíveis.
Dessa forma, devemos entendê-lo como uma iniciativa que tem começo e fim, e que busca algum tipo de melhoria nos mais diversos diferentes âmbitos: ferramentas, métodos, processos, produtos, políticas, serviços, dentre outros. Afinal, ninguém faz um projeto para que as coisas continuem do jeito que estão, certo? (Embora, alguns tenham resultados um tanto… controversos – as famosas iniciativas de pioria.)
Um dos maiores desafios de um projeto tende a ser a interdependência de ações: como ele promove a conjunção de tarefas entre diversas áreas e disciplinas de uma (ou mais) organização, um dos elementos-chave para o sucesso é estabelecer a comunicação e a coordenação adequadas de suas atividades. E isso pode ser feito de diversas maneiras, como veremos à frente. Mesmo em projetos de cunho individual – quando planejamos um programa de desenvolvimento pessoal, uma mudança de residência ou um plano de carreira, por exemplo –, há envolvimento e interdependência de outras pessoas e situações.
Outro ponto importante é entender que algumas iniciativas podem constituir ou não um projeto de acordo com o contexto em que estão inseridas. Por exemplo: para mim, que nunca construí um carro na vida (sequer um de rolimã), fazê-lo seria um projeto; para o operário da linha de produção da indústria automobilística, construir um carro faz parte de um processo, já que representa uma atividade repetida, para qual já existe uma organização de trabalho funcional.
Feito o entendimento inicial sobre o conceito de projeto, vamos às formas de gerenciá-lo.
Projetos em cascata
O PMI – Project Management Institute – foi criado nos Estados Unidos em 1969 com o objetivo de pesquisar, discutir e formular as boas práticas de gestão de projetos. Na década de 1980, seus fundadores desenvolveram os primeiros programas de certificação na área, dando aos profissionais aprovados o título de PMP – Project Management Professional (hoje são mais de 370.000 ao redor do mundo). Um tempo depois, no começo dos anos 90, a primeira versão do PMBOK – o Project Management Body of Knowledge, traduzido aqui como Guia do Conhecimento em Gestão de Projetos – foi publicada[1].
O PMI funciona por meio de “capítulos”, que são escritórios abertos em diversas cidades do mundo e que realizam fóruns de discussão relacionados ao tema, formação e certificação de profissionais, além de fomentar uma rede de associados que atuam na disseminação de sua metodologia de gestão de projetos, contida no PMBOK. Este, por sua vez, consolida as chamadas melhores práticas de gestão de projetos e representa a consolidação do trabalho de pesquisa de milhares de profissionais da área que foram, ao longo dos anos, compilando suas experiências, desafios, cases de sucesso e, assim, aprimorando as práticas vigentes. O guia está dividido em dez áreas de conhecimento, aqui descritas muito brevemente:
– aquisições: processos necessários para comprar ou adquirir produtos, serviços ou resultados externos à equipe do projeto;
– comunicação: processos necessários para assegurar que as informações do projeto sejam planejadas, coletadas, criadas, distribuídas, armazenadas, recuperadas, gerenciadas, controladas, monitoradas e finalmente organizadas de maneira oportuna e apropriada;
– cronograma: processos necessários para gerenciar o término pontual do projeto;
– custos: processos envolvidos em planejamento, estimativas, financiamentos, gerenciamento e controle dos custos, de modo que atenda, honre e respeite o orçamento aprovado;
– escopo: processos necessários para assegurar que o projeto contemple todo o trabalho necessário, e apenas o necessário, para que o mesmo termine com sucesso;
– integração: processos e atividades necessárias para identificar, definir, combinar, unificar e coordenar as várias áreas envolvidas;
– qualidade: processos para incorporação da política de qualidade da organização com relação ao planejamento, gerenciamento e controle dos requisitos de qualidade do projeto e do produto para atender as expectativas das partes interessadas;
– recursos: processos para identificar, adquirir e gerenciar os recursos materiais, tecnológicos e afins, bem como as pessoas necessárias para a conclusão bem-sucedida do projeto;
– riscos: processos de condução de planejamento, identificação, monitoramento e análise de gerenciamento de risco, planejamento e implementação de resposta;
– stakeholders ou partes interessadas: processos promovidos para identificar as pessoas, grupos ou organizações que podem impactar, serem impactados ou ainda se sentirem impactados pelo projeto, analisando suas expectativas e respectivo impacto, para o desenvolvimento de estratégias visando o engajamento eficaz nas decisões e execução do projeto.
O termo “projeto em cascata” (waterfall project) remonta ao estilo de uma de suas principais ferramentas, o diagrama de Gantt (Gantt chart), que é faseado, lembrando os degraus da queda d’água de uma cachoeira:
Cada fase representa uma etapa de avanço do projeto e, para que a etapa seguinte tenha início é necessário que a anterior esteja totalmente concluída – o que acontece por meio de um termo de aceite assinado pelos gestores e stakeholders do projeto. O objetivo é garantir que o time e o contexto estejam prontos para avançar para o próximo bloco de atividades definido durante etapa de planejamento, sem que tarefas pendentes possam gerar problemas ou atrasos.
Em termos de estrutura, um projeto em cascata geralmente é definido pelas seguintes etapas:
– Termo de Abertura, com desmembramento em um Plano de Projeto: compreende a definição do objetivo a ser atingido, bem com as delimitações de escopo a ser entregue, prazo de execução, pessoas e áreas envolvidas, orçamento disponível e o plano de comunicação do projeto. Esta etapa é particularmente crítica, pois uma definição imprecisa do trabalho a ser realizado certamente resultará em uma série de problemas no decorrer de sua execução, seja por falta de clareza sobre o que precisa ser feito e o que será entregue ou desalinhamento de expectativas / informação. As consequências, em qualquer dos casos, partem de conflitos entre as equipes até a criação de produtos e serviços que não atendem aos objetivos desejados. Nas Oficinas de Projetos realizadas pela Arquitetura RH, costumamos compartilhar com os participantes o trecho de um filme chamado Pentagon Wars (1998, com direção de Richard Benjamim e traduzido no Brasil como “Máquina de guerra”). Baseado em um evento verídico, a criação de um veículo blindado de transporte de tropas pelo Exército Americano, ele traz uma visão contundente a respeito da importância da definição de escopo (em determinado momento, a situação de caos assume até ares cômicos);
– Kick-off: cerimônia de abertura oficial do projeto. Em geral, neste evento participam todas as pessoas envolvidas e afetadas pelo projeto, que tomarão ciência dos termos de abertura e, quase sempre, realizarão etapas de integração para que se conheçam e ambientalizem. Isto é importante, pois os projetos tendem, cada vez mais, a ser iniciativas multidisciplinares, conduzidos com a participação de pessoas de diferentes áreas e perfis, e que doravante estarão atuando juntas;
– Análise e entendimento: esta fase pode ser subdividida em duas etapas, AS IS e TO BE. O AS IS é um desenho sistêmico e/ou de processos, procedimentos, políticas, práticas e comportamentos atuais, que já são executados normalmente dentro do escopo definido para o projeto. Por sua vez, o TO BE é uma proposta de melhoria, correção ou transformação trazida pelo projeto. Aqui existe uma nuance importante, porque o sucesso do desenho do cenário futuro (TO BE) depende do entendimento correto do AS IS – afinal, ninguém quer repetir os erros presentes, tampouco complicar ainda mais as coisas. Uma dificuldade com que times de projeto frequentemente se deparam é a falta de definições claras e documentação acerca dos processos existentes. E as pessoas que os executam nem sempre seguem um padrão lógico, não havendo descrições objetivas sobre o que elas recebem do processo anterior (entradas) e o que entregam para o próximo (saídas). Sem isso, é difícil garantir qualidade, acuracidade e até os prazos de entrega das informações;
– Realização: é a execução propriamente dita, partindo do documento de entendimento. Nesta fase são produzidas também as especificações técnicas que darão suporte ao desenvolvimento das atividades. Dependendo da natureza do projeto, esta tende a ser uma das fases mais longas;
– Testes & homologação: nesta etapa, o time de projeto, com o auxílio das áreas e pessoas que receberão a entrega desse projeto, testam a solução desenvolvida a fim de garantir que ela (1) cumpre as propostas declaradas no Plano do Projeto e (2) é aderente às necessidades levantadas durante a fase de Entendimento. Para testar uma solução, a equipe de projeto elabora roteiros com etapas que devem ser realizadas, bem como os resultados esperados a partir de uma determinada sequência de tarefas. Aqui entram importantes questões de qualidade: embora o time de projeto também realize um ciclo de testes chamados unitários, para filtrar erros e problemas mais genéricos, os testes de integração mais importantes são conduzidos pelas partes interessadas (áreas de negócio, clientes etc.) na solução. São essas equipes que validarão especificidades, regras de negócio, questões legais, tributárias, contábeis, regulatórias, dentre outras. Entretanto, não basta um teste simples – enviesado – em que dados corretos são usados para se chegar a um resultado correto. É imprescindível que se realize testes amplos, incluindo situações consideradas incorretas, para garantir que elas serão bloqueadas ou impedidas de seguir adiante. Um teste de qualidade eficaz aborda quatro perspectivas:
– Entrada de dados errados com resultado errado;
– Entrada de dados certos com resultado certo;
– Entrada de dados errados com resultado certo (falso positivo); e
– Entrada de dados certos com resultado errado (falso negativo).
Idealmente, esse é o mínimo que precisa ser feito, garantindo-se que a entrada errada gera resultados errados e que a entrada certa gera resultados certos. Em sistemas de TI isso é importante, mas existem algumas áreas em que isso é absolutamente crítico. Pense na Medicina: um médico analisa informações de exames e conclui que seu paciente tem uma doença grave e precisa passar por uma cirurgia de alto risco – só que os dados dos exames não tinham precisão e, na verdade, esse paciente estava apenas com uma doença simples, que poderia ser tratada em casa, com antibióticos (falso positivo). Ou então: os dados do exame indicam que está tudo bem e, com base nisso, o médico autoriza sua liberação. Chegando em casa, ele tem uma piora expressiva (falso negativo). Sem dúvida, isso terá implicações bastante graves. Por fim, o time responsável pela implantação pode testar unitariamente as funcionalidades de um projeto, mas não a sua integração, justamente para evitar que vieses e conhecimento prévio dos caminhos empregados na construção do projeto afetem a qualidade desse teste;
– Implantação (Go-Live): momento em que a solução homologada pelas partes interessadas pelo projeto (stakeholders) é efetivamente ativada, disponibilizada ao mercado ou colocada em ambiente de Produção. A partir daí, inicia-se uma fase de monitoramento para verificação de eventuais erros ou problemas não captados nos ciclos de teste, além de ajustes de rota que somente serão possíveis quando o produto ou serviço estiver sendo utilizado em larga escala. Embora o projeto em si seja encerrado, processos de melhoria e aprimoramento contínuo assumem a direção e, eventualmente, trazem elementos que vão conduzir a um novo projeto.
Durante muito tempo, esta metodologia foi a mais utilizada para planejamento, execução e entrega de projetos nas mais distintas frentes: construção civil, projetos de defesa, desenvolvimento de software, engenharia de produtos, pesquisa de medicamentos, programas educacionais etc. É, de longe, a mais popular: são cerca de 700.000 membros do PMI em quase todos os países do mundo, embora desde o início dos anos 2000 tenha começado a perder espaço para os frameworks ágeis, especialmente no contexto tecnológico, com o despontar das empresas de tecnologia e startups, como veremos a seguir.
Isso tem a ver com a velocidade com que as mudanças têm ocorrido nos últimos anos e a flexibilidades que esse cenário requer: um projeto em cascata funciona sob a tríade custo, escopo e tempo – fatores que estão diretamente interligados. Qualquer alteração em um deles, portanto, implica em alteração nos demais. Essas alterações, por sua vez, precisam passar por um comitê de aprovação denominado Comitê de Gestão de Mudanças (Change Management Board), que poderá autorizar ou não sua inclusão no âmbito das atividades definidas no Plano de Projeto. Em caso positivo, elas, bem como todas as etapas subsequentes – incluindo as que estiverem em andamento – terão de ser replanejadas, a fim de atualizar esse Plano adequadamente.
No contexto da Indústria 4.0, caracterizado pela “disrupção” em inúmeras esferas, a gestão de projetos sob essa metodologia pode gerar entraves para o tempo de resposta oferecido a essas mudanças do mercado, tornando uma entrega de projeto obsoleta antes mesmo que ela esteja finalizada – e comitês de mudança podem não ser rápidos o suficiente para retomar o passo, tendo em vista todas as etapas (e assinaturas) necessárias para aprovação de mudanças.
Ainda assim, a metodologia de gestão de projetos em cascata é sem dúvida uma das mais robustas do mercado, contando com a experiência e a colaboração de milhares de profissionais que se dedicam ao seu aperfeiçoamento contínuo. Seja entusiasta dela ou não, em algum momento você certamente vai se deparar com os famosos diagramas de Gantt feitos no MS Project, caso isso ainda não tenha ocorrido.
[1] Atualmente estamos na 7ª edição, que possui cerca de 800 páginas e pode ser baixada (somente membros associados) a partir do site dos capítulos do PMI ou adquirida a partir de livrarias e e-commerce em geral.
Quer ver uma nova perspectiva sobre projetos? Acesse aqui a segunda parte deste artigo, no qual discutimos métodos ágeis.
Saiba mais em:
– Project Management Institute, Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK), 6ª edição, 2017.
