Muitas pessoas (normalmente novas com Agile) tem uma compreensão erradas sobre Agile. Da mesma forma, muita gente na comunidade ágil tem idéias equivocadas sobre o CMMI (e… obviamente MPS.Br).

Neste ponto quero destacar cinco destes equívocos:

Equívoco #1: O CMMI é prescritivo

A verdade é que o CMMI prescreve muito pouco. Converse com um avaliador de alta maturidade e ele vai dizer que o CMMI é descritivo e não prescritivo.

Por exemplo, o CMMI diz que você deve ter um documento de requisitos, mas não diz nada sobre como o que ele deve ser parecido. Deve ser super detalhado? Deve ser leve? Deve usar UML? Nada. A escolha é sua. Um Product Backlog pode atender a esse requisito? Claro! Desde que ele atenda as necessidades de seu projeto.

Você decide o que é mais apropriado para você. O CMMI apenas diz que você deve seguir o que você decidiu que seguiria.

Equívoco #2: Um processo não pode funcionar em todos os projetos

Na comunidade ágil, muita gente tem a idéia errada de que o CMMI manda usar um único processo em todos os projetos. Isso não é verdade. O CMMI nível 3 pede um processo padrão organizacional, mas isso não significa usar um único processo em cada projeto. A organização pode ter vários processos padrão que podem ser aplicados em diferentes tipos de projeto. Assim, você pode ter Agile como um padrão para determinados tipos de projeto, RUP para outros tipos e um modelo tradicional para outros. A escolha é sua, os modelos que você vai usar são definidos por você de acordo com sua necessidade.

O padrão é esperado para uma constante evolução. Quando você tem uma situação diferente em seu projeto, isto deve ser incorporado à base de conhecimento e pode ser aplicado também ao Tailoring do processo para que os outros projetos se aproveitem destes novos conhecimentos.

Equívoco #3: Projetos com CMMI tem alto custo

O CMMI realmente pede muito pouco. A maioria dos projetos Agile (bem executados) gera tanta documentação quanto um projeto CMMI. O ponto é que é uma documentação em grande parte diferente.

É fato que muito do “alto custo” dos projetos acontece durante os processos de avaliação, quando a organização precisa manter diversas evidências indiretas dos fatos como todas as atas de reuniões, emails, documentos de detalhamento e outros. Isto acontece muito por orientação das consultorias como uma forma de mitigação do risco de insucesso na avaliação formal. Ninguém quer orientar uma empresa e não ter sucesso em uma avaliação.

Equívoco #4: CMMI significa cascata & Significa seguir um plano e não “atualizar” o plano

Como diria meu amigo André Nascimento: “Quem foi que disse que o CMMI é castata?” Isso é verdade, não há uma única linha no CMMI ou no MPS.Br que fale que o modelo é cascata. Não há nada. Ele é o que você definir que ele é.

O CMMI permite que você escolha qualquer modelo de ciclo de vida. Você pode escolher um modelo ágil se quiser, algo iterativo, algo espiral, enfim, você escolhe. O projeto também não esta amarrado a um plano estático. Na verdade, espera-se que mude, que seja atualizado sempre que for necessário (e isto acontece em todo tipo de projeto).

Equívoco #5: O CMMI valoriza o processo ao invés das pessoas

A valorização das pessoas é uma propriedade cultural da organização e é óbvio que toda organização devem valorizar as pessoas. Especialmente em TI, as pessoas são os maiores “ativos” das organizações. Valorizar as pessoas, reconhecer suas realizações e motiva-las deve ser uma das maiores prioridades de todo gestor (e todo mundo).
Enfim… o CMMI não diz que você não deve valorizar as pessoas. Não há conflito algum entre o CMMI e a valorização das pessoas

Em tempo…
O CMMI tem uma má reputacão na comunidade ágil porque muitas empresas se preocupam mais com a avaliação do que com a melhoria no processo organizacional propriamente dito.

Muitos acreditam que “ter o selo” gera mais valor do que as melhorias no processo organizacional propriamente ditas. Além disso, falhas na institucionalização ou estrutura fraca podem gerar resistências, muitas vezes por falta de compreensão do que é o modelo. Isto tudo, gera implementações que agregam pouco e que não estão alinhadas aos princípios ágeis.

Atualizado em 07-setul-10 (os gráficos serão atualizados)

Devido a grande dificuldade em se encontrar quais empresas no Brasil passaram por avaliações CMMI o Blog CMMI mantém uma lista com estas avaliações.

Ajude-nos a manter esta lista atualizada, informe-nos de uma nova empresa CMMI que confirmaremos e atualizaremos a lista.

O Gráfico abaixo mostra a quantidade de avaliações ao longo dos anos. Nota-se que somente no ano passado conseguimos chegar à quantidade de avaliações que tivemos em 2005, más há explicações para isso pois o CMMI DEV 1.2 entrou em vigor em 2006.

Veja também a lista de empresas MPS.Br

Lista de avaliações CMMI no Brasil

• 7COMm SP 2005
• Alstom Transportes SP 2002
• AMS Tecnologia SP 2004
• Atech Tecnologias Críticas SP 2003
• Atos Origin SP 2004
• ATT/PS Informática MG 2009
• Avansys Tecnologia BA 2009
• Brasília DF 2003
• BRQ SP 2004
• BSI Tecnologia PR 2004
• C.E.S.A.R PE 2003
• Cetil Sistemas de Informática SC 2009
• Citibank SP 2003
• Claro SP 2010
• Complex SP 2009
• CPM SC 2005
• CPM SP 2005
• CPqD SP 2003
• Credicard SP 1998
• CTIS DF 2005
• CTIS PR 2007
• DB1 Informática PR 2010
• DBServer RS 2009
• DBC Company RS 2010
• Dell RS 2003
• Disoft SP 2003
• DRM SP 2005
• DTS Latin America SP 2003
• e-Dablio RJ 2003
• Embraer SP 2006
• FITec PE 2005
• Fortaleza CE 2003
• Foursys Projetos e Sistemas SP 2010
• Gad’Brivia RS 2010
• G&P – Gennari & Peartree SP 2003
• General Motors SP 2005
• Getronics SP 2005
• GSW SP 2008
• GVDASA Informatica RS 2009
• HP SP 2005
• ilegra RS 2009
• Inatel MG 2003
• Infoserver SP 2004
• Inovare Tecnologia PR 2010
• Instituto Atlântico CE 2003
• Interact Solutions RS 2009
• Itaú SP 2005
• Itautec SP 2008
• IVIA CE 2008
• Johnson & Johnson SP 2008
• Kostal Eletromecânica SP 2008
• LG Sistemas GO 2008
• LinkNet DF 2010
• Logocenter SC 2005
• Kenta Informática RS 2010
• M.I. Montreal Informática RJ 2004
• Matera Systems SP 2005
• MATERA Systems Informática SP 2009
• Message RJ 2008
• META IT RS 2007
• Microsiga Software SP 2005
• MJV Tecnologia RJ 2009
• MSA Informática MG 2005
• Nec do Brasil SP 2003
• Prime Informática SP 2005
• Procwork SP 2005
• Phoebus PB 2010
• Recife PE 2002
• Red & White IT Solutions GO 2009
• Relacional - 2006
• Relacional Consultoria RJ 2005
• Santander Banespa SP 2005
• SERPRO Salvador BA 2003
• Sigma Dataserv Informatica PR 2010
• Sistran SP 2009
• Spress Informática S/A MG 2005
• Stefanini SP 2002
• Suntech SC 2009
• T-Systems SP 2005
• Teclógica Serviços em Informática SC 2009
• Tele Design SP 2002
• Telefonica Pesquisa e Desenvolvimento SP 2007
• Telefônica Pesquisa e Desenvolvimento SP 2008
• TSE DF 2005
• Unitech BA 2005
• Vixteam ES 2006
• Vorlans - 2007
• ZCR Informática BA 2006
• ZCR Informática BA 2009

• 7COMm SP 2008
• Accenture SP 2005
• Accenture Brazil SP 2009
• Accenture Delivery Center SP 2004
• Atos Origin SP 2007
• B2Br – Business to Business Informática DF 2008
• BSI Tecnologia PR 2010
• C.E.S.A.R – Recife Center PE 2007
• Cinq Technologies PR 2009
• CI&T SP 2004
• CITS – Centro Internacional de Tecnologia de Software PR 2009
• CPqD SP 2009
• CWI Software Ltda RS 2009
• DATUM RS 2009
• DBA Engenharia de Sistemas RJ 2001
• e-Core RS 2009
• EDS SP 2001
• Ericsson SP 2001
• Hold SP 2009
• IBM Fábrica de Software SP 2003
• Inovare PR 2010
  
• Instituto Atlantico CE 2006
• Instituto de Pesquisas Eldorado SP 2005
• Itaú SP 2007
• Kaizen Consultoria e Serviços SP 2008
• Motorola SP 2001
• NTConsult RS 2009
• Politec SP 2005
• Qualitas SP 2006
• Senior Sistemas SC 2008
• Serasa SP 2008
• Sofhar Gestão e Tecnologia PR 2009
• Spress Informática S/A MG 2007
• Stefanini SP 2003
• Synapsis Brasil Ltda RJ 2009
• T-Systems do Brasil SP 2009
• TIVIT SP 2007
• Tlantic SI RS 2009
• Triad System SP 2009
• Unisys Corporation SP 2009
• Xerox do Brasil ES 1997

• Ci&T SP 2006
• EDS RJ 2003

• Accenture SP 2005
• BRQ SP 2006
• Ci&T SP 2007
• CPM Braxis BA 2007
• EDS SP 2006
• EDS SP 2008
• IBM RJ 2005
• Instituto Atlantico CE 2009
• Politec DF 2006
• Stefanini SP 2005
• Tata Consultancy Services DF 2004
• Unisys MG 2005

Os melhores líderes aceitam a culpa e distribuem o crédito;

Os piores líderes distribuem a culpa e aceitam o crédito.

Pergunta:
A pouco tempo conseguimos o CMMI nível 2 e gostaria uma ajuda com algumas questões:

1. Que tipos de atividades PPQA poderia fazer após atingir o CMMI nível 2 (digo, a caminho do CMMI 3)? Considere que também estamos atrás de outros modelos de melhoria como ITIL, Lean e six sigma e gostaríamos de envolver o PPQA nisto.

2. Qual estratégia podemos seguir para demonstrar o valor do PPQA? Tenho dificuldade em mostrar os ganhos financeiros das destas atividades. Acredito que seria mais fácil a alta direção comprar a idéia vendo os ganhos financeiros.

Resposta:
A resposta da primeira pergunta é simples. Basta ler a área de processo de PPQA, GP 2.9. As atividades de PPQA incluem a execução de auditorias de processo e produto de trabalho do projeto e os processos da organização. Para o nível 2 de maturidade isso significa auditar os processos REQM, PP, PMC, SAM, MA, PPQA e CM. O envolvimento de PPQA em atividades relacionadas a Lean, ITIL e até Six Sigma vem naturalmente conforme sua organização for evoluindo. Não deixe de avaliar o CMMI-SVC e olhe com carinho o que o MPS.Br tem também.

A resposta da pergunta dois é um pouco mais complexa. Basicamente você esta perguntando “qual o custo da qualidade”. Um método que pode lhe ajudar é o “Crosby’s Cost of Quality Model”. Os custos se dividem em duas categorias: Custo da Qualidade e Custo da execução.

O custo da execução inclui coisas como: Planos, documentação, requisitos, projeto, código, integração, etc.

O custo da qualidade é dividido em duas categorias: Custo de conformidade e custo das não-conformidades.

O custo das não-Conformidades inclui corrigir defeitos, re-trabalho documentos, atualizar código fonte, re-revisões, re-testes, correções, mudanças, falhas externas e multas.

O custo da conformidade quebra em mais duas categorias: Custo da Avaliação e Custo de Prevenção.

O custo da avaliação inclui análises, orientações, testes (primeira vez), auditorias independentes e Auditorias.

O custo da prevenção inclui treinamento, políticas, procedimentos, ferramentas, planejamento, melhoria da qualidade, coleta de dados, análise de dados, análise de causa raiz e elaboração de relatórios de qualidade.

O custo de PPQA está incluído no custo da prevenção.

Quando PPQA audita os processos e produtos de trabalho, as auditorias irão revelar as não-conformidades das pessoas não seguindo o processo definido, o que leva ao retrabalho. Ao abordar estas não-conformidades, o objetivo é reduzir ou eliminar efetivamente o retrabalho. Este é o principal ponto que você pode demonstrar financeiramente, a redução do custo com retrabalho.

Este guia salarial oferece informações sobre os salários médios praticados pelo mercado brasileiro para profissionais das áreas de finanças, contabilidade, engenharia, marketing, vendas, tecnologia, bancos e seguros. Essas informações têm como base pesquisas e entrevistas conduzidas pelos especialistas em recrutamento da Robert Half; seu objetivo é ajudar as empresas na tomada de decisões em relação a questões salariais em contratações, promoções ou substituições.

As faixas salariais apresentadas para cada cargo representam a média nacional, sendo que esse número pode variar por região e também de acordo
com o tamanho da empresa. Os salários mencionados, exceto para o setor de bancos, não englobam bônus. Todos os valores representam o salário bruto mensal. Os salários de bancos englobam, na primeira coluna, o salário bruto mensal; na segunda coluna, o variável anual; e, na última coluna, a remuneração anual, somando o fixo com o variável.

Os valores relacionados a tecnologia estão abaixo:

Faça download do guia completo

• Download do Guia Salarial 2010 – 2011 – Brasil

Mais informações acesse: www.roberthalf.com.br

1. Lista de empresas CMMI no brasil
   A lista mais completa  e atualizada de avaliações CMMI das empresas brasileiras
   .
2. O que é CMMI?
   Uma visão geral do que é o CMMI para iniciantes. Veja também a versão melhorada – O que é CMMI II
   .
3. Tutorial mini projeto utilizando Análise de pontos por função
   Tutorial dividido em 3 partes, veja a Parte 1, Parte 2 e Parte 3
   .
4. Chaos Report: Como esta a TI no mundo
   Resumo do famoso relatório que mostra os principais desafios da TI no mundo e sucesso nos projetos.
5. 20 coisas que todo gerente de projetos deveria saber… e fazer
   Lista de 20 excelentes dicas que são úteis e primordiais no dia-a-dia de todo gerente de projetos
   .
6. As sete ferramentas da qualidade
   Conheça as sete ferramentas da qualidade e veja como usa-las em TI
   .
7. 16 atitudes que irão aumentar sua produtividade
   Lista 16 dicas muito boas para melhorar sua produtividade no dia-a-dia
   .
8. Uma visão geral sobre qualidade de software
   Excelente artigo onde falamos da qualidade de software em geral
   .
9. A ética e o gerenciamento de projetos
   Como anda a ética no gerenciamento de projetos? O que é ético, o que é esperado pelas pessoas? Veja estas respostas neste artigo
   .
10. Afinal de contas, o que é rastreabilidade?
    Visão prática do que é rastreabilidade de requisitos, o que os modelos esperam e algumas dicas.
    ..

Neste mês teremos uma boa notidade! Um sorteio. Acompanhe o Blog CMMI e não perca a oportunidade de participar.

O termo “gestão de riscos” cobre muitos diferentes tipos de riscos, incluindo riscos estratégicos, riscos financeiros, riscos de reputações, riscos operacionais, riscos de projetos, riscos ambientais, riscos legais, riscos de contratos ou riscos técnicos, bem como governância corporativa, continuidade dos negócios e recuperação de desastres. Enquanto cada área dessas possui suas próprias linguagens, processos e técnicas, existem princípios que se aplicam a todas elas.

Isso pode ser chamado de “leis universais de gestão de riscos”.

A primeira lei de gestão de riscos é que o risco é incerteza. Um risco é alguma coisa no futuro que pode ou não ocorrer. Isso é vital para uma compreensão adequada de risco e sua gestão. Riscos não existem ainda, na verdade eles podiam nunca existir.

Eles são eventos futuros potenciais ou conjunto de circunstâncias ou condições. Isso os faz bem diferentes de coisas que aconteceram no passado ou que atualmente existem no presente. Eventos do passado e do presente podem ser analisados e mensurados, mas eventos futuros podem ser somente imaginados ou estimados. Um risco que pode ou não pode existir no futuro, não pode ser vivenciado diretamente antes dele acontecer. Isso faz que os riscos sejam diferentes dos pontos de atenção, problemas ou restrições.

Em todo tipo de gestão de riscos, o risco está no futuro, e herda a incerteza.

A segunda lei é que o risco importa. Se ele ocorre, o risco terá consequencias que o torna diferente em algum aspecto. Não é possível ter um risco inconsequente, por definição. Enquanto vários tipos de gestão de riscos enfatiza os diferentes tipos de consequencia, todos concordam que um risco deve afetar alguma coisa. Isso é porque riscos são fortemente ligados aos objetivos. Onde quer que em algum campo do esforço humano esteja tentando alcançar alguma coisa, é possível identificar incertezas que podem afetar as chances do sucesso.

Se os objetivos são para alcançar a governança corporativa, projetos bem sucedidos ou continuidade de negócios, a gestão de riscos concentra-se na identificação de possíveis eventos futuros que poderiam influenciar estes objetivos, e permite que sejam compreendidos e gerenciados eficazmente.

A terceira lei é que a gestão de risco é um processo. Elas podem ter diferentes passos, mas todas as abordagens de gestão de riscos fornecem um framework que é desenhado para maximizar ambos eficiência e eficácia.

Embora os detalhes dos processos de riscos sejam diferentes, todo tipo de gestão de riscos tem duas partes importantes: análise e ação. Antes dos riscos serem gerenciados de maneira adequada, eles primeiro precisam ser identificados, descritos, compreendidos e avaliados. A análise é um primeiro passo necessário mas não é suficiente – ela precisa ser seguida pela ação.

Um processo de risco que não conduz a implementação de ações para lidar com riscos identificados é incompleto e sem utilidade. O último alvo é a gestão do risco, não simplesmente analisá-lo.

Finalmente, a quarta lei é que o risco é gerenciado por pessoas. Os aspectos humanos da gestão de riscos são vitais para seu sucesso e eficácia. As pessoas implementam os processos, embora usamos máquinas para automatizar os cálculos, para armazenar os resultados ou para gerar os relatórios. Pessoas configuram os limites dos riscos, identificam os riscos, avaliam o grau de incerteza e a extensão dos possíveis impactos, propõem respostas apropriadas e implementa as ações negociadas. Isso requer julgamentos, estimativas e decisões para serem feitos na presença da incerteza. Estes julgamentos são assuntos para uma gama de influências, ambas explícitas e ocultas, que podem significativamente afetar o resultado.

A gestão de riscos em cada nível está exposta a fontes surgindo de influências patentes ou veladas, agindo nos indivíduos e grupos que estão tentando tomar decisões baseadas em riscos com informações imperfeitas ou incompletas.

Independente dos tipos de riscos que enfrentamos, temos que seguir essas leis universais de gestão de riscos. Para gerenciar os riscos de maneira eficaz precisamos lidar com as incertezas que importam, seguir um processo estruturado, e levar em conta os aspectos pessoais.

[Projeto Diário]

Pergunta: Boa noite, gosto muito do seu blog, ele tem me ajudado muito.
Na empresa onde trabalho praticamos Agile em quase todos os projetos. A equipe é bem empenhada e a maioria dos nossos projetos vai bem. De uns tempos pra cá começamos a pensar em “certificar” ou no CMMI ou no MPS.Br e o que ajudou muito foi que a diretoria solicitou um estudo neste sentido.

Achamos alguns artigos falando do uso do Agile com CMMI, e alguns destes dizem que o Agile cola bem no CMMI chegando bem até o nível 3. Vi no seu site também um gráfico que mostra isso.

Agora vem as nossas perguntas:

1. Seguimos o Agile muito bem, como o Agile é bem aderente ao CMMI, podemos tomar como verdade que teremos poucos ajustes para conseguir o CMMI nível 3.
2. Da para ir direto para uma avaliação nível 3?
3. Temos pouco ou muito trabalho pela frente?
4. Quais os próximos passos que devemos seguir?

Pergunta de Mariana Catalone – São Paulo

Resposta: Olá Mariana, tive que resumir um pouco sua pergunta, mas a essência esta ai.
No passado havia muita muita discussão em torno de Agile com CMMI. Os agilistas de plantão viam o CMMI como oposto de sua cultura, porém, isso vem mudando e hoje em dia há muitas empresas que adaptam seus “métodos” Agile ao modelo CMMI. O ponto de mudança foi o artigo CMMI or Agile: Why not embrace both! publicado pelo SEI em 2008.

da pra dizer quão próximo do CMMI nível 2 ou CMMI nível 3 você esta sem uma avaliação.

Cada empresa implanta Agile de um jeito diferente da outra. É como o RUP, é muito comum alguém comentar: “Nossa metodologia segue o RUP com algumas customizações” – O perigo esta justamente nas benditas customizações, pois muitas vezes retira-se elementos essenciais por simples falta de compreensão dos mesmos. Vamos ao caso de riscos… a primeira vista as pessoas acham confuso porém, todo mundo que tem carro sabe o risco de ter seu carro danificado ou roubado, e para isso faz um seguro. Um projeto tem um conjunto enorme de riscos… quantos gerentes fazem mesmo gerenciamento de riscos?

Então… a primeira coisa a ser feita na sua empresa seria um Gap Analisys. Esta avaliação deve ser feita por alguém externo a sua empresa justamente para ser totalmente imparcial e independente. Com esse resultado você saberá se tem muito ou pouco trabalho pela frente.

Lembre-se que o Agile não endereça diversas áreas de processo do CMMI como SAM, RSKM, OPD, OT e outras… você deve ter especial atenção à estas áreas.

Sobre ir direto para o nível 3 da sim… na verdade o SEI não coloca nenhuma restrição quanto a isso, mas você obterá resultados mais sólidos evoluindo de nível em nível. Lembre-se do M de maturidade. Maturidade se consegue com o tempo.

Em tempo: Lembre-se que o CMMI é um conjunto das melhores práticas de gestão e engenharia de software. Ele não te diz como fazer, apenas o que deve ser feito, e… segundo o SEI, grande parte das empresas que o usam, tem obtido ótimos resultados financeiros.

Pergunta: Estou procurando informações sobre as responsabilidades do patrocinador em uma avaliação CMMI.

Minha organização está se preparando para uma avaliação CMMI SCAMPI A e eu gostaria de fornecer ao patrocinador um resumo de seu papel e o que é esperado dela em uma avaliação como revisar e assinar o plano de avaliação, participando da abertura e briefings, resultados etc.

Resposta: Parece que você tem boa compreensão das funções do patrocinador da avaliação. Seria bem útil você fazer essa pergunta de seu avaliador para ver se ele tem algum pedido específico para o patrocinador da avaliação.

O patrocinador da avaliação CMMI ou MPS.Br deve:

1. Prover recursos e fundos para o programa de melhoria de processos e sua avaliação
2. Não deve participar da equipe de avaliação
3. Se reunir pelo menos uma vez com o avaliador para discutir a avaliação
4. Fornecer os objetivos de negócio da organização
5. Assinar o plano da avaliação e documentos afins.
6. Participar da abertura e reforçar a razão pela qual a avaliação esta sendo realizada e a importância da participação de todos
7. Se reunir com a equipe de avaliação antes da apresentação de conclusões, receber os resultados e preparar a mensagem apropriada para a organização
8. Assistir a apresentação final de resultados, agradecer a equipe de avaliação e a toda organização independente do resultado. Se o resultado for mal, transformar em uma declaração positiva de encorajamento, etc.
9. Preencher o formulário de feedback para o SEI ou Softex
10. Receber o resultado e mantê-lo pelo menos por três anos
11. Não divulgar publicamente os resultados até a audotiria do SEI ou Softex autorizar.

Pergunta: Porque o Gerenciamento de requisitos (REQM) é do CMMI nível 2 e o Desenvolvimento de requisitos é do CMMI nível 3? Nos desenvolvemos os requisitos primeiro para só depois gerencia-los.

Resposta: Esta pergunta é mais comum do que parece, vez ou outra recebo perguntas similares.

Para responde-la temos que compreender o sentido de cada nível. O CMMI nível 2 trata de estabilizar o projeto, implementar gerenciamento e ganhar controle sobre o mesmo e suas estimativas. Em um programa de melhoria de processos de software, a primeira coisa que deve ser implementada é gestão. Assim que uma organização alcança este objetivo ela pode iniciar as análises de como melhorar as áreas de engenharia de software.

Vamos ver as áreas de processo do CMMI nível 2:

• Gerência de configuração
• Medição e Análise
• Planejamento
• Monitoramento e controle
• Gerenciamento de requisitos
• Gerenciamento de acordos com fornecedores

Note que todas elas tratam do mesmo assunto – Gestão.

Então… a resposta é: Porque estas duas áreas de processo tem focos distintos. Você deve saber o que deve ser feito, quando, qual o esforço, qual o custo para depois evoluir o “como será feito”.

Em tempo: tenha em mente que o CMMI é uma coleção das melhores práticas de gestão e engenharia de software. E ele vem evoluindo desde que foi criado. Ele não é um roadmap para “como fazer engenharia de software” e … o mais comum e conhecido… ele te fala O QUE você deve fazer… o COMO fica por sua conta.

Agir corretamente hoje não é só uma questão de consciência. É um dos quesitos fundamentais para quem quer ter uma carreira longa e respeitada. Em escolhas aparentemente simples, muitas carreiras brilhantes podem ser jogadas fora. Atualmente, mais do que nunca, a atitude dos profissionais em relação às questões éticas pode ser a diferença entre o seu sucesso e o seu fracasso. Basta um deslize, uma escorregadela, e pronto. A imagem do profissional ganha no mercado a mancha vermelha da desconfiança.

Ser ético é uma característica fundamental. Cada vez mais as organizações estão adotando o hábito de checar o passado dos candidatos a alguma vaga. Quem tem a ficha limpa sempre terá as portas abertas nas melhores empresas do mercado. Mas afinal, como é esse profissional?

Ser ético nada mais é do que agir direito, proceder bem, sem prejudicar os outros. É ser altruísta, é estar tranqüilo com a consciência pessoal. É também agir de acordo com os valores morais de uma determinada sociedade.

“Ética é a teoria ou ciência do comportamento moral dos homens em sociedade”.
Adolfo Vasquez

Qualquer decisão ética tem por trás um conjunto de valores fundamentais. Entre eles: ser honesto em qualquer situação, ter coragem para assumir decisões, ser tolerante e flexível, ser íntegro, educado, fiel, humilde e prudente.

Empresas não são apenas entidades jurídicas, elas são formadas por pessoas e só existem por causa delas. Por trás de qualquer decisão, de qualquer erro ou imprudência, estão seres de carne e osso. E são eles que vão viver as glórias ou os fracassos da organização. Quanto mais uma organização se destaca no mercado, mais se deve preocupar com as relações éticas. Errar é humano, mas falhas éticas destroem carreiras e organizações.

Para saber se uma empresa é ou não ética é preciso verificar a maneira como ela se planeja e cria soluções para evitar deslizes e problemas. Prevenção é a palavra de ordem em qualquer organização que valorize a ética nos seus negócios e no ambiente de trabalho.
Ética gera questões extremamente delicadas e, na maioria das vezes, de foro íntimo. Não existe uma receita universal, pronta e completamente eficaz para resolver essas questões. A decisão sempre varia de pessoa para pessoa, de consciência para consciência. Cada um tem seus limites, impostos por suas crenças e pelas leis, e deve seguí-los.

O que fazer para andar com um pouco mais de segurança nesse terreno nebuloso? Eis algumas estratégias:

1. Não faça nada que não possa assumir em público.
2. Avalie detalhadamente os valores da sua empresa. Certifique-se de eles combinam com os seus.
3. Trabalhe sempre com base em fatos. Não julgue baseando-se em suposições.
4. Avalie os riscos de cada decisão que tomar. Meça, cuidadosamente, as conseqüências do seu ato em relação a todos os envolvidos.
5. Uma empresa ética exige não apenas produtos e serviços de qualidade, mas também de conteúdo ético: recolher impostos, remunerar dignamente, preservar a ecologia, o meio ambiente, interagir com lealdade e participar da comunidade.
6. Saiba ouvir. É aconselhável ouvir mais do que falar, especialmente em se tratando de reclamações e consultas de clientes.
7. Trabalhe bem com os temas polêmicos: todas as promessas ao cliente com relação a atendimento e prazos, inclusive as mais informais, devem ser rigorosamente cumpridas.
8. Evite rivalidades. É necessário cultivar boas relações dentro e fora das equipes.
9. Nunca se esqueça que ninguém negocia com empresas, mas com as pessoas das empresas. O caráter da empresa é o caráter que seus empregados têm.
10. Evite clientelismos, privilégios e deixar vazar informações. Também é ético assegurar-se de que as informações foram claras, completas, transparentes e bem recebidas pelo outro.
11. Não fume onde esta prática é proibida e apresente-se sóbrio ao trabalho.
12. Planeje suas ausências no ambiente de trabalho, sempre que possível, de modo a permitir fluxo normal das responsabilidades.
13. Demonstre interesse pelo próprio desenvolvimento, participando de reuniões, encontros e eventos de formação, treinamento e desenvolvimento.
14. Seja pontual em termos do horário de trabalho. Observe políticas, normas e procedimentos.
15. Zele pelo bom nome da empresa. Comunique-se, relacione-se, aja de forma irrepreensível, dentro e fora da organização.
16. Aja de modo participativo, compartilhado, de modo que um problema em qualquer ponto da organização seja responsabilidade de todos e de cada um.
17. Tenha moral elevado e contribua para manutenção do clima de trabalho em alto nível.
18. Zele pelo bom nome dos colegas. Varra de sua vida a fofoca.
19. Não se omita. Assuma seus erros. Quando perceber alguma coisa errada, procure ajudar a consertar.
20. Informações confidenciais não devem sair da empresa em hipótese alguma.

Ser e manter-se um profissional ético não é fácil de administrar, principalmente para nós brasileiros que fomos criados sob a ética da lei de Gerson, do jeitinho, da vantagem acima de tudo. Socialmente aprendemos que é preciso fazer o correto, mas na informalidade impera a idéia de que não há nada de errado em levar vantagem. Há corruptos em outros lugares do mundo, mas no Brasil pequenos delitos são apoiados e até elogiados por amigos e pela família.

Agir eticamente sempre foi e será uma decisão pessoal. Nunca se esqueça, porém, de que esse costuma ser um caminho sem volta. Para o bem ou para o mal.

[Sonia Jordão]

Semana passada um comentário no Twitter me chamou muita atenção. O comentário era o mesmo do título deste post: “Alguém sabe se alguma empresa usa de verdade o MPS.Br?”.

Vamos desconsiderar o equivoco em uma pergunda como esta e entender o que é o tal do MPS.Br. Como vocês já devem saber, o MPS.Br é um modelo de melhoria de processos de software muito similar ao CMMI, mas criado e mantido por brasileiros (Softex).

E assim como o CMMI, o MPS.Br nada mais é do que um conjunto de boas práticas de engenharia de software e gestão. Ele fala o que deve ser feito, mas não como fazer, até porque cada empresa tem sua realidade e pode implementar uma determinada prática de um jeito. O plano do projeto por exemplo pode ser um doc, pode ser sistematizado, pode ser dividido em vários documentos e sistemas, enfim, pode ser do jeito que a empresa achar melhor, ela deve apenas seguir as recomendações que o MPS.Br pede.

Estas recomendações são boas práticas de engenharia de software e gestão, e a empresa pode implementa-las ou não, todavia, para obter o certificado MPS.Br nível X, a empresa deve implementar todas as práticas do nível que deseja. E esta implementação deve ser aprovada por um avaliador MPS.Br.

Agora que já tiramos algumas dúvidas, vamos responder a pergunta… O que você acha?
Alguma empresa usa de verdade o MPS.Br?

A resposta é objetiva. Claro que sim, aliás não apenas as “empresas avaliadas”.

Diversas empresas que sequer pensam em passar por uma avaliação MPS.Br, realizam diversas de suas práticas.

A estimativa de um plojeto, planejamento, identificação de requisitos, integração, controle de qualidade e outras coisas não nasceram no MPS.Br ou no CMMI. Eles já existiam a muito tempo, bem antes até da existência de computadores.

Vamos a algumas observações:

• Se em sua empresa você tem um PMO, certamente você já faz muita coisa de gerenciamento de projetos, gerenciamento de riscos, planejamento e acompanhamento de projetos.
• Você trabalha em uma área de desenvolvimento de software, então, provavelmente você já faz várias práticas dos processos de engenharia de software.
• É muito provável que em sua empresa diversas práticas de estimativa já estejam implementadas e institucionalizadas (você deve estimar para poder vender, certo?).
• Não precisamos falar muito do processo de validação certo? Seu cliente ou usuário provavelmente valida os trabalhos.
• Se vocês usam sharepoint, subversion ou até mesmo o Microsoft Source Safe, provavelmente você também executa várias práticas do processo de Controle de Configuração.

Enfim… estes são alguns exemplo de “uso do MPS.Br”, ou vamos simplificar para “uso de boas práticas de engenharia de software e gestão”.

Tipicamente uma área de desenvolvimento de software já atende várias práticas do modelo, a abrangência obviamente varia de uma empresa para outra. Um consultor vai ajudar a eliminar enganos de entendimento, ficar aderente ao modelo e consequentemente melhorar os resultados da empresa.

E você… o que acha?

Olá pessoal, em TI a cada dia cria-se um novo termo e sempre fica a dúvida “O que é isso?”. Bom, como situações como esta são muito comuns, resolvemos compilar uma lista dos termos mais comuns.

Glossário de termos comuns em TI

Ação Corretiva
Ação realizada para eliminar um problema, não conformidade ou situação indesejada a fim de evitar sua repetição.

Ação Preventiva
Ação realizada evitar a ocorrência de um possível problema, não-conformidade ou defeito.

Agile
Modelo de desenvolvimento de software focado nas pessoas. Não há processos definidos, guias ou instituto certificador. A motivação e o cliente são aspectos primordiais nos métodos ágeis, todavia, praticar Agile é mais uma questão de cultura do que guias e processos.

Análise Crítica de Projeto
Análise completa e sistemática de um projeto a fim de avaliar sua capacidade de atender os requisitos para a qualidade, identificar problemas, se houver, e propor o desenvolvimento de soluções.

Análise de Pontos por Função
Técnica de estimativa de sistemas, também conhecida como FPA – Function Point Analysis, baseada na identificação das funções executadas pelos programas, ao invés de utilizar como base o volume ou a complexidade do código dos programas.
A técnica está baseada na visão externa do usuário, sendo portanto, independente da linguagem utilizada, permitindo calcular o esforço de programação e auxiliando o usuário final a melhorar o exame e avaliação de projetos.

Análise de Requisitos
Conjunto de atividades que permite identificar as necessidades do usuário de modo a obter uma definição clara das características (requisitos) de um sistema. Essas características descrevem o sistema em termos de funcionalidades, desempenho esperado, restrições de projeto, níveis de qualidade esperados, interface com outros elementos do sistema.

Auditoria
Verificação sistemática e independente, para determinar se as atividades da qualidade e seus resultados estão de acordo com o planejado, se foram implementadas com eficácia e se são adequadas.

Certificação
Modo pelo qual uma organização independente dá garantia escrita de que um produto, processo ou serviço está em conformidade com os requisitos especificados.

CMMI – Capability Maturity Model Integration
Modelo para avaliação da maturidade dos processos de software de uma organização e para identificação das práticas chave que são requeridas para aumentar a maturidade desses processos.

Confiabilidade
Conjunto de atributos que evidenciam a capacidade do software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo estabelecido.
Tem como subcaracterísticas: maturidade, tolerância a falhas e recuperabilidade.

Configuração
Relação entre versões de um objeto, ou seja, configuração é uma instância do sistema composta da união de uma versão específica de cada objeto componente. Arranjo de um sistema ou de seus componentes como definidos pelo seu número, natureza e interconexão de suas partes constituintes.

Controle de Versão
Procedimento de gestão do ciclo de vida de um produto. Consiste na identificação formal de modificações solicitadas ou efetuadas e no seu agrupamento, de modo a que fiquem incorporadas, todas elas, em uma determinada configuração do produto, num certo momento. Essa configuração recebe o nome de versão.

Custos da Qualidade
Custos relacionados com as perdas em função da qualidade insuficiente de processos, produtos ou serviços (custos da não-conformidade) ou com os investimentos em atividades que eliminem falhas ou elevem a qualidade de processos, produtos ou serviços (custos da conformidade). A identificação e a apropriação contábil desses custos permite que o administrador possa fazer uma análise do nível de qualidade de sua produção e possa tomar decisões para melhorar esse nível.

Declaração de Conformidade
Declaração, emitida pelo fornecedor ou pelo produtor de um software, assegurando que este opera em conformidade com certas normas ou especificações preestabelecidas.

Depurador Interativo
Software para apoio a testes, cuja função é permitir a visualização passo a passo da execução de uma rotina ou programa e do comportamento de seus elementos antes, durante e após a execução.

Dicionário de Dados
Listagem organizada de todos os elementos de dados que são pertinentes ao sistema, com definições precisas e rigorosas, de forma que tanto o usuário como o analista de sistemas tenham uma compreensão comum das entradas, das saídas, dos componentes dos depósitos de dados.

Driver de Teste
Software que permite a ativação de determinadas partes do software (módulos) com o intuito de testá-las. Normalmente, utilizam-se massas de teste previamente definidas e produzem resultados do teste, que podem ser verificados através da documentação de teste construída pelo analista ou engenheiro de software responsável pelos testes.

Eficiência
Conjunto de atributos que evidenciam o relacionamento entre o nível de desempenho do software e a quantidade de recursos usados, sob condições estabelecidas. Tem como subcaracterísticas: comportamento em relação ao tempo e comportamento em relação aos recursos.

Engenharia da Informação
Popularizada por James Martin, é um caminho direcionado a dados para desenvolvimento de sistemas de informação, oposto à visão de direcionamento a processo de análise estruturada.

Entidade Certificadora
Órgão que realiza a certificação de conformidade, a partir da existência da garantia adequada de que um produto, processo ou serviço, devidamente identificado, está em conformidade com uma norma ou outro documento normativo especificado.

Garantia da Qualidade
Conjunto de atividades planejadas e sistemáticas, implementadas no sistema da qualidade e demonstradas como necessárias para prover confiança adequada de que uma entidade atenderá os requisitos para a qualidade.

Gerência de Projetos
Processo que tem início antes do trabalho técnico, prossegue à medida que o software se desenvolve do modelo conceitual para o modelo computacional e encerra somente quando o software se torna obsoleto.

Gerência de Requisitos
Estabelecimento e manutenção de um entendimento/acordo com o cliente sobre os requisitos para o projeto de software. Este acordo refere-se aos requisitos do sistema alocados para o software. O cliente pode ser interpretado como o grupo de engenharia do sistema, o grupo de marketing, outra organização interna, ou um cliente externo. O acordo compreende requisitos técnicos e não técnicos. O acordo forma a base para a estimativa, planejamento, execução e acompanhamento das atividades do projeto de software através do ciclo de vida do software.

Gerenciamento de Configuração (Software Configuration Management – SCM)
Atividade abrangente que é aplicada em todo o processo de engenharia de software, podendo ser vista como uma atividade de garantia da qualidade de software. Uma vez que uma mudança pode ocorrer a qualquer tempo, as atividades de SCM são desenvolvidas para identificar a mudança; controlar a mudança; garantir que a mudança esteja sendo adequadamente implementada; e relatar a mudança a outras pessoas que possam ter interesse nela. O gerenciamento de configuração de software é um conjunto de atividades que foi desenvolvido para administrar as mudanças em todo o ciclo de vida do software.

Gestão da Qualidade
Todas as atividades da função gerencial que determinam a política da qualidade, os objetivos e as responsabilidades, e os implementam por meios tais como: o planejamento da qualidade, o controle da qualidade, a garantia da qualidade e a melhoria da qualidade dentro do sistema da qualidade.

Gestão de Configuração
Atividade técnica e gerencial aplicada ao longo de todo o ciclo de vida do software que tem por objetivo garantir a integridade do produto sendo desenvolvido, mantendo um histórico de todos os itens sob controle. Basicamente, é composta de quatro tarefas: identificação da configuração, controle da configuração, balanço da configuração e auditoria da configuração.

ISO
International Organization for Standardization (Organização Internacional de Normalização).

ISO 9001
Quality systems – Model for quality assurance in design, development, production, installation and servicing.
Norma internacional da série ISO 9000. Modelo para garantia da qualidade em projetos, desenvolvimento, produção, instalação e serviços associados.É mais completa que as normas ISO 9002 e ISO 9003, da mesma série.

ISO/IEC 12207
Information technology – Software life cycle process.

ISO/IEC 15504
Information technology – Software process assessment.
Norma internacional para avaliação de processos de software, deselvolvida pelo projeto SPICE (Software Process Improvement and Capability dEtermination), o que a torna conhecida também como Modelo SPICE. Define um modelo de referência com processos e níveis de capacidade, orientações sobre como utilizá-lo para melhoria contínua ou determinação da capacidade, e um modelo exemplo compatível .

Lead Appraiser
Avaliador oficial SEI. Responsável por avaliações oficiais CMMI. Há também o High Maturity Lead Appraiser, que é o avaliador que pode realizar avaliações CMMI 4 e CMMI 5.

Medição de Linhas de Código (LOC)
É a métrica de código mais básica. A definição mais comum de LOC estabelece que qualquer linha do programa que não seja comentário ou linha em branco, independente do número de sentenças (lógicas ou operações) estão presentes naquela linha.

Melhoria de Processos de Software (Software Process Improvement)
Uma abordagem (SPI) para melhoria das organizações que desenvolvem e mantêm software. É baseada na melhoria da capacidade de processos fundamentais para organizações de software. Utiliza como referência um modelo de processo, como por exemplo, o CMM e a ISO/IEC 15504-SPICE.

Métrica de Qualidade de Software
Método e uma escala quantitativa que podem ser usados para determinar o valor que uma particularidade (feature) recebe em um produto de software específico.

MPS.Br
Modelo de melhoria de processos de software brasileiro muito similar e aderente ao CMMI porém com algumas diferenças como 7 níveis e novas áreas de processo (chamado pelo MPS.Br apenas por processo).

Peer-review
Técnica de revisão de um produto, na qual um colega (peer) do projetista ou do programador revisa o produto desenvolvido, buscando encontrar erros ou oferecer sugestões de melhoria.

Política da Qualidade
Intenções e diretrizes globais de uma organização relativas à qualidade, formalmente expressas pela alta administração.

Processo
Conjunto de recursos e atividades inter-relacionadas que transformam insumos (entradas) em produtos (saídas). Agrupamento em seqüência de todas as tarefas destinadas a obter um determinado resultado. É a combinação de equipamentos, instalações, mão-de-obra, métodos, técnicas, ferramentas, procedimentos e outros fatores, com a finalidade de elaborar um produto ou alcançar um resultado preestabelecido.

Processo de Software
Conjunto de atividades, métodos, práticas e transformações que as pessoas empregam para desenvolver e manter software e os produtos associados (por exemplo, planos de projeto, documentos de projeto/design, código, casos de teste, manual do usuário).

Programação Orientada a Objetos
Técnica de programação que enfatiza a descrição dos conceitos envolvidos com o domínio do problema (objetos) através de seus dados e operações, encapsulados e representados através de classes. Cada objeto é criado como pertencendo a uma classe. A utilização de um objeto, e sua eventual mudança de estado, se dá a partir de mensagens enviadas a ele, representadas pelas operações encapsuladas na classe. Novas classes podem ser criadas a partir de classes existentes e organizadas através de um processo de classificação e hierarquização, explorando o conceito de herança.Os programas são construídos como organizadores da ativação de mensagens para os objetos, desta forma fazendo com que as funcionalidades de um sistema sejam obtidas através da cooperação dos objetos.

Projeto de Software
Envolve tipicamente análise, especificação, projeto (design), desenvolvimento, teste e/ou manutenção dos componentes de software e da documentação associada.

Prototipação
Método de desenvolvimento que prevê a execução de vários ciclos de análise, especificação e codificação de um sistema.No primeiro ciclo, gera-se um produto simplificado em pouco tempo, de modo que o usuário possa examiná-lo e refinar as suas demandas.Nos ciclos seguintes, o produto é aperfeiçoado e novas funções são sucessivamente implementadas, até se chegar ao produto final.

QFD – Quality Function Deployment
Técnica de planejamento e de especificação de requisitos que consiste em reuniões com técnicos e clientes, nas quais são elaboradas matrizes em que se cruzam informações sobre “o que” é desejado (requisitos) e “como” implementar. É composta por quatro etapas – projeto, componentes, processo e produção, sendo gerada a cada etapa uma matriz, a partir da matriz anterior.As matrizes explicitam relações, conflitos, níveis de dificuldade, estágio tecnológico. Por seu formato peculiar, a matriz do QFD é conhecida como “casa da qualidade”.

Qualidade
Totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas. Entidade pode ser uma atividade ou um processo, um produto, uma organização ou uma combinação desses.

Reengenharia de Software
Técnica de restruturação ou modificação de um código existente, ou de desenvolvimento de um novo código, preservando-se inalterada a especificação ou o projeto do software.

Requisitos
Necessidades básicas do cliente, geralmente explicitadas como condição de negócio no contrato com o fornecedor. São características, tais como especificações técnicas, prazo de entrega, garantia, que o cliente “requer” do produto. Uma condição ou capacidade necessitada por um usuário, para resolver um problema ou alcançar um objetivo.

Requisitos para a Qualidade
Expressão das necessidades ou sua tradução num conjunto de requisitos, explicitados em termos quantitativos ou qualitativos, objetivando definir as características de uma entidade a fim de permitir sua realização e seu exame.

Reuso de Código
Técnica de utilização de um programa, de uma rotina ou de uma biblioteca de rotinas em mais de uma aplicação, ou em diferentes implementações de uma aplicação. Para tal, o código deve ser escrito prevendo-se a sua reusabilidade e enfatizando aspectos de sua abrangência funcional e de independência de ambiente.

SPICE – Software Process Improvement and Capability dEtermination
Projeto estabelecido em junho de 1993 pela ISO/IEC JTC1/SC7 (Subcomitê de Engenharia de Software) com três objetivos principais: auxiliar o desenvolvimento de uma Norma Internacional para avaliação de processos de software; coordenar e analisar utilizações desta futura Norma para subsidiar revisões antes de sua publicação como norma (esta atividade é chamada de SPICE Trials); e disseminar a futura norma no mercado. A norma desenvolvida é a ISO/IEC 15504 que está publicada atualmente com relatório técnico da ISO/IEC. Já foram realizadas duas fases do SPICE Trials, com dados sobre cerca de 100 utilizações da futura norma e a fase 3 está em andamento.

Six Sigma
Modelo para melhoria de processos com base em dados e fatos. Utiliza o método DMAIC e é largamente usado por toda industria. É pouco utilizado em TI, normalmente é praticado nas organizações de alta maturidade.

Teste de Aceitação
Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente determinar se aceita ou não o sistema. Validação de um software pelo comprador, pelo usuário ou por terceira parte, com o uso de dados ou cenários especificados ou reais.Pode incluir testes funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.

Teste de Campo
Verificação de um software ou um trecho de software durante a sua utilização real (em campo), de modo a detectar, confirmar ou examinar falha ou erro relatado.

Teste de Integração
Técnica sistemática para a construção da estrutura de programa, realizando-se ao mesmo tempo, testes para descobrir erros associados a interfaces. O objetivo é, a partir dos módulos testados no nível de unidade, construir a estrutura de programa que foi determinada pelo projeto. O teste de integração cuida das questões associadas aos duplos problemas da verificação e construção de programas.

Teste de Sistema
Processo de testar um sistema integrado de hardware e software para verificar se o sistema satisfaz seus requisitos especificados.

Teste de Unidade
Verificação de um componente de um software, através de teste funcional, desenvolvido a partir da especificação das funções previstas para o componente, ou de teste estrutural, desenvolvido a partir da descrição da estrutura do componente.

Teste de Usabilidade
Verificação e homologação individual do uso por um conjunto de usuários.

Teste Funcional
Teste conduzido para demonstrar a operacionalidade das funções que foram especificadas. O teste funcional (ou caixa-preta) é realizado olhando-se o software apenas através de suas interfaces, portanto testando sua funcionalidade.

Validação
Confirmação, por exame e fornecimento de evidência objetiva, de que os requisitos específicos para um uso pretendido são atendidos. Informações cuja veracidade pode ser comprovada com base em fatos obtidos através da observação, medição, ensaios ou outros meios constituem evidência objetiva.

Verificação
Confirmação, por exame e fornecimento de evidência objetiva, do atendimento aos requisitos especificados. Processo de avaliação de um sistema (ou componente) com o objetivo de determinar se o produto de uma dada fase do desenvolvimento satisfaz às condições impostas no início dessa fase.

Walkthrough Estruturado
Técnica de análise estática na qual um projetista ou programador apresentam aos membros do grupo de desenvolvimento e outros profissionais interessados uma parte de documentação ou código, e os participantes fazem perguntas e comentários sobre possíveis erros, violação de padrões de desenvolvimento ou sobre outros problemas

Excelente vídeo de Daniel Godri sobre motivação mostrando como é o nosso dia-a-dia e as pressões que recebemos.

Muito bom!

Atualmente, 227 empresas brasileiras estão certificadas em algum nível do modelo de qualidade em desenvolvimento de software MPS.BR, número de deve chegar a 300 até o final do ano.

Por outro lado, nenhuma organização tem a versão do selo destinada a orientar a aquisição de desenvolvimento, voltada para compradores de TI.

Buscando alterar essa realidade, a Softex, organização ligada ao governo federal que promove o modelo de qualidade brasileiro, modificou o modelo de negócios de consultoria para chamado modelo de aquisição do MPS.BR.

Como já acontece na área de desenvolvimento de software, a entidade vai credenciar empresas e instituições interessadas em oferecer consultoria para os compradores. Até agora, a difusão neste segmento acontecia por meio de consultores pessoa física.

“Vamos trabalhar para convencer as consultorias já presentes no mercado de fazer o investimento e atuar no lado da compra”, explica José Antonio Antonioni, diretor de Qualidade e Competitividade da Softex.

O objetivo é ter cinco consultorias credenciadas no Brasil até o final do ano. A título de comparação, na área de desenvolvimento de software só Rio Grande do Sul já tem três:  PUC-RS, Software Process e Engesoft.

Antonioni destaca que a ideia é atingir a compradores tanto no setor público como o privado, mas os reposáveis pelas compras governamentais de software são um destinatário óbvio da nova oferta.

Em 2007, o Tribunal de Contas da União recomendou a adoção do MPS.BR entre os requisitos de licitação e a contratação de serviços de TI.

Desde então, alguns órgãos públicos já usaram o MPS.BR como critério, entre eles a gaúcha Procergs na licitação da fábrica de software vencida pela Stefanini – uma empresa MPS.BR nível A, o grau máximo – em maio de 2009.