GERENCIAMENTO DE PROJETO = Arquivo 1A

Caros Alunos, segue material de apoio para nossas aulas " GERENCIAMENTO DE PROJETO"
Para baixar, é só clicar: AQUI

Alunos de ADM UNIP

Caros leitores, essa postagem é direcionada aos meus alunos do curso de Administração - Universidade Unip. O Arquivo é sobre os conceitos de estoque (logística) e servirá de base para elaboração do projeto "Loja Virtual" .

Para baixar o arquivo, é só clicar AQUI
Abs.

Caros leitores, esse post inaugura aqui uma nova fase do blog; quero torna-lo mais didático possível de forma que possa também ser utilizado por meus alunos como fonte de consulta, a ideia é ir aos poucos deixando esse blog como um guia de certificação e melhores práticas de gerenciamento. Podem opinar à vontade!

Boa leitura!

flavio.falcao@gmail.com

Uma breve História da Gerência de Projeto

Como uma disciplina, a gerência de projeto foi desenvolvida de diversos campos de aplicação diferentes, incluindo a construção, a engenharia mecânica, projetos militares, etc. Nos Estados Unidos, o 'pai’ da gerência de projeto é Henry Gantt, chamado o pai de técnicas do planejamento e do controle, que é conhecido pelo uso do gráfico de 'barra' como uma ferramenta de gerência do projeto, para ser um associado as teorias de Frederick Winslow Taylor da administração científica, e para seu estudo do trabalho e da gerência do edifício do navio da marinha. Seu trabalho é o precursor a muitas ferramentas de gerência modernas do projeto, tais como a WBS (work breakdown structure) ou EAP (estrutura analítica do projeto) de recurso que avalia o trabalho. Os anos 50 marcam o começo da era moderna da gerência de projeto. Outra vez, nos Estados Unidos, antes dos anos 50, os projetos foram controlados basicamente se utilizando os gráficos de Gantt, técnicas informais e ferramentas. Nesse tempo, dois modelos programando do projeto matemático foram desenvolvidos: (1) de 'Program Evaluation and Review Technique' ou o PERT, desenvolvido como a parte programa do míssil do submarino Polaris da marinha dos Estados Unidos' (conjuntamente com o Lockheed Corporation); e o (2) 'Critical Path Method' (CPM) desenvolvido em conjunto por DuPont Corporation e Remington Rand Corporation para projetos da manutenção de planta. Estas técnicas matemáticas espalharam-se rapidamente em muitas empresas. Em 1969, o Project Management Institute (PMI) foi dando forma para servir ao interesse da indústria da gerência de projeto. A premissa de PMI é que as ferramentas e as técnicas da gerência de projeto são terra comum mesmo entre a aplicação difundida dos projetos da indústria do software à indústria de construção. Em 1981, os diretores do PMI autorizaram o desenvolvimento de o que se transformou em um guia de projetos o 'Project Management Body of Knowledge', contendo os padrões e as linhas mestras das práticas que são usados extensamente durante toda a profissão. (fonte Wikpedia).

Guia das melhores práticas de TI - Metodologias - Repost

Amigo leitor, segue um post bem longo porém necessário, nosso mercado fervilha com mudanças de tecnologias, diariamente surgem novas certificações e cabe a nós profissionais de IT nos “anternarmos”...Minha sugestão é: Aprenda muito sobre o core da sua empresa isso faz muita diferença! Além de dominarmos a nossa área de atuação, precisamos também acompanhar nem que seja de forma superficial as mudanças que ocorrem a nossa volta; senão estaremos mortos profissionalmente. Tudo o que eu escrevo aqui, é reflexo do meu dia a dia, tenho 35 anos de idade, dos quais 16 dedicados a TI, já atuei em Help desk´s, administrando redes, Instalando servidores, desenvolvendo aplicações, gerenciando projetos e por aí vai...Ou seja, se quisermos continuar no mercado, temos que acompanhar as tendências e mudar na hora certa, segue abaixo um compilado do que temos hoje por aí...Espero que esse texto lhe ajude a enxergar as tendências e talvez até um ajuste no seu plano de carreira!

P.S.

Deixei de fora as metodologias de gerenciamento de projetos (PMI, Prince2 Etc.) Porque pretendo fazer um post especialmente desse assunto.

Aos leitores que me escreveram e ainda não foram respondidos, peço um pouco mais de paciência...O volume aumentou de 10 por semana para mais de 150! Agradeço a todos pela audiência, responderei a todos os e-mails só vou demorar um pouco mais, portanto continuem a escrever, pois a maior parte dos assuntos aqui abordados vem do que vocês escrevem.

Um abraço!

Especial: um guia de certificações e melhores práticas de TI

Amedrontadas com o poderio industrial do Japão nos anos 80, as empresas norte-americanas converteram-se a uma religião – a religião da qualidade. Elas se apressaram em aprimorar seus processos de negócios adotando diversos modelos de qualidade, como ISO 9000 para a corporação, Six Sigma para a fábrica e CMM (capability maturity model) para engenharia de software.

Hoje, os gerentes de TI têm um leque oceânico de disciplinas de qualidade à disposição. Algumas, como Six Sigma e ISO 9000, podem ser impostas ao diretor de TI pelo CEO. Outras, como CobiT (control objectives for information and related technology), podem ser exigidas por seus auditores. E disciplinas focadas em TI podem ter origem em suas próprias instalações, como CMM para desenvolvimento de software e ITIL (information technology infrastructure library) para operações e serviços de TI.

Embora haja alguma sobreposição entre esses modelos de qualidade, na maior parte dos casos eles não entram em conflito. Na verdade, a maioria das grandes empresas usa dois ou três deles. A IBM, por exemplo, utiliza ISO 9000, CMM, ITIL, Six Sigma e vários programas de qualidade criados internamente. Já outras não usam nenhum deles, preferindo ter os seus próprios. A MasterCard International adaptou partes de diversos programas ao seu próprio modo de fazer negócio. Realizou uma avaliação externa de CMM um ano atrás e implementou algumas idéias a partir daí, mas não implantou o modelo formalmente.

Para algumas companhias, um selo de aprovação de um organismo externo, como certificação ISO 9000 ou CMM, pode ser um fator importante. Uma empresa na área de defesa, por exemplo, talvez não consiga trabalhos se não tiver uma alta avaliação CMM. E um selo ISO 9000 pode ser uma exigência para fazer negócio, principalmente fora dos Estados Unidos.

Mas uma empresa pode se exceder em qualquer destes programas, observa Matt Light, analista do Gartner. "Temos uma filosofia chamada ‘apenas o processo suficiente’", diz ele. "Criar seu próprio programa e aplicá-lo somente onde faz sentido costuma ser a melhor opção para organizações que não têm exigências de certificação."

De qualquer forma, alguma coisa você deve fazer no front da qualidade, recomenda Michael J. Ashworth, CIO da unidade de banco de investimento da J.P. Morgan Chase & Co. "Todas estas coisas são apenas maneiras melhores de fazer o que as pessoas estão tentando fazer com um fim específico", diz ele. "Não são um ritual sem sentido; são o senso comum codificado."

IT Infrastructure Library (ITIL)

Responsáveis: Escritório de Comércio do governo Reino Unidos, Pink Elephant e outros.

O que é: Conjunto de melhores práticas para operações e gerenciamento de serviços de TI (como gerenciamento de service desk, incidente, mudança, capacidade, nível de serviço e segurança). Especialmente popular na Europa. O ITIL rastreia problemas em áreas de serviço de TI como help desk, suporte a aplicações, distribuição de software e suporte a sistemas de contato com o cliente e se sobrepõe a CMM em determinadas áreas, como gerenciamento de configuração. O ITIL rastreia, por exemplo, as mudanças feitas em sistemas operacionais, mas a qualidade dessas mudanças — em termos do número e da gravidade de problemas resultantes delas — é uma métrica de CMM.

Pontos fortes: Bem estabelecido, amadurecido, detalhado e focado em questões de qualidade operacional e produção de TI. Pode ser combinado a CMMI para cobrir tudo relacionado a TI.

Limitações: Não aborda o desenvolvimento de sistemas de gerenciamento de qualidade. Não é voltado para processos de desenvolvimento de software. Seu uso depende imensamente de interpretação.

Da informalidade aos processos estruturados.

Six Sigma

Responsável: Desenvolvido pela Motorola.

O que é: Um método de aprimoramento de processo estatístico que enfoca a qualidade do ponto de vista do cliente ou do usuário. Define níveis de serviço e mede variações em relação a estes níveis. Os projetos percorrem cinco fases: definir, medir, analisar, aprimorar e controlar. A variante Design for Six Sigma aplica os princípios deste método à criação de produtos ou serviços sem defeitos, e não ao aprimoramento dos que já existem.

Pontos fortes: Uma abordagem orientada a dados para descobrir a raiz de problemas de negócio e resolvê-los. Leva em conta o custo de qualidade. Em TI, é melhor aplicado em atividades passíveis de repetição e relativamente homogêneas, como operações de call center ou help desk. Design for Six Sigma pode ajudar a desenvolver boas especificações de software.

Limitações: Projetado originalmente para ambientes de manufatura; pode ser difícil aplicá-lo em processos que ainda não estão bem definidos e mensuráveis. Pode aprimorar o processo, mas não diz se você tem o processo certo.

CobiT

Há um ano, Jairo Martins saiu da área de negócios da Siemens Mercosul para ocupar a posição o CIO. Logo de início, desenvolveu um trabalho de ouvidoria com as várias unidades do grupo para saber quais eram as principais queixas em relação ao departamento de TI. O resultado foi desastroso: todas as unidades reclamaram que eram surpreendidas com despesas novas de TI, não viam transparência na apresentação dos custos e nem uma sistemática de tarifação (billing).

A falta de planejamento levou Martins à decisão de adotar o CobiT. O objetivo com a implantação da metodologia foi dar a sua equipe condições para alinhar a infra-estrutura da área aos negócios da empresa, de modo que ouvissem as necessidades dos usuários internos e informar todos os dados que eles julgarem pertinentes. Além disso, a idéia do Cobit é estabelecer parâmetros para subcontratar serviços e se estruturar para geri-los com qualidade. "O Cobit é a mais ampla metodologia para se fazer a gestão de TI e a escolhi porque ela vai me ajudar a gerir a área, ordenar processos internos e obter uma série de benefícios", acredita Martins.

Em julho de 2003, Martins contratou a Big Five Consulting para treinar seu pessoal e deu início à criação de um projeto interno de Cobit. Como líder do projeto, Martins conta que, no momento, ele está adaptando a metodologia para a realidade da Siemens e definindo procedimentos. Com o Cobit, a Siemens quer obter otimização de custos, uma boa gestão da qualidade dos serviços prestados e a garantia da disponibilidade das plataformas de TI.

Apesar de o Cobit ainda se encontrar em fase de implantação (60% dele já foi adotado), ele já trouxe benefícios à empresa. A criação de um comitê de governança de TI, que se reúne a cada trimestre com representantes de todas as unidades da empresa, é resultado da implantação da metodologia. "Nós também conseguimos obter transparência dos custos, que agora são repassados com maior clareza para as áreas, melhora na comunicação com as unidades de negócio, além de uma melhor estruturação dos processos para gestão de TI."

Martins acredita que, até o final deste ano, o Cobit atinja a maturidade 3 dentro da Siemens. Hoje ela está em 2.4. A implantação total do projeto deve se encerrar em meados de 2005.

Control Objectives for Information and Related Technology (CobiT)

Responsável: Information Systems Audit and Control Association e IT Governance Institute

O que é: Um conjunto de diretrizes baseadas em auditoria para processos, práticas e controles de TI. Voltado para redução de risco, enfoca integridade, confiabilidade e segurança. Aborda quatro domínios: planejamento e organização, aquisição e implementação, entrega e suporte e monitoração. Apresenta seis níveis de maturidade, similares aos de CMM.

Pontos fortes: Permite que TI aborde riscos não endereçados explicitamente por outros modelos e que seja aprovada em auditorias. Funciona bem com outros modelos de qualidade, principalmente ITIL.

Limitações: Diz o que fazer, mas não como fazer. Não lida diretamente com desenvolvimento de software ou serviços de TI. Não fornece um "road map" para aprimoramento contínuo de processos.

Lance Turcato, diretor de supervisão de segurança e infra-estrutura de tecnologia da Charles Schwab & Co., define CobiT como uma "ferramenta de governança de TI" que ajuda os gerentes de informática a entender quais controles são necessários e a medir a eficácia destes controles. "Faz parte uma ferramenta de auditoria para que os auditores possam auditar seguindo estes mesmos critérios", acrescenta Turcato.

CobiT demanda um esforço considerável para ser integrado a processos de uma empresa. "As instruções em CobiT são muito genéricas. Fomos obrigados a transformá-lo em ‘linguagem Schwab’ para que as pessoas pudessem entender", diz Turcato. "O desafio maior foi fazer todo mundo aderir. Tivemos que determinar, em todo o grupo de tecnologia, as pessoas apropriadas que possuem estes controles e educá-las em CobiT."

A Lockheed Martin tem quatro unidades no Nível 5 de CMMI. A empresa também usa disciplinas Six Sigma e ISO 9000 em diversas partes de sua organização de TI, mas CobiT é o "modelo de qualidade guarda-chuva", define CIO Joseph R. Cleveland, fornecendo checklists úteis em cada um de seus quatro domínios.

Para algo simples como acrescentar o PDA BlackBerry ao catálogo de dispositivos aprovados da empresa, por exemplo, CobiT perguntará se existe suporte de help desk para ele, se a segurança foi abordada, se já existem procedimentos para adquirir e manter o dispositivo e assim por diante.

Cliveland diz que CobiT se integra bem com CMMI - CobiT detecta a necessidade de determinados controles e CMMI implanta-os. As dúvidas dos auditores sempre podem ser satisfeitas com aspectos de CMMI, segundo Cliveland.

CMM - Software com selo de maturidade

Certificação CMM confere um planejamento mais confiável , aumentando a probabilidade de os recursos da aplicação e ganhar um crachá de merecimento para o mundo inteiro ver — O executivo explica que a certificação foi essencial para que a empresa se firmasse como exportadora de software

Durante 15 anos, as empresas que quiseram aprimorar significativamente suas práticas de desenvolvimento de software — e ganhar um crachá de merecimento para o mundo inteiro ver — percorreram um longo e árduo caminho chamado CMM for software, uma linha de ação capaz de levá-las de um estado de semicaos (onde a maioria está hoje) a uma condição marcada pela precisão, capacidade de repetir procedimentos e baixa taxa de erro normalmente associados a uma linha de montagem de manufatura.

O CMMI, apresentado recentemente pelo Software Engineering Institute, é um modelo de maturidade de processo mais abrangente que combina CMM for software com disciplinas mais amplas nas áreas de engenharia de sistemas e desenvolvimento de produtos. Futuramente, o instituto vai parar de suportar CMM for software em favor do CMMI.

A instalação de TI do JP Morgan Chase usa CMM for software, ao passo que o grupo, no geral, trabalha sob Six Sigma. "Nossas equipes de desenvolvimento alcançaram o CMM nível 2 e estão a caminho do nível 3 em alguns casos", revela Michael Ashworth, CIO da unidade de banco de investimento da JP Morgan Chase & Co. O CIO diz que a mudança do nível 1 para o nível 2 gerou um planejamento mais confiável, aumentando a probabilidade dos recursos da aplicação estarem certos da primeira vez e reduzindo, portanto, a tarefa onerosa de refazer o trabalho.

Passar de um nível de maturidade ao seguinte exige dois ou mais anos de trabalho árduo e, em alguns casos, não vale o esforço, apontam alguns usuários. A Allstate Insurance, por exemplo, quer passar do nível 1 ao nível 3 e parar por aí. "Não vemos necessidade de ir para o nível 4 ou 5", diz Robin Richmond, vice-presidente assistente para Allstate Protection Technology.

No Brasil, o CMM também vem sendo cada vez mais utilizado pelas empresas. A Stefanini IT Solutions, uma das maiores consultorias nacionais de TI, sempre se preocupou em manter um bom nível de qualidade em todos os departamentos, incluindo a fábrica de software. Em 1996 a empresa obteve o certificado ISO 9001 e em 2002, deu mais um passo à frente ao receber a certificação CMM nível 2. O diretor-presidente da empresa, Marco Antônio Stefanini, diz que a homologação foi obtida em apenas 12 meses. O motivo foi o fato de a empresa já ter uma preocupação anterior com qualidade e respeitar as normas ISO 9001. O processo foi conduzido pela ISD-Brasil, empresa credenciada pelo Software Engineering Institute.

No momento, a Stefanini se encontra no meio do processo de implantação do CMM nível 3, iniciado em outubro do ano passado e com previsão de término para setembro. Até agora, os custos estão em R$ 500 mil. Em 2005, a idéia é passar para o nível 4. Apesar de considerar a implantação do CMM um processo caro e que consome muita energia, Stefanini diz que, no caso de sua empresa, a adoção é uma questão de sobrevivência.

Os resultados obtidos com o CMM? O executivo explica que a certificação foi essencial para que a empresa se firmasse como exportadora de software. Com sete subsidiárias no exterior (Argentina, Chile, Peru, Colômbia, México, Estados Unidos e Espanha), a Stefanini tem 15% de sua receita com vendas externas. Deste total, 50% são provenientes dos Estados Unidos. "O CMM é muito bem visto pelo mercado norte-americano, o que acaba se tornando um requisito básico na hora de fechar negócios com empresas internacionais", explica Stefanini.

Entre os principais benefícios já obtidos com o CMM, o executivo destaca a redução de cerca de 60% de retrabalho nos projetos, melhoria nos prazos de atendimento, que subiram de 80% para 96%, queda de 5% a 10% no custo de desenvolvimento, aumento da qualidade do trabalho e controle de gestão.

Capability Maturity Model Integration (CMMI)

Responsável: Software Engineering Institute, Carnegie Mellon University

O que é: O CMMI estende e combina o capability maturity model for software (SW-CMM), o systems engineering capability model e o integrated product development capability maturity model. SW-CMM é uma coleção de melhores práticas para desenvolvimento e manutenção de software. Permite que as empresas avaliem suas práticas e as comparem com as de outras empresas. SW-CMM mede a maturidade do processo, que progride em cinco níveis: 1 (inicial), 2 (gerenciado), 3 (definido), 4 (previsível) e 5 (otimização).

Pontos fortes: Muito detalhado. Criado especificamente para organizações de desenvolvimento de software. Enfoca o aprimoramento contínuo, e não apenas a manutenção de uma certificação. Pode ser usado para auto-avaliação.

Limitações: Não aborda aspectos de operações de TI como gerenciamento de segurança, mudança e configuração, planejamento de capacidade, diagnóstico e funções de help desk. Estabelece metas, mas não diz como atingi-las.

ISO - A excelência da qualidade

A ISO 9000 é um dos sistemas mais amplo, empregado pelas empresas nas áreas de manufatura, engenharia, marketing, vendas e TI

A americana LSI Logic é certificada em ISO 9000 desde 1992. Também usa Six Sigma e Design for Six Sigma. "Mas ISO é o sistema de qualidade mais amplo que empregamos", diz Engelbrecht. "Aplica-se a manufatura, engenharia, marketing, vendas e TI." Ele explica que, enquanto o Design for Six Sigma se concentra em projetos individuais e tenta corrigir os problemas que detecta, a ISO 9000 ajuda a fazer aprimoramentos de qualidade ano a ano. Isso é feito através de auditorias ISO 9000 anuais realizadas por auditores internos e externos.

A Nortel Networks usa a TL 9000, uma versão de ISO 9000 talhada para a indústria de telecomunicações. "A certificação é aplicada à empresa como um todo, mas iniciativas de qualidade em TI também suportam a TL 9000", diz Chris Ashwood, vice-presidente para soluções de desenvolvimento de produtos. "TL 9000 levou ISO 9000 um passo à frente no sentido de reconhecer realmente a importância de TI para o desenvolvimento de produtos."

A instalação de TI da empresa tem um conjunto de prioridades bem definido que é atualizado a cada seis meses, um scorecard para cada projeto e um processo de gerenciamento rígido para rastrear responsabilidades. "Isso se alinha muito claramente com a abordagem de ISSO — fazer o que você diz que vai fazer, rastrear responsabilidades e documentar o processo" , diz Albert Hitchcock, CEO da Nortel.

ISO 9000

Responsável: International Standards Organization

O que é: Um conjunto de padrões auditáveis de alto nível voltados ao cliente (ISO 9000, 9001 e 9004) para sistemas de gerenciamento de qualidade. Destinado a garantir controle, repetibilidade e boa documentação de processos (não de produtos).

Pontos fortes: Bem estabelecido, amadurecido. Goza de prestígio global. Pode ser aplicado em toda a corporação. Cobre desenvolvimento de software e operações e serviços de TI.

Limitações: Requer adaptação considerável quando utilizado em organizações de TI. Enfoca a repetibilidade e a consistência de processos, e não diretamente a qualidade dos processos. Não é bom para descobrir a origem de problemas.

Mind Map

Mind-Map - Uma Ferramenta de Apoio

Caros leitores, sei que para alguns, vou "chover no molhado" mas creio que essa postagem irá ajudar alguns novos profissionais no uso dessa ferramenta que é muito simples, gratuita e extremamente eficiente, eu particularmente já a uso há alguns anos e na minha opinião essa ferramenta é indispensável nas reuniões de Brain storm. Abaixo está o texto da Maria Rita Gramigna que é a perita no assunto. No final do texto tem um link para download do Mind...Lembrando que é freeware. Boa leitura

Você já imaginou trabalhar na resolução de problemas ou no acompanhamento de um projeto importante usando somente uma folha contendo desenhos, símbolos e poucas palavras? Parece impossível?

Pois existe esta possibilidade que, além de criativa, e efetiva e muito prazerosa: o Mind-Map.

TONY BUZAN e BARRY BUZAN – foram seus criadores e difundiram a ferramenta em sua obra “El libro de los mapas mentales – Como utilizar al máximo las capacidades de la mente “.

O livro não está disponível em língua portuguesa, motivo pelo qual decidi fazer um consolidado da técnica para que os leitores tivessem a oportunidade de conhecê-la e experimentá-la.

Reconhecido como poderosa técnica gráfica e a chave-mestra para acender o potencial do cérebro, o Mind-Map reproduz o pensamento irradiante e, portanto, uma função natural da mente humana..

Pode ser usado em todos os aspectos da vida com o objetivo de melhorar a aprendizagem e clarificar o pensamento. Vejamos alguns exemplos de seu uso:

• Memorização de conteúdos

• Planejamento de palestras e exposições

• Planejamento de projetos

• Tomada de decisão

• Solução de problemas

E, ainda, em tarefas simples do dia-a-dia, tais como:

• tomar notas de uma palestra;

• registrar a sequência de um seminário;

• resumir um livro ou artigo;

• definir providências de um projeto;

• registrar a pauta de uma reunião;

• registrar idéias para resolver determinado problema.

• elaborar a lista do supermercado;

• planejar um período de férias.

O Mind-Map como ferramenta de criatividade apresenta algumas vantagens:

• Aproxima a atividade do pensar à de escrever, usando símbolos, cores e palavras.

• É uma atividade estimulante que envolve as pessoas em sua montagem.

• Organiza o pensamento de maneira criativa e inovadora

• Seu visual é agradável e chama a atenção para pontos importantes do contexto.

• É uma forma objetiva e lúdica de planejamento.

• Auxilia sobremaneira na memorização de fatos e dados.

Como montar um Mind-Map?

1. O tema a ser discorrido ocupa imagem central

2. Os sub temas irradiam da imagem central de forma ramificada.

3. As ramas compreendem uma imagem ou uma palavra-chave impressa sobre uma linha associada.

4. Os pontos de menor importância também estão representados como ramas.

5. As ramas formam uma estrutura nodal conectada.

A estrutura do MIND-MAP satisfaz à tendência do cérebro humano de buscar resolução a um contexto iniciado e permite uma sequência infinita de tentativas com o uso de símbolos, desenhos e palavras. Aciona nossa base de dados, favorecendo associações, vínculos e conexões.

Apresenta três variáveis que favorecem seu uso no lugar de outros planejamentos mais ortodoxos:

1. Estimula o funcionamento global do cérebro e permite a visualização do projeto de forma gestáltica

2. Facilita o acompanhamento passo-a-passo de cada ação planejada

3. Tem como foco um ponto central – o objetivo a alcançar – e ao mesmo tempo flexibiliza o cérebro para dispersar-se e mover-se em diversas direções.

Curiosidade:

Os grandes cérebros da humanidade já se valiam dos princípios do mind-map para registro de suas anotações: Leonardo Da Vinci, Picasso, Isaac Newton, Albert Einstein. Todos usavam palavras, símbolos, seqüências, listas, análises, associações, imagens, números e desenhos que davam um ritmo visual e a dimensão gestáltica do pensar criativo.

Para elaborar um Mind-Map deve-se seguir as LEIS DA CARTOGRAFIA MENTAL:

1. Uso de uma imagem central

2. Registro de imagens em toda a extensão do mapa

3. Três ou mais cores para cada imagem

4. Destaques são registrados em volta da figura central.

5. Poucas palavras, com letras de dimensões e cores variadas

6. Desenhos ocupando espaços de forma simétrica

7. Uso de códigos e símbolos

8. Folha na horizontal

Baixe o Mind clicando AQUI

Software - Pontos de função

Pontos de Função?

Caros leitores, ultimamente tenho atuado em muitos projetos de software, e cada vez mais tem me chamado a atenção a falta de conhecimento que alguns profissionais de informática demonstram quanto ao conceito PF. O texto abaixo não é meu (ainda estou sem tempo de escrever) achei bastante didático e por isso compartilho aqui com vocês.

Um abraço!

"Pontos de função" medida funcional de tamanho de software, introduzida em 1979 por Alan Albrecht da IBM.

Medida funcional de tamanho de software é um conceito definido pelo padrão ISO/IEC 14143-1:1998 e refere-se à medição do tamanho do software considerando-se apenas a funcionalidade solicitada e recebida pelos respectivos usuários. Nesse sentido, uma medida funcional de tamanho é uma medida externa, pois mede somente aquilo que é percebido pelos usuários do produto de software, independentemente da forma de implementação escolhida.

A contagem dos pontos de função é regulamentada pelo International Function Point Users Group (IFPUG), organização internacional sem fins lucrativos sediada nos Estados Unidos da América. O IFPUG publica o Counting Practices Manual (Manual de Práticas de Contagem), atualmente em sua versão 4.2.1, que estabelece os padrões para o cálculo dos pontos de função. Para garantir a padronização dos procedimentos de contagem, o IFPUG oferece certificação na técnica e divulga os profissionais certificados através de seu site na Internet – www.ifpug.org.

O método do IFPUG foi oficializado através do padrão internacional ISO/IEC 20926 de 2002.

A contagem dos pontos de função é realizada com base em cinco tipos de componentes de software: arquivos internos, arquivos externos, entradas, saídas e consultas. Esses termos possuem um sentido específico na FPA - Function Point Analysis (Análise de Pontos de Função) e a identificação e classificação dos componentes exige conhecimento especializado.

Os pontos de função são utilizados como fator normalizador do tamanho do software, permitindo o estabelecimento de métricas tais como produtividade (pontos de função produzidos por pessoa-mês), taxa de entrega (homens-hora para a produção de um ponto de função), densidade de defeitos (defeitos encontrados por ponto de função) e outras. A taxa de entrega também pode ser denominada produtividade, o que pode causar confusão. A melhor opção é deixar clara a nomenclatura utilizada em cada caso.

Vem crescendo a utilização, pelas empresas brasileiras, dos pontos de função nos contratos de fornecimento de software, seja através da cotação de preços por ponto de função, ou através da quantificação dos serviços através de medições de pontos de função.

No mundo, os pontos de função do IFPUG são utilizados pela grande maioria das organizações que realizam algum tipo de medição funcional de tamanho de software.

Embora exista uma forte relação entre o tamanho funcional de um software (medido em Pontos de Função) e o esforço gasto no seu desenvolvimento (medido em pessoas-hora), os Pontos de Função não medem diretamente o esforço de desenvolvimento. Nesse sentido, os Pontos de Função são semelhantes ao metro quadrado na construção civil: embora o metro quadrado influa consideravelmente no esforço de construção e no custo de um imóvel, outros fatores poderão contribuir tanto ou mais quanto o metro quadrado. Exemplos de fatores são a localização do imóvel, a idade, o material utilizado na construcão e acabamento, o prestígio do arquiteto, etc. Da mesma forma, dois sistemas podem ter a mesma medida em Pontos de Função e preços totalmente diferentes. Por exemplo, um sistema pode ser monousuário, implementado em uma ferramenta como o Access; o outro pode ser uma aplicação web com várias camadas, envolvendo um mainframe e sofisticados dispositivos de segurança. Neste caso, certamente a quantidade de horas e o preço de cada um desses sistemas será completamente diferente. A conclusão é que o tamanho em Pontos de Função é apenas um dos fatores que influem sobre o esforço de desenvolvimento e sobre o custo de um sistema. Outros importantes fatores são a confiabilidade desejada para o software, a metodologia de desenvolvimento utilizada, o nível de testes requerido, a complexidade dos algoritmos, a dificuldade da plataforma computacional, o estilo de interface com o usuário, o grau de reutilização desejado, a capacidade e experiência da equipe, a disponibilidade de ferramentas de software adequadas e outros.

No passado a empresa SPR - Software Productivity Research - disponibilizava gratuitamente uma tabela de linguagens de programação na internet. Essa tabela atribuía a cada linguagem um nível, sendo fornecidos intervalos de produtividade estimados para cada nível de linguagem. Além disso, a chamada "Tabela da SPR" fornecia estimativas para a razão Linhas de Código Fonte / Ponto de Função, para cada linguagem (também chamada Fator de Backfiring). Essa tabela, embora contivesse dados estatísticos interessantes para pesquisas, foi muitas vezes indevidamente utilizada como base em relacionamentos comerciais. A própria SPR optou por primeiro retirar a tabela do ar e depois traze-la de volta, desta vez como um serviço pago. Convém ler a mensagem de Doug Brindley, vice-presidente da SPR, sobre o assunto.

É bom lembrar que a linguagem de programação é apenas um dos fatores que afetam a produtividade. Conforme explicado em outra pergunta, também são fatores importantes: a confiabilidade desejada para o software, a metodologia de desenvolvimento utilizada, o nível de testes requerido, a complexidade dos algoritmos, a dificuldade da plataforma computacional, o estilo de interface com o usuário, o grau de reutilização desejado, a capacidade e experiência da equipe, a disponibilidade de ferramentas de software adequadas e outros.

A quantidade de linhas de código por PF varia bastante e com diversos fatores, além da linguagem de programação utilizada. Por exemplo, a antiga Tabela da SPR registrava a média de 53 SLOC/PF para a linguagem JAVA. A Tabela da QSM registra 63 SLOC/PF para o JAVA e o David Consulting Group sinaliza com 80 SLOC/PF. Em uma pesquisa realizada com 8 projetos JAVA em um banco brasileiro, a mediana encontrada foi 33 SLOC/PF. Nossa recomendação é que sejam medidos alguns projetos, para poder determinar o valor médio da razão SLOC/PF em cada caso específico.

RESUMINDO:

Análise de Pontos de Função (APF) é uma técnica para a medição de projetos de desenvolvimento de software, visando estabelecer uma medida de tamanho, em Pontos de Função (PF), considerando a funcionalidade implementada, sob o ponto de vista do usuário. A medida é independente da linguagem de programação ou da tecnologia que será usada para implementação.

Sob esse contexto, os objetivos da APF são:

* medir a funcionalidade solicitada pelo usuário, antes do projeto de software, de forma a estimar seu tamanho e seu custo;

* medir projetos de desenvolvimento e manutenção de software, independentemente da tecnologia utilizada na implementação, de forma a acompanhar sua evolução;

* medir a funcionalidade recebida pelo usuário, após o projeto de software, de forma verificar seu tamanho e seu custo, comparando-os com o que foi originalmente estimado;

As organizações podem aplicar a Análise de Pontos por Função como:

* uma ferramenta para determinar o tamanho de pacotes de software adquiridos, através da contagem de todos os Pontos por Função incluídos no pacote;

* uma ferramenta para apoiar a análise da qualidade e da produtividade;

* um mecanismo para estimar custos e recursos envolvidos em projetos de desenvolvimento e manutenção de software;

* um fator de normalização para comparação de software.

Para saber mais: flavio.falcao@gmail.com

De volta!

Caros leitores, estou de volta! Foram duas semanas sem nenhum tempo para atualização do blog...Como eu já disse antes, gerenciar projetos dá trabalho! Enfim projeto devidamente implantado, circuito de palestras completo! Quero agradecer ao pessoal de Baurú e Marília que me receberam de uma forma muito hospitaleira, só não vou mencionar nomes aqui para não cometer o pecado de esquecer alguem.

Respostas aos e-mails recebidos:
É fantástico o número de e-mails que tenho recebido! A maioria deles com algum tipo de solicitação de dicas ou até mesmo de arquivos; procuro responder a todos da melhor forma possível, então se você me escreveu, e ainda não teve resposta, é só aguardar mais um pouco. Selecionei alguns leitores para agradecer, são eles: Henio Brasil, Wendel souza, José Eduardo e o Lucas Cardoso da Bahia que cuida de uma empresa Júnior. É isso aí! vamos aumentar as fileiras de gerentes de projetos qualificados e competentes por esse Brasil!

Convites para palestras e aulas:
Um forte agradecimento aos amigos que me convidam para falar nas palestras de gerenciamento de projetos, juntos criamos uma forma clara e objetiva de disseminar nosso conhecimento, código de ética e conduta.
Se você faz parte de uma instituição ou grupo e deseja montar uma palestra ou um workshop, é só me escrever! Minhas palestras são gratuitas em São Paulo, fora de SP só cobro as despesas de viagens.
Bom...É isso!! Aguardem as novas postagens!
Um abraço

8.000 Visitas

Caros leitores, quero agradecer aos e-mails que tenho recebido, e dizer que alcançamos o volume de 8.000 visitas! Sete meses de vida! Dois contadores somados...Esse número se torna mais expressivo ainda, quando comparado com o tipo de conteúdo que temos aqui, ou seja direcionado e segmentado... O público do GF ,Você leitor! É um público de qualidade, diferenciado, que não está simplesmente surfando na net...Quem chega aqui no blog, é porque tem um objetivo e um foco!




Freqüência: Como todos sabem mantenho esse blog sozinho e devido a compromissos profissionais, não tenho conseguido escrever com a mesma freqüência, afinal...Implantar projetos demanda tempo.
Mas, só mais alguns dias e voltaremos com a regularidade nas postagens, voltando à normalidade.
Um abraço
Flávio
Dúvidas, críticas e sugestões, são sempre bem vindas...Escrevam:
e-mail: flavio.falcao@gmail.com

PMI- Portfólio, Programas e sub-projetos

Caros leitores, infelizmente a falta de tempo não me permitiu fazer hoje a postagem sobre a certificação Prince2, pois o tema requer muita atenção e cuidado, retornarei com o assunto assim que possível.
Hoje optei por postar um tema que apesar de relativamente simples geram muitas dúvidas, recebo ao menos 5 e-mail´s por dia relacionados a portfólio de projetos.
Vamos aos conceitos:

O PMBok traz o conceito de agrupamento que visa facilitar o gerenciamento de projetos.

Portfólio: grupo de programas e/ou projetos que gerenciados de forma consolidada garantem o atendimento das estratégias de negócios da empresa.

Programas: grupo de projetos que gerenciados de forma consolidada trará benefícios que não seriam possíveis se cada um fosse gerenciado de forma isolada

Sub-projetos: são sub-divisões de um projeto maior ou de grande complexidade para facilitar o gerenciamento do projeto.

Lembrando que todo projeto é dividido em fases. As fases também facilitam o gerenciamento porque permitem estabelecermos os entregáveis e os critérios de aceitação para encerramento da fase e início da fase seguinte.

Conceitualmente, ficou claro?
Dúvidas: flavio.falcao@gmail.com

Montando Cronogramas - Itens fundamentais

Caros leitores, mais uma semana muito corrida, infelizmente não consigo publicar aqui tanto quanto gostaria, mas fiquem certos que procuro ser o mais claro e didático possível; Na postagem de hoje, vamos trabalhar alguns itens fundamentais para se montar cronogramas com excelência

Primeiramente, vamos relembrar os processos desta área de conhecimento do PMI:

1. Definição das atividades (Activity definition-Planning)

2. Sequênciamento das atividades (Activity Sequencing-Planning)

3. Estimativa de Recursos (Activity resource estimating-Planning)

4. Estimativa de duração (Activity duration estimating-Planning)

5. Criação do cronograma (Schedule Development-Planning)

6. Controle do cronograma (Schedule Control- Monitoring & Control)

Agora, vamos falar um pouco sobre o processo de seqüenciamento. Assim que finalizamos a decomposição do work package (WBS) em atividades precisamos definir a sequência de execução.

Trata-se do network diagram – ferramenta que auxilia toda a equipe do projeto a visualizar como o projeto será executado. Existem dois tipos de Network diagram: PDM e ADM.

O PDM – Predecessor diagramming method é representado da seguinte forma:

As atividades são representadas pelos quadrados (nodes) e o relacionamento é representado pela seta. Existem 4 tipos de dependências que podem ser utilizadas:

Finish to Start

Start to Start

Start to finish

Finish to Finish

O ADM – Arrow diagramming method é representado da seguinte forma:

Aqui, as atividades são representadas pelas setas e o relacionamento é a esfera (nodes) que as interligam.

Neste tipo de diagrama só podemos utilizar Finish-to-start porém podemos colocar as atividades chamadas “dummy”, ou seja, aquelas com duração igual a zero que precisam ser representadas para que o fluxo de sequência seja corretamente seguido – normalmente são representadas por uma linha tracejada.

Existem outros itens para serem estudados como lead (antecipações) e lags (atrasos). O importante é que esta ferramenta seja compreendida e utilizada pois é um grande aliado do Gerente de Projetos.

Devido à complexidade do assunto, voltaremos ainda com o mesmo tema, fiquem à vontade para me escrever: flavio.falcao@gmail.com

Síndrome de Burnout

Caro leitor, depois de uma semana corrida, quase sem atualizações, volto aqui para falar de algo que tenho presenciado cada vez mais constante nas equipes de projetos, trata-se da síndrome de Burnout.

Na ultima semana fui testemunha de um episódio que muito me fez refletir...Estava eu em uma reunião de milestone discutindo detalhes de um projeto de Marketing, quando um dos Lideres técnicos, literalmente surtou, saiu da sala, com tanta ira, que o seu semblante estava totalmente transformado, a pessoa em questão é um ótimo profissional, já trabalhei com ele em outros projetos e seu profissionalismo, sempre falou mais alto; porém a pressão colocada em cima desse LT foi tão grande que ele simplesmente não aguentou, está afastado de licença médica, segundo o médico que atende a empresa, trata-se da Burnout...Fui pesquisar à respeito e transcrevo abaixo o que achei sobre a doença, bem como os meios de evita-la.

O post é longo, mas vale a pena

Síndrome de Burnout

A Síndrome de Burnout é um termo psicológico que descreve o estado de exaustão prolongada e diminuição de interesse, especialmente em relação ao trabalho. O termo "burnout" (do inglês "combustão completa") descreve principalmente a sensação de exaustão da pessoa acometida.

Burnout é geralmente desenvolvida como resultado de um período de esforço excessivo no trabalho com intervalos muito pequenos para recuperação, mas alguns consideram que trabalhadores com determinados traços de personalidade (especialmente de neuroses) são mais suscetíveis a adquirir a síndrome. Pesquisadores parecem discordar sobre a natureza desta síndrome. Enquanto diversos estudiosos defendem que burnout refere-se exclusivamente a uma síndrome relacionada à exaustão e ausência de personalização no trabalho, outros a percebem como um caso especial da depressão clínica mais geral ou apenas uma forma de fadiga extrema (portanto omitindo o componente de despersonalização).

A chamada Síndrome de Burnout é definida por alguns autores como uma das conseqüências mais marcantes do estresse profissional, e se caracteriza por exaustão emocional, avaliação negativa de si mesmo, depressão e insensibilidade com relação a quase tudo e todos (até como defesa emocional).

O termo Burnout é uma composição de burn=queima e out=exterior, sugerindo assim que a pessoa com esse tipo de estresse consome-se física e emocionalmente, passando a apresentar um comportamento agressivo e irritadiço.

Essa síndrome se refere a um tipo de estresse ocupacional e institucional com predileção para profissionais que mantêm uma relação constante e direta com outras pessoas, principalmente quando esta atividade é considerada de ajuda (médicos, enfermeiros, professores).

Outros autores, entretanto, julgam a Síndrome de Burnout algo diferente do estresse genérico. Para nós, de modo geral, vamos considerar esse quadro de apatia extrema e desinteresse, não como sinônimo de algum tipo de estresse, mas como uma de suas conseqüências bastante sérias.

De fato, esta síndrome foi observada, originalmente, em profissões predominantemente relacionadas a um contacto interpessoal mais exigente, tais como médicos, psicólógos, carcereiros, assistentes sociais, comerciários, professores, atendentes públicos, enfermeiros, funcionários de departamento pessoal, telemarketing e bombeiros. Hoje, entretanto, as observações já se estendem a todos profissionais que interagem de forma ativa com pessoas, que cuidam e/ou solucionam problemas de outras pessoas, que obedecem técnicas e métodos mais exigentes, fazendo parte de organizações de trabalho submetidas à avaliações.

Definida como uma reação à tensão emocional crônica gerada a partir do contato direto, excessivo e estressante com o trabalho, essa doença faz com que a pessoa perca a maior parte do interesse em sua relação com o trabalho, de forma que as coisas deixam de ter importância e qualquer esforço pessoal passa a parecer inútil.

Entre os fatores aparentemente associados ao desenvolvimento da Síndrome de Burnout está a pouca autonomia no desempenho profissional, problemas de relacionamento com as chefias, problemas de relacionamento com colegas ou clientes, conflito entre trabalho e família, sentimento de desqualificação e falta de cooperação da equipe.

Os autores que defendem a Síndrome de Burnout como sendo diferente do estresse, alegam que esta doença envolve atitudes e condutas negativas com relação aos usuários, clientes, organização e trabalho, enquanto o estresse apareceria mais como um esgotamento pessoal com interferência na vida do sujeito e não necessariamente na sua relação com o trabalho. Entretanto, pessoalmente, julgamos que essa Síndrome de Burnout seria a conseqüência mais depressiva do estresse desencadeado pelo trabalho.

A Síndrome em Professores

A burnout de professores é conhecida como uma exaustão física e emocional que começa com um sentimento de desconforto e pouco a pouco aumenta à medida que a vontade de lecionar gradualmente diminui. Sintomaticamente, a burnout geralmente se reconhece pela ausência de alguns fatores motivacionais: energia, alegria, entusiasmo, satisfação, interesse, vontade, sonhos para a vida, idéias, concentração, autoconfiança e humor.

Um estudo feito entre professores que decidiram não retomar os postos nas salas de aula no início do ano escolar na Virgínia, Estados Unidos, revelou que entre as grandes causas de estresse estava a falta de recursos, a falta de tempo, reuniões em excesso, número muito grande de alunos por sala de aula, falta de assistência, falta de apoio e pais hostis. Em uma outra pesquisa, 244 professores de alunos com comportamento irregular ou indisciplinado foram instanciados a determinar como o estresse no trabalho afetava as suas vidas. Estas são, em ordem decrescente, as causas de estresses nesses professores:

* Políticas inadequadas da escola para casos de indisciplina;

* Atitude e comportamento dos administradores;

* Avaliação dos administradores/supervisores;

* Atitude e comportamento de outros professores/profissionais;

* Carga de trabalho excessiva;

* Oportunidades de carreira pouco interessantes;

* Baixo status da profissão de professor;

* Falta de reconhecimento por uma boa aula/por estar ensinado bem;

* Alunos barulhentos;

* Lidar com os pais.

Os efeitos do estresse são identificados, na pesquisa, como:

* Sentimento de exaustão;

* Sentimento de frustração;

* Sentimento de incapacidade;

* Carregar o estresse para casa;

* Sentir-se culpado por não fazer o bastante;

* Irritabilidade.

As estratégias utilizadas pelos professores, segundo a pesquisa, para lidar com o estresse são:

* Realizar atividades de relaxamento;

* Organizar o tempo e decidir quais são as prioridades;

* Manter uma dieta balanceada e fazer exercícios;

* Discutir os problemas com colegas de profissão;

* Tirar o dia de folga;

* Procurar ajuda profissional na medicina convencional ou terapias alternativas.

Quando perguntados sobre o que poderia ser feito para ajudar a diminuir o estresse, as estratégias mais mencionadas foram:

* Dar tempo aos professores para que eles colaborem/conversem;

* Prover os professores com cursos e workshops;

* Fazer mais elogios aos professores, reforçar suas práticas e respeitar seu trabalho;

* Dar mais assistência;

* Prover os professores com mais oportunidades para saber mais sobre alunos com comportamentos irregulares e também sobre as opções de programa para o curso;

* Envolver os professores nas tomadas de decisão da escola/melhor comunicação com a escola.

Como se pode ver, o burnout de professores relaciona-se estreitamente com as condições desmotivadoras no trabalho, o que afeta, na maioria dos casos, o desempenho do profissional. A ausência de fatores motivacionais acarreta o estresse profissional, fazendo com que o profissional largue seu emprego, ou, quando nele se mantém, trabalhe sem muito esmero.

Prince2® - DELIVERABLE (Entregáveis)

Caros leitores, hoje vou detalhar um pouco mais os DELIVERABLES do projeto segundo o Prince2.

Independente de metodologia ou área de conhecimento, devemos seguir as boas práticas de gerenciamento de projetos, e a melhor delas, na minha opinião, é a de “fasear” o projeto, definindo de forma clara e objetiva o que tem que ser entregue e quando. De forma que ao final de cada fase pré estabelecida temos sempre um produto ou “ENTREGA” também conhecido como “DELIVERABLE”.

Uma das grandes vantagens do Prince2, é que por definição, ao final de cada fase deve ser produzida e entregue uma documentação que é amplamente divulgada conforme estabelecido no plano de comunicação, criado ao início e concepção de cada projeto. A vantagem é a total visibilidade e controle, contornando issues e mitigando riscos ao máximo.

Segue abaixo a lista de documentos que devem ser gerados, deixei os nomes originais em Inglês para facilitar o estudo de quem pretende se certificar, a descrição está em português.

Acceptance Criteria:
Define, de forma clara tudo o que pode ser mesurado e o que deve ser feito para que o produto final seja aceitável ao cliente.

Business Case:
A motivação ou necessidades que gerou o projeto, documento bem detalhado, destacando os principais benefícios / economias esperadas com a realização do projeto.

Checkpoint Report:
Relatório de verificação / status do trabalho para cada membro de uma equipe.

Communication Plan:
Um bom plano de comunicação, deve conter a definição, de quais tipos, que tipo de informações devem ser divulgadas e para quem. Assim como a freqüência de cada relatório.

Configuration Item Record:
Um sumário contendo quais documentos foram gerados no período com as respectivas versões.

Configuration Management Plan:
Plano- base que servirá de guia para a criação do plano de qualidade do projeto.

Customer's Quality Expectations:
As expectativas do cliente ou usuário, quanto ao nível de qualidade dos entregáveis do projeto.

Daily log:
É o diário de bordo do gerente de projetos; reuniões, atas etc.

End Project Report:
Relatório final, produzido pelo Gerente do Projeto, encaminhado diretamente ao board contendo a aderência do projeto ao PID.

End Stage Report:
Resumo entregue ao final de cada fase do projeto. Issues, riscos etc.

Exception Plan:
Plano de exceção a ser definido entre as fases do projeto.

Exception Report:
Aanálise das opções contidas no relatório da exceção, com as recomendações do gerente de projetos.

Follow-on Action Recommendations:
Compilado das recomendações para o controle de riscos e manutenção da qualidade e todas as tarefas ainda pendentes que em um future próximo pode afetar a data de entrega.

Highlight Report:
O relatório que fornece ao board do projeto um sumário com o status de cada fase em intervalos regulares.

Initiation Stage Plan:
Utilizado como o documento inicial de aprovação do projeto.

Issue Log:
Registro de issues e controle de cada fase do projeto.

Lessons Learned Log:
Lições aprendidas, problemas com fornecedores, etc.

Lessons Learned Report:
Relatório com as lições aprendidas que o podem ser úteis a outros projetos.

Off-Specification:
Solicitações for a de especificação.

Post-Project Review:
Produzido pelo gerente de projeto para que o board do projeto verifiquem se os benefícios do projeto foram atingidos.

Post-Project Review Plan:
O board do projeto, revisa e altera se necessário a verificação quanto aos resultados do projeto.

Product Breakdown Structure:
Especificação da estrutura do projeto.

Product Checklist:
Lista de verificação de entrega de produtos conforma a fase.

Product Description:
Descrição clara do produto, sua finalidade e quais os critérios de qualidade.

Product Flow Diagram:
Dependências e sequências de entregas dos produtos

Product Status Account:
Geralmente para confirmar a versão de produtos terminados.

Project Approach:
Definição do tipo de solução a ser tornados e de seu método.

Project Brief:
Reunião inicial de projeto para fornecer uma base geral aos envolvidos

Project Initiation Document:
Documento de aprovação oficial do projeto.

Project Management Team Structure & Job Definitions:
Definições da estrutura, do trabalho da equipe da gerência de projetos.

Project Issue:
Pedidos de mudança, de escopo

Project Mandate:
Início official do projeto

Project Plan:
O Board do projeto descreve como e quando os objetivos de um projeto devem ser conseguidos, mostrando os produtos principais, atividades e recursos ser requeridos no projeto.

Project Quality Plan:
Expectativas da qualidade das entregas na visão cliente.

Quality Log:
Validação ou não da qualidade do produto.

Request for Change:
Solicitação de mudança em algum entregável.

Risk Log:
Registro dos riscos a ser atualizados e monitorado.

Stage Plan:
Definições de controles de fases.

Team Plan:
Definições da equipe de gerenciamento de projetos (PMO).

Work Package:
Passagem de bastão de um membro da equipe.

Baseline:
Linha de base Congelada de um produto após uma revisão bem detalhada.

Concession:
Entregas fora-Especificação aceitas pelo board sem ação corretiva.

End Stage Assessment:
Aceite ao final de cada estágio (board)

Tolerances:
Níveis de tolerância a que um projeto é permitido quanto ao desvio de tempo e custo.

Dúvidas?? Escrevam!!

flavio.falcao@gmail.com

ABS.

Habilidades interpessoais - 2

Gerente de Projetos –Capacidade de influenciar pessoas

Outro dia, falamos sobre as habilidades interpessoais de um Gerente de Projetos; hoje, quero dar um foco maior na capacidade de influenciar pessoas e a organização. Gostaria de chamá-los para um momento de reflexão observando as figuras abaixo:

Quando um GP tem pouca influência sobre sua equipe ou organização, as preocupações tendem a tomar muito mais tempo do que deveriam. O impacto é sentido no projeto como um todo!

Vou conseguir alocar as pessoas necessárias para entregar seu projeto? Vou conseguir apoio da organização para renegociar o projeto? Conseguirei alocar os recursos quando finalizar o projeto? E por aí vai (olha a síndrome de Burnout aí...Depois vou fazer uma postagem sobre essa síndrome que vem apavorando alguns profissionais da nossa área).

Quanto maior a capacidade de influenciar, menores serão as preocupações pois o GP se sentirá mais seguro de que conseguirá negociar as necessidades de seu projeto com mais chances de sucesso...Portanto, pratique!

Abs.

Prince2® - Processos

Prince2® - Processos
Caros leitores, no tópico de hoje, vamos conhecer cada um dos processos do Prince2®, Alguns itens, quando traduzidos para o Português, perdem um pouco do sentido original ou pior, ganham novos significados, por isso optei por coloca-los todos em inglês, para visualizar melhor os processos, é só clicar na figura acima do título; lembrando que qualquer dúvida, é só perguntar (diretamente por e-mail ou na caixa de recados ao lado).

Pretendo focar o conteúdo da semana no Prince2®, falando de cada entrada e saída dos processos. Aguardem as novas postagens!
Um abraço!

Directing a Project (DP)

• DP1 Authorising Initiation

• DP2 Authorising a Project

• DP3 Authorising a Stage or Exception Plan

• DP4 Giving Ad Hoc Direction

• DP5 Confirming Project Closure

Starting Up a Project (SU)

• SU1 Appointing a Project Board Exec and Project Manager

• SU2 Deigning a Project Management Team

• SU3 Appointing a Project Management Team

• SU4 Preparing a Project Brief

• SU5 Defining Project Approach

• SU6 Planning an Initiation Stage

Initiating a Project (IP)

• IP1 Planning Quality

• IP2 Planning a Project

• IP3 Refining a Business Case and Risks

• IP4 Setting Up Project Controls

• IP5 Setting Up Project Files

• IP6 Assembling a Project Initiation Document

Controlling a Stage (CS)

• CS1 Authorising Work Package

• CS2 Assessing Progress

• CS3 Capturing Project Issues

• CS4 Examining Project Issues

• CS5 Reviewing Stage Status

• CS6 Reporting Highlights

• CS7 Taking Corrective Action

• CS8 Escalating Project Issues

• CS9 Receiving Completed Work Package

Managing Product Delivery (MP)

• MP1 Accepting a Work Package

• MP2 Executing a Work Package

• MP3 Delivering a Work Package

Managing Stage Boundaries (SB)

• SB1 Planning a Stage

• SB2 Updating a Project Plan

• SB3 Updating a Project Business Case

• SB4 Updating the Risk Log

• SB5 Reporting Stage End

• SB6 Producing an Exception Plan

Closing a Project (CP)

• CP1 Decommissioning a Project

• CP2 Identifying Follow on Actions

• CP3 Evaluating a Project

Gerente de Projetos – Habilidades Interpessoais

Gerente de Projetos – Habilidades Interpessoais

Quando falamos sobre gerenciamento de projetos lembramos logo de cronograma, controle de custos, escopo e muitas vezes esquecemos de falar sobre o profissional destacado como o Gerente de Projetos e suas atribuições interpessoais.

Além de conhecer técnicas de gerenciamento de projetos, entender o ambiente, normas e regulamentações onde seu projeto está inserido, o Gerente de Projetos precisa desenvolver competências administrativas e gerenciais além de habilidades interpessoais.

Hoje vamos focar nas habilidades interpessoais.

Comunicação – 95% do tempo de um GP é gasto com comunicação. O gerente de projetos precisa conhecer os diversos stakeholders de seu projeto e entender a necessidade de informação de cada grupo para identificar corretamente quais informações precisam ser transmitidas, como e quando, criando um plano de comunicação que torne toda a comunicação formal efetiva.

Influenciar a organização – o Gerente de Projetos é acima de tudo um facilitador na condução do projeto e neste contexto ele deve desenvolver a capacidade de conseguir fazer com que as coisas aconteçam dentro de sua organização.

Liderança e motivação– o Gerente de projetos precisa definir e comunicar os objetivos de sua equipe e motivá-los continuamente para que os mesmos sejam alcançados. O GP é responsável pelos membros de sua equipe devendo mantê-los longe da pressão para que possam produzir eficazmente.

Negociação e gerenciamento de conflito – o Gerente de projetos deve buscar sempre o entendimento entre as partes garantindo que as necessidades do cliente estejam sendo contempladas. Uma boa negociação requer a aplicação de técnicas e treino efetivo.

Resolução de problemas – Durante a execução de um projeto o Gerente de projetos irá se deparar com vários conflitos. Existem técnicas que auxiliam a investigação do problema e a identificação de alternativas para tomada de decisão. Quanto mais rápido e preciso for este processo menor será o impacto ao cronograma do projeto.

Por hoje é só! Devido a complexidade desse tema, futuramente retornarei a esse ponto para mapearmos mais detalhadamente como deve ser um plano de comunicação eficaz.

54º Happy Hour PMI - SP

Caros leitores, segue uma dica para quem mora em São Paulo. dia 25/04/08 ( sexta-feira) se realizará o tradicional happy hour que busca promover o networking e a troca de experiências entre os profissionais de gerenciamento de projetos.

Não é preciso confirmar presença. Basta procurar pela mesa do PMI-SP e fazer as apresentações. Familiares e acompanhantes são bem-vindos.

Local: Grill Hall

Rua Pedro de Toledo, 1361

São Paulo - SP

25/04/2008 a partir das 18:00

Preço para membros: R$ 0,00

Preço para não membros: R$ 0,00

Observações: Consumação mínima: R$ 21,00 (buffet de petiscos grátis). Estacionamento gratuito.

Como não é um evento formal fiquem à vontade para irem, inclusive quem (ainda) não é gerente de projetos.

Mudando de assunto, quero agradecer aos leitores que visitam o blog e mandam e-mails é muito boa a troca de experiências, continuem!

Amanhã terei um post bem interessante.

Abraços!

Gerente de Projetos a preço de banana!

Gerentes de projetos a preço de banana!

Hoje eu estava atendendo um cliente na região da Av. Paulista e por causa do trânsito (sempre ele) acabei chegando cedo demais. Tive que aguardar por quarenta minutos na sala de espera. Peguei um livro na minha mala, e quando ia começar a ler, fui abordado por um jovem de mais ou menos 23 anos, que também aguardava alguém. ”Eu conheço você!” disse ele, olhei bem para aquele rapaz, busquei no banco de dados da minha memória e nada! Não me lembrava daquele rosto; fiz aquela cara de conteúdo e disse: “É mesmo? De onde?” Prontamente ele me respondeu que havia assistido uma das minhas palestras sobre gerenciamento de projetos, e que tal palestra havia mudado a vida dele. Falou com aquele entusiasmo que só quando somos jovens possuímos, infelizmente perdemos muito disso no decorrer da vida.

Prontamente eu respondi: “Que bom! E como foi isso?”...O que veio depois, me fez ter uma tarde de reflexão quanto aos rumos que algumas empresas estão tomando. Resumindo o “bate-papo” animado que se desenrolou, o jovem me havia dito que após a minha palestra, decidiu “virar” gerente de projetos, achei muito bom ter dado uma palestra tão boa ao ponto de mudar a carreira profissional de alguém...Porém não acho que uma palestra e um curso relâmpago sejam suficientes para colocar o indivíduo na gerência de qualquer projeto corporativo; porém algumas empresas acham! Ele já estava trabalhando como “gerente de projetos” por uma consultoria e estava ali, no cliente para a primeira reunião sobre um projeto.

Fiquei muito preocupado com aquela conversa, pois ainda durante o “bate papo” fiquei sabendo que a consultoria estava pagando R$ 1.200,00 para um gerente de projetos!

Sem querer desmerecer ninguém nessa estória, muito menos o jovem! Pois ele se mostrou possuidor de uma garra fantástica! Creio que assim que tiver o treinamento e experiência adequados será um grande profissional! Eu disse será, pois não é possível ser um bom gerente de projetos sem a vivência profissional...Que empresa maluca é essa que paga R$ 1.200,00 para um gerente de projetos? Qual a qualidade disso tudo?

Digo não! Não podemos banalizar a função de gerente de projetos, não podemos permitir essas práticas de consultorias não tão éticas, que literalmente “jogam” nossos “estagiários” no mercado com o título de gerente de projetos. Viva a certificação! Viva o PMI! Viva o Prince2! Viva a qualidade no trabalho prestado! E viva os jovens que desejam ingressar na área! Mas que seja do jeito certo, com a qualificação necessária.

Gantti no Excel (de forma quase profissional)

Caro leitor, a às vezes nos encontramos em situações onde infelizmente não temos nenhuma ferramenta de gerenciamento de projetos (Project, Gantt Project, etc.)... Eu já vi cada coisa "feia" criada da mais pura necessidade de se apresentar de forma grafica as atividades de algum projeto. Funcionalmente falando, conseguimos fazer um gráfico de Gantt, até em papel sulfite; mas a idéia aqui é a de criar "algo mais" que o funcional, que possua além de informações corretas um visual agradável...Para entender claramente o que eu estou falando, vamos à prática! Enjoy!

O recurso abordado aqui é usado para exibir o avanço de tarefas de um projeto.
Para criar a tabela, siga os seguinte passos:

1. Abra o Excel, na primeira coluna de sua planilha, a partir da célula A2, escreva a lista de tarefas ou etapas do projeto em questão.

2. Na segunda coluna, a partir de B2, escreva as datas ou momentos de início de cada fase.

3. Na terceira coluna, a partir de C2, digite as datas de término de cada etapa.

AgAgora, basta criarmos o gráfico. Para simplificar sua construção, posicione o cursor em uma célula da área de dados.
1. Vá em Inserir > Gráfico. Na tela de seleção de gráficos, escolha o gráfico de barras empilhadas (segunda opção):

2. Clique em Avançar.

3. Na tela seguinte, selecione a aba Série (ou seqüência, dependendo da sua versão de Excel);

4. O Excel irá sugerir uma montagem para o gráfico, que deverá estar como abaixo. Caso não esteja , selecione as três colunas e recomece o processo.5. Clique em Avançar. Na aba Linhas de Grade, marque a opção Linhas de Grade Principais (eixo das categorias x) e Linhas de Grade Principais (eixo dos valores y).


Daqui por diante, é com você! Experimente os recursos do Excel, como eu disse no início, não fica 100% mas 90% é bem melhor que nada...Uma ótima semana à todos!
ABS.

PMI - Análise de valor agregado

A análise do valor agregado – EV (Earned Value)

A análise do valor agregado, é um método de mensuração de desempenho Introduzido nos anos 60 pelo Departamento de Defesa dos Estados Unidos para obter critérios de padrões de aceitabilidade para contratos de defesa.

· Função: Compara o valor do trabalho realizado com o custo planejado e o custo real, integrando custo, cronograma e escopo.

· Devem ser compreendidas não apenas as fórmulas mas também a interpretação

· Cerca de 6 questões de Análise do Valor Agregado, caem no exame de certificação PMP;

Entendendo:

O cálculo deve ser feito com três valores-chaves.

• (VP) Valor Planejado - Custo orçado do trabalho que deveria ter sido feito (agendado)

• (CR) Custo Real - Custo incorrido no trabalho realizado

• (VA) Valor Agregado - Quanto vale o trabalho realizado? Custo orçado para o trabalho realmente realizado.

Exemplo:

Imaginemos um projeto, em que a primeira fase já encerrou. O orçamento de R$ 300,00 estavam planejados serem gastos. R$300 foram efetivamente gastos, porém somente $200 de progresso físico foi feito.

No modo de gerenciamento tradicional, “gastamos como planejado, tudo está OK”.

Análise Tradicional:

Custo Planejado = R$ 300

Custos Reais = R$ 300 Variação em relação ao plano = R$ 0

Em EVA, gastamos como planejado, entretanto estamos atrasados e deixamos de entregar o equivalente a R$100. Nós estamos com problemas!

Análise do Valor Agregado:

Custo Planejado = R$ 300

Valor Agregado = R$ 200 Custos Reais = R$ 300

Variação de prazo (do plano):

VP = VA – VP = (R$ 100)

Variação real do custo:

VC = VA – CR = (R$ 100)

Índice de Desempenho de Custos:

IDC = VA / CR = 0,66

Índice de Desempenho de Prazos:

IDP = VA / VP = 0,66

Agora necessitamos incrementar nossa eficiência para voltarmos ao planejado e melhorá-la ainda mais se quisermos adiantar trabalho.

Lembre-se destas dicas:

O Valor Agregado é calculado em dado momento e sempre vem antes nas fórmulas acima.

Variação:

VA menos:

• Custo: CR

• Cronograma: VP

• Negativo – “Estouro”

• Positivo – Adianto

Índice:

VA dividido por

• Custo: CR

• Cronograma: VP

• Menor que 1 – “Estouro

• Maior que 1 – Economia

Fontes: Earned Value Project Management 2nd Edition, Quentin Fleming, PMI 2000, Pmbok,e Sotille

Ficou claro? Caso ainda existam dúvidas, por favor me avisem!

Abs!

Unip - Pós graduação / Formação de Professores

Caros leitores, essa postagem é exclusivamente direcionada aos alunos de pós graduação da Unip (formação de professores). O conteúdo do arquivo é uma coletânea das aulas da Professora Adriana Pelissari.
Para baixar o arquivo Aula1 , é só clicar AQUI.

Aula2 postado em 01/04 Clicar AQUI.

Amanhã vou fazer uma postagem bem interessante sobre Valor agregado (PMI).

Abs!

Prince2 - Modelo de Processo

Caros leitores, estou muito satisfeito com os e-mails recebidos! Respondi a TODOS esse final de semana...Infelizmente não tive tempo para postar algo mais detalhado; abaixo está o modelo de processo do Prince2, que apesar de confuso é bastante funcional...No decorrer dessa semana, vou postar uma material mais detalhado, pelos e-mails que tenho recebido, tem bastante gente interessada em se certificar. Eu acho isso muito bom! Precisamos divulgar mais essa metodologia!

Bom, é isso! Um abraço!!

PARA AMPLIAR, É SÓ CLICAR NA IMAGEM ABAIXO:

PMI - Caminho crítico

Vamos falar um pouco sobre caminho crítico

Uma das ferramentas mais importantes de gerenciamento de tempo em um projeto é o cálculo do caminho crítico.

O cálculo será proporcionalmente complexo ao diagrama de rede criado para o seu projeto.

O objetivo é identificar quais são as atividades do seu projeto com folga = 0, ou seja, quais são as atividades que não podem atrasar. Estas serão as atividades que o Gerente de projeto terá que acompanhar de perto pois se atrasarem, causarão impactos para o projeto.

Antes de pensar no caminho crítico você:
1. Definiu o escopo do projeto
2. Criou a WBS – Work breakdown structure
3. Identificou as atividades
4. Estimou a duração das atividades
5. Criou o diagrama de rede – sequenciamento das atividades

O cálculo do caminho crítico não considera limitações de recursos, portanto você pode ou não ter finalizado a estimativa de recursos.
Vamos exercitar:
Para facilitar você deve identificar em seu diagrama de rede: a duração de cada atividade, o início e o término de cada uma:

• ES: earlier start – início mais cedo
• EF: earlier finish – término mais cedo

Automaticamente você estará calculando o que chamamos de Forward pass ou caminho de ida.

O 2º. Passo é calcular o backward pass ou caminho de volta :

• LS: last start – início mais tardio
• LF: last finish – término mais tardio
• TF: Total Float (folga)

O caminho critico será calculado pela diferença entre LF – EF / LS – ES que resulte em 0
No exemplo acima o caminho crítico é composto por A-C-D. Para estas atividades, o início/término mais cedo é o mesmo do início/término mais tardio. Por isto o TF=O e representa que não podem ocorrer atrasos nesta sequencia de atividades sem prejudicar o cronograma do projeto.
Já a atividade B pode atrasar até 3 dias sem causar impacto ao cronograma final do projeto.
FÓRMULAS:

Este é um exemplo bem simples e calculado com base em atividades cuja relação é Finish-to-start – uma das mais comuns.
Porém existem outras relações e conceitos que precisam ser estudados – Start-to-Start, leads and lags.

Este post é apenas uma introdução. Até o próximo post.

Guia das melhores práticas de TI - Metodologias

Amigo leitor, segue um post bem longo porém necessário, nosso mercado fervilha com mudanças de tecnologias, diariamente surgem novas certificações e cabe a nós profissionais de IT nos “anternarmos”...Minha sugestão é: Aprenda muito sobre o core da sua empresa isso faz muita diferença! Além de dominarmos a nossa área de atuação, precisamos também acompanhar nem que seja de forma superficial as mudanças que ocorrem a nossa volta; senão estaremos mortos profissionalmente. Tudo o que eu escrevo aqui, é reflexo do meu dia a dia, tenho 35 anos de idade, dos quais 16 dedicados a TI, já atuei em Help desk´s, administrando redes, Instalando servidores, desenvolvendo aplicações, gerenciando projetos e por aí vai...Ou seja, se quisermos continuar no mercado, temos que acompanhar as tendências e mudar na hora certa, segue abaixo um compilado do que temos hoje por aí...Espero que esse texto lhe ajude a enxergar as tendências e talvez até um ajuste no seu plano de carreira!

P.S.

Deixei de fora as metodologias de gerenciamento de projetos (PMI, Prince2 Etc.) Porque pretendo fazer um post especialmente desse assunto.

Aos leitores que me escreveram e ainda não foram respondidos, peço um pouco mais de paciência...O volume aumentou de 10 por semana para mais de 150! Agradeço a todos pela audiência, responderei a todos os e-mails só vou demorar um pouco mais, portanto continuem a escrever, pois a maior parte dos assuntos aqui abordados vem do que vocês escrevem.

Um abraço!

Especial: um guia de certificações e melhores práticas de TI

Amedrontadas com o poderio industrial do Japão nos anos 80, as empresas norte-americanas converteram-se a uma religião – a religião da qualidade. Elas se apressaram em aprimorar seus processos de negócios adotando diversos modelos de qualidade, como ISO 9000 para a corporação, Six Sigma para a fábrica e CMM (capability maturity model) para engenharia de software.

Hoje, os gerentes de TI têm um leque oceânico de disciplinas de qualidade à disposição. Algumas, como Six Sigma e ISO 9000, podem ser impostas ao diretor de TI pelo CEO. Outras, como CobiT (control objectives for information and related technology), podem ser exigidas por seus auditores. E disciplinas focadas em TI podem ter origem em suas próprias instalações, como CMM para desenvolvimento de software e ITIL (information technology infrastructure library) para operações e serviços de TI.

Embora haja alguma sobreposição entre esses modelos de qualidade, na maior parte dos casos eles não entram em conflito. Na verdade, a maioria das grandes empresas usa dois ou três deles. A IBM, por exemplo, utiliza ISO 9000, CMM, ITIL, Six Sigma e vários programas de qualidade criados internamente. Já outras não usam nenhum deles, preferindo ter os seus próprios. A MasterCard International adaptou partes de diversos programas ao seu próprio modo de fazer negócio. Realizou uma avaliação externa de CMM um ano atrás e implementou algumas idéias a partir daí, mas não implantou o modelo formalmente.

Para algumas companhias, um selo de aprovação de um organismo externo, como certificação ISO 9000 ou CMM, pode ser um fator importante. Uma empresa na área de defesa, por exemplo, talvez não consiga trabalhos se não tiver uma alta avaliação CMM. E um selo ISO 9000 pode ser uma exigência para fazer negócio, principalmente fora dos Estados Unidos.

Mas uma empresa pode se exceder em qualquer destes programas, observa Matt Light, analista do Gartner. "Temos uma filosofia chamada ‘apenas o processo suficiente’", diz ele. "Criar seu próprio programa e aplicá-lo somente onde faz sentido costuma ser a melhor opção para organizações que não têm exigências de certificação."

De qualquer forma, alguma coisa você deve fazer no front da qualidade, recomenda Michael J. Ashworth, CIO da unidade de banco de investimento da J.P. Morgan Chase & Co. "Todas estas coisas são apenas maneiras melhores de fazer o que as pessoas estão tentando fazer com um fim específico", diz ele. "Não são um ritual sem sentido; são o senso comum codificado."

IT Infrastructure Library (ITIL)

Responsáveis: Escritório de Comércio do governo Reino Unidos, Pink Elephant e outros.

O que é: Conjunto de melhores práticas para operações e gerenciamento de serviços de TI (como gerenciamento de service desk, incidente, mudança, capacidade, nível de serviço e segurança). Especialmente popular na Europa. O ITIL rastreia problemas em áreas de serviço de TI como help desk, suporte a aplicações, distribuição de software e suporte a sistemas de contato com o cliente e se sobrepõe a CMM em determinadas áreas, como gerenciamento de configuração. O ITIL rastreia, por exemplo, as mudanças feitas em sistemas operacionais, mas a qualidade dessas mudanças — em termos do número e da gravidade de problemas resultantes delas — é uma métrica de CMM.

Pontos fortes: Bem estabelecido, amadurecido, detalhado e focado em questões de qualidade operacional e produção de TI. Pode ser combinado a CMMI para cobrir tudo relacionado a TI.

Limitações: Não aborda o desenvolvimento de sistemas de gerenciamento de qualidade. Não é voltado para processos de desenvolvimento de software. Seu uso depende imensamente de interpretação.

Da informalidade aos processos estruturados.

Six Sigma

Responsável: Desenvolvido pela Motorola.

O que é: Um método de aprimoramento de processo estatístico que enfoca a qualidade do ponto de vista do cliente ou do usuário. Define níveis de serviço e mede variações em relação a estes níveis. Os projetos percorrem cinco fases: definir, medir, analisar, aprimorar e controlar. A variante Design for Six Sigma aplica os princípios deste método à criação de produtos ou serviços sem defeitos, e não ao aprimoramento dos que já existem.

Pontos fortes: Uma abordagem orientada a dados para descobrir a raiz de problemas de negócio e resolvê-los. Leva em conta o custo de qualidade. Em TI, é melhor aplicado em atividades passíveis de repetição e relativamente homogêneas, como operações de call center ou help desk. Design for Six Sigma pode ajudar a desenvolver boas especificações de software.

Limitações: Projetado originalmente para ambientes de manufatura; pode ser difícil aplicá-lo em processos que ainda não estão bem definidos e mensuráveis. Pode aprimorar o processo, mas não diz se você tem o processo certo.

CobiT

Há um ano, Jairo Martins saiu da área de negócios da Siemens Mercosul para ocupar a posição o CIO. Logo de início, desenvolveu um trabalho de ouvidoria com as várias unidades do grupo para saber quais eram as principais queixas em relação ao departamento de TI. O resultado foi desastroso: todas as unidades reclamaram que eram surpreendidas com despesas novas de TI, não viam transparência na apresentação dos custos e nem uma sistemática de tarifação (billing).

A falta de planejamento levou Martins à decisão de adotar o CobiT. O objetivo com a implantação da metodologia foi dar a sua equipe condições para alinhar a infra-estrutura da área aos negócios da empresa, de modo que ouvissem as necessidades dos usuários internos e informar todos os dados que eles julgarem pertinentes. Além disso, a idéia do Cobit é estabelecer parâmetros para subcontratar serviços e se estruturar para geri-los com qualidade. "O Cobit é a mais ampla metodologia para se fazer a gestão de TI e a escolhi porque ela vai me ajudar a gerir a área, ordenar processos internos e obter uma série de benefícios", acredita Martins.

Em julho de 2003, Martins contratou a Big Five Consulting para treinar seu pessoal e deu início à criação de um projeto interno de Cobit. Como líder do projeto, Martins conta que, no momento, ele está adaptando a metodologia para a realidade da Siemens e definindo procedimentos. Com o Cobit, a Siemens quer obter otimização de custos, uma boa gestão da qualidade dos serviços prestados e a garantia da disponibilidade das plataformas de TI.

Apesar de o Cobit ainda se encontrar em fase de implantação (60% dele já foi adotado), ele já trouxe benefícios à empresa. A criação de um comitê de governança de TI, que se reúne a cada trimestre com representantes de todas as unidades da empresa, é resultado da implantação da metodologia. "Nós também conseguimos obter transparência dos custos, que agora são repassados com maior clareza para as áreas, melhora na comunicação com as unidades de negócio, além de uma melhor estruturação dos processos para gestão de TI."

Martins acredita que, até o final deste ano, o Cobit atinja a maturidade 3 dentro da Siemens. Hoje ela está em 2.4. A implantação total do projeto deve se encerrar em meados de 2005.

Control Objectives for Information and Related Technology (CobiT)

Responsável: Information Systems Audit and Control Association e IT Governance Institute

O que é: Um conjunto de diretrizes baseadas em auditoria para processos, práticas e controles de TI. Voltado para redução de risco, enfoca integridade, confiabilidade e segurança. Aborda quatro domínios: planejamento e organização, aquisição e implementação, entrega e suporte e monitoração. Apresenta seis níveis de maturidade, similares aos de CMM.

Pontos fortes: Permite que TI aborde riscos não endereçados explicitamente por outros modelos e que seja aprovada em auditorias. Funciona bem com outros modelos de qualidade, principalmente ITIL.

Limitações: Diz o que fazer, mas não como fazer. Não lida diretamente com desenvolvimento de software ou serviços de TI. Não fornece um "road map" para aprimoramento contínuo de processos.

Lance Turcato, diretor de supervisão de segurança e infra-estrutura de tecnologia da Charles Schwab & Co., define CobiT como uma "ferramenta de governança de TI" que ajuda os gerentes de informática a entender quais controles são necessários e a medir a eficácia destes controles. "Faz parte uma ferramenta de auditoria para que os auditores possam auditar seguindo estes mesmos critérios", acrescenta Turcato.

CobiT demanda um esforço considerável para ser integrado a processos de uma empresa. "As instruções em CobiT são muito genéricas. Fomos obrigados a transformá-lo em ‘linguagem Schwab’ para que as pessoas pudessem entender", diz Turcato. "O desafio maior foi fazer todo mundo aderir. Tivemos que determinar, em todo o grupo de tecnologia, as pessoas apropriadas que possuem estes controles e educá-las em CobiT."

A Lockheed Martin tem quatro unidades no Nível 5 de CMMI. A empresa também usa disciplinas Six Sigma e ISO 9000 em diversas partes de sua organização de TI, mas CobiT é o "modelo de qualidade guarda-chuva", define CIO Joseph R. Cleveland, fornecendo checklists úteis em cada um de seus quatro domínios.

Para algo simples como acrescentar o PDA BlackBerry ao catálogo de dispositivos aprovados da empresa, por exemplo, CobiT perguntará se existe suporte de help desk para ele, se a segurança foi abordada, se já existem procedimentos para adquirir e manter o dispositivo e assim por diante.

Cliveland diz que CobiT se integra bem com CMMI - CobiT detecta a necessidade de determinados controles e CMMI implanta-os. As dúvidas dos auditores sempre podem ser satisfeitas com aspectos de CMMI, segundo Cliveland.

CMM - Software com selo de maturidade

Certificação CMM confere um planejamento mais confiável , aumentando a probabilidade de os recursos da aplicação e ganhar um crachá de merecimento para o mundo inteiro ver — O executivo explica que a certificação foi essencial para que a empresa se firmasse como exportadora de software

Durante 15 anos, as empresas que quiseram aprimorar significativamente suas práticas de desenvolvimento de software — e ganhar um crachá de merecimento para o mundo inteiro ver — percorreram um longo e árduo caminho chamado CMM for software, uma linha de ação capaz de levá-las de um estado de semicaos (onde a maioria está hoje) a uma condição marcada pela precisão, capacidade de repetir procedimentos e baixa taxa de erro normalmente associados a uma linha de montagem de manufatura.

O CMMI, apresentado recentemente pelo Software Engineering Institute, é um modelo de maturidade de processo mais abrangente que combina CMM for software com disciplinas mais amplas nas áreas de engenharia de sistemas e desenvolvimento de produtos. Futuramente, o instituto vai parar de suportar CMM for software em favor do CMMI.

A instalação de TI do JP Morgan Chase usa CMM for software, ao passo que o grupo, no geral, trabalha sob Six Sigma. "Nossas equipes de desenvolvimento alcançaram o CMM nível 2 e estão a caminho do nível 3 em alguns casos", revela Michael Ashworth, CIO da unidade de banco de investimento da JP Morgan Chase & Co. O CIO diz que a mudança do nível 1 para o nível 2 gerou um planejamento mais confiável, aumentando a probabilidade dos recursos da aplicação estarem certos da primeira vez e reduzindo, portanto, a tarefa onerosa de refazer o trabalho.

Passar de um nível de maturidade ao seguinte exige dois ou mais anos de trabalho árduo e, em alguns casos, não vale o esforço, apontam alguns usuários. A Allstate Insurance, por exemplo, quer passar do nível 1 ao nível 3 e parar por aí. "Não vemos necessidade de ir para o nível 4 ou 5", diz Robin Richmond, vice-presidente assistente para Allstate Protection Technology.

No Brasil, o CMM também vem sendo cada vez mais utilizado pelas empresas. A Stefanini IT Solutions, uma das maiores consultorias nacionais de TI, sempre se preocupou em manter um bom nível de qualidade em todos os departamentos, incluindo a fábrica de software. Em 1996 a empresa obteve o certificado ISO 9001 e em 2002, deu mais um passo à frente ao receber a certificação CMM nível 2. O diretor-presidente da empresa, Marco Antônio Stefanini, diz que a homologação foi obtida em apenas 12 meses. O motivo foi o fato de a empresa já ter uma preocupação anterior com qualidade e respeitar as normas ISO 9001. O processo foi conduzido pela ISD-Brasil, empresa credenciada pelo Software Engineering Institute.

No momento, a Stefanini se encontra no meio do processo de implantação do CMM nível 3, iniciado em outubro do ano passado e com previsão de término para setembro. Até agora, os custos estão em R$ 500 mil. Em 2005, a idéia é passar para o nível 4. Apesar de considerar a implantação do CMM um processo caro e que consome muita energia, Stefanini diz que, no caso de sua empresa, a adoção é uma questão de sobrevivência.

Os resultados obtidos com o CMM? O executivo explica que a certificação foi essencial para que a empresa se firmasse como exportadora de software. Com sete subsidiárias no exterior (Argentina, Chile, Peru, Colômbia, México, Estados Unidos e Espanha), a Stefanini tem 15% de sua receita com vendas externas. Deste total, 50% são provenientes dos Estados Unidos. "O CMM é muito bem visto pelo mercado norte-americano, o que acaba se tornando um requisito básico na hora de fechar negócios com empresas internacionais", explica Stefanini.

Entre os principais benefícios já obtidos com o CMM, o executivo destaca a redução de cerca de 60% de retrabalho nos projetos, melhoria nos prazos de atendimento, que subiram de 80% para 96%, queda de 5% a 10% no custo de desenvolvimento, aumento da qualidade do trabalho e controle de gestão.

Capability Maturity Model Integration (CMMI)

Responsável: Software Engineering Institute, Carnegie Mellon University

O que é: O CMMI estende e combina o capability maturity model for software (SW-CMM), o systems engineering capability model e o integrated product development capability maturity model. SW-CMM é uma coleção de melhores práticas para desenvolvimento e manutenção de software. Permite que as empresas avaliem suas práticas e as comparem com as de outras empresas. SW-CMM mede a maturidade do processo, que progride em cinco níveis: 1 (inicial), 2 (gerenciado), 3 (definido), 4 (previsível) e 5 (otimização).

Pontos fortes: Muito detalhado. Criado especificamente para organizações de desenvolvimento de software. Enfoca o aprimoramento contínuo, e não apenas a manutenção de uma certificação. Pode ser usado para auto-avaliação.

Limitações: Não aborda aspectos de operações de TI como gerenciamento de segurança, mudança e configuração, planejamento de capacidade, diagnóstico e funções de help desk. Estabelece metas, mas não diz como atingi-las.

ISO - A excelência da qualidade

A ISO 9000 é um dos sistemas mais amplo, empregado pelas empresas nas áreas de manufatura, engenharia, marketing, vendas e TI

A americana LSI Logic é certificada em ISO 9000 desde 1992. Também usa Six Sigma e Design for Six Sigma. "Mas ISO é o sistema de qualidade mais amplo que empregamos", diz Engelbrecht. "Aplica-se a manufatura, engenharia, marketing, vendas e TI." Ele explica que, enquanto o Design for Six Sigma se concentra em projetos individuais e tenta corrigir os problemas que detecta, a ISO 9000 ajuda a fazer aprimoramentos de qualidade ano a ano. Isso é feito através de auditorias ISO 9000 anuais realizadas por auditores internos e externos.

A Nortel Networks usa a TL 9000, uma versão de ISO 9000 talhada para a indústria de telecomunicações. "A certificação é aplicada à empresa como um todo, mas iniciativas de qualidade em TI também suportam a TL 9000", diz Chris Ashwood, vice-presidente para soluções de desenvolvimento de produtos. "TL 9000 levou ISO 9000 um passo à frente no sentido de reconhecer realmente a importância de TI para o desenvolvimento de produtos."

A instalação de TI da empresa tem um conjunto de prioridades bem definido que é atualizado a cada seis meses, um scorecard para cada projeto e um processo de gerenciamento rígido para rastrear responsabilidades. "Isso se alinha muito claramente com a abordagem de ISSO — fazer o que você diz que vai fazer, rastrear responsabilidades e documentar o processo" , diz Albert Hitchcock, CEO da Nortel.

ISO 9000

Responsável: International Standards Organization

O que é: Um conjunto de padrões auditáveis de alto nível voltados ao cliente (ISO 9000, 9001 e 9004) para sistemas de gerenciamento de qualidade. Destinado a garantir controle, repetibilidade e boa documentação de processos (não de produtos).

Pontos fortes: Bem estabelecido, amadurecido. Goza de prestígio global. Pode ser aplicado em toda a corporação. Cobre desenvolvimento de software e operações e serviços de TI.

Limitações: Requer adaptação considerável quando utilizado em organizações de TI. Enfoca a repetibilidade e a consistência de processos, e não diretamente a qualidade dos processos. Não é bom para descobrir a origem de problemas.

(Fonte: Pesquisas na internet agradecimentos a Françoise).

UML - Que raio é isso?

Iniciando a semana...

Carlo leitor, a ultima semana foi realmente muito atribulada, por isso demorei um pouco mais para "postar" dessa vez.
O artigo de hoje trata da UML, estou envolvido em um projeto relativamente grande e na ultima quinta-feira enquanto participava de uma reunião, qual foi a surpresa, quando um elemento chave do projeto nos olhou firmemente e disse: "Eu não tenho a menor idéia do que o seu analista fala...Que raios é UML?..."
Eu não tenho nenhuma intenção aqui de aprofundar no tema, meu intuito aqui é apenas dar um bom over view para os leigos...Bom depois você´s me dizem se eu consegui...
Aproveito também para dizer que responderei todos os e-mail´s recebidos essa semana! Foram mais de 50! Obrigado pela audiência!! Escrevam!!
Abraços!

UML – Unified Modeling Language

A UML (Unified Modeling Language) é uma linguagem para modelagem visual de sistemas orientados a objetos, apoiando sua especificação, documentação, visualização e desenvolvimento.

Criada e mantida pelo OMG – Object Management Group ( www.omg.org/ ), organização internacional sem fins lucrativos que reúne um grupo de empresas de TI que desenvolve, publica e mantém padrões para a área de TI, mais especificamente para tecnologias de desenvolvimento orientadas a objetos.

Lançada pelo OMG em Novembro de 1997 (versão 1.1), está atualmente na versão 2.0.

Sintetiza os principais métodos de modelagem visual existentes, sendo considerada uma das linguagens mais expressivas para modelagem de sistemas orientados a objetos.

Diagramas Estruturais:

• · Diagrama de objetos
• · Diagrama de classes
• · Diagrama de componentes
• · Diagrama de instalação
• · Diagrama de pacotes
• · Diagrama de estrutura

Diagramas Comportamentais

• · Diagrama de Casos de Uso
• · Diagrama de Máquina de Estados
• · Diagrama de atividade
• · Diagramas de Interação
• · Diagrama de seqüência
• · Diagrama de Interatividade
• · Diagrama de colaboração
• · Diagrama de tempo

O Diagrama de Caso de Uso descreve o que um sistema faz do ponto de vista de um observador externo.

A ênfase se dá no que o sistema faz, e não no como.

Diagramas de Casos de Uso são estreitamente ligados a cenários.

Um cenário é um exemplo do que acontece quando alguém interage com o sistema

Um Caso de Uso é um sumário de cenários para uma tarefa ou objetivo específicos.

Casos de Uso são especialmente úteis em três áreas:

Levantamento de funcionalidades (requisitos): novos Casos de Uso geralmente agregam requisitos novos à medida que o sistema é analisado e o seu desenho (design) toma forma.

Comunicação com o cliente: a simplicidade da notação (bem menos complexa que os demais diagramas da UML) torna Diagramas de Casos de Uso uma boa maneira para os desenvolvedores se comunicarem com os clientes.

Geração de Casos de Teste: a coleção de cenários de um Caso de Uso pode sugerir um conjunto de testes associados àqueles cenários.

Repost Prince2

Amigos, "repostei" dois links , pois tenho recebido alguns e-mails com algumas dúvidas que podem ser esclarecidas nos links abaixo.
Quero agradecer a audiência, e-mail´s e recados que tenho recebido, todos respondidos (assim que possível).
Continuem a perguntar, cada vez que recebo um e-mail com alguma dúvida, normalmente tenho que rever algo já aprendido e muitas vezes até esquecido ou seja todos nós ganhamos!
Abraços!

GF Info - Gerenciamento de projetos - PMI-Prince2: Gerenciamento de Projetos - Links úteis

GF Info - Gerenciamento de projetos - PMI-Prince2: Gerenciamento de Projetos - Links úteis

GF Info - Gerenciamento de projetos - PMI-Prince2: Um pouco mais de Prince2

GF Info - Gerenciamento de projetos - PMI-Prince2: Um pouco mais de Prince2

PMI - Decore os processos

PMI - Processos

Se você está estudando para a certificação PMP, certamente já memorizou que o PMI tem 5 grupos de processos contendo 44 processos distribuídos em 9 áreas de conhecimento. Fácil até aqui. Mas, nas não é o suficiente para passar na prova. Você também precisa memorizar quais são os 44 processos e onde eles se encaixam.
Para você que tem dificuldades em memorizar aquele quadro da página 70 do PMBOK deixo esta dica – crie uma tabela de acrônimos como esta que estou postando hoje. Facilita a memorização e você ainda pode montá-la como apoio naqueles 15 minutos que antecedem a prova.

Pra ter certeza de que montou o quebra-cabeça corretamente você pode montar outro acrônimo como se fosse um número de CPF para memorizar quantos processos cada área de conhecimento tem – 756.334.466. Lembre-se apenas que para usar este acrônimo corretamente você tem que memorizar a seqüência das seções na mesma ordem que aparecem no PMBOK.

Depois que você passar na prova vai me agradecer por esta dica....boa sorte!

É só clicar na tabela abaixo:

Entendendo a SWOT

Análise SWOT

Amigos, pelas perguntas que tenho recebido ultimamente, sobre o tema que apesar de ser velho conhecido de muitos , ainda deixa algumas dúvidas em outros. Espero que esse texto ajude a esclarecer.
Boa leitura:

A análise SWOT é uma poderosa ferramenta de marketing, e deve ser realizada / utilizada ao menos uma vez por ano, durante o planejamento estratégico de marketing, ou sempre que se iniciar um projeto. A sigla SWOT, vem das iniciais das palavras inglesas Strenghts (forças), Weaknesses (fraquezas), Opportunities (oportunidades) e Threats (ameaças), ou em português F.O.F.A. (nunca vi ninguém falando FOFA fora das faculdades).
Não há registros precisos sobre a origem desse tipo de análise, segundo HINDLE & LAWRENCE (1994) a análise SWOT foi criada por dois professores da Harvard Business School: Kenneth Andrews e Roland Christensen. Por outro lado, TARAPANOFF (2001:209) indica que a idéia da análise SWOT já era utilizada há mais de três mil anos quando cita em uma epígrafe um conselho de Sun Tzu: “Concentre-se nos pontos fortes, reconheça as fraquezas, agarre as oportunidades e proteja-se contra as ameaças ” (SUN TZU, 500 a.C.) Apesar de bastante divulgada e citada por autores, é difícil encontrar uma literatura que aborde diretamente esse tema.

O caminho mais indicado para entender o conceito da análise SWOT é buscar diretamente sua fonte: The concept of corporate strategy, do próprio Kenneth Andrews. Porém, uma leitura superficial dessa fonte frustra os mais afoitos por definições precisas e modelos práticos, pois o autor não faz nenhuma referência direta à análise SWOT em todo seu livro.

Para montar uma Análise SWOT de Riscos (Identificação de pontos fortes, pontos fracos, ameaças e oportunidades), normalmente usamos uma simples planilha dividida em quatro, grande áreas:

· (S) Strengths (Pontos Fortes, de origem interna)

· (W) Weaknesses (Pontos Fracos, de origem interna)

· (O) Opportunities (Oportunidades externas)

· (T) Threats (Ameaças externas)

A análise SWOT pode servir para se avaliar uma empresa, um projeto, uma parte do projeto, um produto, uma equipe, etc. Para cada um destes itens, fazemos alguns questionamentos:

Pontos Fortes:

O que você (empresa/equipe/pessoa) faz bem?

Que recursos especiais você possui e pode aproveitar?

O que outros (empresas/equipes/pessoas) acham que você faz bem?

Pontos Fracos:

No que você pode melhorar?

Onde você tem menos recursos que os outros?

O que outros acham que são suas fraquezas?

Ameaças:

Que ameaças (leis, regulamentos, concorrentes) podem lhe prejudicar ?

O que seu concorrente anda fazendo?

Oportunidades:

Quais são as oportunidades externas que você pode identificar?

Que tendências e "modas" você pode aproveitar em seu favor?

Ameaças e oportunidades - Uma das partes da análise SWOT é o estudo do ambiente externo à organização em busca de ameaças e oportunidades. Trata-se da análise daquilo que está sempre fora do controle das empresas, mas que é importante de se conhecer e monitorar. Entre as forças a serem consideras estão os fatores demográficos, econômicos, históricos, políticos, sociais, tecnológicos, sindicais, legais, etc.

As fontes para esta análise serão tiradas da grande imprensa, dos órgãos governamentais, dos indicadores financeiros, das organizações correlatas e das revistas e associações especializadas no seu campo de atuação.

As ameaças e oportunidades sempre afetam de forma homogênea todas as organizações que concorrem num mesmo mercado-alvo. Contudo as organizações que perceberem as mudanças e tiverem agilidade para se adaptarem, serão aquelas que melhor proveito tirará das oportunidades e menor dano das ameaças.

Esta análise deve levar em conta não somente as tendências que afetam a organização, mas também a probabilidade destas tendências tornarem- se eventos reais. Desnecessário dizer que devemos dar maior atenção às tendências com maior probabilidade de acontecer, para assim evitar as ameaças reais e explorar as oportunidades da melhor maneira possível.

Forças e fraquezas - A outra parte da análise SWOT, trata dos pontos fortes e fracos da organização, ou seja de seu ambiente interno. Assim, quando percebe-se um ponto forte, devemos ressaltá-lo ainda mais e quando percebemos um ponto fraco devemos agir para corrigí-lo ou pelo menos para minimizar seus efeitos.

É isso aí, espero ter contribuido com algum conhecimento.

Qualquer dúvida: flavio.falcao@gmail.com

Ferramenta de gestão de tempo

Ferramenta de gestão de tempo

AVISO IMPORTANTE!!

Caro leitor, reforço aqui que toda e qualquer ferramenta (software) que eu coloco à disposição para download aqui no blog, é regulamentada como “Open source” ou seja são ferramentas de uso livre, 100% legalizadas, e testadas pessoalmente por mim; portanto se você gostou da proposta da ferramenta, Baixe e use sem receio nenhum!

Personal Task Manager - PTM

Achei a proposta dessa ferramenta muito interessante, avaliei durante uma semana e pude concluir que sua principal funcionalidade é “cobrar” suas tarefas e controlar o tempo despendido em cada uma delas. A interface é muito simples e interessante pois possui o mesmo layout do “Task Manager” do Windows. Como ferramenta de “Self Control” é perfeita.

Estou criando um manual de uso em português, quem se interessar é só avisar que eu enviarei por e-mail ou, dependendo do volume das solicitações, posto aqui mesmo no blog.

Para baixar, é só clicar AQUI.

Aproveitando...Obrigado pelas mensagens de apoio e sugestões.

[]´s

Project Managers - Salários

Pesquisa salarial indica que Gerentes de Projetos e possuidores da credencial PMP® estão entre aqueles que recebem os salários mais altos da área de TI.

Na sua pesquisa salarial anual realizada entre 35.573 profissionais de TI de 197 países, a revista Certification Magazine aponta que a média salarial dos profissionais de gerenciamento de projetos está entre os mais altos de todas as áreas de TI. Os que possuem a credencial Project Management Professional (PMP) receberam os mais altos salários entre todos os profissionais de TI possuidores de certificação profissional. Os resultados da pesquisa foram divulgados na edição de Dezembro de 2006. Todos os valores apresentados foram cotados em dólar (US$).

Das 22 áreas de TI, a média salarial da área de gerenciamento de projetos foi divulgada como a quinta maior, em torno de $85.590. A média do ano passado foi praticamente igual atingindo valores de $85.850. Somente 4 especializações em TI mostraram média salarial anual superior: information security com média de $93.500; network design com $89.770, storage com $87.390 e system integration com $86.840.

Os profissionais detentores da credencial PMP foram além. Entre os aproximadamente 100 tipos de certificações de TI pesquisadas, os possuidores da credencial PMP receberam média salarial de $95.430, sendo o décimo salário mais alto.

Mais de 96% dos pesquisados possuíam pelo menos uma certificação e sua média de aumento salarial superou a média nacional em 12%.

Dez por cento dos pesquisados eram mulheres, contudo recebiam praticamente a mesma quantia que os homens.

A idade foi um fator de influência no valor dos salários. Profissionais com idade entre 60 e 64 anos tiveram a maior média salarial, em torno de $80.520.

Os ganhos relatados foram mais que monetários. A maioria dos pesquisados acredita que suas certificações aumentaram a sua confiança e ganharam um grande respeito por parte da gerência e colegas.

Sobre a pesquisa:

Foram recebidas informações de 35.573 profissionais de TI de 197 países, com margem de erro de aproximadamente 1% e com 95% de nível de confiabilidade. Quase 90% dos pesquisados eram homens, mais de 60% vivem fora dos Estados Unidos e 70% obtiveram as suas certificações nos últimos 5 anos. Quase 60% dos pesquisados disseram que trabalham entre 40 e 50 horas semanais e outros 16% mais que 50 horas. Pouco mais de 57% dos pesquisados trabalham em empresas com menos de 5.000 funcionários.

A Certification Magazine (ISSN 1529-6903) é publicada mensalmente pela MediaTec Publishing, Inc., Oakland, California, USA.

Fonte: PMI® Community POST

Utilizando Pareto na gestão de projetos

Análise de Pareto na Gestão de Projetos Esse texto não é meu pertence ao pessoal da tenstep, está muito didático...Boa leitura!

A Análise de Pareto pode ser utilizada quando você encontra vários problemas relacionados ou um problema comum com múltiplas causas. Com esta técnica, você coleta métricas sobre quantas vezes ocorre cada problema ou a causa. O objetivo da Análise de Pareto é observar os problemas e determinar sua freqüência de ocorrência. Isso, por sua vez, lhe proporcionará as informações necessárias para priorizar o seu esforço para garantir que você está utilizando seu tempo onde obterá o impacto mais positivo. A Análise de Pareto se baseia na clássica regra 80/20. Em outras palavras, 20% das ocorrências causam 80% do problema. Por exemplo, digamos que você tem um problema relacionado com a falha de um produto baseado em um número de causas. Através da observação e coleta de métricas, você determina que há oito causas. Em vez de tratar as causas de forma aleatória, uma Análise de Pareto poderá lhe mostrar que 80% dos problemas são provocados por três maiores causas. Isso lhe dá informações para saber quais as causas deverão ser resolvidas primeiro. A ferramenta associada a essa técnica de solução de problemas é o Diagrama de Pareto. O Diagrama de Pareto é um mapa, gráfico ou histograma mostrando cada problema e a freqüência com que o mesmo ocorre. É criado como segue: 1. Crie uma tabela listando todos os problemas ou causas observadas. 1. Para cada problema, identifique o número de ocorrências por um período fixo de tempo. 1. Ordene os problemas por número de ocorrências, do mais alto ao mais baixo. 1. Acrescente uma coluna para o subtotal. Problema 1 115 53% Problema 3 50 77% Problema 2 25 88% Problema 6 15 95% Problema 4 5 98% Problema 5 5 100% Note que isto nos traz informações importantes. Embora haja seis problemas identificados no total, você precisa resolver primeiro os problemas n °1 e n°3. É aí que você terá o maior impacto. Se em vez disso você decidisse trabalhar nos problemas n°4 e n°5, o resultado do seu esforço seria quase desprezível. Isso não significa que você não queira resolver os demais problemas. No entanto, a Análise de Pareto lhe fornece informações sobre a ordem em que eles devem ser enfrentados. Ela também lhe dá uma idéia do valor relativo que você obtém em resolver cada problema. Definitivamente você não quer exercer o mesmo esforço resolvendo o problema n°5 como faria no problema n°1. O retorno não é o mesmo. (Naturalmente, você poderá determinar que o problema n°6 pode ser resolvido rapidamente e você poderá decidir resolve-lo mais cedo. O diagrama de Pareto não lhe diz o que fazer, mas lhe fornece a informação de modo que você possa tomar as decisões de forma mais efetivas.) Muitas vezes, você verá os resultados de um Diagrama de Pareto mostrados como um histograma ou diagrama de barras. Isso dá mais ênfase visual aos dados que você observou. Problema 1 115 Problema 2 25 Problema 3 50 Problema 4 5 Problema 5 5 Problema 6 15 Problema 1 115 Problema 3 50 Problema 2 25 Problema 6 15 Problema 4 5 Problema 5 5 Problema 1 Problema 2 Problema 3 Problema 4 Problema 5 Problema 6