segunda-feira, 2 de março de 2015

Plano de gerenciamento de projetos para quê?





Um dos processos que mais me intriga no Gerenciamento da Integração do PMBOK é o de “Desenvolver o plano de gerenciamento do projeto”. Sabemos que o primeiro processo deste grupo de processos é “Desenvolver o termo de abertura do projeto” e também sabemos que para desenvolver o mesmo teremos as seguintes atividades:

  • Especificação do trabalho do projeto: determina o escopo do produto, explicando a necessidade do negócio, podendo ainda justificar essa necessidade utilizando o plano estratégico da empresa. Basicamente, descreve o que precisa ser o resultado do projeto.
  • Business case: justifica o motivo do projeto ser realizado utilizando aspectos de mercado. Em suma, “vende” o projeto para o patrocinador.
  • Acordos: descreve as responsabilidades de cada parte envolvida no projeto. Geralmente representado por um contrato.
  • Fatores ambientais da empresa: padrões ou situações culturais da empresa ou de fora da mesma que podem influenciar no projeto.
  • Ativos de processos organizacionais: documentações formais que determinam processos de trabalho a serem seguidos durante a execução do projeto.

Com essas informações, o PMBOK nos diz que podemos ter, no TAP (Termo de Abertura do Projeto), as seguintes informações:

  • Finalidade ou justificativa do projeto;
  • Critérios de sucesso do projeto;
  • Requisitos de alto nível;
  • Premissas e restrições;
  • Descrição de alto nível do projeto e seus limites;
  • Riscos de alto nível;
  • Resumo do cronograma (marcos);
  • Resumo do orçamento;
  • Lista das partes interessadas;
  • Requisitos para aprovação (quem aprova e decide que acabou)
  • Patrocinador

Pense bem: considerando o cenário de trabalho da região de Passo Fundo e os níveis de maturidade em GP que as empresas daqui apresentam, me faço a seguinte questão: vale a pena desenvolver um PGP (Plano de gerenciamento do projeto) mesmo que o TAP contenha tudo que se precisa saber?

Concordo que é preciso detalhar, pelo menos em nível médio, os requisitos e cronograma do projeto. Consideraria, até, uma pequena seção para as informações de Recursos Humanos do projeto. Mas, além dessas duas informações, o que mais uma empresa de médio porte necessitaria para ter uma boa gestão do projeto sem o PGP?

Ainda não estou convencido, e acredito que poucas empresas realmente precisam desse documento. E vocês, o que acham desse documento e de sua utilidade? 

Compartilhe sua opinião nos comentários :)
Compartilhe este artigo:

segunda-feira, 10 de fevereiro de 2014

Você está pronto para ser Product Owner?



Agora que já estudamos um pouco mais sobre quem é e o que faz o Product Owner, é hora de pensar se temos as qualidades e habilidades necessárias para cumprir bem esta função. Portanto, separei algumas das características mais exigidas e procuradas por grandes empresas na descrição de cargos de Product Owner. Confira:
  • Visão: um bom Product Owner precisa entender e enxergar como será o produto entregue ao final do projeto para assim poder orientar o time;
  • Liderança: o PO (Product Owner) atua em um papel muito parecido com o de Gerente de Projetos, portanto, é preciso ter facilidade em guiar o time na direção correta;
  • Negociação: a principal função do PO é fazer a ligação entre o cliente, a empresa e o time Scrum, e isso exige negociação de prazos, requisitos, custos e tudo mais. Portanto, o PO precisa ser um bom negociador para agradar à todas as partes.
  • Experiência: para poder ter uma boa visão do projeto e responder as duvidas do time é extremamente aconselhável que o PO tenha experiência na área em que está atuando, assim, os prazos diminuem e o ruído na comunicação praticamente não existirá.
  • Comunicação: descrever requisitos de forma objetiva para o time e apresentar os recursos do produto de forma clara para o cliente são os desafios diários de um PO, portanto, a comunicação eficaz é indispensável. Afinal, quem quer um PO lento em um projeto ágil?
Então, será que você está pronto para encarar este desafio? Pensou em mais alguma característica que um Product Owner tem que ter? Então compartilhe conosco nos comentários, e não deixe de acessar os links abaixo para entender melhor o que se espera de um Product Owner!

How a Product Owner work
How to make a good Product Owner
How to be a Product Owner

Até mais!

Compartilhe este artigo:

terça-feira, 28 de janeiro de 2014

Você sabe quem é o Product Owner?

Se você faz parte de um time de desenvolvimento de software, provavelmente usa o Scrum no dia a dia, correto? Não? Tudo bem, a maioria das empresas não usa (ainda).



As maiores empresas de software do mercado já usam as boas práticas do Scrum em seus processos diários de desenvolvimento para aumentar a produtividade e agilizar a entrega de seus projetos, e em breve a sua empresa deve começar também (se você também está esbarrando na resistência das pessoas à mudança, este texto pode te ajudar).

Um papel muito importante do Scrum é o de Product Owner, a pessoa responsável por entender os requisitos do produto e fazer o meio campo entre o cliente e o time de desenvolvimento. A lista de tarefas deste papel é extensa, e realizar todas essas atividades com sucesso exige dedicação integral da pessoa para o time. Dentre as tarefas do Product Owner, estão:
  • Criar a visão do produto: imaginar como ele será quando estiver pronto e descrever o que o mesmo precisará atender;
  • Gerenciar o Product Backlog: adicionar e remover itens do Product Backlog, sempre mantendo-o atualizado e de acordo com o andamento do projeto;
  • Gerenciar o Plano de Liberações: artefato que define a ordem em que as funcionalidades do produto serão entregues.
  • Aprovar ou rejeitar as entregas: avaliar se o produto entregue atende os requisitos de aceitação, e recusá-lo sempre que necessário, pois é o Product Owner que apresentará o produto ao cliente, portanto, ele precisa estar certo de que a entrega cumprirá o prometido.
  • Manter os interessados atualizados sobre o projeto, envolvendo-os em reuniões sempre que necessário;
  • Gerenciar o orçamento do projeto, utilizando seus recursos para garantir que os prazos sejam cumpridos.
  • Estar presente nas reuniões do Scrum, pois sempre que o time possuir alguma dúvida sobre o produto deverá recorrer ao Product Owner para esclarecê-la.
Percebeu como o Product Owner chega muito próximo de ser um Gerente de Projetos?  Ele acaba sendo a referência para o time, e é responsável por garantir que o produto final seja entregue dentro do esperado, no tempo esperado e com o custo combinado.

Quer saber mais sobre a vida de Product Owner? Consulte os links abaixo:
Entendendo o papel de Product Owner
Mas o que faz um Product Owner?

Compartilhe este artigo:

domingo, 15 de dezembro de 2013

Conceitos básicos do BPMN



Olá pessoal, tudo bem?

Estive essa semana precisando relembrar alguns conceitos básicos de BPMN e encontrei um material muito legal no blog da iProcess que traz um passo a passo muito bem explicado sobre os conceitos básicos do BPMN. Veja abaixo os links dos materiais:

1 - Atividades e sequências
2 - Gateways
3 - Eventos de Início e Fim
4 - Eventos Intermediários
5 - Subprocessos
6 - Swimlanes e Artefatos

O material é bem completo e tem exemplos bem legais que facilitam a interpretação e visualização da aplicação dos conceitos básicos. Vale a pena conferir! Compartilhe este artigo: