Stephen Kanitz *
Nenhum ditado popular explica tão bem os problemas do Brasil e do mundo como "Em terra de cego quem tem um olho é rei". Ele mostra por que existe tanta gente incompetente dirigindo nossas empresas e nossas instituições. Mostra também por que é tão fácil chegar ao topo da pirâmide social sem muita visão ou competência. Basta ter um mínimo de conhecimento para sair pontificando soluções.
Todo mundo palpita em economia e futebol como se fosse Ph.D. no assunto. Se o técnico Luiz Felipe Scolari tivesse ouvido os palpiteiros, jamais seríamos pentacampeões mundiais de futebol. Por isso temos tantos intelectuais para lá de arrogantes, que se acham predestinados a dirigir nossa vida com muita teoria e pouca informação.
Existe um corolário desse ditado que me preocupa por suas conseqüências. "Em terra de cego, quem tem um olho é rei, e quem tem dois olhos é muito malvisto." Indivíduos inteligentes e capazes são encarados como uma enorme ameaça e precisam ser rapidamente eliminados pelos que estão no poder.
Por essa razão, pessoas com mérito e competência dificilmente são promovidas no Brasil. Promovidos são os bajuladores e puxa-sacos. Quando aparece alguém com dois olhos, os reizinhos tratam de eliminá-lo, quanto antes melhor.
Já cansei de ver gente competente que, de um momento para o outro, deixou de ser ouvida pela diretoria. Já vi muito jornalista que, de repente, caiu em desgraça. Já vi muito jovem comentar algo brilhante na aula e ser duramente criticado pelo professor, sem saber o motivo. Todos cometeram o erro fatal de mostrar que tinham dois olhos. Por favor, não deixe que isso aconteça com você.
Se você é dos milhares de brasileiros que possuem dois olhos, tome cuidado. Em terra de cego, você corre perigo. Nunca mostre a seu chefe, professor ou colega de trabalho os olhos que tem. Lamento não poder dar nenhum bom conselho, eu sou dos que têm um olho só.
A maioria dos dois-olhos que conheço já desistiu de lutar e optou pelo anonimato. Quando eles têm uma idéia brilhante, colocam a solução na mesa de seus chefes e deixam que a idéia seja descaradamente roubada. Eles se fingem de mortos, pois sabem que, se agirem de modo diferente, poderão tornar-se vítimas. Mas há saídas melhores.
Se seu chefe tem um olho só, mude de emprego e procure companhias que valorizem o talento, que tenham critérios de avaliação claros e baseados em meritocracia. São poucas, mas elas existem e precisam ser prestigiadas.
Ou, então, procure um chefe que tenha dois olhos e grude nele. Ele é o único que irá entendê-lo. Ajude-o a formar uma grande equipe. Se ele mudar de empresa, mude com ele. Seja diferente, procure os melhores chefes para trabalhar, não as melhores companhias. Normalmente, as grandes empresas já são dominadas por reizinhos de um olho só.
Por isso, considere criar um negócio com outros como você. Vocês terão sucesso garantido, pois vão concorrer com milhares de executivos e empresários de um olho só. Nosso erro como nação é justamente não identificar aqueles que enxergam com dois olhos, para poder segui-los pelos caminhos que trilham. Eles deveriam ser valorizados, e não perseguidos, como o são. O Brasil precisa desesperadamente de gente que pense de forma clara e coerente, gente que observe com os próprios olhos aquilo que está a sua volta, em vez de ler em livros que nem foram escritos neste país.
Se você for um desses, tenha mais coragem e lute. Junte-se a eles para combater essa mediocridade mundial que está por aí. Vocês não se encontram sozinhos. Nosso povo tem dois olhos, sim, e é muito mais esperto do que se imagina. Ele está é sendo enganado há tempos, enganado por gente com um olho só.
Foi-se o tempo de uma elite pensante comandar a massa ignara. Hoje, a maioria do povo tem acesso à internet e a home pages com mais informação do que essa intelligentsia tinha quando fez seu doutorado. Se informação é poder, ela não é mais restrita a um pequeno grupo de bem formados. Nosso povo só precisa acreditar mais em si mesmo e perceber que cegos são os outros, aqueles com um olho só.
* Stephen Kanitz é administrador (www.kanitz.com.br)
Artigo Publicado na Revista Veja,
edição 1796, ano 36, nº 13, 2 de abril de 2003.
A relação entre os gerentes de projeto e o PMO
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
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?
Assinar:
Comentários (Atom)