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.

Fonte: http://www.infoq.com/br/articles/product-owner-efetivo

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

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”.

Em síntese: O que é gerenciamento de projetos?

O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades a fim de atender aos seus requisitos. Planejamento, iniciação, execução e monitoramento, são os meios de controle que o gerente de projetos utiliza para garantir o sucesso na entrega das demandas e alcançar os objetivos esperados.

Gerenciar um projeto inclui:

• Identificação das necessidades;
• Estabeler objetivos claros e alcançáveis;
• Balancear as demandas conflitantes de qualidade, escopo, tempo e custo;
• Adaptação das especificações, dos planos, da abordagem às diferentes preocupações e expectativas das diversas partes interessadas.

É importante observar que muitos processos dentro do gerenciamento de projetos, são iterativos devido a existência e necessidade de uma elaboração progressiva durante todo o seu ciclo de vida do projeto. Isto é, conforme uma equipe aprende mais sobre um projeto, maior será seu nível de gerenciamento de detalhes e com isso, alcançar o objetivo se torna uma consequência natural.

Entendimento do ambiente do projeto

Praticamente todos os projetos são planejados e implementados em um contexto social, econômico, internacional, político, físico e ambiental, tendo impactos intencionais e não intencionais positivos e/ou negativos. Sendo assim, os envolvidos devem ter a capacidade de adaptação e versatilidade como premissas básicas nas suas ações.

Ambiente cultural e social: o time precisa entender como o projeto afeta as pessoas e como as pessoas afetam o projeto. Isso exige um entendimento de aspectos econômicos, demográficos, educacionais, éticos, étnicos, religiosos e de outras características das pessoas envolvidas. Cabe ao gestor examinar a cultura organizacional e ter a autoridade para gerenciar o projeto.

Ambiente internacional e político: talvez seja necessário que alguns membros da equipe estejam familiarizados com as leis e costumes internacionais, nacionais, regionais e locais aplicáveis, além do clima político que possa afetar o projeto. Outros fatores internacionais a serem considerados são as diferenças de fuso horário, feriados nacionais e regionais e a logística (viagens, teleconferência, etc.).

Ambiente físico: em caso de impacto no ambiente físico, alguns membros da equipe de projetos precisam conhecer bem a ecologia local e a geografia física, somente com a ciência desses aspectos, os envolvidos tem a dimensão e a realidade das causas e efeitos referente a entrega do projeto.

Por fim, o termo "gerenciamento de projetos" às vezes é usado para descrever uma abordagem organizacional ou gerencial na condução de atividades não somente ligadas a TI e sim a um contexto geral dentro de uma organização, em síntese: "é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo."

Guia do conjunto de conhecimentos em gerenciamento de projetos – (GUIA PMBOK) 3ª Edição

Escritório de gerenciamento de projetos

Da mesma forma que o conceito de projeto, o conceito de Escritório de Gerenciamento de Projetos admite muitas definições, mas sem muita variação conceitual. Pode-se definir o PMO como sendo a entidade organizacional formalmente estabelecida responsável por:

• Definir, uniformizar e defender padrões, processos, métricas e ferramentas;
• Oferecer serviços de gerenciamento, treinamento e documentação;
• Garantir o alinhamento das iniciativas à estratégia organizacional e confeccionar relatórios de progresso e acompanhamento.

Modelos, funções e composição interna:
Os PMO´s podem ser divididos em três tipos principais:

• Nível 1 – Escritório de Controle de Projetos
• Nível 2 – Escritório de Suporte aos Projetos
• Nível 3 – Escritório Estratégico de Projetos

Apesar da divisão de modelos, diferentes tipos de escritórios podem ser utilizados ao mesmo tempo em áreas distintas da organização ou mesmo dentro da mesma área. Esses modelos podem também se misturar, fazendo com que as fronteiras entre eles sejam muito tênues.

Nível 1 – Escritório de Controle de Projetos

Um PMO de nível 1 é responsável pela emissão de relatórios e pelo acompanhamento de indicadores previamente estabelecidos, sem influenciar a forma como os projetos são conduzidos. As funções de um PMO neste nível são:

• Emitir relatórios de progresso, custos, orçamento, performance e riscos.
• Manter uma base de dados de ações históricas.

Em síntese, um escritório desse nível trabalha controlando as atividades do dia-a-dia dos projetos, para ajudar os gestores a assegurar a realização das metas, resultados e orçamento planejados.

Nível 2 – Escritório de Suporte aos Projetos

Um PMO de nível 2 geralmente controla projetos grandes ou um número expressivo de projetos pequenos e médios. É responsável por:

• Todas as funções de um PMO de nível 1;
• Fornecer treinamento em gerenciamento de projetos;
• Estabelecer e verificar o cumprimento de padrões e métricas;
• Possibilitar o alinhamento dos projetos às estratégias organizacionais;
• Controlar e armazenar as lições aprendidas e os relatórios gerados;
• Definir, implementar e controlar mecanismos de controle de mudanças;
• Assumir o papel de mentor para projetos com problemas.

Assim, basicamente, um PMO de nível 2 difere de um de nível 1 principalmente pelo poder de influenciar no andamento dos projetos por meio de definição de metodologias, técnicas, métricas e ferramentas a serem utilizadas.

Nível 3 – Escritório Estratégico de Projetos

Um Escritório Estratégico de Projetos opera no nível corporativo, coordenando e definindo políticas para todos os projetos dentro da organização, gerenciando o portfólio corporativo e prestando auxílio aos escritórios de nível 1 e 2, se existirem. Neste nível, um PMO geralmente é considerado um centro de excelência em gerenciamento de projetos, guiando e ajudando o nível gerencial das organizações e demais membros dos times a alcançarem seus resultados de maneira mais eficiente.

. Neste nível de PMO, as funções principais são:

• Todas as funções do PMO de nível 2;
• Padronização do gerenciamento de projetos;
• Identificação, priorização e seleção de projetos;
• Gerenciamento corporativo de recursos;
• Implantação e manutenção de um sistema de informações;
• Alinhamento dos projetos à estratégia corporativa;
• Desenvolvimento profissional dos integrantes do PMO.

A principal diferença entre os níveis 2 e 3 dos Escritórios de Gerenciamento de Projetos é o caráter corporativo do segundo em relação ao caráter departamental do primeiro. Muitos escritórios são considerados modelos híbridos em relação aos níveis apresentados. O importante dessa divisão é observar que não se deve definir um PMO de nível 3 e ocupá-lo exclusivamente com tarefas operacionais de projetos, ou definir um PMO de nível 1 e ocupá-lo com tarefas estratégicas.

Uma das funções do PMO é ser o guardião da metodologia do gerenciamento de projetos da empresa e o responsável por sua contínua evolução. Para tanto, o escritório faz uso de um modelo de maturidade em gerenciamento de projetos.

Fonte: Promon Business & Technology Review