Como Minimizar o Impacto Cultural na Implantação da Fase G do MPS.BR em uma Pequena Empresa

Trabalho de Conclusão de Curso em Administração de Empresas com foco em Gestão de Negócios por Aline Ferraresi Nascimento Hirayama (dez/2008).


Para as empresas que buscam a melhoria no relacionamento com seus clientes, maiores vantagens competitivas, aumento no número de profissionais especialistas, aumento na produtividade, abertura novos mercados e parcerias fortes, o caminho é a excelência em processos, o que pode ser alcançado com foco no padrão MPS.BR. Porém, implantar o processo apresenta alguns desafios, principalmente por se tratar de pessoas. Com um líder dentro do perfil desejado, com foco no desenvolvimento das habilidades dos profissionais e na comunicação, aumenta-se as chances do comprometimento sincero.

I.  INTRODUÇÃO

O desenvolvimento tecnológico brasileiro teve um cenário particular ao do resto do mundo. Protegendo o país de um bombardeio de tendência de alta tecnologia dos países desenvolvidos, como Japão e Estados Unidos, o governo do Brasil intentava um desenvolvimento próprio de software e hardware, visando uma alta capacitação científico-tecnológica para sustentar demanda tanto nacional quanto externa.

Para essa finalidade, foi implantada a SEI (Secretaria Especial de Informática) que gerou reserva de mercado no setor em 1984 sob a Lei Federal nº 7.232/84. Entre os incentivos naquela Lei se encontravam:

- Preferência nas compras governamentais de bens e serviços da área à indústria nacional.

- Isenção de impostos de importação de equipamentos, máquinas e componentes, como o IPI (imposto sobre produtos industrializados), IE (imposto de exportação) e o II (imposto de importação).

- Isenção nas operações de crédito, câmbio e seguro.

- Dedução dobrada das despesas operacionais no IRPJ.

- Depreciação acelerada de bens.

- Prioridade nos financiamentos governamentais. (NAZARENO, 2004, pg. 4)

A Lei também impedia a importação de produtos com similar nacional e garantia á empresas produtoras brasileiras exclusividade na comercialização de hardware e software. Mas este método não se mostrou eficiente ao longo do tempo, como descrevem Duarte e Branco (2001):

Mesmo naqueles casos onde não existia similaridade, a importação poderia ser bastante demorada. O mercado interno ainda era incipiente, com o consumo de software se restringindo a produtos, e o consumo de hardware limitado a equipamentos de pequeno porte produzidos no país ou a importados de médio e grande porte.

E Meira (1993 apud Duarte e Branco, 2001) continua:

A política de reserva de mercado resultou não só em um parque de hardware carente das últimas inovações tecnológicas, mas também em um segmento de software que se ressentia da falta de fontes de fomento e financiamento. [1]

A aderência a essa política de reserva de mercado teve também impactos na mentalidade do empresariado brasileiro dando a idéia de um governo protecionista, o que agravou o atraso tecnológico e manteve todo o parque industrial com baixos níveis de eficiência e pouco competitivo. (SUZIGAN, 1988, pg.6)

A reserva de mercado teve fim efetivo em outubro de 1992, deixando o setor tecnológico sem base institucional mínima quanto à fabricação, desenvolvimento e comercialização de bens e serviços.[2] (TIGRE, 1993, apud GARCIA e ROSELINO, 2002). Outras Leis entraram em vigor a partir desde ano na tentativa de estimular o setor, de acordo com Anexo 1.

Enquanto isso, no começo dos anos 90, o setor industrial brasileiro em geral vivia um momento de "precipício hiper-inflacionário" com a abertura de mercado, onde as empresas corriam grande risco de endividamento e procuraram não fazer grandes investimentos em sua produção – pelo contrário, incentivavam cortes e mudanças organizacionais –; e os consumidores, aturdidos pela alta desenfreada de preços, não conseguiam usufruir o aumento da competição.

Entre as mudanças organizacionais adotadas entre 1989 e 1994 se encontram, destacadamente, o início da adoção de práticas gerenciais associadas à Gerência da Qualidade Total (TQM) e certificação nas normas da ISO. Lembrando que essas ações gerenciais objetivavam redução de custos e não uma modernização sob forma de aquisição de máquinas e equipamentos – o que trouxe pouca renovação em termos de produtos e mercado. (CASTRO, 2001)

Neste período de mudanças e aderência à práticas relacionadas a qualidade, o governo cria o Projeto DESI (Desenvolvimento Estratégico da Informática) que incorporava dentre seus projetos o Programa Nacional de Software para Exportação, a SOFTEX, que tinha como objetivo fomentar e apoiar atividades de inovação e desenvolvimento científico e tecnológico de geração e transferência de tecnologias e de promoção do capital humano, com ênfase no mercado externo e a inserção do país na economia mundial.

Em meio a este cenário, em 1996 foi criada a empresa de capital privado base deste estudo, com foco em desenvolvimento de soluções de TI para o segmento industrial.

Durante todo seu trajeto, a empresa se especializou em soluções por ondas de rádio, em ambientes geograficamente distribuídos; em integração de soluções complementares a sistemas de gestão, como SAP R/3 e Oracle Applications; em desenvolvimento de soluções WebSphere para IBM; em soluções para tecnologias celulares e host access inteligentes; soluções outsoucing; e em desenvolvimento de sistemas sob-medida para grandes e médias empresas de diferentes segmentos e regiões do país, como a Rhodia, Votorantim, Gerdau e CPFL.

Além disso, firmou importantes parcerias, entre elas a IBM, que escolheu a empresa para residências internacionais de seus profissionais para elaboração de IBM Redbooks, guias de suporte técnico de soluções IBM.

Por diversos anos a empresa foi certificada pela Dun & Bradstreet por sua confiabilidade econômica para atingir mercado offshore.

No começo de 2008, a empresa contava com 33 profissionais divididos entre as áreas de Consultoria, Sistemas, Administrativa e Vendas.

Durante sua história, a empresa contou com funcionários dedicados, porém, especialistas em áreas diferentes de sua atuação na empresa.

Por não ter acompanhado a tendência de gestão de qualidade e não ter investido em especialização de pessoal desde seu nascimento, a empresa não teve seus processos detalhadamente definidos e certificados em todas suas áreas. Além da falta de metodologias técnicas e administrativas, falta de clareza quanto o plano de carreira, apoio financeiro à especialização, comunicação, avaliação técnica e comportamental, feedback e uma necessária atualização quanto a técnicas gerenciais.

Todos esses pontos tornam o ambiente da empresa frágil, colaborando ao desânimo profissional por falta de papéis claramente definidos e de perspectiva com relação à carreira a médio e longo prazo.

Buscando melhoria e solidez em seus processos, a Direção da empresa deseja implementar o MPS.BR, um selo de qualidade que normatiza todo o processo de desenvolvimento de software.

Este trabalho tem como objetivo criar parâmetros de implantação da fase G do MPS.BR na empresa e os pontos que serão levantados durante este trabalho serão:

- Passos para a preparação do ambiente para mudança cultura

- Perfil do líder da implantação

- Principais fatores para o sucesso da implantação

- Principais fatores para o insucesso da implantação

- Estratégias para envolvimento máximo dos profissionais, criando um ambiente estimulante, inovador e desafiador.

Este trabalho foi dividido em 5 capítulos.

Neste capítulo foi apresentado brevemente o desenvolvimento tecnológico no Brasil, o nascimento e o perfil da empresa, sua situação problema e o objetivo do estudo.

No Capítulo II, descreveu-se o nascimento da tecnologia da informação no Brasil e no Mundo e até a chegada a gestão do conhecimento.

No Capítulo III, foram abordados os conceitos do MPS.BR, um programa de melhorias do processo de desenvolvimento de software, visando a excelência.

No Capítulo IV, apresentam-se algumas sugestões de técnicas para a aplicação de uma nova cultura baseada no MPS.BR visando diminuir o impacto na equipe que fará a implantação.

No Capítulo V, expõe-se as considerações finais, pertinentes aos resultados que espera-se alcançar: a excelência.

II.  Tecnologia da Informação

A tecnologia da informação teve sua primeira aparição junto à necessidade de coletar, selecionar, processar e disseminar uma quantidade enorme de dados relevantes durante a Segunda Guerra Mundial, principalmente por parte dos Estados Unidos, Grã-Bretanha e URSS. (FREIRE, 2006)

Durante os anos 50, uma massa de cientistas, engenheiros e financiadores começaram os estudos, do que, mais tarde, Borko nomearia como Ciência da Informação:

Propriedades e o comportamento da informação, as forças que dirigem o fluxo e o uso da informação e as técnicas, tanto manuais quanto mecânicas de processar a informação visando sua armazenagem, recuperação e disseminação. [3](BORKO, 1968, apud ARRAES et al, 2007)

Apesar de Borko ter definido Ciência da Informação antes do aparecimento do primeiro microcomputador em 1981, pela IBM, valoriza-se seu poder de visão quanto aos campos de estudo desta ciência, descritos por Galvão no ano de 2000:

- Demanda da informação

- Produção e reprodução de documentos

- Análise lingüística

- Tradução

- Linguagens documentárias

- Análise e projeto de sistemas

- Padrões de reconhecimento de imagens e de voz

- Sistemas especialistas

Nesta mesma década, já se começava a dar importância do estudo do comportamento humano no processo de recuperação da informação. (INGWERSEN[4], 1992, apud ARRAES et al, 2007)

Nas décadas de 60 e 70, em plena Guerra Fria, o Departamento de Defesa dos Estados Unidos desenvolveu um projeto de pesquisa que interligava alguns computadores em rede experimental objetivando descentralizar informações e distribuí-las estrategicamente, evitando uma possível perda em caso de ataque ao Centro de Processamento de Dados. Nasce a partir desse experimento a Internet como arma de guerra. (MARTINELI, 2001)

No Brasil, em 1970, nascia o Curso de Mestrado em Ciência da Informação, em convênio entre o Instituto Brasileiro de Bibliografia e Documentação (IBBD) e a Universidade Federal do Rio de Janeiro (UFRJ) visando formar especialistas em informação, documentação científica e uso das novas tecnologias que apareciam. (ARRAES et al, 2007)

Em 1985, Hwang (apud GALVÃO, 2000) dividiu os sistemas computacionais em subespaços ainda aceitos nos dias de hoje:

- O maior, de processamento de dados, incluindo caracteres alfanuméricos, símbolos e medidas diversas, sem relações, gerados em grandes quantidades pelo homem;

- O da informação que é uma coleção de dados agregados com infinitas interações;

- O conhecimento, que é soma da informação com conteúdo semântico;

- E o da inteligência, ainda sem definição formal, mas é ligado à capacidade de comunicação plena entre homem e máquina, inferência lógica e senso de criatividade.[5]

Nos anos 2000, a troca de informações pela Internet deixa de ser exclusiva à computadores e passa a ser móvel através de aparelhos portáteis como telefones celulares, pagers bidirecionados, palmtops e outros.[6] (MCNEALY apud MARTINELI, 2001).

Atualmente, o foco desta ciência é a gestão da informação. Wah (2000 apudFERREIRA, 2003) define o processo de gestão como:

Uma ferramenta gerencial para administrar o conhecimento e a informação e agregar-lhe valor ao filtrá-la, sintetizá-la e resumí-la, permitindo aos utilizadores – trabalhadores do conhecimento / tomadores de decisão – conseguir a informação necessária para passar à ação.[7]

A Gestão do Conhecimento que está comprometida com uma atividade-fim tem como função de gerar riquezas através do imensurável: a capacidade de pensar e de gerar o conhecimento. (MARTINELI, 2001).

III.  MPS.BR - Melhoria de Processo do Software Brasileiro

O MPS.BR, Melhoria de Processo do Software Brasileiro, surgiu para ser referencial com respeito à maturidade, definição, avaliação e melhoria dos processos de software e serviços correlatos. É compatível com os padrões de qualidade aceitos internacionalmente e atende a necessidade de implantar os princípios de engenharia de software de forma adequada ao contexto das empresas brasileiras, independente de seu tamanho, características, públicas ou privadas.

O MPS.BR é uma iniciativa coordenada pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID).

O Processo se baseia na NBR ISO/IEC 12207, pelas emendas 1 e 2 das normas internacionais ISO/IEC 12207 e ISO/IEC 15504, e em conformidade ao CMMI-DEV[8]. Ele trabalha com três frentes:

• MR-MPS – Modelo de Referência para Melhoria de Processo de Software

Contém os requisitos que os processos das unidades organizacionais devem atender. Três documentos estão baseados neste modelo:

• Guia Geral: com definições dos níveis de maturidade, processos e atributos do processo.
• Guia de Aquisição: boas práticas destinadas à organizações que pretendam adquirir software e serviços correlatos.
• Guia de Implementação: composto de 7 partes, uma para cada nível do MR-MPS.

• MA-MPS – Modelo de Avaliação para Melhoria de Processo de Software

Descreve o processo e o método de avaliação do MPS.BR, os requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras.

• MN-MPS – Modelo de Negócio para Melhoria de Processo de Software

Descreve regras de negócios para implementação do MR-MPS pelas instituições implementadoras, avaliação seguindo o MA-MPS pelas instituições avaliadoras, organização de grupos de empresas para implementação do MR-MPS e avaliação MA-MPS pelas instituições organizadoras de grupos de empresas, certificação de consultores de aquisição e programas anuais de treinamento por meio de cursos, provas e workshops MPS.BR.

3.1  Detalhamento do MR-MPS

O MR-MPS define os níveis de maturidade que são uma combinação entre processos e capacidade. Os processos são delineados pelo ISO/IEC 15504-2 e expondo os propósitos e resultados finais da execução. A capacidade é relacionada com o atendimento dos atributos de processo de cada nível de maturidade.

Detectar o nível de maturidade de uma organização permite prever o seu desempenho futuro ao executar um ou mais processos.

O MPS.BR divide em seteníveis de maturidade de A a G, como a Figura 2 acima. O processo se inicia do G até o nível A. Cada um desses níveis foca a organização nos processos para melhoria e, atendendo os propósitos e atributos do nível, pode-se avançar para o próximo.

Quanto à capacidade, quanto mais a organização evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido pela organização. Sendo os níveis de maturidade acumulativos, se a organização está no nível F, esta possui nível de capacidade do nível F que inclui atributos do processo (AP) dos níveis G e F para todos os processos relacionados no nível F.

A tabela 1 apresenta os níveis de maturidade, os processos e os atributos de processo correspondentes a cada nível.

Nível	Processos	Atributos do Processo (AP)
A	Análise de Causas de Problemas e Resolução – ACP	AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2 , AP 5.1 e AP 5.2
B	Gerência de Projetos – GPR (evolução)	AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2, AP 4.1 e AP 4.2
C	Gerência de Riscos – GRI	AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
	Desenvolvimento para Reutilização – DRU
	Análise de Decisão e Resolução – ADR
	Gerência de Reutilização – GRU (evolução)
D	Verificação – VER	AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
	Validação – VAL
	Projeto e Construção do Produto – PCP
	Integração do Produto – ITP
	Desenvolvimento de Requisitos - DRE
E	Gerência de Projetos – GPR (evolução)	AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
	Gerência de Reutilização – GRU
	Gerência de Recursos Humanos – GRH
	Definição do Processo Organizacional – DFP
	Avaliação e Melhoria do Processo Organizacional – AMP
F	Medição – MED	AP 1.1, AP 2.1 e AP 2.2
	Garantia da Qualidade – GQA
	Gerência da Configuração – GCO
	Aquisição - AQU
G	Gerência de Requisitos – GRE	AP 1.1 e AP 2.1
	Gerência de Projetos – GPR

Tabela 1 – Níveis de Maturidade do MR-MPS[11]

A capacidade do processo no MPS.BR possui nove AP's com seus correspondentes resultados esperados do atributo do processo (RAP) para alcance completo do atributo de processo. Vide anexo 3.

Devido a esse trabalho ser focado na implementação da fase G, segue a descrição dos propósitos e resultados esperados referentes para este nível de maturidade.

3.2  Nível G – Parcialmente Gerenciado

É o nível inicial na implementação do MPS.BR e é, por esse mesmo motivo, um desafio, visto que se trata de uma mudança de cultura organizacional na empresa. É uma redefinição de algumas operações na rotina de trabalho e estabelecer objetivos, prazos e escopo para cada projeto em execução.

O objetivo da implementação do nível G é tornar a organização capaz de gerenciar parcialmente seus projetos de desenvolvimento de software, torná-la orientada a projetos.

De acordo com a Tabela 1, os objetivos da fase G giram em torno de dois assuntos: Gerência de Projetos (GPR) e Gerência de Requisitos (GRE), que serão detalhados a seguir.

3.2.1  Gerência de Projetos (GPR)

O processo de Gerência de Projetos (GPR) envolve as seguintes atividades:

- Desenvolver um plano geral de controle do projeto. Inclui identificar e estimar o escopo, os produtos de trabalho e as tarefas do projeto; estabelecer recursos necessários; identificar e analisar os riscos do projeto; estabelecer compromissos; e definir o cronograma de execução baseado no ciclo de vida definido para o projeto.Plano do projeto estabelece a base de execução e controle para as atividades do projeto junto aos seus interessados (especialmente o cliente) e obter o comprometimento e mantê-lo ao longo da execução.

- Conhecer o progresso do projeto de maneira que ações corretivas possam ser tomadas quando a execução do projeto desviar do planejado. É a comparação real da tarefa, do esforço, do custo e do cronograma com o que foi planejado previamente. Essa visão possibilita a tomada de decisão de ações corretivas quando o status do projeto se desvia do esperado, podendo incluir re-planejamento, novos acordos ou atividades adicionais para diminuição dos riscos do plano.

3.2.1.1  Resultados Esperados para GPR

-  GPR1 – O escopo do trabalho para o projeto é definido. O escopo é o ponto de partida para o planejamento do projeto. Nele é definido todo o trabalho necessário para que o entregável (produto ou serviço) satisfaça as necessidades, características e funções especificadas pelo cliente. No escopo devem conter o que está e não está incluído no projeto, objetivo, limites e restrições e todos os entregáveis. O escopo pode ser representado por meio do WBS (Work Breakdown Structure) ou por meio de um Documento de Visão.

-  GPR2 – As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados. Todos os itens levantados no escopo devem ser decompostos em componentes menores, mais facilmente gerenciáveis e mensuráveis. São contadas tabelas internas e externas ao sistema, classes, objetos, relatórios, telas, consultas a banco de dados, cálculos, transações e atores dos casos de uso, linhas de código, etc. Uma técnica muito utilizada (porém não necessita ser obrigatoriamente esta técnica) para mensurar o tamanho do software é a de Análise de Ponto de Função. Com este nível de detalhamento, pode-se estimar o escopo pela complexidade, número de requisitos e/ou histórico de projetos.

-  GPR3 – O modelo e as fases do ciclo de vida do projeto são definidas. O ciclo de vida do projeto visa um maior controle gerencial por ter fases e atividades que gera entregáveis necessários para o desenvolvimento de fases posteriores. A organização pode ter um modelo de ciclo de vida para todos os projetos ou predefinir mais de um modelo de desenvolvimento, selecionando aquele que melhor atender às suas características. A definição de fases possibilita períodos planejados de avaliação e de tomada de decisões com relação a recursos, abordagem técnica, reavaliação de escopo e custo do projeto.

-  GPR4 – E esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências bibliográficas. As estimativas de esforço e custo consideram o escopo, produtos de trabalho e as tarefas estimadas para o projeto; os riscos; as mudanças previstas; o ciclo de vida escolhido para o projeto; viagens previstas; nível de competência da equipe, etc. Os parâmetros criados com base histórica devem ser periodicamente calibrados.

-  GPR5 – O orçamento e o cronograma do projeto, incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos. Com base no GPR1 e GPR4, onde o escopo, esforço e custo não definidos, pode ser gerado o cronograma, considerando as dependências entre tarefas, recursos e os marcos e/ou pontos de controle, com coerência entre eles. Com base no cronograma, é estabelecido o orçamento do projeto. O orçamento e cronograma são instrumentos fundamentais para o acompanhamento diário do projeto e precisam ser revistos e atualizados sempre que necessário.

-  GPR6 – Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados. Os riscos de um projeto precisam ser identificados, analisados e priorizados. Para facilitar isso, elaborar uma lista com os riscos mais comuns pode ser útil para identificar quais destes riscos são os potenciais para o projeto em questão. Após isso, deve-se fazer uma análise de probabilidade de ocorrência e gravidade para definir a prioridade dos riscos. Estes devem ser registrados, assim como o acompanhamento de seus estados e as ações que deverão ser tomadas em caso de ocorrência.

-  GPR7 – Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-los. O planejamento de recursos humanos inclui informações de como e quando o recurso será envolvido no projeto, critérios para sua liberação, competência necessária para a execução das atividades, mapa de competências da equipe e identificação de necessidades de treinamento (de qualquer natureza – sala de aula, on-line, no trabalho, leituras, aconselhamentos, orientações, etc).

-  GPR8 – As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados. Devem ser detalha e explicitamente especificadas as tarefas e recursos e ambiente necessários, incluindo, por exemplo, equipamentos, ferramentas, serviços, componentes, viagens e requisitos de processo. Quanto a recursos humanos, inclui os treinamentos do GPR7. Deve ser feito mesmo que seja óbvio. Se não houver o que lista, deve-se registrar o fato de que a questão foi examinada.

-  GPR9 – Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança. Os dados do projeto – somente os relevantes – são os relatórios, dados informais, estudos e análises, atas de reuniões, documentação, lições aprendidas, artefatos gerados, itens de ação e indicadores, que podem estar em qualquer formato, digital ou impresso. A identificação, coleta, armazenamento, distribuição, acesso e segurança dos dados devem ser planejados. O motivo de se coletar cada dado, assim como a inexistência de dados confidenciais, deve ser explicitada.

-  GPR10 – Planos para a execução do projeto estabelecidos e reunidos no Plano do Projeto. A união de todas as informações do projeto levantadas em todas as GPR's de forma organizada e relacionadas entre sim em um documento ou mais, formam o Plano do Projeto. A utilização de uma mesma referência facilita não somente o gerenciamento dessas informações, como também a formação de uma base histórica, que poderá beneficiar a organização em etapas posteriores de melhorias.

-  GPR11 – A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados. No início do projeto deve-se fazer uma avaliação preliminar a partir da visão geral dos objetivos, características dos resultados pretendidos, dos recursos financeiros, técnicos, humanos, bem como restrições impostas pelo cliente, ambiente externo e interno e condições de desenvolvimento. O mesmo estudo de viabilidade pode acontecer durante o projeto em marcos específicos para maior precisão de sucesso. Em caso de projetos rotineiros, não há necessidadede estudos de viabilidade, mas deve-se definir um critério explícito para o mesmo não ser realizado.

-  GPR12 – O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido. Para conseguir o compromisso dos envolvidos no projeto – equipe, gerência, clientes, usuários -, é importante revisar o planejamento com eles e conciliar as diferenças existentes entre os recursos estimados e disponíveis, negociando quando houver conflitos quanto aos requisitos, custos e prazos, por exemplo. Algumas organizações realizam uma reunião no início do projeto (kick off) para resolver conflitos e obter o comprometimento. O atendimento esse resultado esperado está associados com o GPR11, pois a análise de viabilidade pode resultar em ações para soluções de conflitos.

-  GPR 13 – O progresso do projeto é monitorado com relação ao estabelecido no Plano de Projeto e os resultados são documentados. Essa atividade é essencial para o gerenciamento: acompanhar o que foi planejado, detectar problemas e corrigi-los. Os resultados e os critérios de conclusão de cada tarefa são analisados, as entregas são avaliadas em relação às suas características, a aderência ao cronograma e os esforços são examinados, bem como o uso dos recursos. Análises devem ser realizadas e decisões serem tomadas considerando-se as variações dos dados e desvios entre resultados e valores atuais e esperados. O acompanhamento pode ser realizado utilizando-se ferramentas de planejamento, em que se pode examinar o previsto contra o realizado, usando-se indicadores de progresso e cumprimento de marcos ou ainda reuniões e comunicação pessoal. É importante ressaltar que devem existir registros desses acompanhamentos.

-  GPR14 – O envolvimento das partes interessadas no projeto é gerenciado. Os interessados relevantes no projeto devem ser identificados, em que fases eles são importantes e como eles serão envolvidos (comunicações, revisões em marcos de projeto, comprometimentos, entre outros). Uma vez identificados, este plano deverá ser seguido. Além da comunicação em si, é necessário verificar se os compromissos assumidos pelas partes interessadas estão sendo cumpridos ou negociados, sejam eles internos ou externos, visando identificar aqueles que não foram satisfeitos ou que possuem um grande risco de não serem satisfeitos.

-  GPR15 – Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento. Não é o mesmo que acontece no GPR13. Os marcos são definidos ainda no planejamento do projeto e podem ser, por exemplo, no início ou término de cada fase. Essas revisões têm o objetivo de verificar se existem condições para se iniciar a fase ou a próxima fase. Podem ter caráter formal, com participação de qualquer dos envolvidos no projeto e, sempre que necessário, deve-se realizar um re-planejamento e uma nova análise de sua viabilidade, verificando se é possível sua continualidade.

-  GPR16 – Registros de problemas identificados e resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas. O GPR13 e GPR15 possibilitam a identificação de problemas que devem ser analisados e registrados com qualquer tipo de ferramenta para gerenciamento de problemas. Os problemas precisam ser corrigidos e gerenciados até sua resolução, com base no GPR17.

-  GPR17 – Ações para corrigir desvio em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão. O controle dos problemas levantados, as ações tomadas, os responsáveis pelas ações e os resultados devem ser registrados em ferramentas específicas de gerenciamento de problemas, como as de bug tracking. Quando as ações corretivas são apropriadas, quando o impacto e os riscos associados são modelados e gerenciados, as mudanças podem ser realizadas. Acompanhar o andamento de uma ação corretiva inclui verificar com freqüência se foi resolvida, não deixar pendências e investigar sua efetividade.

3.2.2  Gerência de Requisitos (GRE)

O requisito representa a capacidade que deve ser encontrada no software para satisfazer um contrato, um padrão, uma especificação ou documentos formalmente impostos, permitindo que o usuário consiga resolver um problema ou alcançar um objetivo.

O processo de Gerência de Requisitos (GRE) envolve as seguintes atividades:

-  Controlar a evolução dos requisitos. Gerenciar todos os requisitos recebidos ou gerados pelo projeto, incluindo os funcionais e não-funcionais. Quando o projeto recebe requisitos ou modificações de uma pessoa autorizada, estes devem ser revisados para resolver questões e prevenir mau entendimento antes de serem incorporados ao escopo.

-  Documentar, rastrear e identificar inconsistências. Todas as mudanças nos requisitos devem ser documentadas, assim como suas justificativas. Deve-se manter a rastreabilidade bidirecional entre os requisitos e produtos de trabalho e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto.

3.2.2.1  Resultados Esperados para GRE

-  GRE1 – O entendimento dos requisitos é obtido junto aos fornecedores de requisitos. O objetivo é garantir que os requisitos sejam claramente definidos, o que é um dos fatores determinantes para o sucesso do projeto. A cada novo conjunto de requisitos, deve-se rever com o cliente se as necessidades e expectativas estão sendo atendidas. Deve-se documentar os requisitos e a comprovação do entendimento dos mesmos. Os fornecedores de requisitos devem ser identificados a partir de critérios bem definidos, com que se tem o entendimento dos requisitos, pelo patrocinador do projeto. Toda a comunicação deve ser registrada formalmente em atas, e-mails, ferramentas de comunicação ou outros meios, com a comprovação de que todos os envolvidos estão de acordo.

-  GRE2 – Os requisitos de software são aprovados utilizando critérios objetivos. Os requisitos devem ser aprovados após uma avaliação com base em critérios objetivos, previamente estabelecidos. Alguns exemplos de critérios que poderão constar numa checklist são: possuir única identificação; ser relevante; ser completo; estar consistente com os demais requisitos; ser testável e rastreável. As aprovações têm envolver a equipe do projeto e o cliente numa reunião para este objetivo, podendo ser o kick off onde se apresenta o projeto como um todo. Sempre que houverem mudanças de requisitos aprovadas, outras aprovações deverão acontecer quanto ao escopo, cronograma e esforço.

-  GRE3 – A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida. Deve ser estabelecido um mecanismo que permita rastrear a dependência entre os requisitos e os produtos de trabalho para facilitar a avaliação do impacto das mudanças de requisitos que possam ocorrer, por exemplo, no escopo, nos produtos ou nas tarefas do projeto. Devem acontecer tanto na forma horizontal como na vertical. A rastreabilidade na horizontal estabelece as dependências de um mesmo nível, por exemplo, dos requisitos entre si ou entre códigos dependentes. A rastreabilidade verticalé mais baixo nível, desde um requisito fonte até, por exemplo, os códigos da unidade ou módulos do software, sendo esta essencial para a análise de impactos nas mudanças de requisitos, como identificar como a mudança de requisitos pode impactar os planos do projeto já aprovadas.

-  GRE4 – Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos. São necessárias revisões ou uso de mecanismo que identifique inconsistências entre os requisitos e planos, atividade e produtos do trabalho. O resultado deve ser registrado, ações corretivas executadas e acompanhadas até que sejam resolvidas.

-  GR5 – Mudanças nos requisitos são gerenciadas ao longo do projeto. As necessidades de mudanças devem ser registradas e deve-se disponibilizar um histórico das decisões acerca dos requisitos.

3.2.3  Os atributos de processo (AP) no nível G

À medida que a organização evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar um processo deve ser atingido pela organização.

Os níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de capacidade do nível F que inclui os AP dos níveis G e F. No caso da fase G, existem resultados esperados de que vão de RAP 1 a RAP 8. É exigido que os AP 1.1 e AP 2.1 sejam caracterizados como T (totalmente implementado) ou L (largamente implementado).

Seguem os AP 1.1 e AP 2.1 descritos nos detalhes:

-  AP 1.1 – O processo é executado. Expressa o quanto o processo atinge o seu propósito. Quanto a esse atributo, segue o resultado esperado (RAP):

-  RAP1 – O processo atinge seus resultados definidos.Este resultado garante que há produtos de trabalho de saída identificáveis, atingindo o propósito do processo.

-  AP 2.1 – O processo é gerenciado.Implica no planejamento, atribuição da responsabilidade, recursos necessários, monitoramento e controle da execução dos processos, tomando ações corretivas. Os resultados esperados são:

-  RAP2 – Existe uma política organizacional estabelecida e mantida para o processo. Existem políticas de processos na organização, neles são explicitados quem são as autoridades para aprovar cada tipo de documento e quais são as expectativas do(s) processo(s). Todo o material deve ser publicado e divulgado aos envolvidos no projeto, pela intranet, por exemplo.

-  RAP3 – A execução do processo é planejada. Deve ser estabelecido e documento um plano para a execução do processo, o que inclui recursos, responsabilidades, tempo, atividade de controle e de monitoramento da execução do processo. Esse planejamento deve ser revisto sempre que necessário.

-  RAP4 – A execução do processo é monitorada e ajustes são realizados para atender aos planos.O monitoramento do processo pode ser incluído nas atividades de monitoramento do projeto, assegurando assim que a execução segue conforme planejado e que as ações corretivas sejam tomadas sempre que houver desvios significativos em relação ao planejado.

-  RAP5 – Os recursos necessários para a execução do processo são identificados e disponibilizados.Incluem recursos financeiros, condições físicas adequadas, pessoal e ferramentas apropriadas (incluindoprocessos e modelos de documentos predefinidos). Todos esses recursos devem estar descritos em planos específicos para os processos.

-  RAP6 – As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência.Deve-se assegurar que as pessoas tenham o conhecimento em relação ao seu papel no processo, incluindo trabalho em grupo, liderança, análise e solução de problemas. Treinamentos devem ser disponibilizados quando necessário. Mantém-se o registro das competências atuais e necessárias das pessoas para a realização dos diversos papéis na execução dos processos.

-  RAP 7 – A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento no projeto.O objetivo é identificar as partes envolvidas, planejar e assegurar manter o seu envolvimento. Estes podem ser envolvidos tipicamente em atividades como planejamento, coordenação, revisão e definição de requisitos.

-  RAP8 – Métodos adequados para monitorar a eficácia e adequação do processo são determinados.O objetivo é fornecer visibilidade do estado da execução dos processos, considerando sua adequação ao projeto, operação com recursos apropriados e alcance dos resultados esperados pelo projeto.

IV.  IMPLEMENTAÇÃO DA FASE G DO MPS.BR

Muitos são os benefícios relacionados à implantação do MPS.BR, como "melhoria no relacionamento com clientes, maiores vantagens competitivas, aumento no número de funcionários treinados, aumento de produtividade, abertura de novos mercados, parcerias com fornecedores, etc." (MOURA, 2002).

Porém, implantá-lo apresenta alguns desafios, principalmente por se tratar de uma mudança cultural para a organização e por envolver pessoas.

Com relação à mudança organizações Morgan[15] (1972) e Bennis[16] (1976, apud MOURA, 2002) defendem que deve ser planejada, incorporando seis características fundamentais:

- deve ser lógica, para criar um referencial para aqueles que trabalham na organização; deve ser inteligível, para facilitar sua comunicação e compreensão; deve ser explícita, para evitar ambigüidades em termos de relações; deve ser estruturada a partir de princípios seguros, que ensejam estabilidade e, ao mesmo tempo deve ser flexível para motivar as pessoas a enfrentar problemas inesperados e aproveitar oportunidades imprevistas e, finalmente, deve agregar valor ao trabalho, para que a organização adquira vantagem competitiva.

Embora disseminar a cultura de gerenciamento de projetos e de requisitos exija tempo, Crawford[17] (2002 apud Martins et al, 2005) sugere que a organização imprima certa velocidade à implantação para apresentar os primeiros resultados em seis meses.

Apresentam-se abaixo sugestões de passos para uma mudança cultural que permita o sucesso da implantação do MPS.BR.

4.1 - 1º passo – Alta gerência

Nesta etapa, a alta gerência e os gerentes participam do Curso de Introdução ao MPS.BR fornecido pela sociedade que a criou, a SOFTEX, de 2 dias de duração, em diversos locais do Brasil.

Essa participação é essencial visto que um fator crítico e inicial para a implantação de um processo de qualidade é a firme convicção da alta gerência, de acordo com Kerzner (2002, pg. 98):

O desenvolvimento acelerado de uma metodologia exige a existência de um executivo convicto de sua indispensabilidade, não apenas um executivo responsável por sua implantação. O executivo superior é aquele interessado na prática da mudança e que comanda o desenvolvimento e a implantação da metodologia em todas as suas etapas.

Essa questão vai contra à comum "resistência branca" da gerência, conceito que traduz o comportamento "daqueles que dizem acreditar nas propostas de mudanças apresentadas, mas que não alteram seus hábitos e atrasa o alcance das melhorias pretendidas." (MOURA, 2002)

Com a alta gerência ciente da necessidade de mudança, parte dela também o incentivo ao trabalho em equipe, a cooperação, a confiança e uma comunicação eficaz em nível interno. (KERZNER, 2002, pg. 224)

Tendo as alta e média gerências algumas ações como fundamento básico, torna-se possível concretizar o sucesso comportamental, sendo elas de acordo com Kerzner (2002, pg.321):

- Incentivar a franqueza e a honestidade de todos;

- Criar um clima de incentivo à concorrência legítima;

- Planejar adequadamente o financiamento necessário para a conclusão do projeto;

- Desenvolver um entendimento muito claro da importância relativa dos custos, cronogramas e metas de desempenho técnico;

- Desenvolver canais de comunicação próximos e informais e uma estrutura organizacional enxuta;

- Delegar autoridade de aprovação ou rejeição ao principal contato do cliente para decisões importantes para o projeto;

- Rejeitar comprometimentos exagerados;

- Tomar decisões ágeis;

- Cultivar boas relações de trabalho;

- Evitar relacionamentos dominados pela frieza;

- Evitar relatórios com excesso de detalhes.

O perfil do líder faz toda a diferença no projeto de implantação do MPS.BR, sendo que as características necessárias são as seguintes:

- Entende e demonstra competência como gerente de projetos;

- Trabalha de maneira criativa e inovadora quando necessário, mas não procura problemas desnecessariamente;

- Demonstra altos níveis de auto-motivação desde o começo;

- Ostenta alto grau de integridade, passando longe das ambições políticas e da falta de ética;

- Dedica-se à empresa, não apenas ao projeto;

- Jamais se mostra auto-suficiente;

- É humilde na liderança;

- É apto para integrar

- É pró-ativo

- Assume altos riscos e usa o tempo necessário para trabalhar as contingências;

- Sabe quando administrar a complexidade e quando abortá-la;

- Demonstra perseverança;

- Tenta fazer emergir o melhor das pessoas;

- É disposto a ajudar aos colegas a realizar todo o que são capazes;

- Comunica-se adequadamente, sempre confiante e sem desespero.

- Nunca sonega informações;

- Jamais lidera com imposições;

- Faz elogios públicos e críticas em particular;

- Promove críticas construtivas ao invés de ataques pessoais;

- Bom ouvinte

- Envolve a equipe nos processos decisórios;

- É acessível para todos os funcionários; (Kerzner, 2002, pg. 321 e 322)

Os gerentes precisam aprender a exercer o papel de facilitadores, de capacitadores, de alguém cuja função é a de desenvolver pessoas e habilidades, as tornando capazes de realizar processos adicionadores de valor por si só. (MOURA, 2002)

4.2 - 2º passo – Conhecer o status atual

Nesta fase é necessário identificar a situação atual para se traçar um objetivo a se almejar. Esses dados podem ser obtidos por meio de questionários e entrevistas com os funcionários (CARVALHO et al, 2001).

Segue um modelo de questionário que evidencia indicativos já existentes na empresa que satisfaçam o nível G, de acordo com Szimanski et al (2006):

Processo: Gerência de Projetos – GPR
Referência	Resultados Esperados	Sim	Não
GPR1	O escopo do trabalho para o projeto está definido.
GPR2	O escopo, os produtos de trabalho e as tarefas do projeto são estimados, através de métodos apropriados.
GPR3	As fases do ciclo de vida do projeto são definidas.
GPR4	A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada.
GPR5	As tarefas, os recursos e a infra-estrutura necessários para completar o trabalho são planejados.
GPR6	O cronograma e o orçamento do projeto são estabelecidos e mantidos.
GPR7	Premissas e restrições são identificadas, incluindo as dependências de tarefas e os critérios para estabelecer as ações corretivas.
GPR8	Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridades de tratamento são determinados e documentados.
GPR9	Os dados relevantes do projeto são identificados, coletados, armazenados e distribuídos. Um mecanismo é estabelecido para acessá-los, incluindo questões de privacidade e segurança.
GPR10	Os recursos humanos para o projeto são planejados considerando o perfil e conhecimentos necessários para executar o projeto.
GPR11	O esforço e custo para produtos de trabalho e tarefas são estimados baseados em dados históricos ou referências ténicas.
GPR12	O envolvimento dos interessados do projeto é planejado.
GPR13	O Plano do Projeto é revisado com os interessados do projeto e o compromisso com o plano é obtido.
GPR14	Periodicamente o projeto é monitorado com relação ao Plano do Projeto e o resultado é relatado aos interessados.
GPR15	Quando há desvio em relação ao Plano do Projeto ou quando as metas não são atingidas, são implementadas ações corretivas que são gerenciadas até as suas conclusões.

Tabela 2 – Processo de Gerência de Projetos - GPR[18]

Processo: Gerência de Requisitos – GRE
Referência	Resultados Esperados	Sim	Não
GRE1	Uma comunicação contínua com o cliente é estabelecida.
GRE2	O entendimento dos requisitos é obtido.
GRE3	Critérios objetivos para a aceitação dos requisitos são definidos.
GRE4	O comprometimento com os requisitos é estabelecido, registrado e mantido.
GRE5	Uma matriz de rastreabilidade bidirecional entre os requisitos, os planos do projeto e produtos de trabalho é gerada e mantida.
GRE6	Inconsistências entre os planos do projeto, os produtos de trabalho e os requisitos são identificados e corrigidas.
GRE7	Mudanças nos requisitos são gerenciadas ao longo do projeto.

Tabela 3 – Processo de Gerência de Requisitos – GRE[19]

Para o sucesso na implantação da fase G do MPS.BR, todas as referências devem ter resposta "sim". E este é o objetivo final. Que todos os profissionais respondam "sim", sabendo detalhadamente como cada referência acontece no processo de desenvolvimento de software.

4.3 - 3º passo – Divulgar a decisão de implantação do processo de qualidade

Obtidas as informações, estas devem ser consolidadas e apresentadas a alta administração, gerentes e desenvolvedores. "A organização deve assegurar que seu pessoal está consciente quanto à pertinência e importância de suas atividades e de como elas contribuem para atingir os objetivos da qualidade." (CARVALHO[20], 2000, apud MOURA, 2002)

Com base nos estudos de casos de Martins et al (2005) e Szimanski et al (2006) um dos primeiros passos para a implantação da fase G do MPS.BR para a criação de um clima organizacional de mudança é "evidenciar a importância da mudança e o senso de urgência junto aos membros da organização" (MARTINS et al, 2005). Os argumentos que poderão ser usados são, além dos pontos fracos com relação às exigências do MPS.BR, as taxas de insucesso em projetos e a comparação da empresa com outras organizações topo de linha do setor.

É importante identificar os grupos de resistência e apresentar a eles os benefícios da mudança. Para Chang (2000), o conflito gerado pode oferecer oportunidades, como também pode destruir o progresso da equipe se não for bem administrado.

Carvalho et al(2001), sugere que divulgação da decisão seja feita por meio de um workshop com toda a equipe, de forma a "conscientizar e mobilizar os gerentes e desenvolvedores para a promoção das práticas e mudanças requeridas pelo programa". É fundamental que toda a equipe presencie o comprometimento da alta direção com relação à mudança que se evidencia.

O autor continua sugerindo que o evento pode ser organizado em forma de palestras sobre o tema, mostrando de forma não densa o que é o MPS.BR, quais os objetivos do programa e diversos casos de sucesso com empresas do mesmo porte. Mais detalhes do programa serão trabalhados em outros passos.

É importante salientar neste workshop que um grupo que será escolhido para começar um projeto como piloto (SZIMANSKI, 2006), validando todo o processo nas exigências MPS.BR e que os outros projetos em andamento continuarão com o atual processo até seu término. A partir do final do projeto-piloto, todos os novos projetos seguirão o novo processo de desenvolvimento, que passará com melhorias contínuas.

4.4 - 4º passo – Treinamento

O grupo de desenvolvedores é escolhido para participar do projeto-piloto sob as diretrizes do MPS.BR. Para esse início de modelagem, definição e detalhamento de processo, busca-se profissionais com experiências sólidos em processos de desenvolvimento, levantamentos de requisitos e com bons resultados em projetos passados.

É sugerido que o gerente seja escolhido pela equipe de desenvolvimento formada e a alta direção, de acordo com o perfil apresentado no item 4.1, visto a experiência que estes tiveram em projetos passados juntos. Pode-se criar uma tabela como o modelo abaixo (Tabela 4), com a opção de preenchimento anônimo. O gerente de projetos que tiver maior pontuação, será o líder do projeto-piloto.

A sugestão de pontuação é:

1 – profissional nunca demonstra essa característica

2 – profissional demonstra essa característica eventualmente

3 – profissional sempre demonstra essa característica

Característica	Opção X	Opção Y	Opção Z
Entende e demonstra competência como gerente de projetos
Trabalha de maneira criativa e inovadora quando necessário, mas não procura problemas desnecessariamente;
Demonstra altos níveis de auto-motivação desde o começo;
(continua...)

Tabela 4 – Escolha do líder do projeto-piloto

Escolhido o líder da equipe do projeto-piloto, toda ela, excluindo a alta direção, participa do Curso para Implementadores, da Softex, de 3 dias de duração.

Após o curso, o grupo define os papéis e responsabilidades de forma explícita, documenta e cria um cronograma de atividades. Todo o material será arquivado em local de uso comum para todos os profissionais envolvidos neste projeto.

4.5 - 5º passo – Criar um Ambiente de Uso Comum

A empresa já tem um ambiente de cooperação onde todos os funcionários tem acesso com controle de usuários em determinadas pastas. É o Project Server, ferramenta da Microsoft. Para desenho dos processos, Szimanski (2006) sugere o uso do MS Visio e, para gerenciamento da configuração jediVCS para atividade de controle de versões.

4.6 - 6º passo – Fazer um Plano de Comunicação

Moura (2002 pg. 57) reforça quanto à importância da comunicação interna afirmando que um dos aspectos mais difíceis do planejamento das organizações é "como fazer com que a pessoa certa se comunique a respeito das tarefas certas no momento certo e com as atitudes certas de colaboração e de solução de problemas."

Um bom plano de comunicação em ação é essencial para as pessoas enfrentarem os processos de mudança, diminuindo sua ansiedade e desconfiança sem fundamento.

Uma sugestão de plano de comunicação de Rezende (2003), em seu estudo de caso, é elaborar um plano de comunicação e divulgação com informativos de atividades do projeto-piloto, atas de trabalho, documentos e textos na intranet, relatórios para diretoria, plano de reuniões, cronogramas, apresentações e avaliações permanentes da efetividade, qualidade e produtividade do projeto abertos para todos da empresa.

A divulgação explícita de bons resultados em marcos específicos são essenciais para aumentar a credibilidade do projeto também para os que não estão participando dele, assim como a divulgação de pontos que não tiveram grande êxito e precisam ser melhorados nos próximos projetos.

4.7 - 7º passo – Clientes

Kerzner (2002 pg. 99) ainda enfatiza a importância em trabalhar não somente o ambiente interno para mudanças, mas também o externo: os clientes. Eles também têm que acreditar e confiar na metodologia, para poder entender e aceitar quando algumas novas mudanças são inviáveis uma vez iniciada uma fase específica do ciclo de vida do projeto.

O autor ainda cita o exemplo de uma indústria automotiva que convidou seus clientes para assistirem às reuniões de revisão de final de fases do projeto, o que maximizou a confiança entre o cliente e o provedor. Carvalho et al (2001) sugere buscar um cliente que esteja disposto a ser o pioneiro no processo de implantação do MPB.BR e que possa participar de forma mais intensa que o habitual de todas as fases do projeto, afim de validá-lo.

4.8  Outros Fatores Importantes para o Sucesso da Implementação

É importante enfatizar que os conflitos são parte integrante da vida das empresas com cultura de gestão de projetos. O gerente de projeto é um gerente de conflitos. E estes últimos surgem com facilidade em uma equipe onde os integrantes não entendem as funções e responsabilidade de cada um e do conjunto. (KERZNER, 2002, pg. 314)

Um fator motivacional para a equipe é a valorização de sua participação e opinião, permitindo que haja um "espaço para sugestão de melhorias no plano proposto, proporcionando a participação de todos na sua construção". (SZIMANSKI, 2005).

Na visão de Frame[21] (1999 apud RABECHINI e CARVALHO, 2002), se os gerentes desejam ver seus grupos de projetos motivados, eles devem trabalham com a visão de que a equipe do projeto é uma entidade única. E isto seria possível através da condução de reuniões produtivas, criação de um espaço físico próprio para eles, da criação de sinais específicos, da divulgação dos resultados, do reconhecimento de esforços extras, do gerente ter seu comportamento focado às pessoas do seu grupo e uma estruturação correta do grupo quanto às responsabilidades de cada pessoa do grupo. E para uma participação ativa nas atividades do projeto, o gerente precisa medir seu desempenho ao longo do projeto, num processo contínuo de gerenciamento.

Porém, para isso, o mesmo autor salienta que para medir o desempenho da equipe são necessários alguns critérios mínimos como objetivos claros e factíveis, entregáveis intermediários bem definidos, habilidades gerencial e técnicas diferenciadas, bom relacionamento entre a equipe e com clientes, coesão, ferramentas adequadas, disciplina e liderança.

Thamhain[22] (1993 apud RABECHINI e CARVALHO, 2003) criou dois grupos que podem servir de base para identificar as competências em equipes e medir seu desempenho. Um de indicadores de tarefa, com características orientadas as atividades e o outro grupo é de indicadores de pessoas, resultados em projeto.

Indicadores de Tarefa	Indicadores de Pessoas
Desempenho técnico: indicador que visa medir o aprimoramento técnico de seus membros e, via de regra, avaliar a equipe por seu desempenho técnico.	Envolvimento da equipe:referem-se aos stakeholders e com o resultado do projeto em si. A equipe deve ser pró-ativa e passar essa imagem aos envolvidos do projeto, gerando um ambiente de confiança.
Planejamento dos prazos e orçamentos: indicadores que medem a capacidade da equipe em gerenciar os prazos e custos do projeto.	Gerenciamento de conflitos:refere-se ao processo de identificação de conflitos e seus modos de resolução. Toda equipe de projetos passa por momentos de conflito que devem ser administrados, para evitar que o desempenho diminua. Neste sentido, identificar e antever possíveis pontos de conflitos, resolvendo-os antes que eles aconteçam é um bom procedimento da equipe,
Avaliação por resultados:são os fatores relacionados aos alvos que o projeto precisa atingir e, também das recompensas envolvidas quando atingidos.	Comunicação:é um indicador fundamental para que uma equipe obtenha alto desempenho. O conhecimento do plano do projeto e o processo de geração, estoque, disseminação e controle das informações são aspectos críticos do gerenciamento.
Inovadoras e criatividade: considerando o ambiente, estes indicadores representam a valorização da criatividade de seus membros e das soluções de fato entendidas como criativas.	Espírito de equipe: As equipes consolidadas geralmente têm membros que apresentam espírito colaborador em detrimento do individualismo, buscam juntos os resultados e procuram sempre se proteger contra eventuais injustiças.
Estabelecimento de especificações:são indicadores que se referem aos requisitos do projeto e controles periódicos da qualidade das atividades do projeto até a hora do aceite do cliente.	Confiança mútua:. A confiança aqui discutida refere-se a um dos pré-requisitos para a formação de equipe, pois uma atividade tem interface com informações e resultados oriundos de outras atividades, a equipe precisa ter a confiança que tais entradas estejam de acordo com os requisitos planejados.
Gerenciamento das mudanças: indicam a flexibilidade e o acompanhamento do processo de implementação.	Auto-desenvolvimento: Os membros de uma equipe buscam desenvolver habilidades, que irão contribuir para se atingir os resultados do projeto, identificando possibilidades técnicas para isto. A participação em congressos e simpósios que formem competências visando a melhoria dos resultados do projeto é importante.
Previsões de prazo e custo:indicam o entendimento das tendências do projeto bem como estabelecimento de cenários dos negócios da organização ao qual o projeto está vinculado.	Interface organizacional:refere-se a capacidade da equipe em se relacionar com a empresa visando conseguir recursos e apoios para o projeto.
Capacidade da equipe em buscar resultados do projeto e se relacionar com a empresa:Quanto mais a equipe conhece as potencialidades e possibilidades da empresa que faz parte, poder explorar melhor seus recursos e, certamente, melhor contribuir para o sucesso de seus projetos.

Tabela 5 – Indicadores de Desempenho de Tarefas e Pessoas

V.  CONSIDERAÇÕES FINAIS

Tradicionalmente as empresas operam com um apronfundamento técnico muito grande, deixando para segundo plano os aspectos gerenciais. Porém, o comprometimento dos colaboradores é fundamental para o sucesso da implantação dos processos de melhorias. Mas isto não surge sem uma atenção especial às necessidades dos profissionais e sem um planejamento estimulante.

Definição de papéis, investimento intenso em treinamentos, muní-los com todas as informações que necessitam do projeto para que participem intensamente e os incentive as críticas construtivas, são os caminhos para o aprendizado, o trabalho em equipe, a processos mais bem modelados, a comunicação mais eficiente e, enfim, à excelência.

REFERENCIAL BIBLIOGRÁFICO

ARRAES, Bruno; CAMARGO, Liriane; CARVALHO, Ângela; CASTRO, Fabiano. Tecnologias da Informação e Comunicação como Recurso Interativo na Perspectiva da Ciência da Informação. Marilia: Revista Eletrônica Informação e Cognição, 2007.

CARVALHO, Ana Elizabete Souza de; TAVARES, Helena Cristina; CASTRO Jaelson Brelaz. Uma Estratégia de Implantação de uma Gerência de Requisitos Visando a Melhorias dos Processos de Software. Pernambuco: Universidade Federal de Pernambuco, 2001.

CASTRO, Antonio Barros de. A Reestruturação Industrial Brasileira nos Anos 90. Uma Interpretação. Rio de Janeiro: Revista de Economia Política, 2001.

CHANG, R.Y. O Sucesso Através das Equipes. São Paulo: Editoria Futur, 2000.

DUARTE, Carlos H.; BRANCO, Carlos E. Impactos Econômicos da Política Setorial Brasileira para Tecnologias da Informação. Rio de Janeiro: Revista do BNDS, 2001

FERREIRA, Danielle Thiago. Profissional da Informação: Perfil de Habilidades Demanandas pelo Mercado de Trabalho. Disponível em: < http://www.scielo.br/scielo

.php?pid=S0100-19652003000100005&script=sci_arttext&tlng=pt > Acesso em 21 de Setembro de 2008.

FREIRE, Gustavo Henrique. Ciência da Informação: Temática, Histórias e Fundamentos. Belo Horizonte: Universidade Federal de Minas Gerais, 2006.

GALVÃO, Maria Cristiane Barbosa; BORGES, Paulo César Rodrigues. Ciência da Informação: Ciência Recursiva no Contexto da Sociedade da Informação. Disponível em: < http://www.scielo.br/scielo.php?pid=S0100-19652000000300005&script=sci_

arttext&tlng=es >. Acesso em 21 de Setembro de 2008.

GARCIA, Renato; ROSELINO, José Eduardo. Avaliação Crítica dos Resultados da Lei da Informática e seus reflexos sobre o Complexo Eletrônico. Campinas: Unicamp, 2002.

KERZNER, Harold. Gestão de Projetos: as Melhores Práticas. Tradução: Marco Antônio Viana Borges, Marcelo Klippel e Gustavo Severo de Borba. Porto Alegre: Bookman, 2002.

MARTINELI, Rosa Maria Feltrim. Tecnologia da Informação na Construção do Conhecimento: Uma Abordagem a partir do Modelo de Nonaka & Takeuchi. Florianópolis: Universidade Federal de Santa Catarina, 2001.

MARTINS, Andréia P.; MARTINS, Marcelo R.; PEREIRA, Márcia M.; MARTINS, Vergílio A. Implantação e Consolidação de Escritório de Gerenciamento de Projetos: Um Estudo de Caso. Revista Produção: São Paulo, 2005.

MOURA, Gisela Garcia. Comportamentos de Resistência a Mudança da Média Gerência Diante da Implantação da NBR ISSO 9000. Florianópolis: Universidade Federal de Santa Catarina, 2002.

NAZARENO, Cláudio. O Software, a Legislação Brasileira e Proposições em Andamento na Câmara. Brasília: Câmara dos Deputados, 2004.

PETRI, Flávia de; et al. Uma Experiência de Capacitação e Inicio de Melhoria de Processo de Software com o Método PRO2PI-WORK. Universidade São Judas Tadeu: São Paulo, 2005.

RABECHINI, Roque; CARVALHO, Marly Monteiro de. Perfil das Competências em Equipes de Projetos. Fundação Getúlio Vargas: São Paulo, 2002.

REZENDE, Denis Alcides. Metodologia para Projeto de Planejamento Estratégico de Informações Alinhado ao Planejamento Estratégico: a Experiência do Senac-PR. Brasília: Ci. Inf, 2003.

SOFTEX. MPS.BR – Melhoria de Processo do Software Brasileiro, Guia Geral (v.1.1). Sociedade SOFTEX, Brasil, 2007.

SOFTEX. Guia de Implementação – Parte 1: Nível G (v.1.1). Sociedade SOFTEX, Brasil, 2007

SUZIGAN, Wilson. Estado e Industrialização no Brasil. Campinas: Revista de Economia Política, 1988.

SZIMANSKI, Fernando; ROUILLER, Ana Cristina; SOUZA, Adler Diniz de. Aplicando MPS.BR nível G na Melhoria do Processo de Desenvolvimento de Software numa Pequena Empresa. Criativa Sistemas: Gurupi, 2006.

ANEXO 1

LEGISLAÇÃO BRASILEIRA

A relação apresentada a seguir[23] é o resumo da legislação brasileira que trata do assunto da informática e da produção de software até 2001. Para cada lei citada, é exposta a sua ementa e a explicação resumida do dispositivo legal.

ANEXO 2

ISO/IEC e CMMI[24]

ISO/IEC 12207 e suas emendas 1 e 2

A Norma ISO/IEC 12207 foi criada pela ISO – International Organization for Standardization e o IEC - International Electrotechnical Commission dentro de um esforço conjunto dessas organizações.

Em 1988, foi proposto o desenvolvimento da norma e em agosto de 1995 ela foi publicada como norma internacional. Em 1998, foi publicada a sua versão brasileira que tem o mesmo nome que a internacional, somente acrescida das iniciais NBR.

Em outubro de 2002 e 2004, foram feitas atualizações na norma ISO/IEC 12207, chamadas de emendas 1 e 2 respectivamente, onde foram inseridas algumas melhorias. Essas melhorias criaram novos ou expandiram escopo de alguns processos, inseriram para cada processo o seu propósito e resultados e para os novos processos definiram suas atividades e tarefas. Essas modificações têm o objetivo de representar a evolução da Engenharia de Software, as necessidades vivenciadas pelos usuários da norma e a harmonização com a série ISO/IEC 15504 - Avaliação de Processo.

A norma ISO/IEC 12207 e suas emendas 1 e 2 estabelecem uma arquitetura comum para o ciclo de vida de processos de software com uma terminologia bem definida.

Contém processos, atividades e tarefas a serem aplicadas durante o fornecimento, aquisição, desenvolvimento, operação e manutenção de produtos de software e serviços correlatos.

Os processos definidos na NBR ISO/IEC 122075 devem ser utilizados como referência na implementação do MR-MPS e avaliação seguindo o MA-MPS. É possível realizar inclusões de novos processos ou exclusões e alterações de processos que não sejam pertinentes ao negócio, seguindo o processo de adaptação da NBR ISO/IEC 12207.

ISO/IEC 15504

Em setembro de 1992, a ISO realizou um estudo chamado "Necessidades e Exigências para uma Norma de Avaliação de Processos de Software". O trabalho concluiu que era pertinente a elaboração de uma norma que fosse aplicável à melhoria de processos e à determinação da capacidade. Este padrão deveria considerar os métodos e normas já existentes (como por exemplo, o SW-CMM® e a ISO 9001), abranger todos os processos de software e ser construído pelos especialistas que já desenvolviam e trabalhavam com os métodos e normas existentes à época. Como resultado desse primeiro trabalho, a ISO iniciou em janeiro de 1993 o projeto SPICE (Software Process Improvement and Capability Determination) com o objetivo de produzir inicialmente um relatório técnico que fosse, ao mesmo tempo, mais geral e abrangente que os modelos existentes e mais específico que a norma ISO 9001 originando assim a série de normas ISO/IEC 15504 [ISO/IEC 15504-1, 2004] [ISO/IEC 15504-2, 2003] [ISO/IEC 15504-3, 2004] [ISO/IEC 15504-4, 2004] [ISO/IEC 15504-5, 2006].

A ISO/IEC 15504 presta-se à realização de avaliações de processos de software com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de uma unidade organizacional. Se o objetivo for a melhoria de processos, a unidade organizacional pode realizar uma avaliação com o objetivo de gerar um perfil dos processos que será usado para a elaboração de um plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos. No segundo caso, a organização tem o objetivo de avaliar um fornecedor em potencial, obtendo o seu perfil de capacidade. O perfil de capacidade permite ao contratante estimar o risco associado à contratação daquele fornecedor em potencial para auxiliar na tomada de decisão de contratá-lo ou não.

CMMI-DEVSM

O modelo SW-CMM® (Software Capability Maturity Model) foi definido no SEI (Software Engineering Institute) a pedido do Departamento de Defesa dos Estados Unidos. A partir de 1991, foram desenvolvidos CMMs® para várias disciplinas (Engenharia de Sistemas, Engenharia de Software, Aquisição de Software, Gerência e Desenvolvimento da Força de Trabalho, Desenvolvimento Integrado do Processo e do Produto). Embora estes modelos tenham mostrado sua utilidade, o uso de múltiplos modelos se mostrou problemático. O CMMISM surgiu para resolver o problema de se usar vários modelos e é o resultado da evolução do SW-CMM®, SECM® (System Engineering Capability Model) e IPD-CMM® (Integrated Product Development Capability Maturity Model). É, portanto, o sucessor destes modelos.

Além disso, o framework CMMISM foi desenvolvido para ser consistente e compatível com a ISO/IEC 15504. Em 2006 foi publicada a versão 1.2 do CMMI, o CMMI-DEV (CMMI for Development) [SEI, 2006].

ANEXO 3

ATRIBUTOS DE PROCESSOS E OS RESPECTIVOS RESULTADOS ESPERADOS[25]

AP 1.1.O processo é executado

Este atributo é uma medida do quanto o processo atinge o seu propósito. O resultado esperado é:

RAP 1. O processo atinge seus resultados definidos.

AP 2.1.O processo é gerenciado

Este atributo é uma medida do quanto a execução do processo é gerenciada. Os resultados esperados são:

RAP 2. Existe uma política organizacional estabelecida e mantida para oprocesso.

RAP 3. A execução do processo é planejada.

RAP 4 (Para o Nível G). A execução do processo é monitorada e ajustes são realizados para atender aos planos.

RAP 4 (A partir do Nível F). Medidas são planejadas e coletadas para monitoração da execução do processo.

RAP 5. Os recursos necessários para a execução do processo são identificados e disponibilizados.

RAP 6. As pessoas que executam o processo são competentes em termos de

formação, treinamento e experiência.

RAP 7. A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento no projeto.

RAP 8. Métodos adequados para monitorar a eficácia e adequação do processo são determinados.

RAP 9. (A partir do Nível F) A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente e são tratadas as não conformidades.

AP 2.2.Os produtos de trabalho do processo são gerenciados

Este atributo é uma medida do quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente. Os resultados esperados são:

RAP 10. Requisitos para documentação e controle dos produtos de trabalho são estabelecidos.

RAP 11. Os produtos de trabalho são documentados e colocados em níveis apropriados de controle.

RAP 12. Os produtos de trabalho são avaliados objetivamente com relação aos padrões, procedimentos e requisitos aplicáveis e são tratadas as não conformidades.

AP 3.1. O processo é definido

Este atributo é uma medida do quanto um processo padrão é mantido para apoiar a implementação do processo definido. Os resultados esperados são:

RAP 13. Um processo padrão é definido, incluindo diretrizes para sua adaptação para o processo definido.

RAP 14. A seqüência e interação do processo padrão com outros processos são determinadas.

AP 3.2 O processo está implementado

Este atributo é uma medida do quanto o processo padrão é efetivamente implementado como um processo definido para atingir seus resultados. Os resultados esperados são:

RAP 15. Dados apropriados são coletados e analisados, constituindo uma base para o entendimento do comportamento do processo, para demonstrar a adequação e a eficácia do processo, e avaliar onde pode ser feita a melhoria contínua do processo.

AP 4.1 O processo é medido

Este atributo é uma medida do quanto os resultados de medição são usados para assegurar que o desempenho do processo apóia o alcance dos objetivos de desempenho relevantes como apoio aos objetivos de negócio definidos. Os resultados esperados são:

RAP 16. As necessidades de informação requeridas para apoiar objetivos de negócio relevantes da organização e dos projetos são identificadas.

RAP 17. A partir do conjunto de processos-padrão da organização e das necessidades de informação são selecionados os processos e/ou elementos do processo que serão objeto de análise de desempenho.

RAP 18. Objetivos de medição do processo e/ou sub-processo são derivados das necessidades de informação.

RAP 19. Objetivos quantitativos de qualidade e de desempenho dos processos e/ou sub-processos são derivados das necessidades de informação.

RAP 20. Medidas e a freqüência de realização das medições são identificadas e definidas de acordo com os objetivos de medição do processo/sub-processo e os objetivos quantitativos de qualidade e de desempenho do processo.

RAP 21. Resultados das medições são coletados, analisados e reportados para monitorar o atendimento dos objetivos quantitativos de qualidade e de desempenho do processo/sub-processo.

RAP 22. Resultados de medição são utilizados para caracterizar o desempenho do processo/sub-processo.

AP 4.2 O processo é controlado

Este atributo é uma medida do quanto o processo é controlado estatisticamente para produzir um processo estável, capaz e previsível dentro de limites estabelecidos. Os resultados esperados são:

RAP 23. Técnicas de análise e de controle de desempenho são identificadas e aplicadas quando necessário.

RAP 24. Limites de controle de variação são estabelecidos para o desempenho normal do processo.

RAP 25. Dados de medição são analisados com relação a causas especiais de variação.

RAP 26. Ações corretivas são realizadas para tratar causas especiais de variação.

RAP 27. Limites de controle são redefinidos, quando necessário, seguindo as ações corretivas.

RAP 28. Modelos de desempenho do processo são estabelecidos e mantidos.

AP 5.1 O processo é objeto de inovações

Este atributo é uma medida do quanto as mudanças no processo são identificadas a partir da análise de causas comuns de variação do desempenho e da investigação de enfoques inovadores para a definição e implementação do processo. Os resultados esperados são:

RAP 29. Objetivos de melhoria do processo são definidos de forma a apoiar os objetivos de negócio relevantes.

RAP 30. Dados adequados são analisados para identificar causas comuns de

variação no desempenho do processo.

RAP 31. Dados adequados são analisados para identificar oportunidades para aplicar melhores práticas e inovações.

RAP 32. Oportunidades de melhorias derivadas de novas tecnologias e conceitos de processo são identificadas.

RAP 33. Uma estratégia de implementação é estabelecida para alcançar os

objetivos de melhoria do processo.

AP 5.2 O processo é otimizado continuamente

Este atributo é uma medida do quanto as mudanças na definição, gerência e desempenho do processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo. Os resultados esperados são:

RAP 34. O impacto de todas as mudanças propostas é avaliado com relação aos objetivos do processo definido e do processo padrão.

RAP 35. A implementação de todas as mudanças acordadas é gerenciada para assegurar que qualquer alteração no desempenho do processo seja entendida e sejam tomadas as ações pertinentes.

RAP 36. A efetividade das mudanças, levando em conta o seu desempenho resultante, é avaliada com relação aos requisitos do produto e objetivos do processo, para determinar se os resultados são devidos a causas comuns ou especiais.

[1]MEIRA, Silvio Lemos. Formação de Recursos Humanos, Pesquisa e Desenvolvimento: Bases para uma política de Informática. MCT/SEPIN, 1993.

[2]TIGRE, P.B. Liberalização e Capacitação Tecnológica: O Caso da Informática Pós-Reserva de Mercado no Brasil. Rio de Janeiro: Universidade Federal do Rio de Janeiro, 1993.

[3] BORKO, H. Information Science: What's is its ? Washington: American Documentation, 1968.

[4] INGWERSEN, P. Information Retrieval Interaction. London: Taylor Graham, 1992.

[5] HWANG, Kai; BRIGGS, Fayé A. Computer Architecture and Parallel Processing. Singapore: McGraw-Hill, 1985.

[6] MCNEALY, Scott. Por um mundo (sempre) conectado. HSM Management, nº 24, ano 4, jan-fev 2001.

[7]WAH, L. Muito além de um modismo. HSM Management, São Paulo, n.22, p.51-54. set/out 2000.

[8]Vide Anexo 2 para detalhes sobre ISO/IEC 12207, ISO/IEC 15504 e CMMI-DEV.

[9]SOFTEX. MPS.BR (2007)

[10] Disponível em: <http://www.pentagrama.com.br/website/tecnologia.php?cod=5>. Acesso em 30 de Setembro de 2008.

[11]SOFTEX. MPS.BR (2007)

[12] UNIVERSITY OF BRIDGEPORT. Project Management Systems (CPM/PERT). Disponível em <http://www.bridgeport.edu/sed/projects/cs597/unfiled/zhipingli/Wbs.gif>. Acesso em 16 de novembro de 2008.

[13]MICROSOFT.Aprimorando a Segurança dos Aplicativos da Web; Ameaças e Contramedidas. Disponível em <http://www.microsoft.com/brasil/security/guidance/topics/devsec/images%5CSGFG07102.jpg>. Acesso em 16 de novembro de 2008.

[14] BUGZILLA BUG TRACKING SYSTEM. Bug Resolution Worflow. Disponível em <http://osdir.com/ml/bug-tracking.bugzilla.devel/2004-01/msg00135.html>.Acesso em 20 de novembro de 2008.

[15]MORGAN, J. Administração da Mudança. Rio de Janeiro: Zahar Editores, 1996.

[16] BENNIS, V.F. Organizações em Mudança. São Paulo: Editora Atlas, 1976.

[17] CRAWFORD, J.K. The Strategic Project Office: A Guide to Improving Organizational Perfomance. New York: Marcel Dekker Inc, 2002.

[18] SZIMANSKI, Fernando et al. Aplicando MPS.BR nível G na melhoria de processo de desenvolvimento de software numa pequena empresa. Criativa Sistemas: Gurupi, (2006)

[19]SZIMANSKI, Fernando et al. Aplicando MPS.BR nível G na melhoria de processo de desenvolvimento de software numa pequena empresa. Criativa Sistemas: Gurupi, (2006)

[20] CARVALHO, A.B. O que esperar da série ISO 9000. Banas Qualidade, São Paulo, n.100, p.42, set.2000

[21] FRAME, J.D., Project Management Competence: Building Key Skills for Individuals, Teams, and Organizations. San Francisco: Jossey-Bass Publishiers, 1999.

[22] THAMHAIN, H.J. Team Building in Project Management. New York: Van Nostrand Reinhold, 1993.

[23]NAZARENO, Cláudio. O Software, a Legislação Brasileira e Proposições em Andamento na Câmara. Brasília: Câmara dos Deputados, 2004.

[24] SOFTEX. MPS.BR – Melhoria de Processo do Software Brasileiro, Guia Geral (v.1.1). Sociedade SOFTEX, Brasil, 2007.

[25] SOFTEX. MPS.BR – Melhoria de Processo do Software Brasileiro, Guia Geral (v.1.1). Sociedade SOFTEX, Brasil, 2007.