Blog CMMI & MPS.BR

O que nos leva a nos comprometer com alguém ou com alguma coisa?
O que nos leva a iniciar e terminar uma atividade?
A buscar a cada dia uma forma melhor de fazer as coisas?
A assumir a responsabilidade quando um erro aparece?
A cumprir aquilo que nos propomos a fazer?

Nada mais e nada menos do que o nosso COMPROMETIMENTO!

A etimologia do verbo comprometer indica que a palavra significa “fazer promessa com”, ou seja, empenhar-se, obrigar-se.

E só agimos desta forma porque temos confiança no outro ou na empresa, valores em comum, uma causa em comum.

Grau de compromisso

Você têm valores em comum com a sua empresa?
Você têm uma causa comum com o seu parceiro?
Quando você se propõe a fazer algo para você mesmo você cumpre?

Desta forma é que avaliamos o nosso grau de compromisso com os outros e com nós mesmos.

O valor do comprometimento

E por que esta competência é tão valorizada?

Porque comprometimento refere-se a perseverar ou se destacar em tempos difíceis.

Estar comprometido com um resultado nos ajuda a manter a calma diante das adversidades e obstáculos que nos cercam. Estar comprometido com uma meta nos ajuda a superar perdas ocasionais de motivação.

Mas quais são os fatores que determinam o comprometimento?

Eugenio Mussak, em seu livro Caminhos da Mudança (2008) identifica as cinco condições básicas para que ocorra o comprometimento, em qualquer tipo de relação:

1. Admiração
2. Respeito
3. Confiança
4. Paixão
5. Intimidade

Veja o post completo →

O que é liderança?

O líder é quem guia, quem dá a cara a tapas, quem toma a frente, quem inspira, quem dá confiança… São muitas definições, mas a melhor que já ouvi é: o líder é quem serve.

Servir, pra mim, é:

Mostrar o caminho além do horizonte: O líder é quem alinha o grupo em torno de uma visão, mostrando o caminho a ser percorrido e garantindo o comprometimento de todos para chegar lá.

Fornecer ferramentas e monitorar os trabalhos: O líder é responsável por acompanhar e cobrar as atividades de cada um. Assim, ele deve fornecer quaisquer ferramentas e/ou orientações pra que todos façam sua parte da melhor forma.

Inspirar pelo exemplo: O líder é como um ídolo, transparecendo confiança, direção, pulso firme, honestidade e que sabe como e o quê fazer.

Bernardinho: Postura de um líder

Saber o que é o conceito de liderança não é o suficiente – como tudo, o difícil é botar em prática. Por isso, como é de praxe no Saia do Lugar, aqui vão 7 dicas práticas para líderes:

1- Seja sempre transparente
Líderes também erram (menos Chuck Norris) e passam por problemas. Seus liderados não querem ver alguém perfeito, mas sim alguém que consegue lidar com problemas e, principalmente, resolvê-los.

2- Dê valor às opiniões alheias
A época dos tiranos já passou. Um líder que não aceita opiniões, ainda mais da sua equipe, não consegue criar harmonia no trabalho.

3- Nunca desista
Você e sua equipe provavelmente terão ondas de desmotivação, quando é normal que você queira dar um roundhouse-kick em tudo. Nesse momento em que não se sente vontade de cantar uma bela canção, o líder deve se sobressair pra motivar a equipe e fazê-la chegar numa solução.

O texto abaixo foi escrito originalmente pelo Lee Iacocca, o cara que salvou a Chrysler (da outra vez) e escreveu o livro “Where Have All The Leaders Gone?” (Cadê os líderes?).

O texto se chama”A teoria dos 9 C’s – o que um líder deve ter como características”:

1- Um líder tem que mostrar Curiosidade. Ele deve ouvir pessoas que estejam fora do círculo do “Sim, senhor”.  Se ele não testa suas crenças e opiniões, como ele sabe que está certo? A falta de habilidade em ouvir é uma forma de arrogância. Isso pode parecer que ou você acha que sabe tudo, ou que você simplesmente não se importa.

2- Um líder deve ser Criativo, fazer algo que ninguém imaginaria, algo realmente diferente. O famoso pensar fora da caixa. Líder é administrar mudanças – não importa se você lidera uma empresa ou um país.

3- Um líder deve Comunicar. Eu não estou falando de fazer fofoca ou de soltar grunhidos. Estou falando sobre encarar a realidade e falar a verdade.

4- Um líder deve ser uma pessoa de Caráter. Isso significa saber a diferença entre certo e errado e ter coragem de fazer a coisa certa. Abraham Lincoln disse uma vez, “Se você quer testar o caráter de um homem, dê poder a ele”.

5- Um líder precisa ter Coragem. Presunção não é coragem. Falar alto também não é coragem. Coragem é o comprometimento de sentar numa mesa de negociação e falar.

6- Para ser um líder você precisa ter Convicção – um fogo dentro de você. Você tem que ter paixão. Você tem que real e profundamente querer fazer algo até o fim.

Veja o post completo →

Todos que se interessaram por Gerenciamento de Projetos já ouviram que mais de 80% do tempo de um GP é gasto com comunicação.

O PMBOK afirma que: “A comunicação foi identificada como a maior razão de sucessoou fracasso de um projeto”.

Apesar disto, dentro da gigantesca bibliografia de gerenciamento de projeto é extremamente difícil encontrar bons livros falando sobre o assunto, mesmo o PMBOK, depois de afirmar a sua importância através da frase citada acima, dedica apenas 21 de suas 336 páginas ao Gerenciamento da Comunicação,  e vale ressaltar que isso significa um avanço em relação a versão 2003, que dedicava apenas 14 páginas.

O Grande problema que percebi em várias metodologias de desenvolvimento/gerenciamento com que trabalhei é que se confunde comunicação com documentação.

Documentação é importante sim, para que todos saibam o que está acontecendo, para nivelar informações e para sinalizar o acompanhamento do projeto.

…o que não está documentado, não foi combinado ou não foi dito…

Dentro da área de conhecimento de Gerenciamento da Comunicação, o PMBOK define 5 Processos:

1. Identificar Partes Interessadas
2. Planejar as Comunicações
3. Reportar o Desempenho
4. Gerenciar as Expectativas das Partes Interessadas
5. Distribuir Informações

Em minha experiência de projetos, gerenciando e sendo gerenciado, pude perceber que os processos que recebem maior atenção são “Reportar o Desempenho” e “Distribuir Informações”, muito provavelmente porque esses elementos são, basicamente, processos de documentação.

Ouvi certa vez de um superintendente, em reunião para Gerentes de Projeto, a seguinte frase: “…se falharmos na documentação do que ocorreu durante o projeto, ficamos sem defesa, nas mãos do cliente…”

Realmente isso é verdade, se não está documentado, não temos defesa, MAS…Precisamos mesmo nos defender sempre?

Para mim essa metodologia devia se chamar COASS (Cover Our ASS!)

Veja o post completo →

Antes de iniciarmos, temos que ter em mente que as práticas genéricas são elementos mandatários do CMMI e seu objetivo central é a institucionalização, mas… o que é institucionalização?

O CMMI define como institucionalização: “A maneira de se fazer negócios que uma organização segue rotineiramente como parte de sua cultura corporativa”. Em outras palavras, o jeito que as coisas são feitas aqui.

Diversos elementos podem atrapalhar a implementação das práticas genéricas como menosprezar a importância da institucionalização, foco apenas nas práticas específicas ou até mesmo sub-estimar o tempo e esforço necessário para sua implementação.

Vamos falar da Generic Goal 2:

• GP 2.1 Estabelecer uma política organizacional
• GP 2.2 Planejar o processo
• GP 2.3 Prover recursos
• GP 2.4 Atribuir responsabilidades
• GP 2.5 Treinar as pessoas
• GP 2.6 Gerenciar configurações
• GP 2.7 Identificar e envolver stakeholders relevantes
• GP 2.8 Monitorar e controlar o processo
• GP 2.9 Analisar aderência objetivamente
• GP 2.10 Revisar o status com a alta direção

Mitos sobre práticas genéricas

GP 2.1 Mito 1: “Tudo que precisamos fazer é escrever algumas políticas e pedir para o CIO assina-las”

• As políticas podem virar um papel que nunca ninguém irá ler
• As políticas devem definir claramente o que deve ser feito
• Se as políticas documentarem o que a alta gerência realmente acredita ser importante, as chances delas serem seguidas aumentam considerávelmente.

GP 2.2 Mito 2 “Um plano para cada área de processo”

• O perigo dos infinitos planos “Aqui esta o plano para coletar as métricas de PPQA”
• O planejamento apropriado deve ser realizado para cada área de processo envolvido
• Garantir tempo, esforço e custo suficiente para executar as tarefas necessárias para realizar cada processo

GP 2.3 Mito 3: “Esta prática e apenas para garantir que teremos pessoas suficientes”

• O risco de focar apenas em pessoas: “Nunca teremos pessoas suficientes”
• Recursos INCLUEM custo, instalações, ferramentas e obviamente pessoas
• “Recursos adequados” quer dizer que o processo pode ser seguido naturalmente sem restrições de custo, prazo ou pessoas

GP 2.4 Mito 4: “As pessoas não precisam da descrição de seu serviço”

• Não assuma que as pessoas compreenderam suas responsabilidades e nível de autoridade
• Defina claramente papéis e responsabilidades que alinhem as pessoas ao serviço realizado
• Faça as pessoas compreenderem seus papel e defina a autoridade necessária para realizar seu trabalho

Veja o post completo →

Na melhor das hipóteses, o Gerenciamento de Projeots é uma tarefa desafiadora e complexa. Entretanto, vejo frequentemente gerentes de projetos tornarem esta atividade ainda mais difícil por terem expectativas erradas do que deve ser a função.

De uma forma rápida e direta, gerenciamento de projetos É gerenciamento de problemas. Se não fosse esse o caso, não haveria a necessidade de gerentes de projetos. Pelo contrário, um pedido de trabalho seria feito sem qualquer problema (pessoas, ferramentas, cronograma, requisitos, etc). Bastaria simplesmente alinhar o que deve ser feito e esperar a conclusão. As coisas aconteceriam sem qualquer problema.

“Eu estou aqui para ajudar vocês, para tirar os problemas para que vocês possam trabalhar”
- Marcio Oliveira

Na verdade, nosso papel existe porque este mundo hipotético não existe. Recursos são super alocados, tecnologias não funcionam como escrito nas revistas, habilidades necessitam de updates, requisitos não estão claros, os prazos são apertados, enfim, o mundo de Alice não existe.

Frequentemente trabalho com GPs que comentarem estes tipos de transtornos, aborrecimentos, ou “problemas”. Normalmente estas ações externas são tratadas como “azar” que o gerente teve naquele projeto. No entanto, isto nada mais é do que o trabalho normal do GP. Uma coisa é fato “haverá problemas no projeto” e o gerente do projeto esta lá para resolve-los para que a equipe possa continuar.

Nem é preciso dizer que estes GPs, que pensam nos problemas como aborrecimentos ou “azar” passam boa parte de seu tempo tensos, irritados e até mesmo frustados. Para evitar isso o gerente de projetos deve planejar melhor, pensar com mais clareza, ter mais visão estratégica, obter mais apoio do sponsor e da equipe do projeto, e, fazer uma análise de riscos minuciosa.

Veja o post completo →

Esta área de processo é muito mal compreendida em TI (e mal utilizada). A maioria das empresas define como risco um percentual a mais para se inflar o custo de um projeto como por exemplo:

• Cliente novo: 10%
• Falta de pessoal disponível: 5%
• Linguagem nova: 5%
• Ambiente “encardido”: 10%

E por ai vai… Com isso, se o projeto inicialmente custava R$ 50.000,00, agora ele custará 30% a mais, ou seja, R$ 65.000,00.

Esta é uma análise equivocada do que é riscos em projeto, e consequentemente não tratou o problema (risco), apenas criou um fundo para tentar cobrir um possível prejuizo.

Esta análise equivocada é mais comum do que parece, constantemente vejo casos assim em empresas que presto consultoria, mas isso acontece porque muitos acham que gerenciamento de riscos é um bixo de sete cabeças, já vi muita gente falar “isso não serve pra nada” e até mesmo “Isso é teoria, na vida real ninguém usa”.

Então, vamos “descomplicar” este assunto. Primeiramente, Gerenciamento de riscos é mais fácil do que parece e é muito provável que você faça isso no seu dia-a-dia de forma tão natural que nem perceba. Vamos a um exemplo:

Você vai em uma concessionária VW e compra um Fox zerinho. A entrada veio de suas economias de dois anos e o restante foi financiado em 48 vezes.

Agora… onde estão os riscos com esta nova aquisição? Vejamos alguns:

• Seu Fox pode ser roubado
• Alguém pode bater nele
• Você pode sofrer um acidente
• Você pode tomar uma multa
• E várias outras coisas

Estes são alguns dos riscos e obviamente você precisa tratá-los e há várias formas para isso como contingência, mitigação, transferência e outros.

Vamos tratar este caso juntos. Se o seu Fox for roubado, além de ficar sem carro você ainda terá que pagar as prestações, então, para isso você precisa de uma contingência, ou seja, um Plano B. Você contrata um seguro para seu carro. Com isso você transferiu o risco para seguradora, e esta por sua vez, coloca várias cláusulas no contrato para você não abusar ou agir de má fé.

Veja o post completo →

O tamanho do seu projeto, o tamanho da sua equipe, o tamanho de suas entregas, o tamanho de seus checklist, o tamanho dos seus códigos – enfim, tudo em um projeto depende do TAMANHO. O tamanho muda as regras de como o jogo será jogado.

Quanto maior o projeto (em tamanho ou complexidade) mais importante é para o gerente de projetos, “quebra-lo” em módulos ou projetos menores e dividir a responsabilidade com pessoal qualificado.

Isto garantirá que todos os membros do projeto (incluindo o gerente do projeto), poderão ver o quadro geral sem se perder em detalhes enquanto estão verificando a saúde (status) do projeto.

Projetos distribuidos tendem a ser maiores que muitos outros tipos de projeto. O gerente deve usar varias táticas para não deixar que o tamanho influencie nas partes menores. A palavra “grande” quer dizer muitas coisas, mas nenhuma em específico. Ela pode querer dizer que você tem uma equipe de 10 pessoas trabalhando durante 12 meses, como também pode querer dizer que você tem uma equipe de centenas de pessoas trabalhando em manutenção de sistemas (como por exemplo um outsourcing).

Aqui vão algumas dicas de como trabalhar com o “tamanho correto” e garantir que todos entenderam como as peças menores influenciam no todo.

• Quebre o projeto em projetos menores, fluxos de trabalho menores, módulos menores ou pacotes menores no melhor jeito possível para seu gerenciamento.
• Garanta que cada fluxo de trabalho tenha pelo menos um ponto focal responsável por sua entrega
  Se possivel, tente colocar alguns membros da equipe com dois chapéus em fluxos de trabalho distintos. Isto melhorará no entendimento da visão do todo (o projeto).
• Acompanhe o desempenho (Não importa o jeito, mas acompanhe) de cada fluxo de trabalho ou pacote SEPARADAMENTE e colete alguns indicadores periodicamente para montar o todo.
• Documente e compartilhe os riscos, casos, pressuposto e dependências de cada pacote.

Veja o post completo →

Há tempos, definiu-se como líder, aquela pessoa que tem seguidores atraídos pelo carisma e confiança. Um chefe por sua vez, tem autoridade única e exclusivamente pelo cargo que detém. Desta forma, podemos dizer que todo líder tem completas condições de ser um chefe, mas temos que refletir se: E o contrário, é possível?

Chefiar é buscar resultados, planejar os trabalhos das pessoas, organizar, priorizar, manter e controlar. Estas nada mais são que  funções básicas, porém, hoje em dia, para chefirar também é necessário motivar as pessoas. Com uma equipe motivada consegue-se melhores resultados e um clima melhor (e nem preciso dizer que reduz o custo e aumenta a produtividade).

Ser chefe é bem mais fácil pois o poder conferido ao cargo por sí é o aparato necessário. O líder, por outro lado, deve se preocupar em conduzir as pessoas, dar um significado ao trabalho e convencer os liderados a defender sua causa.

Diferentemente das épocas anteriores, hoje as pessoas escolhem onde querem trabalhar. As pessoas da Geração Y, não se prendem mais a uma empresa, logo, se não estiverem satisfeitas em seu local de trabalho trocarão tão fácil quanto trocam de roupa. E… com o mercado aquecido, provavelmente elas não ficarão um dia sequer desempregadas. Isso deveria ser motivo suficiente para as empresas preferirem ter líderes e não chefes.

Hoje, todo chefe tem o discurso de líder na ponta da língua, é um discurso bonito, e todos gostam de ouvir, porém suas ações lhe dirão se ele é realmente um líder. Talvéz a até tenha mudado a forma de pensar, mas não a de agir e isto leva tempo.

Um líder é aquele que mesmo sem autoridade alguma consegue ser seguido, respeitado e obedecido. Ele consegue unir um grupo, representa-lo e leva-lo a atingir objetivos.

Chefiar é fazer com que as pessoas façam algo.
Liderar é fazer com que as pessoas queiram fazer algo.

Assim, podemos ver várias diferenças entre chefes e líderes como:
Veja o post completo →

Jack Welch é um dos CEOs mais admirados do mundo e um dos lideres de negócios mais influentes de nossa era. Em seus 20 anos na GE, ele ajudou a otimizar diversos processos ditos como burocráticos e aplicou diversas inovações gerenciais. Ainda na GE, ele formou diversos líderes em todos os níveis.

Veja as oito máximas de Jack Welch:

• Líderes valorizam a sua equipe incessantemente, usando cada encontro como uma oportunidade de avaliar e orientar as pessoas e construir autoconfiança.
• Líderes certificam-se de que as pessoas não apenas conheçam a visão, mas vivam e respirem sua visão.
• Líderes penetram na pele das pessoas, emanando energia positiva e otimismo.
• Líderes estabelecem confiança com franqueza, transparência e crédito.
• Líderes têm coragem para tomar decisões impopulares e emocionais.
• Líderes sondam e pressionam com uma curiosidade que beira o ceticismo, certificando-se de que suas perguntas sejam respondidas com ações.
• Líderes inspiram, por meio do seu exemplo, a assunção de riscos e o aprendizado.
• Líderes comemoram.

A grande maioria dos Gerentes de Projetos de TI Experientes que conheço entraram nessa carreira acidentalmente… (Uso o termo a grande maioria para não cometer algum equívoco ao usar “todos”, porque não consegui me lembrar de nenhum que não tenha sido assim, você que me lê, conhece algum?)

A recente valorização da Certificação PMP, tende a mudar um pouco isso, mas como ela exige que se tenha pelo menos 4.500 horas de experiência comprovada, isso ainda vai demorar muito tempo, mas o que quero questionar com esse artigo é, ser Gerente de Projetos é mesmo um acidente de percurso?

Note que falei em Gerentes de Projetos de TI, o PMI inclusive é oriundo de projetos de Engenharia Cívil, pois é muito mais fácil numa obra de engenharia, um prédio ou uma ponte por exemplo, falamos de um produto que tem séculos de história e já se percebe a necessidade de um projeto, de fases bem definidas (fundações, alvenaria, acabamento, hidráulica, elétrica, etc) e quando uma obra de engenharia dá errado, o prédio ou a ponte cai, e morre gente, por isso desde sempre, ou desde há muito tempo, a legislação exige o projeto, exige e fiscalização e a sociedade cobra isso, e quem contrata o prédio ou a ponte sabe que ela precisa ser gerenciada e que isso custa…

Já quando falamos de informática, falamos de algo muito recente, poucas décadas, de algo intangível. Quando um projeto de software dá errado perde-se “apenas” dinheiro e tempo (normalmente), quem compra um projeto de TI somente agora está percebendo que é preciso contratar um gerenciamento eficiente, porque isso vai garantir o produto comprado.

Mas porque os Gerentes de Projeto de TI foram um “acidente de percurso”?

No Brasil, há cerca e 25 anos atrás começou na área de TI o processo de terceirização, visando adequar os custos, inicialmente apenas com locação de mão de obra, rapidamente isso evoluiu para “proposta fechada” (vulgo projeto).

Veja o post completo →