Blog CMMI & MPS.BR

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 →

A partir de hoje também estaremos falando de MPS.BR aqui no Blog CMMI. Então não estranhe pois quando falarmos de uma PA, também colocaremos o processo equivalente do MPS.BR.
Aos que não conhecem, o MPS.BR é um modelo de qualidade muito parecido com o CMMI e mantido pela Softex. Ele foi baseado na ISO 12107, ISO 15504 e no próprio CMMI. Outro ponto interessante é que ele também é organizado por estágios, mas, diferente do CMMI, ele tem 7 estágios.

A – Em Otimização;
B – Gerenciado quantitativamente;
C – Definido;
D – Largamente Definido;
E – Parcialmente Definido;
F – Gerenciado;
G – Parcialmente Gerenciado.

Ele tem poucos anos, mas tem trazido excelentes resultados à comunidade de software do Brasil. Atualmente mais de 100 empresas foram avaliadas em algum nível do MPS.BR e muitas destas continuam a jornada para os níveis mais altos.
Isto é excepcional pois acredito que dentro de 3 à 5 anos teremos pelo menos 40 empresas brasileiras avaliadas em alta maturidade.

No ritimo atual, acredito que este ano a quantidade de avaliações MPS.BR já deva passar a quantidade de avaliações CMMI aqui no Brasil.

Se você se interessou procure a Softex e veja como participar e obter subsidio do governo (sim, o governo subsidia parte do processo).

Enfim, é um modelo muito (muito mesmo) simular ao CMMI. Vale a pena o investimento.
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.

Algumas dúvidas comuns são:
O que é o EPG?
Como montar um EPG?
Como é composto o EPG?

Bom, primeiramente, o EPG significa Engineering Software Group. Muitos ainda chamam de SEPG, o que não é errado, mas a terminologia nova é sem o “S”

O EPG é responsável pela definição e manutenção dos processos da organização. Recomenda-se que seus membros possuam profundos conhecimentos em engenharia de software e na própria organização.
O EPG deve ter um responsável que normalment é chamado de “EPG Leader”.

O diagrama abaixo demonstra como um EPG é tipicamente composto:

Cada uma destas áreas deve:
Veja o post completo →

Olá, atendendo ao pedido do nosso leitor Tony, resolvemos criar um post que explica de um jeito mais fácil o que é o CMMI.

CMMI Nível 1

Antes de mais nada, não existe avaliação CMMI nível 1, mas esta é uma classificação que pode ser dada a toda empresa que não foi avaliada em um nível de maturidade CMMI.
É o que é feito na maioria das empresas, requisitos entram e o produto sai, mas não se sabe ao certo como ele saiu e o que foi necessário para conseguir isto.

CMMI Nível 2

O CMMI nível 2 implementa a Gestão (PMI pode ajudar muito nesta fase). Neste ponto, cria-se o plano de projeto e os projetos são tocados de forma organizada e sistematizada. Você começa a medir as coisas e analisar o desempenho, assim as decisões são tomadas com mais embasamento. Gestão é a palavra chave do CMMI nível 2.

Veja o post completo →

Depois do post “quanto tempo é necessário para se conseguir o CMMI?” recebi alguns e-mails perguntando o que faz demorar tanto para implementar o CMMI.

Primeiramente vamos entender que CMMI significa Capability Maturity Model Integration. Ou seja, é um modelo que prega capacidade e maturidade, e como todos sabem, não se vende maturidade em pílulas, maturidade leva tempo.

É simples, para seu filho de 5 anos entender o que é uma função [Y= f(x)] ele precisará aprender um monte de coisas antes como por exemplo “ler”, e ainda assim, quando ele tiver 15 anos se você der a ele o livro “Matemática aplicada” ele ainda assim não vai entender, ou vai ter um entendimento simplista do que é uma função.

Investe-se muito em um programa CMMI e para isto existe um tempo mínimo. Se uma organização tentar fazer nos chamados “prazos recordes” ela correrá um risco enorme de “gastar tudo de novo daqui a 3 anos”.

Particularmente conheço pelo menos dois casos de empresas que sairam do nível 0 para o 3 em menos de 2 anos, tem o Appraisal SCAMPI A publicado no site da sei e hoje não fazem um simples “plano de projeto” ou tem um processo definido. Em outras palavras, estas empresas vão gastar a mesma coisa ou mais quando forem reavaliadas ou seu SCAMPI A perderá a validade se sofrerem uma visita surpresa da SEI.

Claro que isto não é regra, também conheço casos de empresas que conseguiram o CMMI 2 e depois o 3 em 2 anos e o modelo esta firme e forte nas empresas.

Enfim, é melhor investir de forma consistente para que tenha maturidade de fato do que menosprezar o que realmente significa “maturidade”.