Blog CMMI & MPS.BR

Constantemente este tipo de discussão aparece quando converso com amigos das mais variadas empresas. Tanto empresas com CMMI e MPS.Br quanto empresas sem. O problema aparece porque RH e gerentes de projetos não entram em um consenso na definição do que é um profissional ruim, bom, e excepcional.

Será que o João, aquele excelente programador é mesmo excelente? E a Maria, dizem que ela é ruinzinha, será que é mesmo. Será que isso não é marketing?

Os questionamentos são variações de:

• “Como eu sei que um profissional é bom?”
• “Como eu avalio se o desempenho de um profissional é bom?”
• “Como eu quantifico a importância de um profissional para a empresa?”
• “Como identificar as falsas percepções?”
• “Como fazer isso, de verdade e atender OT?”

E… em sua grande maioria, as empresas não querem fazer isso apenas para constar em OT, querem ter o benefício real.

Em TI, muitas vezes avalia-se as pessoas puramente pela percepção, e não pelos resultados. Você provavelmente conhece que dizem que é bom, mas até hoje você procura saber no que. Um amigo comentou: “Tem um gerente de serviços lá na empresa que a gerência de departamento acha o cara o máximo, mas tudo serviço que ele entrega é atrasado, e alguns clientes nem podem ouvir o nome dele. Porque acham ele tão bom quando ele não é?”. Infelizmente eu não conheço o caso, apenas a versão do meu amigo, mas, muito provavelmente é “percepção” – há várias possibilidades que vão desde ele ter muita teoria e nenhuma prática até terem falado para o gerente do departamento que ele era bom. Veja o post completo →

Há um equívoco em achar que CMMI e métodos ágeis são opostos. Um depende mais de processos e institucionalização de um método padrão, o outro enfatiza a iteração entre os envolvidos no projeto e “Fazer software e não documentação” (Manifesto Agil). Um processo documentado e institucionalizado é o coração do CMMI e é frequentemente utilizado como modelo para definição de metodologias de desenvolvimento para projetos críticos. Por outro lado, a abordagem Agil é colocada em ação quando um projeto apresenta mudanças incrementais, em particular aquelas que não foram incluídas na definição de escopo inicial.

Há criticas a ambos, bem como: “CMMI é usado apenas em grandes projetos ou projetos de críticos que necessitam uma equipe muito grande e um ciclo de vida rígido”. Do outro lado: “Aqueles que implementam métodos Ágeis tem sido classificados como o indisciplinados ou “hackers” de projetos de software”.

O Software Engineering Institute (SEI) acredita que os críticos não estão exatamente certos. O sucesso ou fracasso da aplicação das metodologias Agile nada tem a ver com documentação, e segundo Margaret Kulpa e Johnson Kent: “Você poderia escrever uma tonelada de documentação sobre seus processos sem necessariamente praticar o que está no papel.

Então, onde é que os gerentes de projeto encontram “terreno comum”? Segundo os autores: “A institucionalização”, que o CMMI define como “A maneira de fazer negócios que uma organização segue rotineiramente como parte de sua cultura”. Simplificando, uma empresa de TI pode ter um alto grau de colaboração como parte de seu DNA , implementar a cultura Agile e estar aderente aos princípios definidos pelo CMMI ao mesmo tempo.

Há diversas formas de se institucionalizar métodos Agile com CMMI através da adoção de práticas genéricas associadas aos níveis de maturidade 2 e 3. Aqui estão algumas das mais importantes, senão as mais fáceis em um programa de implementação
Veja o post completo →

O que é mais importante para um gerente de projetos? Certificação, Pós Graduação ou formação?

Constantemente tenho me deparado com esse questionamento, e por isso resolvi escrever este post para dar uma resposta definitiva, direta e que não deixe dúvidas, enfim, sem enrrolação.

E a resposta é: Depende.

Existem no mercado muitos cursos (e isso não é prerrogativa do Gerenciamento de Projetos) “baratinhos”, que prometem o impossível e que tentam forçar o “candidato a  aluno”  a uma decisão tendenciosa que resulte na compra do curso oferecido. A maioria deles vem com um carimbo como “alguma coisa PMI” ou “alguma coisa PMP”.

Não gosto dessa posição por achar que ela caminha pelo limite da ética, um argumento mais forte e ela cai para o lado errado…

Por isso eu respondo Depende, e procuro ajudar quem faz a pergunta a encontrar sua própria resposta, porque o que serve para um, pode não servir para outro e assim por diante, então, vamos analisar esses três caminho:

Certificação

As certificações, e a Certificação PMP oferecida pelo  PMI não é exceção, não tem por objetivo ensinar algo, mas avaliar se o candidato já tem conhecimento suficiente para assumir a função de gerente de projetos, é um “carimbo de atestado de competência”, ou… vamos falar diferente, atesta que o canditato se deu bem na prova.

Estes certificados são reconhecidos pelo mercado, e apesar de não concordar com essa fábrica de certificados isso, é uma realidade de mercado e faz diferença na carreira profissional, porém, os cursos de certificação PMI ou qualquer outra, não tem por objetivo ensinar nada ao candidato. O Objetivo é preparar o candidato (que já CONHECE o assunto) a passar na prova e tirar sua certificação.

Portanto não é indicado para quem quer iniciar a carreira. O Público alvo é quem tem MUITO conhecimento e quer apenas comprovar isso, com um certificado reconhecido internacionalmente.  Mesmo porque, pelas regras do PMI (que muitos tentam burlar com informações falsas) é preciso ter 4.500 horas de experiência para se candidatar a prova.

Veja o post completo →

Prólogo

O objetivo deste mini-tutorial é mostrar como se inicia um projeto.
Para facilitar o entendimento (e disseminar conhecimento) ele é focado na simplicidade, facilitando assim o entendimento.

A estimativa de tamanho em APF toma por base que todos os elementos são de complexidade média, todavia é importante vocês terem em mente que isto é apenas o início. Em se interessando procurem ler mais sobre estimativa, planejamento, desenvolvimento de requisitos e controle de mudanças – aos que estão iniciando com MPS.BR ou CMMI, este tutorial vai ajudar bastante nos primeiros níveis.

Tutorial Mini Projeto – O nascimento da idéia

Um amigo te liga e pede para você fazer uma visita pois ele precisa de um projeto, ele te fala que é bem simples e precisa apenas de um aplicativo para gerenciar seus contatos.

Chegando em seu escritório, a conversa começa e ele fala que tem mais de 1.000 contatos em uma agenda (papel mesmo) e que quer (e precisa) automatizar isso. Na sua cabeça você já percebe que terá uma tela (até agora).

Conversa vai, conversa vem, ele comenta que um grande problema que ele tem é que ele não consegue dizer de onde são os contatos. Ele comenta que se ele pudesse agrupar-los, isso o ajudaria muito.

Ele também comenta que gostaria que tudo ficasse em uma única tela, ele não gosta de ficar passeando de uma tela pra outra.

Veja o post completo →

A descrição de papéis e responsabilidades (também conhecida como descrição de cargos e responsabilidades) é uma coisa básica na industria, porém em TI ela ainda esta engatinhando.

Vamos fazer um teste, procure em sua empresa se há uma documentação definindo claramente o que você (ou alguém com o mesmo cargo) deve fazer. Bom… provavelmente em mais de 90% dos casos não haverá nada ou uma definição informal do que é.

O mesmo vale para os níveis de senioridade.

Mas, porque é tão importante ter essa descrição? Simples: organização, produtividade e escala.

Tendo os crítérios, você reduz riscos de:
Contratar um junior achando que é senior
Enviar demanda a um profissional que não esta apto a executa-la
Ter diferentes faixas salariais para o mesmo perfil
Não cumprimento de prazos
E outras

Vale lembrar que esta definição deve ser apoiada pela política organizacional e deve ter a aprovação e comprometimento da alta direção.

Agora, vamos a um exemplo simples de como deve ser uma “descrição de cargos e responsabilidades”:

Cargo: Programador Junior Java
Formação: Técnica, superior ou curso que ateste os conhecimentos

Conhecimentos:
1. UML
2. Java
3. …

Habilidades:
1. Conversação em inglês
2. Digitação rápida
3. …

Responsabilidades:
1. Entregar os produtos com a qualidade definida
2. Apontar diáriamente as horas trabalhadas nas tarefas específicas
3. …

A quem se reporta: Gerente de desenvolvimento

É muito importante você definir critérios para os elementos evitando que alguém que saiba apenas a frase “the book is on the table” seja classificado com “Conversação em Inglês – OK”

Lembrando, este é um exemplo básico, da pra evoluir bem com elementos como: “Elementos Obrigatórios e Opcionais”, “Faixa Salarial”, “Atuação secundária”,”autoridade”, etc, etc, etc

Os que estão envolvidos com OT ou GRH devem montar esta definição para cada cargo (papel ou função) de sua organização e segui-la.

Abraço a todos.
Veja o post completo →

Atendendo a nossa leitora Walkiria, estarei colocando alguns posts voltados a OT (e GRH – mais pra frente explico).

Hoje vamos falar da importância de ter papéis e funções definidas.
Primeiramente, isto é pré requisito tanto para o CMMI quanto para o MPS.BR, mas você deve estar se perguntando “o que minha empresa ganha com isso?”. Bom, ganha produtividade e agilidade.

Muitas empresas (normalmente as pequenas) não tem isso muito bem definido, então é como se todo mundo pudesse fazer tudo (e fazem). Nestes casos ninguém acaba se especializando em nada e com isso perde-se a oportunidade de aumentar a produtividade e ganhar agilidade. Um analista que passa 70% do tempo programando, com certeza não se especializará em levantamento de requisitos, relacionamento, desenvolvimento de requisitos e outras disciplinas voltadas a análise, pelo contrário ele se poderá ser excelente em “java” ou “.net”, então você pergunta “mas… ele não é um analista???”
Ele até pode programar, mas se ele é analista, seu principal foco é análise e é ai que ele deve se especializar.
O mesmo vale para as vagas (muito comum) de Gerente de Projetos onde na descrição consta até J2EE. Bom… se a vaga é pra gerente as habilidades que ele deve ter são várias mas J2EE com certeza não é uma delas, e é comum encontrar J2EE e não encontrar “Gerência de Riscos”

Uma dica que dou é:

• Mapear os cargos (ou papéis);
• Definir as responsabilidades de cada um;
• Definir as habilidades necessárias;
• Definir critérios para classificar alguém como A ou B
• E o mais importante… manter tudo isso funcionando

Especialização gera agilidade, que gera aumento da produtividade e que acaba reduzindo os custos.