Produtividade e projetos bem sucedidos: O que está faltando?

Por Roberto Argento (http://www.linkedin.com/in/robertoargento)

Há cerca de um mês deparei-me com o artigo de Joe Marasco: “Software development productivity and Project success rates: Are we attacking the right problem?” . Ele toca num assunto que havia chamado minha atenção durante várias sessões de “project assessments” que eu me dediquei em 2005. Durante o ano passado participei da avaliação de cerca de 14 projetos ou organizações de desenvolvimento em 6 países da América latina (México, Brasil, Chile, Argentina, Peru e Colômbia), em diversos setores da economia (finanças, seguros, telecom, software houses, órgão públicos, energia) e abrangendo diversas tecnologias. Do desenvolvimento Java ao mainframe, da criação de produtos de prateleira à manutenção de ERPs. Nesses diagnósticos dois aspectos se sobressaíram.

O primeiro deles está relacionado ao estágio de desenvolvimento que a indústria de software se encontra em nossa região. É interessante notar que não há diferenças significativas de maturidade entre os projetos dessa pequena amostra. Estamos todos mais ou menos com as mesmas questões e caminhando na mesma direção.

O outro aspecto está relacionado a um problema comum a todos os projetos analisados: levantamento de requisitos . Não importa o sintoma apresentado pela equipe: “Não conseguimos testar, os sistemas são muito voláteis” ou “Os usuários mudam de idéia muitas vezes” ou “Tudo muda o tempo todo”. O fato é que todos os projetos analisados usam técnicas muito primárias para levantamento de requisitos. É quase como se quisessem tirar esse “problema” da frente e começar a desenvolver. É esse ponto que gostaria de explorar um pouco mais.

O interessante é que quase todas as equipes possuem bons padrões de documentação de requisitos: especificações funcionais, modelos, planilhas, etc. Entretanto, praticamente todos os grupos usam apenas uma técnica de levantamento de requisitos. Muitos deles recebem as especificações escritas e as tomam como boas, sem um aprofundamento maior, seja do problema ou da solução. É quase como se uma testemunha fosse interrogada apenas pelo promotor ou pelo advogado de defesa, sem nenhuma verificação ou busca de contradições no seu depoimento.

O senhor Marasco coloca esse tema sobre outro ponto de vista. Ele apresenta um contraste entre o importante ganho de produtividade das equipes de nas últimas décadas e a relativa pequena melhora na taxa de êxito nos projetos. Segundo o Chaos Report , publicado desde 1994 pelo Standish Group, a taxa de sucesso em projetos passou de 16% em 94, para 28% em 2001 e 31% em 2003. Nesse ritmo, apenas em 2014 vamos conseguir fazer com que metade dos projetos de desenvolvimento tenha sucesso.

Joe Marasco defende a tese que estamos sendo muito bons em desenvolver novas soluções, mas pouco eficientes em levantar o problema correto e os requisitos corretos. Ou seja, fazemos mais rápido e com técnicas mais sofisticadas as soluções erradas.

A prática de gerência de requisitos nos ensina que devemos combinar várias técnicas para levantar e esclarecer os requisitos. Assim conseguiremos validar o que um grupo está nos dizendo, o reinquirindo de outras formas e/ou comparando suas repostas com as de outros grupos. Técnicas como entrevistas, questionários, workshops, brain storms, entre outras, são raramente usadas de forma combinada com esse propósito.

Nossa experiência tem mostrado que não basta o uso de técnicas como casos de uso e desenvolvimento iterativo ou o uso de ferramentas de gerência de requisitos que permitam controlá-los, acompanhar suas mudanças e manter a rastreabilidade entre eles e os demais artefatos de software. Tudo isso é importante e garante um ganho de produtividade significativo, mas o uso de técnicas mais sofisticadas de levantamento é chave para quebrarmos o ciclo de construir a aplicação que achamos ser correta, receber as críticas, tentar novamente,...

Muitas vezes o simples treinamento em conjunto dos analistas de negócio, usuários e o pessoal de sistemas nas técnicas corretas, como aquelas descritas no RUP , reduzem graves problemas de entendimento entre os dois grupos. Em outras, o uso de uma consultoria especializada pode ajudar à organização a reduzir o abismo entre as áreas, diminuindo o estresse e facilitando o sucesso coletivo.

Como um colega costuma dizer: “Os usuários sabem o que querem, mas em geral não sabem descrevê-lo! Mas quando o vêem sabem identificá-lo”. Somente com um trabalho sistemático de levantamento das necessidades de negócios, dos requisitos de software, das especificações funcionais e não-funcionais, suportado por ferramentas que possibilitem o gerenciamento e a colaboração é que poderemos levar nossas equipes de desenvolvimento a um novo patamar. O patamar de produtividade e qualidade que nossas organizações precisam para competir no mundo plano .

Referências:

“Software development productivity and Project sucess rates: Are we attacking the right problem?”, por Joe Marasco, CEO, Ravenflow:
http://www-128.ibm.com/developerworks/rational/library/feb06/marasco/index.html?ca=drs-#rate

“Requirements: An introduction” por Scott McEwen, Metasys Technologies, Inc.
http://www-128.ibm.com/developerworks/rational/library/4166.html

Para mais informações ver: http://www.standishgroup.com

“Dissecting business from software requirements” por Jochen Krebs:
http://www-128.ibm.com/developerworks/rational/library/aug05/krebs/index.html

RUP - Rational Unfied Process
http://www-128.ibm.com/developerworks/rational/products/rup

Por que utilizar uma Metodologia de Desenvolvimento de Sistemas

A informalidade em projetos de TI tornou-se um fator de fracasso em muitos projetos. Alguns estudos, como por exemplo, às pesquisas publicadas pelo Standish Group, revelam que a quantidade de projetos fora do prazo, custo ou até mesmo abandonados, está diminuindo através da adoção de metodologias de gerenciamento de projetos. No entanto, não basta somente gerenciar melhor os projetos. É preciso aliar o bom gerenciamento de projetos com a escolha da melhor solução metodológica, observando sempre a cultura organizacional da empresa.
Uma Metodologia de Desenvolvimento de Sistemas é composta por seqüências de atividades executadas de forma organizada, que visam à construção de um Sistema de Informação com qualidade, no prazo e custo determinados, deve ser adequada à organização, de forma a otimizar o desenvolvimento de sistemas sem, no entanto, burocratizar a execução das atividades. Por este motivo, uma MDS desenvolvida para uma organização é eficiente apenas para a organização que a gerou, tornando-se menos eficiente em outra organização. Outra característica importante é que ela deve ser mutável, ou seja, da mesma forma que uma organização muda ao longo do tempo, ela deve adequar-se às mudanças de forma a manter a produtividade e eficiência desejada.
Existem diversas abordagens de ciclo de vida de software nas quais podemos basear uma MDS. Podemos citar, dentre as principais, o modelo Cascata, Evolucionário, por Prototipação, Iterativo e Incremental, dentre outros. Cada abordagem de ciclo de vida possui vantagens e desvantagens que precisam ser observadas na elaboração. Por exemplo, para softwares que tenham os requisitos estáveis e imutáveis, a abordagem em Cascata é mais eficiente. No entanto, seria um desastre a adoção do mesmo modelo para softwares que tenham os requisitos instáveis e mutáveis. Isso reforça o conceito de que cada organização deva ter sua própria metodologia e que a mesma deve ser desenvolvida observando a cultura organizacional e a estrutura de desenvolvimento proposta na organização.
Existem várias metodologias, nas mais variadas abordagens de ciclo de vida, disponíveis no mercado. Podemos destacar, dentre as principais, o RUP, OPENUP, XP, SCRUM. Pode-se também, conforme o caso, fazer um misto entre metodologias, obtendo assim o melhor de cada metodologia envolvida.
Quando bem implantada, traz, entre outros, os seguintes benefícios:
· Independência de indivíduos e facilidade de manutenção: Como os sistemas são bem estruturados e têm documentação padronizada e atualizada, um analista consegue, em pouco tempo, dar manutenção em um sistema que não conhece, evitando a figura do “dono do sistema”, situação desvantajosa tanto para a organização quanto para o próprio analista.
· Aumento da produtividade: Sistemas bem construídos têm mais partes reutilizáveis.
· Um bom gerenciamento de projetos: Como as etapas e produtos estão bem definidos, é possível saber a cada momento como está o andamento do projeto.
Uma metodologia atinge seu objetivo se for prática, de fácil utilização, rápida aprendizagem e, na medida do possível, suportada por ferramentas que automatizem tarefas repetitivas e mantenham o trabalho organizado. Portanto quando bem desenvolvida e adaptada à organização é uma poderosa ferramenta para se alcançar maturidade em desenvolvimento de projetos de TI.

Guia de Certificações do PMI - PMP

Segue um roteiro com os primeiros passos necessários para se tirar a certificação PMP. Antes de tudo lembre-se: "Basta darmos um primeiro passo e já não estaremos mais no mesmo lugar!!!"

O Project Management Institute (PMI) é uma instituição sem fins lucrativos criada nos Estados Unidos em 1969 com a finalidade de promover avanços nas técnicas de gerenciamento de projetos através da qualificação profissional.Vivemos numa sociedade em que a competição e o rápido avanço tecnológico são realidades. Dessa maneira, se faz cada vez mais necessária a capacitação qualitativa dos profissionais dos diversos setores da economia. Pensando dessa maneira que o Project Management Institute vem promover essa capacitação. Hoje, essa organização é a única que possui seu processo de certificação não só reconhecido em todo mundo, como também pela International Organization for Standardization (ISO).

O Project Management Professional (PMP) foi criado em 1984 e hoje é o principal produto do PMI. Consiste na certificação da qualidade profissional individual promovida por esse instituto e reconhecida em todo o mundo, tanto no que diz respeito ao conhecimento quanto à experiência necessária ao bom desempenho da missão de gerenciar projetos.O Certified Associate in Project Management (CAPM) foi instituído em 2002 e amplamente revisado em 2004, e está voltado para praticantes de gerenciamento de projetos que demonstrem conhecimento fundamental em gerenciamento de projetos, que atuem sob a orientação de gerentes de projetos experientes, e que ainda não atendam aos requisitos de experiência na área que os qualifiquem para a certificação PMP. Vale ressaltar que as empresas vêm exigindo a certificação PMP e, com isso, a certificação CAPM não parece ser um bom caminho por uma questão de mercado.

O Que é o Processo de Certificação PMP?
O processo de certificação PMP consiste em uma pré-qualificação do candidato seguida de uma prova teórica sobre as áreas de conhecimentos em gerenciamento de projetos segundo o Guia PMBoK.

E porque se Certificar?
• Profissionalização do papel de gerência de projetos.
• Ampliação da empregabilidade do profissional;
• Reconhecimento do grau de qualificação atestado internacionalmente;
• Possibilidade de adicionar um aumento salarial médio acima de 10%;
• Segundo dados do próprio PMI, em torno de 61% dos empregadores reembolsam o exame de certificação e as taxas de preparação aos candidatos aprovados.

Requisitos para Certificação
Em linhas gerais o candidato precisa comprovar experiência em projetos equivalente a um mínimo de 4500 ou 7500 horas dependendo se é ou não formado em nível superior, além de educação na área de gerenciamento de projetos.

Para se certificar como PMP você precisará:
• Ter Background Educacional
• Comprovar Experiência na área através de:
1)Para quem tem nível superior: Comprovação de no mínimo 4.500 hs de atividades de liderança e direção em projetos. Essas atividades obrigatoriamente têm que ter ocorrido no período compreendido entre os últimos OITO anos;
2)Para quem tem nível médio: Comprovação de no mínimo 7.500 hs de atividades de liderança e direção em projetos. Essas atividades obrigatoriamente têm que ter ocorrido no período compreendido entre os últimos OITO anos.
• Mínimo de 35 horas de educação recebida específica na área de gerenciamento de projetos.
• Estar de acordo com o Código de Conduta Profissional do PMI.
• Pagar a taxa de inscrição; (US$405.00 para membros ou US$555.00 para os que não forem membros).
• Passar na prova de certificação.
Obs.: Quanto à comprovação das horas, o PMI atua exigindo que o candidato formalize (através de assinatura) que está sujeito às diretrizes de ética da entidade. No momento da submissão do pacote ele exige que, para cada projeto reportado, seja indicado um contato que possa verificar a experiência informada (deve ser preenchido um formulário por projeto -tantos quantos necessários para atingir o mínimo das horas, - 4500 ou 7500, conforme o caso.). Posteriormente, por um processo de amostragem, o PMI audita os pacotes submetidos. Se o candidato for auditado, receberá solicitações para que apresente comprovações das horas trabalhadas. Caso não consiga fazê-lo, estará passível de sanções definidas pelas Diretrizes de Ética do PMI. (Muita atenção a esta observação. Não invente projetos, pois esta auditoria realmente acontece e conheço pessoas que foram auditadas).

A taxa de inscrição para a prova é de US$ 405.00 para membros do PMI ou US$ 555.00 para os não membros. Recomendo fortemente que se associem ao PMI em virtude dos benefícios que vocês terão tais como o recebimento de publicações técnicas com artigos de interesse da comunidade de gerenciamento de projetos.

Vide comparativo:
Filiando-se ao PMI e ao capítulo de seu estado: Filiação ao PMI - Anuidade (US$ 119,00) + Filiação ao PMI – 1ª Inscrição (US$ 10,00) + Filiação ao capítulo DF (US$ 20,00) + Inscrição p/ Prova (US$ 405,00) = US$ 554,00
Sem filiar-se ao PMI: Inscrição p/ Prova (US$ 555,00) = US$ 555,00

Observamos que optando por se tornar membro do PMI, bem como do Capítulo, você obterá maiores benefícios em função do investimento realizado, revertendo para si, mais benefícios além do direito de realizar o exame, posto que você ainda economizará US$ 1.00. Além dos benefícios em tornar-se membro, você pagará US$ 100.00 a menos caso precise fazer o reexame, uma vez que a taxa de reexame é de US$ 275,00 para membros do PMI e US$ 375,00 para não membros. (Vale a pena pensar nisso!!)

Uma vez cumpridos os requisitos apresentados, você receberá uma carta de elegibilidade credenciando-o a se submeter a prova em um dos locais autorizados para tal. A carta de elegibilidade tem um ano de validade.

Etapas do Processo de Certificação PMP
1º - Qualificação:
Consiste na verificação por parte do PMI das informações submetidas para que seja avaliado se o candidato é ou não habilitado a prestar o exame teórico. Em caso afirmativo, será encaminhada ao candidato uma carta informando-lhe todos os dados necessários para a marcação da prova,informações sobre adiamento e cancelamento, número de elegibilidade que o identifique e permita o agendamento do exame, além de informações sobre o local e condições de realização do exame.
2º - O Exame
De posse dessas informações, o candidato entrará em contato com um dos centros de testes e assim efetuará a marcação de seu exame, através da informação de seu número de elegibilidade.Isso irá autorizá-lo a fazer a prova, indicando-o local e condições para fazer o exame de certificação.O exame é realizado on-line via computador, sendo o resultado informado imediatamente após o término da prova. Em Brasília, a casa Thomas Jefferson é o centro Prometric autorizado para o exame PMP.
O exame para PMP consiste de uma prova de múltipla escolha com 200 questões - com 4 opções de resposta cada - sobre toda a área de conhecimento compilada no PMBoK. O candidato tem um máximo de 4 horas para completar o teste. O teste é composto de 175 questões válidas para o exame e de 25 questões de validação, as quais estão ordenadas de forma aleatória.O percentual mínimo de acerto das questões da prova para garantir a qualificação do profissional deve ser de 60, 57%, representando 106 das 175 questões. Cada questão tem apenas 1 (uma) única resposta correta dentre quatro alternativas possíveis. Todas as questões têm o mesmo valor -> 1(um) ponto, independentemente de sua complexidade. Os assuntos são divididos percentualmente da seguinte maneira:

- 11% -> Iniciação;

- 23% -> Planejamento;

- 27% -> Execução;

- 21% -> Controle;

- 9% -> Fechamento;

- 9% -> Responsabilidade Profissional.

Acessem o site http://www.pmi.org/ para maiores informações e para iniciarem todo o processo.
Bem, compreender o processo de certificação PMP é o primeiro passo para iniciar a empreitada! Disponibilizarei nos próximos posts o material que utilizei para estudar para a prova.

Certificações Profissionais: Somente o PMP é suficiente?

Por José Eduardo Motta Garcia, PMP (jose.eduardo.garcia@gmail.com)

Vistas por muitos como caça-níqueis de empresas e instituições, as certificações profissionais, que há tempos fazem muito sucesso entre os profissionais de TI, também estão presentes no mundo do gerenciamento de projetos. E nesta área, a certificação PMP do PMI é, sem dúvida, a mais conhecida e desejada. A pergunta é: quais outras certificações seriam importantes, além do PMP?
Partindo do pressuposto de que conhecimento nunca é demais, muitos poderiam responder que qualquer uma, relacionada à área de atuação, seria importante. Porém, além da questão financeira, temos que lidar com um recurso limitado, não renovável e cada vez mais escasso – o tempo.
O próprio PMI lançou as certificações CAPM, voltada para profissionais de projetos em início de carreira, e a PgMP, para os gerentes de programas com grande experiência. Ambas, por motivos distintos, ainda não se popularizaram no Brasil. A CAPM enfrenta um problema de que o mercado exige o PMP, seja qual for o nível de atividade a ser realizada. Já a PgMP, além de ser mais recente, possui mais pré-requisitos e um rigoroso processo de avaliação, e não apenas um exame.
No Brasil, muitos gerentes de projetos são oriundos da área de TI. Com isso, algumas certificações mais voltadas à tecnologia são freqüentemente requisitadas, como o ITIL, para gerenciamento de serviços de TI, e o COBIT, para governança de TI alinhada ao negócio.
Para metodologias de gerenciamento de projetos há várias opções. Entre as principais, destaque para a PRINCE2, criada pelo governo britânico, cuja principal vantagem é a flexibilidade de adaptação a cada projeto, e que cresce a cada ano no Brasil com as certificações Foundation e Practitioner. A suíça IPMA (International Project Management Association), representada no Brasil pela ABGP (Associação Brasileira de Gerenciamento de Projetos), é a mais antiga associação mundial em gerenciamento de projetos e também possui seu programa de certificações, dividido em 4 níveis. Há ainda metodologias alternativas e não menos interessantes, como a da Scrum Alliance, para gerenciar projetos ágeis, que concede a certificação Scrum Master para quem conclui com sucesso seu treinamento oficial.
Com relação a ferramentas, também existem as certificações específicas para os principais sofwares utilizados na área de projetos. A IIL (International Institute for Learning) certifica profissionais em Microsoft Project, com os níveis White, Orange, Blue e Black Belt. O Primavera, outro software bastante utilizado, possui certificações para os níveis básico e avançado.
Em se tratando de melhoria de qualidade em processos, a Six Sigma, criada a partir de práticas ensinadas na Motorola University, reina absoluta em popularidade. Posteriormente foi incorporado o conceito Lean, que é dar foco no que realmente é essencial. Esta certificação também possui vários níveis e a fonte mais respeitada é a ASQ (American Society for Quality).
Outro assunto que freqüentemente está na pauta de discussões entre profissionais da área é o modelo de maturidade. Para se montar um PMO, por exemplo, é quase inevitável utilizar um. O PMI possui o OPM3, e as certificações são para Assessor e Consultant. O mais utilizado, CMMI, também possui treinamentos oficiais no Brasil, reconhecidos pela SEI (Software Engineering Institute). Uma opção 100% brasileira é o MPS.Br, da SOFTEX, com as certificações de introdução, implementadores, avaliadores e de melhoria de processos.
Não há dúvidas que a certificação PMP é o primeiro grande objetivo de um gerente de projetos, porém a continuidade torna-se cada vez mais necessária. As alternativas são as mais variadas possíveis, e a área de atuação pode ajudar a definir o caminho. Buscar uma certificação de outra metodologia de gerenciamento de projetos e outra de modelo de maturidade tendem a ser opções interessantes.
Sobre o futuro, se eu fosse apostar em uma certificação promissora para a área de projetos, inovaria e colocaria minhas fichas na LEED Accredited Professional, da GBCI (Green Building Certification Institute), pois o conceito de sustentabilidade e a preocupação com o meio ambiente são cada vez mais evidentes na implantação de novos projetos, seja qual for o ramo de atividade da empresa.
Muitos defendem que o importante é apenas possuir o conhecimento e saber colocá-lo em prática, e que a certificação é dispensável. É claro que profissionais que se limitam apenas à teoria tendem a fazer sucesso apenas na área acadêmica, porém como provar ao mercado que se realmente conhece o assunto? Mas essa é outra discussão...

Mudanças no Escopo de um Projeto

Um dos maiores problemas vividos pelas equipes de desenvolvimento de sistemas tem sido gerenciar as mudanças ocorridas em um projeto. Saber lidar com essas mudanças tem sido um grande desafio para os gerentes de projetos, pois exige um conjunto de habilidades e boas práticas para controlá-las. Outro fator importante que devemos ter em mente é que as mudanças sempre existirão e que as mesmas não poderão ser inibidas.
Segundo a Rita Mulcahy, devemos entregar para o cliente exatamente o que ele solicitou; nem mais, nem menos. Entregar algo extra é um desperdício de tempo e não acrescenta benefícios ao projeto, especialmente considerando que somente 34% dos projetos são bem sucedidos. Esta afirmação também é abordada no PMBoK 3º edição, pagina 119, da seguinte maneira: “As mudanças não controladas são freqüentemente chamadas de aumento do escopo do projeto(Gold Plating)”
A falta de controle nas alterações do escopo origina-se ainda no início do projeto com os objetivos mal definidos no termo de abertura do projeto. A ausência de um plano de projeto juntamente com a falta de credibilidade por parte dos patrocinadores devido ao grande índice de falhas, falta de levantamento e elaboração de um plano de riscos e, principalmente, avaliação da “tripla restrição” a cada solicitação de mudanças, são os pilares de um projeto mal sucedido. Outro fator importante e pouco observado pelos gestores de projetos é que todo projeto deve ter um plano de comunicação bem estruturado e definido para que todos os interessados no projeto possam acompanhar o desenvolvimento do mesmo através da distribuição das informações e dos relatórios de desempenho. Através dos relatórios de desempenho obtemos feedback das partes interessadas e aumentamos a certeza de que estamos “no caminho certo”.

Saber gerenciar as mudanças é essencial, principalmente quando envolve as mudanças de variáveis que podem gerar o fracasso de um projeto. Diante desta preocupação, o PMBoK em sua 3º edição, na área de conhecimento referente a Escopo, define o processo controle do escopo e atribuí a ele a responsabilidade de influenciar os fatores que criam mudanças no escopo do projeto e de controlar o impacto dessas mudanças. Ele garante que todas as mudanças solicitadas e ações corretivas recomendadas sejam processadas por meio do processo controle integrado de mudanças do projeto. Ainda, segundo o PMBoK, o processo controle do escopo do projeto também é usado para gerenciar as mudanças no momento em que efetivamente ocorrem e é integrado a outros processos de controle.
Sabemos que a necessidade de mudanças em um projeto é inevitável e que estas não podem ser inibidas. Diante dessa afirmação, temos que preparar nossos projetos de forma a se adaptarem as mudanças conforme ocorrem, mantendo sempre o foco nos objetivos definidos no termo de abertura do projeto. Não é necessariamente o excesso de mudanças que faz um projeto fracassar, mas a falta de controle e monitoramento das mesmas. Sendo assim, devemos observar que mudanças em um projeto não é uma falha, mas a falta de controle geralmente resulta num projeto fracassado. É imprescindível assumirmos que todos os projetos sofrem alterações e um bom gerente de projetos sempre planeja como essas mudanças serão solicitadas, validadas, implementadas, documentadas e comunicadas.