Meu nome é Dmitry Volkov. Durante o meu trabalho como gerente de produtos, acumulei muitas histórias sobre vitórias e falhas, como construir adequadamente a comunicação entre desenvolvimento e negócios e o que nunca deveria ser feito. Hoje vou contar duas dessas histórias.
Fiz algumas falsas antes mesmo de me mudar para o Yandex.Money. Hoje vou contar como, em uma empresa siberiana, perdemos um PM forte devido a mal-entendidos mútuos sobre o que as empresas realmente precisam. A segunda história será sobre a importância de explicar à equipe que o produto é necessário ao mercado e como a velocidade, a eficiência e o trabalho bem coordenado de todos os participantes do processo o acompanham. E um pouco mais sobre como essas coisas funcionam no Yandex.Money.
Nota do editor: este texto é o resultado de um relatório de Dmitry Volkov no comício de Piemnaya em 28 de fevereiro de 2019. A opinião editorial de algumas questões pode não coincidir com a opinião do autor.Há alguns anos, mudei minha pequena empresa para trabalhar em uma grande empresa siberiana, onde construí um serviço para transferências de dinheiro online. Naquele momento, trabalhei com cinco equipes, cada uma delas com seu próprio gerente de projeto, e isso me ajudou muito, porque era muito difícil para mim me comunicar com todos esses irmãos introvertidos. Uma das equipes foi reunida recentemente e foi nomeada para o cargo de PM com uma formação muito forte. Antes disso, ela trabalhou por vários anos como analista em um grande banco, e era difícil encontrar alguém mais adequado para um produto financeiro.
Devo dizer que este primeiro-ministro era de fato um diamante facetado - era firme em suas decisões e julgamentos e nos convinha um pouco mais do que completamente. Naquele momento, parecia-nos que vivíamos de acordo com o Agile; portanto, organizávamos constantemente planejamento, preparação, retrospectivas e, em quase todas as reuniões, o PM esmagava a autoridade, seu julgamento e tentava dominar a equipe e os produtos.
Ela questionou tudo - que esse recurso possa ser implementado na arquitetura de nosso produto, desafiou a avaliação da equipe e duvidou da adequação de outros produtos. Às vezes, esse desacordo atingia a sabotagem da empresa. Como isso se manifestou?
Uma vez que realizamos testes no corredor, conversamos com um grupo de foco e de repente percebemos que a capacidade de adicionar uma data de liberação do passaporte não é a coisa mais óbvia para os usuários. Pedimos à equipe que cortasse um pacote com o calendário padrão no Android e implementasse o recurso usando um tambor simples para selecionar números, datas e meses do ano.
Mas PM achou nossa ideia absurda. Ela não concordou que o absurdo que estamos oferecendo agora geralmente valha a pena. Naquele momento, percebi que não podemos interagir, não está claro o que estamos fazendo, por que e como os interesses dos clientes são levados em consideração.
No entanto, o problema foi descoberto rapidamente. A coisa toda estava na posição extremamente simples, fácil e descontraída da empresa: "Eu disse - é necessário, faça-o". E isso causou um conflito interno no projeto na decisão de criar algum tipo de recurso que oferecemos.
As empresas têm essa formulação historicamente. Entendo que, do ponto de vista do produto, isso não é verdade, mas o crescimento de uma grande empresa em 3.500 pessoas estava atrelado a planos, projetos trimestrais e indicadores financeiros. Portanto, tudo relacionado ao dinheiro causou uma reação: "Temos que fazer isso". E toda vez que nos faziam a pergunta: “Por que estamos implementando esse recurso?”, Meu colega e eu respondemos da mesma forma: “Só porque é necessário, porque por uma questão de dinheiro”. Todo o nosso negócio era pelo dinheiro. Enviar transferências de dinheiro - trata-se de dinheiro. Tudo dependia de dinheiro - nossos salários, bônus e pães em pontos de café.
Em algum momento, todos brigaram com todos. Testadores brigaram com desenvolvedores, testadores brigaram com administradores, administradores brigaram conosco porque algo não funcionou para nós, nós os encontramos, mas não funcionou novamente, e nos encontramos novamente. Uma confusão completa estava acontecendo. Não ficou claro o que fazer e, para resolver o conflito, tivemos que atrair uma equipe de RH e o diretor técnico da empresa. Depois de algum tempo, decidimos que a equipe deveria ser dissolvida.
Eu estava com vergonha, mas a decisão foi tomada - dissolvemos a equipe, distribuímos colegas para as demais equipes. O projeto foi oferecido para mudar para outro produto, que não estava relacionado a transferências de dinheiro, para não se cruzar mais com esses colegas, como eu. Infelizmente, ela levou essa situação muito perto de seu coração e saiu naquele dia.
Portanto, por causa das comunicações mal construídas e, em geral, por causa dos meus erros, perdemos um jogador muito forte em nossa equipe que poderia trazer grandes benefícios para a empresa, mas não poderia, porque foi expulso de nossas fileiras. Desde então, não esqueço que focar nos objetivos pode levar ao fakap mais selvagem e arruinar a equipe. E se essa situação se desenvolver novamente, estarei mais preparado para resolver esse conflito.
Sobre comunicações e relações
Outro caso sobre o qual quero falar também é sobre comunicação e relacionamentos, mas sobre relacionamentos mais elevados, mais provavelmente até sobre amor.
Assim que uma imagem clara é formada na minha cabeça do que está acontecendo na equipe, isso significa que estou perdendo de vista alguma coisa. E para não fazer mais fakaps semelhantes ao anterior, eu apenas tenho que me comunicar com toda a equipe, cada um individualmente, e transmitir a todos os valores de negócios que buscamos, transmiti-los com a mesma precisão que fazemos para nossos clientes .
Tínhamos dez equipes de diferentes cidades e tentei participar de quase todas as atividades associadas a elas. Participei de todas as reuniões e stand-ups e falei sobre como a implementação de um determinado recurso afetou a lucratividade da empresa. Falei às pessoas sobre números, gráficos, mudanças em termos de crescimento ou diminuição no número de usuários, mostrando os resultados de relatórios analíticos. Também falei sobre o fakap - como a introdução de novas funções não trouxe o resultado esperado. Era importante reconhecer abertamente os erros dos negócios ao estabelecer prioridades, o que também era importante para a equipe começar a confiar em mim e no segundo gerente que estava envolvido neste produto.
Cada equipe esteve envolvida no processo de discutir as características do produto com base no impacto, valor e importância para o cliente e a empresa. Ao mesmo tempo, revisamos quase completamente o processo de definição do problema na lista de pendências, e agora cada recurso foi registrado na lista de pendências com base em quatro perguntas: por que, para quem, como e o que . Os impactos usuais descritos no livro de Goiko Adzic .
Isso tornou possível envolver os participantes em todos os processos em andamento, e todas as equipes começaram a ficar mais atentas ao que viam e aos nossos requisitos.
Mas não apenas nós estávamos mudando. Tornou-se completamente errado as equipes permanecerem em silêncio ou virem até nós e dizerem que nossas idéias ou nós mesmos somos péssimos, por isso não faremos isso. Havia uma necessidade de explicar por que não devemos fazer alguma característica ou por que queremos fazer outra coisa. Além disso, as equipes foram convidadas não apenas a escrever código, mas também a começar a usar esse produto por conta própria.
Portanto, realizamos um experimento - cada desenvolvedor teve que deixar um escritório acolhedor, ir ao banco, atravessar todos os círculos do inferno e da tristeza, eventualmente fazer uma transferência de dinheiro, mas entender como os usuários se sentem em cada estágio.
Devo dizer que trabalhamos com um público complexo. Depois, eram migrantes trabalhadores, imigrantes da Ásia Central, que deixaram sua marca nos cenários de usuários. A participação direta da equipe nos processos pelos quais o usuário passa ajudou a entender que não somos suficientes para exibir as personalidades do usuário e criar um mapa da jornada do cliente, e fizemos tudo isso.
E então eles ficaram surpresos quando as equipes começaram a vir com muitas novas idéias e sugestões. Eles queriam falar sobre como estavam desconfortáveis em algum momento ou, inversamente, quão bem foram feitas as notificações de que a transferência de dinheiro foi recebida com sucesso e assim por diante. Eles carregavam muitas idéias para nós e cada vez melhoravam nosso produto.
Portanto, se você entender que o gerente de produto com quem trabalha diariamente é do povo silencioso, daqueles que não gostam de falar sobre os negócios que você faz com ele, pegue a mão dele e leve-o para uma sala escura. Diga a ele como uma equipe como a disseminação de informações ajudará cada um de vocês a se envolver totalmente no processo de desenvolvimento.
Diga a ele que é necessário enxergar não apenas os recursos que ele deseja, que é necessário refinar e codificar legados, para corrigir fragmentos antigos de muletas, porque às vezes a correção de tais tarefas abre seus fluxos completamente para nós. Converse abertamente com ele e a equipe sobre o que está acontecendo com seu produto. Peça a ele para comparecer a todos os grupos da sua equipe e sempre contar o que você conseguiu alcançar no dia anterior. Deixe-o mostrar os números dos relatórios analíticos, os resultados dos grupos focais e assim por diante.
Isso definitivamente o ajudará a ver o problema de maneira mais ampla, porque seus colegas provavelmente estão prontos para compartilhar suas opiniões com ele, mas agora não confiam nele.
Em geral, os desenvolvedores realmente não gostam de dizer nada sobre si ou sobre um produto, exceto por várias palavras estranhas que eu ainda não entendo muito bem e que não aprendi todo esse tempo, sobre o código e muito mais. Cada desenvolvedor quer criar um produto de qualidade e compartilhar sua opinião, mas muitos têm medo de que não sejam ouvidos. Se você e seu produto estão abertos à equipe (você está com o produto), as pessoas lhe dirão tudo de boa fé, e isso também afetará o desenvolvimento do seu projeto.
As equipes do Yandex.Money também funcionam assim. Uma conexão estreita do projeto com o produto nos permite desenvolver muito mais rápido do que antes - limpamos regularmente o backlog, removendo tarefas obsoletas que possamos ter, sendo rudes, às vezes avaliando nossas tarefas em camisetas e histórias, a fim de facilitar o tempo e acelerar os processos, planejamento. Nós nos comunicamos com nossa equipe e falamos sobre como o usuário se comporta em cada estágio do CJM, o que acontece nos relatórios com números e métricas.
Concluindo, posso dizer que, se o seu produto não compartilhar o que está acontecendo no mercado ou no seu produto, é hora de pedir que ele faça isso. Assim que você diz à equipe o que exatamente está fazendo e por quê, o envolvimento de todos os participantes aumenta muito. Comprovado na prática.
Surpresa para quem leu - neste post, há um código promocional para um bônus interessante do Yandex.Money. Ele receberá aquele que encontrar e ativar pela primeira vez .
UPD 10:20 O primeiro código promocional ocorreu nas entrelinhas antes do kata. Foi ativado em 17 minutos.
E se você não tiver tempo, não desanime - também haverá códigos promocionais nos próximos posts. Assine o nosso blog para ficar à frente de todos na próxima vez.
Texto preparado por:
O autor é Dmitry Volkov.
Editores - Eugene Shklyar, Denis Vonsarovsky.