terça-feira, 26 de julho de 2011

Como lidar com a ausência (indisponibilidade) do Product Owner

Uma questão bastante abordada e discutida quando pensamos em projetos que utilizam do SCRUM como ferramenta de processo, é a ausência (indisponibilidade) do Product Owner. Se levarmos em consideração que PO é o "cara" que melhor conhece o produto, que tem clara a prioridade do que deve ser feito, é a pessoa que demanda as necessidades do negócio, considero natural que esta "entidade" não seja tão acessível quanto pregamos no SCRUM.
Como resolver esta questão?
Abaixo uma matéria escrita por Paulo Rebelo  no site  INFOQ explana um pouco mais sobre o assunto.

Como lidar com a ausência de um Product Owner efetivo

O papel do Product Owner tem grande importância no Scrum, mas muitos dos profissionais que assumem esse papel não possuem o tempo necessário para acompanhar a equipe, não tendo disponibilidade sequer para a evolução do produto da forma que merece. Neste artigo, são exploradas alternativas para tornar mais efetivo o papel do Product Owner. 

Papel e responsabilidades

Em Scrum, lembrando, temos três papéis bem claros: ScrumMaster, Product Owner e membro da Equipe (ou do Time). Nosso foco é no Product Owner, que possui basicamente as seguintes responsabilidades:
  • Conceber o produto, escrevendo suas histórias e funcionalidades gerais;
  • Priorizar as histórias de mais alto valor;
  • Estar disponível para a equipe, ajudando-a a entender os requisitos;
  • Aprovar as histórias realizadas pela equipe;
  • Definir as necessidades dos usuários;
  • Garantir o retorno de investimento para cada funcionalidade entregue;
  • Possibilitar que seja feito o mais simples possível, mantendo a funcionalidade necessária.
A efetiva contribuiçāo do Product Owner (PO), como se vê, é um fator chave para o sucesso do projeto. Mas será que os POs possuem a dedicação exigida para a entrega de um produto? Da mesma forma que a equipe e o ScrumMaster, o PO também precisa ter o foco necessário, sendo este um valor importante do Scrum.
É importante que o PO participe das reuniões diárias, e sua presença é obrigatória em Reviews e Plannings (lembrando que Review é a reunião de apresentação do que foi realizado pelo time, e Planning é a reunião de planejamento do que será feito em um determinado ciclo de entrega). 
Recomenda-se ainda que o PO esteja disponível para a equipe, para lidar com eventuais dúvidas e sugestões. Além disso, na reunião de Product Grooming, contamos com o PO para trazer as respostas e os direcionamentos necessários.
No entanto, isso frequentemente não é o que acontece na prática, pois muitos dos Product Owners são extremamente ocupados, não possuindo o tempo para dedicação à equipe e principalmente ao produto. Muitos dos eleitos para a função de PO cuidam de outras atividades, outros produtos, até mesmo gerenciam outras equipes, dentre varias responsabilidades adicionais. Esse acúmulo de funções pode ser enormemente prejudicial para todos os envolvidos no projeto. 

Alternativas

Como lidar com essa situação? Em muitos casos, o que se pode fazer é tratar o PO atribulado como um Business Owner, delegando as tarefas do PO de fato, com o foco no desenvolvimento do produto e na equipe. Saber delegar e confiar no profissional para o qual está passando essa responsabilidade traz retorno para o próprio Business Owner. O PO precisa se conscientizar (ou ser conscientizado) de que não é possível "encaixar" mais um papel em seu dia-a-dia. Deve-se ainda reforçar que esta é uma responsabilidade básica para o Scrum.
É neste último ponto que talvez esteja o problema: será que a implantação do Scrum nas empresas fica realmente clara e transparente para todos? Às vezes, "transformamos" o atual Gerente de Projetos em ScrumMaster, treinamos o time de desenvolvimento em técnicas ágeis, mas e o Product Owner? Não bastaria apenas treinar aquele que hoje responde pelo produto, pois é ele mesmo quem deveria exercer essa função?
Querendo ou não, a denominação de PO do Scrum é confundida por muitos, talvez pela tradução literal da palavra ("dono do produto"). Mas, o fato é que a escolha do PO pode ser decisivo para o sucesso de um projeto. Imagine um PO sem capacidade de determinar o retorno de investimento do seu produto; ou que não saiba o que gera mais valor.
Existem implantações de Scrum, nas quais já participei, em que existia um grupo de Product Owners e um Chief Product Owner (recomendo a leitura do artigo de Roman Pichler que trata do papel de Chief Product Owner). O Chief Product Owner é um profissional responsável por treinar, colaborar e conduzir os Product Owners. Na minha experiência, o modelo funcionou bem, pois os CPOs eram focados na função e por existir essa comunidade, compartilhavam muitas experiências. Os Product Owners faziam a interface com a área de negócio e o dono real do produto era considerado o Business Owner (leia mais sobre o conceito de Business Owner no artigo de Dean Leffingwell).
Outra opção para garantir uma boa condução do produto é a alocação de um analista de negócio. Esta pessoa faz o detalhamento dos épicos, temas e histórias; fica ao lado do time e responde às dúvidas de negócio, viabilizando a geração de valor para o produto, entre outras funções. Mas novamente aqui podemos cair em uma armadilha: o analista não é um Product Owner de fato, e muitas vezes requisitaria certo tempo do verdadeiro Product Owner. Isso porque não teria a mesma autonomia para priorizar ou aceitar as histórias, por exemplo.

O Problema da indisponibilidade

A falta de tempo do PO tende a se tornar um círculo vicioso, que na maioria das vezes acaba sobrecarregando o ScrumMaster. Se o PO não cumpre com a sua função como deveria, o ScrumMaster é quem acaba assumindo grande parte da responsabilidade. Não é raro encontrar um ScrumMaster refinando uma história para o time ou até mesmo criando-a. 
Dito isso, algumas questões vêm à tona: será que foram dadas as condições necessárias para o PO realizar efetivamente o seu trabalho; ou seja, não deveria o PO ser um Business Owner, e permanecer em um papel com menos responsabilidades? Para isso acontecer, no entanto, precisaria ele contratar um PO e delegar essa função, ou deixar a resolução do impasse a cargo de quem implantou o Scrum? 

A Implantação do Scrum nas Empresas 

Toda a culpa parece ficar por conta do Scrum, o que não é verdade. Apesar de ser um framework baseado em princípios simples, o Scrum detém complexidade significativa e sua implantação em empresas exige cuidado e atenção a detalhes. Se a implantação não ocorrer de forma bem planejada, novos problemas surgirão e a impressão do Scrum ficará comprometida. 
Os papéis e as responsabilidades de cada um devem ficar muito claros, não pode haver sobreposição de tarefas (por exemplo, um PO deve se dedicar a essa função). Além disso, treinamentos são necessários para todos, inclusive para os profissionais nas demais funções, que, de uma forma ou de outra, serão afetados pela implantação. E, talvez o mais importante, é a transformação cultural da empresa, e o aprendizado e a adaptação dos profissionais que a compõem.

Conclusões

O papel de Product Owner no Scrum é complexo, envolvendo múltiplas tarefas e responsabilidades. É preciso ter foco no produto a ser entregue e tempo de dedicação. Portanto, a escolha do Product Owner é de vital importância para todos os envolvidos. É o Product Owner quem direciona o produto. Mas se não tem o tempo necessário, e não for possível fazer mudanças na empresa para que o tenha, será melhor considerá-lo como Business Owner e contratar um Product Owner que realize essa função.

quinta-feira, 21 de julho de 2011

Métodos ágeis - JIRA como uma ferramenta de gerenciamento de projetos.

Diferente do modelo tradicional para o controle de projetos, a metodologia ágil exige uma evolução tecnológica das aplicações e ferramentas para o gerenciamento de projetos. Um dos melhores exemplos com o qual atuo é o JIRA - Atlassian.

JIRA é altamente customizável, possuindo inúmeros recursos que ajudam em um projeto de gerenciamento de requisitos.

JIRA para Gerentes de Projeto
 Gerencie todos os seus projetos
 Gerencie muitos componentes em um único local
 Controle as atividades de sua equipe
 Monitore progressos em seus projetos
 Acesso on-line seguro




Gerenciar projetos e componentes
 Rastreie todos os seus projetos
 Gerencie sua lista de to-dos
 Número ilimitado de tarefas e sub-tarefas
 Descrições
 Arquivar anexos
 Mecanismo individual de workflow para: departamento, projeto e tipo de tarefa
 Customização de workflows




















Controle as atividades de sua equipe
 Relatórios de monitoramento de tempo
 Road maps
 Painéis com atualizações de status
 Exportação de relatório de dados para Microsoft Word e Excel
 Exportação de relatório de dados como XML e RSS


Monitorar o progresso de seus projetos
 Dashboard para atualizações de status rápido
 Gráficos e relatórios sobre o seu dashboard pessoal
 Relatórios enviados automaticamente
 Atualizações por e-mail

Acesso on-line seguro
 Regimes de segurança granular
 Gerenciamento de segurança em nível empresarial

Time Tracking
 Definir uma estimativa para cada tarefa
 Log de tempo gasto em cada tarefa
 Registro de acompanhamento de tempo para cada fase do projeto
 Acompanhar tarefas de risco em um projeto
 Definir feeds RSS em tarefas de risco














Controle de atividades do projeto














Agilizar tarefas de gerenciamento de projeto
 Mostra a estrutura de hierarquia de issues
 Fornece avançados planners para Gerentes de Projetos
 Gerencie issues de risco em um projeto
 Integre JIRA com MS Project


Link hierarquias entre issues


















Gerenciamento de risco/Gerenciamento de Projeto Ágil
 Definição de responsável por drag and drop
 Estimativa de Issue
 Planejamento da Iteração
 Gráfico Burndown
 Relatório sobre o estado da iteração























Vale ressaltar que cada gerente de projeto tem seu estilo e meio de gestão... as aplicações, ferramentas e controles são todos direcionados conforme seu maior conforto e meio de condução.

Em parceria com a ECORE, minha intenção desse post não é "vender" a aplicação, e sim disseminar o conhecimento sobre uma solução completa para a gestão de projetos, não nos limitando apenas ao velho e bom MS Project.



Fonte: http://blog.ecore.com.br

sexta-feira, 8 de julho de 2011

Como deve agir um analista de negócios?

Essa é uma questão muito subjetiva, e na maioria dos casos esse profissional é sempre colocado em xeque pela sua conduta, devido a ser uma posição de destaque na organização, a maturidade do indivíduo que exerce a função de analista de negócios deve ser bem dilatada e seu senso crítico altamente treinado para não cair nas valas de uma gestão que em quase sua totalidade possui gestores que ainda não sabe quem realmente são ou o que fazem esses elementos.


Grandes organizações confundem as profissões, em determinados casos nomeiam analistas de sistemas e consultores como analistas de negócios, estratégia essa adotada como manobra comercial, a fim de valorizar o profissional perante o seu cliente e diminuir seu custo referente ao valor da hora/homem na prestação de serviços.

Após vários anos de experiência e com mais de 11.000 horas de trabalho atuando como analista de negócios, entendi como realmente deve se comportar um profissional nessa posição.


Agir com toda a isenção que a função lhe permite, sua posição de destaque faz com que se torne um facilitador e em muitos casos influenciador na tomada de decisões estratégicas. Para tanto, sua linha de conduta e postura devem ser íntegras, seu nível de envolvimento com a área de negócios não pode ultrapassar a fronteira do “desejo e necessidade”, sua missão é exclusivamente alcançar o objetivo definido pela organização.


O ato de executar uma atividade com base no seu julgamento do certo ou errado, desejável ou indesejável... Faz parte do conflito diário que vive esse profissional, em sua essência a excelência é o seu maior princípio, mesmo que fatores externos e alheios a estratégia apareçam. Seu modo de agir e se comportar não podem ser corrompidos pelo “sistema”.


Claro que esse é o mundo ideal e não o que vivemos, e afirmo: estamos muito longe dessa condição. Porém, os analistas de negócios que tem essa maturidade e que mantém-se imunes aos problemas do dia a dia, devem ser prestigiados e respeitados, seus valores representam que seu modo de agir não está só alinhado a estratégia da organização, mas também a sua ética.


Quais são realmente as atribuições de um analista de negócios?


Manuais, livros, instituições e afins com a devida chancela, descrevem, orientam e certificam quais as atribuições de um analista de negócios, porém em muitos casos a prática não permite que os mesmos desempenhem seu papel conforme sua essência e em muitos outros casos nem sequer dispõe das ferramentas necessárias para execução de seus trabalhos.


Especificar, modelar, descrever, prototipar e analisar as demandas são as competências padrões do analista de negócios toda mecânica utilizada nessas ações são sua responsabilidade, ele não deve ser sênior em linguagens de programação, banco de dados e aplicações técnicas, é sim um especialista nato em gerir conflitos (pessoas), conduzir/coordenar projetos, agregar mais valor às entregas, gerar indicadores, e principalmente agir como um facilitador dentro da organização.


Enfim, a grande maioria dos gestores não desenvolve nas organizações o espaço necessário para aplicação das melhores práticas e técnicas da análise de negócio, e por isso sempre afirmo e concluo: “somente unidos seremos capazes de disseminar o conhecimento e criar a cultura do analista de negócios nas empresas”.