O profissional que trabalha com gerenciamento de projetos tem inúmeras alternativas de certificar os seus conhecimentos e ser reconhecido no mercado como uma pessoa que domina o assunto.
Diversos institutos internacionais oferecem uma grade de certificados que se adaptam a profissionais em diferentes estágios de desenvolvimento da carreira.
A seguir, eu listarei os principais institutos e os certificados que eles oferecem:
PMI - Project Management Institute
É o instituto que trata a gerência de projetos mais conhecido internacionalmente e é responsável pela publicação do badalado guia de práticas PMBOK.
O profissional tem as seguintes opções de se certificar junto ao PMI:
CAPM - Certified Associate in Project Management
Para profissionais iniciantes na gerência de projetos.
PMP - Project Management Professional
A certificação mais completa do PMI, voltada para profissionais experientes.
PgMP - Program Management Professional
Voltada para profissionais que gerenciam programas.
PMI-ACP - PMI Agile Certified Practitioner
Certificação para gerenciamento de projetos utilizando um método ágil.
PMI-RMP - PMI Risk Management Professional
Específica para o gerenciamento de riscos.
PMI-SP - PMI Scheduling Professional
Específica para o gerenciamento de tempo.
IPMA – International Project Management Association
Apesar de mais conhecido, o PMI não é o único instituto internacional de gerência de projetos. O IPMA é outro instituto que tem reconhecimento internacional e muitas empresas adotam as suas práticas de gerenciamento de projetos.
O IPMA foi fundado em 1965, tem sede na Suíça, segue uma linha similar ao PMI, porém, com enfoque voltado a atividades e não disciplinas. O seu framework é mais utilizado na Europa, enquanto o PMI é mais forte nas Américas. Ele é representado no Brasil pela ABGP (Associação Brasileira de Gerenciamento de Projetos).
Diferentemente do PMI, a certificação do IPMA é divididas em níveis, de forma que o profissional pode ir escalando o seu reconhecimento no mercado gradativamente. Os níveis de certificação são:
Level D - Certified Project Management Associate
Deve ter conhecimentos de Gerenciamento de projetos, os quais poderão ser aplicados em alguns campos da sua especialidade. Não é exigida experiência profissional.
Level C - Certified Project Manager
É capaz de gerenciar, com razoável independência, projetos não complexos, coordenar as tarefas técnicas de equipes de projeto e apoiar o gerente de um projeto complexo em todas as áreas de aplicação do gerenciamento de projetos.
Level B - Certified Senior Project Manager
Deve ter a capacidade de gerenciar projetos complexos com total independência.
Level A - Certified Projects Director
Deve ter a capacidade de dirigir todos os projetos constituintes de um programa ou todos os projetos de uma empresa ou linha de negócio ou ainda um projeto complexo com participantes de diferentes culturas e geografias.
Para os níveis mais altos de certificação, o IPMA usa, além de provas de conhecimento, outros critérios de avaliação, como entrevista e comprovação de experiência.
PRINCE2 - PRojects IN Controlled Environments
Mais conhecida na Europa, especialmente no Reino Unido, a PRINCE2 ainda está dando os primeiros passos na América do Sul. Com proposta totalmente diferente das certificações do PMI, a PRINCE2 é uma metodologia e tem como objetivo estabelecer um passo a passo para gerenciar projetos.
Quem mantém a metodologia é o OGC (The Office of Government and Commerce) do Reino Unido. As certificações são gerenciadas pelo APM Group e a documentação é suportada pelo TSO (The Stationery Office), todos ligados ao governo britânico.
Ela tem três níveis de certificação:
Foundation
É a certificação para profissionais iniciantes no PRINCE2.
Practicioner
É o nível mais alto de certificação para profissionais que utilizam o PRINCE2.
Instrutor Certificado
É a certificação para quem quer ser instrutor de PRINCE2. Para passar por este nível, o profissional deve comprovar horas de experiência e ser auditado pelo OGC (Office of Government Commerce). O exame, neste caso, só pode ser aplicado por um instrutor PRINCE2 – há apenas dois no Brasil, segundo a Elumini, consultoria oficial dessa metodologia por aqui, que está estruturando um treinamento no país.
Mostrando postagens com marcador Gerência de Projetos. Mostrar todas as postagens
Mostrando postagens com marcador Gerência de Projetos. Mostrar todas as postagens
quinta-feira, 29 de setembro de 2011
sábado, 7 de maio de 2011
Curso gratuito de SCRUM
Quem quiser conhecer o SCRUM, framework para gerenciamento ágil de projetos, pode fazer o mini-curso gratuito oferecido pela Qualifico. A duração é de 3 horas, aproximadamente.
http://www.qualifico.com.br/curso.asp?curso=SCM
http://www.qualifico.com.br/curso.asp?curso=SCM
quarta-feira, 29 de setembro de 2010
Como funcionam os projetos de software
Os projetos de software nem sempre atingem os seus objetivos. Para mostrar como estes projetos funcionam, existe um exemplo bem humorado que é usado há muito tempo:
01 - Como o cliente descreveu a sua necessidade:
02 - Como o analista de requisitos entendeu:
03 - O que o gerente de conta vendeu para o cliente:
04 - Como o analista especificou:
05 - O que o programador construiu:
06 - O que a equipe de testes recebeu:
07 - Como o projeto foi documentado:
08 - Qual é o plano de recuperação de desastre:
09 - Como o marketing anunciou:
10 - O que a operação instalou:
11 - Como é suportado:
12 - Quando foi entregue:
13 - Quanto foi cobrado do cliente:
14 - O que o cliente realmente queria:
Veja mais exemplos em: http://www.projectcartoon.com
01 - Como o cliente descreveu a sua necessidade:
Veja mais exemplos em: http://www.projectcartoon.com
segunda-feira, 26 de julho de 2010
Diferenças entre engenharia de software e engenharias tradicionais
Quem trabalha com desenvolvimento de software está quase sempre envolvido com atrasos na entrega e com problemas de qualidade no produto construído. Quando estes problemas se tornam muito frequentes, inevitavelmente as pessoas começam a comparar a Engenharia de Software com as engenharias tradicionais, pois, é perceptível que nas demais engenharias os problemas de atraso e qualidade são muito menos recorrentes.
Por que ao construir um prédio é possível cumprir o planejamento com muito mais precisão e ter muito menos inconformidades no final do que quando estamos construindo um sistema de informação?
A minha intenção neste post é fazer uma comparação entre os principais aspectos das engenharias tradicionais e de software, para nos ajudar cada vez mais nos aproximarmos das boas práticas de engenharia e a explicar a nossos clientes porque não conseguimos cumprir prazos com a mesma constância que o pessoal das outras engenharias.
Os principais aspectos que diferenciam a engenharia de software das demais são:
Maturidade da área
Existem poucos padrões a serem seguidos quando se executa projetos de software. Na maioria das outras áreas de engenharia já existe uma cultura secular ou até mesmo milenar (lembrando que os egípcios já construíam pirâmides complexas há mais de 5.000 anos), fazendo com que muitos métodos e técnicas sejam extremamente testados e de amplo domínio. Na engenharia de software quase tudo ainda é muito mais experiência de alguns do que conhecimento de todos.
Produto intangível
Os gerentes de projetos de outras áreas, normalmente, trabalham com objetos materiais visíveis e tangíveis. Estes objetos podem ser sentidos, observados, tocados, etc., e mediante o uso das informações obtidas através do uso dos sentidos podem ser melhorados, corrigidos ou modificados. Enquanto isso, a natureza abstrata e intangível do projeto de software limita muito a ação do gerente. É muito mais fácil os envolvidos perceberem e avaliarem o desenvolvimento do projeto de um navio, de uma casa ou de uma máquina do que ver o progresso de um projeto de software cuja visibilidade é meramente conceitual, através de um conjunto de documentos.
A mesma dificuldade de perceber o andamento do trabalho se repete ao tratarmos sobre alterações no produto finalizado. É muito mais fácil para um engenheiro explicar a um cliente o esforço necessário para mudar a janela de uma casa de lugar depois dela pronta, do que um engenheiro de software demonstrar para o seu usuário o esforço para mudar um botão de posição na tela de um sistema. “Mas basta apenas mudar o botão de lugar, não pode demorar esse tempo todo...” é a resposta padrão que os profissionais de software ouvem.
Facilidade para modelagem / prototipação
Quando se trata de projetar objetos tangíveis, é muito mais fácil criar um modelo ou protótipo que represente bem para os interessados aquilo que se pretende construir. Pode-se lançar mão de diversos artifícios: plantas, desenhos, maquetes, modelos computacionais em 3D, etc. Permitindo até mesmo que criemos modelos que simulam o funcionamento do produto depois de pronto. Já para um software, que é intangível, a questão da prototipação é mais complexa, normalmente o que fazemos são os layouts das telas e a simulação da navegação, contudo, isso não basta. Por trás das telas pode haver regras de negócios extremamente complexas que não são representadas no protótipo e, consequentemente, não podem ser validadas pelos interessados.
Falta de padronização nos projetos
Grande parte dos projetos de software são projetos únicos, pois, visam informatizar processos que também são únicos. Existe a experiência anterior com outros projetos, mas ela não se aplica integralmente no novo projeto. Isso torna difícil antecipar problemas, pois, a maioria deles serão problemas novos.
Rápida evolução tecnológica
Como há uma rápida evolução tecnológica na área de TI, nem mesmo a tecnologia usada, os métodos e ferramentas já conhecidas e experimentadas em projetos anteriores servirão de parâmetros para o novo projeto. Muitas ferramentas ou técnicas amplamente utilizadas há pouco mais de uma década, hoje são completamente obsoletas.
Na maioria das áreas a opção mais comumente adotada para acompanhar a evolução tecnológica ou o aperfeiçoamento de métodos e técnicas é projetar novos produtos que englobam os avanços tecnológicos. Em projetos de software, não raro, tenta-se adaptar os produtos existentes às novas tecnologias.
Conhecimento da área de atuação
Os projetistas das demais áreas de engenharia, em geral, gerenciam projetos muito específicos de sua área de conhecimento enquanto os projetistas de software são solicitados a desenvolver os seus projetos nas mais variadas áreas do conhecimento humano, áreas estas que eles não dominam. Isto torna as incertezas de seu sucesso ainda maiores, pois, eles dependem essencialmente do conhecimento de pessoas que por sua vez não dominam as técnicas de desenvolvimento de software.
Identificação das falhas
Enquanto os gerentes de projetos de outras áreas podem orgulhar-se de colocar no mercado produtos sem defeitos, os gerentes de produtos de software, geralmente devem contentar-se em oferecer produtos que sejam confiáveis, não necessariamente sem defeitos. Confiáveis são produtos que podem apresentar defeitos, mas estes não devem ocorrer em situações normais de uso, não podem ser frequentes e nem aparecer nos momentos mais críticos de uso do produto.
Outra consideração significativa diz respeito às indicações de possíveis falhas. Nas demais áreas, as falhas são geralmente antecedidas por ocorrências facilmente percebidas, tais como rachaduras em prédios, barulhos estranhos em máquinas, cheiros incomuns em aparelhos elétricos ou produtos químicos, fumaça em motores, por exemplo. Em produtos de software as possíveis falhas muitas vezes só são percebidas na hora do uso.
Várias formas de se implementar o mesmo produto
Na maioria das áreas o número e a variedade de implementações satisfatórias é, em geral pequeno, isto quando não se reduz a uma só. Em engenharia de software pode haver uma enorme variedade de implementações satisfatórias. Desta forma as especificações de um projeto de produto de software devem incluir diretrizes para se escolher adequadamente uma alternativa correta.
Dependência de outros fatores
Outra dificuldade em projetos de software é que a qualidade dos produtos de outras áreas depende, em geral, somente da qualidade construída no produto. Já na área de produtos de software a qualidade do resultado produzido pelo software depende da qualidade da máquina na qual ele vai ser executado, da qualidade dos outros produtos de software com os quais ele interage (sistema operacional, compilador, servidor de aplicação, gerenciador de Banco de Dados, etc.).
Instabilidade dos requisitos
Normalmente, quem pretende construir um prédio ou uma máquina tem previamente uma ideia formada do que quer ou, pelo menos, não começa a execução sem ter essa ideia, porém, na engenharia de software não é raro nos deparamos com um cliente que quer um sistema para resolver um problema que ele não sabe exatamente qual é e nós iniciarmos o projeto antes de conhecer o problema a fundo. Como nestes casos começamos a trabalhar sem saber exatamente onde queremos chegar, é normal que ao longo do tempo os requisitos mudem e parte do trabalho tenha que ser refeita, consequentemente, não conseguimos cumprir o planejamento original.
Por que ao construir um prédio é possível cumprir o planejamento com muito mais precisão e ter muito menos inconformidades no final do que quando estamos construindo um sistema de informação?
A minha intenção neste post é fazer uma comparação entre os principais aspectos das engenharias tradicionais e de software, para nos ajudar cada vez mais nos aproximarmos das boas práticas de engenharia e a explicar a nossos clientes porque não conseguimos cumprir prazos com a mesma constância que o pessoal das outras engenharias.
Os principais aspectos que diferenciam a engenharia de software das demais são:
Maturidade da área
Existem poucos padrões a serem seguidos quando se executa projetos de software. Na maioria das outras áreas de engenharia já existe uma cultura secular ou até mesmo milenar (lembrando que os egípcios já construíam pirâmides complexas há mais de 5.000 anos), fazendo com que muitos métodos e técnicas sejam extremamente testados e de amplo domínio. Na engenharia de software quase tudo ainda é muito mais experiência de alguns do que conhecimento de todos.
Produto intangível
Os gerentes de projetos de outras áreas, normalmente, trabalham com objetos materiais visíveis e tangíveis. Estes objetos podem ser sentidos, observados, tocados, etc., e mediante o uso das informações obtidas através do uso dos sentidos podem ser melhorados, corrigidos ou modificados. Enquanto isso, a natureza abstrata e intangível do projeto de software limita muito a ação do gerente. É muito mais fácil os envolvidos perceberem e avaliarem o desenvolvimento do projeto de um navio, de uma casa ou de uma máquina do que ver o progresso de um projeto de software cuja visibilidade é meramente conceitual, através de um conjunto de documentos.
A mesma dificuldade de perceber o andamento do trabalho se repete ao tratarmos sobre alterações no produto finalizado. É muito mais fácil para um engenheiro explicar a um cliente o esforço necessário para mudar a janela de uma casa de lugar depois dela pronta, do que um engenheiro de software demonstrar para o seu usuário o esforço para mudar um botão de posição na tela de um sistema. “Mas basta apenas mudar o botão de lugar, não pode demorar esse tempo todo...” é a resposta padrão que os profissionais de software ouvem.
Facilidade para modelagem / prototipação
Quando se trata de projetar objetos tangíveis, é muito mais fácil criar um modelo ou protótipo que represente bem para os interessados aquilo que se pretende construir. Pode-se lançar mão de diversos artifícios: plantas, desenhos, maquetes, modelos computacionais em 3D, etc. Permitindo até mesmo que criemos modelos que simulam o funcionamento do produto depois de pronto. Já para um software, que é intangível, a questão da prototipação é mais complexa, normalmente o que fazemos são os layouts das telas e a simulação da navegação, contudo, isso não basta. Por trás das telas pode haver regras de negócios extremamente complexas que não são representadas no protótipo e, consequentemente, não podem ser validadas pelos interessados.
Falta de padronização nos projetos
Grande parte dos projetos de software são projetos únicos, pois, visam informatizar processos que também são únicos. Existe a experiência anterior com outros projetos, mas ela não se aplica integralmente no novo projeto. Isso torna difícil antecipar problemas, pois, a maioria deles serão problemas novos.
Rápida evolução tecnológica
Como há uma rápida evolução tecnológica na área de TI, nem mesmo a tecnologia usada, os métodos e ferramentas já conhecidas e experimentadas em projetos anteriores servirão de parâmetros para o novo projeto. Muitas ferramentas ou técnicas amplamente utilizadas há pouco mais de uma década, hoje são completamente obsoletas.
Na maioria das áreas a opção mais comumente adotada para acompanhar a evolução tecnológica ou o aperfeiçoamento de métodos e técnicas é projetar novos produtos que englobam os avanços tecnológicos. Em projetos de software, não raro, tenta-se adaptar os produtos existentes às novas tecnologias.
Conhecimento da área de atuação
Os projetistas das demais áreas de engenharia, em geral, gerenciam projetos muito específicos de sua área de conhecimento enquanto os projetistas de software são solicitados a desenvolver os seus projetos nas mais variadas áreas do conhecimento humano, áreas estas que eles não dominam. Isto torna as incertezas de seu sucesso ainda maiores, pois, eles dependem essencialmente do conhecimento de pessoas que por sua vez não dominam as técnicas de desenvolvimento de software.
Identificação das falhas
Enquanto os gerentes de projetos de outras áreas podem orgulhar-se de colocar no mercado produtos sem defeitos, os gerentes de produtos de software, geralmente devem contentar-se em oferecer produtos que sejam confiáveis, não necessariamente sem defeitos. Confiáveis são produtos que podem apresentar defeitos, mas estes não devem ocorrer em situações normais de uso, não podem ser frequentes e nem aparecer nos momentos mais críticos de uso do produto.
Outra consideração significativa diz respeito às indicações de possíveis falhas. Nas demais áreas, as falhas são geralmente antecedidas por ocorrências facilmente percebidas, tais como rachaduras em prédios, barulhos estranhos em máquinas, cheiros incomuns em aparelhos elétricos ou produtos químicos, fumaça em motores, por exemplo. Em produtos de software as possíveis falhas muitas vezes só são percebidas na hora do uso.
Várias formas de se implementar o mesmo produto
Na maioria das áreas o número e a variedade de implementações satisfatórias é, em geral pequeno, isto quando não se reduz a uma só. Em engenharia de software pode haver uma enorme variedade de implementações satisfatórias. Desta forma as especificações de um projeto de produto de software devem incluir diretrizes para se escolher adequadamente uma alternativa correta.
Dependência de outros fatores
Outra dificuldade em projetos de software é que a qualidade dos produtos de outras áreas depende, em geral, somente da qualidade construída no produto. Já na área de produtos de software a qualidade do resultado produzido pelo software depende da qualidade da máquina na qual ele vai ser executado, da qualidade dos outros produtos de software com os quais ele interage (sistema operacional, compilador, servidor de aplicação, gerenciador de Banco de Dados, etc.).
Instabilidade dos requisitos
Normalmente, quem pretende construir um prédio ou uma máquina tem previamente uma ideia formada do que quer ou, pelo menos, não começa a execução sem ter essa ideia, porém, na engenharia de software não é raro nos deparamos com um cliente que quer um sistema para resolver um problema que ele não sabe exatamente qual é e nós iniciarmos o projeto antes de conhecer o problema a fundo. Como nestes casos começamos a trabalhar sem saber exatamente onde queremos chegar, é normal que ao longo do tempo os requisitos mudem e parte do trabalho tenha que ser refeita, consequentemente, não conseguimos cumprir o planejamento original.
sexta-feira, 26 de março de 2010
JAD (Joint Application Design) - Técnica de levantamento interativo
No desenvolvimento de sistemas, uma das tarefas mais difíceis é conseguir extrair do cliente todos os requisitos necessários a fim de retratar fielmente o processo de negócio que será implementado por meio de um sistema informatizado.
Esta dificuldade tem várias causas possíveis: muitas vezes os requisitos não estão suficientemente claros para o próprio cliente do sistema; os processos de negócios passam por áreas e pessoas diferentes e nem sempre elas concordam sobre quais são os requisitos do sistema; outras vezes, o cliente aproveita a oportunidade de informatizar o processo de negócio para rever o próprio processo e essas duas atividades acabam se confundindo; o cliente pode mudar de ideia ao longo do tempo e um requisito definido no início da especificação pode estar diferente no final.
Para minimizar estes problemas, uma solução é reunir todos os envolvidos com a definição dos requisitos e fazer um esforço concentrado para levantar os requisitos do sistema no menor espaço de tempo possível.
Uma boa ferramenta para promover este tipo de dinâmica é o JAD (Joint Application Design). O JAD é uma técnica de levantamento interativo, criada por dois profissionais da IBM do Canadá na década de 1970 onde, em uma ou mais sessões, são reunidos todos os interessados no assunto para tomar as decisões sobre o mesmo. A técnica tem uma abordagem voltada para o trabalho em equipe e visa definir um modelo de solução de problemas baseado em CONSENSO.
A dinâmica do JAD:
São feitas reuniões participativas, chamadas de sessões, envolvendo representantes de todas as áreas relacionadas com os assuntos em discussão.
As regras da sessão:
Esta dificuldade tem várias causas possíveis: muitas vezes os requisitos não estão suficientemente claros para o próprio cliente do sistema; os processos de negócios passam por áreas e pessoas diferentes e nem sempre elas concordam sobre quais são os requisitos do sistema; outras vezes, o cliente aproveita a oportunidade de informatizar o processo de negócio para rever o próprio processo e essas duas atividades acabam se confundindo; o cliente pode mudar de ideia ao longo do tempo e um requisito definido no início da especificação pode estar diferente no final.
Para minimizar estes problemas, uma solução é reunir todos os envolvidos com a definição dos requisitos e fazer um esforço concentrado para levantar os requisitos do sistema no menor espaço de tempo possível.
Uma boa ferramenta para promover este tipo de dinâmica é o JAD (Joint Application Design). O JAD é uma técnica de levantamento interativo, criada por dois profissionais da IBM do Canadá na década de 1970 onde, em uma ou mais sessões, são reunidos todos os interessados no assunto para tomar as decisões sobre o mesmo. A técnica tem uma abordagem voltada para o trabalho em equipe e visa definir um modelo de solução de problemas baseado em CONSENSO.
A dinâmica do JAD:
São feitas reuniões participativas, chamadas de sessões, envolvendo representantes de todas as áreas relacionadas com os assuntos em discussão.
As regras da sessão:
- Todos os participantes são iguais. Nas sessões JAD, a estrutura hierárquica e de poder são deixadas do lado de fora. Todas as posições tem o mesmo peso e serão avaliadas pelo grupo sem levar em conta qual é a origem da mesma.
- Apenas uma pessoa fala de cada vez. Assim todos terão chance de expressar a sua opinião e de ouvir as opiniões do restante do grupo.
- Todas as opiniões são válidas. É preciso não ter uma posição pré-concebida sobre as opiniões dadas.
- Hora para começar, interromper e terminar. É necessário definir uma agenda para as sessões e cumpri-la à risca.
- Celular desligado. Durante a sessão não devem acontecer interrupções externas.
- Recursos visuais. Utilizar intensivamente recursos visuais para tornar o projeto do sistema mais palpável e permitir que ele seja entendido pelos diversos participantes. Uma fotografia é mais explicativa e rica em detalhes do que 1000 palavras para a descrição de um fato.
- Sponsor (Patrocinador). É o executivo responsável pelo projeto, o dono do sistema. Ele precisa ter autonomia para tomar decisões, definir estratégias e direcionar o trabalho.
- Facilitador. É o responsável por conduzir a sessão. Ele não precisa ser um especialista no assunto que está sendo tratado. Ele deverá estar focado em organizar a dinâmica, dando a palavra a cada participante, obtendo o consenso sobre os assuntos tratados, organizando o registro das decisões e intermediando os conflitos.
- Escriba. É a pessoa responsável por registrar todas as discussões e decisões em um local que todos possam visualizar, como um quadro ou flip-chart.
- Documentador. É o responsável por registrar todas as decisões em um documento formal, como uma ata de reunião ou uma especificação de requisitos, que será assinado por todos ao final das sessões.
- Especialistas. São as pessoas que tem conhecimento do assunto que está sendo discutido e que podem efetivamente contribuir para a discussão e na tomada de decisões.
- Observadores. São pessoas que estão na sessão apenas para conhecer mais do assunto que está sendo tratado ou para assimilar a técnica da reunião. Os observadores não podem se manifestar durante a sessão.
- A sessão precisa ter presente as pessoas que tem poder de decisão sobre o assunto tratado, pois, não adianta tomar decisões durante a reunião que poderão ser contestadas quando todos voltarem para o escritório.
- As decisões precisam ser tomadas por consenso, pois, todos os participantes da sessão precisam sair de lá comprometidos com as definições registradas.
- As sessões devem ocorrer fora do ambiente de trabalho dos participantes para evitar interrupções e prevenir que os participantes se vejam tentados a tratar de assuntos ligados a sua rotina diária.
- Não deixar que os participantes imponham suas opiniões em função do seu nível hierárquico, para evitar que pessoas de nível hierárquico mais baixo fiquem constrangidas em debater ou discordar.
- Definir claramente qual será o produto gerado no final das sessões.
- Maior produtividade. Estudos relatam aumentos de 20 a 60% na produtividade, em relação aos métodos tradicionais.
- Maior qualidade. Usuários e analistas de sistemas costumam citar “projeto de softwares de alta qualidade” como sendo o maior benefício do método.
- Trabalho em equipe. Promove o espírito de cooperação, entendimento e trabalho em equipe.
- Custos mais baixos. O projeto de alta qualidade, obtido através do JAD, possibilita uma grande economia de tempo e dinheiro mesmo após a entrega do sistema.
segunda-feira, 18 de maio de 2009
Processos X Projetos
Não é raro que as pessoas confundam essas duas palavras e seus significados: processos e projetos. Mas a distinção dos dois termos é fundamental para quem está inserido numa organização.
Um processo pode ser definido como uma sequência de atividades dinâmicas e contínuas, logicamente relacionadas, executadas para obter um resultado bem definido. Outra definição descreve o processo como uma sequência de passos, tarefas e atividades que convertem entradas em uma saída. Um processo é contínuo e repetitivo.
Já um projeto é um empreendimento temporário com o objetivo de criar um produto ou serviço único. Tem início, meio e fim. O projeto é normalmente autorizado como resultado de uma ou mais considerações estratégicas: pode ser uma demanda de mercado, necessidade organizacional, solicitação de um cliente, avanço tecnológico ou requisito legal. Veja as principais características dos projetos: (1) são temporários, possuem um início e um fim definidos; (2) são planejados, executados e controlados; (3) entregam produtos, serviços ou resultados exclusivos; (4) são realizados por pessoas; e (5) são realizados com recursos limitados.
Ou seja, em geral, os processos estão relacionados ao dia-a-dia das empresas, enquanto os projetos estão mais relacionados à inovação ou novos produtos e serviços.
quinta-feira, 18 de dezembro de 2008
Vale a pena ser Gerente de Projeto?
Muitas vezes, o Gerente de Projetos recebe toda a pressão pelos resultados do projeto, mas, nenhum apoio para obtê-los.
O velho e bom Dilbert consegue demonstrar isso como ninguém.
Será que realmente vale a pena ser Gerente de Projeto? Essa é uma resposta que cada um precisa dar a si mesmo.
quinta-feira, 27 de novembro de 2008
Quanto o Gerente de Projeto precisa conhecer o assunto do projeto
Sempre que se debate o perfil ideal de um profissional para gerenciar um determinado projeto, surge uma dúvida: O Gerente do Projeto precisa entender apenas das técnicas gerais de gerenciamento de projetos (controle de prazos, custos, escopo, qualidade, etc.) ou é importante que ele entenda também do assunto do projeto que ele está gerenciando.
Eu, mais uma vez, vou lançar mão da reposta padrão dos consultores mais conceituados do mercado (aqueles que falam um monte de termos em inglês e cobram a hora em dólar): depende...
Em minha opinião, depende principalmente do tamanho do projeto.
Para um projeto muito grande, que envolve centenas ou milhares de pessoas com valores de investimentos elevados, importa muito pouco que o Gerente do Projeto seja um especialista no assunto objeto do mesmo, pois, além do projeto já ser complexo por si só e não existir possibilidade que uma única pessoa domine todas as áreas de conhecimento demandadas por ele, também é possível que o Gerente aloque especialistas nos diversos assuntos tratados. Para o Gerente de um grande projeto, é muito mais importante que ele possua características fortes de liderança, negociação, planejamento, etc.
Por exemplo, quando a Intelig começou a operar no Brasil, o seu capital majoritário era de origem francesa e foi designado para cuidar da implantação da empresa um advogado francês, que não entendia nada de tecnologia da informação ou de telecomunicações. Sob a liderança desse profissional, foi criada do zero uma nova companhia de telecomunicações para concorrer com a Embratel. Na época, a operação foi considerada um sucesso.
Contudo, se o projeto é de pequeno porte, o Gerente é mais exigido em ter um domínio maior sobre o assunto tratado pelo mesmo.
Imagine um projeto de desenvolvimento de sistemas com dois analistas, dois programadores e um Gerente de Projeto. Este Gerente pode não precisar entender tudo de especificação e construção de software, mas, com certeza ele não poderá ser um ignorante completo no assunto, pois, ele terá de discutir aspectos ligados à tecnologia a ser utilizada, ao processo de desenvolvimento, a modularização de sistemas, a interfaces com outros aplicativos, etc.
O Gerente de um projeto pequeno tem muito menos suporte de recursos financeiros ou humanos, para se abster totalmente do assunto do projeto e se concentrar apenas na gestão.
Por isso, normalmente, quem se torna Gerente dos Projetos são profissionais ligados à área executora dos mesmos. Engenheiros em obras ou analistas de sistemas na construção de software. Porém, se estes profissionais querem progredir na carreira trabalhando efetivamente como Gerente de Projeto, eles precisam se preparar para abstrair dos assuntos dos projetos e se concentrar mais nas técnicas de gerenciamento, pois, somente assim, eles terão a possibilidade de gerenciar projetos de maior complexidade.
Para termos uma noção do conhecimento necessário do Gerente de Projeto sobre o assunto, conforme o tamanho do projeto, podemos imaginar um gráfico parecido com o abaixo:
Eu, mais uma vez, vou lançar mão da reposta padrão dos consultores mais conceituados do mercado (aqueles que falam um monte de termos em inglês e cobram a hora em dólar): depende...
Em minha opinião, depende principalmente do tamanho do projeto.
Para um projeto muito grande, que envolve centenas ou milhares de pessoas com valores de investimentos elevados, importa muito pouco que o Gerente do Projeto seja um especialista no assunto objeto do mesmo, pois, além do projeto já ser complexo por si só e não existir possibilidade que uma única pessoa domine todas as áreas de conhecimento demandadas por ele, também é possível que o Gerente aloque especialistas nos diversos assuntos tratados. Para o Gerente de um grande projeto, é muito mais importante que ele possua características fortes de liderança, negociação, planejamento, etc.
Por exemplo, quando a Intelig começou a operar no Brasil, o seu capital majoritário era de origem francesa e foi designado para cuidar da implantação da empresa um advogado francês, que não entendia nada de tecnologia da informação ou de telecomunicações. Sob a liderança desse profissional, foi criada do zero uma nova companhia de telecomunicações para concorrer com a Embratel. Na época, a operação foi considerada um sucesso.
Contudo, se o projeto é de pequeno porte, o Gerente é mais exigido em ter um domínio maior sobre o assunto tratado pelo mesmo.
Imagine um projeto de desenvolvimento de sistemas com dois analistas, dois programadores e um Gerente de Projeto. Este Gerente pode não precisar entender tudo de especificação e construção de software, mas, com certeza ele não poderá ser um ignorante completo no assunto, pois, ele terá de discutir aspectos ligados à tecnologia a ser utilizada, ao processo de desenvolvimento, a modularização de sistemas, a interfaces com outros aplicativos, etc.
O Gerente de um projeto pequeno tem muito menos suporte de recursos financeiros ou humanos, para se abster totalmente do assunto do projeto e se concentrar apenas na gestão.
Por isso, normalmente, quem se torna Gerente dos Projetos são profissionais ligados à área executora dos mesmos. Engenheiros em obras ou analistas de sistemas na construção de software. Porém, se estes profissionais querem progredir na carreira trabalhando efetivamente como Gerente de Projeto, eles precisam se preparar para abstrair dos assuntos dos projetos e se concentrar mais nas técnicas de gerenciamento, pois, somente assim, eles terão a possibilidade de gerenciar projetos de maior complexidade.
Para termos uma noção do conhecimento necessário do Gerente de Projeto sobre o assunto, conforme o tamanho do projeto, podemos imaginar um gráfico parecido com o abaixo:
quarta-feira, 15 de outubro de 2008
Certificação em Gerência de Projetos do IPMA
O instituto que trata a gerência de projetos mais conhecido internacionalmente é o PMI (Project Management Institute), que publica o conhecido guia de práticas PMBOK.
Um profissional, para ser reconhecido no mercado como uma pessoa que domina a gerência de projetos, tem a opção de se certificar junto ao PMI, candidatando-se à certificação PMP (Project Management Professional). Quem obtém tal certificação, demonstra que conhece a fundo as práticas descritas no PMBOK.
Contudo, o PMI não é o único instituto internacional de gerência de projetos e nem a PMP é a única certificação disponível. Outro instituto que tem um reconhecimento internacional e muitas empresas adotam as suas práticas de gerenciamento de projetos é o:
IPMA – International Project Management Association
O IPMA foi fundado em 1965, com sede na Suíça, segue uma linha similar ao PMI, porém, com enfoque voltado a atividades e não disciplinas. Ele provém uma linha de base padronizada com foco em conhecimento, experiência e atitudes pessoais. O seu framework é mais utilizado na Europa, enquanto o PMI é mais forte nas américas. Ele é representado no Brasil pela ABGP (Associação Brasileira de Gerenciamento de Projetos).
O IPMA também oferece uma certificação para profissionais de gerenciamento de projetos. Diferentemente do PMI, a certificação do IPMA é divididas em níveis, de forma que o profissional pode ir "escalando" o seu reconhecimento no mercado gradativamente. Os níveis de certificação são:
Nível D: Associado em Gerenciamento de Projetos Certificado (Cerfied Project Management Associate)
Deve ter conhecimentos de Gerenciamento de projetos, os quais poderão ser aplicados em alguns campos da sua especialidade não é exigida experiência profissional.
Nível C: Gerente de Projetos Certificado (Certified Project Manager)
É capaz de gerenciar, com razoável independência, projetos não complexos, coordenar as tarefas técnicas de equipes de projeto e apoiar o gerente de um projeto complexo em todas as áreas de aplicação do gerenciamento de projetos.
Nível B: Gerente de Projetos Sênior Certificado (Certified Senior Project Manager)
Deve ter a capacidade de gerenciar projetos complexos com total independência.
Nível A: Diretor de Projetos Certificado (Certified Projects Director)
Deve ter a capacidade de dirigir todos os projetos constituintes de um programa ou todos os projetos de uma empresa ou linha de negócio ou ainda um projeto complexo com participantes de diferentes culturas e geografias
Para os níveis mais altos de certificação, o IPMA usa, além de provas de conhecimento, outros critérios de avaliação, como entrevista e comprovação de experiência.
A desvantagem mais evidente da certificação IPMA, é que no Brasil ela não é tão reconhecida pelo mercado quanto a do PMI. Mas, pode ser uma alternativa mais barata e gradual de se certificar, ou então, uma opção para completar os conhecimentos em gerência de projetos com outro framework.
Um profissional, para ser reconhecido no mercado como uma pessoa que domina a gerência de projetos, tem a opção de se certificar junto ao PMI, candidatando-se à certificação PMP (Project Management Professional). Quem obtém tal certificação, demonstra que conhece a fundo as práticas descritas no PMBOK.
Contudo, o PMI não é o único instituto internacional de gerência de projetos e nem a PMP é a única certificação disponível. Outro instituto que tem um reconhecimento internacional e muitas empresas adotam as suas práticas de gerenciamento de projetos é o:
IPMA – International Project Management Association
O IPMA foi fundado em 1965, com sede na Suíça, segue uma linha similar ao PMI, porém, com enfoque voltado a atividades e não disciplinas. Ele provém uma linha de base padronizada com foco em conhecimento, experiência e atitudes pessoais. O seu framework é mais utilizado na Europa, enquanto o PMI é mais forte nas américas. Ele é representado no Brasil pela ABGP (Associação Brasileira de Gerenciamento de Projetos).
O IPMA também oferece uma certificação para profissionais de gerenciamento de projetos. Diferentemente do PMI, a certificação do IPMA é divididas em níveis, de forma que o profissional pode ir "escalando" o seu reconhecimento no mercado gradativamente. Os níveis de certificação são:
Nível D: Associado em Gerenciamento de Projetos Certificado (Cerfied Project Management Associate)
Deve ter conhecimentos de Gerenciamento de projetos, os quais poderão ser aplicados em alguns campos da sua especialidade não é exigida experiência profissional.
Nível C: Gerente de Projetos Certificado (Certified Project Manager)
É capaz de gerenciar, com razoável independência, projetos não complexos, coordenar as tarefas técnicas de equipes de projeto e apoiar o gerente de um projeto complexo em todas as áreas de aplicação do gerenciamento de projetos.
Nível B: Gerente de Projetos Sênior Certificado (Certified Senior Project Manager)
Deve ter a capacidade de gerenciar projetos complexos com total independência.
Nível A: Diretor de Projetos Certificado (Certified Projects Director)
Deve ter a capacidade de dirigir todos os projetos constituintes de um programa ou todos os projetos de uma empresa ou linha de negócio ou ainda um projeto complexo com participantes de diferentes culturas e geografias
Para os níveis mais altos de certificação, o IPMA usa, além de provas de conhecimento, outros critérios de avaliação, como entrevista e comprovação de experiência.
A desvantagem mais evidente da certificação IPMA, é que no Brasil ela não é tão reconhecida pelo mercado quanto a do PMI. Mas, pode ser uma alternativa mais barata e gradual de se certificar, ou então, uma opção para completar os conhecimentos em gerência de projetos com outro framework.
segunda-feira, 6 de outubro de 2008
Modelos de maturidade em gestão de projetos - OPM3
Os profissionais da área de TI já estão habituados há algum tempo a lidar com modelos de maturidade no desenvolvimento de software, onde os mais conhecidos no Brasil são o CMMI e o MPS.BR. Estes modelos procuram determinar quanto uma organização está madura no processo de desenvolvimento de softwares. Quanto maior o nível de maturidade da organização, melhor é a qualidade do produto final.
Porém, começa a ficar mais comum no mercado se falar em “modelo de maturidade em gestão de projetos”. O princípio é o mesmo dos modelos de software: eles procuram medir a maturidade da organização no gerenciamento de seus projetos, portfólios e programas. Quanto maior o nível de maturidade, melhor a qualidade dos projetos tratados pela organização.
Os modelos de maturidade de gestão projetos mais comuns no mercado são:
· ESI – International’s Project Framework
· PMMM – Project Management Maturity Model
Criado por Harold Kerzner em 2001 e descrito no livro “Strategic Planning for Project Management using a Project Management Maturity Model”. John Wiley & Sons. Composto de cinco níveis de maturidade, a exemplo do CMMI.
· Prado-MMGP (Modelo de Maturidade em Gerenciamento de Projetos) – veja detalhes no blog PontoGP.
Está descrito no livro “Maturidade em Gerenciamento de Projetos”, Darci Prado. Não chega a ser um modelo muito popular, mas, é um exemplo de um modelo desenvolvido no Brasil.
Porém, neste post, eu vou me concentrar no modelo OPM3 do PMI. Depois eu entro em mais detalhes sobre os modelos acima.
· OPM3 – Organizational Project Management Maturiry Model
É um modelo desenvolvido pelo PMI (Project Management Institute), que é responsável também pelo PMBOK, o guia de referência em gerenciamento de projetos mais conhecido no mundo. Por isso, o OPM3 é 100% compatível com o PMBOK. Ele foi desenvolvido de forma virtual em 35 países, com o apoio de mais de 800 voluntários com experiência em gerenciamento de projetos na identificação das melhores práticas.
Ele é estruturado a partir de um conjunto de Melhores Práticas (Best Practices), que são formadas a partir de um agrupamento de Capacidades (Capabilities):
Melhores Práticas (Best Practices)
Uma Melhor Prática é um caminho ótimo atualmente reconhecido pela indústria para se alcançar um objetivo. Para o gerenciamento de projetos organizacional, isto inclui a habilidade para entregar projetos consistentemente e com sucesso para implementar estratégias organizacionais. Existem aproximadamente 702 Melhores Práticas documentadas.
Elas são categorizadas de acordo com os domínios de Gerenciamento Organizacional de Projetos: Projeto, Programa e Portfólio. E também pelos níveis de maturidade de melhoria de processos: Padronizar, Medir, Controlar, Continuar melhorando:
Capacidades (Capabilities)
Um conjunto de Capacidades é que dão a possibilidade de alcance de uma Melhor Prática. São passos incrementais rumo a níveis superiores de maturidade. A existência de uma capacidade é demonstrada pela existência de seus Resultados (Outcomes) correspondentes.
As Capacidades são categorizadas por grupos de processos: Iniciar, Planejar, Executar, Controlar e Concluir.
Resultados (Outcomes)
É o resultado tangível ou intangível da aplicação ou demonstração de uma capacidade.
KPI (Key Performance Indicators)
Representa a medição de um Outcome através de uma métrica.
A estrutura geral do modelo é:
O modelo contempla um “Diretório de Melhores Práticas”, onde elas são documentadas e um “Diretório de Capacidades” associadas a uma dada Melhor Prática.
O modelo é baseado em um ciclo constituído de: Conhecimento, Avaliação e Aperfeiçoamento. Portanto, para se fazer a avaliação da maturidade da organização, é preciso seguir os passos abaixo:
- Estudar o modelo
Ler e obter o conhecimento básico do OPM3, seus componentes e operação.
- Realizar a Avaliação
Determinar o ambiente geral no “continuum” da maturidade organizacional de gerenciamento de projetos.
- Determinar o foco de melhoria
Identificar as áreas de Melhores Práticas mais carentes de melhoria.
- Determinar o caminho de melhoria
Identificar as Capacidades necessárias para executar as melhorias com base nas Melhores Práticas.
- Avaliar as Capacidades atuais
Determinar quais Capacidades identificadas no passo anterior já existem na organização e quais devem ser desenvolvidas.
- Plano para Melhorias
Criar plano para o desenvolvimento de Capacidades necessárias para executar as Melhores Práticas, priorizando conforme identificado anteriormente. Alinhar as necessidades da organização e recursos disponíveis. Aplicar processos descritos no guia PMBOK
- Implementar Melhorias
Pôr em prática o plano de melhorias. Reajustar o plano de acordo com o clima da organização.
- Repetir o processo
Reavaliar a organização para confirmar ou não o progresso. Continuar trabalhando em Melhores Práticas identificadas anteriormente.
O PMI oferece duas ferramentas para realizar a avaliação da organização: “OPM3 Self Assessment” permite uma avaliação mais superficial da organização e “OPM3 ProductSuite” onde a avaliação é conduzida por um consultor certificado. Ambas são cobradas.
A avaliação é feita a partir de um questionário com 151 questões, veja o início do questionário:
O resultado é dado de forma a mostrar o nível de maturidade da organização em relação às várias categorias analisadas e às Melhores Práticas que devem ser melhoradas:
Assinar:
Postagens (Atom)