Blog CMMI & MPS.BR

Treinamento
O Coaching não se propõe a transferir conhecimento entre as partes. O que ocorre é o desenvolvimento de habilidades intrínsecas do cliente.

Mentoring
O mentor possui uma determinada expertise técnica e orienta um profissional a seguir uma determinada linha de conduta.

Consultoria
O consultor faz uma análise do cenário, tira conclusões e apresenta propostas de soluções ao cliente.

Aconselhamento
O aconselhador propõe de forma direta uma solução para alguém…

Diferente de tudo isso, o Coaching não dá o caminho das pedras; não tira conclusões nem apresenta soluções; não faz julgamentos; não induz o cliente a tomar qualquer decisão ou

atitude …

O papel do Coach é levar o Coachee (cliente) a profundas reflexões que o possibilita encontrar as respostas que lhe são mais adequadas. Afinal, cada ser humano é diferente um do outro e o “cérebro é uma máquina sem manual de operação”.

Ao contrário da psicologia, o Coaching não se preocupa com eventos do passado para explicar traumas, bloqueios ou mágoas. O foco está no presente e no futuro, ou seja, o importante é “plantar” hoje para “colher” no mesmo dia ou no futuro.

No Coaching, só existe um motivo para observar o passado: obter aprendizado para fazer diferente e melhor no futuro.

Em suma, o que importa é foco + ação + resultado + melhoria contínua.

[Alexandre]

Esta é outra pergunta recorrente, e a resposta é: “Depende do que você quer”. Vamos as mais comuns:

Quero apenas implementar CMMI: Nada, absolutamente nada. Uma empresa pode pegar o relatório técnico que “é” o CMMI (modelo CMMI), ler, e começar a implementar. O SEI não obriga nenhum treinamento para isso, aliás, este é um dos motivos do modelo que pode ser baixado gratuitamente. Todavia, para ser totalmente franco, até hoje não vimos uma sequer empresa que tenha conseguido sucesso em um SCAMPI através desta abordagem simples. Há algumas pequenas coisas, algumas dicas, alguns atalhos que um especialista em CMMI pode te passar em poucas horas e que podem fazer a diferença entre o sucesso ou não em um SCAMPI (Um Attention Course passa boa parte disto em apenas 4h).

Quero participar de uma equipe de avaliação SCAMPI: Um pré-requisito é o curso de introdução ao CMMI. Em seguida, durante a preparação para o SCAMPI, os membros recebem um “treinamento no método de avaliação SCAMPI” do avaliador lider (Lead Appraiser) ou membro qualificado. Mas isto faz parte do processo de avaliação SCAMPI – não é o treinamento para avaliador oficial SEI.

Quero ser um instrutor oficial do curso de introdução ao CMMI:  É necessário conceitos intermediários sobre o CMMI, o treinamento de instrutor e então ser observado ministrando o treinamento CMMI. Tudo isto, antes de ser oficialmente declarado como “Instrutor Oficial CMMI”.

Quero ser um Avaliador Oficial CMMI (Lead Appraiser): São necessários o curso de intrudução ao CMMI, conceitos intermediários sobre o modelo, participar como membro de equipe de duas avaliações SCAMPI, o curso de avaliador SCAMPI e por ultimo ser observado em uma avaliação SCAMPI. Só depois disto e com o ok do membro SEI que fez a observação, que você será declarado como Lead Appraiser.

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 →

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 →

Com a chegada do CMMI 1.3, muitos estão se perguntando: “O que vai mudar no CMMI 1.3?”. Esperado para novembro de 2010, esta versão incluirá melhorias em todos os modelos CMMI (CMMI-DEV 1.3, CMMI-ACQ 1.3 e CMMI-SVC 1.3).

Este update também trará melhorias ao método de avaliação SCAMPI e treinamentos CMMI relacionados. Segundo o SEI, as mudanças não irão exigir grandes mudanças ou reciclagem dos modelos implementados.

As principais mudanças no modelo serão:

Maior esclarecimento sobre Alta Maturidade

Como já é de conhecimento, quando você realiza uma avaliação SCAMPI, seu resultado reflete um nível de maturidade da organização. Organizações iniciantes no CMMI são tipicamente classificadas como Baixa Maturidade enquanto aquelas que tem mais tempo ou tem obtido melhores resultados são consideradas “exemplares de alta maturidade”.

Na versão 1.3, uma das grandes mudanças será um melhor esclarecimento e entendimento do que é Alta Maturidade. Foi criado um time com foco em alta maturidade e os membros dessa equipe tem se concentrado em fazer mudanças que melhorem a clareza do que é e como alcançar este nível.

O SEI sabe que na versão 1.2, alta maturidade está confuso levanto à uma variedade infinita de interpretações e é exatamente este ponto que eles querem resolver. Quer um exemplo: Pergunte a 5 pessoas o que é um modelo de desempenho e você terá 5 respostas diferentes (e provavelmente nenhuma certa).

A equipe pretende esclarecer os seguintes pontos:

• O papel do material informativo nas avaliações de alta maturidade
• O significado e uso dos modelos de processos e modelagem de processos
• Como os objetivos de negócio estão ligados à alta maturidade
• O que são causas comuns e como devem ser utilizadas
• O que se espera de alta maturidade no desempenho individual de cada processo
• A seleção, definição e o nível de instanciação dos subprocessos

A equipe de Alta Maturidade do SEI está focada nas PAs OPP – Organization Process Performance, QPM – Quantitative Project Management, OID – Organizational Innovation and Deployment e CAR – Causal Analysis and Resolution.

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.

OT – Treinamento organizacional

50. Tenha um mapa de treinamentos necessários para cada função
51. Defina claramente quais os treinamentos de responsabilidade da empresa e quais são os do projeto
52. Envolva a área de treinamento no planejamento do projeto
53. Identifique quais são os treinamentos necessários para atender os objetivos estratégicos da empresa
54. Mantenha um programa de treinamento contínuo
55. Colete informações de desempenho dos treinamentos
56. Verifique se após os treinamentos houve melhora de desempenho nas pessoas
57. Tenha uma descrição de responsabilidades e autoridades de cada função
58. Planeje o investimento com treinamentos e periodicamente verifique os benefícios
59. Armazene os dados de treinamentos

PI – Integração de produto

60. Identifique as necessidades de integração entre produtos e componentes
61. Planeje como será a sequência de integração
62. Crie critérios para garantir que os produtos estão prontos para serem integrados
63. Tenha métodos alternativos de integração e selecione o melhor (se possível com DAR)
64. Armazene informações sobre o processo de decisão sobre integrações
65. Tenha guias ou processos de como as atividades de integração devem ser realizadas
66. Verifique a compatibilidade entre as interfaces
67. Documente os ajustes necessários nas interfaces
68. Crie mecanismos que garantam que o produto final contem as versões corretas dos códigos e componentes

RD – Desenvolvimento de requisitos

69. Identifique as necessidades do projeto
70. Identifique as expectativas que os envolvidos tem com o projeto
71. Tenha guias que auxiliem o desenvolvimento de requisitos
72. Traduza os requisitos de negócio e necessidades em requisitos técnicos
73. Verifique antes da validação com cliente
74. Defina critérios que liberem os produtos para validação com cliente
75. Assegure o entendimento correto dos requisitos – valide formalmente com o cliente
76. Faça o mapeamento dos requisitos com funções, códigos, componentes, aquisições, etc.

Veja o post completo →

Olá pessoal, hoje vamos falar de dicas para institucionalização, o diagrama abaixo demonstra o que pode-se fazer.

Vamos comentar cada uma destas iniciativas:
Treinamentos: Esta iniciativa é a mais óbvia de todas, mas é fundamental, sua eficiência é entre média e baixa, mas não deve ser descartada.
Workshop: Evento onde você apresenta o modelo de um jeito mais informal, você pode torna-lo interativo fazendo brincadeiras e distribuindo prêmios – tem eficiência média
E-Mails rápidos: E-mails cursos, de até 15 linhas resumindo ao máximo um determinado assunto, sua linha deve ser informal – tem eficiência entre média e alta
Dicas: E-mails ou avisos com dicas de determinados assuntos, devem ser rápidos e preferencialmente gráficos – tem eficiência média-baixa
Quadros: Similar ao Dicas, apresentam mais informações. Coloca-se normalmente nos quadros de avisos da empresa – tem eficiência baixa.
Banners: Banners sempre ajudam, o ideal é torna-los o mais gráfico e fácil possível, deixe os detalhes nos processos e use uma linguagem de fácil interpretação – tem eficiência alta
Guias: As pessoas adoram guias, assim, é uma boa iniciativa criar um guia para os principais trabalhos – tem eficiência média
Testes: Testes fazem com que as pessoas estudem, seus resultados são medianos, mas sempre devem ser usados como complemento aos treinamentos – tem eficiência média
Concursos: Quando com prêmios, os concursos ajudam demais a institucionalização, as pessoas vão atrás dos prêmios e de queba, aprendem mais sobre os processos – tem eficiência média alta.

Vale lembrar que todas estas iniciativas ajudam, mas não “resolvem”. Emprenho e comprometimento são fundamentais.

A melhor iniciativa é as pessoas praticarem os processos, é a mais “simples” e mais eficiente.

Como diria meu grande  grande amigo Edson Sayeg: “Não é preciso decorar, basta praticar”
Veja o post completo →