Meu nome é Maxim e, nos últimos oito anos, trabalho em grandes empresas como analista de negócios e product owner. Hoje gostaria de compartilhar com vocês minha opinião sobre o desenvolvimento de produtos, organizado com o uso de um grande número de equipes de desenvolvimento.
Aqueles que estiverem interessados e dispostos a falar sobre este assunto - sejam bem-vindos em cat.
Vamos começar com as grandes empresas. Por grandes empresas, quero dizer empresas com milhares de desenvolvedores, testadores, analistas, engenheiros de desenvolvimento, proprietários de produtos e outros gerentes de pessoal. São dezenas de divisões, centenas de equipes, hierarquias complexas, dependências infinitas e áreas de responsabilidade.
Entrar em tal empresa, no início é difícil de navegar. Mas o tempo passa e agora você pode imaginar a sua "ilha". Via de regra, são:
- Algum sistema ou componente compreensível que esteja envolvido em um processo de negócios muito grande e complexo;
- O product owner é uma pessoa que sem dúvida sabe onde desenvolver este sistema;
- Um conjunto de documentação em vários graus de relevância;
- Um conjunto de testes, automatizado e não muito.
Soa familiar?
É assim que se parece um típico e não o pior sistema de desenvolvimento de software. Normalmente, os departamentos de desenvolvimento de empresas com produtos de sucesso assumem essa forma em 10-15 anos. Produtos de sucesso rendem dinheiro, dinheiro é investido no desenvolvimento. O desenvolvimento está crescendo aos trancos e barrancos, é escalado linearmente e chega a uma situação em que os gerentes de projeto não conseguem mais manter todas as dependências em suas cabeças, muitas equipes começam a puxar o "cobertor" sobre si mesmas e, às vezes, prejudicar o produto ao invés de desenvolvê-lo. Em tal situação, é normal que uma equipe se esforce para o seu próprio sucesso, não mais se preocupando que seus colegas estejam passando por alguns problemas, e por causa disso sua característica comum não será entregue. É da natureza das coisas desenvolver a funcionalidade que inúmeras partes interessadas pedem mais alto, e não aquela de que os usuários precisam.O desenvolvimento "na mesa" não é incomum. O processo está em andamento - os requisitos vêm, são implementados, testados, entregues. É fácil esconder o principal atrás de uma tela cheia de agitação - o desenvolvimento de produtos não é tão eficaz quanto costumava ser.
Para entender essa perda de eficiência, vamos nos voltar para os clássicos do gerenciamento de produtos. Agora, existem escolas ou universidades online suficientes que podem lhe ensinar essa ciência por algum dinheiro.
Minha pequena lista se você não os conhecesse
Então, segundo os “clássicos”, produto é o que as pessoas compram. As tarefas de um gerente de produto são encontrar o público-alvo, determinar a mensagem de valor, selecionar canais de vendas adequados, reduzir a economia, encontrar pontos de crescimento, classificar todas as hipóteses adequadas. Se necessário, mude a ideia, público-alvo, canais, mensagem, modelo de negócio, mercado. Ou até mesmo matar o produto se ficar claro que ele não tem perspectivas previsíveis.
Não soa como a história acima, certo?
A questão é que, quando você é uma pequena startup, todos os processos de desenvolvimento de produtos são bastante transparentes e diretos. É muito fácil identificar o problema e corrigi-lo. É fácil entender a ideia do produto. É fácil entender e desenvolver a funcionalidade necessária. Usuários - aqui estão eles, à mão. Prod - aqui está, com todas as métricas.
Porém, com o passar do tempo, o produto ganha participação no mercado, se desenvolve em uma linha de produtos, cada vez mais desenvolvedores são contratados e, antes que você perceba, sua empresa se transforma em uma grande confusão de estruturas, interesses e responsabilidades.
- Usuários de produtos personalizados? Agora que seus product owners não se lembram deles, eles correm de um stakeholder para outro, tentando entender quais requisitos devem ser atendidos primeiro;
- A economia da unidade foi clara e transparente? Agora os donos do produto nem consideram o PnL (Lucro e Perda), carregando toda a equipe na pista de sprint com laterais com benefícios duvidosos;
- Havia uma história de trabalho, mapa de jornada do cliente e outras pessoas? Agora eles escrevem na loja “Como product owner, quero que isso seja feito porque o departamento de Operação e Manutenção precisa”;
- Houve um entendimento da responsabilidade pelo resultado e pelos termos? Agora que cada equipe é sua própria, seus recursos serão entregues à produção para um ou dois lançamentos mais tarde.
A complexidade de gerenciar o desenvolvimento de produtos em grande escala está crescendo exponencialmente. O que fazer?
A primeira coisa que vem à mente para a alta administração é que precisamos de uma estrutura mágica que fará com que todo esse sistema complexo funcione como um relógio suíço. Existe demanda - existe oferta. Eu conheço várias estruturas que, em teoria, podem lidar com a tarefa em mãos.
Eles são uma "bala de prata"?
Passei por várias transformações empresariais em que foram contratados golden coaches, introduzidos os mais modernos processos de gestão e comunicação. Milhares de pessoas mudaram de posição durante a noite e se mudaram para uma nova estrutura, uma nova equipe, novos processos, novos projetos.
E posso dizer o seguinte:
- é caro;
- não é rápido;
- é muito arriscado;
- o sucesso final depende muito da cultura da empresa. Se as pessoas entendem e acreditam, o sucesso é provável.
Esta abordagem é a única correta? Vamos ver o que mais você pode fazer.
Acredito que existam outras maneiras de dimensionar o desenvolvimento de produtos. Infelizmente, não tenho instruções passo a passo para você, mas aqui estão minhas idéias que podem ajudá-lo com isso:
Produto . O produto deve agregar valor. Considere o zoológico de seus sistemas e componentes em termos de valor. Destaque todos os fluxos de valor para clientes finais, contrapartes ou terceiros e divida o mapa do sistema por esses fluxos. Cada product owner deve ter uma cadeia completa de sistemas de valor sob controle. Dê a ele alguns analistas se o escopo da responsabilidade for muito grande.
Métricas... Para gerenciar, primeiro você precisa aprender a medir. Cada product owner deve identificar métricas para seu produto, com base nas quais ele conduzirá o desenvolvimento deste produto.
Usuários . Vamos deixar de lado as partes interessadas. Somente os usuários podem dar uma ideia real do valor de um produto. O product owner deve ser orientado pelos resultados das entrevistas e pela análise dos tickets de suporte em suas hipóteses.
Hipóteses . Não há mais implementações cegas da funcionalidade. Cada epopeia ou recurso deve ter expectativas para o impacto nas métricas. Ao implementar recursos e testá-los com testes A / B, os proprietários do produto devem entender se a hipótese foi bem-sucedida ou não.
Coordenação... Obviamente, o trabalho de vários produtos precisa ser coordenado de acordo com a estrutura que você escolher. No entanto, você não deve transformar essa coordenação em um conselho de responsabilidade coletiva de gerentes de produto.
Acredito que apenas mantendo as condições descritas acima você pode escalar com sucesso o gerenciamento de produtos e, em geral, não importa qual estrutura você escolher para esse escalonamento.