Este relatório explora a questão com base no tamanho da empresa e na maturidade e alcance do projeto e da função da gestão de programas (PPM).
Uma das perguntas mais comuns que recebemos tem a ver com a questão sobre a quem e onde os gerentes de projeto da empresa devem reportar. Deve ser ao escritório de gestão de projetos (PMO)? Ou eles devem se ater às aplicações ou à infraestrutura? Não há nenhuma resposta comum a todos.
Descobertas Chave
• Todos os gerentes de projeto devem ter pelo menos um relacionamento de reporte matrizado com o PMO para garantir que questões sobre status e desempenho possam ser abordadas.
• As empresas centradas em projetos tais como engenharia ou construção consideram a transferência para centros de competência no setor de TI uma extensão natural do modo como fazem negócios, e que podem fazer uma mudança nos níveis iniciais de maturidade. Outras empresas podem considerar de forma geral que a prática seja mais fácil de adotar nos níveis posteriores de maturidade.
• Deve haver somente uma fonte para as práticas recomendadas pela empresa. Muitas das questões relativas a quem e onde os gerentes de projeto devem reportar estão na verdade tentando solucionar um problema do tipo "cozinheiros demais na cozinha."
Recomendações
• Assegure-se de que todos os gerentes de projeto que trabalham em projetos da carteira do PMO procurem o PMO para obter diretrizes sobre o processo e as práticas da PPM. Este relacionamento não precisa ser ditatorial, mas deve servir pelo menos de orientação.
• Para pequenas empresas com apenas três ou quatro gerentes de projeto, considere fazer com reportem ao PMO, mas quando o número chegar a oito ou 10, considere agrupá-los com os analistas corporativos, e fazer com que reportem a um único gerente de recursos.
• Para empresas maiores com 15 ou mais gerentes de projeto, centralize o grupo em um centro de competências, com um gerente que seja também responsável por todo o treinamento, orientação e desenvolvimento dos gerentes de projeto.
ANÁLISE
A questão de como organizar a estrutura de reporte de um gerente de projeto é uma daquelas perguntas mais triviais, comuns (e persistentes) na maioria das empresas. Eles devem se ater às aplicações ou à infra-estrutura, ou eles devem recorrer ao PMO e se tornar gerentes de projeto "em tempo integral"? Como muitas outras perguntas, não há uma resposta comum a todos os casos — isso dependerá do tamanho da empresa e da maturidade e alcance da função da PPM.
Há alguns potenciais inconvenientes em se presumir automaticamente que a melhor resposta é fazer com que os gerentes de projeto reportem ao PMO. Por exemplo, embora os gerentes de projeto estejam sempre focados na entrega de projetos ou programas, esse não é necessariamente o foco primário do PMO. As funções mais comuns para o PMO incluem:
• Reporte de status para a administração sênior
• Gestão de carteiras
• Garantia de qualidade
• Desenvolvimento, implementação e manutenção de metodologias
• Treinamento
• Orientação
• Planejamento da capacidade dos recursos
• Contratação de recursos humanos para projetos
• Gestão de riscos
• Melhores práticas de comunicações
• Melhores práticas de gestão de mudanças
• Análise dos casos corporativos
• Facilitação
Essa lista de funções tende a variar (novamente, dependendo do tamanho e da maturidade do PMO), mas em todos os casos, o PMO deve estar fornecendo conhecimentos únicos para o desenvolvimento e uso dos recursos de gestão de projetos da empresa.
Abordando a questão do PMO como despesas gerais
O motivo mais comum para fazer com que os gerentes de projeto reportem ao PMO é fazer com que a percepção do PMO evolua de uma "divisão de despesas gerais/governança" para uma divisão em linha — em cujo ponto ele deixará de ser visto como algo que lida com despesas gerais. A lógica parece boa na superfície, mas há definitivamente um inconveniente. Nesse cenário, o PMO se torna mais frequentemente a via da escalada para questões diárias sobre a gestão de projetos. Infelizmente, aquelas uma ou duas pessoas que podem na verdade ser consideradas como staff do PMO (o diretor e o ocasional assistente administrativo) não têm absolutamente nenhum tempo para oferecer nenhum dos serviços listados acima. Isso pode tornar o PMO sujeito a críticas de que não esteja realmente fornecendo nenhum valor adicional e que poderia ou deveria ser eliminado. O PMO também tende a ser encaixado em um nível muito inferior da empresa se é visto apenas como uma divisão de gestão de recursos, o que torna ainda mais difícil que forneça com êxito os serviços citados acima.
Por outro lado, especialmente em empresas nos estágios iniciais de maturidade, se um PMO estiver centrado essencialmente na observância, controle e metodologia e não efetivamente ajudar a melhorar o desempenho de projetos, ele frequentemente passa a liderar a lista de divisões com maior probabilidade de serem eliminadas.
Então, onde está o meio termo?
Até mais ou menos o Nível 3, um PMO que esteja focado na melhoria da produtividade dos projetos costuma ser o mais bem sucedido. Felizmente, a produtividade costuma ser a medida mais fácil de ser mensurada. Para garantir que as mensurações sejam significativas, os seguintes pontos de dados precisam ser estabelecidos:
• O número de projetos finalizados no ano anterior
• O número de projetos iniciados no ano anterior
• A duração média do projeto (incluindo pedidos de mudanças)
• A duração originalmente planejada dos mesmos projetos
• O aumento na duração devido a eventos de risco que tenham ocorrido no ano anterior
• O aumento na duração devido a mudanças de escopo no ano anterior
• A satisfação dos usuários com o produto resultante dos projetos no ano anterior
Esses sete fatores, quando devidamente combinados, podem ajudar a demonstrar como o PMO poderá acrescentar valor e mostram que, sem um PMO, os projetos simplesmente exigem mais tempo e custam mais.
O Valor do Reporte Matrizado e da Comunidade de gerentes de projeto
Se a situação padrão não envolver fazer com que os gerentes de projeto reportem ao PMO, a quem e onde devem reportar? Mais uma vez, isso depende do tamanho e da maturidade.
As empresas com apenas três ou quatro gerentes de projeto identificados podem geralmente fazer com que reportem ao PMO. Quando esse número chega à casa dos oito a 10 gerentes, faz mais sentido agrupar os gerentes de projeto com os analistas corporativos e fazer com que reportem a um gerente de recursos que possa administrar múltiplos grupos de recursos humanos. A coisa mais importante a compreender sobre os gerentes de recursos é que são responsáveis por gerir e contratar o pessoal dos seus grupos. Eles não são responsáveis pela direção, desenvolvimento de práticas, adoção de melhores práticas ou qualquer coisa mais que possa interferir no alcance e na missão do PMO. Para empresas que possuam softwares de gestão de recursos já implantados, o gerente de recursos também se tornará responsável por manter atualizadas as informações da ferramenta e por garantir que todos saibam onde supostamente devem estar e quando devem supostamente estar lá.
Fazer com que os gerentes de projeto reportem a um gerente de recursos ajuda a evitar o problema de enviar insumos concorrentes para o gerente de projeto O maior problema individual que os clientes enfrentam é este: Quando os gerentes de projeto possuem gerentes de RH com outras linhas de responsabilidades, eles (os gerentes de RH) frequentemente tentam influenciar as atividades de um projeto, e em alguns casos tentam simplesmente ditar se algo deve ou não ser feito. Embora isso seja um clássico paradigma de reporte para empresas no Nível de maturidade 0 da PPM (geralmente devido ao tamanho), ele se torna ineficaz na medida em que a empresa amadureça — e em algum ponto poderá se tornar uma causa raiz do por que o desempenho do projeto não está melhorando.
Se houver mais gerentes de projeto (digamos, de 12 a 20), então um centro de competências autônomo poderá ser criado, que reporte a um gerente que então será responsável não somente pela gestão de recursos mas — muito mais importante — pelo treinamento e desenvolvimento de carreiras. Essas funções poderão então der transferidas ao PMO e ao centro de competências. As empresas centradas em projetos tais como engenharia ou construção consideram a transferência para os centros de competência no setor de TI como uma extensão natural do modo como fazem negócios. Outras empresas geralmente consideram que isso seja um conceito organizacional apropriado nos níveis posteriores de maturidade.
Uma outra vantagem significativa desse relacionamento de reporte é a capacidade de prover atenção e recursos para os "gerentes de projeto acidentais" — isto é, aqueles contratadores de pessoal sob pressão para atuarem como gerente de projeto em um pequeno projeto e que talvez nunca administrem novamente um outro projeto. Nesse caso, o centro de competência será responsável por fornecer suporte a esses "gerentes de projeto acidentais" através de mecanismos tais como uma comunidade de práticas (veja "Kit de Ferramentas: Estabelecendo uma Comunidade de Práticas de Gestão de Projetos").
Em todo caso, cada gerente de projeto que atue na empresa — seja "acidental" ou em tempo integral — deve possuir um relacionamento de reporte matrizado com o PMO. O relacionamento matrizado tem a intenção de garantir que cada gerente de projeto compreenda que o PMO tem a autoridade e a responsabilidade fazer as perguntas mais chatas e difíceis e que realmente requerem respostas.
Um pensamento final: O PMO trabalhará melhor se estiver lá para garantir que os projetos sejam executados de forma eficaz. Isso se obtém mais facilmente se todas as pessoas da empresa virem o PMO como envolvido na obtenção de bons resultados nos projetos e não como sendo o único responsável por tal êxito. Ao adaptar os arranjos de reporte dos gerentes de projeto às necessidades e à maturidade da empresa, o objetivo que acabamos de discutir será mais facilmente alcançado.
Donna Fitzgerald, do Gartner
6 de julho de 2009
10 habilidades em Gerenciamento de Projetos que podem ajudar sua carreira.
10 habilidades em Gerenciamento de Projetos que podem ajudar sua carreira
Autor: Michelle LaBrosse, PMP
Estas dicas importantíssimas foram publicadas na newsletter de Agosto do PMI Sâo Paulo. Sugiro uma leitura minuciosa e colocar em prática para o desenvolvimento do soft skill dos gerentes de projetos.
1. Mostrar resultados. Gerenciamento de Projeto é a arte e a ciência de se fazer as coisas acontecerem. Quando você melhorar suas habilidades em Gerenciamento de Projetos, você saberá como fazer acontecer mais rapidamente e eficientemente, e ainda mais importante, você aprende como documentar os resultados. Em nossa carreira, comumente só somos bons pelas nossas últimas decisões. Você não pode ser um profissional de acertos únicos. Em vez disso, poderá, como um gráfico, ano após ano, mostrando sucesso após o sucesso.
2. Ser eficiente. Quando você aplica os princípios de Gerenciamento de Projetos no seu trabalho, na sua casa ou vida, você parar de reinventar a roda. O Gerenciamento de Projetos ensina você como tornar mais eficiente o uso dos recursos para gerar o melhor resultado no menor período de tempo. Ao final de cada projeto, você captura as melhores práticas e lições aprendidas, criando uma documentação de valor incalculável com erros e acertos. Soa muito bom para ser verdade? Bons Gerentes de Projetos o fazem em todos os projetos, e você pode também.
3. Criar um diálogo permanente. Um erro comum em Gerenciamento de Projetos e no time de projetos é o pressuposto que uma reunião basta para que todos possam seguir o trabalho do projeto e, em seguida, termina a comunicação, e de algum modo tudo magicamente será terminado. Suas competências de comunicação não são sobre o seu vocabulário. Elas são sobre a forma como você gerencia sua comunicação. Você está comunicando com freqüência suficiente e com clareza? Está comunicando o que é relevante? Você está comunicando o seu sucesso?
4. Jogar bem com os outros. As pessoas ouvem a palavra trabalho em equipe, e eles resmungam ou eles dizem que eles são, obviamente, um jogador da equipe. É por isso que eu queria trazê-lo de volta para o lugar em nossa mente, no jardim da infância, chamada: Caixa de Areia. Você brinca bem com os outros? Será que as outras pessoas querem estar na sua equipe? São respeitados por você? Você ouve ativamente o que os outros têm a dizer? Bons Gerentes de Projetos sabem quando devem conduzir e quando sair do caminho. Quando alguém é entrevistado, você sabe o que essa pessoa está pensando: Posso trabalhar com ele? Será que o meu trabalho será bom com ela?
5. Deixar sua confiança brilhar. Quando alguém mostra confiança, todos na sala sentem também.
6. Manter seus Compromissos. Errar nos prazos e projetos que escorregam em rachaduras são erros assassinos na carreira. As habilidades de Gerenciamento de Projeto têm como foco o cumprimento de marcos e resultados que constroem sua reputação e dá aos membros do projeto uma razão para confiarem em você. “Sei que posso sempre contar com ela para fazer o trabalho.” Esta citação pode, e deve, ser sobre você.
7. Manter a calma. Bons Gerentes de Projetos não se desesperam. Eles podem permanecer calmos e no controle, porque eles têm documentações que contém todas as Informações críticas do projeto.
8. Adaptação a mudanças. Não ignore a mudança. Empresas mudam. Prazos se alteram. As pessoas vêm e vão. Bons Gerentes de Projetos sabem que muitas vezes tem que adaptar os planos e documentar o que mudou e quais serão os impactos das mudanças no projeto inteiro.
9. Saiba o que você não conhece. Quais são seus pontos fortes e fracos? Quais as competências que você precisa para se deslocar a partir do “status quo” para o próximo nível? Uma vez que você tenha uma base sólida de Gestão de Projetos, continue crescendo nestas habilidades. Não estagnar, aprendizagem contínua e uma sede de conhecimento são sempre atraentes para os empregadores e membros da equipe.
10. Liderança com propósito e paixão. As pessoas vão acompanhar aqueles que sabem o que que estão fazendo e que pode gerar resultados. Gerenciamento de Projeto é uma poderosa ferramenta de liderança, pois não só nos mostra como manter o nosso olhar sobre o prêmio e da finalidade, mas é também sobre a paixão de conquistar o sucesso. Nada melhor do que o sentimento de realização.
Fonte: Published in PM World Today – September 2007 (Vol. IX, Issue IX)
http://www.pmworldtoday.net/tips/2007/sep.htm#4
ou Versão PDF
http://www.pmforum.org/library/tips/2007/PDFs/LaBrosse-9-07.pdf
Autor: Michelle LaBrosse, PMP
Estas dicas importantíssimas foram publicadas na newsletter de Agosto do PMI Sâo Paulo. Sugiro uma leitura minuciosa e colocar em prática para o desenvolvimento do soft skill dos gerentes de projetos.
1. Mostrar resultados. Gerenciamento de Projeto é a arte e a ciência de se fazer as coisas acontecerem. Quando você melhorar suas habilidades em Gerenciamento de Projetos, você saberá como fazer acontecer mais rapidamente e eficientemente, e ainda mais importante, você aprende como documentar os resultados. Em nossa carreira, comumente só somos bons pelas nossas últimas decisões. Você não pode ser um profissional de acertos únicos. Em vez disso, poderá, como um gráfico, ano após ano, mostrando sucesso após o sucesso.
2. Ser eficiente. Quando você aplica os princípios de Gerenciamento de Projetos no seu trabalho, na sua casa ou vida, você parar de reinventar a roda. O Gerenciamento de Projetos ensina você como tornar mais eficiente o uso dos recursos para gerar o melhor resultado no menor período de tempo. Ao final de cada projeto, você captura as melhores práticas e lições aprendidas, criando uma documentação de valor incalculável com erros e acertos. Soa muito bom para ser verdade? Bons Gerentes de Projetos o fazem em todos os projetos, e você pode também.
3. Criar um diálogo permanente. Um erro comum em Gerenciamento de Projetos e no time de projetos é o pressuposto que uma reunião basta para que todos possam seguir o trabalho do projeto e, em seguida, termina a comunicação, e de algum modo tudo magicamente será terminado. Suas competências de comunicação não são sobre o seu vocabulário. Elas são sobre a forma como você gerencia sua comunicação. Você está comunicando com freqüência suficiente e com clareza? Está comunicando o que é relevante? Você está comunicando o seu sucesso?
4. Jogar bem com os outros. As pessoas ouvem a palavra trabalho em equipe, e eles resmungam ou eles dizem que eles são, obviamente, um jogador da equipe. É por isso que eu queria trazê-lo de volta para o lugar em nossa mente, no jardim da infância, chamada: Caixa de Areia. Você brinca bem com os outros? Será que as outras pessoas querem estar na sua equipe? São respeitados por você? Você ouve ativamente o que os outros têm a dizer? Bons Gerentes de Projetos sabem quando devem conduzir e quando sair do caminho. Quando alguém é entrevistado, você sabe o que essa pessoa está pensando: Posso trabalhar com ele? Será que o meu trabalho será bom com ela?
5. Deixar sua confiança brilhar. Quando alguém mostra confiança, todos na sala sentem também.
6. Manter seus Compromissos. Errar nos prazos e projetos que escorregam em rachaduras são erros assassinos na carreira. As habilidades de Gerenciamento de Projeto têm como foco o cumprimento de marcos e resultados que constroem sua reputação e dá aos membros do projeto uma razão para confiarem em você. “Sei que posso sempre contar com ela para fazer o trabalho.” Esta citação pode, e deve, ser sobre você.
7. Manter a calma. Bons Gerentes de Projetos não se desesperam. Eles podem permanecer calmos e no controle, porque eles têm documentações que contém todas as Informações críticas do projeto.
8. Adaptação a mudanças. Não ignore a mudança. Empresas mudam. Prazos se alteram. As pessoas vêm e vão. Bons Gerentes de Projetos sabem que muitas vezes tem que adaptar os planos e documentar o que mudou e quais serão os impactos das mudanças no projeto inteiro.
9. Saiba o que você não conhece. Quais são seus pontos fortes e fracos? Quais as competências que você precisa para se deslocar a partir do “status quo” para o próximo nível? Uma vez que você tenha uma base sólida de Gestão de Projetos, continue crescendo nestas habilidades. Não estagnar, aprendizagem contínua e uma sede de conhecimento são sempre atraentes para os empregadores e membros da equipe.
10. Liderança com propósito e paixão. As pessoas vão acompanhar aqueles que sabem o que que estão fazendo e que pode gerar resultados. Gerenciamento de Projeto é uma poderosa ferramenta de liderança, pois não só nos mostra como manter o nosso olhar sobre o prêmio e da finalidade, mas é também sobre a paixão de conquistar o sucesso. Nada melhor do que o sentimento de realização.
Fonte: Published in PM World Today – September 2007 (Vol. IX, Issue IX)
http://www.pmworldtoday.net/tips/2007/sep.htm#4
ou Versão PDF
http://www.pmforum.org/library/tips/2007/PDFs/LaBrosse-9-07.pdf
100 Regras para Gerentes de Projeto da NASA
As 100 regras foram divididas por assunto:
O Gerente de Projetos; Trabalho Inicial; Comunicações; Pessoal; Revisões e Relatórios; Contratados e Contratações; Engenheiros e Cientistas; Equipamentos; Computadores e Software; Alta Administração, Program Offices e Outros; Planejamento do Programa, Orçamento e Estimativas; Cliente; As Instruções de Gerenciamento da NASA; Tomando Decisões; Ética Profissional e Integridade; Gerenciamento de Projetos e Trabalho de Equipe; Tratando e Evitando Fracassos
O Gerente de Projetos
Regra 1: Um gerente de projetos deve visitar ao menos uma vez toda pessoa que está produzindo alguma coisa para o seu projeto; deve conhecer todos os gerentes no seu projeto (tanto do governo como do contratado), e conhecer os membros do time de integração. As pessoas gostam de saber que o gerente de projetos está interessado no seu trabalho e a melhor demonstração desse interesse é visitá-los e ver em primeira mão o que estão fazendo.
Regra 2: Um gerente de projetos precisa saber o que motiva os contratados do projeto (i.e., seu sistema de premiação, seu sistema fiscal, suas políticas e a cultura da sua companhia).
Regra 3: Os princípios de administração continuam os mesmos. Acontece apenas que as ferramentas mudaram. Você ainda encontra as pessoas certas para fazer o trabalho e sai do caminho para que elas possam realizá-lo.
Regra 4: Seja com quem for que você fizer um acordo, seja justo. O Espaço não é um grande parque de diversões. Você pode ser surpreendido com a freqüência com que você tem de trabalhar com as mesmas pessoas. Melhor que elas o respeitem do que carreguem ressentimentos.
Regra 5: Pessoas cruéis, desprezíveis, ou muito antipáticas, cavalheiros e damas podem ser gerentes de projeto. “Almas desgarradas”, procrastinadores e indecisos não podem.
Regra 6: Um gerente de projetos confortável é alguém esperando pela sua próxima missão ou alguém à beira do fracasso. Segurança não é normal em gerenciamento de projetos.
Regra 7: Um problema que os novos gerentes descobrem é que todos querem resolver seus problemas. Velhos gerentes ouviram da alta administração – “resolva seus próprios malditos problemas, é para fazer isso que nós te contratamos”.
Regra 8: Fazer rápido não toma o lugar de pensar consigo mesmo. É preciso ter tempo para “cheirar as rosas”. Para o seu trabalho, você precisa ter tempo para entender as conseqüências das suas ações.
Regra 9: O chefe pode não saber como fazer o trabalho, mas ele deve saber o que quer. Se ele não sabe, deve descobrir o que espera e quer. Um líder cego tende a andar em círculos.
Regra 10: Nem todos os gerentes bem-sucedidos são competentes e nem todos os gerentes mal-sucedidos são incompetentes. A sorte ainda representa uma parte do sucesso ou do fracasso, mas favorece o gerente competente que trabalha duro.
Regra 11: Nunca tente responder à altura alguma desconsideração de alguém no projeto. Isso não é um bom costume e o coloca no mesmo nível da outra pessoa. Além disso, provavelmente termina por prejudicar a execução do projeto.
Regra 12: Não se torne demasiadamente arrogante a ponto de não poder mudar sua posição, especialmente se o seu pessoal lhe disser que você está errado. Cultive uma atitude no projeto onde o seu pessoal saiba que pode lhe falar sobre decisões erradas.
Regra 13: Um gerente que é seu próprio Engenheiro de Sistemas ou Gerente Financeiro é alguém que provavelmente tentará realizar uma cirurgia aberta de coração em si mesmo.
Regra 14: A maioria dos gerentes obtém sucesso na força e capacidade da sua equipe.
Trabalho Inicial
Regra 15: As sementes dos problemas são jogadas cedo. O planejamento inicial é a parte mais vital de um projeto. A revisão da maioria dos projetos mal-sucedidos ou problemas de projeto, indicam que os desastres foram desde o início bem planejados para acontecer.
Comunicações
Regra 16: Esforços cooperativos exigem boa comunicação e sistemas de aviso/prevenção antecipados. Um gerente de projetos deve tentar manter seus colaboradores cientes do que está acontecendo e deve ser aquele que lhes fala em primeiro lugar de qualquer rumor ou mudança real de planos. Os colaboradores devem ser consultados antes que as coisas sejam colocadas na forma final, mesmo se eles têm apenas uma pequena parcela da ação. Um gerente de projetos que limita a visão dos seus colaboradores será tratado de forma distante e será considerado uma pessoa sem integridade.
Regra 17: Conversar não é barato; mas a melhor maneira de entender um problema técnico ou pessoal é conversar com as pessoas certas. Falta de conversação num nível adequado é mortal.
Regra 18: A maioria dos encontros internacionais são realizados em inglês. Esta é uma língua estrangeira para a maioria dos participantes como Americanos, Alemães, Italianos, etc. É importante ter discussões adequadas de forma que não haja má interpretação do que é dito.
Regra 19: Você não pode ser ignorante na linguagem da área que gerencia ou daquelas áreas com que interage. Educação é uma necessidade para o gerente moderno. Existem cursos simples para aprender computês, comuniquês e todo o resto dos modernos “êses” do mundo. Você não pode gerenciar se você não entender o que está sendo dito ou escrito.
Pessoal
Regra 20: Você não pode prestar atenção em tudo. O que você pode fazer é observar as pessoas. Elas têm de saber que você não vai aceitar um trabalho pobre.
Regra 21: Nós desenvolvemos um grupo de pessoas cujo interesse particular é mais importante que o trabalho; ou ao menos assim parece para gerentes mais velhos. Parece aos antigos gerentes que aqueles mais novos são mais interessados na forma que no conteúdo. A questão é: os velhos gerentes estão certos ou estão apenas velhos? Considere ambos os pontos-de-vista.
Regra 22: Um bom técnico, inspetor de qualidade e um chefe flexível são mais importantes na obtenção de um bom produto do que todos os papéis e revisões.
Regra 23: A origem da maioria dos problemas são as pessoas; mas diabos se elas vão admitir. Conheça as pessoas trabalhando no seu projeto para saber quais são os seus reais pontos fracos.
Regra 24: É preciso prestar muita atenção aos workaholics – se eles estiverem indo na direção errada, podem fazer um grande estrago num curto período. É possível sobrecarregá-los e vencer pelo cansaço, mas é difícil determinar se a carga é muito grande, já que grande parte dela é autogerada. É importante garantir que tais pessoas tenham tempo livre suficiente e que a carga de trabalho não exceda 25% a 50% do normal.
Regra 25: Sempre tente negociar seu apoio interno até o mais baixo nível. O que você quer é o apoio da pessoa fazendo o trabalho, e quanto mais você conseguir se aproximar dela nas negociações, melhor.
Regra 26: Se você tem alguém que não olha, pergunta e analisa; peça que o transfiram.
Regra 27: Tempo particular é muito importante. Você precisa ser cuidadoso, como gerente, para que perceba o valor do tempo das outras pessoas (i.e., o trabalho que você distribui e as reuniões devem ser necessárias). Você precisa, onde for possível, isolar a sua equipe daquele trabalho desnecessário (i.e., alguns pedidos devem ser ignorados ou uma resposta negativa enviada ao demandante).
Regra 28: As pessoas que apenas monitoram o trabalho e não ajudam a realizá-lo nunca parecem saber exatamente o que está acontecendo (estar envolvido é a chave para a excelência).
Regra 29: Não existe maior motivação do que dar a uma pessoa competente sua peça no quebra-cabeça para controlar; mas um tapinha nas costas ou uma recompensa sempre ajudam.
Regra 30: São principalmente os incompetentes que não gostam de exibir o seu trabalho.
Regra 31: Existem raras ocasiões em que uma pessoa – e só ela – pode fazer o trabalho. Estes especialistas estão em áreas técnicas que são mais artísticas e de habilidade do que o normal. Trate muito bem estas pessoas, mas consiga o seu trabalho pronto assim que for possível. Conseguir o trabalho realizado por uma outra pessoa leva duas ou três vezes mais; e o produto normalmente é abaixo da média.
Regra 32: As pessoas têm razões para fazer as coisas do jeito que fazem. A maioria quer fazer um bom trabalho e, se não fazem, o problema é que provavelmente não sabem como ou exatamente o que é esperado.
Regra 33: Se você tem um problema que para ser resolvido exige mais pessoas, você deve se parecer, ao colocar mais gente, como um cozinheiro que pôs pouco sal na comida.
Revisões e Relatórios
Regra 34: A NASA definiu um conjunto de revisores e um conjunto de revisões. Uma vez que esteja firmemente estabelecido, o sistema vai voar sozinho, assim use-o ao máximo. Tente encontrar uma forma das revisões serem úteis para você.
Regra 35: O número de revisões está aumentando, mas a transferência de conhecimento continua a mesma; então, todos os seus gráficos e apresentações devem ser construídos com isso em mente. Isto significa que você deve ser capaz de construir um conjunto de slides que apenas precisassem ser reorganizados de uma apresentação para outra.
Regra 36: Não esconda nada dos revisores. A reputação deles e a sua está na mira. Mostre todas as verrugas e espinhas. Não ofereça desculpas – apenas declare os fatos.
Regra 37: Revisões externas são marcadas na pior hora possível. Então, mantenha um conjunto de informações técnicas e do negócio atualizadas, de forma que você possa responder rapidamente. Não ter informações atualizadas deve ser motivo de demissão.
Regra 38: Nunca diminua sua equipe em público (i.e., em reuniões públicas, não reverta decisões de trabalhos que você lhes deu para fazer). Mesmo que você ordene uma mudança, nunca tire da sua equipe a responsabilidade por implementá-la.
Regra 39: Revisões são para o revisado e não para o revisor. A revisão é inútil se o revisado dela não aprender nada.
Regra 40: Uma reunião de trabalho tem cerca de seis participantes. Reuniões maiores do que isso são para transferência de informações (a ciência da administração tem mostrado que num grupo maior que doze, alguns estão perdendo seu tempo).
Regra 41: A quantidade de revisões e relatórios é proporcional ao entendimento do administrador (i.e., quanto menos a administração conhece ou entende sobre as atividades, mais ela requer revisões e relatórios). É necessário neste tipo de ambiente garantir que os dados sejam apresentados de forma que uma pessoa mediana, pouco familiarizada com as atividades, possa entendê-los. Manter os dados simples e claros nunca insulta a inteligência de ninguém.
Regra 42: Gerentes que se baseiam apenas na papelada para fazer seus relatórios de atividades são fracassos declarados.
Regra 43: A documentação não substitui o conhecimento. Existe uma grande diferença em como se supõe que as coisas devam ser, o que se acredita que aconteceu, e a realidade. Documentos são normalmente uma visão estática no tempo que fica rapidamente ultrapassada.
Regra 44: Só porque você entrega relatórios mensais, não pense que você pode sintetizar alguma coisa num relatório anual. Se a administração entendesse os mensais, não precisaria de um anual.
Regra 45: Abreviaturas e siglas estão se tornando um sofrimento. Cada projeto agora tem alguns milhares. Isso faz a alta administração ter de saber centenas. Use-as de forma econômica em apresentações, a não ser que seu objetivo seja confundir.
Regra 46: Lembre-se, geralmente é mais fácil fazer a papelada ridícula do trabalho do que questionar a sua necessidade. Lute apenas se for um assunto global, que vai economizar muito trabalho futuro.
Contratados e Contratações
Regra 47: Um gerente de projetos não é o monitor do trabalho de um contratado, mas deve ser o orientador. Em situações de premiação por resultados, o pessoal do governo deve fazer todos os esforços possíveis para garantir que o contratado obtenha um escore alto (i.e., esteja no cronograma e produza um bom trabalho). Contratados não falham, a NASA sim e é por isso que devemos ser proativos no apoio. Também é por isso que uma baixa avaliação prejudica ao gerente de projetos por parte do governo tanto quanto ao gerente do contratado, uma vez que significa que ele não está conseguindo ter o trabalho realizado.
Regra 48: Premiação por resultados é uma boa ferramenta que coloca disciplina tanto no contratado como no governo. O escore concedido representa o status do projeto assim como a habilidade gerencial das duas partes. O Sistema de Medição de Gerenciamento de Projetos (Project Management Measurement System – PMS) deve ser usado para verificar os escores. Baixas avaliações persistentes requerem intervenção da alta administração para determinar a razão. Bons escores contínuos (que sejam consistentes com o PMS) refletem um projeto bem conduzido, mas se estes escores não são consistentes com o PMS, a alta administração deve tomar atitudes para descobrir o porquê.
Regra 49: O moral do pessoal contratado é importante para um gerente do governo. Assim como você não quer comprar um carro construído por funcionários insatisfeitos, você não quer comprar equipamento de vôo desenvolvido por pessoas desmotivadas. Você deve tomar uma atitude ativa em motivar todas as pessoas no projeto.
Regra 50: Ser amigável com um contratado é admirável – ser um amigo dum contratado é perigoso para sua objetividade.
Regra 51: Lembre-se, seu fornecedor de pessoal tem uma tendência a ter uma interface um-para-um com a sua equipe. Cada membro da sua equipe custa a você ao menos uma pessoa no contrato por ano.
Regra 52: Fornecedores tendem a avaliar a capacidade dos funcionários da equipe do governo e recrutar sua parte do projeto de acordo com isso. Se pensarem que os seus funcionários são ferro-velho, eles vão colocar no seu projeto suas pessoas menos capacitadas.
Regra 53: Contratados respondem bem ao cliente que presta atenção no que eles estão fazendo, mas não muito bem ao cliente que fica dando palpites na sua atividade. A regra básica é que o cliente sempre tem razão, mas o custo vai crescer se um cliente sempre quiser as coisas feitas da sua maneira ao invés daquela planejada pelo contratado. A regra é: nunca mude os planos do contratado a não ser que eles estejam errados ou muito caros (i.e., a velha máxima de que o ótimo é inimigo do bom).
Regra 54: Existe apenas uma solução para um gerente de projetos fraco na indústria – livre-se dele rápido. O principal trabalho de um gerente de projetos na indústria é manter o cliente feliz. Garanta que aquele que estiver trabalhando com você saiba que não é a bajulação, mas obedecer o cronograma, manter-se nos custos previstos e entregar um bom produto que faz você feliz.
Engenheiros e Cientistas
Regra 55: Engenharia excessiva é comum. Engenheiros gostam de quebra-cabeças e labirintos. Tente fazê-los manter seus projetos simples.
Regra 56: O primeiro sinal de problema vem da curva de cronograma ou de custo. Engenheiros são os últimos a saber que estão com problemas. Engenheiros nascem otimistas.
Regra 57: O projeto tem muitos recursos internos. Há provavelmente cinco ou dez engenheiros de sistemas levando em conta todos os contratados e desenvolvedores de instrumentos. Este é um poderoso recurso que pode ser usado para atacar problemas.
Regra 58: Muitos gerentes, só porque têm os cientistas sob contrato no seu projeto, esquecem que os cientistas são seus clientes e muitas vezes têm acesso mais fácil à alta administração do que eles próprios.
Regra 59: A maioria dos cientistas são racionais, a menos que você ponha em perigo a chance deles realizarem seus experimentos. Eles vão trabalhar com você se acreditarem que você está lhes dizendo a verdade. Isto inclui reduzir-lhes os próprios planos.
Equipamentos
Regra 60: Na indústria espacial, não existem coisas como equipamentos previamente pilotados. As pessoas que constroem a próxima unidade provavelmente nunca viram a unidade anterior. Existem provavelmente pequenas mudanças (talvez até mudanças importantes), o ambiente operacional provavelmente mudou; as pessoas que checam a unidade na maioria dos casos não a entendem, e nem aos equipamentos de testes.
Regra 61: A maioria dos equipamentos funciona conforme construído, não como o projetista planejou. Isto acontece devido ao layout do projeto, falha de entendimento por parte do projetista ou falha no entendimento das especificações do componente.
Computadores e Software
Regra 62: Não usar técnicas modernas, como sistemas computacionais, é um grande erro, mas esquecer que o computador simula o pensamento é um erro ainda maior.
Regra 63: O software já tem hoje todos os parâmetros do hardware (i.e., mudanças de requisito, alta porcentagem do custo da missão espacial, necessidade de controle de qualidade, necessidade de procedimentos de validação, etc.). E tem a característica adicional de ser quase impossível determinar que não possua defeito. Faça funcionar o básico do sistema e só então acrescente os sinos e apitos. Nunca jogue fora uma versão que funciona, mesmo se tiver toda a confiança de que a versão mais nova está OK. É necessário ter planos de contingência para software.
Regra 64: O conhecimento é normalmente revisado através de simulações ou testes, mas modelos computacionais têm erros ocultos, dos quais o menor deles não é ter dados de entrada pobres.
Regra 65: Nos tempos antigos, os engenheiros tinham a experiência prática, técnicos sabiam como a eletrônica funcionava e o que se esperava que fizesse, e técnicos de layout também tinham conhecimento – mas hoje só o computador sabe com certeza e ele ainda não está falando.
Alta Administração, Program Offices e Outros
Regra 66: Não assuma que você sabe o porquê da alta administração ter feito alguma coisa. Se você sente que deve saber, pergunte. Você receberá algumas respostas incríveis que vão surpreendê-lo.
Regra 67: Conheça seus superiores – alguns gostam de uma boa piada, outros só gostam de uma piada se eles a contarem.
Regra 68: Lembre-se, o chefe tem o direito de tomar decisões. Mesmo se você pensar que ele está errado, diga-lhe o que você pensa, mas se ele ainda quiser feito do seu jeito, faça do jeito dele e esforce-se ao máximo para que o resultado seja bem-sucedido.
Regra 69: Nunca peça a seu superior para tomar uma decisão que você pode tomar. Assuma que você tem a autoridade para tomar decisões a não ser que saiba que há um documento que estabeleça inequivocamente que você não pode.
Regra 70: Você e o Gerente do Programa devem trabalhar como um time. O Gerente do Programa é o seu advogado no Quartel-General da NASA e deve estar próximo dos tomadores de decisão e deve auxiliar seus esforços de estar próximo também.
Regra 71: Saiba quem são os tomadores de decisão do programa. Pode ser alguém de fora que tenha o ouvido do Congresso ou o Administrador, ou o Administrador Associado, ou um dos cientistas – alguém na cadeia de comando – seja que for. Tente estabelecer uma linha de comunicação com eles, seja numa base formal ou informal.
Planejamento do Programa, Orçamento e Estimativas
Regra 72: Hoje em dia precisamos expandir o estado da arte, ficar dentro do orçamento, aceitar riscos, não errar e ser pontuais. Estranhamente, tudo isso anda bem desde que as regras básicas como o perfil dos recursos e o planejamento sejam definidos com antecedência e mantidos.
Regra 73: As maiorias dos projetos antigos extrapolavam o previsto por causa de estimativas ruins e não por causa de erros. Aumentar as estimativas não vai baixar os custos da NASA, mas vai melhorar a sua reputação. Na realidade, existe uma alta probabilidade de que ter melhores estimativas vai aumentar os custos e garantir um maior lucro para a indústria, a não ser que os honorários diminuam para refletir um menor risco por parte dela. Uma melhor reputação é necessária no ambiente atual.
Regra 74: Todos os problemas são solucionáveis num tempo, assim tenha certeza de ter suficiente contingência no cronograma – se você não tiver, o próximo gerente de projetos que ocupará o seu lugar, terá.
Regra 75: A velha NASA expandiu os limites da tecnologia e ciência; desta forma, ela não se importava com requisitos incompletos ou excessivos. A nova NASA deve trabalhar como se todos os projetos fossem de preço fechado (“fixed price”). Assim, requisitos incompletos se tornaram um pecado mortal.
Regra 76: Conheça os recursos da sua área e, se possível, de outras áreas. Outras áreas, se têm os recursos, geralmente ficam felizes em ajudar. É sempre surpreendente quanta coisa boa se pode conseguir apenas pedindo.
Regra 77: Além da informação orçamentária antes da submissão pelo Presidente ao Congresso, provavelmente não há informações secretas num projeto – então não trate coisa alguma como segredo. Todos produzem melhor se puderem ver o quadro todo, assim não esconda nada de ninguém.
Regra 78: Os programas da NASA competem por recursos de orçamento – eles não competem uns com os outros (i.e., você nunca ataca outro programa ou trabalho da NASA com a idéia de que possa receber seus recursos). Venda o que você tiver pelo seu próprio mérito.
Regra 79: O “ano que vem” é sempre o ano com recursos e prazos adequados. O “ano que vem” chega no 50º ano da sua carreira.
O Cliente
Regra 80: Lembre-se quem é o cliente e quais são os seus objetivos (i.e., confira com ele
quando você for mudar alguma coisa significativa).
As Instruções de Gerenciamento da NASA
Regra 81: As instruções de gerenciamento da NASA foram escritas por outro empregado como você; assim, questione-as se elas não fizerem sentido. É possível que outro funcionário da NASA vá reescrevê-las ou pô-las de lado por sua causa.
Tomando Decisões
Regra 82: Decisões erradas tomadas cedo podem ser recuperadas. Decisões certas tomadas tarde demais não podem corrigi-las.
Regra 83: Às vezes a melhor coisa a fazer é nada. Eventualmente é também a melhor ajuda que você pode dar. Apenas escutar é tudo o que é preciso em muitas ocasiões. Você pode ser o chefe, mas se constantemente tem que resolver o problema de alguém, você está trabalhando por ele.
Regra 84: Nunca tome uma decisão baseada num esboço. Procure pelo equipamento real ou qualquer informação de fato que estiver disponível, como diagramas. Tempo demais é desperdiçado por pessoas analisando um esboço cuja função é apresentar um princípio.
Ética Profissional e Integridade
Regra 85: Integridade significa que seus subordinados confiam em você.
Regra 86: Na correria para atingir as metas, é sempre importante lembrar para quem você trabalha. Deixar o chefe sem a visão do todo não vai ser bom para você a longo prazo.
Gerenciamento de Projetos e Trabalho de Equipe
Regra 87: Os projetos requerem trabalho de equipe para obter sucesso. Lembre-se, a maioria dos times têm um treinador e não um chefe, mas o treinador ainda deve chamar algumas das jogadas.
Regra 88: Nunca assuma que alguém sabe alguma coisa ou fez alguma coisa a menos que você lhe tenha perguntado; até mesmo o óbvio é subestimado ou ignorado quando for necessário, especialmente numa atividade de grande stress.
Regra 89: Quem quer que tenha dito que mendigos não podem escolher muito não entende nada de gerenciamento de projetos, apesar de que muitas vezes é melhor confiar na sorte do que conseguir um apoio fraco.
Regra 90: Um quebra-cabeça é difícil de identificar a partir de apenas uma peça; assim, não se surpreenda se membros do time sem todas as informações chegarem à conclusão errada.
Regra 91: Lembre-se, o Presidente, o Congresso, a OMB, o QG da NASA, a alta direção e seus clientes, todos têm trabalho a fazer. Tudo o que você deve fazer é mantê-los felizes.
Tratando e Evitando Fracassos
Regra 92: No caso de um fracasso:
a) Faça um cronograma dos eventos e inclua tudo que souber;
b) Derrube os fatos conhecidos. Verifique cada teoria contra eles;
c) Não bata nos dados até que eles confessem (i.e., saiba quando parar de tentar forçar um cenário);
d) Não chegue a uma conclusão rápido demais. Tenha certeza de que qualquer anormalidade foi explicada. Lembre-se que a conclusão errada é prólogo para o próximo fracasso;e) Saiba quando parar.
Regra 93: Coisas que falham são lições aprendidas para o futuro. Ocasionalmente, as coisas dão certo: estas também são lições aprendidas. Tente repetir aquilo que funcionar.
Regra 94: Erros são aceitáveis, mas o fracasso não é. Fracasso é somente um erro do qual você não pode se recuperar; assim, tente criar planos de contingência e estratégias alternativas para os itens ou planos que têm alto risco.
Regra 95: A História é um prólogo. Nunca houve um projeto até hoje que não tenha tido problemas numa de suas partes, a despeito de todos os requisitos e testes feitos. Tempo e estar preparado para reagir são as únicas proteções.
Regra 96: Experiência pode ser boa, mas testar é melhor. Saber que algo vai funcionar nunca substitui a prova de que ele funciona.
Regra 97: Não tenha medo de falhar ou você não vai obter sucesso, mas sempre trabalhe sua capacidade de recuperação. Parte desta capacidade é saber quem pode lhe ajudar.
Regra 98: Uma das vantagens da NASA nos primeiros anos era o fato de que todo mundo sabia que os fatos a respeito dos quais tínhamos toda a certeza podiam estar errados.
Regra 99: Redundância em equipamentos pode ser uma ficção. Nós somos adeptos de construir coisas para serem idênticas, de modo que se uma falhar, a outra também vai falhar. Tenha certeza de que todos os equipamentos sejam construídos como se fossem únicos e necessários para o sucesso da missão.
Regra 100: Nunca dê desculpas; ao invés disso, apresente planos de ações a tomar.
Fonte: NASA
O Gerente de Projetos; Trabalho Inicial; Comunicações; Pessoal; Revisões e Relatórios; Contratados e Contratações; Engenheiros e Cientistas; Equipamentos; Computadores e Software; Alta Administração, Program Offices e Outros; Planejamento do Programa, Orçamento e Estimativas; Cliente; As Instruções de Gerenciamento da NASA; Tomando Decisões; Ética Profissional e Integridade; Gerenciamento de Projetos e Trabalho de Equipe; Tratando e Evitando Fracassos
O Gerente de Projetos
Regra 1: Um gerente de projetos deve visitar ao menos uma vez toda pessoa que está produzindo alguma coisa para o seu projeto; deve conhecer todos os gerentes no seu projeto (tanto do governo como do contratado), e conhecer os membros do time de integração. As pessoas gostam de saber que o gerente de projetos está interessado no seu trabalho e a melhor demonstração desse interesse é visitá-los e ver em primeira mão o que estão fazendo.
Regra 2: Um gerente de projetos precisa saber o que motiva os contratados do projeto (i.e., seu sistema de premiação, seu sistema fiscal, suas políticas e a cultura da sua companhia).
Regra 3: Os princípios de administração continuam os mesmos. Acontece apenas que as ferramentas mudaram. Você ainda encontra as pessoas certas para fazer o trabalho e sai do caminho para que elas possam realizá-lo.
Regra 4: Seja com quem for que você fizer um acordo, seja justo. O Espaço não é um grande parque de diversões. Você pode ser surpreendido com a freqüência com que você tem de trabalhar com as mesmas pessoas. Melhor que elas o respeitem do que carreguem ressentimentos.
Regra 5: Pessoas cruéis, desprezíveis, ou muito antipáticas, cavalheiros e damas podem ser gerentes de projeto. “Almas desgarradas”, procrastinadores e indecisos não podem.
Regra 6: Um gerente de projetos confortável é alguém esperando pela sua próxima missão ou alguém à beira do fracasso. Segurança não é normal em gerenciamento de projetos.
Regra 7: Um problema que os novos gerentes descobrem é que todos querem resolver seus problemas. Velhos gerentes ouviram da alta administração – “resolva seus próprios malditos problemas, é para fazer isso que nós te contratamos”.
Regra 8: Fazer rápido não toma o lugar de pensar consigo mesmo. É preciso ter tempo para “cheirar as rosas”. Para o seu trabalho, você precisa ter tempo para entender as conseqüências das suas ações.
Regra 9: O chefe pode não saber como fazer o trabalho, mas ele deve saber o que quer. Se ele não sabe, deve descobrir o que espera e quer. Um líder cego tende a andar em círculos.
Regra 10: Nem todos os gerentes bem-sucedidos são competentes e nem todos os gerentes mal-sucedidos são incompetentes. A sorte ainda representa uma parte do sucesso ou do fracasso, mas favorece o gerente competente que trabalha duro.
Regra 11: Nunca tente responder à altura alguma desconsideração de alguém no projeto. Isso não é um bom costume e o coloca no mesmo nível da outra pessoa. Além disso, provavelmente termina por prejudicar a execução do projeto.
Regra 12: Não se torne demasiadamente arrogante a ponto de não poder mudar sua posição, especialmente se o seu pessoal lhe disser que você está errado. Cultive uma atitude no projeto onde o seu pessoal saiba que pode lhe falar sobre decisões erradas.
Regra 13: Um gerente que é seu próprio Engenheiro de Sistemas ou Gerente Financeiro é alguém que provavelmente tentará realizar uma cirurgia aberta de coração em si mesmo.
Regra 14: A maioria dos gerentes obtém sucesso na força e capacidade da sua equipe.
Trabalho Inicial
Regra 15: As sementes dos problemas são jogadas cedo. O planejamento inicial é a parte mais vital de um projeto. A revisão da maioria dos projetos mal-sucedidos ou problemas de projeto, indicam que os desastres foram desde o início bem planejados para acontecer.
Comunicações
Regra 16: Esforços cooperativos exigem boa comunicação e sistemas de aviso/prevenção antecipados. Um gerente de projetos deve tentar manter seus colaboradores cientes do que está acontecendo e deve ser aquele que lhes fala em primeiro lugar de qualquer rumor ou mudança real de planos. Os colaboradores devem ser consultados antes que as coisas sejam colocadas na forma final, mesmo se eles têm apenas uma pequena parcela da ação. Um gerente de projetos que limita a visão dos seus colaboradores será tratado de forma distante e será considerado uma pessoa sem integridade.
Regra 17: Conversar não é barato; mas a melhor maneira de entender um problema técnico ou pessoal é conversar com as pessoas certas. Falta de conversação num nível adequado é mortal.
Regra 18: A maioria dos encontros internacionais são realizados em inglês. Esta é uma língua estrangeira para a maioria dos participantes como Americanos, Alemães, Italianos, etc. É importante ter discussões adequadas de forma que não haja má interpretação do que é dito.
Regra 19: Você não pode ser ignorante na linguagem da área que gerencia ou daquelas áreas com que interage. Educação é uma necessidade para o gerente moderno. Existem cursos simples para aprender computês, comuniquês e todo o resto dos modernos “êses” do mundo. Você não pode gerenciar se você não entender o que está sendo dito ou escrito.
Pessoal
Regra 20: Você não pode prestar atenção em tudo. O que você pode fazer é observar as pessoas. Elas têm de saber que você não vai aceitar um trabalho pobre.
Regra 21: Nós desenvolvemos um grupo de pessoas cujo interesse particular é mais importante que o trabalho; ou ao menos assim parece para gerentes mais velhos. Parece aos antigos gerentes que aqueles mais novos são mais interessados na forma que no conteúdo. A questão é: os velhos gerentes estão certos ou estão apenas velhos? Considere ambos os pontos-de-vista.
Regra 22: Um bom técnico, inspetor de qualidade e um chefe flexível são mais importantes na obtenção de um bom produto do que todos os papéis e revisões.
Regra 23: A origem da maioria dos problemas são as pessoas; mas diabos se elas vão admitir. Conheça as pessoas trabalhando no seu projeto para saber quais são os seus reais pontos fracos.
Regra 24: É preciso prestar muita atenção aos workaholics – se eles estiverem indo na direção errada, podem fazer um grande estrago num curto período. É possível sobrecarregá-los e vencer pelo cansaço, mas é difícil determinar se a carga é muito grande, já que grande parte dela é autogerada. É importante garantir que tais pessoas tenham tempo livre suficiente e que a carga de trabalho não exceda 25% a 50% do normal.
Regra 25: Sempre tente negociar seu apoio interno até o mais baixo nível. O que você quer é o apoio da pessoa fazendo o trabalho, e quanto mais você conseguir se aproximar dela nas negociações, melhor.
Regra 26: Se você tem alguém que não olha, pergunta e analisa; peça que o transfiram.
Regra 27: Tempo particular é muito importante. Você precisa ser cuidadoso, como gerente, para que perceba o valor do tempo das outras pessoas (i.e., o trabalho que você distribui e as reuniões devem ser necessárias). Você precisa, onde for possível, isolar a sua equipe daquele trabalho desnecessário (i.e., alguns pedidos devem ser ignorados ou uma resposta negativa enviada ao demandante).
Regra 28: As pessoas que apenas monitoram o trabalho e não ajudam a realizá-lo nunca parecem saber exatamente o que está acontecendo (estar envolvido é a chave para a excelência).
Regra 29: Não existe maior motivação do que dar a uma pessoa competente sua peça no quebra-cabeça para controlar; mas um tapinha nas costas ou uma recompensa sempre ajudam.
Regra 30: São principalmente os incompetentes que não gostam de exibir o seu trabalho.
Regra 31: Existem raras ocasiões em que uma pessoa – e só ela – pode fazer o trabalho. Estes especialistas estão em áreas técnicas que são mais artísticas e de habilidade do que o normal. Trate muito bem estas pessoas, mas consiga o seu trabalho pronto assim que for possível. Conseguir o trabalho realizado por uma outra pessoa leva duas ou três vezes mais; e o produto normalmente é abaixo da média.
Regra 32: As pessoas têm razões para fazer as coisas do jeito que fazem. A maioria quer fazer um bom trabalho e, se não fazem, o problema é que provavelmente não sabem como ou exatamente o que é esperado.
Regra 33: Se você tem um problema que para ser resolvido exige mais pessoas, você deve se parecer, ao colocar mais gente, como um cozinheiro que pôs pouco sal na comida.
Revisões e Relatórios
Regra 34: A NASA definiu um conjunto de revisores e um conjunto de revisões. Uma vez que esteja firmemente estabelecido, o sistema vai voar sozinho, assim use-o ao máximo. Tente encontrar uma forma das revisões serem úteis para você.
Regra 35: O número de revisões está aumentando, mas a transferência de conhecimento continua a mesma; então, todos os seus gráficos e apresentações devem ser construídos com isso em mente. Isto significa que você deve ser capaz de construir um conjunto de slides que apenas precisassem ser reorganizados de uma apresentação para outra.
Regra 36: Não esconda nada dos revisores. A reputação deles e a sua está na mira. Mostre todas as verrugas e espinhas. Não ofereça desculpas – apenas declare os fatos.
Regra 37: Revisões externas são marcadas na pior hora possível. Então, mantenha um conjunto de informações técnicas e do negócio atualizadas, de forma que você possa responder rapidamente. Não ter informações atualizadas deve ser motivo de demissão.
Regra 38: Nunca diminua sua equipe em público (i.e., em reuniões públicas, não reverta decisões de trabalhos que você lhes deu para fazer). Mesmo que você ordene uma mudança, nunca tire da sua equipe a responsabilidade por implementá-la.
Regra 39: Revisões são para o revisado e não para o revisor. A revisão é inútil se o revisado dela não aprender nada.
Regra 40: Uma reunião de trabalho tem cerca de seis participantes. Reuniões maiores do que isso são para transferência de informações (a ciência da administração tem mostrado que num grupo maior que doze, alguns estão perdendo seu tempo).
Regra 41: A quantidade de revisões e relatórios é proporcional ao entendimento do administrador (i.e., quanto menos a administração conhece ou entende sobre as atividades, mais ela requer revisões e relatórios). É necessário neste tipo de ambiente garantir que os dados sejam apresentados de forma que uma pessoa mediana, pouco familiarizada com as atividades, possa entendê-los. Manter os dados simples e claros nunca insulta a inteligência de ninguém.
Regra 42: Gerentes que se baseiam apenas na papelada para fazer seus relatórios de atividades são fracassos declarados.
Regra 43: A documentação não substitui o conhecimento. Existe uma grande diferença em como se supõe que as coisas devam ser, o que se acredita que aconteceu, e a realidade. Documentos são normalmente uma visão estática no tempo que fica rapidamente ultrapassada.
Regra 44: Só porque você entrega relatórios mensais, não pense que você pode sintetizar alguma coisa num relatório anual. Se a administração entendesse os mensais, não precisaria de um anual.
Regra 45: Abreviaturas e siglas estão se tornando um sofrimento. Cada projeto agora tem alguns milhares. Isso faz a alta administração ter de saber centenas. Use-as de forma econômica em apresentações, a não ser que seu objetivo seja confundir.
Regra 46: Lembre-se, geralmente é mais fácil fazer a papelada ridícula do trabalho do que questionar a sua necessidade. Lute apenas se for um assunto global, que vai economizar muito trabalho futuro.
Contratados e Contratações
Regra 47: Um gerente de projetos não é o monitor do trabalho de um contratado, mas deve ser o orientador. Em situações de premiação por resultados, o pessoal do governo deve fazer todos os esforços possíveis para garantir que o contratado obtenha um escore alto (i.e., esteja no cronograma e produza um bom trabalho). Contratados não falham, a NASA sim e é por isso que devemos ser proativos no apoio. Também é por isso que uma baixa avaliação prejudica ao gerente de projetos por parte do governo tanto quanto ao gerente do contratado, uma vez que significa que ele não está conseguindo ter o trabalho realizado.
Regra 48: Premiação por resultados é uma boa ferramenta que coloca disciplina tanto no contratado como no governo. O escore concedido representa o status do projeto assim como a habilidade gerencial das duas partes. O Sistema de Medição de Gerenciamento de Projetos (Project Management Measurement System – PMS) deve ser usado para verificar os escores. Baixas avaliações persistentes requerem intervenção da alta administração para determinar a razão. Bons escores contínuos (que sejam consistentes com o PMS) refletem um projeto bem conduzido, mas se estes escores não são consistentes com o PMS, a alta administração deve tomar atitudes para descobrir o porquê.
Regra 49: O moral do pessoal contratado é importante para um gerente do governo. Assim como você não quer comprar um carro construído por funcionários insatisfeitos, você não quer comprar equipamento de vôo desenvolvido por pessoas desmotivadas. Você deve tomar uma atitude ativa em motivar todas as pessoas no projeto.
Regra 50: Ser amigável com um contratado é admirável – ser um amigo dum contratado é perigoso para sua objetividade.
Regra 51: Lembre-se, seu fornecedor de pessoal tem uma tendência a ter uma interface um-para-um com a sua equipe. Cada membro da sua equipe custa a você ao menos uma pessoa no contrato por ano.
Regra 52: Fornecedores tendem a avaliar a capacidade dos funcionários da equipe do governo e recrutar sua parte do projeto de acordo com isso. Se pensarem que os seus funcionários são ferro-velho, eles vão colocar no seu projeto suas pessoas menos capacitadas.
Regra 53: Contratados respondem bem ao cliente que presta atenção no que eles estão fazendo, mas não muito bem ao cliente que fica dando palpites na sua atividade. A regra básica é que o cliente sempre tem razão, mas o custo vai crescer se um cliente sempre quiser as coisas feitas da sua maneira ao invés daquela planejada pelo contratado. A regra é: nunca mude os planos do contratado a não ser que eles estejam errados ou muito caros (i.e., a velha máxima de que o ótimo é inimigo do bom).
Regra 54: Existe apenas uma solução para um gerente de projetos fraco na indústria – livre-se dele rápido. O principal trabalho de um gerente de projetos na indústria é manter o cliente feliz. Garanta que aquele que estiver trabalhando com você saiba que não é a bajulação, mas obedecer o cronograma, manter-se nos custos previstos e entregar um bom produto que faz você feliz.
Engenheiros e Cientistas
Regra 55: Engenharia excessiva é comum. Engenheiros gostam de quebra-cabeças e labirintos. Tente fazê-los manter seus projetos simples.
Regra 56: O primeiro sinal de problema vem da curva de cronograma ou de custo. Engenheiros são os últimos a saber que estão com problemas. Engenheiros nascem otimistas.
Regra 57: O projeto tem muitos recursos internos. Há provavelmente cinco ou dez engenheiros de sistemas levando em conta todos os contratados e desenvolvedores de instrumentos. Este é um poderoso recurso que pode ser usado para atacar problemas.
Regra 58: Muitos gerentes, só porque têm os cientistas sob contrato no seu projeto, esquecem que os cientistas são seus clientes e muitas vezes têm acesso mais fácil à alta administração do que eles próprios.
Regra 59: A maioria dos cientistas são racionais, a menos que você ponha em perigo a chance deles realizarem seus experimentos. Eles vão trabalhar com você se acreditarem que você está lhes dizendo a verdade. Isto inclui reduzir-lhes os próprios planos.
Equipamentos
Regra 60: Na indústria espacial, não existem coisas como equipamentos previamente pilotados. As pessoas que constroem a próxima unidade provavelmente nunca viram a unidade anterior. Existem provavelmente pequenas mudanças (talvez até mudanças importantes), o ambiente operacional provavelmente mudou; as pessoas que checam a unidade na maioria dos casos não a entendem, e nem aos equipamentos de testes.
Regra 61: A maioria dos equipamentos funciona conforme construído, não como o projetista planejou. Isto acontece devido ao layout do projeto, falha de entendimento por parte do projetista ou falha no entendimento das especificações do componente.
Computadores e Software
Regra 62: Não usar técnicas modernas, como sistemas computacionais, é um grande erro, mas esquecer que o computador simula o pensamento é um erro ainda maior.
Regra 63: O software já tem hoje todos os parâmetros do hardware (i.e., mudanças de requisito, alta porcentagem do custo da missão espacial, necessidade de controle de qualidade, necessidade de procedimentos de validação, etc.). E tem a característica adicional de ser quase impossível determinar que não possua defeito. Faça funcionar o básico do sistema e só então acrescente os sinos e apitos. Nunca jogue fora uma versão que funciona, mesmo se tiver toda a confiança de que a versão mais nova está OK. É necessário ter planos de contingência para software.
Regra 64: O conhecimento é normalmente revisado através de simulações ou testes, mas modelos computacionais têm erros ocultos, dos quais o menor deles não é ter dados de entrada pobres.
Regra 65: Nos tempos antigos, os engenheiros tinham a experiência prática, técnicos sabiam como a eletrônica funcionava e o que se esperava que fizesse, e técnicos de layout também tinham conhecimento – mas hoje só o computador sabe com certeza e ele ainda não está falando.
Alta Administração, Program Offices e Outros
Regra 66: Não assuma que você sabe o porquê da alta administração ter feito alguma coisa. Se você sente que deve saber, pergunte. Você receberá algumas respostas incríveis que vão surpreendê-lo.
Regra 67: Conheça seus superiores – alguns gostam de uma boa piada, outros só gostam de uma piada se eles a contarem.
Regra 68: Lembre-se, o chefe tem o direito de tomar decisões. Mesmo se você pensar que ele está errado, diga-lhe o que você pensa, mas se ele ainda quiser feito do seu jeito, faça do jeito dele e esforce-se ao máximo para que o resultado seja bem-sucedido.
Regra 69: Nunca peça a seu superior para tomar uma decisão que você pode tomar. Assuma que você tem a autoridade para tomar decisões a não ser que saiba que há um documento que estabeleça inequivocamente que você não pode.
Regra 70: Você e o Gerente do Programa devem trabalhar como um time. O Gerente do Programa é o seu advogado no Quartel-General da NASA e deve estar próximo dos tomadores de decisão e deve auxiliar seus esforços de estar próximo também.
Regra 71: Saiba quem são os tomadores de decisão do programa. Pode ser alguém de fora que tenha o ouvido do Congresso ou o Administrador, ou o Administrador Associado, ou um dos cientistas – alguém na cadeia de comando – seja que for. Tente estabelecer uma linha de comunicação com eles, seja numa base formal ou informal.
Planejamento do Programa, Orçamento e Estimativas
Regra 72: Hoje em dia precisamos expandir o estado da arte, ficar dentro do orçamento, aceitar riscos, não errar e ser pontuais. Estranhamente, tudo isso anda bem desde que as regras básicas como o perfil dos recursos e o planejamento sejam definidos com antecedência e mantidos.
Regra 73: As maiorias dos projetos antigos extrapolavam o previsto por causa de estimativas ruins e não por causa de erros. Aumentar as estimativas não vai baixar os custos da NASA, mas vai melhorar a sua reputação. Na realidade, existe uma alta probabilidade de que ter melhores estimativas vai aumentar os custos e garantir um maior lucro para a indústria, a não ser que os honorários diminuam para refletir um menor risco por parte dela. Uma melhor reputação é necessária no ambiente atual.
Regra 74: Todos os problemas são solucionáveis num tempo, assim tenha certeza de ter suficiente contingência no cronograma – se você não tiver, o próximo gerente de projetos que ocupará o seu lugar, terá.
Regra 75: A velha NASA expandiu os limites da tecnologia e ciência; desta forma, ela não se importava com requisitos incompletos ou excessivos. A nova NASA deve trabalhar como se todos os projetos fossem de preço fechado (“fixed price”). Assim, requisitos incompletos se tornaram um pecado mortal.
Regra 76: Conheça os recursos da sua área e, se possível, de outras áreas. Outras áreas, se têm os recursos, geralmente ficam felizes em ajudar. É sempre surpreendente quanta coisa boa se pode conseguir apenas pedindo.
Regra 77: Além da informação orçamentária antes da submissão pelo Presidente ao Congresso, provavelmente não há informações secretas num projeto – então não trate coisa alguma como segredo. Todos produzem melhor se puderem ver o quadro todo, assim não esconda nada de ninguém.
Regra 78: Os programas da NASA competem por recursos de orçamento – eles não competem uns com os outros (i.e., você nunca ataca outro programa ou trabalho da NASA com a idéia de que possa receber seus recursos). Venda o que você tiver pelo seu próprio mérito.
Regra 79: O “ano que vem” é sempre o ano com recursos e prazos adequados. O “ano que vem” chega no 50º ano da sua carreira.
O Cliente
Regra 80: Lembre-se quem é o cliente e quais são os seus objetivos (i.e., confira com ele
quando você for mudar alguma coisa significativa).
As Instruções de Gerenciamento da NASA
Regra 81: As instruções de gerenciamento da NASA foram escritas por outro empregado como você; assim, questione-as se elas não fizerem sentido. É possível que outro funcionário da NASA vá reescrevê-las ou pô-las de lado por sua causa.
Tomando Decisões
Regra 82: Decisões erradas tomadas cedo podem ser recuperadas. Decisões certas tomadas tarde demais não podem corrigi-las.
Regra 83: Às vezes a melhor coisa a fazer é nada. Eventualmente é também a melhor ajuda que você pode dar. Apenas escutar é tudo o que é preciso em muitas ocasiões. Você pode ser o chefe, mas se constantemente tem que resolver o problema de alguém, você está trabalhando por ele.
Regra 84: Nunca tome uma decisão baseada num esboço. Procure pelo equipamento real ou qualquer informação de fato que estiver disponível, como diagramas. Tempo demais é desperdiçado por pessoas analisando um esboço cuja função é apresentar um princípio.
Ética Profissional e Integridade
Regra 85: Integridade significa que seus subordinados confiam em você.
Regra 86: Na correria para atingir as metas, é sempre importante lembrar para quem você trabalha. Deixar o chefe sem a visão do todo não vai ser bom para você a longo prazo.
Gerenciamento de Projetos e Trabalho de Equipe
Regra 87: Os projetos requerem trabalho de equipe para obter sucesso. Lembre-se, a maioria dos times têm um treinador e não um chefe, mas o treinador ainda deve chamar algumas das jogadas.
Regra 88: Nunca assuma que alguém sabe alguma coisa ou fez alguma coisa a menos que você lhe tenha perguntado; até mesmo o óbvio é subestimado ou ignorado quando for necessário, especialmente numa atividade de grande stress.
Regra 89: Quem quer que tenha dito que mendigos não podem escolher muito não entende nada de gerenciamento de projetos, apesar de que muitas vezes é melhor confiar na sorte do que conseguir um apoio fraco.
Regra 90: Um quebra-cabeça é difícil de identificar a partir de apenas uma peça; assim, não se surpreenda se membros do time sem todas as informações chegarem à conclusão errada.
Regra 91: Lembre-se, o Presidente, o Congresso, a OMB, o QG da NASA, a alta direção e seus clientes, todos têm trabalho a fazer. Tudo o que você deve fazer é mantê-los felizes.
Tratando e Evitando Fracassos
Regra 92: No caso de um fracasso:
a) Faça um cronograma dos eventos e inclua tudo que souber;
b) Derrube os fatos conhecidos. Verifique cada teoria contra eles;
c) Não bata nos dados até que eles confessem (i.e., saiba quando parar de tentar forçar um cenário);
d) Não chegue a uma conclusão rápido demais. Tenha certeza de que qualquer anormalidade foi explicada. Lembre-se que a conclusão errada é prólogo para o próximo fracasso;e) Saiba quando parar.
Regra 93: Coisas que falham são lições aprendidas para o futuro. Ocasionalmente, as coisas dão certo: estas também são lições aprendidas. Tente repetir aquilo que funcionar.
Regra 94: Erros são aceitáveis, mas o fracasso não é. Fracasso é somente um erro do qual você não pode se recuperar; assim, tente criar planos de contingência e estratégias alternativas para os itens ou planos que têm alto risco.
Regra 95: A História é um prólogo. Nunca houve um projeto até hoje que não tenha tido problemas numa de suas partes, a despeito de todos os requisitos e testes feitos. Tempo e estar preparado para reagir são as únicas proteções.
Regra 96: Experiência pode ser boa, mas testar é melhor. Saber que algo vai funcionar nunca substitui a prova de que ele funciona.
Regra 97: Não tenha medo de falhar ou você não vai obter sucesso, mas sempre trabalhe sua capacidade de recuperação. Parte desta capacidade é saber quem pode lhe ajudar.
Regra 98: Uma das vantagens da NASA nos primeiros anos era o fato de que todo mundo sabia que os fatos a respeito dos quais tínhamos toda a certeza podiam estar errados.
Regra 99: Redundância em equipamentos pode ser uma ficção. Nós somos adeptos de construir coisas para serem idênticas, de modo que se uma falhar, a outra também vai falhar. Tenha certeza de que todos os equipamentos sejam construídos como se fossem únicos e necessários para o sucesso da missão.
Regra 100: Nunca dê desculpas; ao invés disso, apresente planos de ações a tomar.
Fonte: NASA
Líder de Projeto, Coordenador de Projeto, Gerente de Projeto, … Esclarecendo cada Função !
Há uma grande confusão no mercado em relação aos cargos para profissionais de projetos, pois é muito comum vermos anúncios de oportunidades para Coordenadores de Projetos que exigem especialização acadêmica, certificação PMP e grande experiência em projetos.
Como também vagas para Gerentes de Projetos onde é crucial que o profissional tenha grande capacidade para exercer funções técnicas, como por exemplo, de programação de software.
Estes são apenas dois exemplos superficiais de como muita gente, principalmente o mercado está um pouco confuso não só em relação a definição do nome do cargo, mas principalmente das funções a serem exercidas pelos profissionais.
Um dos grandes motivadores para esta confusão toda é que não há uma definição oficial, formalmente reconhecida em relação aos cargos para profissionais de gerenciamento de projetos para o mercado como um todo, até mesmo porque o cargo de Gerente de Projetos é relativamente novo, pelo menos no Brasil, onde há alguns anos atrás “a nomenclatura” não era utilizada como nos dias de hoje.
Bom … vamos ao foco do assunto !!!
A idéia aqui é esclarecer um pouco as diferentes funções para cada cargo que envolve o nome Projetos:
Coordenador de Projeto: Este profissional, onde é muito comum atuar em dois tipos diferentes de contextos. O primeiro e mais freqüente é quando este profissional atua como o próprio nome diz, na coordenação de uma área ou frente importante dentro de um projeto de porte geralmente de médio para grande. É muito comum nestes projetos que haja coordenadores responsáveis por alguma “parte”, como por exemplo, pela fase de construção (programação) em projeto de desenvolvimento de software, pois é na fase de execução que geralmente há um grande esforço do projeto e o papel de um coordenador se torna indispensável, pois tal função as vezes poderia não ser exercida pelo gerente do projeto por diversos fatores tais como tempo de envolvimento direto ou mesmo estar gerenciando outros projetos. Muitas vezes a falta de um conhecimento profundamente técnico do gerente de projetos justifica a presença de um Coordenador.
Para os casos de projetos de software, o papel do Coordenador de Projetos pode ser muito amplo, podendo ir deste o entendimento de requisitos, validações técnicas, distribuição e validação das demandas de trabalho e até mesmo (em muitos casos), colocar a mão na massa, ou seja, realizar também a programação.
É importante mencionar, que para esta função, o foco do Coordenador é mais voltado para as questões técnicas ou mesmo de negócio (escopo) do Projeto. Em algumas estruturas este profissional é chamando inclusive de Coordenador ou Líder técnico, pois geralmente o profissional que ocupa esta função tem como principal característica a sua expertise técnica.
Se o foco deste profissional é técnico, entende-se que a questão da gestão não deveria ser atribuída na sua totalidade para ele, pois só a questão técnica em muitas vezes toma toda a atenção e tempo do Coordenador. É comum que este profissional tenha uma interatividade muito grande com o Gerente do Projeto, no sentido de lhe fornecer todos os dados pertinentes para que o Gestor do Projeto possa realizar os controles da entregas do projeto, além dos custos, riscos, comunicações e etc.
Há um outro contexto que a figura do Coordenador de Projetos aparece. Nas estruturas matriciais, principalmente as equilibradas ou fracas, onde a responsabilidade do projeto geralmente recaí em um gerente funcional para a qual o Coordenador de Projetos hierarquicamente responde.
Apenas como curiosidade, hoje a grande maioria dos alunos que buscam os cursos de especialização (MBA) em gerenciamento de projetos são exatamente profissionais com este perfil e nestas situações profissionais.
Líder de Projetos: Este é um profissional de gestão ! A diferença para o mercado é que o tal Líder atua em contextos menores, ou seja, projetos de pequeno porte, com escopo, orçamentos e equipes de pequeno porte, mas que a gestão (como para qualquer projeto) é essencial. Muitas vezes nestas situações um pouco mais simples é comum ver o Líder de Projeto envolvido em questões técnicas, mas nunca deixando o foco do gerenciamento (principalmente escopo, tempo, custos e qualidade) de lado. Este envolvimento técnico é possível geralmente pelo pouco tempo gasto no gerenciamento, principalmente quando um plano de projeto é bem elaborado, a execução tem poucos desvios e também a quantidade de projetos sob gestão do Líder é baixa.
Para o Líder de Projetos, o perfil ideal que o mercado busca é o profissional que tenha uma boa bagagem técnica e principalmente visão de processos, técnicas e boas práticas de gerenciamento de projetos.
Gerente de Projetos: Profissional integralmente responsável pelo empreendimento que gerencia. Ou seja, responsável pelo escopo, custos, riscos, qualidade e pela equipe. É o ponto focal de clientes, áreas usuárias e fornecedores, além do efetivo gerenciamento adequado da comunicação junto a todas as partes interessadas do Projeto.
Este é o profissional que tem como objetivo final entregar o produto ou serviço resultante do projeto conforme as expectativas acordadas (principalmente as restrições), satisfazendo o cliente final, patrocinadores e equipes.
O perfil exigido para um Gerente de Projetos hoje no mercado é de um profissional com experiência em sua área de atuação (desenvolvimento de software, infraestrutura, construção civil), vivência em gerenciamento de projetos, domínio de técnicas, processos e ferramentas de gerenciamento e preferencialmente com uma especialização na área de projetos (MBA) e ou uma certificação internacional como o PMP.
Para finalizar, é bom lembrar que as variações de nomenclaturas e funções em geral (para quaisquer cargos) podem estar vinculadas aos aspectos políticos, culturais e estruturais de cada Organização.
A idéia aqui foi passar uma visão do lado generalista do mercado. Portanto as definições acima não são uma regra.
Marcos Pires, PMP, Gerente de escritório de projetos (PMO), professor para cursos de MBA em Gestão de Projetos, instrutor para cursos de certificação PMP e colunista para jornais, revistas e sites sobre o tema gerenciamento de projetos.
Email: marcos.pires.2000@bol.com.br
Perfil: http://www.linkedin.com/in/marcospiresgp
Twitter: www.twitter.com/projetizado
Como também vagas para Gerentes de Projetos onde é crucial que o profissional tenha grande capacidade para exercer funções técnicas, como por exemplo, de programação de software.
Estes são apenas dois exemplos superficiais de como muita gente, principalmente o mercado está um pouco confuso não só em relação a definição do nome do cargo, mas principalmente das funções a serem exercidas pelos profissionais.
Um dos grandes motivadores para esta confusão toda é que não há uma definição oficial, formalmente reconhecida em relação aos cargos para profissionais de gerenciamento de projetos para o mercado como um todo, até mesmo porque o cargo de Gerente de Projetos é relativamente novo, pelo menos no Brasil, onde há alguns anos atrás “a nomenclatura” não era utilizada como nos dias de hoje.
Bom … vamos ao foco do assunto !!!
A idéia aqui é esclarecer um pouco as diferentes funções para cada cargo que envolve o nome Projetos:
Coordenador de Projeto: Este profissional, onde é muito comum atuar em dois tipos diferentes de contextos. O primeiro e mais freqüente é quando este profissional atua como o próprio nome diz, na coordenação de uma área ou frente importante dentro de um projeto de porte geralmente de médio para grande. É muito comum nestes projetos que haja coordenadores responsáveis por alguma “parte”, como por exemplo, pela fase de construção (programação) em projeto de desenvolvimento de software, pois é na fase de execução que geralmente há um grande esforço do projeto e o papel de um coordenador se torna indispensável, pois tal função as vezes poderia não ser exercida pelo gerente do projeto por diversos fatores tais como tempo de envolvimento direto ou mesmo estar gerenciando outros projetos. Muitas vezes a falta de um conhecimento profundamente técnico do gerente de projetos justifica a presença de um Coordenador.
Para os casos de projetos de software, o papel do Coordenador de Projetos pode ser muito amplo, podendo ir deste o entendimento de requisitos, validações técnicas, distribuição e validação das demandas de trabalho e até mesmo (em muitos casos), colocar a mão na massa, ou seja, realizar também a programação.
É importante mencionar, que para esta função, o foco do Coordenador é mais voltado para as questões técnicas ou mesmo de negócio (escopo) do Projeto. Em algumas estruturas este profissional é chamando inclusive de Coordenador ou Líder técnico, pois geralmente o profissional que ocupa esta função tem como principal característica a sua expertise técnica.
Se o foco deste profissional é técnico, entende-se que a questão da gestão não deveria ser atribuída na sua totalidade para ele, pois só a questão técnica em muitas vezes toma toda a atenção e tempo do Coordenador. É comum que este profissional tenha uma interatividade muito grande com o Gerente do Projeto, no sentido de lhe fornecer todos os dados pertinentes para que o Gestor do Projeto possa realizar os controles da entregas do projeto, além dos custos, riscos, comunicações e etc.
Há um outro contexto que a figura do Coordenador de Projetos aparece. Nas estruturas matriciais, principalmente as equilibradas ou fracas, onde a responsabilidade do projeto geralmente recaí em um gerente funcional para a qual o Coordenador de Projetos hierarquicamente responde.
Apenas como curiosidade, hoje a grande maioria dos alunos que buscam os cursos de especialização (MBA) em gerenciamento de projetos são exatamente profissionais com este perfil e nestas situações profissionais.
Líder de Projetos: Este é um profissional de gestão ! A diferença para o mercado é que o tal Líder atua em contextos menores, ou seja, projetos de pequeno porte, com escopo, orçamentos e equipes de pequeno porte, mas que a gestão (como para qualquer projeto) é essencial. Muitas vezes nestas situações um pouco mais simples é comum ver o Líder de Projeto envolvido em questões técnicas, mas nunca deixando o foco do gerenciamento (principalmente escopo, tempo, custos e qualidade) de lado. Este envolvimento técnico é possível geralmente pelo pouco tempo gasto no gerenciamento, principalmente quando um plano de projeto é bem elaborado, a execução tem poucos desvios e também a quantidade de projetos sob gestão do Líder é baixa.
Para o Líder de Projetos, o perfil ideal que o mercado busca é o profissional que tenha uma boa bagagem técnica e principalmente visão de processos, técnicas e boas práticas de gerenciamento de projetos.
Gerente de Projetos: Profissional integralmente responsável pelo empreendimento que gerencia. Ou seja, responsável pelo escopo, custos, riscos, qualidade e pela equipe. É o ponto focal de clientes, áreas usuárias e fornecedores, além do efetivo gerenciamento adequado da comunicação junto a todas as partes interessadas do Projeto.
Este é o profissional que tem como objetivo final entregar o produto ou serviço resultante do projeto conforme as expectativas acordadas (principalmente as restrições), satisfazendo o cliente final, patrocinadores e equipes.
O perfil exigido para um Gerente de Projetos hoje no mercado é de um profissional com experiência em sua área de atuação (desenvolvimento de software, infraestrutura, construção civil), vivência em gerenciamento de projetos, domínio de técnicas, processos e ferramentas de gerenciamento e preferencialmente com uma especialização na área de projetos (MBA) e ou uma certificação internacional como o PMP.
Para finalizar, é bom lembrar que as variações de nomenclaturas e funções em geral (para quaisquer cargos) podem estar vinculadas aos aspectos políticos, culturais e estruturais de cada Organização.
A idéia aqui foi passar uma visão do lado generalista do mercado. Portanto as definições acima não são uma regra.
Marcos Pires, PMP, Gerente de escritório de projetos (PMO), professor para cursos de MBA em Gestão de Projetos, instrutor para cursos de certificação PMP e colunista para jornais, revistas e sites sobre o tema gerenciamento de projetos.
Email: marcos.pires.2000@bol.com.br
Perfil: http://www.linkedin.com/in/marcospiresgp
Twitter: www.twitter.com/projetizado
As gerações que vem por aí…
Todos aqui lembram do manifesto ágil, certo? Os quatro princípios? Pois então.
Ele traduz a corrente (ágil) que propõe uma nova visão de “gestão” de empresa, pessoas e processos. Existem muitos outros e todos são bastante similares. Todos convergem para um ponto em comum: flexibilidade, gestão de pessoas e do conhecimento.
Você acha que isso não é importante?
Então tenha a certeza que você não está preparado para o futuro.
A geração Z está chegando. Muito se fala das gerações do século 20: Baby Boomers, Geração X, Geração Y, Geração Z.
Essa separação de gerações foi realizada para buscar identificar particularidades e características próprias das pessoas que nasceram durante períodos de tempo.
Por exemplo, os Baby Boomers são aqueles que nasceram no mundo pós-guerra. Geração X são (teoricamente) os filhos dos Baby Boomers, e assim por diante.
Através da caracterização dessas gerações foi possível identificar e entender o contexto em que elas se encontravam e o funcionamento da economia, sociedade e mercado de trabalho destas épocas. Não entrarei em detalhes maiores sobre cada geração, mas o foco desse tópico é analisar o mercado de trabalho.
Não é exagero falar que os Baby Boomers viveram uma época em que o trabalho basicamente se resumia em realizar tarefas. Pensar era algo para poucos. Era a época ideal para o chamado “comando-controle”, onde os chefes mandavam, os funcionários faziam. Tudo devidamente controlado. Não havia flexibilidade e o conhecimento era muito pouco valorizado.
A geração X viveu já um mundo mais complicado. O pós-guerra dos Baby Boomers trazia uma certa esperança de dias melhores. A geração X viveu o auge da Guerra Fria e isso, aliado à sociedade composta por Baby Boomers já não tão esperançosos, os tornaram realistas e pessimistas. Muitos consideram a geração X como a geração “perdida”. Porém, foi durante o período da geração X que surgiram movimentos como o “Toyota Way” e o conceito de "Liderança Situacional”. Portanto é preciso ter cuidado para não generalizar.
Por outro lado, a geração X como um todo ainda vivia o auge do mercado onde flexibilidade e conhecimento não estavam em pauta. É a geração da “transição”, podemos chamar assim.
A geração Y, por outro lado, já foi criada em uma sociedade mais otimista e com sede de crescimento. Além disso, viveu intensamente o período do boom da era da tecnologia e da informação. E isso transformou de forma gigantesca o mercado de trabalho. As empresas agora podiam automatizar diversos processos. A informação começou a deixar de ser privilégio de poucos e secundária.
Esta geração viveu a transição da maior revolução da sociedade moderna: a internet.
Essa proximidade com a tecnologia e informação a tornou completamente diferente da sua predecessora. A geração Y passou a saber de tudo (mas sem profundidade), consegue trabalhar facilmente de forma multi-tarefa, suporta o trabalho sob pressão, é normalmente comunicativa, dentre outras características. Essa geração NÃO funciona no modo “comando e controle” e as empresas (tardiamente) começaram a se dar conta disso.
Conceitos como “gestão de competências”, “feedback”, “liderança 360 graus”, etc. se tornaram comuns.
E isso tem explicação: a geração Y normalmente não tolera empresas que não mudaram sua cultura. Se a empresa ainda viver no modo “chefe manda, funcionário faz”, terá um turnover altíssimo com pessoas dessa geração. Essas pessoas exigem flexibilidade e são adeptas ao livre conhecimento, por assim dizer. E estará comprometendo o seu futuro, pois a geração X e os Baby Boomers deixarão de ser a força motriz das empresas em pouco tempo.
Agora vamos mais adiante. E a próxima geração? O que será da geração Z?
Imaginem as crianças de hoje que já nasceram em um mundo totalmente conectado à internet. Desde o jardim de infância, essas crianças já fizeram trabalhos usando computador e a internet. O conhecimento para elas está a alguns cliques. O rítmo e a velocidade com que elas conduzem suas vidas é pelo menos 2x maior do que o da geração Y (que já era veloz!).
Será uma geração mais multi-tarefas do que nunca, com outro tipo de conhecimento e forma de pensar. O que será que essa geração demandará do mercado e das empresas?
Na minha opinião, essa geração será duplamente mais exigente do que a geração Y. E precisará ser moldada com muito cuidado, pois terão uma capacidade diferenciada para tomar decisões, pensar soluções e atuar sob pressão (lembrem-se que eles já sofrem pressões de prazos no colégio!). Por outro lado, isso poderá gerar um sentimento de auto-suficiência que deverá ser tratado com cuidado pelas empresas.
Flexibilidade será prioridade número 1 da geração.
Alie isso a fatos prováveis como: redução do número da população jovem (a geração Z será proporcionalmente menor do que as anteriores), a constante necessidade da informação e do conhecimento por parte das empresas e o rítmo cada vez mais rápido do mercado. Temos um cenário bastante interessante e desafiador pela frente.
E daí você pode se perguntar: e o que nós temos a ver com isso?
Ora, nós da Geração Y seremos os responsáveis por liderar a geração Z!
Será que nossas empresas estão preparadas para receber as primeiras pessoas desta geração?
Será que NÓS estamos preparados para lidar com eles?
Será que o que conhecemos hoje como gestão será suficiente?
Pense nisso. O futuro não está tão distante assim.
Um abraço!
http://www.agileway.com.br/2009/07/25/as-geracoes-que-vem-por-ai/
Ele traduz a corrente (ágil) que propõe uma nova visão de “gestão” de empresa, pessoas e processos. Existem muitos outros e todos são bastante similares. Todos convergem para um ponto em comum: flexibilidade, gestão de pessoas e do conhecimento.
Você acha que isso não é importante?
Então tenha a certeza que você não está preparado para o futuro.
A geração Z está chegando. Muito se fala das gerações do século 20: Baby Boomers, Geração X, Geração Y, Geração Z.
Essa separação de gerações foi realizada para buscar identificar particularidades e características próprias das pessoas que nasceram durante períodos de tempo.
Por exemplo, os Baby Boomers são aqueles que nasceram no mundo pós-guerra. Geração X são (teoricamente) os filhos dos Baby Boomers, e assim por diante.
Através da caracterização dessas gerações foi possível identificar e entender o contexto em que elas se encontravam e o funcionamento da economia, sociedade e mercado de trabalho destas épocas. Não entrarei em detalhes maiores sobre cada geração, mas o foco desse tópico é analisar o mercado de trabalho.
Não é exagero falar que os Baby Boomers viveram uma época em que o trabalho basicamente se resumia em realizar tarefas. Pensar era algo para poucos. Era a época ideal para o chamado “comando-controle”, onde os chefes mandavam, os funcionários faziam. Tudo devidamente controlado. Não havia flexibilidade e o conhecimento era muito pouco valorizado.
A geração X viveu já um mundo mais complicado. O pós-guerra dos Baby Boomers trazia uma certa esperança de dias melhores. A geração X viveu o auge da Guerra Fria e isso, aliado à sociedade composta por Baby Boomers já não tão esperançosos, os tornaram realistas e pessimistas. Muitos consideram a geração X como a geração “perdida”. Porém, foi durante o período da geração X que surgiram movimentos como o “Toyota Way” e o conceito de "Liderança Situacional”. Portanto é preciso ter cuidado para não generalizar.
Por outro lado, a geração X como um todo ainda vivia o auge do mercado onde flexibilidade e conhecimento não estavam em pauta. É a geração da “transição”, podemos chamar assim.
A geração Y, por outro lado, já foi criada em uma sociedade mais otimista e com sede de crescimento. Além disso, viveu intensamente o período do boom da era da tecnologia e da informação. E isso transformou de forma gigantesca o mercado de trabalho. As empresas agora podiam automatizar diversos processos. A informação começou a deixar de ser privilégio de poucos e secundária.
Esta geração viveu a transição da maior revolução da sociedade moderna: a internet.
Essa proximidade com a tecnologia e informação a tornou completamente diferente da sua predecessora. A geração Y passou a saber de tudo (mas sem profundidade), consegue trabalhar facilmente de forma multi-tarefa, suporta o trabalho sob pressão, é normalmente comunicativa, dentre outras características. Essa geração NÃO funciona no modo “comando e controle” e as empresas (tardiamente) começaram a se dar conta disso.
Conceitos como “gestão de competências”, “feedback”, “liderança 360 graus”, etc. se tornaram comuns.
E isso tem explicação: a geração Y normalmente não tolera empresas que não mudaram sua cultura. Se a empresa ainda viver no modo “chefe manda, funcionário faz”, terá um turnover altíssimo com pessoas dessa geração. Essas pessoas exigem flexibilidade e são adeptas ao livre conhecimento, por assim dizer. E estará comprometendo o seu futuro, pois a geração X e os Baby Boomers deixarão de ser a força motriz das empresas em pouco tempo.
Agora vamos mais adiante. E a próxima geração? O que será da geração Z?
Imaginem as crianças de hoje que já nasceram em um mundo totalmente conectado à internet. Desde o jardim de infância, essas crianças já fizeram trabalhos usando computador e a internet. O conhecimento para elas está a alguns cliques. O rítmo e a velocidade com que elas conduzem suas vidas é pelo menos 2x maior do que o da geração Y (que já era veloz!).
Será uma geração mais multi-tarefas do que nunca, com outro tipo de conhecimento e forma de pensar. O que será que essa geração demandará do mercado e das empresas?
Na minha opinião, essa geração será duplamente mais exigente do que a geração Y. E precisará ser moldada com muito cuidado, pois terão uma capacidade diferenciada para tomar decisões, pensar soluções e atuar sob pressão (lembrem-se que eles já sofrem pressões de prazos no colégio!). Por outro lado, isso poderá gerar um sentimento de auto-suficiência que deverá ser tratado com cuidado pelas empresas.
Flexibilidade será prioridade número 1 da geração.
Alie isso a fatos prováveis como: redução do número da população jovem (a geração Z será proporcionalmente menor do que as anteriores), a constante necessidade da informação e do conhecimento por parte das empresas e o rítmo cada vez mais rápido do mercado. Temos um cenário bastante interessante e desafiador pela frente.
E daí você pode se perguntar: e o que nós temos a ver com isso?
Ora, nós da Geração Y seremos os responsáveis por liderar a geração Z!
Será que nossas empresas estão preparadas para receber as primeiras pessoas desta geração?
Será que NÓS estamos preparados para lidar com eles?
Será que o que conhecemos hoje como gestão será suficiente?
Pense nisso. O futuro não está tão distante assim.
Um abraço!
http://www.agileway.com.br/2009/07/25/as-geracoes-que-vem-por-ai/
ScrumMaster Interview Tips
Posted by Shane Hastie on Jul 13, 2009 11:00 AM Community Agile
The ScrumMaster or Iteration Manager is a crucial role on Agile teams, and selecting which organisation or team to work with is important – when considering taking on a new project it’s important to set the environment up for success.
The Agile Manifesto emphasises the importance of People over Process, and a large part of the ScrumMaster’s responsibility is creating a team environment where people can collaborate to deliver working software effectively.
The official Scrum website defines the responsibilities of the ScrumMaster as
The ScrumMaster is responsible for the proper and complete implementation of the Scrum process.
To the degree that the implementation must start with trade-off's and incomplete practices because of the implementation environment, the ScrumMaster will always keep the benefits and values of the complete implementation in mind and incrementally move the team and organization toward that end state.
The ScrumMaster is specifically responsible for:
• Removing the barriers between development and the customer so the customer directly drives development;
• Teaching the customer how to maximize ROI and meet their objectives through Scrum;
• Improving the lives of the development team by facilitating creativity and empowerment;
• Improving the productivity of the development team in any way possible; and,
• Improving the engineering practices and tools so each increment of functionality is potentially shippable.
Given the criticality of the role, it is important to ensure that the person taking up the role of ScrumMaster on a team is right for the role, and that the environment enables success.
David J Bland of the Scrumology blog provides a list of 10 questions for the potential ScrumMaster to consider when considering taking on a new team/project:
1. How long are your iterations? – Ideally this is 2 weeks, but if it is close within reason it is a positive sign. Be wary of extremely long answers that slip into months, as these are not agile characteristics.
2. What is your team size & make up? - Small, cross functional teams are important. Take note of any answers that lean towards large silos of developers. You may also want to follow up on whether or not the team is distributed or co-located.
3. Are your Product Owners available for questions? – A non-existent Product Owner can wreak havoc on an agile team. This could be why the Scrum Master position is vacant!
4. Do you use Continuous Integration? – It is difficult to remain true to the tenets of agile with a clunky batch process for code deployment. Try to pin them down on what tools they use here to prevent them from sidestepping the question.
5. Do you use Test Driven Development / Design? - Similar to CI above, TDD is another indicator of agility. Again try to find out the tool set they use for this process, as it will vary by technology stack.
6. How do you document User Stories? – There is no one perfect answer for this, but they should touch on small excerpts of functionality that are on a task board or in project management software. Lengthy SRS or functional specifications should raise a red flag.
7. What metrics do you use for tracking? - Points or hours should be sufficient. I’d pay attention on whether or not their fibonnacci scale goes to extremes. Measuring actuals vs estimates can lead the conversation to some interesting areas. Try to determine whether or not actuals are used against team members.
8. How often do your teams meet? – This should be every day if you are playing the role of a true Scrum Master. This can be more challenging with distributed teams in different time zones.
9. Do you have executive buy-in for agile? – While I’ve practiced grass roots agile without executive buy-in, I would not jump head first into a position without knowing the big picture. If the employer states that even C-level executives have received CSM/CPO training it is a big plus in my book.
10. What other responsibilities does the Scrum Master have? – Depending on the organization this can vary, but it is worth asking especially if they responsibilities do not interest you in the least. It is better to know about them now!
Johanna Rothman, Steve Smith, George Dinwiddie and other Aye Conference hosts provide a list of useful tips for interviews and assessments, for both interviewer and interviewee:
Interview tips:
Use open-ended questions as much as possible
Use behavior-description questions as much as possible to get real live examples
Use meta questions to ask about what else to ask about separate strategic questions of management from tactical questions of technical staff
Interview traps:
Never ask leading questions, such as "is your manager a bozo?"
You won't get an honest answer and the question diminishes your authority, authenticity, and credibility. A lot to lose in one question.
Avoid opinion questions such as, "Do you like what you do?" Instead, reframe it as, "What's working for you here?" and "What prevents you from getting your job done?"
What traps as out there for unsuspecting ScrumMasters, and how can they be avoided?
The ScrumMaster or Iteration Manager is a crucial role on Agile teams, and selecting which organisation or team to work with is important – when considering taking on a new project it’s important to set the environment up for success.
The Agile Manifesto emphasises the importance of People over Process, and a large part of the ScrumMaster’s responsibility is creating a team environment where people can collaborate to deliver working software effectively.
The official Scrum website defines the responsibilities of the ScrumMaster as
The ScrumMaster is responsible for the proper and complete implementation of the Scrum process.
To the degree that the implementation must start with trade-off's and incomplete practices because of the implementation environment, the ScrumMaster will always keep the benefits and values of the complete implementation in mind and incrementally move the team and organization toward that end state.
The ScrumMaster is specifically responsible for:
• Removing the barriers between development and the customer so the customer directly drives development;
• Teaching the customer how to maximize ROI and meet their objectives through Scrum;
• Improving the lives of the development team by facilitating creativity and empowerment;
• Improving the productivity of the development team in any way possible; and,
• Improving the engineering practices and tools so each increment of functionality is potentially shippable.
Given the criticality of the role, it is important to ensure that the person taking up the role of ScrumMaster on a team is right for the role, and that the environment enables success.
David J Bland of the Scrumology blog provides a list of 10 questions for the potential ScrumMaster to consider when considering taking on a new team/project:
1. How long are your iterations? – Ideally this is 2 weeks, but if it is close within reason it is a positive sign. Be wary of extremely long answers that slip into months, as these are not agile characteristics.
2. What is your team size & make up? - Small, cross functional teams are important. Take note of any answers that lean towards large silos of developers. You may also want to follow up on whether or not the team is distributed or co-located.
3. Are your Product Owners available for questions? – A non-existent Product Owner can wreak havoc on an agile team. This could be why the Scrum Master position is vacant!
4. Do you use Continuous Integration? – It is difficult to remain true to the tenets of agile with a clunky batch process for code deployment. Try to pin them down on what tools they use here to prevent them from sidestepping the question.
5. Do you use Test Driven Development / Design? - Similar to CI above, TDD is another indicator of agility. Again try to find out the tool set they use for this process, as it will vary by technology stack.
6. How do you document User Stories? – There is no one perfect answer for this, but they should touch on small excerpts of functionality that are on a task board or in project management software. Lengthy SRS or functional specifications should raise a red flag.
7. What metrics do you use for tracking? - Points or hours should be sufficient. I’d pay attention on whether or not their fibonnacci scale goes to extremes. Measuring actuals vs estimates can lead the conversation to some interesting areas. Try to determine whether or not actuals are used against team members.
8. How often do your teams meet? – This should be every day if you are playing the role of a true Scrum Master. This can be more challenging with distributed teams in different time zones.
9. Do you have executive buy-in for agile? – While I’ve practiced grass roots agile without executive buy-in, I would not jump head first into a position without knowing the big picture. If the employer states that even C-level executives have received CSM/CPO training it is a big plus in my book.
10. What other responsibilities does the Scrum Master have? – Depending on the organization this can vary, but it is worth asking especially if they responsibilities do not interest you in the least. It is better to know about them now!
Johanna Rothman, Steve Smith, George Dinwiddie and other Aye Conference hosts provide a list of useful tips for interviews and assessments, for both interviewer and interviewee:
Interview tips:
Use open-ended questions as much as possible
Use behavior-description questions as much as possible to get real live examples
Use meta questions to ask about what else to ask about separate strategic questions of management from tactical questions of technical staff
Interview traps:
Never ask leading questions, such as "is your manager a bozo?"
You won't get an honest answer and the question diminishes your authority, authenticity, and credibility. A lot to lose in one question.
Avoid opinion questions such as, "Do you like what you do?" Instead, reframe it as, "What's working for you here?" and "What prevents you from getting your job done?"
What traps as out there for unsuspecting ScrumMasters, and how can they be avoided?
Atitude é tudo!
Ele estava sempre de bom humor e sempre tinha algo de positivo para dizer. Se alguém lhe perguntasse como ele estava, a resposta seria logo:
- Se melhorar, estraga.
Ele era um gerente especial em um restaurante, pois seus garçons os seguiam de restaurante em restaurante apenas pelas suas atitudes. Ele era um motivador nato.
Se um colaborador estava tendo um dia ruim, Luís estava sempre dizendo como ver o lado positivo da situação.
Fiquei tão curioso com seu estilo de vida que um dia lhe perguntei:
" Você não pode ser uma pessoa positiva todo o tempo. Como
faz isso?
Ele me respondeu :
"A cada manhã ao acordar, digo para a mim mesmo: Luís, você tem duas escolhas hoje: pode ficar de bom humor ou de mau humor.
Eu escolho. "ficar de bom humor".
Cada vez que algo ruim acontece, posso escolher bancar a vítima ou aprender alguma coisa com o ocorrido.
Eu escolho "aprender algo".
Toda vez que alguém reclamar, posso escolher aceitar a reclamação ou mostrar o lado positivo da vida.
"Certo, mas não é fácil"- argumentei.
"É fácil sim", disse-me Luís.
A vida é feita de escolhas. Quando você examina a fundo, toda situação sempre oferece escolha. Você escolhe como reagir às situações. Escolhe como as pessoas afetarão o seu humor. É sua a escolha de como viver sua vida.
Eu pensei sobre o que o Luís disse e sempre lembrava dele quando fazia uma escolha.
Anos mais tarde, soube que Luís cometera um erro, deixando a porta de serviço aberta pela manhã. Foi rendido por assaltantes. Dominado, enquanto tentava abrir o cofre, sua mão tremendo pelo nervosismo, desfez a combinação do segredo. Os ladrões entraram em pânico e atiraram nele.
Por sorte foi encontrado a tempo de ser socorrido e levado para um hospital.
Depois de 18 horas de cirurgia e semanas de tratamento intensivo, teve alta ainda com fragmentos de balas alojadas em seu corpo.
Encontrei Luís mais ou menos por acaso. Quando lhe perguntei como estava, para variar me respondeu: "Se melhorar, estraga".
Contou-me o que havia acontecido perguntando:
- Quer ver minhas Cicatrizes?"
Recusei ver seus ferimentos, mas perguntei-lhe o que havia passado em sua mente na ocasião do assalto.
"A primeira coisa que pensei foi que deveria ter trancado a porta de trás, respondeu."
Então, deitado no chão, ensangüentado, lembrei que tinha duas escolhas: - poderia viver ou morrer.
Escolhi "viver".
"Você não estava com medo? "Perguntei.
- "Os para-médicos foram ótimos. Eles me diziam que tudo ia dar certo e que ia ficar bom" ...
Mas quando entrei na sala de emergência e vi a expressão dos médicos e enfermeiras, fiquei apavorado. Em seus lábios eu lia:
- "Esse aí já era".
Decidi então que tinha que fazer algo.
"O que fez?" Perguntei.
- "Bem. Havia uma enfermeira que fazia muitas perguntas.
Perguntou-me se eu era alérgico a alguma coisa. Eu respondi: sim.
Todos pararam para ouvir a minha resposta. Tomei fôlego e gritei :
- Sou alérgico a balas!
Entre risadas lhes disse:
- Eu estou escolhendo viver, operem-me como um ser vivo, não como morto."
Luís sobreviveu graças à persistência dos médicos, mas também graças a sua atitude.
Aprendi que todo dia temos a opção de viver plenamente. Afinal de contas,
"ATITUDE É TUDO".
Agora você tem duas opções:
1. Ler esta mensagem e guardá-la em alguma pasta ou
2. Transmiti-la aos seus amigos para que possam tirar conclusões e repassá-la a outras pessoas.
Eu particularmente escolhi te abençoar com esta mensagem no dia de hoje!
Faça sua escolha e, SEJA FELIZ...
- Se melhorar, estraga.
Ele era um gerente especial em um restaurante, pois seus garçons os seguiam de restaurante em restaurante apenas pelas suas atitudes. Ele era um motivador nato.
Se um colaborador estava tendo um dia ruim, Luís estava sempre dizendo como ver o lado positivo da situação.
Fiquei tão curioso com seu estilo de vida que um dia lhe perguntei:
" Você não pode ser uma pessoa positiva todo o tempo. Como
faz isso?
Ele me respondeu :
"A cada manhã ao acordar, digo para a mim mesmo: Luís, você tem duas escolhas hoje: pode ficar de bom humor ou de mau humor.
Eu escolho. "ficar de bom humor".
Cada vez que algo ruim acontece, posso escolher bancar a vítima ou aprender alguma coisa com o ocorrido.
Eu escolho "aprender algo".
Toda vez que alguém reclamar, posso escolher aceitar a reclamação ou mostrar o lado positivo da vida.
"Certo, mas não é fácil"- argumentei.
"É fácil sim", disse-me Luís.
A vida é feita de escolhas. Quando você examina a fundo, toda situação sempre oferece escolha. Você escolhe como reagir às situações. Escolhe como as pessoas afetarão o seu humor. É sua a escolha de como viver sua vida.
Eu pensei sobre o que o Luís disse e sempre lembrava dele quando fazia uma escolha.
Anos mais tarde, soube que Luís cometera um erro, deixando a porta de serviço aberta pela manhã. Foi rendido por assaltantes. Dominado, enquanto tentava abrir o cofre, sua mão tremendo pelo nervosismo, desfez a combinação do segredo. Os ladrões entraram em pânico e atiraram nele.
Por sorte foi encontrado a tempo de ser socorrido e levado para um hospital.
Depois de 18 horas de cirurgia e semanas de tratamento intensivo, teve alta ainda com fragmentos de balas alojadas em seu corpo.
Encontrei Luís mais ou menos por acaso. Quando lhe perguntei como estava, para variar me respondeu: "Se melhorar, estraga".
Contou-me o que havia acontecido perguntando:
- Quer ver minhas Cicatrizes?"
Recusei ver seus ferimentos, mas perguntei-lhe o que havia passado em sua mente na ocasião do assalto.
"A primeira coisa que pensei foi que deveria ter trancado a porta de trás, respondeu."
Então, deitado no chão, ensangüentado, lembrei que tinha duas escolhas: - poderia viver ou morrer.
Escolhi "viver".
"Você não estava com medo? "Perguntei.
- "Os para-médicos foram ótimos. Eles me diziam que tudo ia dar certo e que ia ficar bom" ...
Mas quando entrei na sala de emergência e vi a expressão dos médicos e enfermeiras, fiquei apavorado. Em seus lábios eu lia:
- "Esse aí já era".
Decidi então que tinha que fazer algo.
"O que fez?" Perguntei.
- "Bem. Havia uma enfermeira que fazia muitas perguntas.
Perguntou-me se eu era alérgico a alguma coisa. Eu respondi: sim.
Todos pararam para ouvir a minha resposta. Tomei fôlego e gritei :
- Sou alérgico a balas!
Entre risadas lhes disse:
- Eu estou escolhendo viver, operem-me como um ser vivo, não como morto."
Luís sobreviveu graças à persistência dos médicos, mas também graças a sua atitude.
Aprendi que todo dia temos a opção de viver plenamente. Afinal de contas,
"ATITUDE É TUDO".
Agora você tem duas opções:
1. Ler esta mensagem e guardá-la em alguma pasta ou
2. Transmiti-la aos seus amigos para que possam tirar conclusões e repassá-la a outras pessoas.
Eu particularmente escolhi te abençoar com esta mensagem no dia de hoje!
Faça sua escolha e, SEJA FELIZ...
Deus, dá-me as perguntas certas!
Como falar a céticos, descrentes, familiares e amigos "cabeça-dura" sobre Deus.
Eu amo responder perguntas com perguntas. Cresci numa família de italianos, onde eram comuns diálogos como estes:
Eu: Oi, vó. Como está o tempo por aí?Minha avó: E como você acha que poderia estar, bem no meio do verão?
Eu: E aí tio, como está você? Tio Henry: Por que você pergunta?
Eu: Tia, quanto tempo! E o Beto, como vai? Tia Nine: Comparado com o quê?
Atenção: “questionadores” não tentam, necessariamente, obter respostas certas.
Na verdade eles querem apenas ver você se contorcer tentando responder... Gosto de pensar que este ambiente incômodo na minha formação, acabou me ajudando, muitos anos depois, a entender a benção que é você saber responder perguntas com perguntas.
Hoje creio que isto me ajuda demais na minha tentativa diária de seguir o exemplo de Jesus.
Você já se deu conta quantas vezes Ele respondeu a uma pergunta fazendo outra?
Quando o homem rico perguntou a Jesus “Bom Mestre, o que farei para herdar a vida eterna?” Jesus respondeu: "Por que você me chama de bom?" (Mc 10:17-18).
Quando os líderes religiosos lhe perguntaram se era certo pagar impostos a César, Ele perguntou de quem era a face na moeda (Mt 22:17-20).
Quando os fariseus procuravam uma razão para acusá-lo e lhe perguntaram "É permitido curar no sábado?" a resposta de Jesus foi uma pergunta: "Qual de vocês, se tiver uma ovelha e ela cair num buraco no sábado, não irá pegá-la e tirá-la de lá?" (Mt 12:9-12).
Bom, deixe-me ser sincero: a principal razão de eu responder perguntas com perguntas é que estou cansado... Depois de anos respondendo perguntas de céticos, descrentes, familiares e amigos “cabeça-dura” eu simplesmente cansei, pois percebi que não era uma resposta que eles realmente estavam buscando.
Em algumas ocasiões (muitas, na verdade...) respondi com o que eu acreditava ser absolutamente bíblico e compreensível para ouvidos “não-treinados” - tentei, na maioria das vezes, falar em português – sem “crentear” - apenas para ver se o meu questionador ao menos movia os ombros. Mas minha triste percepção era de que apenas acabava de dar a ele mais uma razão para achar que todos nós cristãos somos uns paspalhos! Ao invés de minha resposta trazê-lo mais para perto de Jesus e de Sua salvação, ela simplesmente o empurrava pra longe. Em vez de ajudar sua mente e coração a enxergar as coisas por uma perspectiva diferente, minhas respostas apenas forneciam munição para futuros ataques contra o evangelho.
Desta forma, comecei a responder perguntas com perguntas. E meus resultados foram sensivelmente melhores.
Regra reversa
Meu ministério tem sido desenvolvido dentro do mundo corporativo. Para cada minuto que passo na eclesia são quase quinze minutos na diáspora. Vivo em sua totalidade o verso de Mt 10:16 “...os estou enviando como ovelhas entre lobos. Portanto, sejais astutos como as serpentes e sem malícia como as pombas”. E, dentro deste mundo corporativo, tenho tido muitas oportunidades de praticar no dia-a-dia aquilo que prego nos púlpitos.
Ano passado, entre meus clientes, estava um grupo empresarial muito grande, com faturamento anual na casa dos US$3 bilhões. Este grupo é dirigido por um time de poderosos e céticos executivos, cuja formação acadêmica de alto grau inclui MBA’s nas melhores universidades dos Estados Unidos e Europa.
Ao perceberem em mim uma certa “atitude de pomba” – no sentido da falta da malícia quase obrigatória naquele universo - este time resolveu me por na parede: uniram-se e passaram a questionar-me diariamente sobre os mais variados temas, relacionando assuntos cotidianos dos negócios às questões de ética e fé. Até que, finalmente, a inevitável pergunta apareceu. Um deles disse: “Bom, nós temos conversado muito sobre suas convicções e concluímos que você, lá no fundo, acredita mesmo que aqueles que não concordam com suas idéias a respeito de Deus e da Bíblia – como, por exemplo, todos os que seguem diferentes religiões, que crêem em distintas formas de manifestação de Deus ou que baseiam sua fé em outros livros que não a Bíblia – estão a caminho do inferno, não é mesmo?"
"Você acredita em inferno?" respondi, quase instintivamente...
Meus questionadores provavelmente jamais consideraram seriamente a possibilidade de céu e inferno. Minha resposta os deixou confusos, talvez porque eles estavam sendo agora desafiados, quando suas intenções eram apenas desafiar-me...
Finalmente, após um longo silêncio, ele respondeu: “Não, eu não creio em inferno. Acho isto simplesmente ridículo. "
Então escolhi utilizar a sua própria escolha de palavras e devolvi: “Então, já que você não acredita em inferno, por que está me fazendo esta pergunta ridícula?”
Eu não estava tentando ser o “senhor espertinho”. Estava apenas tentando ajudá-los a encarar honestamente as razões e motivações por detrás daquela pergunta. A expressão do grupo indicou que eu marcara um ponto importante. Foi então que outra pergunta quebrou o silêncio.
Outro membro daquele grupo disse em alto e bom som: “Bem, eu acredito em inferno. Você crê que todos os que não adotam a fé cristã irão para lá?"
E novamente eu perguntei: "Que tipo de pessoa, na sua opinião, irá para o inferno?
Hitler, por exemplo, você crê que ele está no inferno?" (falar de Hitler, apesar de desagradável, é sempre de grande auxílio, principalmente com gente que pensa que sabe demais. Este questionador específico, além de Presidente da empresa, é judeu!)
"Mas é claro que Hitler está no inferno !!" disse ele num tom áspero.
"E como você pensa que Deus decide quem vai para o céu e quem vai para o inferno? Será que Ele faz um gráfico de possibilidades?" respondi perguntando.
A partir deste momento, a conversa tornou-se amigável e civilizada. E um longo processo de diálogos sérios e enriquecedores sobre o amor de Deus, os pecados da humanidade e o grande trabalho realizado por Jesus a nosso favor começou entre eu e aquele time de executivos.
Responder com perguntas mostrou-se um método muito eficaz, apesar de indireto, para compartilhar o evangelho com um certo tipo de pessoas.
Um outra vez onde o questionamento foi mais eficaz que as respostas biblicamente inquestionáveis – obviamente inquestionáveis a partir do ponto de vista daqueles que conhecem a Jesus - foi numa feira da Associação Paulista de Supermercados. O diretor de uma grande empresa para qual eu estava prestando serviços comentou - em tom de sátira e de forma que eu ouvisse - com outro executivo do maior grupo supermercadista do país sobre o fato do meu evidente constrangimento com os trajes e a postura de algumas promotoras que faziam uma apresentação no stand onde estávamos.
Ele disse: “este aí é crente. Ele não gosta de mulher. Sua religião não permite que ele tenha mais de uma”. E então, a queima-roupa, me perguntou na frente de muitas pessoas: “Você não enjoa de só olhar para a mesma mulher há tantos anos? Se Deus as fez assim, tão lindas, que mal há em admirá-las e chegar perto delas?”
Então lhe respondi perguntando: “Suponhamos que você morasse no alto de uma montanha e, impedido de dirigir, tivesse que contratar um motorista para levar seus filhos à escola. Na estrada entre sua casa e a escola há um trecho desmoronado e, portanto, muito estreito, que obriga o carro a passar bem na beirada de um grande e profundo precipício. Ao entrevistar o primeiro motorista você pergunta: a que distância você é capaz de passar da beira do precipício?
E ele responde: Eu sou capaz de passar a 5 cm sem problemas, deixa comigo! Ao entrevistar o segundo, você repete a pergunta e ele responde que passaria a 10 cm.. Porém, ao entrevistar o terceiro você ouve como resposta EU SEMPRE PASSAREI O MAIS LONGE POSSÍVEL DA BEIRA DO PRECIPÍCIO.”
Baseado nestas suposições, perguntei: “Qual dos três você contrataria?” E ele me respondeu sem pensar: “O terceiro”.
Um longo silêncio pairou no ar.
Então sentei-me à mesa e disse: “Sabe, não é que eu não goste de mulher, eu apenas passo o mais longe possível da beira do precipício... E você?”
E naquela noite nós rimos muito no caminho entre a feira e o hotel e uma sólida amizade teve início...
Boas Perguntas
Responder a uma pergunta com outra pergunta tem vantagens significativas em relação a usar respostas diretas. Isto te ajuda a trazer à tona as razões e motivações reais por trás da pergunta.
Isto também tira a pressão dos seus ombros e a devolve aos ombros daquele que está questionando você. Isto é importante porque, como eu já disse: questionadores não tentam, necessariamente, obter respostas certas. Na verdade eles querem apenas ver você se contorcer tentando responder.
Por exemplo, os chefes dos sacerdotes, os mestres da Lei e os líderes religiosos perguntaram a Jesus: "Com que autoridade estás fazendo estas coisas? Quem te deu esta autoridade?"
Sua resposta foi: "digam-me: o batismo de João era do céu ou dos homens?”
Após uma pequena discussão entre eles, responderam: “Não sabemos de onde era”.
Jesus, então, mostrou a eles que as perguntas feitas tinham motivações equivocadas e, portanto, não mereciam uma resposta, dizendo: “Tampouco lhes direi com que autoridade estou fazendo estas coisas” (Lc 20:1-8).
Na verdade, a pergunta dos mestres era simplesmente um ataque disfarçado de pergunta.
Responder este tipo de perguntas com outras perguntas não apenas devolve o “fogo amigo” de volta a sua origem como também o faz de forma a reduzir a possibilidade de uma tréplica hostil.
As pessoas em geral não gostam de variações bruscas na temperatura das conversas, principalmente quando o calor está sobre elas, e rapidamente ajustam o termostato... Responder perguntas com outras perguntas também serve de pavimentação ao caminho para a evolução no processo de diálogo, em vez de uma resposta certa e direta que provavelmente não seria recebida por ouvidos com motivações duvidosas.
A conversa de Jesus com a mulher samaritana está dentro deste padrão (Jo 4:1-26). As noções daquela mulher sobre justiça, pecado e adoração a Deus precisavam ser mudadas antes que ela pudesse compreender a forma como Jesus se posicionava. Sem as perguntas feitas por Jesus, ela provavelmente jamais teria percebido a questão da fé que salva.
É claro que, muitas vezes, uma resposta direta é preferível, particularmente quando o questionador é sincero e pede uma explicação clara e objetiva a respeito da visão bíblica sobre determinado tema. Em algumas ocasiões Jesus usou a estratégia de ir direto ao ponto! Sua resposta imediata ao mestre da lei que queria saber qual era o mandamento mais importante é um bom exemplo disto (Mc 12:28-31).
Por estas razões esforcem-se e segurem suas respostas.
Perguntem antes de responder e iniciem um diálogo sincero.
Quando um colega de trabalho – num tom acusatório - lhe perguntar: “Como você pode acreditar num Deus que permite que milhares de pessoas morram de fome no mundo?” pergunte-lhe: “Como você explica esta horrível tragédia?”
Quando o seu vizinho lhe perguntar: “Por que você crê que Jesus é mais do que apenas um bom professor de moral e ética?” pergunte-lhe: “Por que você pensa que Jesus foi um bom professor? Você já leu alguns dos ensinamentos de Jesus? E de suas leituras, qual foi a mensagem principal que você percebeu a respeito dos pensamentos de Jesus?
A mensagem do evangelho é importante demais para continuar sendo pregada a ouvidos propositalmente surdos.
As respostas da Bíblia são realmente o que as pessoas precisam ouvir, mas devemos ajudá-las a encontrar as razões e motivações corretas, de forma que as tornemos dispostas e disponíveis para ouvi-las.
O apóstolo Pedro está totalmente certo quando nos pede: “...estejam sempre preparados para responder a qualquer pessoa que lhes pedir a razão da esperança que há em vocês...” (1 Pe. 3:15).
Mas isto também significa responder as perguntas com outras perguntas. Tal qual fez Jesus.
Tanto quanto respostas certas, que Deus lhes dê as perguntas certas.
Autor: Deni Belotti
Eu amo responder perguntas com perguntas. Cresci numa família de italianos, onde eram comuns diálogos como estes:
Eu: Oi, vó. Como está o tempo por aí?Minha avó: E como você acha que poderia estar, bem no meio do verão?
Eu: E aí tio, como está você? Tio Henry: Por que você pergunta?
Eu: Tia, quanto tempo! E o Beto, como vai? Tia Nine: Comparado com o quê?
Atenção: “questionadores” não tentam, necessariamente, obter respostas certas.
Na verdade eles querem apenas ver você se contorcer tentando responder... Gosto de pensar que este ambiente incômodo na minha formação, acabou me ajudando, muitos anos depois, a entender a benção que é você saber responder perguntas com perguntas.
Hoje creio que isto me ajuda demais na minha tentativa diária de seguir o exemplo de Jesus.
Você já se deu conta quantas vezes Ele respondeu a uma pergunta fazendo outra?
Quando o homem rico perguntou a Jesus “Bom Mestre, o que farei para herdar a vida eterna?” Jesus respondeu: "Por que você me chama de bom?" (Mc 10:17-18).
Quando os líderes religiosos lhe perguntaram se era certo pagar impostos a César, Ele perguntou de quem era a face na moeda (Mt 22:17-20).
Quando os fariseus procuravam uma razão para acusá-lo e lhe perguntaram "É permitido curar no sábado?" a resposta de Jesus foi uma pergunta: "Qual de vocês, se tiver uma ovelha e ela cair num buraco no sábado, não irá pegá-la e tirá-la de lá?" (Mt 12:9-12).
Bom, deixe-me ser sincero: a principal razão de eu responder perguntas com perguntas é que estou cansado... Depois de anos respondendo perguntas de céticos, descrentes, familiares e amigos “cabeça-dura” eu simplesmente cansei, pois percebi que não era uma resposta que eles realmente estavam buscando.
Em algumas ocasiões (muitas, na verdade...) respondi com o que eu acreditava ser absolutamente bíblico e compreensível para ouvidos “não-treinados” - tentei, na maioria das vezes, falar em português – sem “crentear” - apenas para ver se o meu questionador ao menos movia os ombros. Mas minha triste percepção era de que apenas acabava de dar a ele mais uma razão para achar que todos nós cristãos somos uns paspalhos! Ao invés de minha resposta trazê-lo mais para perto de Jesus e de Sua salvação, ela simplesmente o empurrava pra longe. Em vez de ajudar sua mente e coração a enxergar as coisas por uma perspectiva diferente, minhas respostas apenas forneciam munição para futuros ataques contra o evangelho.
Desta forma, comecei a responder perguntas com perguntas. E meus resultados foram sensivelmente melhores.
Regra reversa
Meu ministério tem sido desenvolvido dentro do mundo corporativo. Para cada minuto que passo na eclesia são quase quinze minutos na diáspora. Vivo em sua totalidade o verso de Mt 10:16 “...os estou enviando como ovelhas entre lobos. Portanto, sejais astutos como as serpentes e sem malícia como as pombas”. E, dentro deste mundo corporativo, tenho tido muitas oportunidades de praticar no dia-a-dia aquilo que prego nos púlpitos.
Ano passado, entre meus clientes, estava um grupo empresarial muito grande, com faturamento anual na casa dos US$3 bilhões. Este grupo é dirigido por um time de poderosos e céticos executivos, cuja formação acadêmica de alto grau inclui MBA’s nas melhores universidades dos Estados Unidos e Europa.
Ao perceberem em mim uma certa “atitude de pomba” – no sentido da falta da malícia quase obrigatória naquele universo - este time resolveu me por na parede: uniram-se e passaram a questionar-me diariamente sobre os mais variados temas, relacionando assuntos cotidianos dos negócios às questões de ética e fé. Até que, finalmente, a inevitável pergunta apareceu. Um deles disse: “Bom, nós temos conversado muito sobre suas convicções e concluímos que você, lá no fundo, acredita mesmo que aqueles que não concordam com suas idéias a respeito de Deus e da Bíblia – como, por exemplo, todos os que seguem diferentes religiões, que crêem em distintas formas de manifestação de Deus ou que baseiam sua fé em outros livros que não a Bíblia – estão a caminho do inferno, não é mesmo?"
"Você acredita em inferno?" respondi, quase instintivamente...
Meus questionadores provavelmente jamais consideraram seriamente a possibilidade de céu e inferno. Minha resposta os deixou confusos, talvez porque eles estavam sendo agora desafiados, quando suas intenções eram apenas desafiar-me...
Finalmente, após um longo silêncio, ele respondeu: “Não, eu não creio em inferno. Acho isto simplesmente ridículo. "
Então escolhi utilizar a sua própria escolha de palavras e devolvi: “Então, já que você não acredita em inferno, por que está me fazendo esta pergunta ridícula?”
Eu não estava tentando ser o “senhor espertinho”. Estava apenas tentando ajudá-los a encarar honestamente as razões e motivações por detrás daquela pergunta. A expressão do grupo indicou que eu marcara um ponto importante. Foi então que outra pergunta quebrou o silêncio.
Outro membro daquele grupo disse em alto e bom som: “Bem, eu acredito em inferno. Você crê que todos os que não adotam a fé cristã irão para lá?"
E novamente eu perguntei: "Que tipo de pessoa, na sua opinião, irá para o inferno?
Hitler, por exemplo, você crê que ele está no inferno?" (falar de Hitler, apesar de desagradável, é sempre de grande auxílio, principalmente com gente que pensa que sabe demais. Este questionador específico, além de Presidente da empresa, é judeu!)
"Mas é claro que Hitler está no inferno !!" disse ele num tom áspero.
"E como você pensa que Deus decide quem vai para o céu e quem vai para o inferno? Será que Ele faz um gráfico de possibilidades?" respondi perguntando.
A partir deste momento, a conversa tornou-se amigável e civilizada. E um longo processo de diálogos sérios e enriquecedores sobre o amor de Deus, os pecados da humanidade e o grande trabalho realizado por Jesus a nosso favor começou entre eu e aquele time de executivos.
Responder com perguntas mostrou-se um método muito eficaz, apesar de indireto, para compartilhar o evangelho com um certo tipo de pessoas.
Um outra vez onde o questionamento foi mais eficaz que as respostas biblicamente inquestionáveis – obviamente inquestionáveis a partir do ponto de vista daqueles que conhecem a Jesus - foi numa feira da Associação Paulista de Supermercados. O diretor de uma grande empresa para qual eu estava prestando serviços comentou - em tom de sátira e de forma que eu ouvisse - com outro executivo do maior grupo supermercadista do país sobre o fato do meu evidente constrangimento com os trajes e a postura de algumas promotoras que faziam uma apresentação no stand onde estávamos.
Ele disse: “este aí é crente. Ele não gosta de mulher. Sua religião não permite que ele tenha mais de uma”. E então, a queima-roupa, me perguntou na frente de muitas pessoas: “Você não enjoa de só olhar para a mesma mulher há tantos anos? Se Deus as fez assim, tão lindas, que mal há em admirá-las e chegar perto delas?”
Então lhe respondi perguntando: “Suponhamos que você morasse no alto de uma montanha e, impedido de dirigir, tivesse que contratar um motorista para levar seus filhos à escola. Na estrada entre sua casa e a escola há um trecho desmoronado e, portanto, muito estreito, que obriga o carro a passar bem na beirada de um grande e profundo precipício. Ao entrevistar o primeiro motorista você pergunta: a que distância você é capaz de passar da beira do precipício?
E ele responde: Eu sou capaz de passar a 5 cm sem problemas, deixa comigo! Ao entrevistar o segundo, você repete a pergunta e ele responde que passaria a 10 cm.. Porém, ao entrevistar o terceiro você ouve como resposta EU SEMPRE PASSAREI O MAIS LONGE POSSÍVEL DA BEIRA DO PRECIPÍCIO.”
Baseado nestas suposições, perguntei: “Qual dos três você contrataria?” E ele me respondeu sem pensar: “O terceiro”.
Um longo silêncio pairou no ar.
Então sentei-me à mesa e disse: “Sabe, não é que eu não goste de mulher, eu apenas passo o mais longe possível da beira do precipício... E você?”
E naquela noite nós rimos muito no caminho entre a feira e o hotel e uma sólida amizade teve início...
Boas Perguntas
Responder a uma pergunta com outra pergunta tem vantagens significativas em relação a usar respostas diretas. Isto te ajuda a trazer à tona as razões e motivações reais por trás da pergunta.
Isto também tira a pressão dos seus ombros e a devolve aos ombros daquele que está questionando você. Isto é importante porque, como eu já disse: questionadores não tentam, necessariamente, obter respostas certas. Na verdade eles querem apenas ver você se contorcer tentando responder.
Por exemplo, os chefes dos sacerdotes, os mestres da Lei e os líderes religiosos perguntaram a Jesus: "Com que autoridade estás fazendo estas coisas? Quem te deu esta autoridade?"
Sua resposta foi: "digam-me: o batismo de João era do céu ou dos homens?”
Após uma pequena discussão entre eles, responderam: “Não sabemos de onde era”.
Jesus, então, mostrou a eles que as perguntas feitas tinham motivações equivocadas e, portanto, não mereciam uma resposta, dizendo: “Tampouco lhes direi com que autoridade estou fazendo estas coisas” (Lc 20:1-8).
Na verdade, a pergunta dos mestres era simplesmente um ataque disfarçado de pergunta.
Responder este tipo de perguntas com outras perguntas não apenas devolve o “fogo amigo” de volta a sua origem como também o faz de forma a reduzir a possibilidade de uma tréplica hostil.
As pessoas em geral não gostam de variações bruscas na temperatura das conversas, principalmente quando o calor está sobre elas, e rapidamente ajustam o termostato... Responder perguntas com outras perguntas também serve de pavimentação ao caminho para a evolução no processo de diálogo, em vez de uma resposta certa e direta que provavelmente não seria recebida por ouvidos com motivações duvidosas.
A conversa de Jesus com a mulher samaritana está dentro deste padrão (Jo 4:1-26). As noções daquela mulher sobre justiça, pecado e adoração a Deus precisavam ser mudadas antes que ela pudesse compreender a forma como Jesus se posicionava. Sem as perguntas feitas por Jesus, ela provavelmente jamais teria percebido a questão da fé que salva.
É claro que, muitas vezes, uma resposta direta é preferível, particularmente quando o questionador é sincero e pede uma explicação clara e objetiva a respeito da visão bíblica sobre determinado tema. Em algumas ocasiões Jesus usou a estratégia de ir direto ao ponto! Sua resposta imediata ao mestre da lei que queria saber qual era o mandamento mais importante é um bom exemplo disto (Mc 12:28-31).
Por estas razões esforcem-se e segurem suas respostas.
Perguntem antes de responder e iniciem um diálogo sincero.
Quando um colega de trabalho – num tom acusatório - lhe perguntar: “Como você pode acreditar num Deus que permite que milhares de pessoas morram de fome no mundo?” pergunte-lhe: “Como você explica esta horrível tragédia?”
Quando o seu vizinho lhe perguntar: “Por que você crê que Jesus é mais do que apenas um bom professor de moral e ética?” pergunte-lhe: “Por que você pensa que Jesus foi um bom professor? Você já leu alguns dos ensinamentos de Jesus? E de suas leituras, qual foi a mensagem principal que você percebeu a respeito dos pensamentos de Jesus?
A mensagem do evangelho é importante demais para continuar sendo pregada a ouvidos propositalmente surdos.
As respostas da Bíblia são realmente o que as pessoas precisam ouvir, mas devemos ajudá-las a encontrar as razões e motivações corretas, de forma que as tornemos dispostas e disponíveis para ouvi-las.
O apóstolo Pedro está totalmente certo quando nos pede: “...estejam sempre preparados para responder a qualquer pessoa que lhes pedir a razão da esperança que há em vocês...” (1 Pe. 3:15).
Mas isto também significa responder as perguntas com outras perguntas. Tal qual fez Jesus.
Tanto quanto respostas certas, que Deus lhes dê as perguntas certas.
Autor: Deni Belotti
Jesus era...peripatético
por Max Gehringer
Numa das empresas em que trabalhei, eu fazia parte de um grupo de treinadores voluntários. Éramos coordenados pelo chefe de treinamento, o professor Lima, e tínhamos até um lema: "Para poder ensinar, antes é preciso aprender" (copiado, se bem me recordo, de uma literatura do Senai). Um dia, nos reunimos para discutir a melhor forma de ministrar um curso para cerca de 200 funcionários. Estava claro que o método convencional -- botar todo mundo numa sala -- não iria funcionar, já que o professor insistia na necessidade da interação, impraticável com um público daquele tamanho.Como sempre acontece nessas reuniões, a imaginação voou longe do objetivo, até que, lá pelas tantas, uma colega propôs usarmos um trecho do Sermão da Montanha como tema do evento. E o professor, que até ali estava meio quieto, respondeu de primeira.
Aliás, pensou alto:
-Jesus era peripatético...
Seguiu-se uma constrangida troca de olhares, mas, antes que o hiato pudesse ser quebrado por alguém com coragem para retrucar a afronta, dona Dirce, a secretária, interrompeu a reunião para dizer que o gerente de RH precisava falar urgentemente com o professor. E lá se foi ele, deixando a sala à vontade para conspirar.
-Não sei vocês, mas eu achei esse comentário de extremo mau gosto – disse a Laura.
-Eu nem diria de mau gosto, Laura. Eu diria ofensivo mesmo -- emendou o Jorge, para acrescentar que estava chocado, no que foi amparado por um silêncio geral.
-Talvez o professor não queira misturar religião com treinamento, ponderou o Sales, que era o mais ponderado de todos. -- Mas eu até vejo uma razão para isso,
- Que é isso, Sales? Que razão?
- Bom, para mim, é óbvio que ele é ateu.
- Não diga!
- Digo. Quer dizer, é um direito dele. Mas daí a desrespeitar a religiosidade alheia...
Cheios de fúria, malhamos o professor durante uns dez minutos e, quando já o estávamos sentenciando à fogueira eterna, ele retornou. Mas nem percebeu a hostilidade. Já entrou falando:
- Então, como ia dizendo, podíamos montar várias salas separadas e colocar umas 20 pessoas em cada uma. É verdade que cada treinador teria de repetir a mesma apresentação várias vezes, mas... Por que vocês estão me olhando desse jeito?
- Bom, falando em nome do grupo, professor, essa coisa aí de peripatético, veja bem...
- Certo! Foi daí que me veio a idéia. Jesus se locomovia para fazer pregações, como os filósofos também faziam, ao orientar seus discípulos. Mas Jesus foi o Mestre dos Mestres, portanto a sugestão de usar o Sermão da Montanha foi muito feliz. Teríamos uma bela mensagem moral e o deslocamento físico... Mas que cara é essa?...
Peripatético quer dizer "o que ensina caminhando". E nós ali, encolhidos de vergonha. Bastaria um de nós ter tido a humildade de confessar que desconhecia a palavra que o resto concordaria e tudo se resolveria com uma simples ida ao dicionário.
Isto é, para poder ensinar, antes era preciso aprender. Finalmente, aprendemos. Duas coisas:
A primeira é: o fato de todos estarem de acordo não transforma o falso em verdadeiro.
E a segunda é que a sabedoria tende a provocar discórdia, mas a ignorância é quase sempre unânime.
Numa das empresas em que trabalhei, eu fazia parte de um grupo de treinadores voluntários. Éramos coordenados pelo chefe de treinamento, o professor Lima, e tínhamos até um lema: "Para poder ensinar, antes é preciso aprender" (copiado, se bem me recordo, de uma literatura do Senai). Um dia, nos reunimos para discutir a melhor forma de ministrar um curso para cerca de 200 funcionários. Estava claro que o método convencional -- botar todo mundo numa sala -- não iria funcionar, já que o professor insistia na necessidade da interação, impraticável com um público daquele tamanho.Como sempre acontece nessas reuniões, a imaginação voou longe do objetivo, até que, lá pelas tantas, uma colega propôs usarmos um trecho do Sermão da Montanha como tema do evento. E o professor, que até ali estava meio quieto, respondeu de primeira.
Aliás, pensou alto:
-Jesus era peripatético...
Seguiu-se uma constrangida troca de olhares, mas, antes que o hiato pudesse ser quebrado por alguém com coragem para retrucar a afronta, dona Dirce, a secretária, interrompeu a reunião para dizer que o gerente de RH precisava falar urgentemente com o professor. E lá se foi ele, deixando a sala à vontade para conspirar.
-Não sei vocês, mas eu achei esse comentário de extremo mau gosto – disse a Laura.
-Eu nem diria de mau gosto, Laura. Eu diria ofensivo mesmo -- emendou o Jorge, para acrescentar que estava chocado, no que foi amparado por um silêncio geral.
-Talvez o professor não queira misturar religião com treinamento, ponderou o Sales, que era o mais ponderado de todos. -- Mas eu até vejo uma razão para isso,
- Que é isso, Sales? Que razão?
- Bom, para mim, é óbvio que ele é ateu.
- Não diga!
- Digo. Quer dizer, é um direito dele. Mas daí a desrespeitar a religiosidade alheia...
Cheios de fúria, malhamos o professor durante uns dez minutos e, quando já o estávamos sentenciando à fogueira eterna, ele retornou. Mas nem percebeu a hostilidade. Já entrou falando:
- Então, como ia dizendo, podíamos montar várias salas separadas e colocar umas 20 pessoas em cada uma. É verdade que cada treinador teria de repetir a mesma apresentação várias vezes, mas... Por que vocês estão me olhando desse jeito?
- Bom, falando em nome do grupo, professor, essa coisa aí de peripatético, veja bem...
- Certo! Foi daí que me veio a idéia. Jesus se locomovia para fazer pregações, como os filósofos também faziam, ao orientar seus discípulos. Mas Jesus foi o Mestre dos Mestres, portanto a sugestão de usar o Sermão da Montanha foi muito feliz. Teríamos uma bela mensagem moral e o deslocamento físico... Mas que cara é essa?...
Peripatético quer dizer "o que ensina caminhando". E nós ali, encolhidos de vergonha. Bastaria um de nós ter tido a humildade de confessar que desconhecia a palavra que o resto concordaria e tudo se resolveria com uma simples ida ao dicionário.
Isto é, para poder ensinar, antes era preciso aprender. Finalmente, aprendemos. Duas coisas:
A primeira é: o fato de todos estarem de acordo não transforma o falso em verdadeiro.
E a segunda é que a sabedoria tende a provocar discórdia, mas a ignorância é quase sempre unânime.
10 regras para uma boa apresentação
A opinião é unânime. Os vídeos dos TED Talks são uma delícia de ver. Qual é o segredo dessas palestras? Acho que o primeiro (e principal) segredo é o mesmo dos eventos HSM: só tem gente bamba falando.
Mas, mesmo que você não seja (ainda) tão bamba quanto esse pessoal, pode fazer uma apresentação em sua empresa, ou para clientes, ao estilo TED Talk – se quiser. Basta se lembrar das poéticas palavras do Seth Godin (amor no palco; respeito na plateia) e seguir as 10 regras formatadoras (DOs & DON’Ts).
1. Não despeje o conteúdo simplesmente.
2. Sonhe um sonho grande ou mostre algo realmente novo – ou ainda algo que você nunca compartilhou antes.
3. Revele sua curiosidade e sua paixão.
4. Conte uma história.
5. Comente à vontade sobre o que outros falam, trazendo à tona concordâncias e controvérsias.
6. Não se apegue muito ao ego. Mostre vulnerabilidade, exiba (use) seus fracassos tanto quanto seu sucesso.
7. Não venda nada no palco: nem sua empresa, nem produtos, nem livros. Nem peça dinheiro.
8. Lembre-se o tempo todo de que rir (e provocar risos) é bom.
9. Não leia sua apresentação. Jamais.
10. Não roube o tempo dos que o estão seguindo.
Também há exemplos de apresentações igualmente impactantes apesar de os recursos variarem:
• Sem slides e sem script (no teleprompter): Ken Robinson/Do schools kill creativity?
• Com slides incrivelmente visuais: Seth Godin/Why tribes, not money or factories, will change the world.
• Com slides simples (mas de alto impacto): Al Gore/15 ways to avert a climate crisis.
• Com script (no teleprompter) e sem slides: Isabel Allende/ Tales of passion.
• Com slides supérfluos, em bullets: Tony Robbins/Why we do what we do.
• Com script (no teleprompter) e com slides: Jill Bolte Taylor/My stroke of insight.
• Com slides que são mera desculpa para contar histórias: Hans Holing/Debunking third-world myths with the best stats you’ve ever seen.
• Com excesso de slides: Larry Lessig/How creativity is being strangled by the law.
• Com música ao vivo (também foi assim com Ben Zahnder na ExpoManagement, diga-se de passagem): Ben Zahnder/Classical music with shining eyes.
Mas, mesmo que você não seja (ainda) tão bamba quanto esse pessoal, pode fazer uma apresentação em sua empresa, ou para clientes, ao estilo TED Talk – se quiser. Basta se lembrar das poéticas palavras do Seth Godin (amor no palco; respeito na plateia) e seguir as 10 regras formatadoras (DOs & DON’Ts).
1. Não despeje o conteúdo simplesmente.
2. Sonhe um sonho grande ou mostre algo realmente novo – ou ainda algo que você nunca compartilhou antes.
3. Revele sua curiosidade e sua paixão.
4. Conte uma história.
5. Comente à vontade sobre o que outros falam, trazendo à tona concordâncias e controvérsias.
6. Não se apegue muito ao ego. Mostre vulnerabilidade, exiba (use) seus fracassos tanto quanto seu sucesso.
7. Não venda nada no palco: nem sua empresa, nem produtos, nem livros. Nem peça dinheiro.
8. Lembre-se o tempo todo de que rir (e provocar risos) é bom.
9. Não leia sua apresentação. Jamais.
10. Não roube o tempo dos que o estão seguindo.
Também há exemplos de apresentações igualmente impactantes apesar de os recursos variarem:
• Sem slides e sem script (no teleprompter): Ken Robinson/Do schools kill creativity?
• Com slides incrivelmente visuais: Seth Godin/Why tribes, not money or factories, will change the world.
• Com slides simples (mas de alto impacto): Al Gore/15 ways to avert a climate crisis.
• Com script (no teleprompter) e sem slides: Isabel Allende/ Tales of passion.
• Com slides supérfluos, em bullets: Tony Robbins/Why we do what we do.
• Com script (no teleprompter) e com slides: Jill Bolte Taylor/My stroke of insight.
• Com slides que são mera desculpa para contar histórias: Hans Holing/Debunking third-world myths with the best stats you’ve ever seen.
• Com excesso de slides: Larry Lessig/How creativity is being strangled by the law.
• Com música ao vivo (também foi assim com Ben Zahnder na ExpoManagement, diga-se de passagem): Ben Zahnder/Classical music with shining eyes.
Desenvolvimento Ágil: o que seu chefe deve saber?
De acordo com um estudo da Evans Data (registro é necessário), mais da metade dos desenvolvedores americanos estão utilizando algum tipo de metodologia de desenvolvimento ágil. Parece que alguns chefes desta turma toda nem sequer conhecem os benefícios da abordagem ágil para o desenvolvimento de sistemas.
No Brasil, sempre pobre em estatísticas, não encontrei uma pesquisa que indicasse qual o porcentual dos desenvolvedores brasileiros que fazem uso de alguma metodologia ágil. Imagino que tenhamos um cenário semelhante ao dos E.U.A. Se você pesquisar no Google Scholar, verá que nossas universidadem produzem muita pesquisa sobre estas metodologias.
Neste artigo do CIO.com, o autor lista 7 pontos importantes que todo gerente de software (e desenvolvedor) deveria saber sobre métodos ágeis.
1. Permitem o Desenvolvimento de Software de Melhor Qualidade
Foco nas funcionalidade, no que o software irá fazer, revisões com pares (peer reviews), processos mais leves liberando o desenvolvedor da burocracia pesada das metodologias tradicionais… …tudo isto produz softwares de melhor qualidade.
2. Promove uma Mudança na “mentalidade” do time de desenvolvimento
Não é apenas um processo, metodologias ágeis promovem uma “nova atitude” na forma como o software é desenhado e implementado. Segundo o consultor Mike Sutton (Wizewerx.com), ocorre uma mudança da forma de pensar. A adoção é um processo, por vezes, doloroso pois “…força as organizações as organizações e indivíduos a confrontar o desperdício, ineficiência e falta de informação”. Ainda segundo ele, os desenvolvedores nerds vão precisar conversar uns com os outros e com o resto do mundo. Pasmem!
3. Mudanças ágeis além do tradicional “fluxo de desenvolvimento”
A adoção de metodologia ágil produzi um impacto na cultura da organização. intensa colaboração, feedback constantes, formas não tradicionais de acompanhamento de projeto, reuniões curtas e objetivas (meu sonho!)… …tudo isto é confrontado com um processo já estabelecido (o status quo).
Se problemas surgirem, e eles irão surgir, não culpem a nova metodologia. Eles já estavam aí, a nova abordagem apenas mostrou os problemas de forma mais explícita. Vejam o que afirma um outro consultor (Steven Gordon):
…collaboration brings to the surface a lot of issues, problems and obstructions in the organization. Do not kill the messenger, Gordon urges; agile is not creating these issues, only making them more apparent. CIOs have to prioritize and address the problems. “If the organization appears to be ignoring these issues after they are surfaced, people will come to believe that the agile principles make no difference and will go back to just minding their own business and doing their jobs in isolation…
4. Ágil não Significa “Caos é Bom”
Existe uma idéia pré-concebida de que tais métodos trarão uma “bagunça” para o processo. Agilidade não significa desorganização.
Por outro lado, nem todo projeto pode utilizar uma metodologia deste tipo. Esta abordagem se encaixa muito bem para aqueles desenvolvimentos (que precisam ser feitos) rápidos e cujos requisitos não estão claros(!).
(eu sei, todos nossos projetos também são assim…)
5. Benefícios de uma Metodologia Ágil Compensam a Espera
Como toda mudança os benefícios não serão vistos imediatamente. Segundo o artigo, quem adotou não quer voltar atrás.
Um grande benefício é que, devido a iterações mais curtas, a equipe de TI pode verificar os riscos mais cedo e as decisões de “go/no-go” serão feitas nas fases iniciais.
6. Não existe a “Bala de Prata”
Não se engane, a metodologia ágil não será a “salvação da lavoura”. Programadores ruins continuaram ruins. Veja outro trecho:
Give competent and invested people agile, and you’ll have happier
people doing better work more rapidly. Give incompetent, unempowered
people agile (or even worse, just the word agile), and you’ll still fail
7. Sucesso Depende das Pessoas
Ainda bem. Desenvolvedores gostam de ver suas criações em ação. Nada é mais frustante do que ver todo seu esforço criativo, para construir uma solução de software, ser arquivado ou abortado. Já participei de vários projetos de software que não tiveram continuidade. É altamente desmotivador.
Com um processo ágil o time que implementa pode ver o resultado mais rápido e isto motiva ainda mais, apesar de todos os problemas de requisitos incompletos e a eterna insatisfação dos usuários.
No Brasil, sempre pobre em estatísticas, não encontrei uma pesquisa que indicasse qual o porcentual dos desenvolvedores brasileiros que fazem uso de alguma metodologia ágil. Imagino que tenhamos um cenário semelhante ao dos E.U.A. Se você pesquisar no Google Scholar, verá que nossas universidadem produzem muita pesquisa sobre estas metodologias.
Neste artigo do CIO.com, o autor lista 7 pontos importantes que todo gerente de software (e desenvolvedor) deveria saber sobre métodos ágeis.
1. Permitem o Desenvolvimento de Software de Melhor Qualidade
Foco nas funcionalidade, no que o software irá fazer, revisões com pares (peer reviews), processos mais leves liberando o desenvolvedor da burocracia pesada das metodologias tradicionais… …tudo isto produz softwares de melhor qualidade.
2. Promove uma Mudança na “mentalidade” do time de desenvolvimento
Não é apenas um processo, metodologias ágeis promovem uma “nova atitude” na forma como o software é desenhado e implementado. Segundo o consultor Mike Sutton (Wizewerx.com), ocorre uma mudança da forma de pensar. A adoção é um processo, por vezes, doloroso pois “…força as organizações as organizações e indivíduos a confrontar o desperdício, ineficiência e falta de informação”. Ainda segundo ele, os desenvolvedores nerds vão precisar conversar uns com os outros e com o resto do mundo. Pasmem!
3. Mudanças ágeis além do tradicional “fluxo de desenvolvimento”
A adoção de metodologia ágil produzi um impacto na cultura da organização. intensa colaboração, feedback constantes, formas não tradicionais de acompanhamento de projeto, reuniões curtas e objetivas (meu sonho!)… …tudo isto é confrontado com um processo já estabelecido (o status quo).
Se problemas surgirem, e eles irão surgir, não culpem a nova metodologia. Eles já estavam aí, a nova abordagem apenas mostrou os problemas de forma mais explícita. Vejam o que afirma um outro consultor (Steven Gordon):
…collaboration brings to the surface a lot of issues, problems and obstructions in the organization. Do not kill the messenger, Gordon urges; agile is not creating these issues, only making them more apparent. CIOs have to prioritize and address the problems. “If the organization appears to be ignoring these issues after they are surfaced, people will come to believe that the agile principles make no difference and will go back to just minding their own business and doing their jobs in isolation…
4. Ágil não Significa “Caos é Bom”
Existe uma idéia pré-concebida de que tais métodos trarão uma “bagunça” para o processo. Agilidade não significa desorganização.
Por outro lado, nem todo projeto pode utilizar uma metodologia deste tipo. Esta abordagem se encaixa muito bem para aqueles desenvolvimentos (que precisam ser feitos) rápidos e cujos requisitos não estão claros(!).
(eu sei, todos nossos projetos também são assim…)
5. Benefícios de uma Metodologia Ágil Compensam a Espera
Como toda mudança os benefícios não serão vistos imediatamente. Segundo o artigo, quem adotou não quer voltar atrás.
Um grande benefício é que, devido a iterações mais curtas, a equipe de TI pode verificar os riscos mais cedo e as decisões de “go/no-go” serão feitas nas fases iniciais.
6. Não existe a “Bala de Prata”
Não se engane, a metodologia ágil não será a “salvação da lavoura”. Programadores ruins continuaram ruins. Veja outro trecho:
Give competent and invested people agile, and you’ll have happier
people doing better work more rapidly. Give incompetent, unempowered
people agile (or even worse, just the word agile), and you’ll still fail
7. Sucesso Depende das Pessoas
Ainda bem. Desenvolvedores gostam de ver suas criações em ação. Nada é mais frustante do que ver todo seu esforço criativo, para construir uma solução de software, ser arquivado ou abortado. Já participei de vários projetos de software que não tiveram continuidade. É altamente desmotivador.
Com um processo ágil o time que implementa pode ver o resultado mais rápido e isto motiva ainda mais, apesar de todos os problemas de requisitos incompletos e a eterna insatisfação dos usuários.
Entendendo o PRINCE2™
Resumo – Este artigo apresenta alguns conceitos chave do PRINCE2™, um método de gestão de projetos desenvolvido pelo governo do Reino Unido, e que tem sido utilizado como padrão não só por aquele governo, mas também pelo setor privado de diversos países, em todos os continentes.
Apresentando uma visão geral do modelo de processos no qual o método é baseado, além de seus componentes e técnicas, o texto mostra também os benefícios da sua adoção, sugerindo critérios para o sucesso de sua implementação e citando um breve estudo com o PMBOK, que revela, claramente, existência de uma sinergia entre as duas abordagens.
O que é PRINCE2™?
O PRINCE2™, ou Project In a Controlled Environment, é um método não proprietário para gerenciamento de projetos. É adaptável a qualquer tipo ou tamanho de projeto e cobre seu gerenciamento, controle e organização. Um projeto PRINCE2™ possui as seguintes características:
· Controle e organização do início ao fim;
· Regular revisão de progressos baseada nos planos e no business case;
· Pontos de decisão flexíveis;
· Gerenciamento efetivo de qualquer desvio do plano;
· Envolvimento da gerência e das partes interessadas em momentos-chave durante toda a execução do projeto;
· Um bom canal de comunicação entre o time do projeto e o restante da organização.
O PRINCE2™ é de fato um padrão
O PRINCE2™ foi lançado como um método para gerenciamento de projetos pelo governo britânico em 1996, tendo sido criado em 1989 a partir do PROMPTII, o qual, por sua vez, surgiu em 1975 e foi adotado em 1979 como padrão para gerenciamento dos projetos de sistemas de informação do governo.
Hoje, o PRINCE2™ vem sendo adotado como padrão para todos os projetos governamentais no Reino Unido e amplamente utilizado pela iniciativa privada não só naquele país, mas também em outros lugares da Europa, África, Oceania e Estados Unidos. Considerado o método de gerenciamento de projetos mais utilizado no mundo, conta com mais de 250 mil profissionais certificados, sendo ainda que cerca de 1500 pessoas prestam, mensalmente, os exames de certificação Foudation e Practitioner. Existem mais de 120 centros de treinamento credenciados PRINCE2™ pelo mundo, os quais provêem treinamento, em 17 idiomas, de 59 ferramentas de gerenciamento de projetos desenvolvidas com base no Método. No Brasil, a metodologia PRINCE2™ já vem sendo utilizada em algumas organizações, e é crescente a procura por informações a respeito do assunto.
Benefícios
Com a utilização do PRINCE2™, a organização tem como benefícios um gerenciamento controlado das mudanças em termos de investimento e retorno; um ativo envolvimento dos usuários e das partes interessadas durante todo o ciclo de vida do projeto - o que garante que os produtos atinjam os requisitos de negócio, funcionais, de ambiente, de serviço e de gerenciamento. A metodologia possui uma abordagem que distingue o gerenciamento do projeto do desenvolvimento dos produtos, de tal forma que pode ser aplicada na elaboração de projetos de qualquer segmento de mercado, desde a construção de um navio até o desenvolvimento de um sistema de informação. Os gerentes de projeto que utilizam o PRINCE2™ são capazes de utilizar uma estrutura para delegação, autoridade e comunicação e ter definidos todos os pontos durante o projeto. Desta forma, todos os riscos serão revistos e analisados e haverá uma sistemática natural para o gerenciamento de riscos.
Um Overview do PRINCE2™
O PRINCE2™ é baseado em oito processos e 45 sub-processos, os quais definem as atividades que serão executadas ao longo do ciclo de vida do projeto. Juntamente com esses, são descritos oito componentes que são como áreas de conhecimento que devem ser aplicadas de acordo com a necessidade, dentro das atividades de cada processo. A figura 1 mostra uma visão da estrutura do PRINCE2™. Apesar de não descrever quais ferramentas e técnicas devem ser aplicadas, o manual do PRINCE2™ fornece três técnicas que auxiliam no planejamento e controle dos projetos.
Figura 1 – Processos e componentes PRINCE2™ - Baseado no Manual Prince2 – Managing a Successful Projects with PRINCE2™.
Processos
Starting up a Project – Primeiro processo da metodologia, é iniciado a partir da emissão de um documento denominado Project Mandate, que define, em alto nível, as razões para o projeto. O objetivo desse processo é responder à pergunta: “Existe um projeto viável e que traga valor?”.
Directing a project – Processo de responsabilidade do Project Board, constitui um grupo com responsabilidade de dar direcionamento ao projeto, formado por representantes do negócio, usuários e fornecedores. Aqui são tomadas as decisões sobre o andamento do projeto e sobre prováveis exceções ocorridas ao longo do ciclo de vida. Directing a project tem, como princípio, o gerenciamento por exceção, onde o Project Board monitora o projeto via relatórios e controles por intermédio de pontos de decisão pré-determinados.
Initiating a project – Tem como propósito elaborar os planos que formarão a baseline do projeto e que farão parte do Project Initiating Document (PID), que constitui o contrato entre o Project Manager e o Project Board.
Managing Stage Boundaries – PRINCE2™ recomenda que o projeto seja dividido em estágios. Este processo é executado ao término de cada estágio e tem como objetivos:
· Garantir ao Project Board que todos os produtos planejados para o estágio foram completados conforme o que foi definido.
· Prover as informações necessárias para avaliar se o projeto continua viável.
· Preparar e aprovar o planejamento para o próximo estágio.
· Listar qualquer lição aprendida no estágio que está terminando.
· Tratar qualquer exceção ou desvio do planejamento aprovado pelo Project Board.
Controlling a Stage – este processo descreve as atividades de controle e monitoramento dos estágios do projeto, constituindo o dia-a-dia do gerente do projeto. Aqui, são autorizados os pacotes de trabalho, avaliados os riscos e as solicitações de mudanças e efetuadas as ações corretivas necessárias.
Managing Product Delivery – O objetivo deste processo é garantir que os produtos planejados serão criados e entregues. PRINCE2™ separa o gerenciamento do projeto do desenvolvimento do produto. Este processo constitui a interface com os processos de desenvolvimento dos produtos do projeto existentes na organização como, por exemplo, o RUP (Rational Unified Process) para desenvolvimento de software.
Planning – Este processo desempenha um papel importante nos outros processos. Associado à técnica product-based planning, sua função é auxiliar no desenvolvimento dos planos necessários para o projeto.
Closing a Project – o propósito deste processo é realizar o fechamento controlado do projeto. O fechamento pode ser conduzido ao término do projeto, quando este já desenvolveu e entregou todos os produtos propostos ou se, por algum motivo, tornou-se inviável.
Componentes
Business Case – Justifica a existência do projeto. A filosofia-chave por trás do PRINCE2™ é a concepção de que o Business Case deve direcionar o projeto. Ao longo do ciclo de vida do projeto, o ele é revisado e validado para garantir que o projeto se mantenha relevante. Um sólido Business Case irá auxiliar no alinhamento do progresso do projeto aos objetivos do negócio, mantendo-o relevante para a organização. Se não existir um Business Case satisfatório, o projeto não deve ser iniciado. Ele é a ferramenta pela qual o Project Board irá monitorar sua viabilidade.
Organisation - Provê uma estrutura para o projeto com a definição de papéis e responsabilidades e o relacionamento entre os diversos papéis atuantes no projeto. A figura 10 mostra a estrutura de gerenciamento de projetos PRINCE2™.
Figura 10 – Project Management Structure Baseado no Managing a Successful Projects with PRINCE2™.
Plans - Disponibiliza um conjunto de planos que podem ser adaptados às características do projeto. O planejamento é vital para o sucesso de um projeto, e o plano deve conter informações detalhadas o suficiente para deixar claros os resultados que se quer alcançar.
Controls - Oferece uma série de controles que ajudam na previsão e nas decisões para a resolução de problemas. Nenhum projeto é conduzido 100% de acordo com o plano, sendo comuns desvios em custo, prazo, ou em algum outro indicador. Aqui é aplicado o conceito de tolerância, onde se definem os níveis de tolerância que o projeto pode aceitar. Isso significa que, se a cada verificação de status o projeto estiver dentro da faixa de tolerância, não será preciso nenhuma ação do Project Board, que será acionado somente se houver alguma previsão de que as referidas faixas serão excedidas. Isso é conhecido como gerenciamento por exceção, uma forte característica dos projetos PRINCE2™.
Management of Risk - Define os momentos-chave onde os riscos devem ser avaliados e revisados, além da abordagem a ser aplicada em sua manutenção.
Quality in a Project Environment - Apresenta uma abordagem para o controle de qualidade dos aspectos técnicos e de gerenciamento do projeto durante todo seu ciclo de vida.
Configuration Management - Define as funções essenciais e informações necessárias para a gerência de configuração do projeto, garantindo o correto versionamento dos produtos a serem entregues. Constitui uma proteção para os produtos do projeto.
Change Control – Técnica cujo objetivo é controlar as mudanças do projeto, verificando e validando seus impactos.
Técnicas
Product-based Planning – PRINCE2™ tem foco de planejamento nos produtos que o projeto deverá desenvolver e não nas atividades desempenhadas na sua produção. Isso altera a forma de planejar e controlar o projeto. O planejamento e definição do escopo são realizados a partir de uma estrutura denominada PBS (Product Breakdown Structure) muito similar à EAP (Estrutura Analítica de Projeto), na qual o produto final do projeto é quebrado em sub-produtos até o menor nível de sub-produtos identificáveis. A estrutura também ajuda na criação de pacotes de trabalho, que facilitam a distribuição e o controle do trabalho para as equipes de desenvolvimento. Esta técnica provê um framework que pode ser aplicado a qualquer tipo de projeto, disponibilizando uma seqüência lógica para o trabalho a ser realizado.
Change Control Technique - Define os passos para o efetivo tratamento das mudanças solicitadas ao longo do projeto. Visa exclusivamente o controle de mudanças nos produtos desenvolvidos pelo projeto (specialist products), e não dos produtos de gerenciamento (management products).
Quality Review Technique – Constitui um processo estruturado para a revisão de qualidade, que visa garantir que cada produto entregue atinja o seu propósito conforme a sua especificação de qualidade.
Implantando o PRINCE2™
A chave do sucesso da utilização do PRINCE2™ é a sua escalabilidade/adaptabilidade,. É recomendado que cada processo seja implementado a partir da seguinte questão: “Quão extensivamente este processo deve ser aplicado para este projeto?”. Dessa forma, para um projeto pequeno um processo pode ser menos formal e ser todo desenvolvido em uma reunião, enquanto que para projetos maiores, ou que envolvam maiores impactos para a organização, eles serão extensos e com mais formalidade. Uma boa estratégia é determinar um padrão mínimo (com a definição de uma política) de documentos obrigatórios e opcionais. Na implantação em um ambiente corporativo, devem ser considerados os padrões já existentes, como por exemplo, padrões de qualidade, ferramentas, etc.
O PRINCE2™ e o PMBOK
Existe um alto nível de compatibilidade entre o PRINCE2™ e o PMBOK. O segundo constitui uma ampla base de conhecimentos em gerenciamento de projetos, e é fato que toda empresa, desejando gerenciar seus projetos de forma a aumentar suas chances de sucesso, deverá levá-lo em consideração. O PRINCE2™ é totalmente aderente às boas práticas contidas no PMBOK, sendo em alguns aspectos a sua materialização.
Agregando valor ao projeto, o PRINCE2™:
· Provê um modelo de processos melhor direcionado ao gerenciamento de um projeto específico.
· Possui um processo de planejamento mais claro, que permite ao gerente de projetos planejar o esforço para fazer os planos necessários ao projeto.
· Possui uma estrutura organizacional com papéis e responsabilidades definidas para o time de projeto, especificando quem faz o que e quando.
· Estabelece a divisão do projeto em estágios, facilitando o gerenciamento e o planejamento do projeto.
· Estabelece checks points com processos detalhados para captura de informação sobre o progresso do projeto.
· Materializa o controle integrado de mudanças (sub-processo 4.6 do PMBOK), provendo uma detalhada abordagem de controle de mudanças e gestão de configuração ao longo do processo de gerenciamento do projeto.
· Determina processos claros para definição, verificação e controle do escopo do projeto,
· Provê monitoramento e controle de riscos, fatores intrínsecos aos processos de gerenciamento do projeto.
Conclusão
Gerenciar um projeto é um empreendimento, por sua natureza, cheio de incertezas e mudanças. Sem uma metodologia definida, todos os envolvidos terão idéias diferentes sobre como o trabalho deverá ser organizado ou como o projeto deverá ser completado. Sem um método, o projeto dificilmente será finalizado dentro das expectativas de custo, tempo e qualidade. E pode-se afirmar que isso é especialmente verdade para projetos grandes.
PRINCE2™ reúne um completo conjunto de conceitos e processos de gerenciamento de projetos capazes de endereçar, de forma efetiva, a atividade de gerenciar um projeto. Colocando em prática vários conceitos do PMBOK, e sendo totalmente escalável, o PRINCE2™ se adequa a qualquer tipo ou tamanho de projeto, em qualquer tipo de organização e é fator determinante para todos os projetos do governo no Reino Unido. É uma metodologia consistente, baseada em anos de experiência de vários gerentes e equipes de projetos, além de ser de fácil aprendizado e poder ser utilizada gratuitamente.
Referências:
1. OGC, Office Goverment Commerce; Managing Succesful Projects with PRINCE2™. Edição 2005, Publicado por TSO (The Stationery Office).
2. OGC, Office Goverment Commerce; Tailoring PRINCE2™. Edição 2004, Publicado por TSO (The Stationery Office).
3. OGC, Office Goverment Commerce; For Successful Project Management: Think PRINCE2™. Edição 2007, Publicado por TSO (The Stationery Office).
4. Bentley, Colin. PRINCE2™ A Practical Handbook.2º Edição, 1997.
5. OGC, Office Goverment Commerce; Web site: http://www.ogc.gov.uk/
6. PRINCE2™; Web site : http://www.prince2.org.uk/
7. PMI (Project Management Institute); PMBOK – Project Management Bod of Knowlodge, 3rd editon.
Assinar:
Postagens (Atom)