Arquivo mensal: fevereiro 2011

Ética em Gerenciamento de Projetos

Muita gente acredita que Código de Ética e Conduta Profissional seja uma das disciplinas do PMBOK. Trata-se de uma visão equivocada da realidade. Não que o PMI menospreze sua importância, até porque conduta ética, legal e profissional, bem como as responsabilidades de um gerente de projetos  abrangem 29 das 200 questões do exame de certificação PMP (14,5%).

“Visto não ser fácil relacionar uma questão específica a um domínio específico, as questões de ética e responsabilidade profissional usualmente aparecem associadas a questões comuns a todos os domínios, como sensibilidade cultural, gerenciamento de conflitos de interesse, …, aconselhamento, etc…” Mauro Afonso Sotille, PMP

O fato observado acima serve para comprovar a presença da ética nas nove áreas do conhecimento definidas pelo PMI. Porém, para justificar essa onipresença vejamos alguns exemplos de disciplinas onde a ética se destaca de forma mais intensa. No gerenciamento dos recursos humanos, o GP deve trabalhar sua liderança de forma imparcial, honesta e criteriosa. Para isso, deve apoiar os integrantes no seu desenvolvimento profissional, fornecendo feedbacks constantes, realizando avaliações consistentes, de forma a permitir o crescimento da equipe. Além de incentivar e motivar o GP deve estar atento a duas regras básicas:

1. Elogios e críticas

  • Ao elogiar algum profissional, o faça na frente de outras pessoas, possibilitando ele se sentir valorizado e com sua auto-estima ampliada.

  • Não pratique assédio moral! Ao criticar, o faça de forma discreta, sem expor o profissional.

2. “Pontos Fortes” e “Pontos Fracos”

Nas reuniões de feedback, o termo “pontos fortes” deve ser utilizado, pois permite destacar do profissional aquilo que tem de bom, porém o termo “pontos fracos” não deve fazer parte do vocabulário dos gerentes. Uma alternativa é usar a expressão “pontos a desenvolver”! Quando abordamos os pontos fracos de alguém deixamos claro que se trata de algo deficitário, estabelecido e incorporado a essa pessoa. Entretanto, se dissermos que o ponto a desenvolver é a comunicação escrita (como no exemplo acima), isto transmitirá a ela uma verdade (que não é boa), mas a mensagem trará de forma implícita uma idéia de que é algo a melhorar, possível e provável, pois depende do esforço da própria pessoa. Assim, a mensagem transmitida desta maneira tem uma carga de positividade, de desafio e estímulo [SOUZA, 2010].

O gerenciamento de aquisições é outra disciplina bastante vulnerável aos aspectos da ética. O gerente de projetos por diversas vezes tem a responsabilidade de escolher ou recomendar fornecedores e/ou pessoas que venham a dar suporte para o desenvolvimento do projeto. Nesse momento o GP não deve beneficiar empresas ou pessoas levando em conta interesses pessoais. Ele tem que ser imparcial e decidir quais são as melhores opções baseando-se em uma análise de capacidade e qualidade de serviços prestados.

Analisando o exposto acima fica claro como a ética e produtividade são fatores que caminham lado a lado. Espero que você também tenha notado! Ora, se eu como gerente de projetos assumir minhas responsabilidades com respeito, justiça e honestidade para com meus liderados obtenho em troca respeito e confiança. Por conseguinte, os stakeholders irão se inspirar por meio dos meus bons exemplos e ajudar a disseminar essa cultura organizacional da ética. O que certamente trará bons resultados com ganhos em produtividade e melhoria do ambiente de trabalho! Por isso, tenha sempre em mente que o Código de Ética e Conduta Profissional é requisito para o exercício pleno da profissão de gerente de projetos.

SOUZA, Washington. A ética e o gerenciamento de projetos. Blog CMMI. 2010.
DINSMORE, Paul C.; CAVALIERE, Adriane. Como se tornar um profissional em gerencimento de projetos. Qualitymark, 3ª ed. 2009.
Anúncios

6º encontro do grupo de estudos GE2PS

Ocorreu no último dia 15/02/2011, em uma universidade da capital sergipana, mais um encontro do Grupo de Estudos em Gestão e Engenharia de Projetos de Software. Fui convidade pelo professor Alércio Bressano para trabalhar como facilitador do encontro. Abordamos o tema “Liderança como fator de produtividade e lucratividade”.  Dentre alguns pontos que receberam destaque podemos citar:

– Perfis de liderança

– Características de um bom líder

– Como liderar em épocas de incertezas econômicas e políticas

Apresentei um vídeo com cenas do filme “Fomos Heróis” onde evidenciam-se as diversas características que um bom líder deve possuir. Podemos destacar ainda um artigo publicado na revista Você S/A trazido pelo professor Alércio o qual põe em cheque a teoria da liderança motivacional. Debatemos e analisamos os diversos pontos de vista apresentados.

Slides:

Vídeo:

Fotos do encontro:

Este slideshow necessita de JavaScript.

Depoimentos:

“O GE2PS é um momento ímpar de parar, refletir, aprender, trocar experiências, saber ouvir, fortalecer networking, enfim. Estamos “engatinhando” na área de desenvolvimento de software e estudar assuntos sobre gestão e engenharia são estratégias determinantes para um bom resultado e o sucesso na entrega de produtos e soluções informatizadas. Neste último encontro foi mais um exemplo de que precisamos evoluir nas habilidades interpessoais, na forma de lidar com as pessoas, na tarefa de liderar (não somente as outras pessoas, mas a nós mesmos). Sempre saio dos encontros do grupo com boas reflexões e motivado a mudar ainda mais! Não espere cair do céu o que você tanto almeja. Faça a mudança acontecer!”. Alércio Bressano (Gerente de Projetos e Professor Universitário)

Resultado da enquete: “Quais metodologias e/ou práticas ágeis você utilizaria em seu ambiente de trabalho?”

O resultado da enquete serve de indicativo para demonstrar alguns fatos. Dentre esses fatos destaca-se a preferência dos profissionais pelo framework Scrum (50%) que atualmente domina o cenário profissional das mais diversas organizações. Logo atrás com 20% vemos a Extreme Programming como metodologia mais aceita e preferida. A prática ágil TDD (Teste Driven Development) conseguiu alcançar expressivo resultado, o que demonstra a tendência cada vez maior do crescimento da área de testes no processo de desenvolvimento de softwares. Por fim, com menor força aparecem as metodologias FDD(5%), ASD (5%), e as não-votadas Crystal e DSDM. Esse último ponto demonstra ou a falta de conhecimento das práticas dessas metodologias ou ainda a não aceitação de suas técnicas por grande parte dos profissionais interessados em métodos ágeis.

Gráfico Burndown como ferramenta para avaliar riscos em Projetos Ágeis

O gerenciamento de riscos é uma disciplina fundamental utilizada durante todo o processo de desenvolvimento de um projeto. E você sabe por que, caro leitor? Porque, na verdade, tudo o que nós gerenciamos são riscos.  Vamos pensar um pouco: se preciso concluir uma tarefa no prazo estimado de um dia e planejo quais serão os passos necessários para concluir essa tarefa no prazo estabelecido, não estou gerenciando  meu tempo. Não se engane! Na verdade, o que você estou gerenciando é o risco de atrasar a conclusão daquela tarefa. Essa mesma linha de raciocínio pode ser utilizada em diversas outras situações.

Muitos acreditam que as metodologias ágeis ignoram completamente os riscos em um projeto. Nao é bem assim! O que acontece é que o manisfesto ágil aposta em valores que vão de encontro às crenças das metodologias tradicionais. Os riscos são vistos como inerentes aos projetos e são aceitos, mas nunca ignorados! Com suas pequenas iterações  e entregas constantes de produto potencialmente utilizável ao cliente, o time evita o maior risco que os projetos enfrentam: não entregar nada. Assim, as metologias ágeis buscam se antecipar à ocorrência dos riscos, o que prova que eles não são ignorados.

Hiren Doshi e Kane Mar publicaram, recentemente, alguns artigos sobre a análise do Gráfico de Burndown, apresentando que tipo de informações ou perguntas podemos extrair dele. Trata-se de “uma ferramenta importante para o acompanhamento do progresso de um time ágil e muitas informações podem ser extraídas do mesmo. Também podemos utilizá-lo para acompanhamento do projeto, produto ou releases” [HAZRATI, 2010].  A análise de Hiren Doshi foi baseada nas perguntas e no gráfico abaixo:

Em um gráfico de burndown eixo Y pode ter como unidade horas, semanas ou story points, enquanto o eixo X pode ser em dias ou sprints. É importante frisar que a unidade escolhida deve ser a mais adequada com a realidade de cada projeto ou organização, visto que cada unidade possui visões e objetivos diferentes.

“Burndown por horas e burndown por pontos tem propósitos diferentes!! Ninguém espera que um burndown por horas diga o quanto de valor foi entregue, mas apenas o acompanhamento do ritmo dirário do time. Os dois são importantes!” Alexandre Magno, CST

Podemos fazer uma análise do gráfico acima, o que nos trará subsídios para que possamos evitar que riscos futuros de projeto.

Observando a linha azul (linha 1) podemos visualizar um cenário não desejado. O time não conseguiu alcançar seus objetivos traçados durante a Sprint Planning, o que indica que o planejamento e/ou a execução não estão bons. Podemos citar algumas situações que podem contribuir para a construção deste cenário: planejamento de mais histórias do que a capacidade do time, alteração de prioridades durante o sprint ou uma falta de união do time. E quais são os riscos que este cenário apresenta?

  • Atrasos na entrega de partes potencialmente utilizáveis do produto ao cliente;
  • Desgastes com renegociação de prazos;

A linha roxa (linha 2) apresenta um cenário onde o time conseguiu atingir a meta, porém esteve longe do progresso ideal. A curva acentuada pode indicar que o time não atualizou suas estimativas de maneira adequada ou ainda que hisórias incompletas foram retiradas da sprint. Isso demonstra um time comprometido com o prazo, porém pouco interessado com a qualidade do processo e do produto gerado. O principal risco envolvido nesse cenário é a insatisfação do cliente com relação ao que foi prometido e o que realmente foi entregue. A consequência imediata pode ser desgaste na relação com o cliente, bem como eventuais quebras de contratos.

Por fim, a linha verde (linha 3) demonstra um cenário ideal, onde planejamento e execução foram bem feitos. O time é auto-organizado e bastante adaptável a mudanças. Porém, como diria o poeta,  nem tudo são flores! Sempre existe algo que pode ser melhorado e isso deve ser feito durante a Sprint Retrospective, que envolve uma análise dos pontos positivos e negativos apresentados pelo time durante a Sprint.

Bem o objetivo desse post foi demonstrar que o Gráfico de Burndown pode ser uma ótima ferramenta de apoio na gestão de riscos de projetos ágeis.  E para tanto, ela deve ser utilizada de acordo com as necessidades que o negócio ou organização necessita. Caso o leitor queira se aprofundar um pouco mais no assunto, existe um artigo publicado na LOCAWEB que faz uma outra análise sobre o Burndown focada em mudanças na sprint. Há também um outro artigo muito interessante de Kane Mar, Seven common Sprint Burndown graph signatures, onde ele separa o Burndown em sete categorias apresentando as nuances desses diversos cenários. Vale a pena conferir!

DOSHI, Hiren. Sprint Burndown says a lot about your scrum team... PracticeAgile  Software Development, 2010.
HAZRATI, Vikas. Analisando gráficos de Burndown. InfoQ, 2010.
Mudanças de Sprint. LOCAWEB, 2010.
MAR, Kane. Seven common Sprint Burndown graph signatures. 2006.