Seis esquemas para ajudar a explicar os conceitos de gerenciamento de produtos



Algumas fotos úteis para entender e explicar as principais idéias no gerenciamento de produtos


Eles dizem que uma imagem vale mais que mil palavras, mas, para ser honesto, acho que isso é um eufemismo: a visualização ajuda a garantir um entendimento comum da idéia, simplifica a comunicação e elimina a maioria das nuances inerentes à linguagem escrita e falada.

Gostaria de mostrar seis esquemas que costumo usar para discutir idéias relacionadas ao gerenciamento de produtos. Eles são bem recebidos pelo público e transmitem perfeitamente a essência. Esses esquemas são:

  • "Gerente de produto como gargalo".
  • "Funil de entrega do produto".
  • "O clássico impasse Waterfall - Agile."
  • "Tamanho da iniciativa, risco e envolvimento da liderança."
  • "Bancas de conhecimento".
  • A importância da segmentação.

Você pode usá-los em seu trabalho da maneira que desejar.

Traduzido para Alconost

"Gerente de produto como gargalo"


Um dos erros mais comuns que noto com os gerentes de produto é o desejo de participar de todas as discussões. Sim, esta é a intenção correta: você precisa entender tudo para poder responder a qualquer pergunta sobre o produto.

Infelizmente, essa abordagem tem muitas desvantagens. Primeiro, isso é impraticável: você será rapidamente sobrecarregado com informações, o que afetará negativamente não apenas a eficácia da equipe, mas também o seu bem-estar. Acredite em mim - eu experimentei isso em mim mesmo. Em segundo lugar, você está destruindo a autonomia da equipe.

Um bom gerente de produtos sabe quando intervir e quando é melhor se afastar - eles conversarão e descobrirão por si mesmos. O objetivo de criar uma equipe autônoma é eliminar o maior número possível de dependências.

Considere o exemplo na figura abaixo. Imagine a situação à esquerda quando um desenvolvedor da Web pergunta qual algoritmo de rastreamento implementar e o gerente de produto se volta para analistas que dizem que você precisa seguir a implementação do iOS. Em seguida, o gerente vai ao desenvolvedor do iOS, recebe as informações necessárias e depois retorna ao desenvolvedor da web e explica tudo para ele. Essa abordagem não apenas adiciona trabalho extra ao gerente de produto, mas também atrasa a resolução do problema.

Compare isso com o exemplo à direita: o desenvolvedor da Web aborda diretamente o analista primeiro (quem explica o que é necessário) e depois o especialista em iOS (que fornece as informações necessárias). Observe como há menos interações nesse caso (setas vermelhas).



Se expandirmos nosso exemplo e adicionarmos mais algumas setas (verde e azul), isso estará muito mais próximo do número real de problemas resolvidos simultaneamente na equipe. O número de interações está crescendo rapidamente e todas elas estão vinculadas ao gerente.



Como aplicar o esquema. Se você estiver constantemente sobrecarregado de trabalho, pense se a interação na equipe está ajustada da melhor maneira: você realmente precisa estar em todas as reuniões? O trabalho normal continua enquanto você está de férias ou tudo para? Se o último for verdadeiro, você precisará conscientemente fazer esforços que simplifiquem a interação na sua ausência.

"Funil de entrega de produtos"


Este é um dos meus padrões favoritos: permite-me explicar o conceito de um funil de produtividade da equipe em relação ao tamanho dos projetos que estão sendo trabalhados. Frequentemente, tenho que enfrentar a decepção de parceiros de negócios e desenvolvedores quanto ao tempo que leva para o produto entrar no mercado: parece-lhes que o trabalho está indo muito devagar.



Normalmente, esse problema é causado pelo fato de o trabalho ser realizado apenas em grandes tarefas (funil à esquerda). Como resultado, uma equipe pode fazer apenas uma coisa de cada vez. Essa abordagem pode estar correta se tivermos certeza de que uma determinada função certamente estará em demanda - e isso é raro. Se algo sair da linha de montagem (no nosso caso, do funil) e for desnecessário, no final, você gasta mais esforço para entender isso do que o necessário.

A razão pela qual, em uma abordagem flexível do desenvolvimento, eles tendem a dividir o trabalho em fragmentos menores, é que permite obter rapidamente um resultado tangível e valioso para os negócios e com menos riscos. O funil à direita oferece muito mais espaço para manobras: tarefas menores (pontos azuis) podem passar pelo funil mais rapidamente - o que significa que serão testados mais rapidamente na prática. Se o resultado for bem-sucedido, você poderá investir mais esforço (círculo rosa). Se o resultado for insatisfatório, mudamos para outra coisa, mas limitamos os recursos alocados. Cada teste na prática permite aumentar os recursos investidos. Como resultado, temos muitos projetos pequenos, vários médios e muito poucos grandes. Assim, o risco é reduzido e o retorno do investimento é aumentado.

Como aplicar o esquema. Lembre-se do que você teve que trabalhar nos últimos meses (incluindo o que foi descartado). Todas as tarefas eram grandes em escala e complexidade, ou era uma combinação de várias tarefas atuais (tanto em um tópico quanto em diferente)? Atribua um tamanho a cada tarefa (por exemplo, nas escalas S, M, L) e imagine como será o funil.

“O clássico impasse Waterfall - Agile”


Existem muitos exemplos na Internet sobre esse tópico, mas eu gostaria de chamar a atenção para os esforços despendidos. Muitas empresas de alimentos não dizem diretamente que o tempo da equipe também é um investimento. Se os gerentes de produto tivessem os relatórios de ganhos e perdas de sua ideia, veriam que os salários são frequentemente o maior item de despesa. Portanto, você precisa procurar todas as oportunidades para aumentar os lucros (retorno do investimento).

Quando uma equipe trabalha em grandes fragmentos, esperamos obter um efeito imediato. Mas mesmo se assumirmos que lançamos imediatamente a solução perfeita sem problemas técnicos (vou lhe contar um segredo: isso é muito improvável), acontece que nossa equipe (se você olhar a linha do tempo) fez grandes investimentos que não funcionaram (gráfico à esquerda).

Ao liberar um produto com mais frequência, em partes menores, você está perdendo seu trabalho gradualmente - e isso começa a render imediatamente, porque você pode aprender com os erros mais rapidamente e entender o que é necessário e o que não é. No segundo gráfico, o valor de um produto para uma empresa é quase sempre superior ao custo do esforço despendido - é isso que você deve buscar.



Como aplicar o esquema. Costumo usar esses gráficos quando preciso explicar por que nem sempre é interessante adicionar outros recursos aos recursos do produto na iteração atual. Além disso, com a ajuda deles, é conveniente lembrar a você e à equipe sobre o lado comercial da questão.

“Tamanho da iniciativa, risco e envolvimento da liderança”


Este gráfico reflete dois aspectos. À esquerda está a pirâmide de iniciativas. Sua amplitude mostra quantas iniciativas podem ser trabalhadas simultaneamente: uma base ampla - muito, uma estreita - um pouco. Ao mesmo tempo, as tarefas com maior risco estão no topo (são poucas) e com um pequeno risco - na parte inferior (há mais).



À direita, há um indicador de envolvimento da gerência. Quanto mais amplo, maior o envolvimento da gerência no trabalho é necessário ou esperado - ou seja, com um número maior de gerentes de uma classificação mais alta, é necessário consultar. Quanto mais estreito o indicador, menor a necessidade de se referir aos "mais altos".

Você provavelmente tem muitas tarefas pequenas - como verificar textos escritos ou desenhos desenhados: eles têm um risco muito baixo, os resultados podem ser constantemente otimizados. Aqui a liderança não estará muito interessada em participar - e não faz sentido nisso. Mas as tarefas no topo da pirâmide terão um risco maior (por exemplo, pode ser o lançamento de um produto completamente novo) - é aqui que a participação e o apoio da liderança serão necessários.

Como aplicar o esquema. Na minha experiência, esse esquema é uma excelente ferramenta para os líderes e as próprias equipes: explica por que a liderança deve estar envolvida em alguns casos e por que isso não deve ser feito em outros.

O tópico da participação dos gerentes no trabalho é bastante complicado. Eu a revi com mais detalhes no artigo Por que o “Modelo Spotify” não resolve todos os problemas .

"Bancas do conhecimento"


Este gráfico é o resultado de uma verificação trimestral da situação na equipe em que meu colega trabalhava. Essa é uma ótima maneira de visualizar o impacto do isolamento de departamentos e equipes em relação ao compartilhamento de conhecimento. É impossível ter 100% de conhecimento em todas as áreas afetadas pelo produto, mas se você perceber a falta de conhecimento, isso ajudará a se concentrar na comunicação entre os departamentos.

Um funcionário individual é geralmente bem versado no que está trabalhando. Mas quanto mais longe você estiver dos outros, menos conscientes eles estarão do "seu" tópico.



Como aplicar o esquema. Lembre a si e aos outros que o trabalho na organização desacelerará necessariamente devido ao fato de que ninguém pode saber tudo e, mais importante, se houver um conflito, um dos motivos mais prováveis ​​será a falta de informações e a intenção não maliciosa ( consulte o artigo Incompreensão, intenção não maliciosa ).

A importância da segmentação


Um dos erros comuns que encontro quando uma empresa considera iniciativas e experimentos é a otimização por valores médios, e não por segmentos. Meu exemplo favorito é distorcido à percepção média: "Em média, uma pessoa tem menos de duas pernas".

Se hipóteses e áreas de cobertura se tornam muito extensas, elas naturalmente limitam o impacto potencial do teste. Na verdade, você está tentando satisfazer muitas pessoas ao mesmo tempo - e é improvável que isso funcione. No diagrama abaixo, o mais comum é o terceiro caso (à direita), no qual não há alterações significativas.

A seguir, são apresentados três experimentos hipotéticos. No primeiro, tivemos um aumento, no segundo - uma queda, no terceiro, não houve mudanças. No entanto, frequentemente, se você se aprofundar nos resultados, poderá encontrar novas oportunidades potenciais ou algum tipo de limitação. No primeiro caso, embora o experimento como um todo tenha sido bem-sucedido, no segmento B você pode ver uma diminuição no desempenho - aqui seria necessário entender qual foi o motivo da deterioração e, possivelmente, excluí-lo quando o produto foi lançado.

Vamos agora dar uma olhada no terceiro caso. Em geral, não houve mudanças significativas, no entanto, existem resultados positivos nos segmentos B e C - e são compensados ​​por uma queda nos segmentos A e D. Assim, também recebemos aqui uma direção que pode ser estudada mais adiante.



Como aplicar o esquema. Tente formular hipóteses mais específicas e estude os resultados para possibilidades e limitações adicionais. Sobre o assunto de hipóteses e experimentos, eu recomendo ler algo de Rick Hyam - confira seu Centro Experimental . Crie arquétipos através da pesquisa do usuário e dados demográficos ( Nikki Anderson ) - isso ajudará a entender melhor qual segmento de consumidores você está direcionando.

Conclusão


Isso é tudo. Espero que os diagramas e diagramas acima ajudem a visualizar alguns conceitos e explicá-los a outros!

Sobre o tradutor

O artigo foi traduzido por Alconost.

A Alconost localiza jogos , aplicativos e sites em 70 idiomas. Tradutores em idioma nativo, teste linguístico, plataforma em nuvem com API, localização contínua, gerentes de projeto 24/7, qualquer formato de recursos de string.

Também criamos vídeos de publicidade e treinamento - para sites que vendem, imagem, publicidade, treinamento, teasers, exploradores, trailers do Google Play e da App Store.

Leia mais

Source: https://habr.com/ru/post/pt485176/


All Articles