Uma nova ótica para Gerente de Projetos

O gerente de projetos deve ser cada vez mais um tipo de profissional que sabe gerir, mais individualmente do que em nível de categoria, as próprias relações dos projetos. Ele deve acima de tudo saber que: O que realmente faz funcionar uma empresa são as pessoas.

por Fabio Camara

Da experiência na consultoria de empresas, o que se revela a base de toda problemática é a carência de conhecimento sobre o que realmente está acontecendo na dinâmica do projeto. Não se conhece o que acontece, não se conhecem as realidades que estão agindo naquele momento a não ser pelos efeitos póstumos.

Não estamos falando de conhecimentos técnicos específicos, pois estes podem ser adquiridos facilmente. Estamos falando de liderança nos projetos, na organização. Porque para além de toda a tecnologia a primeira referência de qualquer atividade é o individuo. A diferença no sucesso de qualquer atividade não é mais devida apenas à técnica, mas ao indivíduo. Um dado incontestável é que o êxito de um projeto é sempre verificação histórica de um homem.

Um novo projeto de software, infelizmente, possui uma enorme chance de ter resultados decepcionantes. O problema nasce do fato que os projetos são iniciados sem levar em conta fatores humanos, ou melhor, criam-se expectativas sobre ferramentas, metodologias e processos esquecendo que o que realmente faz um projeto funcionar são os seus participantes.

Quando estudamos propostas diferentes para este quadro geral, observamos no manifesto ágil:

_ "Indivíduos e interações ao invés de processos e ferramentas".

Desta forma podemos definir que ser ágil é aplicar propostas diferentes para problemas antigos, sob uma nova ótica - a ótica humana. É simples, é apenas uma nova abordagem.

Por exemplo, muitas empresas nestes últimos anos montaram escritórios de projetos (também conhecidos como PMO - Project Management Office) com o objetivo de mudar alguma coisa no cenário dos resultados dos desenvolvimentos dos projetos. Aplicou-se um vasto conhecimento de processos e construíram uma infinidade de controles. Na minha visão, passaram horas a fio estudando algo que já é evidente, que todos têm certeza. "Os projetos estão com sérios problemas".

Este tipo de ação orienta ao determinismo psíquico. Desta forma, uma causa gera um efeito, este efeito gera outro efeito e depois outro efeito como um programa.

Meu objetivo neste artigo não é esgotar o assunto, sabendo-se que é vasto e polêmico. Ficarei imensamente feliz se eu conseguir sensibilizar meu leitor a curiosidade de conhecer propostas diferentes.

Projeto e programa

Antes de continuar o artigo, acredito que seja muito válido explicar, ou melhor, especificar o sentido da palavra "projeto". Na minha leitura, torna-se fácil quando diferenciamos do conceito de programa.

O programa é uma série pré-impostada de eventos fixos, os quais produzem um determinado efeito. Se o projeto tem sempre, como no caso do programa, o seu escopo específico, diferencia-se do primeiro pelo fato que no seu proceder é absolutamente variável.

Por exemplo: não é importante conhecer passagens intermediárias de quem tem a intenção de ir estudar na biblioteca; se o seu projeto é esse, pode usar qualquer meio, passar por qualquer lugar, desde que permaneça fiel ao efeito final: estudar na biblioteca.

No programa, ao contrário, tudo é sistematicamente calculado. Onde passar, como e quando são fundamentais.

A máquina funciona por programas, enquanto o homem é capaz também de projetar.

Se trouxermos isso para um projeto de desenvolvimento de software, poderíamos:

• Colher idéias sobre requisitos necessários ao nosso projeto;
• Validar estas idéias, reduzindo-as ou especificando-as (tornando-as claras). Coloque-as numa lista que poderíamos apelidar de "Product Backlog";
• Estimar e priorizar todos os itens da lista. Separe depois em conjuntos de funcionalidades que devem ser produzidas em determinado tempo. Vamos apelidar este conjunto que deve ser produzido em um tempo fixo de "sprint";
• Desenvolva;
• Revise seu desenvolvimento;
• Faça uma retrospectiva no final do conjunto de funcionalidades, colhendo fatos, avaliando o que foi bom e o que deve melhorar.

Parece simples. É simples. É a metodologia SCRUM. Nesta metodologia duas práticas são fundamentais ao gerente de projetos: Manter as coisas simples e livrar-se de todos os impedimentos. Minha contribuição da dúvida para meu leitor imaginário é: como pode alguém que está seguindo sistematicamente processos manter as coisas simples e livrar-se de todos os impedimentos?

O novo gerente de projetos

Hoje, quem trabalha com projetos, é sobretudo um knowledge worker, ou melhor, uma pessoa que trabalha por métodos e não por processos, sobre objetivos e não por horários.

Muitos processos tornam-se imediatamente obsoletos devido a novas características de negócios. A velocidade das mudanças impõe a exigência de uma atualização contínua das competências e das habilidades. Para ser gerente de projetos hoje não se pode permanecer esclerosado em papéis, funções e modalidades operacionais que necessariamente devem confrontar-se com cenários mutáveis.

Um tipo de resultado positivo em um projeto só é totalmente repetível se permanecerem as mesmas pessoas e se tratar dos mesmos problemas. Em outras palavras, é inútil seguir um "script" de como gerenciar um projeto de desenvolvimento de software.

Eu particularmente acredito que no futuro próximo, a diferença fundamental entre os gerentes de projetos não será a bagagem de conhecimentos e experiências que soube acumular, organizar e renovar, mas sobretudo o método com o qual saberá continuamente capitalizá-los em adaptação e evolução.

Se estudarmos MSF (Microsoft Solutions Framework), tanto MSF Essentials como MSF for Agile Software Development, encontraremos uma descrição e uma lista de responsabilidades que devem ser efetuadas pelo gerente do projeto. A especificação de responsabilidades claras para os papéis necessários de um projeto é um dos pontos fortes do MSF. Entretanto a informação sempre toma forma conforme os olhos de quem a vê. Mesmo que eu e o meu leitor estudemos juntos, seriamente, tudo que é ensinado no papel MSF Project Manager, agiremos de forma diferente dentro do projeto.

Em resumo, o sucesso como gerente de projetos não será pela quantidade de informação que se tem, e sim pelo modo útil de usar a informação em função do escopo do projeto.

É preciso compreender que o conhecimento diferencia-se em três:

1- Conhecimento explícito: é o conhecimento que pode ser catalogado. Facilmente encontra-se em livros e artigos;

2- Conhecimento incorporado: é o conhecimento que você reproduz, seja com ação, seja com direção, sem entender. É uma soma da informação com a intuição;

3- Conhecimento tácito: é um modo particular de entender que não é possível de ser explicado.

Todos nós temos estes três tipos de conhecimento. Por isso, somos únicos em determinada situação, somos parecidos em outra determinada situação. Agimos de acordo com nossos tipos de conhecimentos.

Como trabalhar por métodos

O cenário no qual o colaborador é fundamentalmente um executor, guiado por processos e regras muito claras e das quais raramente se desvia está se deslocando para um cenário no qual o colaborador tem cada vez mais responsabilidades, não trabalha mais com base em horas, mas com base no alcance de certos objetivos.

Executores com regras claras é um cenário apropriado para o nível puramente operacional. Quando tratamos dos cargos estratégicos e táticos, os livros sobre PMI, CMMI, RUP, TOC, MSF e SCRUM devem servir como um guia de técnicas e práticas que podem ser aplicados para determinada situação, desde que você compreenda e transcenda.

Compreender é alcançar com inteligência o que está sendo ensinado no livro. Transcender é passar além dos limites de forma superior ao que está sendo ensinado. Em outras palavras, construa em cima de ensinamentos que você compreendeu e terás resultados magníficos.

Não existe nenhum empresário que espere do gerente de projetos relatórios mostrando como estão os projetos em andamento. Relatórios, gráficos, controles, são todos menores comparados ao cliente satisfeito por um produto (que normalmente é o resultante de um projeto) sendo entregue.

Para trabalhar com base em métodos, verifica-se hoje que as propostas ágeis são as mais adequadas. Agilidade pode ser definida como "a habilidade tanto para criar quanto para responder às mudanças, de modo a lucrar em um ambiente turbulento de negócios." (Jim Highsmith, no livro "Agile Software Development Ecosystems").

Para identificar um gerente de projetos que trabalha por métodos, não utilize o critério de avaliar seus certificados técnicos, sua formação acadêmica ou as empresas no qual trabalhou. Observe seus resultados. Observe como ele lidera. Não é ser gerente de projetos do ponto de vista técnico, é ser gerente de projetos do ponto de vista realizador.

Considerações finais

A intensidade da mudança exigida das empresas para serem competitivas, remetem-nos a tornar indispensável a necessidade de formação contínua e inovadora. Esta formação deve buscar respostas eficazes que se ponham "a priori" e não "a posteriori" como é observado em praticamente todos os departamentos de informática. O resultado prático desta formação é preparar pessoas para saber dar, de tal modo, respostas eficazes aos problemas - que mudam momento a momento.

O gerente de projetos deve ser cada vez mais um tipo de profissional que sabe gerir, mais individualmente do que em nível de categoria, as próprias relações dos projetos. Ele deve acima de tudo saber que: O que realmente faz funcionar uma empresa são as pessoas.

Para Saber Mais

Treinamento de MSF + Agile Methods da F|Camara Formação e Consultoria (http://www.fcamara.com.br)

Referências

• Agile Software Development: The Cooperative Game by Alistair Cockburn;
• Visual Studio Team System Rocks by Fábio Câmara, Clementino Mendonça e outros;
• Software Engineering with Microsoft Visual Studio Team System by Sam Guckenheimer;
• Agile And Iterative Development - A Managers Guide by Craig Larman.