Muitos tiveram que lidar com uma situação em que o gerente exige uma equipe de unicórnios com uma pele de arco-íris, e o prazo foi ontem. Nessa equipe, o trabalho pode se transformar em um conflito eterno, todos estão tentando proteger seus interesses e todos esquecem completamente que se uniram inicialmente para criar um produto de qualidade e comunicar benefícios. Essa equipe dificilmente pode ser considerada eficaz.
Sobre o que é uma equipe de produtos eficaz, como montá-la e o que precisa ser feito para que todos os membros da equipe se envolvam ao máximo no processo, conversamos com especialistas em um painel de discussão que ocorreu em nosso escritório. Juntamente conosco, Roman Abramov (diretor de produtos da CarPrice e fundador da ProductStar) buscou respostas para as perguntas, Mikhail Alexandrovsky (fundador Dostavista), Anna Boyarkina (chefe do produto Miro), Ilya Krasinsky (CEO Rick.ai) e Michael Yan (CEO ManyChat) . Detalhes sob o corte.
Em 8 de agosto, ocorreu um painel de discussão no escritório da ManyChat, no qual discutiram o tópico de formar uma equipe de produto eficaz e relevante para muitas empresas. Os especialistas convidados foram
- Roman Abramov, diretor de produto da CarPrice e fundador da ProductStar
- Mikhail Alexandrovsky, fundador Dostavista
- Anna Boyarkina, chefe do produto Miro
- Ilya Krasinsky, CEO da Rick.ai
- Michael Yan, CEO da ManyChat.
A reunião foi moderada por Kira Matveeva, diretora de produtos do Grupo Lamoda. Durante a discussão, discutimos quais ferramentas e processos existem, como unir e dirigir uma equipe, ajudar os funcionários a crescer e desenvolver, manter a motivação, bombear habilidades e também responder a perguntas da platéia.
Para quem aprecia especialmente o efeito da presença pessoal,
sugerimos assistir à gravação da transmissão . Para todos os outros - uma transcrição detalhada da discussão. Boa leitura!
O que é uma equipe de produto, qual a diferença de uma equipe que não é de produto?
Roma:
Uma equipe de produto é uma equipe que vê um produto, provavelmente online. No meu entendimento, pode incluir desenvolvedores, testadores, profissionais de marketing, designers (especialmente). Estes não são apenas produtos. A tarefa dos produtos é liderar e organizar essa equipe. Para que eles se sintam bem juntos, e que tudo isso leve a um resultado.
Ilya:
Vamos adicionar holivar imediatamente para que não seja chato: quando todos concordam com todos. Eu sempre sou bombardeado quando a equipe de produto "vê o produto". A propósito, a equipe difere dos funcionários, pois os membros da equipe estão unidos por um objetivo. Adoro as equipes responsáveis pelo dinheiro, e acontece que 60% do tempo você não precisa cortar o produto. Pelo contrário, é necessário jogar fora o desnecessário.
Michael:
Vamos continuar a holivarit. Eu não concordo que a equipe seja sobre dinheiro. É sobre algumas métricas de produto. As equipes de produtos e não produtos são diferentes, pois as equipes que não são produtos têm objetivos em métricas que não são produtos. Nada mais.
Michael:
Vamos adicionar algo mais a isso. Geralmente todo mundo concorda com tudo, mas aqui eles começaram com uma disputa. Tivemos uma grande pergunta - se os produtos são responsáveis por dinheiro ou por outras métricas. Recentemente, li uma coisa boa no
Product Star : "O objetivo do gerente de produtos é aumentar a receita da empresa". Parece-me que isso combina diferentes pontos de vista, porque diferentes empresas em diferentes estágios podem ter objetivos completamente diferentes. E a equipe de produto vai para a missão da empresa através das tarefas e objetivos que agora estão enfrentando. No início, você pode ter a tarefa de alcançar lucratividade. Então, quando você obtém rentabilidade, continua a crescer e pode pensar em muitas outras coisas.
Anya:
Essa é uma pergunta muito complexa, controversa e estranha. Cada um de nós acrescentou nossos próprios significados. Se você pensar bem, o gerente de produto e a equipe de produto são uma equipe que tem um produto à sua disposição e, por meio dela, a equipe afeta as métricas, os negócios da empresa e o alcance das metas. Eu concordo, eles podem ser diferentes. Pode ser capitalização, pode ser dinheiro, pode ser alguns outros indicadores. No caso geral, essa não é apenas uma história sobre a equipe enxergando alguns recursos (embora isso seja interessante e interessante), mas sobre como a equipe resolve o problema de alcançar os objetivos da empresa.
Estrutura da equipe, funções e tipos de organização. Quem pode estar na equipe e quais são as áreas de responsabilidade?
Anya:
Acho interessante dizer ... Ao mesmo tempo, decidimos dividir a equipe em uma equipe de um produto básico (básico) e uma equipe de crescimento. Em algum lugar há 3 ou 4 anos, quando priorizamos as tarefas, sempre houve um conflito de interesses: o que investimos - no desenvolvimento da funcionalidade do produto ou em experimentos. Valorizando ou tentando escalá-lo? Uma das soluções legais que funciona nesta fase (não estou dizendo que sempre será assim): uma equipe separada foi alocada para o crescimento. Você precisa entender que temos todo o negócio dividido em duas partes condicionais: parte do lucro é gerada pelo autoatendimento, quando alguns caras compram um produto, e também há um negócio de contato humano com um departamento de vendas. É no autoatendimento que a equipe de crescimento trabalha e fornece o GoToMarket
(aproximadamente GoToMarket - entrada no mercado) para novos produtos. A equipe emprega 20 a 22 pessoas: gerentes de produto, designers, desenvolvedores. Existem 4 gerentes de produto.
Ilya:
Ou seja, essas são, de fato, quatro equipes que possuem determinadas métricas, que podem descobrir mais rapidamente e assim por diante. E as equipes de infraestrutura que os controlam para que não curem nada.
Anya:
O que significam as equipes de infraestrutura?
Ilya:
Eu amo esse esquema: você precisa fazer experiências rápidas. Esse é um tipo de equipe completamente diferente, os desenvolvedores aceitam as regras do jogo que “não estamos fazendo isso agora, certo, com padrões de design, banco de dados e ORM. Estamos fazendo um esboço; eles jogaram a frente, lançaram o mais rápido possível e assim por diante. ”
Nesse caso, surge o problema de muitas equipes começarem a criar muitos códigos de lixo, sua qualidade diminui, e são fortalecidas pelas equipes de infraestrutura que fazem análises de código, asseguram a qualidade do código e assim por diante. Os recursos estão focados em métricas de produtos e experimentos rápidos, equipes de infraestrutura - na qualidade do código, componentes complexos e longos, mecanismo, refatoração, etc.
Anya:
Sim, em termos gerais. Sempre deve haver algum tipo de base que permita fazer experiências rápidas.
Michael:
Também temos algo parecido. Há algum tempo, dividimos o desenvolvimento de produtos em equipes principais e de crescimento. Cada equipe tem esquadrões
(aprox. Esquadrão - comando) que lidam com algo separado. Como muitas empresas, começamos a compartilhar desenvolvimento e produtos. Mas quando o crescimento começou, começamos a fazer quadrados onde há desenvolvedores, produtos, analistas e outra pessoa, se necessário, por exemplo, DevOps. Inicialmente, os desenvolvedores obedeceram à estação de serviço e nada mais. Agora eles também o obedecem, ele os dispensa, os cria e isso é tudo. Mas, ao mesmo tempo, os desenvolvedores também são membros dos esquadrões. Isso funciona bem, o código é mantido em boas condições. Inicialmente, temos todos os desenvolvedores do Signora. Isso também é ruim quando não há movimento, quando alguém está ensinando, criando alguém.
Ilya:
Mas você tem algum tipo de assimetria, algumas equipes se concentram em experimentos rápidos, outras em verificação e refatoração de código: cobrança, por exemplo, é um tópico doloroso eterno que é serrado e refatorado por um longo tempo?
Michael:
Existe uma equipe de infraestrutura que não está na equipe de crescimento, que lida com as "partes íntimas do código".
Anya:
Nós também temos um!
Ilya:
Vou acrescentar. Há uma coisa que não vejo com tanta frequência. O que é funcionalidade cruzada? Quando não corremos para outro departamento, porque temos designers e desenvolvedores na mesma equipe. E gosto muito de adicionar gerentes de vendas à equipe de produtos para que eles fiquem lá parte do tempo. Existem clientes e os gerentes de vendas se comunicam com os clientes, entendem o que eles precisam. E há uma equipe de produtos envolvida no desenvolvimento de produtos. Eu gosto de preencher a lacuna entre os gerentes de vendas e a equipe de produtos. Quero que as vendas entrem em suporte e desenvolvimento e falem sobre o que está acontecendo, de alguma forma influenciado.
Michael:
Temos um ponto interessante. Originalmente, éramos uma equipe remota e tentamos obter o menor crescimento possível. Quando nos tornamos mais de 20 pessoas, nos reunimos no primeiro escritório de Moscou. Então, conseguimos um escritório em São Francisco, contratamos um cara legal da Atlassian que construiu grandes histórias. Ele também começou a contratar pessoas locais. E tivemos um problema que o marketing começou a se separar da equipe do produto.
Agora estamos começando a construir novas equipes. Começamos a enviar desenvolvedores para o escritório de São Francisco. Eles ajudam os profissionais de marketing com seus conhecimentos e habilidades.
E agora estamos formando duas equipes de crescimento que se fundirão em uma era
(aprox. Área de Produto, uma linha de produtos que combina várias equipes de produtos) e trabalharão em conjunto com o marketing. Eles terão suas próprias métricas e tarefas. Uma equipe estará em São Francisco, a outra em Moscou. E para atingir seus objetivos e seguir em frente, eles precisarão sincronizar constantemente. Não posso dizer que já funcione, mas me parece que vai ser legal.
Roma:
Do interessante, posso dizer três coisas. Primeiro, nossa tendência é "menos, mas melhor". Havia 100 das 600 pessoas em TI, agora existem menos de 50, mas estão melhor e mais. Três desenvolvedores fortes, mesmo sem um produto, farão mais de 10 maus com um produto. Como uma forja de pessoal, temos um ramo de Kirov.
A segunda tendência e realidade é que temos muito offline. Os negócios não são apenas vendas, mas também um grande varejo, franquias em todo o país, armazéns gigantescos, milhares de carros que revertem completamente o país inteiro em três dias. Por tudo isso, fazemos CRM, todas as ligações que as pessoas precisam. Isso geralmente é negligenciado por pessoas com experiência on-line, mas isso é importante e é uma ótima história.
A terceira tendência - transferimos toda a TI para o trabalho remoto. Os resultados dobraram, a rotatividade é zero. Anteriormente, um júnior chegou, nós o treinamos, ele o dominou e, assim que levantou a mão, foi arrastado - em Avito, Chipre. Agora todo mundo está feliz, está trabalhando em casa, a esposa está por perto, a produtividade é excelente, um bom motivador para o desenvolvedor, todo mundo é bom.
Trocamos gradualmente como um teste A / B. Temos o sistema de negócios da OKR, o usamos há dois anos, ajuda muito a sincronizar com os negócios. No começo houve um dia em casa, qualquer. Depois, houve dois dias em casa, depois três. Este trimestre foi inserido a semana toda em casa. Enquanto tudo está funcionando bem, as pessoas estão felizes, há resultados. Eu acredito que este é o futuro - por que sentar em um escritório abafado, pagar aluguel?
Há apenas um plug - esses são processos. O principal problema foi a discriminação contra funcionários remotos. “Por que vamos conectar um cara que está sentado fora de casa. Deixe ele sentar lá. Mas quando todo mundo entende isso amanhã e eu vou me sentar em casa, todo mundo se conecta a todos. Eu também trabalho remotamente.
Como garantir que todos os funcionários remotos estejam envolvidos o máximo possível?
Roma:
Tudo é decidido pela prática. Se você escreve para um funcionário, mas ele não está on-line, se Slack não tem o status de “foi almoçar”, então na próxima semana ele estará no escritório. Uma pessoa deve ser responsável; se trabalha remotamente, deve estar disponível constantemente.
O SkyEng fala muito sobre sua prática nesta área. Um dos principais fornecedores diz que você pode trabalhar em pé e usar uma tábua de passar como suporte. Comprei uma cadeira confortável, estou sentada à mesa da cozinha, conversando no Skype, está tudo bem.
Ilya:
O escritório deve estar lá para que você possa se reunir e discutir idéias. Mas o legal da coisa remota é que as pessoas estão sentadas e fazendo suas próprias coisas, ninguém as distrai mais uma vez. Legal quando o número de reuniões é mínimo. A coisa mais importante, na minha opinião, e o que ensinamos sobre a integração em equipe:
- Como a tarefa é colocada. Este é um problema eterno. Usamos a estrutura situação-problema-solução (consulte os 2 primeiros capítulos do livro da pirâmide de Minto) e definimos a tarefa a partir do resultado, ou seja, respondendo à pergunta sobre o que fazer e qual deve ser o resultado.
- Cultura das minas: primeiro, os membros da equipe escrevem o texto, depois chamam e discutem bloqueadores e perguntas brevemente ou planejam ações profundas.
- Cultura de entrega do resultado, incluindo intermediário.
Em geral, as equipes distribuídas são sobre adultos que sabem como gerenciar seu tempo e os ajudam a fazê-lo de forma eficaz.
O produto e o projeto são uma pessoa?
Anya:
O produto deve decidir se precisa ou não de um projeto. Se você precisa avançar as coisas, quem se importa?
Michael:
Tivemos uma graduação de produtos em que vimos um crescimento gradual. A propósito,
Roma falou sobre isso
antes do painel de discussão . Para nós, o produto de primeiro nível é quando você pode resolver um problema do backlog e resolvê-lo. Quando há uma especificação e descrição, você só precisa concluí-lo. O segundo nível é encontrar uma solução quando a "dor" do usuário é conhecida. Qualquer pessoa do nível 2 deve ser capaz e do nível 1. O terceiro nível, quando há uma métrica específica na entrada que você precisa influenciar, e já existem problemas e oportunidades para ela. O quarto nível está trabalhando com estratégia. No componente atual, o produto, localizado dentro da equipe multifuncional, desempenha as funções do próprio gerente de projeto ou (melhor) a própria equipe possui uma função distribuída do gerente de projeto. Quando uma equipe é pequena (por exemplo, 6 pessoas) e trabalhada em conjunto, e os sprints são curtos, um gerente de projeto não é necessário. Para unidades maiores, que consistem em várias equipes, existe um proprietário do produto que também pode trabalhar diretamente com os gerentes de produto nas equipes. Portanto, agora não temos gerentes de projeto no ManyChat.
Anya:
Muitas vezes, em diferentes entrevistas, eles me perguntam: "Você tem um produto envolvido em gerenciamento de projetos"? É ótimo quando há uma equipe que se move. Mas, ainda assim, essa é uma habilidade importante, e você deve entender como fazê-lo. Se você precisar obter um resultado, precisará resolver problemas. Portanto, acredito que essa habilidade deveria ser, porque sem ela é muito difícil avançar, especialmente em situações com um alto nível de incerteza. Pode ser possível desenvolver uma equipe que faça tudo sozinha, mas você precisa ser capaz de fazer isso.
Michael:
O produto deve ser responsável por garantir que o resultado seja alcançado. Mas como isso é feito não é importante. Se houver competência dentro da equipe - isso é legal. Caso contrário, ele precisa ser reabastecido.
Michael:
Historicamente, tínhamos um projeto e produtos diferentes, então o número de equipes aumentou e percebemos que não precisávamos de um gerente de projeto separado. Quando tudo é mais ou menos ajustado em equipes, isso não é necessário. Um projeto é necessário quando uma nova equipe é formada, precisa ser construída, os processos devem ser ajustados. Precisamos de uma pessoa que saiba como fazer isso. Mas se ele continuar sendo necessário, algo está errado na equipe. Cada equipe decide como funciona. Inicialmente, os projetos participaram de tudo isso. Com o tempo, vários projetos permaneceram, eles não são atribuídos a equipes específicas e fazem outras coisas.
Ilya:
Muito perto do padrão que "professamos". Graças a Maxim Dorofeev, uma frase como "um homem com as mãos na bunda" apareceu na indústria. Essa pessoa é muito fácil de identificar, geralmente trabalha nos fins de semana e, se sai de férias, tudo desmorona na equipe. Ele pinga o tempo todo para que eles venham às reuniões diárias. Existe uma classe de pessoas que travam tudo em si mesmas, e surgem problemas. Acontece um “passe de gerente” que transfere constantemente tarefas entre pessoas com perda de significado ao longo do caminho.
Nossos produtos podem atuar como projetos em equipe, eles podem promover tickets no sistema. Mas nós realmente amamos isso quando os desenvolvedores escrevem os próprios tickets. Nosso projeto considera métricas, visualiza problemas na equipe, monitora quantas tarefas estão em andamento, analisa a velocidade da passagem, estima onde as tarefas estão pendentes - sejam elas de revisão de código ou não. Ajuda a fazer diagnósticos. O projeto está fora da equipe, no sentido de não fechar o processo, mas ajuda, facilita e eles estão na fase de lançamento com a equipe.
O gerente de projeto é uma "palavra de capa" na qual você pode colocar qualquer coisa. Em geral, se um funcionário quiser, posso dar a ele a posição de rainha Victoria. Quem se importa com o que é chamado? Alguém gosta do termo "Scrum-master", alguém gosta mais do "facilitador de processos".
Michael:
Treinador ágil ...
Ilya:
Eu os amo à distância ... Eu os amo muito, mas à distância.
Novela:
Muitos caras vêm aos nossos cursos que trabalham no papel de um projeto. Eles vêm com considerações de que sabem melhor o que fazer do que os outros, querem aprender novas habilidades, por exemplo, para aprender a se comunicar com os usuários e assim por diante.
Mas tenho certeza de que a pessoa responsável pelo resultado não deve apenas fazer promessas sem olhar para a equipe, mas entender claramente que ela está "sob o capô". Ele pode desenhar castelos no ar, embora talvez outro ano precise refatorar. Só então ele pode garantir o resultado.
Como desenvolver em uma equipe de produtos?
Roma:
Quando fui para cá, tentei agregar em minha mente as perguntas que surgem nos planos de desenvolvimento. As perguntas mais comuns:
Primeira pergunta: onde encontrar o mentor? Você pode se tornar meu mentor?
A segunda pergunta: qual curso escolher, o que ler?
Terceira pergunta: como crescer se você já se tornou alguém?
O mais legal é quando seu mentor é seu líder. Eu próprio procurei garantir que meu líder fosse um mentor. O mentor de fora não conhece o contexto dos problemas que você está resolvendo e há muitos pontos negativos nisso. Mas em cada empresa existem níveis de informação, e o chefe pode saber ainda mais do que você. Ele pode aconselhar o que fazer sem entrar em detalhes.
Como bombear? A profissão do produto é muito diversificada e versátil. Porém, em diferentes locais de trabalho, são necessárias habilidades e habilidades diferentes, elas devem ser bombeadas de lados diferentes. Existem produtos B2B e B2C, e essas são histórias completamente diferentes. O que os caras estão falando sobre produtos de massa, no B2B, será 80% inútil. Você precisa estudar tudo e escolher onde está interessado em cavar.
Terceiro - o que aprender, para onde correr, se já sou legal. Vejo que nesta sala há muitos caras legais e experientes, e muitos deles pensam que já ouviram tudo isso, e não há nada de novo. Mas o mais importante é não pensar que você sabe tudo melhor que os outros. Quanto mais você expande o campo do conhecimento, mais ele tem contato com a realidade e mais você não sabe. Se parece que você sabe tudo, então está se degradando.
Precisa expandir a rede. , — , . : - , . , . , , — .
, . , , , , , , , -, . . , , , .
:
. , , . — . , , .
, , ( , ), , , -. , . , , . , , . : ( ), , , , , . - , - . , . , — , . — 90% .
— . , , . MVP, . «» ? custdev, . , , . — . , .
— 10 . , 30% . , . , , , . , , , . , .
, , 2 CEO, , , . , 0 1, , . .
, $15 000. - , 20-30 , , 50-60. « ». , 0 1 — . . , , .
:
, - -. Google: « 20% , ». , . « » , , .
, . , , , , — , «», . , , .
, , . , , . , : , . , . . , , — 10 , . , , . , . , , (: ). , , . , , — - , . , , « ». , , .
, . , OKRs. , , . , , , , . , - , .
:
— , , . , . -, - , . - , -… . . , . , , , . , . , . . . , . , — . -, . , , , .
:
, , . , - , . , .
. . , . , ( ).
:
: . — -. , . - , . - . , . , -, , . . -, , : « … … ». , . .
Obviamente, quando você se deparar com uma tarefa prática, escolherá a conferência e o livro certos. É melhor quando a necessidade de crescimento vem de uma tarefa específica.E em conclusão
Pedimos a especialistas para compartilhar links úteis e colocá-los em um só lugar. Todas as informações podem ser obtidas no nosso bot no Facebook ou no canal Telegram .