Certificação Nível C
Nível C: Gerente de Projetos Certificado (Certified Project Manager)
Especificação: É capaz de gerenciar, com razoável independência, projetos não complexos, coordenar as tarefas técnicas de equipes de projeto e apoiar o gerente de um projeto complexo em todas as áreas de aplicação do gerenciamento de projetos
Fonte: http://www.abgp.org.br
Certificação Nível D
Nível D: Associado em Gerenciamento de Projetos Certificado (Cerfied Project Management Associate)
Especificação: Deve ter conhecimentos de Gerenciamento de projetos, os quais poderão ser aplicados em alguns campos da sua especialidade não é exigida experiência profissional
Fonte: http://www.abgp.org.br
International Project Management Association
Entidade International Project Management Association – IPMA
O Programa de Certificação em Gerenciamento de Projetos é realizado sob a responsabilidade da ABGP e encontra-se reconhecido pela entidade International Project Management Association – IPMA.
O IPMA é responsável por manter um sistema universal para validação dos programas nacionais de certificação e pela coordenação e harmonização das certificações de acordo com a sua estrutura geral e princípios.
Compete às Associações Nacionais (MA´s), como a ABGP, desenvolver e gerir os Programas de Certificação aprovados pelo IPMA para vigorarem nos respectivos países e estabelecerem, em ligação com o IPMA, os Conselhos Nacionais de Certificação.
A certificação não é apenas um teste, mas sim a compilação de múltiplas exigências:
– Conhecimento técnico
– Auto-avaliação
– Habilidades pessoais
– Entrevista
– Experiência comprovada como PM
Fonte: http://www.abgp.org.br
A Importância do Orçamento para as empresas
Orçar na linguagem náutica significa colocar a vela a favor do vento como meio de que a embarcação atinja o seu objetivo. É dessa maneira que o orçamento faz com as empresas as direcionam para os objetivos.
A necessidade de orçar é muito antiga porque o homem sempre precisou fazer algumas previsões para estocar comida durante o inverno e com isso desenvolveu as primeiras praticas orçamentária. A palavra orçamento deve-se aos antigos romanos que coletavam impostos e também foi utilizada para as bolsas de tesouraria e os funcionários que a usavam. Na França o termo era conhecido como bougue ou bogutte e vem do latim, entre 1400 e 1450 o termo bouguett tornou-se parte do vocabulário inglês. A historia do orçamento empresarial teve sua origem na administração pública e foi utilizado como instrumento de planejamento e controle das operações empresariais na Du Pont nos Estados Unidos em 1919 sendo que entre os anos de 1950 e 1960 ele ganha relevância com uso pelas grandes empresas.
Toda empresa quer ela seja grande, média ou pequena sempre existe um planejamento por mais simples que seja com uma missão, valores e visão, é claro que nas grandes empresas existem os Planejamentos Estratégicos com suas missões bem definidas, valores que norteiam os negócios e a visão de com a empresa deseja ser vista daqui por exemplo a 5 anos.Nas empresas pequenas o planejamento estratégico pode ser um simples pedaço de papel onde o proprietário escreve o que deseja e como deseja alcançar o objetivo.
O orçamento tem uma missão muito importante, pois é um plano que onde esta contida as quantidade de recursos (materiais, horas trabalhadas ou recursos financeiros) capazes de conduzir a empresa aos seus objetivos, conforme Padoveze (2004, p 128), o orçamento deve conter alguns propósitos gerais como: a) orçamento como sistema de autorização: o orçamento aprovado é um meio de autorização de recursos para todos os setores da empresa; b) um meio para projeções e planejamento, as peças orçamentárias serão utilizadas para os processos de projeções e planejamento permitindo estudos para períodos posteriores. c) um canal de comunicação e coordenação, é um instrumento para comunicar e coordenar os objetivos corporativos e setoriais; d)um instrumento de motivação, ele permite um grau de liberdade de atuação dentro das linhas aprovadas;e) um instrumento para avaliação e controle, avalia o desempenho dos gestores e controla os objetivos corporativos e setoriais. f) uma fonte para a tomada de decisão, por conter os dados previstos e esperados é uma ferramenta fundamental para a tomada de decisões sobre os eventos econômicos diários de responsabilidade dos gestores operacionais.
Esta importante ferramenta de gestão deve acompanhar a estratégia da empresa, o seu acompanhamento e controle devem ser constantes para que se possam atingir os objetivos planejados para o período assim com um barco a vela de aportar em seu porto de chegada.
Pedro Paulo Galindo Morales é Graduado em Gestão de Sistemas Produtivos, possui especialização em Controladoria e trabalha na área de Gestão Orçamentária de uma empresa multinacional de Distribuição de Energia Elétrica.
Blog: www.falandodegestao.wordpress.com
E-Mail: [email protected]
A importância da gestão de custos Interganizacionais para empresas
Uma empresa para se manter no mercado nos dias atuais tem que prestar atenção a um ponto fundamental, seus custos porque os clientes estão cada vez mais exigentes e as tecnologias para elaboração de produtos e serviços estão cada vez mais difusas para que a empresa ganhe vantagem competitiva e se mantenha é preciso desenvolver um sistema de gestão de custos que garanta esse diferencial.
Gestão de Custos Interganizacionais (GCI) é um processo cooperativo de gerenciamento de custos que inclui outras organizações dentro de uma cadeia de valor alem da própria empresa, sendo que a cadeia de valor de qualquer empresa é o conjunto de atividades que criam valor, desde as fontes de matérias-primas básicas, passando por fornecedores de componentes até o produto final entregue nas mãos do consumidor.
É, portanto, um enfoque externo à empresa vendo cada empresa no contexto da cadeia global de atividades geradoras de valor esses irá causar impactos a todos aqueles integrantes desta cadeia por isso é que se pode dizer que Gestão de Custos Interganizacionais (GCI) são ações coordenadas entre clientes e fornecedores para otimizar resultados.
Vantagem Competitiva é um diferencial, por causa disso é que se precisa desenvolver um instrumento de gestão que possibilite olhar para fora da empresa ainda mais que nos tempos atuais a competição é entre cadeias de valores, ninguém consegue mais vender pelo preço que quer é importante que a empresa gerencie seus custos.
Alguns fatores devem ser levados em consideração para se implantar a (GCI), esses são em números de cinco e recebem o nome de fatores condicionantes: produto, componentes, níveis de relacionamento, tipos de cadeia e mecanismos de governança. Cada um desses fatores condicionantes será comentado a seguir.
-
Produto: os produtos devem ser analisados quanto a sua margem quanto mais um produto tiver uma margem de lucro ou contribuição baixa mais teremos que gerenciá-lo porque se conseguirmos expandir os benefícios por toda a cadeia de valor irá ter a sua margem melhorada quanto a sua funcionalidade e atributos conseguiremos um resultado melhor, pois quanto mais valor agregado de um produto mais a necessidade de sua gestão.
-
Componentes: A GCI não se aplica, necessariamente, a todos os fornecedores de todos os componentes do produto; objetivo é identificar quais são os componentes recomendáveis à aplicação da GCI. Duas variáveis devem ser analisadas: nível de restrição tecnológica que determina se ela é estratégica e do componente e seu índice de valor que pode ser relacionado com seu custo beneficio.
-
Níveis de relacionamento: A fase seguinte é a análise dos relacionamentos de parceria e as classificações dos fornecedores são: comum (menor inter-relação), auxiliar (quando a empresa tem a certeza de que o parceiro tem capacidade de satisfazer às transações requeridas), principal (a parceria é formalizada por contratos de longo prazo) e familiar (trabalha como se fosse parte do quadro da empresa). Quanto mais intenso o nível de relacionamento, mais propícia é a aplicação da GCI;
-
Tipos de Cadeia: existem três tipos de classificação: tirania (só uma empresa domina), oligarquia (duas ou mais companhias dominam a cadeia) e democracia (onde não há uma organização que comande; as firmas devem formar alianças);
-
Mecanismos de governança: Trata-se de artefatos, aparelhos, instrumentos etc. que auxiliam a gestão de custos entre empresas com o objetivo de orientar, controlar, medir, informar, dar parâmetros, ser guia para as organizações, viabilizando a GCI.
A empresa deve compreender que a ineficiência pode estar no fornecedor, são custos importados, um bom exemplo disso é o laboratório que entrega medicamentos em hospital, ele entrega na mesma embalagem em que é comercializado em farmácias e tendo como conseqüência o fato que o hospital terá que manter funcionários para separar os remédios e assim repassar os custos para o consumidor e se ele não aceitar pagar esse custo o hospital perdera mercado,o interessante é fazer a gestão de custos na cadeia para baratear o custo.
Hoje a competição é também entre cadeias de valores ou suprimento, o celular pode competir com uma roupa ou até mesmo uma lanchonete. O importante é agir em conjunto para baratear o custo nã não se deve pressionar os fornecedores por menores preços deve-se buscar inspiração no sistema Toyota de produção que é uma gestão mais compartilhada. Não se deve agir como dois burrinhos amarrados onde cada um tem um capim do seu lado e eles não conseguem comer porque um puxa para cada lado.
Para uma gestão correta tudo deve ser acompanhado, áreas podem estar gerando dejetos que podem ser reaproveitados, cada atividade desenvolvida na empresa deve ser registrada pelos sistemas controle, desde o cafezinho, uso de telefone, equipamentos que clientes não usam tudo é importante para a competitividade o custo esta presente em tudo que se faz.
A responsabilidade pela gestão de custos é da Diretoria de Controladoria na maioria das vezes ou um Departamento de Custos porem a gestão de custo é responsabilidade de todos seus princípios devem ser disseminados pela empresa para que se possa garantir a competitividade e lucratividade da empresa.
Pedro Paulo Galindo Morales é Graduado em Gestão de Sistemas Produtivos, possui especialização em Controladoria e trabalha na área de Gestão Orçamentária de uma empresa multinacional de Distribuição de Energia Elétrica.
Blog: www.falandodegestao.wordpress.com
E-Mail: [email protected]
Diferenciando Premissas de Restrições
Quando o assunto é gerenciamento de projetos, constantemente observo pessoas confundirem premissas com restrições e vice e versa.
A confusão entre essas palavras ocorre cedo, logo no processo de iniciação, em um dos primeiros documentos do projeto: o Termo de Abertura (Project Charter). Esse documento, utilizado para o Sponsor (patrocinador) aprovar o início do projeto, requer que sejam expostas as premissas e as restrições. Apesar de cometido no começo do projeto, o erro de conceito é percebido comumente apenas no processo de execução, onde eventuais mudanças já requerem alto grau de esforço e validação política junto ao Sponsor.
Mas afinal: Qual a diferença entre premissas e restrições?
Basicamente premissas são hipóteses e restrições são deveres. Porém, essa definição não basta para apresentar claramente a diferença entre os dois termos. A chave da questão está na pergunta: “Quem executa o trabalho está no ambiente externo ou interno ao projeto?”.
Premissas são suposições dadas como certas sobre o ambiente externo ao projeto. Sobre elas é baseado o plano e a promessa de tempo e custo.
Podemos resumir a afirmação acima na equação:
Premissas = Suposições + Ambiente externo ao Projeto
Já restrições são limitações impostas internamente ou externamente ao trabalho executado pela equipe de projeto.
E a equação para a afirmação acima seria:
Restrição = Limitações + Ambiente Interno ou Externo ao Projeto + Trabalho Executado pela Equipe de Projeto
Para exemplificar, segue um organograma padrão, pertinente a quase todos os tipos de projeto:
{gallery}GP{/gallery}
Com base na visão deste organograma, vamos supor a criação de um projeto referente a uma luxuosa e grandiosa festa de casamento ao ar livre em um sítio no período da manhã. E na Declaração de Escopo do Projeto há a seguinte descrição:
A luz do sol será refletida nos prismas colocados à margem do lago situado atrás da capela, produzindo um arco-íris.
Para que esta ação ocorra, não há dependência única de trabalho executado pela equipe do projeto, mas sim de um fator externo ao controle do projeto: o clima. Se não houver sol, não haverá luz refletida nos prismas e consequentemente não haverá arco-íris. Conclui-se que se trata de uma suposição dada como certa referente ao fator clima que está externo ao controle do projeto. Sendo assim, trata-se de uma premissa. Essa premissa poderia ser declarada da seguinte forma no Termo de Início do projeto:
Haverá sol pela manhã incidindo no lago situado por de trás da capela.
Uma premissa nunca possuirá um termo de obrigatoriedade como a palavra “deverá”. Seria errado reescrever a frase acima da seguinte forma: “Deverá haver sol pela manhã incidindo no lado situado por de trás da capela”. Não é possível obrigar uma premissa a ocorrer, pois ela não está sob o controle do projeto, mas apenas sob monitoramento, consequentemente, não se pode impor a palavra “deverá”.
O fato de não escrever palavras que transcendam o sentido de obrigação em premissas pode parecer capricho, mas não é. Utilizar termos desse tipo pode ser um termômetro para saber se o que está sendo escrito é uma premissa ou uma restrição. Se realmente houver necessidade de inserir, por exemplo, um “deverá” na frase, este pode ser um indício de que a afirmação não é uma premissa, mas uma restrição.
Caso seja realmente obrigatório que uma afirmação aconteça, a atividade responsável para que esta afirmação ocorra deve estar mapeada na Declaração de Escopo do Projeto e incluída na WBS/EAP (Work Breakdown Structure ou Estrutura Analítica de Projeto), para então poder se “candidatar” a restrição. Reiterando: restrições são limitações impostas internamente ou externamente ao trabalho executado pela equipe de projeto. Quando um projeto, por exemplo, é feito sob contrato, as cláusulas contratuais geralmente serão restrições.
Mas continuando com o exemplo do projeto da festa de casamento, uma restrição poderia ser “Todos os garçons devem falar inglês”. Esse item pode totalmente ser atendido apenas com a o trabalho da equipe do projeto através de uma atividade como “Recrutamento e Seleção”, que deve estar mapeada na WBS e descrita na Declaração de Escopo.
E ainda citando o fator clima, caso o projeto incluísse a procura por um local para realização da festa, uma restrição poderia ser “O evento deverá ocorrer em um sítio no Estado de São Paulo, no município que apresente o menor índice de chuva no mês de maio dos últimos 5 anos”. Esta ação pode ser sanada através de uma atividade de pesquisa completamente passível de realização pela equipe do projeto. Não está sendo exigido que haja sol, mas apenas que o evento seja realizado em um local que historicamente possua a menor incidência de chuva no mês desejado.
Convém ressaltar que tanto Premissas como Restrições, além de serem expostas no Termo de Início, também devem ser descritas na Declaração de Escopo do Projeto ou em um documento específico. A diferença é que o trabalho responsável por satisfazer uma Premissa não existe na Declaração de Escopo, nem na WBS, pois não se trata de uma atividade que está sob controle da equipe do projeto, ou seja, não há trabalho dentro do projeto. Ao contrário, uma atividade responsável por atender uma Restrição deve estar na Declaração de Escopo e na WBS, pois é um trabalho da equipe do projeto.
Clay Susini Aquino Junior possui MBA em Gerenciamento de Projetos pela Fundação Getúlio Vargas e é Bacharel em Sistemas de Informação com Ênfase em Planejamento Estratégico pela Universidade Presbiteriana Mackenzie. É membro do PMI (Project Management Institute) e ministra palestras e aulas sobre Gerenciamento de Projetos, Metodologias de Projetos de Desenvolvimento de Software e Gestão Financeira.
Contato: [email protected]
Diferenciando Programas de Projetos
Um equívoco comum cometido pelos Escritórios de Gerenciamento de Projetos é conceber um Programa como Projeto ou vice e versa.
Em um primeiro momento esse tema parece soar sem importância, como se fosse apenas mais uma definição teórica e puramente conceitual, mas é a base para o fracasso real de inúmeros Projetos.
No Brasil e, principalmente, no setor corporativo privado, Projetos são erroneamente definidos como Programas apenas por serem grandes. Mas tamanho é simplesmente a consequência, e não o motivo para um Programa existir.
Outras justificativas usadas para transformar conjuntos de Projetos em Programa são o aproveitamento da dinâmica comum de vários recursos e a existência de inúmeras frentes de trabalho com mais de um time. Realmente Programas possuem essas características, mas apenas como consequência de um fator maior: a concepção de uma idéia geradora de um benefício estratégico, dando origem a um conjunto de iniciativas independentes responsáveis por concretizar o benefício idealizado.
Um Programa, antes de se tornar um conjunto de projetos, nasce como uma idéia estratégica geradora de um benefício singular, sem a real certeza de que virá a se tornar dois, cinco ou dezenas de Projetos independentes. No momento de concepção do Programa, não sabemos ao certo o que deve ser feito para atingir o benefício idealizado, tampouco como fazer. Sabemos apenas que uma série de tarefas independentes gerará um benefício estratégico e único. E é comum um Programa, em plena execução, ainda gerar novos Projetos com o intuito de consolidar o benefício estratégico definido anteriormente.
Por sua vez, Projeto é um esforço pontual, menos abstrato. Por mais que um Projeto em sua fase de iniciação possua indefinição de escopo, tempo e custo, sempre temos em mente o principal entregável. Sabemos o “o que”. Apenas não sabemos ainda o “como”. E nesse contexto, para diferenciar um Projeto de um Programa, não importa o tempo, o custo e nem a quantidade ou interação entre os recursos.
Parafraseando o PMBoK (Project Management Body of Knowledge), do PMI (Project Management Institute), Projeto é um empreendimento temporário, com recursos limitados, que gera um resultado, produto ou serviço único. Já Programa é um conjunto de Projetos independentes que estão unidos e associados estrategicamente para geração de um benefício. Em um Programa, obviamente cada projeto possui um benefício próprio, afinal são independentes. Mas o benefício gerado pelo Programa é diferente dos benefícios individuais de cada Projeto. E esse benefício do Programa é geralmente pensado primeiramente e estrategicamente antes de ser criado o conjunto de Projetos.
Como exemplo, podemos citar o Programa de Aceleração do Crescimento (PAC) do Governo Federal. O Programa possui como objetivo construir infraestrutura logística e energética para sustentar o crescimento do País. O objetivo de um Programa sempre terá a característica de ser abstrato, pois na concepção da idéia só há a expectativa do benefício e não do objeto entregável. Não sabemos exatamente o que terá que ser feito para que o benefício seja obtido, tampouco como.
O Governo Federal dividiu o PAC em seis Subprogramas e duas Frentes de Trabalho. Os Subprogramas do PAC são: PAC Energia, PAC Habitação, PAC Cidade Melhor, PAC Comunidade Cidadã, PAC Água e Luz Para Todos e PAC Transportes.
Cada um desses Subprogramas possui vários Projetos. Por exemplo, o Subprograma Cidade Melhor possui o Projeto Construção Estação de Tratamento de Esgoto na Baixada Santista, o Projeto de Construção de Drenagem Urbana na Baixada Fluminense, entre outros. E há também os Projetos internos do Programa que não são expostos à população, como Projetos de marketing para promover o Programa em rádio, TV e Internet, Projetos de Desenvolvimento de Sistemas de Informação do Governo etc.
Outra característica dos Programas é a existência das Frentes de Trabalho. Em tradução livre do The Standard for Program Management do PMI, Programas incluem elementos de trabalho não contidos em nenhum de seus Projetos. Esses elementos são as Frentes de Trabalho, que atravessam os Projetos, não necessariamente todos, apoiando a integração necessária para o benefício único do Programa. Como exemplo, a auditoria interna poderia ser uma Frente de Trabalho do PAC. As ações de auditoria atravessariam os Projetos gerando o benefício de integridade do Programa como um todo. Mas oficialmente o PAC possui duas Frentes de Trabalho: Medidas Institucionais e econômicas e a outra é Desenvolvimento Econômico Social.
A construção de uma usina hidrelétrica, por exemplo, se idealizada unitariamente, é um Projeto. Mesmo que leve 10 anos para ser construída e mobilize bilhões de reais, continuaria sendo um Projeto, e não um Programa, pois o que foi idealizado é o produto de forma direta.
Essa usina poderia estar dentro do Programa de Aceleração do Crescimento, e seria completamente normal caso a usina não tivesse sido idealizada no momento da concepção do Programa, pois se pensou no benefício da Aceleração do Crescimento no Brasil, e não em todas as entregas palpáveis que concretizariam esse benefício.
Programas geralmente possuem fases futuras totalmente abstratas em escopo, tempo e custo, muito mais abstratas que as fases futuras de um Projeto. De maneira rotineira, Programas são subdivididos em fases ou subprogramas. A primeira fase constantemente possui projetos visualizados com mais clareza ou já em execução. E a as demais com a visualização apenas da percepção do benefício desejado.
Após toda essa exposição conceitual, ainda perdura a dúvida: qual o problema em confundir Projeto com Programa ou vice e versa?
Conceber e executar um Projeto como Programa não é tão grave, mas certamente criará na corporação uma imagem errada do que é Programa e a sensação de que gerenciar Programa é o mesmo que gerenciar Projeto. E caso a corporação comece a implementar o conceito de Programa, terá dificuldade em difundir o conceito correto.
Porém, será catastrófico executar um Projeto quando na verdade for um Programa. O “Projeto” sofrerá aumento de escopo e prazo constantemente e a corporação não entenderá o motivo, mas ocorre que o peso de uma idéia estratégica, que é abstrata, foi delineado para ser entregue em um único “Projeto”, que possui um molde pontual e bem mais objetivo que a fase inicial de um Programa. O titulado “Projeto” nesse caso, terá inúmeras fases e mais cedo ou mais tarde essas serão tão independentes uma das outras que possuirão entregas totalmente diferentes, auto-suficientes e com objetivos próprios. Novos entregáveis começarão a ser criados no decorrer do ciclo de vida e não serão bem aceitos pela corporação, pois serão concebidos como se fossem incremento de escopo (scope creep) e causadores de atraso, quando na verdade são novos Projetos, independentes, e que apenas agora se visualizou a necessidade estratégica de criá-los e assim solidificar cada vez mais a expectativa abstrata inicial. Essa sucessão de desastres costuma ocorrer quando se faz a gestão de um Projeto sendo na verdade um Programa.
Gerenciando por tendências: Matemática, estatística e conhecimento
Muito se fala em gerenciamento por tendências, mas o que é isso? Vou tentar dar uma resposta bem direta e resumida. Gerenciar por projetos nada mais é do que o uso objetivo e simultâneo de matemática, estatística e conhecimento do ambiente passado e presente do projeto.
Não entrarei no mérito das “fórmulas”, para isso proponho que procurem algo sobre “EVM” (Earned Value Management ou Gerenciamento de Valor Agregado). A parte matemática e estatística do gerenciamento por tendências, nada mais é do que a solução de algumas contas simples (como diria um ex-professor meu, conta de padeiro!) e a análise de métricas em determinada fase do projeto, ou seja, não exige nenhum conhecimento especial. Um bom usuário de excel é capaz de fazê-lo. Então, qual o grande segredo? A resposta é simples: Conhecer o projeto, conhecer o produto do projeto e as circunstâncias na qual ele foi, está sendo e será executado. Por exemplo:
Preciso entregar 10 plantas em 20 dias, faço uma previsão média de 2 dias para executar cada uma delas. Depois de 10 dias descubro que ao invés de 5, conclui apenas 3. Fazendo uma análise matemática afirmo com absoluta certeza que o projeto está atrasado! Mas está? Quais foram as condições que levaram a entrega de 3 plantas e não 5? Essas condições se repetirão? É possível que eu tenha executado as 3 plantas de maior complexidade e agora as outras 7 sejam concluídas nos próximos 10 dias? Após analisar todo o cenário, posso afirmar se o projeto está ou não realmente atrasado ou adiantado.
O grande erro, já observei isso não uma ou duas vezes, mas várias, é basear seu relatório de andamento e desempenho apenas em números, contas. Reconheço que muitas vezes as alta administração não tem tempo para relatórios detalhados, mas essas observações são muito importantes, ou estaremos passando posições erradas e que poderão comprometer completamente o projeto, e pior, quando pode não haver mais “remédio” (à não ser atualizar o curriculum).
Gerenciar por tendências não é adivinhar o futuro, mas sim, se aproximar da realidade, acompanhando todo período de duração do projeto.
É possível avaliar as pessoas segundo Maslow?
Depois de identificar alguns problemas de produtividade e de qualidade no trabalho, passei o último mês fazendo um exercício mental para avaliação de alguns colaboradores. Basicamente, procurei associar a postura de cada um à “Teoria de Maslow”.
Abraham Maslow propõe que as necessidades humanas estão agrupadas em cinco categorias ordenadas hierarquicamente, à saber:
1) Necessidades fisiológicas: Pessoas precisam ter suas necessidades básicas atendidas, como fome, sede, calor, frio e etc.
2) Necessidades de segurança: Pessoas devem se sentir seguras, com relação a segurança física, residência e etc.
3) Necessidade social:Pessoas possuem necessidade de se sentirem unidas a outras pessoas, de fazer parte de um grupo;
4) Necessidade de estima: pessoas tem necessidade de serem bem consideradas por outras pessoas como significativas, de serem prestigiadas;
5) Necessidade de auto-realização: Pessoas tem necessidade de serem tuo o que são capazes;
Sabidas as cinco necessidades da “Teoria de Maslow”, segue minha conclusão. Na maioria das pessoas identifiquei, no máximo, o desejo de preenchimento da terceira necessidade (o que é diferente de estarem transitoriamente neste estágio) ,ou seja, querem apenas fazer parte de um grupo, o que limita suas ações ao mesmo nível das ações do grupo. Se o grupo estiver na média, elas também estarão na média, o que nivela por baixo a qualidade do trabalho. Portanto, embora sejam pessoas com as quais temos maior facilidade de relacionamento (pelo próprio desejo de fazer parte do grupo), são pessoas, em geral, acomodadas e de baixa ou média produtividade.
Identifiquei poucas pessoas nos estágios 4 e 5. Não coincidentemente, boa parte delas são pessoas de relacionamento um pouco mais difícil, já que são pessoas mais questionadoras, vaidosas e seguras de suas opiniões, porém, com um nível de produtividade alto. Pois bem, sempre ouvi que podemos “moldar” as características técnicas, mas não o perfil das pessoas, ou seja, posso ensinar às pessoas o trabalho a ser feito, mas não mudar seu comportamento, qual dos grupos é mais interessante?
Não sou especialista em gestão de pessoas, mas para os especialistas ficam as discussões: É possível avaliar as pessoas segundo Maslow? O que é melhor? pessoas produtivas de caráter difícil ou pessoas medianas de fácil relacionamento? E se tivermos em nossa equipe apenas pessoas nos estágios 4 e 5? Deixo no ar. Com a palavra, os especialistas!