Blog CMMI & MPS.BR

Antes, vamos a duas perguntas:

• Quais os dados você confia e porque você confia neles?
• Quais os dados você não confia e porque você não confia neles?

Fazendo esta reflexão será mais fácil entender a importância de MA Medição e Análise. MA é base para os níveis 4 e 5 (A e B do MPS.BR) e se ela não for bem implementada e de maneira séria ela simplesmente terá que ser refeita quando chegar ao nível 4, tornando a implementação ainda mais cara. Alguns sintomas de falhas no sistema de medições são:

• Os profissionais preenchem a planilha de horas apenas no fim da semana
• Informações como “custo do projeto” estão em mais de um local e há divergências
• Se você perguntar a 5 pessoas diferentes onde esta o esforço do projeto cada uma vai pegar em um lugar diferente
• Horas adicionais não são computadas no projeto (para não estourar o custo)
• O gerente não faz um acompanhamento constante dos indicadores
• Projetos com problemas não são analisados, apenas faz-se uma força tarefa para entregá-los
• Não são realizadas pesquisas com os clientes insatisfeitos
• Existe muita entrada de dados manual
• Existem vários dados apontados como “0”

É uma verificação simples, mas vai revelar muito sobre o sistema de medições

Informações ruins lhe levarão a tomar decisões ruins.

Tipicamente, quando seu sistema de medições não é bom, você pode tem problemas como:

• Estimativas erradas
• Custo adicional (e normalmente desnecessário)
• Falta de visibilidade do progresso

A dica que dou é levar MA a sério logo nos primeiros níveis, fazendo isso, você vai economizar muito tanto nas próximas implementações quanto nos seus projetos.
Veja o post completo →

O caso a seguir aconteceu no mesmo projeto do post “Qualidade custa mais?”.

Hoje em dia muitos falam sobre produtividade, mas compreender o que é de fato produtivo é algo bem complexo.

Naquele projeto, fiz um experimento interessante.
Tínhamos dois analistas programadores muito bons, o Primeiro (Leandro) era conhecido na empresa como um dos mais rápidos. Passei para ele um programa de 20h (programa A). Ele terminou o programa em aproximadamente 7h (35% do tempo).

A segunda analista programadora (Eline) também era conhecida como muito boa, mas não tão boa quanto o Leandro. Passei para ela um programa de 16h (programa B). Ela terminou o programa em aproximadamente 11h (68%).
Se você tivesse que premiar alguém, quem você premiaria? Olhando esses números você não tem dúvidas de quem é o melhor, certo?

Esta é a análise feita pela maioria das pessoas, mas… (há sempre um mas) os programas foram para a área de testes.

Quando retornaram da área de testes o programa A necessitava de várias correções e ajustes, já o programa B praticamente não teve erro.

Nas idas e vindas do programa A, utilizou-se mais 9h, ou seja, o programa dele não foi finalizado em 7h e sim em 16h.

Agora vamos refazer a análise.

• Leandro – utilizou 80% do tempo
• Eline – utilizou 68% do tempo

Agora você pode responder aquela pergunta sem com mais embasamento.

Ambos tiveram uma produtividade excelente, mas analisando os dados da forma correta, consegue-se ver quem foi o mais eficiente quem teve a melhor produtividade naquele projeto.

Enfim, como dito, a primeira análise é a mais comum (e equivocada), mas devemos sempre avaliar todo o ciclo para ter certeza de que estamos avaliando o processo da forma correta.
Veja o post completo →

A Jornada Goiânia em Engenharia de Software é um evento sem fins lucrativos realizado pela LG Informática e pela Estratégia Tecnologia da Informação, desde 2001, em Goiânia – GO.
Trata-se de um evento técnico, voltado para o público de profissionais e estudantes da área de tecnologia da informação.

Criada para atender uma demanda existente na comunidade de profissionais,alunos e empresas de tecnologia na região Centro-Oeste, a JGES já faz parte do calendário regional de eventos sobre tecnologia, tendo como principal objetivo difundir conhecimento e experiência relevantes e atuais para um público ávido por novidades e informações consistentes na área de informática.

Em cada edição, o evento apresenta um tema relevante da atualidade, atraindo um público de bom nível e número considerável de participantes. Neste ano será realizada a nona edição do evento, que contará com mini-cursos e palestras enfocando o tema: Aplicações Práticas em Engenharia de Software.

Para mais informações sobre o evento clique aqui

Por volta de 2003 gerenciei um projeto de um portal interno para uma grande multinacional. O esforço estimado com APF foi de aproximadamente 7.000h e estava bem justo.

Este era nosso primeiro projeto neste cliente e o mesmo estava muito apreensivo com a qualidade pois o projeto envolvia mais de 10 áreas da empresa (marketing, RH, Engenharia, Presidência, etc).

A equipe prevista era de dois analistas e seis programadores. Então decidi mudar um pouco e trocar um destes programadores por um tester. No começo várias pessoas falaram que não daria certo e que o projeto atrasaria porque “faltaria braço”.

A tester que coloquei no projeto (Fabiana Custódio) era uma pessoa muito integra e que realmente se preocupava com a imagem da empresa. Para fortalecer este processo, no lançamento do projeto divulguei a todos seu papel e que nada sairia da empresa sem o aval dela. Em apoio ao processo implementamos também a bonificação por produtividade.

O projeto foi andando e começaram a aparecer os bugs (internos sempre), a Fabiana realizava os testes, encontrava os bugs e passava para os programadores corrigirem. Em um determinado momento começou um “movimento” para tira-la do projeto pois segundo alguns “os problemas estavam aparecendo e isto não era bom”.

Tentaram de diversas formas me convencer de que ela atrapalhava o andamento do projeto, mas sempre fui firme. Do ponto de vista gerencial os resultados estavam excelentes pois o cliente não encontrava erros em nossas entregas. Comercialmente o cliente também estava muito satisfeito.

Veja o post completo →

Uma das principais responsabilidades de um gerente de projetos é zelar pelo custo do projeto e usar este dinheiro da melhor forma possível (Leia o PMI para mais detalhes).

Apesar disto ser (vamos dizer) óbvio, não são muitos os gerentes que fazem uma boa gestão do custo, e, durante o planejamento do projeto o gerente do projeto deve analisar tudo o que deve ser feito e fazer uma análise de custo x benefício .

Se você tem 10.000 para fazer uma determinada coisa, e existe um “componente” que faz exatamente o que você quer por menos da metade do preço, porque não adquiri-lo? Bom, é muito provável que você já deva ter presenciado uma situação assim, e é mais provável ainda que a decisão tenha sido de “fazer” o requisito, perdendo assim uma excelente oportunidade para economizar.

Outro caso é: Em um sistema onde você o usuário se cadastra e escolhe seu estado a pergunta é: Será desenvolvido uma tela de manutenção de estados?

Cenário 1: Sim, o cliente precisa atualizar a lista de estados sempre que precisar – Custo: R$ 1.000,00 (referente à 20 horas de trabalho)

Cenário 2: Não, é uma tabela que raramente muda, o custo não justifica o benefício – Custo: R$ 0,00

É um caso simples, mas neste caso simples você já economizou um montante do seu custo. Claro que existirão casos onde estes desenvolvimentos serão necessários, todavia serão minoria e mesmo nestas minorias, provavelmente a contratação de um serviço (como o de CEP dos correios) saia mais em conta.

Uma dica: Pratique esta análise durante o planejamento. Provavelmente você terá boas surpresas.

Vou deixar de lado toda parte histórica e vamos para a prática.
O principio de Pareto também é muito conhecido como a regra dos 80/20. Esta é uma ferramenta muito boa tando em projetos six sigma quanto no gerenciamento de projetos pois o Pareto lhe ajuda a focar no que realmente importa.

Vamos a alguns exemplos práticos de Pareto:

• 20% do tempo despendido produz 80% dos resultados
• 80% de suas ligações telefonicas são destinadas a 20% dos seus contatos
• 20% das ruas são responsáveis por 80% do trafego (não em São Paulo)
• 80% dos pedidos em um restaurante vem de 20% do menu
• 20% de seus clientes são responsáveis por 80% do seu faturamento
• 20% das pessoas causam 80% dos problemas
• 20% dos recursos de um sistema ocupam 80% do tempo de desenvolvimento

Faça alguns destes testes e você verá que o principio de pareto é verdadeiro.

Nos níveis de alta maturidade (CMMI 4 e 5 ou MPS.BR B e A) você utilizará muito Pareto que também é uma ferramenta indispensável em projetos Six Sigma.

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 →