You are currently browsing the Guia do Gerente de Produtos 2.0 blog archives for October, 2007


Gerência de Produtos vs. Gerência de Projetos

Se você quer ser um mau Gerente de Produtos, misture gerenciamento de produto com gerenciamento de projetos. Os termos são parecidos, pois os conceitos também o são. Gerentes de Produto devem gerenciar projetos, já que precisam garantir que os projetos sejam feitos. Ambas são funções gerenciais (certo?) então os skills e a experiência necessários são praticamente os mesmos. Gerentes de Projeto apenas entram no caminho e tentam tirar o controle do projeto das mãos do Gerente de Produtos.

Se você quer ser um bom Gerente de Produtos, aprenda a diferença entre gerenciamento de produtos e gerenciamento de projetos. Embora os termos sejam similares, há grandes diferenças entre gerencia de projetos e gerencia de produtos. Confundir os dois conceitos é bastante comum, mesmo entre os mais experientes no desenvolvimento de produtos.

Gerentes de projeto são responsáveis pela entrega bem sucedida de um projeto – um empreendimento único com objetivo, escopo, prazo, orçamento e outras restrições. Um gerente de projeto trabalha para alinhar recursos, gerenciar problemas e riscos, e, basicamente, coordena todos os vários elementos necessários para completar o projeto. Quanto a seu relacionamento com produtos, projetos podem ser executados para construir um produto, incluir novas funcionalidades num produto, ou criar novas versões ou extensões de um produto. Quando o projeto é finalizado, o gerente de projetos usualmente muda para outro projeto, que pode ser ligado a outro produto.

Gerentes de Produto são responsáveis pela entrega geral e pelo sucesso contínuo de um produto. Uma vez que o projeto de construção do produto está completo e o gerente de projetos já está com outro projeto, o Gerente de Produtos fica para gerenciar o produto ao longo de todo seu ciclo de vida. Outros projetos relativos ao produto podem ser iniciados, com o Gerente de Produtos sendo a constante ao longo do caminho, definindo os objetivos do projeto e guiando o time para cumprir os objetivos de negócio que foram definidos.

Um desafio para os dois papéis é que eles podem parecer conflitantes. Um Gerente de Produtos pode querer incluir diversas funcionalidades para atender às necessidades dos clientes, mas o gerente de projetos pode querer manter o escopo o menor possível, para que o projeto possa ser entregue no prazo e dentro do orçamento. Definições tradicionais (e provavelmente estas acima também), geralmente descaracterizam o gerente de projetos como sendo unicamente focado em ter o projeto terminado a tempo e dentro do orçamento, sem qualquer preocupação com atender ou não as necessidades do mercado.

Bons Gerentes de Produto e bons gerentes de projetos são capazes de criar um equilíbrio a partir destes conflitos. Bons gerentes de projeto sabem que o verdadeiro sucesso de um projeto não é ele estar dentro do prazo e do orçamento, mas sim ele atender às metas e objetivos estabelecidos. Bons Gerentes de Produto sabem que todas as funcionalidades do mundo são irrelevantes se o projeto está constantemente atrasado e nunca chega ao mercado, ou se está muito acima do orçamento previsto para se concretizar.

Especialmente para produtos baseados em web e tecnologia, a confusão entre gerenciamento de projetos e de produtos é comum, e potencialmente prejudicial às organizações que não percebem as diferenças. Como Rob Grady escreve em Are you a Web Project Manager or Web Product Manager? (Part I):

Hoje, à medida que os sites se tornam crescentemente importantes para os negócios, eles são, ainda, infelizmente, gerenciados como projetos. Isto se torna problemático na tentativa de se atingir os objetivos do negócio, priorizações e em se ter os skills corretos para gerenciar o que agora é core nos negócios. Se o site se tornou ou é uma função core dos negócios, há uma necessidade ainda maior do que gerenciar um projeto; se tornou um produto que terá uma série de projetos dirigidos pelos objetivos do negócio.

Há alguns pontos importantes a se considerar no que diz respeito à gerencia de projetos e a gerencia de produtos:

  • Assim como todo produto precisa de um Gerente de Produtos, todo projeto precisa de um gerente de projetos.
  • Só porque os Gerentes de Produto acham que podem gerenciar seus próprios projetos não significa que eles devam fazê-lo.
  • Os skills, talentos, e conhecimentos necessários para o gerenciamento de projetos são bem diferentes dos necessários para o gerenciamento de produtos.
  • Assim como é difícil encontrar uma única pessoa que possa cobrir os papéis de gerente de projetos e de marketing de produtos, é difícil encontrar uma pessoa que possa ser bem sucedido em ambos, o gerenciamento de produtos e o gerenciamento de projetos.
  • Gerenciamento de projetos não é uma pedra no sapato do gerenciamento de produtos, e nem vice-versa.
  • Bons gerentes de projeto têm tanto valor quanto bons Gerentes de Produto.
  • Encontrar um bom gerente de projetos para gerenciar seus projetos irá lhe ajudar a ser um Gerente de Produtos ainda melhor.
  • Quanto menos tempo os Gerentes de Produto gastarem com gerenciamento de projetos, mais tempo poderão gastar no gerenciamento de produtos.
  • Para evitar conflitos entre o gerenciamento de produtos e o gerenciamento de projetos, Gerentes de Produto, gerentes de projeto e equipes de projeto devem todos concordar com as metas e objetivos compartilhados o tanto quanto for possível.

Esta é uma tradução livre do conteúdo escrito por Jeff Lash (http://www.jefflash.com/) no How To Be A Good Product Manager (http://www.goodproductmanager.com/)

Gerentes de Desenvolvimento Ágil devem virar seu pensamento de ponta cabeça!

Gerentes de Desenvolvimento em equipes que praticam o desenvolvimento ágil devem mudar seu pensamento totalmente.

Uma forma que gosto de usar para ilustrar a mudança de mentalidade necessária para um Gerente de Desenvolvimento Ágil (ou devo dizer, um líder), é pensar no organograma da organização de cabeça para baixo.

O gerente de desenvolvimento trabalha para a equipe, e não o oposto. Seu papel é prover o suporte necessário para o time trabalhar consistemente dando o seu melhor. Ele faz isso garantindo que o time tenha tudo de que possa precisar para entregar o software, e removendo quaisquer obstáculos que reduzam a velocidade do time de desenvolvimento.

É claro que também há aspectos de políticas e governança no papel do gerente em uma organização, o que não pode ser ignorado e nem descrito de forma apropriada sob esta ótica. No entanto, pensou que é uma maneira útil de pensar no papel dos gerentes no desenvolvimento ágil.

Um gerente de desenvolvimento deve balancear seu papel de dar suporte ao time perante as restrições da organização, e gerenciar as expectativas de cada um de acordo com isso. Geralmente isso não é fácil, ou seríamos todos gerentes :-)

Mas quando um Gerente de Desenvolvimento faz esta transição – transformou esta mudança de mentalidade num hábito, pensando naturalmente desta forma – então ele está na transição de ser um simples Gerente para ser um verdadeiro líder.

Escolha o nome certo pra seus projetos

Se você quer ser um mau Gerente de Produtos, use o nome interno de um projeto como o nome a ser utilizado para comunicação externa. O time já adotou este nome, e você o acha sensacional, então, porque não utilizá-lo com os clientes? O pessoal de vendas e marketing já está familiarizado com o nome. Além disso, foi um nome de projeto dado pelos executivos da empresa, e você não quer ofendê-los utilizando outro nome ao se comunicar com os clientes.

Se você quer ser um bom Gerente de Produtos, escolha os nomes internos e externos para os projetos com cuidado. Dar nomes a produtos é uma área importante, mas distinta do que vamos falar aqui. Em vez disso, pense em projetos específicos – novas versões de um produto, conjuntos de novas melhorias ou a implementação de novas funcionalidades mais elaboradas.

É importante ter um bom nome para um projeto para que possa ser usado internamente. Nomes internos de um projeto devem comunicar a visão e o propósito do projeto. Eles precisam identificar e dar o tom para o time de desenvolvimento de produtos. Chamar ao novo sistema de carrinho de compras de seu site de “versão 3″ é bom, mas tão genérico que chega a não significar nada. Chamá-lo de “Reformulação do eCommerce” tem a vantagem de aproveitar a oportunidade de focar o projeto e dar ao time um senso de direção.

Há uma razão pela qual os militares dão nomes a missões específicas. Concordando ou não com a estratégia e a tática, é difícil acreditar que a “Operação Tempestade no Deserto” deveria ter se chamado “A Iniciativa do Kuwait/Iraque de 1991” (embora neste caso o nome interno tenha sido usado também na comunicação externa). Bons nomes solidificam a missão de um projeto.

Independente de qual seja o nome interno de seu projeto, e o quão apropriado ele possa ser, ele não deve ser utilizado na comunicação com clientes, usuários ou outros stakeholders externos. Nomes internos servem para um propósito totalmente diferente e são utilizados por pessoas muito familiarizadas com o projeto. Nomes externos precisam comunicar a proposição de valor, benefícios e funcionalidades para uma série de tipos diferentes de clientes. Nomes que você ame como Gerente de Produtos podem não significar nada para um cliente e potencial.

Tenha cuidado ao utilizar nomes internos com pessoas que tem contato direto com clientes externos. Vendas, marketing, assessoria de imprensa e atendimento ao cliente estão na linha de fronte diariamente, interagindo com os que estão do lado de fora da empresa, e deve haver clareza e consistência em sua mensagem. Repita muitas vezes o nome interno para estes grupos, e eles podem se confundir ao falar com clientes e outros de fora da empresa.

Bons nomes de projeto são importantes para focar times de desenvolvimento de produtos, mas não para se comunicar com o mercado. Certifique-se de escolher o nome certo para o propósito certo e use apenas seu nome externo ao interagir com clientes ou equipes que se relacionam com os clientes, para evitar a possível confusão.

Esta é uma tradução do conteúdo escrito por Jeff Lash (http://www.jefflash.com/) no How To Be A Good Product Manager (http://www.goodproductmanager.com/)