Medindo e gerenciando a qualidade

Em 2015, decidimos extinguir a função de Quality Assurance (QA) de nossa equipe de desenvolvimento de produtos da Locaweb. Tínhamos 12 QAs, alguns com perfil de desenvolvedor e outros com perfil SysAdmin. Ao propor a extinção da função de QA, alguns dos QAs se tornaram devs, enquanto outros assumiram a função de administradores de sistemas. Os motivos que nos levaram a extinguir a função de QA da Locaweb são:

  • Quando existe uma função de QA separada da função de desenvolvimento de software, é comum ouvir frases como “a funcionalidade está pronta, agora está em fase de QA”, o que denota uma cultura de desenvolvimento de produto em cascata. Essa cultura pode aumentar consideravelmente o tempo de desenvolvimento e afetar negativamente a qualidade do software.
  • Quando há uma função de QA separada da função de desenvolvimento de software, também é comum ouvir frases como “por que o QA não detectou esse bug?”, o que denota uma cultura de encontrar os culpados. Essa cultura pode ser muito prejudicial ao engajamento e motivação da equipe e, consequentemente, impactar negativamente a qualidade do software.
  • A qualidade não deve ser preocupação de uma pessoa ou equipe, deve ser preocupação de todos os que estão trabalhando na criação do software.
  • A qualidade é um requisito não funcional, ou seja, que especifica um critério para avaliar o funcionamento de um produto digital, enquanto requisito funcional especifica um comportamento do software. Desempenho, escalabilidade, operabilidade, monitorabilidade são alguns exemplos de requisitos de software não funcionais que são tão importantes quanto a qualidade. Mesmo assim, não há funções definidas para garantia de desempenho, garantia de escalabilidade, garantia de operabilidade e garantia de monitorabilidade. Por que a qualidade é o único requisito não funcional que tem uma função específica dedicada para garanti-la?
  • O controle de qualidade se concentra em garantir a qualidade do processo de desenvolvimento de software. Se uma função separada é necessária para garantir essa qualidade, por que não há necessidade de uma função separada para garantir a qualidade do processo de gestão de produto, o processo de design, o processo de marketing de produto, o processo de vendas, o processo financeiro de uma empresa?
  • Havia uma preocupação de que, se o próprio engenheiro agora tivesse que testar, as entregas demorariam mais para ficar prontas. Essa preocupação existia porque os engenheiros consideravam que seu trabalho estava concluído – e a entrega estava pronta – quando passavam a história para o QA testar. No entanto, o conceito de pronto do engenheiro está incorreto, pois ele acabou de passar a história para a próxima fase, o teste. Do ponto de vista do usuário, a história só está pronta quando o usuário pode usar o novo recurso. Portanto, o tempo que a entrega permanece no controle de qualidade ainda é o tempo de desenvolvimento, mesmo não estando mais nas mãos do engenheiro. E esse tempo fica ainda maior quando a história passa pelo controle de qualidade, mas é rejeitada e precisa voltar para a engenharia.

Quando entrei na Conta Azul, eles também haviam acabado de extinguir a função de QA, e os ex-QAs passaram a ser analistas de negócios, principalmente ajudando gerentes de produto.

Eu vi outras empresas também discutindo a necessidade de QAs e, em alguns casos, um debate acalorado emerge em torno deste tópico. No entanto, ter ou não ter QAs não deve ser o centro da discussão. Ter ou não ter essa função é a solução de um problema, normalmente referido como “como podemos melhorar a qualidade do nosso produto?”, e esse problema deve ser o centro da discussão.

Como podemos melhorar a qualidade do nosso produto?

Uma simples pesquisa no Google sobre qualidade de software produzirá toneladas de definições normalmente relacionadas ao atendimento de requisitos funcionais e não funcionais. Quando o software não atende a um requisito funcional ou não funcional, ele apresenta um defeito, um bug. Portanto, para melhorar a qualidade de um produto de software, precisamos trabalhar em duas coisas:

  • reduzindo seus bugs existentes;
  • não gerando novos bugs.

Uma boa maneira de controlar isso é ter uma medição semanal de seu inventário de bugs e novos bugs por semana e discutir isso todas as semanas com a equipe. Fizemos isso no Gympass. Definimos no início de cada trimestre qual é a meta para o inventário de bugs e a média de novos bugs por semana.

Quantidade total de bugs no Gympass

A imagem mostra a evolução do nosso estoque de bugs para o 2º trimestre de 2019. Iniciamos o trimestre com 215 bugs em nosso estoque e almejamos uma meta de menos de 166 ao final do trimestre, uma redução de quase 23%. Fechamos o trimestre com um estoque de 136 bugs, uma redução de 36%. Fizemos isso nos concentrando não apenas na resolução de bugs em nosso inventário, mas também no controle do número de novos bugs por semana.

Quantidade de novos bugs detectados por semana no Gympass

No primeiro trimestre de 2019, tivemos uma média de 26,2 bugs criados por semana. Durante o segundo trimestre, reduzimos essa média para 17,4 novos bugs por semana, para um total de 226 novos bugs durante o trimestre. Isso é uma redução de 33% no número de novos bugs por semana.

Isso parece uma melhoria muito boa, certo? Mas há muito espaço para melhorias aí. Deixe-me explicar a matemática do gerenciamento de bugs:

Se fomos capazes de reduzir nosso estoque de bugs de 215 para 136, isso significa que resolvemos pelo menos 79 bugs. No entanto, criamos 226 novos bugs (17,4 novos bugs por semana x 13 semanas) durante o trimestre. Resolvemos 79 + 226 = 305 bugs durante o trimestre, é muito trabalho de correção de bugs. Se tivéssemos gerado 90 novos bugs durante o trimestre, uma média de 6,9 novos bugs por semana, em vez dos 226 novos bugs, poderíamos ter zerado o inventário de bugs.

Um aspecto adicional da resolução do bug a ser medido é o SLA (Service Level Agreement) de resolução, ou seja, quantos dias a equipe levou para resolver um bug a partir do dia em que o bug foi identificado pela primeira vez. Para isso, classificamos os bugs pela sua gravidade, que é o impacto que causa aos usuários e ao negócio. Os bugs de maior gravidade são aqueles que precisamos resolver no mesmo dia; erros de alta gravidade, em 7 dias e média de gravidade, em 14 dias. O gráfico a seguir mostra como estávamos no Gympass no quarto trimestre de 2019.

SLA de resolução de bugs no Gympass

Essa não é a visualização ideal porque mostra apenas uma imagem do momento, e não uma evolução. Para entender a evolução de qualquer métrica, você precisa ver como ela se saiu em diferentes pontos no tempo.

Assim que me juntei à Lopes, comecei a trazer esse tema para a discussão com os times. Uma das coisas que notamos é que 50% dos itens “deploiados” era correção de bugs. Fui informado de que “esses bugs eram pegos antes de ir para produção, o que é algo bom”. De fato, ainda bem que esses bugs não chegaram ao ambiente de produção e apareceram para nossos usuários. Contudo, eles chegaram à pré-produção e precisavam ser corrigidos. Não seria melhor se esses erros nem sequer existissem, nem mesmo em pré-produção?

Os OKRs que definimos para nos ajudar com o tema qualidade foram 3 KRs adicionais no objetivo de Aumentar a cadência de deploys em produção que comentei no capítulo anterior:

  • KR: Reduzir o número de novos bugs para 5% em pré-produção.
  • KR: Reduzir o número de bugs totais para 10% em pré-produção.
  • KR: Manter o número de bugs totais abaixo de 5% em produção.

E adicionamos o seguinte OKR:

  • Objetivo: Melhorar a qualidade das entregas das squads.
  • KR: Revisar 100% das novas histórias para encontrar requisitos mal definidos e/ou ambíguos.
  • KR: Efetuar revisão de 25% dos Pull Requests dos squads.
  • KR: Mensurar volume de Pull Requests dos squads.

Outro exemplo de controle de bugs

Na Conta Azul dobramos o time de desenvolvimento de produtos em um período de 8 meses entre novembro de 2017 e julho de 2018. Esse crescimento tinha por objetivo aumentar a capacidade produtiva do time.

Quantidade de entregas e de pessoas por semana da Conta Azul

Além disso dividimos a quantidade de entregas pelo total de pessoas no time para avaliar se estávamos conseguindo aumentar nossa produtividade individualmente.

Quantidade de entregas por pessoa na Conta Azul

Contudo, com o aumento de pessoas no time, acabou aumentando a quantidade de bugs. Tanto que o time que já vinha tendo 40% de suas entregas como correção de bugs acabou tendo que aumentar essa proporção para 60%. Ou seja, apesar de ter aumentado a produtividade individual e total, esse aumento de produtividade não estava sendo sentido pelo usuário, pois acabava sendo usado para refação.

Percentual de correção bug na Conta Azul

Para controlarmos esse problema, aumentamos nosso foco em corrigir esses bugs dentro dos SLAs, que eram:

  • 85% dos chamados resolvidos em até 7 dias
  • 98% dos chamados resolvidos em até 30 dias
SLA de resolução de bugs em 7 dias da Conta Azul
SLA de resolução de bugs em 30 dias da Conta Azul

Veja que a qualidade piorou e o cliente sofreu com isso. Mas, depois de algum tempo, conseguimos retornar aos níveis de SLA definidos. Olhávamos essa métrica semanalmente e, sempre quando discutíamos sobre essa métrica, concordávamos que a melhor maneira de cumprir o SLA era não criar bugs!

Qualidade não é só controle de bugs

Além do controle de bugs, há vários outros aspectos que impactam na qualidade do produto digital que entregamos para os usuários. Desempenho, escalabilidade, operabilidade, monitorabilidade são alguns exemplos de requisitos não funcionais.

Quando me juntei ao Gympass, na minha segunda segunda-feira o sistema ficou fora para os usuários por volta das 19:00. Comecei a perguntar para as pessoas do time o que estava acontecendo e a resposta foi que as segundas-feiras são dias de pico de visita às academias e que às vazes o sistema não dava conta do volume. Como não havia monitoração, não éramos alertados de que o volume estava maior que o usual e não conseguíamos nos preparar adequadamente. Dois meses depois, quando o Rodrigo Rodrigues se juntou ao Gympass como CTO, ele apelidou o evento de “Back Mondays”. Para endereçar o problema passamos a monitorar e implementar uma infraestrutura que desse conta dos picos das segundas-feiras. E definimos OKRs para uptime, requests de HTTP bem-sucedidos e tempo de reposta do backend.

Uptime – Gympass
Requests de HTTP bem sucedidos – Gympass
Tempos de resposta do backend – Gympass

Por que a qualidade é tão importante?

Qualquer usuário prefere utilizar um produto de boa qualidade que se comporte conforme o esperado. Isso é condição sine qua non para fornecer uma boa experiência do usuário.

Além da experiência do usuário, há outro aspecto importante a considerar quando falamos sobre qualidade e bugs. Sempre que alguém precisa trabalhar na resolução de um bug que foi encontrado em um produto digital, essa pessoa precisa parar de trabalhar no que quer que esteja trabalhando no momento para poder resolver o bug. Esta é uma interrupção no fluxo de trabalho. Se essa pessoa fosse capaz de entregar o software sem aquele bug, ela poderia continuar a trabalhar em coisas novas sem interrupções, o que a tornaria mais produtiva.

A relação entre produtividade e qualidade

Tive a oportunidade de participar de um curso do MIT sobre como criar organizações de alta velocidade. O curso foi ministrado pelo Professor Steven J. Spear, autor do livro The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition. Esse é um daqueles cursos muito densos, cheios de conteúdo, mas que pode ser resumido em um parágrafo:

Organizações de alta velocidade são capazes de aprender muito rápido, especialmente com suas falhas, e de absorver esse aprendizado como parte integrante do conhecimento da organização.

Uma organização de alta velocidade trabalha seguindo os 4 passos adiante:

  • Estar preparado para capturar conhecimento e encontrar problemas em sua operação.
  • Entender e resolver esses problemas para construir novos conhecimentos.
  • Compartilhar o novo conhecimento com toda a organização.
  • Liderar para desenvolver habilidades 1, 2 e 3.

O exemplo clássico é a Toyota, com a manufatura enxuta e o conceito de parar a produção sempre que houver falhas, corrigindo-as e usando-as como oportunidade de aprendizado para que não aconteçam mais. Essa capacidade de aprender com as falhas é o que dá à Toyota a capacidade de permanecer à frente de seus concorrentes por tanto tempo.

Outro bom exemplo é a Alcoa, que tinha uma taxa de incidentes de trabalho de 2% ao ano, considerada normal. A Alcoa tem mais de 40.000 funcionários, portanto, 2% dos incidentes de trabalho por ano significa que 800 funcionários por ano têm algum tipo de incidente de trabalho. Esse é um número bastante impressionante e preocupante.

Para combater esse problema, eles implementaram uma política de tolerância zero a erros. Antes de implementar esta política, os erros eram vistos como parte do trabalho. Agora, os funcionários são incentivados a relatar erros de operação em 24 horas, propor soluções em 48 horas e contar a solução encontrada para seus colegas para garantir que o conhecimento se espalhe por toda a organização.

Isso fez com que o risco de incidentes caísse de 2% para 0,07% ao ano! Essa redução na taxa de incidentes significava que menos de 30 funcionários por ano tinham algum problema de incidente de trabalho depois que a política de tolerância a erro zero foi implementada e a Alcoa obteve um aumento de produtividade e qualidade semelhante ao da Toyota.

Falhar rápido vs. aprender rápido

Um fator importante nos exemplos da Toyota e da Alcoa é que reconhecer e aprender com as falhas deve fazer parte da cultura da empresa. Isso é algo um pouco mais comum na cultura das empresas de tecnologia, mas não tão comum em empresas tradicionais. Durante o curso do MIT dividi mesa com um executivo brasileiro, do Grupo Globo, um executivo espanhol, da AMC Networks International (Walking Dead, Breaking Bad e Mad Men), um gerente de projetos alemão residente no Azerbaijão que trabalha para a Swire Pacific Offshore (indústria de petróleo e gás) e uma estudante de pós-doutorado do MIT em energia solar vinda da Arábia Saudita.

Todos os meus companheiros de mesa eram de indústrias mais tradicionais. Eu era o único de uma empresa de internet. Os executivos da Globo e da AMC estavam lá porque viram a Netflix com seu streaming de vídeo sob demanda e o YouTube com seu enorme catálogo de vídeos gerados por usuários como grandes ameaças, roubando seu público muito rapidamente e eles queriam entender como poderiam se defender.

Embora o tema seja um tanto óbvio para as empresas de internet, especialmente com a cultura de startups de tecnologia que valorizam o fail fast (falhar rápido). É isso que torna a Netflix e o YouTube uma ameaça às empresas de mídia tradicionais, como o Grupo Globo e AMC Networks. No entanto, mesmo isso sendo parte da cultura das empresas de internet, sentar e discutir isso com pessoas de empresas mais tradicionais foi uma grande oportunidade de reflexão sobre a relação entre a falha, o reconhecimento da falha, o aprendizado e a alta velocidade:

  • Reconhecer as falhas e usar as falhas como uma oportunidade de aprendizagem deve estar bem enraizado na cultura da organização. Se as pessoas não tomarem cuidado, à medida que uma empresa cresce, ela pode perder a capacidade de aceitar as falhas como oportunidades de aprendizado. É muito comum que as empresas, à medida que cresçam, sejam cada vez mais avessas a falhas e criem uma cultura que, em última análise, incentive as pessoas a esconderem erros e falhas.
  • Outro aspecto importante do aprendizado com as falhas é tornar esse processo um padrão da empresa. Não adianta falhar, reconhecer o erro, afirmar que você não vai mais cometer aquela falha e, algum tempo depois, cometê-la novamente. Esse processo de aprendizado com as falhas deve fazer parte da cultura da empresa. Sempre que uma falha é identificada, o aprendizado deve acontecer o mais rápido possível para evitar que ela aconteça novamente. Se a mesma falha acontecer novamente, algo está quebrado no processo de aprendizagem com a falha.
  • Mesmo em empresas de internet, percebo que aprender com as falhas é mais comum na equipe de desenvolvimento de produtos, uma vez que retrospectivas e aprendizado contínuo fazem parte da cultura de desenvolvimento ágil de software. Em outras áreas da empresa, aprender com as falhas é menos comum. Essa capacidade de sistematizar o aprendizado com o fracasso deve permear toda a empresa.

Mesmo que ouçamos muito sobre a cultura das empresas de internet de falhar rápido, falar sobre falhar rápido diverge nosso foco do que é realmente importante, aprender rápido. Devemos colocar nossa energia no aprendizado, não no fracasso. É o processo de aprendizagem que faz evoluir pessoas e empresas. E é a capacidade de uma organização aprender rápido, principalmente com seus fracassos, que vai permitir que ela se mova em velocidades realmente altas.

Resumindo

  • Questionar se o desenvolvimento de produto deve ou não ter uma equipe de QA dedicada não é a pergunta certa.
  • O problema que você está tentando resolver é como melhorar a qualidade do seu produto.
  • Uma boa métrica proxy de qualidade são os bugs. Inventário de bugs, novos bugs por semana e SLA de resolução de bugs.
  • Uma equipe de desenvolvimento de produto deve ter todos os seus membros seguindo essas métricas e agindo para melhorá-las.
  • Gerir bugs não é suficiente para gerir a qualidade do produto digital. Desempenho, escalabilidade, operabilidade, monitorabilidade são alguns exemplos de requisitos não funcionais que impactam diretamente na qualidade do produto digital.
  • A qualidade está em primeiro plano para fornecer uma boa experiência do usuário. Além disso, é fundamental para aumentar a velocidade de sua equipe de desenvolvimento de produto. Quanto menos bugs uma equipe tiver para corrigir, mais tempo ela terá para se concentrar em coisas novas.
  • Organizações de alta velocidade são capazes de aprender muito rápido, especialmente com suas falhas, e de absorver esse aprendizado como parte integrante do conhecimento da organização.

No próximo capítulo vamos ver um pouco mais sobre métricas.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Medindo e gerenciando a produtividade

Como podemos andar mais rápido? Como podemos entregar mais com o mesmo time? Por que temos a impressão de que o time está lento? Quando o time era menor, parecia que ele conseguia entregar mais. Esses são questionamentos e afirmações muito comuns que ouço sobre times de desenvolvimento de produto. Toda empresa que tem um time de desenvolvimento de produtos digitais gostaria que esse time fosse mais rápido. Neste capítulo vou mostrar as duas ferramentas essenciais para conseguir ter times mais rápidos e produtivos.

Medição

Não há como melhorar algo que não se mede. O que é velocidade de desenvolvimento de produto? É importante haver uma definição clara dessa métrica e consequente mensuração.

No meu último ano na Locaweb, estávamos nos focando bastante em produtividade, ou seja, em como os times de desenvolvimento de produto e de software da Locaweb poderiam produzir mais, sem precisarmos colocar mais gente nos times, e sem que a qualidade das entregas caísse.

O gráfico seguinte mostra nossos números. Contabilizamos quantidades de entregas por semana e, como dá para ver, em algumas semanas mais do que quadruplicamos a quantidade de entregas por semana.

Quantidade de entregas por semana na Locaweb

Esse aumento de produtividade aconteceu quando o time cresceu apenas 10% em quantidade de pessoas, logo, não dá para creditar esse aumento de produtividade ao aumento de pessoas nos times.

Quando há um aumento desses, além do natural questionamento sobre se o aumento de produtividade se deve ao aumento de pessoas nos times, outro questionamento que existe é se houve queda da qualidade das entregas. Uma das medições de qualidade que fazemos é a quantidade rollbacks. Como é possível perceber a seguir, mesmo com o aumento de produtividade, a quantidade de rollbacks foi reduzida em 40%!

Quantidade de rollbacks por semana na Locaweb

Na Locaweb fizemos uns cálculos estimados de entregas por semana no período de setembro de 2015 a fevereiro de 2016. O cálculo foi bem simples, total de deploys feitos no período dividido pelo número de semanas. Passamos, então, a comunicar toda a empresa sobre as entregas da semana.

Depois que cheguei à Conta Azul, decidimos implementar o mesmo tipo de controle de entregas semanais e acabamos conseguindo também um bom aumento da produtividade.

Quantidade de entregas por semana na Conta Azul

Tanto na Locaweb quanto na Conta Azul, cada gestor de produtos me mandava na sexta-feira as entregas da semana, eu compilava os dados e anotava a quantidade de cada semana, gerando esses gráficos. A partir do momento em que começamos a medir, ficou mais claro o nível em que estávamos, e as ações que passamos a fazer visando o aumento de produtividade começaram a mostrar resultado no gráfico. Além disso, os times passaram a usar uma única ferramenta de medição, o Jira, o que deu a eles uma visão melhor de progresso de cada time e permitiu comparações com troca de experiência, isto é, algo como “olha que interessante o seu gráfico, como vocês conseguiram aumentar esse indicador?”.

No Gympass, como escalamos a equipe muito rapidamente, decidimos controlar o número de entregas por pessoa por semana. Contamos as pessoas que ingressaram 2 meses antes, uma vez que as pessoas precisam de 1 a 2 meses para se tornarem produtivas. Em um trimestre, conseguimos aumentar em 16% nossa produtividade por pessoa. O número de entregas era extraído diretamente do JIRA.

Quantidade de entregas por semana no Gympass

Na Gympass, também medimos o número de deploys, tanto em nosso core, conhecido como monólito, quanto em microsserviços. Também conseguimos um aumento considerável em um ano.

Quantidade de deploys por mês no Gympass

Na Lopes, assim que um deploy era feito, um email era enviado com uma lista dos itens “deploiados”. Uma das primeiras coisas que fiz foi compilar esses relatórios em uma planilha para construir o gráfico adiante. Daí foi fácil notar que os deploys não aconteciam todos os dias. Aconteciam em média uma vez por semana. Assim que notamos isso, definimos OKRs para aumentar a frequência de deploys, o que vem surtindo efeito. Os OKRs que definimos foram:

  • Objetivo: Aumentar a cadência de deploys em produção;
  • KR: Aumentar o número de deploys por semana para no mínimo 3 (quanto mais melhor);
  • KR: Reduzir o número máximo de novas features por deploy para no máximo 10.
Quantidade de deploys por dia na Lopes

O que impacta a produtividade

A produtividade de um time de desenvolvimento de produto é impactada por vários fatores. Certa vez encontrei um artigo bem interessante escrito por Michael Dubakov, fundador da empresa Targetprocess onde ele mostra um mapa mental com todos os elementos que podem impactar positiva ou negativamente a produtividade de um time de desenvolvimento de produto. Esse artigo não está mais disponível mas, graças ao site Wayback Machine, é possível acessá-lo em:

http://web.archive.org/web/20150827162352/http://www.targetprocess.com/articles/speed-in-software-development/

O mapa mental é este aqui:

Mapa mental da Targetprocess sobre o que impacta a produtividade

Este diagrama mostra coisas e atividades que afetam a velocidade de desenvolvimento de alguma forma. Verde significa que uma atividade aumenta a velocidade. Quanto mais você tiver, melhor. Amarelo indica que existe algum máximo. Por exemplo, você pode acumular dívida técnica e aumentar a velocidade, mas, se acumular muito, isso o atrasará significativamente. O vermelho mostra coisas que retardam o desenvolvimento, quanto menos você tiver, melhor. A seta verde indica efeito crescente. Por exemplo, o trabalho focado aumenta a velocidade de desenvolvimento. A seta vermelha indica efeito decrescente. Por exemplo, melhores habilidades de desenvolvimento diminuem a complexidade do sistema (bons engenheiros criam sistemas menos complexos).

O que gosto dessa imagem é que ela mostra quão complexo é esse tema e quantas coisas podem impactar positiva ou negativamente a velocidade do time. Na Conta Azul acompanhávamos esse tema todo trimestre na Product Council, reunião em que conversávamos sobre o planejamento trimestral do time de desenvolvimento de produto com a liderança. Tinha um slide onde elencávamos todos os temas que podiam impactar a velocidade para discutirmos o que estávamos fazendo sobre cada um desses tópicos.

Temas que impactavam a velocidade do time de desenvolvimento de produto da Conta Azul

Coloque o tema produtividade no centro da discussão

Não há bala de prata, com cada time que trabalho foram várias ações que tomamos e sempre tivemos a certeza de que sempre há mais ações que poderão ser tomadas para aumentar a produtividade ainda mais.

A única bala de prata que existe é transformamos produtividade em tema importante de nossas conversas. Todos passaram a conversar sobre produtividade e sobre o que poderíamos fazer para melhorá-la.

Esse movimento nos fez iniciar várias mudanças e experimentos que nos ajudaram a aumentar consideravelmente nossa produtividade. Se você também quer aumentar a produtividade de seu time de desenvolvimento de produtos, coloque isso como tema central de suas conversas e experimente bastante. Você verá como há espaço para melhorar bastante a produtividade dos seus times de desenvolvimento de software.

Outro ponto importante: não deixe para discutir o tema produtividade esporadicamente. Minha recomendação é que você o faça semanalmente. Criar uma cadência semanal dará oportunidade de, a cada semana, experimentar com algo novo e discutir os resultados com o time.

Resumindo

  • Não existe bala de prata para aumentar a produtividade de um time de desenvolvimento de produto. Contudo, existem sim duas ferramentas essenciais para ajudar nesse objetivo.
  • A primeira ferramenta é medição. Não há como melhorar algo que não se mede. O que é velocidade de desenvolvimento de produto? É importante haver uma definição clara dessa métrica e consequente mensuração.
  • A segunda ferramenta é trazer o tema produtividade para o centro da discussão. Todos do time de desenvolvimento de produto são responsáveis pela produtividade do time. Por isso, ao trazer o tema para o centro da discussão, todos poderão colaborar para melhorar a produtividade.

No próximo capitulo veremos como outra métrica que tem impacto direto na produtividade, a qualidade.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Visão, estratégia, objetivos e estrutura de time

Aqui vou falar sobre as ferramentas que tenho usado nos meus quase 30 anos de carreira em liderança de desenvolvimento de produtos e que tenho compartilhado com outros e outras líderes para possam utilizar com suas equipes. Elas incluem visão, estratégia, objetivos, métricas, relacionamentos, contratação, feedback e cerimônias.

Você vai perceber que as ferramentas que vou comentar aqui não são softwares como planilhas, apresentações, documentos, Slack, JIRA, Confluence etc. Esses softwares costumam ser bem úteis, mas eles são só um veículo de documentação, comunicação e metrificação das ferramentas que vamos ver.

Visão, estratégia, objetivos e estrutura de time

Todos esses itens são, além de conceitos muito importantes, ferramentas essenciais para qualquer head de produto. Em todas as oportunidades que iniciei como head de produto, esses foram os primeiros temas de que eu tratei, começando sempre com visão de produto e, em seguida, partindo para os temas de estratégia, objetivos e estrutura de time. Esse também é meu primeiro foco quando começo algum trabalho de advisoring. Procuro entender quais são a visão, estratégia, objetivos e estrutura de time. Caso não haja algum desses elementos, eu ajudo as pessoas da empresa a os criarem.

Já expliquei o que são e como criar cada um desses itens nos seus respectivos capítulos da parte I, por isso farei apenas uma rápida revisão dessas ferramentas.

Visão

Como expliquei no capítulo Visão de produto, para fazer a visão de produto é preciso ter clareza sobre os objetivos da empresa com o produto, bem como entender profundamente os problemas e as necessidades que os clientes têm e que serão resolvidos pelo produto. Os 6 passos para construir uma visão de produto são obter objetivos estratégicos da empresa, obter entendimento dos problemas e necessidades dos clientes, desenhar primeira versão da visão, iterar e refinar, comunicar e revisar.

Costumo documentar e comunicar a visão de produto em uma apresentação. Se necessário, coloco alguma introdução teórica explicando os conceitos de plataforma e de marketplace. Em toda apresentação que faço, reapresento a visão de produto para deixá-la clara para todos.

Estratégia e objetivos

A estratégia de produto nada mais é do que o caminho que você vai seguir para chegar à sua visão de produto. Para criar sua estratégia de produto você precisa ter bastante entendimento sobre seu mercado, ou seja, os concorrentes, o mercado potencial e acessível, o crescimento desse mercado, se existem disruptores e como ele é regulado. Você também precisa entender seus pontos fortes e fracos, as oportunidades e ameaças. Uma análise SWOT pode ajudar. Com essas informações em mãos, você define o que você e seu time vão fazer para atingir a visão de produto, quais os objetivos que vocês precisam alcançar e quais métricas lhes dirão que vocês estão atingindo esses objetivos. OKRs são uma ótima ferramenta para trabalhar seus objetivos e métricas.

Existem alguns livros e cursos falando sobre como definir e usar OKRs. Por isso não vou entrar em muitos detalhes aqui. De forma bem sucinta, você define junto com o time alguns objetivos para um período – normalmente um trimestre ou um ano – e define em quais métricas vocês vão mexer para mostrar que o objetivo está sendo atingido.

Costumo documentar os OKRs em planilhas, que uso para acompanhar a evolução toda a semana com líderes do meu time de desenvolvimento de produtos, e também apresentar e discutir os OKRs com outras lideranças e áreas da empresa. A seguir, um exemplo:

Exemplo de planilha de OKRs

Note que toda semana os KRs são atualizados. Cada líder do time atualiza seus KRs com seus times toda segunda-feira e, depois, líderes e head de produto passam pelos KRs para ver como está o andamento de cada um e se há algum impedimento em que pode ser colocada energia para remover. Gosto de fazer na segunda-feira pois ajuda o time a organizar o trabalho da semana. A cadência semanal é fundamental para ajudar o time a revisar a performance no mínimo semanalmente e fazer ajustes se necessário. Se a cadência for maior (quinzenal ou mensal), perdem-se valiosas oportunidades de corrigir problemas e remover impedimentos.

A coluna T0 indica o valor inicial da métrica. A coluna responsável tem o nome da pessoa que é responsável por aquele KR e que vai liderar os esforços para fazê-lo acontecer. E a coluna suporte lista as pessoas ou áreas que vão ajudar o responsável.

Vale relembrar que, quanto mais próximo dos objetivos e das métricas de negócio forem os OKRs, melhor será para o time, pois ele 7estará trabalhando para ajudar a empresa em seus objetivos e resultados.

Estrutura de time

No capítulo Estrutura de Time eu disse que times de desenvolvimento de produto são organizados em times mínimos, também chamados de squads, compostos de engenheiras, product designers e product managers. É importante deixá-los o mais enxuto possível para ajudar em sua produtividade. Esses times mínimos são agrupados em times de produto chamados de tribos de produto.

4 formas de se organizar os times de produto: por produto ou funcionalidade, por tipo de usuário, por jornada ou por objetivo. É possível também usar dois tipos diferentes de organização criando uma organização híbrida. Existem também as tribos estruturais, que criam a estrutura necessária para as tribos de produto performarem. Times que compõem as tribos estruturais são SRE/DevOps, Dados, Arquitetura/Ferramentas/Fundação, Design Ops, Segurança da Informação, Sistemas Internos, Engenharia de Vendas e Serviços Profissionais.

Para ajudar a organizar o time, costumo usar um modelo de planilha bem simples como a seguinte:

Exemplo de planilha de estrutura de time

Essa planilha contém a estrutura do time e as pessoas que fazem parte dele. Note que não estamos documentando liderança funcional, e sim a liderança de cada time. No exemplo, temos João como GPM líder da PM Letícia e da PD Carol, Maria como GPM líder do PD Rafa e Sandra como líder dos times estruturais de SRE/TI, de Dados e do Pedro, que lidera a engenharia de 2 squads da tribo A e do squad da tribo B.

Um ponto importante é que não basta só criar esses elementos e depois não os utilizar. Essas ferramentas são proveitosas quanto mais você as utiliza. Planilha de OKRs eu uso no mínimo toda semana. Visão e estratégia, sempre que tenho oportunidade, eu falo sobre esses temas. Estrutura de time, sempre que vamos falar de contratações ou mudanças no time, utilizo a planilha que mostrei acima.

Resumindo

  • Visão, estratégia, objetivos e estrutura de time são, além de conceitos muito importantes, ferramentas essenciais para qualquer head de produto.
  • Para visão e estratégia, uma apresentação com alguns slides é suficiente. Para OKR e estrutura de time, planilhas dão conta do recado.
  • Mais importante do que os softwares que você utiliza para documentar Visão, estratégia, objetivos e estrutura de time é o que você faz com essas ferramentas. Planilha de OKRs eu uso no mínimo toda semana. Visão e estratégia, sempre que tenho oportunidade, eu falo sobre esses temas. Estrutura de time, sempre que vamos falar de contratações ou mudanças no time, utilizo a planilha de estrutura de time.

No próximo capítulo vamos ver como medir e aumentar a produtividade de um time de desenvolvimento de produto.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Mentalidade de ecossistema

Esse valor eu aprendi no Gympass. Era um dos valores corporativos da empresa e, na minha opinião, toda plataforma tem que ter esse valor. Muitas vezes me deparei com CEOs e heads de produto de plataforma que afirmavam que faziam tudo pelo cliente, que a empresa inteira era voltada ao cliente. Contudo, quando eu perguntava mais sobre esse tema, eu acabava descobrindo que o cliente ao que eles se referiam era apenas um dos atores da plataforma e os outros eram tratados apenas como “mal necessário”.

Na descrição do valor no site do Gympass está escrito:

Mentalidade de ecossistema

Tomamos decisões que criam valor para o nosso ecossistema Gympass e nos ajudam a alcançar nossa missão.

O exemplo que darei sobre mentalidade de ecossistema foi a implementação do produto de aulas ao vivo que o Gympass criou durante a crise do COVID-19.

Diversificando – e digitalizando – um portfólio de produtos

Durante a pandemia do COVID-19, diversificamos – e digitalizamos – nosso portfólio de produtos em tempo recorde. Passamos de um produto offline, acesso a academias e estúdios, para 4 produtos, 3 deles totalmente digitais, em menos de um mês:

  • Acesso a academias e estúdios: acesso a mais de 50.000 academias e estúdios em 14 países;
  • Aulas ao vivo: para quem gosta de treinar em grupo ou quer reviver a sensação da aula com os colegas da academia;
  • Personal trainers: para quem prefere uma abordagem mais personalizada e gosta de se exercitar no seu tempo;
  • Gympass Wellness: pacote de aplicativos com mais de 60 aplicativos para quem busca opções para melhorar o bem-estar físico e mental (da nutrição à sessão de terapia).

A seguir explico como fizemos isso.

Visão do Produto

Quando entrei para o Gympass, em meados de 2018, uma das primeiras coisas que fiz foi construir uma visão de produto. Tínhamos um propósito muito forte: vencer a inatividade. No entanto, para construir um produto digital, precisamos mais do que um propósito.

Visão de produto do Gympass

Essa visão orientou a definição da organização de desenvolvimento de produtos Gympass. Como comentei no capítulo Estrutura de time, montamos equipes em torno de cada um dos participantes do marketplace, além de uma equipe central que atuava no fluxo de pagamentos recolhendo o pagamento das empresas e de seus funcionários, fazendo todos os cálculos e determinando o pagamento de cada academia parceira.

Quando eu estava construindo essa visão de produto e discutindo-a com diferentes pessoas na organização, foi fácil ver muitas oportunidades de expandir esse mercado. Há uma grande quantidade de novas categorias de oferta que poderíamos adicionar ao nosso marketplace:

Oportunidades de expansão do Gympass

Existem 3 tipos de elementos em um mercado:

  • Oferta: bens ou serviços disponíveis para consumo.
  • Demanda: pessoas ou empresas que podem precisar de bens ou serviços oferecidos pelo fornecedor.
  • Mercado: onde a demanda encontra oferta e ocorre uma transação.

Esses três elementos se relacionam da seguinte maneira:

  • Entrega de valor: o mercado agrega valor à demanda e à oferta. O valor entregue à oferta são pessoas ou empresas interessadas em seus bens ou serviços. O valor entregue à demanda é um número variado de fornecedores de bens e serviços.
  • Pagamento: para ter acesso aos bens e serviços oferecidos pelos fornecedores, a demanda paga o mercado e o mercado paga a oferta. Normalmente, o mercado retém uma taxa por transação. Essa taxa pode ser fixa ou uma porcentagem do pagamento.
Dinâmica de um marketplace

Dada a dinâmica acima, podemos expandir um mercado da seguinte maneira:

  • Diversificação da demanda: você pode oferecer os bens e serviços do seu mercado para novos segmentos e regiões geográficas.
  • Diversificação de suprimentos: você pode oferecer novos bens e serviços à sua demanda.
  • Entrega de novo valor: você pode oferecer um novo valor para sua oferta e demanda.
  • Gestão financeira de pagamentos: como o pagamento da demanda para a oferta passa pelo mercado, você pode oferecer serviços financeiros tanto para a demanda quanto para a oferta, como pagamento antecipado e crédito, e pode gerenciar o spread.
Possibilidade de expansão de um marketplace

No entanto, tínhamos muito a fazer em nosso produto principal naquela época, então não tínhamos energia suficiente para nos concentrar na expansão de nosso marketplace e deixamos os planos na gaveta.

Novo empreendimento

Em outubro de 2019, chegamos a um ponto em que nossa equipe de desenvolvimento de produto estava bem estruturada e trabalhando adequadamente para enfrentar nossos desafios em nosso produto principal, então decidimos nos concentrar na expansão de nosso marketplace.

Decidimos trabalhar em uma ideia chamada “hub de parcerias do usuário final Gympass”. O plano era fazer parceria com aplicativos de bem-estar e fornecê-los aos nossos usuários.

Essa nova ideia tinha duas hipóteses principais que precisávamos testar:

  • Disposição para parceria de fornecedores de aplicativos. Os provedores de aplicativos, assim como as academias, estão acostumados com o modelo de receita mensal recorrente. Eles aceitariam ser pagos por dia de uso?
  • Disposição de pagar de nossa base de usuários. Nossa base de usuários está interessada em pagar uma mensalidade para ter acesso aos aplicativos?

Para testar nossa primeira hipótese, construímos um deck com a proposta de valor que planejávamos entregar aos parceiros e conversamos com alguns parceiros em potencial. Apresentamos a oportunidade de parceria a 8 potenciais parceiros, dos quais 6 mostraram interesse e 4 decidiram juntar-se à nossa prova de conceito. NEOU, um app de treino de atividade física, 8fit, um app de treino de atividade física e de nutrição, Tecnonutri, um app de nutrição e ZenApp um app de meditação.

Ok, nossa primeira hipótese foi validada e precisávamos validar a segunda hipótese, a disposição a pagar. Nosso usuário está disposto a pagar para ter acesso a esses aplicativos através do Gympass?

Para testar nossa segunda hipótese, construímos um formulário simples, onde descrevemos o produto e perguntamos nome, e-mail e empresa. Após o usuário fornecer essas informações, ele seria direcionado para uma página de assinatura do Paypal, onde ele precisa fornecer os dados do cartão de crédito para assinar o serviço. O usuário receberia um e-mail com o link de ativação de cada aplicativo. Não havia um produto real, apenas um formulário para testar o interesse e um e-mail com os links para os aplicativos.

Inicialmente, o chamamos de Gympass W, o W significando wellness (bem-estar). Adicionamos um beta para que todos pudessem entender que não era um produto acabado. Mais tarde, renomeamos para Gympass Wellness para deixar sua proposta de valor mais clara.

Nosso plano era testar essa prova de conceito com 5 clientes corporativos nos EUA e 5 no Brasil, o que nos forneceria uma base de potenciais usuários de 15.000 funcionários. Nossa expectativa era ter cerca de 200 assinantes. Lançamos internamente – eat your own dog food (coma sua própria ração para cachorro) – em 9 de março de 2020 e conquistamos 66 inscritos. Em seguida, veio o COVID-19.

COVID-19

Quando uma empresa é atingida por uma crise, ela precisa olhar para estas duas perspectivas:

  • preservar o dinheiro;
  • identificar e se adaptar às mudanças nos problemas e necessidades do cliente.

Embora gestores de produto e as equipes de desenvolvimento de produto tenham um papel importante no primeiro, seu papel principal é no segundo.

No Gympass temos 3 clientes diferentes e todos eles profundamente impactados pelo COVID-19:

  • academias em muitas cidades foram fechadas para auxiliar nas medidas de distanciamento físico aplicadas em muitas cidades para evitar a disseminação do COVID-19 e, consequentemente, estão perdendo receitas recorrentes de usuários que não frequentam a academia;
  • os usuários, funcionários de nossos clientes, não podem mais ir às academias e têm que ficar em casa, mas também têm que se manter ativos de alguma forma, mas sua primeira reação é cancelar ou pausar sua inscrição no Gympass, pois não terão acesso às academias por um tempo;
  • clientes corporativos, cujos funcionários estão em casa e não vão mais a academias, enquanto os RHs se preocupam em como manter esses funcionários engajados e produtivos.

Gympass Wellness, o primeiro produto digital

Fomos capazes de adaptar nosso piloto do Gympass Wellness em tempo recorde para ser oferecido a toda a nossa base de usuários, de forma que eles possam não apenas permanecer ativos, mas também cuidar de sua alimentação e de suas mentes durante esses tempos tão desafiadores. Com o Gympass Wellness, fomos capazes de atender aos problemas e necessidades dos usuários e de nossos clientes corporativos durante a crise.

E aqui entra a mentalidade de ecossistema. Devemos sempre olhar para todos os participantes em nosso mercado e garantir que todos se beneficiem de usá-lo.

Live Classes, o segundo produto digital

Com o Gympass Wellness, fomos capazes de atender às necessidades de nossos clientes corporativos e de seus funcionários. E as academias? Ao serem fechadas, estavam perdendo receita. Seus clientes não os visitavam mais, então os usuários regulares das academias estavam propensos a cancelar sua assinatura, enquanto aqueles que costumavam ir às academias usando o Gympass não iam à academia durante a crise, o que causaria uma perda de receita para as academias também. Para ajudar as academias parceiras, decidimos e implementamos em tempo recorde 2 soluções:

  • Fornecemos às academias um aplicativo white-label para que elas pudessem oferecer a todos os seus clientes, independente de serem ou não funcionários de clientes do Gympass, para que as academias pudessem entregar valor aos seus clientes, ajudando-os a se manter ativos em casa;
  • Fornecemos uma plataforma para as academias agendarem e transmitirem aulas ao vivo para todos os usuários do Gympass, para que eles possam manter seus instrutores empregados, enquanto fornecem aos usuários do Gympass conteúdo exclusivo. Essa plataforma é chamada de Live Classes.

Personal Trainers, o terceiro produto digital

As Live Classes forneciam uma plataforma 1:N, o que significa que um instrutor poderia fornecer orientação de atividade física para N usuários. Logo percebemos que poderíamos criar outro produto além do Live Classes, orientação de atividade física 1:1, que poderia ser disponibilizada nos planos de nível superior do Gympass. Em seguida, criamos nosso terceiro produto digital, Personal Trainers.

Resumindo

  • Mentalidade de ecossistema significa tomar decisões que criam valor para todos os atores de uma plataforma.
  • No Gympass, durante a crise do COVID-19, depois de colocarmos o Gympass Wellness para todos os seus clientes e os funcionários desses clientes, uma parte importante do ecossistema ainda estava sofrendo, as academias. Foi a mentalidade de ecossistema que guiou o Gympass para criar o produto de Live Classes, que permitiu que as academias continuassem operando mesmo estando de portas fechadas.

Pronto, com este capítulo concluímos a segunda parte do livro, sobre Princípios. Aqui vimos meus princípios pessoais de liderança:

  • Pessoas: a prioridade nº 1, sempre.
  • Liderar é como ser um médico.
  • Liderando sob pressão.
  • Mentoria é uma via de mão dupla.
  • Como e quando delegar.

Vimos também o que é cultura empresarial, um conjunto de maneiras de resolver problemas e reagir a situação compartilhadas por um grupo de pessoas trabalha junto. Vimos também os 5 valores necessários para criar produtos digitais de sucesso:

  • Não desperdice tempo buscando culpados, foque nos aprendizados.
  • Não compare situações de trabalho com guerra, ninguém quer matar ninguém.
  • Lucro e receita são consequência, não deve ser o foco principal.
  • Transparência, a fundação de um time de alta performance.
  • Diversidade, a base dos melhores produtos.

Por fim, vimos um conjunto de quatro valores que são de fato o núcleo de todo time de desenvolvimento de produtos digitais. São os valores que compõem a cultura de produto, que nada mais é do que o conjunto de comportamentos dos times de desenvolvimento de produtos digitais que produzem os melhores resultados:

  • Lançamento antecipado e frequente
  • Foco no problema
  • Entrega de resultado
  • Mentalidade de ecossistema

Vamos agora ver as ferramentas? \o/

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Foco no problema

É da natureza humana resolver problemas. Sempre que ouvimos falar de problemas, entramos quase imediatamente no modo de solução: começamos a buscar soluções para o problema. No entanto, se antes conseguirmos um melhor entendimento sobre o contexto em que o problema ocorre e a motivação para resolvê-lo, há mais chances de conseguirmos encontrar soluções mais simples e fáceis de implementar.

É comum ver outras áreas pedindo à equipe de desenvolvimento de produtos que implemente o recurso A ou B porque precisamos dele para fechar um negócio ou para não perder esse grande cliente. Um exemplo comum que tenho ouvido atualmente é “precisamos implementar o Apple Pay e o Google Pay como um novo método de pagamento”. A questão aqui é que, falando em soluções, perdemos o foco no problema que originou essa solução.

Qual é o problema?

Para ajudar as pessoas a se focarem no problema, pergunte sempre “Qual é o problema?”. Quando uma nova solicitação de funcionalidade chega à equipe de desenvolvimento do produto, devemos agradecer ao solicitante pelo pedido e, em seguida, devemos perguntar sobre o problema que gerou a solicitação. Cada membro da equipe de desenvolvimento de produtos precisa ter esse comportamento sempre que uma solicitação de nova funcionalidade for recebida.

Ao colocar isso em prática, em breve as solicitações virão não apenas com uma solução, mas também com muitas informações sobre o problema. É interessante ver essa mudança cultural, mas requer a disciplina dos membros da equipe de desenvolvimento de produtos para sempre perguntar sobre o problema. E quando menciono os membros da equipe de desenvolvimento de produtos, estou me referindo a todos, não apenas aos gestores de produto, mas também aos designers e às engenheiras e engenheiros de produto.

Mentalidade de problema vs. solução

A principal vantagem de nos focarmos em entender melhor o problema é que, quanto mais tempo investirmos nisso, mais fácil será encontrar uma solução e há boas chances de que essa solução seja mais simples e rápida de implementar do que a primeira solução que pensamos.

Aqui está uma ótima citação de Albert Einstein:

“Se eu tivesse uma hora para resolver um problema, gastaria 55 minutos pensando sobre o problema e cinco minutos pensando nas soluções.”

Einstein acredita que a qualidade da solução que você gera está em proporção direta com sua capacidade de identificar e compreender o problema que espera resolver.

Deixe-me contar uma pequena história para ilustrar isso. Durante a corrida espacial, os cientistas se depararam com o problema de escrever no espaço onde não houvesse gravidade para fazer a tinta cair em uma caneta esferográfica. Os americanos começaram seus esforços de P&D e depois de algum tempo e alguns milhões de dólares, eles construíram uma caneta com um pequeno motor que bombeia tinta para o papel, mesmo sem gravidade. Enquanto isso, os russos decidiram usar lápis.

Caneta que escreve em ambientes sem gravidade.

Essa história mostra um bom exemplo de como pular direto para a solução pode nos fazer gastar tempo e dinheiro desnecessários para chegar a soluções incompletas ou exageradas. É uma questão cultural, ou seja, um comportamento que podemos e devemos mudar. E o primeiro passo para mudar um comportamento é reconhecer quando ele acontece. Quando um membro da equipe de desenvolvimento de produto recebe uma solicitação para implementar algo, ele deve perguntar à pessoa que trouxe a solicitação qual é o problema que esse “algo” deve resolver e por que é necessário resolvê-lo.

Aqui estão alguns exemplos das empresas em que trabalhei.

Na Locaweb, provedora de hospedagem web no Brasil, os serviços de hospedagem e e-mail podem parar de funcionar devido a fatores externos como o domínio que está associado à hospedagem e ao e-mail não ser renovado.

Primeira solução: Registro.br, o registrador brasileiro de domínios .br lançou uma API para permitir que a Locaweb cobrasse o domínio do cliente em nome do Registro.br. A princípio, a ideia parecia boa, já que a Locaweb cobrar o domínio parecia a forma mais fácil de garantir que o cliente saiba que tem que pagar pelo registro do domínio para manter os serviços de hospedagem e e-mail funcionando corretamente. Porém, quando analisamos mais a fundo, vimos que essa solução poderia gerar alguns problemas. O cliente seria cobrado duas vezes pelo mesmo registro de domínio porque o Registro.br continuaria cobrando o domínio. O que acontece se o cliente pagar as duas contas? E se ele pagar apenas o Registro.br? E se ele pagar apenas Locaweb? Além disso, implementar um novo tipo de cobrança em que cobraríamos por um serviço de terceiros era algo novo para a equipe da Locaweb. Novos processos teriam que ser cuidadosamente projetados.

Solução real: começamos a nos perguntar se haveria maneiras mais simples de resolver o problema de ajudar nosso cliente a não esquecer que ele tem que pagar pelo registro de domínio no Registro.br. Como seria possível cobrar pelos serviços do Registro.br, foi possível acessar as informações sobre o domínio prestes a expirar. Decidimos desenhar uma solução mais simples: implementar uma régua de comunicação com este cliente avisando-o da importância de pagar ao Registro.br para garantir que os serviços de e-mail e hospedagem continuem funcionando normalmente. Esta é uma solução muito mais simples do que implementar um processo de faturamento dobrado. Se o Registro.br nos fornecer a URL de cobrança, podemos enviar as informações desse link ao cliente e as chances de solucionar o problema aumentarão ainda mais. E uma sequência de comunicação é muito mais simples e rápida de implementar do que um processo de faturamento duplicado.

Na Conta Azul, um ERP SaaS para MPEs (micro e pequenas empresas), usamos contadores como um de nossos canais de distribuição e queríamos aumentar as vendas por meio de contadores.

Primeira solução: compras em lote, onde os contadores adquiririam um número fixo de licenças do Conta Azul para revender aos seus clientes. Um sistema de gerenciamento de compras em lote levaria cerca de 3 meses para ser implementado, pois deveria permitir que os contadores comprassem licenças da Conta Azul a granel, mas só deveria começar a cobrar do cliente da contadora quando esse cliente realmente ativasse a licença.

Solução real: os contadores não se importavam com as compras em lote. O que eles queriam era dar um desconto aos seus clientes para que eles pudessem assinar a Conta Azul com esse desconto exclusivo proporcionado por seu relacionamento conosco. O custo para implementar isso foi zero, pois o sistema já tinha um recurso de gerenciamento de descontos.

No Gympass, um parceiro de fitness que estava ingressando em nossa rede solicitou que apresentássemos seu waiver (termo de isenção de responsabilidade) a todos os usuários que fizessem o check-in em suas instalações.

Primeira solução: mudar nosso aplicativo para pedir aos usuários que vão a este parceiro de fitness que leiam seu waiver em nosso aplicativo e marquem um checkbox informando que leram e estão de acordo.

Solução real: nenhuma alteração em nosso aplicativo. Usamos um campo de texto personalizável na configuração de uma academia em nosso sistema que normalmente é apresentado aos usuários que farão check-in nessa academia para apresentar o seguinte texto: “Ao fazer o check-in, você concorda com os termos e condições localizados em http://fitnesspartner.com/waiver”.

Não me interprete mal, é muito bom que todos tragam soluções sempre que quisermos discutir algo a ser feito pela equipe de desenvolvimento de produto. Quanto mais ideias de solução tivermos, melhor. No entanto, precisamos nos educar para ter um entendimento mais profundo do problema por trás dessa solução, para que tenhamos a chance de encontrar soluções mais simples e rápidas para implementar. E é, em última análise, o trabalho da gestora de produto e de todos os membros da equipe de desenvolvimento de produto perguntar qual é o problema e por que precisamos resolvê-lo.

Projetos vs. problemas

O ano novo é tempo de retrospectiva e planejamento. O que normalmente é feito a cada trimestre pela maioria das equipes de desenvolvimento de produtos é feito de forma mais intensa na virada do ano, em conjunto com outras áreas da empresa. É o processo de planejamento anual, que normalmente vem junto com o processo de orçamento. O que faremos neste novo ano que está chegando? Quais são os principais projetos que trabalharemos ao longo do ano?

Mesmo que o planejamento seja superimportante para ter clareza sobre quais projetos são prioridades para o novo ano, esta lista de projetos pode fazer você perder de vista um aspecto muito importante do planejamento, o “porquê”.

Não é incomum ver o planejamento de ano novo para uma equipe de desenvolvimento de produto, e até mesmo para toda a empresa, como uma lista de projetos. Para ajudá-lo a ver sua lista de projetos em um ângulo diferente, adicione 2 colunas:

  • uma para descrever quais são os problemas que você está tentando resolver em cada projeto;
  • e outra para descrever para quem você está tentando resolver este problema.

Já discuti as questões de ter uma mentalidade orientada para a solução versus uma mentalidade orientada para o problema, mas quando se trata de planejamento de ano novo, esse problema fica ainda mais evidente. Os benefícios de ter clareza sobre os problemas que deseja resolver e para quem você planeja resolvê-los são:

Garantir que os problemas estejam alinhados com a visão e estratégia da empresa: quando focamos em projetos, é fácil perder de vista os problemas que estamos tentando resolver, para quem planejamos resolver, e se são esses problemas que realmente precisamos resolver.

Definir quais problemas são mais importantes para resolver: priorizar projetos sem saber quais problemas esses projetos resolvem, e para quem, pode tornar as prioridades não alinhadas com o que é realmente importante para a empresa. Porém, para sermos mais eficazes em trazer o resultado desejado, devemos priorizar os problemas a serem resolvidos e garantir que a priorização esteja alinhada com a visão e estratégia da empresa.

Resolver mais de um problema com o mesmo projeto: às vezes, você pode descobrir que está tentando resolver mais de um problema com um projeto, e isso pode não ser um problema. Mas você precisa saber disso. Talvez você possa ter soluções mais simples se tratar cada problema separadamente. Talvez nem todos valham a pena resolver neste momento.

Verificar se os projetos são as melhores soluções: quando mudamos o foco dos projetos para os problemas e temos uma visibilidade clara da prioridade dos problemas, fica mais fácil verificar se os projetos listados são a melhor solução para o problema em questão. Às vezes, podemos encontrar soluções que são mais fáceis de implementar quando mudamos nosso foco para a compreensão dos problemas.

Então pegue sua lista de projetos e crie essas duas colunas, problemas a serem resolvidos em cada projeto e para quem os problemas serão resolvidos. Isso ajudará você a se concentrar nas coisas mais importantes para este novo ano.

Equipes solucionadora de problemas vs. equipes implementadoras de solução

Marty Cagan, uma referência bem conhecida na comunidade de produtos digitais, escreveu há algum tempo um artigo interessante sobre equipes de produtos x equipes de funcionalidades, onde explica a diferença entre três tipos de equipes, as equipes de entrega, as equipes de funcionalidades e as equipes de produto. Ele define de cada tipo de equipe da seguinte forma:

  • As equipes de entrega não são multifuncionais (basicamente apenas desenvolvedores mais um product owner que administra o backlog), não estão focadas no resultado (as pessoas são todas orientadas à entrega de funcionalidades) e não têm autonomia (estão lá para codificar e entregar).
  • As equipes de funcionalidades geralmente são multifuncionais (têm pelo menos uma designer e uma gestora de produto), mas ainda se preocupam com a produção e entrega de funcionalidades.
  • As equipes de produto são multifuncionais, focadas e avaliadas pelo resultado, e têm autonomia para apresentar soluções que funcionem.

Ele explica que os melhores resultados para a organização dona do produto e para os usuários desse produto vêm das equipes que ele chama de equipes de produto. Ele tem usado muito a palavra empoderado (empowered) para descrever esses times.

Qualquer produto digital existe para dois propósitos principais:

  • Ajudar a empresa dona do produto digital a atingir seus objetivos.
  • Resolver os problemas e atender as necessidades de seus usuários.

Portanto, qualquer produto digital e suas funcionalidades são soluções para problemas da empresa dona do produto e soluções para resolver os problemas do usuário e atender às suas necessidades.

Neste contexto de produto digital, quando digo que gastar mais tempo entendendo o problema produz as melhores soluções, quero dizer que somos capazes de entregar o mais rápido possível o melhor produto e funcionalidades para resolver o problema em mãos com software de boa qualidade e boa experiência de usuário.

Solucionar problemas vs. implementar solução

O que Marty descreve como equipes de entrega e equipes de funcionalidades são equipes de implementadores de soluções. Essas equipes trabalham na implementação de uma solução concebida por outra pessoa. E essa outra pessoa normalmente é alguém da chamada “área de negócios”, que pode ser alguém de vendas, marketing, sucesso do cliente, suporte ao cliente, finanças, operações, um diretor, um vice-presidente ou um fundador. Em tal equipe, o gerente de produto gerencia principalmente o backlog e ajuda a equipe a entregar a solução solicitada, o designer de produto se concentra principalmente em desenhar uma interface agradável e os engenheiros têm que codificar e implantar a solução solicitada. As equipes de implementação da solução fazem o que foi solicitado, com pouco ou nenhum compromisso com a qualidade da solução, ou mesmo se a solução implementada realmente resolve o problema. Podem também ser chamadas de “fábrica de funcionalidades”. Sua performance é medida pela quantidade de funcionalidades que o time produz.

Por outro lado, o que Marty descreve como equipes de produto empoderadas são equipes de solução de problemas. Essas equipes trabalham para compreender profundamente as causas do problema, o contexto e a motivação que as pessoas têm para resolvê-lo. Ao fazer isso, eles são capazes de implementar a melhor solução para o problema em questão.

Existem três razões principais pelas quais as equipes de solução de problemas são mais eficazes do que as equipes de implementadores de soluções:

Conhecimento de produto digital: não há ninguém melhor do que os membros da equipe para encontrar a melhor solução de produto digital para um problema. Uma solução entregue o mais rápido possível, com boa qualidade de software e boa experiência do usuário. Isso acontece porque uma equipe de solucionadores de problemas é uma equipe multifuncional composta por engenheiros que entendem a tecnologia disponível, designers de produto, que têm um conhecimento profundo dos usuários, suas dores e necessidades, e gestores de produto, que têm um bom entendimento do contexto empresarial do problema a ser resolvido.

Duas cabeças pensam melhor do que uma: este velho ditado significa que é mais fácil para duas pessoas que se ajudam resolverem um problema do que para uma pessoa resolver um problema sozinha. Uma equipe de solucionadores de problemas não descarta nenhuma sugestão de solução das “áreas de negócios”. Na verdade, essas sugestões de solução são muito úteis para ajudar a equipe a entender melhor o problema, mas elas devem ser consideradas dessa forma, sugestões. Uma equipe de solucionadores de problemas primeiro entende profundamente o problema e, em seguida, analisa as opções de solução.

Compromisso: um efeito colateral adicional de uma equipe de solução de problemas é que os membros dessa equipe estão profundamente comprometidos com o sucesso da implementação da solução, uma vez que estão profundamente envolvidos no processo de busca da solução.

Criação de equipes de solução de problemas

Agora que expliquei por que as equipes de solução de problemas são o melhor tipo de equipe de produto que uma empresa pode ter, explicarei como construir equipes de solução de problemas. Existem três aspectos que precisam ser considerados:

Ambiente: é fundamental que toda a organização entenda o poder de ter equipes de produtos digitais para solução de problemas. A velocidade e a qualidade das soluções entregues por uma equipe de produto digital que sempre começa a resolver os problemas a partir de um entendimento profundo do problema é muito melhor do que as soluções entregues por equipes de implementadores de soluções. Consequentemente, os resultados do negócio serão melhores e mais rápidos. É função e responsabilidade do head de produto ajudar a organização a entender isso.

Qual é o problema: uma maneira muito eficaz de enfocar toda a organização para longe da mentalidade de solução e mais próximo da mentalidade de problema é perguntar constantemente “Qual é o problema que estamos tentando resolver?” e “Por que é importante resolver este problema?”. Isso ajudará as pessoas de toda a organização a mudar sua perspectiva e, consequentemente, perceber a importância de um entendimento profundo do problema antes de implementar uma solução. Essa é uma mudança de comportamento que toda a equipe de desenvolvimento de produto digital pode ajudar sua organização a fazer. Sempre que alguém pede à equipe de produto para implementar algo, pergunte “Qual é o problema que estamos querendo resolver?”.

Confiança: este é um aspecto crítico para construir equipes bem-sucedidas de produtos digitais de solucionadores de problemas. Normalmente as pessoas da “área de negócios” acreditam ter um melhor entendimento do negócio do que as da equipe de produto. Esse comportamento fica ainda mais visível quando a equipe de produto digital é nova na organização. Como uma pessoa nova na organização pode entender mais sobre o negócio do que quem está na empresa há anos? Provavelmente ela não pode, especialmente se ela vier de um mercado diferente. No entanto, quem faz parte da equipe de produto digital normalmente tem muita experiência na construção de produtos digitais, provavelmente mais experiência do que qualquer outra pessoa na organização.

Por isso, é fundamental que a “área de negócios” eduque a equipe de produto digital sobre os aspectos de negócios da organização. Essa busca por educação é papel e responsabilidade dos gerentes de produto, que devem aprender com a “área de negócios” e educar designers e engenheiros de produto sobre o negócio. Uma forma prática de acelerar esse aprendizado é trazer pessoas da “área de negócios” para as sessões de discussão sobre o problema. É assim que a equipe de produto ganha a confiança das demais áreas da organização.

Acredito que estão claros os benefícios de ter equipes de produto digital de solucionadores de problemas versus implementadores de solução. Toda a organização precisa entender a diferença a fim de pressionar por mais e mais equipes de resolução de problemas. A head de produto tem essa como uma de suas maiores responsabilidades, ajudar a construir o ambiente e a confiança necessária para o sucesso das equipes de solução de problemas.

A armadilha do top-down

Quando falo sobre as diferenças entre equipes solucionadoras de problemas vs equipes implementadoras de solução, normalmente ouço comentários como “Queremos ser uma equipe de solucionadores de problemas, mas na minha empresa todas as soluções são top-down e a única coisa que podemos fazer é implementá-las”.

Essas situações agravam-se quando surge pressão. A pressão mais recente que muitas empresas estão sofrendo é a crise do COVID-19. Na ânsia de resolver os problemas o mais rápido possível, os líderes da empresa pedem às equipes que implementem esta ou aquela solução de maneira rápida, muito rápida.

A armadilha

Deixe-me agora abordar o elefante na sala, o ambiente de tomada de decisão top-down. Isso tem um impacto enorme em qualquer equipe neste tipo de ambiente. Sem fazer parte da decisão sobre a solução, as pessoas que implementam a solução acabarão por ficar desmotivadas.

Por que estou chamando de armadilha do top-down? Porque muitos dos ambientes de tomada de decisão percebidos como top-down são isso que acabei de escrever, uma percepção.

Vamos usar a principal característica que toda gestora de produto deve ter, empatia. A habilidade de alguém se colocar no lugar de outra pessoa para entender suas aspirações, motivações, necessidades e problemas. Pessoas com quem tive a oportunidade de falar sobre as características essenciais de um gestor de produto sabem o quão importante considero a empatia como um traço crítico para PMs de sucesso.

Aqui estão 2 dicas para ajudar os membros da equipe de produto a ter empatia com os chamados tomadores de decisão top-down e escapar da armadilha de cima para baixo:

  • Compreendendo a situação: coloque-se no lugar do solicitante da implementação de solução. As pessoas resolvem problemas, é a natureza delas, e sempre que se deparam com um problema, pulam para o modo de solução e tentam encontrar e implementar soluções o mais rápido possível. Sob maior pressão, como a crise COVID-19, o desejo de encontrar e implementar soluções é exacerbado. Na maioria dos casos, as pessoas não querem ser tomadores de decisão top-down, elas simplesmente têm uma necessidade de resolver o problema o mais rápido possível.
  • Alterando o status quo: faça perguntas sobre a solicitação de implementação de solução. Que problema estamos resolvendo? Para quem? Por que é importante resolver esse problema? Por que agora? Por que precisamos entregar algo rápido, mesmo comprometendo a qualidade? Se lhe perguntarem o motivo de tantas perguntas, explique que está tentando entender melhor o problema para ver se existem outras soluções mais baratas e rápidas.

Essas dicas ajudarão todos na equipe de produto a fazer a mudança para um processo de tomada de decisão mais colaborativo.

Na maioria das vezes, as pessoas entendem os benefícios de um processo colaborativo de tomada de decisão. Mesmo sob pressão, as soluções colaborativas produzirão melhores resultados. Soluções concebidas em um processo colaborativo são normalmente mais baratas e rápidas de implementar porque mais pessoas tiveram a chance de discutir as opções de solução e a equipe que implementará a solução selecionada estará verdadeiramente comprometida com seu sucesso.

Para construir, manter e melhorar as equipes de solução de problemas e evitar transformá-las em equipes de implementação de soluções, especialmente quando sob maior pressão, é fundamental evitar a armadilha do top-down.

Os heads de produto têm o papel e a responsabilidade de promover essas mudanças de comportamento para ajudar a construir um processo de tomada de decisão mais colaborativo e, consequentemente, mais eficaz.

Resumindo

  • Um passo muito importante para criar uma boa solução é a compreensão do problema. Quando ouvimos sobre um problema, imediatamente começamos a pensar nas soluções. No entanto, quanto mais tempo gastamos aprendendo sobre o problema, mais fácil será encontrar uma solução e há boas chances de que essa solução seja mais simples e rápida de implementar do que a primeira solução que pensamos.
  • Se você tiver uma lista de projetos para fazer, crie duas colunas a mais nessa lista, uma para problemas a serem resolvidos em cada projeto e outra para quem os problemas serão resolvidos. Isso ajudará você a se concentrar nos problemas a serem resolvidos, e não nos projetos, que são a solução.
  • Equipes de implementação de solução são equipes trabalham na implementação de uma solução concebida por outra pessoa. Equipes de solução de problemas são equipes trabalham para compreender profundamente as causas do problema, o contexto e a motivação que as pessoas têm para resolvê-lo. Ao fazer isso, eles são capazes de implementar a melhor solução para o problema em questão.
  • A armadilha top-down é a percepção do processo de tomada de decisão sendo feito pelos líderes da empresa, sem oportunidade de participação do resto dos funcionários. Essa percepção é exacerbada quando uma empresa enfrenta uma pressão crescente, como a crise do COVID-19.
  • As pessoas são orientadas para a solução e, quanto maior a pressão, mais rápido as pessoas desejam que as soluções sejam implementadas.
  • Para ajudar a lidar com essa situação, use a empatia para entender o ponto de vista do solicitante de implementação da solução e pergunte a ele por que é necessário implementar a solução solicitada.
  • Os heads de produto têm a função e a responsabilidade de promover essas mudanças de comportamento para ajudar a construir um processo de tomada de decisão mais colaborativo.

No próximo capítulo vamos entender mais sobre o foco em entrega de resultados.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Diversidade, a base dos melhores produtos

Tenho visto com cada vez mais frequência manifestações sobre diversidade. Não sou muito de assistir TV, mas certo dia em 2017 acabei vendo um pouco de TV Globo. Peguei o final do Jornal Nacional e o início da novela. No Jornal Nacional, vi uma matéria sobre a PUC de São Paulo inaugurando banheiros unissex – lembrando que PUC é Pontifícia Universidade Católica, uma universidade ligada à religião Católica. Em seguida, na novela apareceu uma personagem que estava contando para os pais e familiares que ela nasceu no corpo errado, que era um homem que havia nascido em um corpo de mulher, ou seja, que ele era transgênero. Em seguida, durante o intervalo, veio a campanha da Globo intitulada “Tudo começa pelo respeito” sobre respeito à identidade de gênero.

Isso é muito bom! Aceitar e respeitar as diferenças é a base para evoluirmos como sociedade e construirmos um futuro cada vez melhor para nós, para nossos filhos e para toda a humanidade.

Quando faltam o respeito e a capacidade de aceitar a diversidade, podem acontecer situações muito ruins, por exemplo, de pais rejeitando o próprio filho. Fiquei bastante impressionado quando li o relato da Daniela Andrade, consultora sênior da ThoughtWorks, onde ela conta que:

“Como fui expulsa da casa dos meus pais, por ser transexual —  e aqui eu digo que a primeira grande violência que sofremos é dentro de casa  —  há muitos anos não tenho parentes com quem contar em momentos de necessidade, todos deram as costas para mim.”

Como é possível um pai rejeitar a própria filha? Sou pai e sei como o amor de pai é algo muito intenso, capaz de passar por cima de qualquer problema para podermos sempre ajudar e suportar nossos filhos. Estava conversando outro dia com minha esposa sobre esse relato e sobre a dificuldade das pessoas em aceitarem as diferenças, ao ponto de rejeitarem seus próprios filhos. Foi nesse momento que minha esposa disse uma frase que me marcou. Ela disse que, em última instância, todas as pessoas são diferentes. Transgênero, cisgênero, heterossexual, homossexual, bissexual, assexual, negro, branco, amarelo, jovem, adulto, meia-idade, terceira idade, brasileiro, canadense, francês, vietnamita, fluminense, mineiro, paulista, carioca, belo-horizontino, corredor, ciclista, nadador, engenheiro, arquiteto, advogado, quem gosta de música pop, rock, jazz, clássico e assim por diante. Mesmo gêmeos idênticos são diferentes.

Se todas as pessoas são diferentes, aceitar e respeitar as diferenças não é só desejável, é necessário e obrigatório para que possamos viver em sociedade de uma forma mais harmônica e sustentável. São valores que devem ser ensinados para todas as pessoas desde o berço.

E o que diversidade tem a ver com gestão de produtos digitais?

Além da importância de aceitar e respeitar as diferenças para ajudar a criar uma sociedade mais harmônica e sustentável, a diversidade vai ajudar a criar produtos digitais cada vez melhores por dois motivos:

  • Diversidade traz novos pontos de vista. Ter um time de desenvolvimento de produtos mais diverso traz novos pontos de vista e novas maneiras de pensar, o que ajudará a desenvolver um produto melhor. Não é à toa que o time de desenvolvimento de produtos é composto de engenheiros de software, designers de experiência do usuário e gestores de produto. Cada pessoa tem visões diferentes do que é um bom produto e essas diferenças, quando bem trabalhadas pelo time, é o que ajuda a criar um produto melhor.
  • Da mesma forma que o grupo de clientes que usa o seu software é diverso, seu time também deveria ser. Normalmente os times de desenvolvimento de produto de software são compostos em sua maioria por homens, só que a população do Brasil é mais diversa. Tanto na Conta Azul como na Locaweb, mais de 88% do time é composto de homens. Só que esses times fazem produtos que serão usados pela população brasileira, que é composta por 48,2% de homens e 51,8% de mulheres segundo o IBGE (Instituto Brasileiro de Geografia e Estatística). Vale lembrar ainda que a divisão “homens” e “mulheres” é simplista e que a diversidade de gênero é não binária, ou seja, há outras identidades de gênero além de feminino e masculino.

Por isso é tão importante refletir e conversar sobre o assunto diversidade. Só assim você poderá pensar em questões tão essenciais para o sucesso do seu produto. Como melhorar a diversidade do seu time de desenvolvimento de produto? Como fomentar discussões que trazem diferentes pontos de vista e ajudam a enxergar sob novos ângulos o seu produto e os problemas que ele ajuda a resolver?

Em todos os times que liderei eu trouxe esse tema para ser discutido. Juntos pensamos em como poderíamos melhorar essa diversidade. Um exemplo interessante do resultado desse trabalho ao longo de 12 meses foi o que conseguimos fazer no Gympass, com um aumento de 5 pontos percentuais.

Time de desenvolvimento de produto do Gympass em setembro de 2018
Time de desenvolvimento de produto do Gympass em agosto de 2019
Evolução da diversidade do time de desenvolvimento de produto do Gympass

Na Conta Azul conseguimos algo similar entre 2016 e 2018 com um aumento de 6,1 pontos percentuais.

Time de desenvolvimento de produto da Conta Azul em 2016
Time de desenvolvimento de produto da Conta Azul em 2018
Evolução da diversidade do time de desenvolvimento de produto da Conta Azul

Diversidade de perspectivas

A equipe de desenvolvimento de produto é composta por engenheiras de software, designers de experiência do usuário e gestoras de produto. Cada uma tem uma perspectiva diferente do que é um bom produto e essas diferenças são o que ajudam a criar um produto melhor, quando as diferenças são bem resolvidas pela equipe.

Algum tempo atrás, ouvi a seguinte frase:

O fato de duas pessoas discordarem não significa necessariamente que uma delas esteja errada.

Isso realmente me fez pensar na diversidade de perspectivas. Isso tem a ver com empatia, uma das 7 características essenciais de um gestor de produto. Empatia é a habilidade de alguém de pisar no lugar de outra pessoa para entender suas aspirações, motivações, necessidades e problemas. Qual é o seu contexto? Como ela vê e ouve as coisas? O que a faz entender as coisas nessa perspectiva?

Existe uma ótima ferramenta chamada mapa de empatia, que tem o objetivo de ajudar as equipes a obter uma visão mais profunda de seus clientes.

Mapa de empatia

As pessoas têm diferentes origens, diferentes histórias, diferentes conhecimentos. Devemos reconhecer e respeitar essas diferenças e entender que às vezes não chegaremos a um acordo, mas tudo bem, desde que respeitemos a perspectiva uns dos outros. Talvez possamos criar uma terceira perspectiva a partir das duas diferentes. Talvez possamos decidir experimentar uma delas, ou ambas, e ver e comparar os resultados.

Desde que haja respeito e empatia, a diversidade traz muitos bons resultados para todos.

Resumindo

  • Existem duas razões principais que motivam a construção de times de desenvolvimento de produtos digitais diversos. A primeira é que a diversidade traz novos pontos de vista. A segunda razão é que da mesma forma como o grupo de clientes que usa seu produto é diversa, sua equipe de desenvolvimento de produto também deve ser.
  • As pessoas têm diferentes origens, diferentes histórias, diferentes conhecimentos. Devemos reconhecer e respeitar essas diferenças e entender que às vezes não chegaremos a um acordo, mas tudo bem, desde que respeitemos a perspectiva uns dos outros.
  • Está em nossas mãos tornar o ambiente de desenvolvimento de produtos digitais mais inclusivo. O caminho para isso acontecer é trazer o tema à tona e torná-lo parte das conversas.

Com este capítulo, terminamos de ver o que é cultura e quais são, na minha opinião, os 5 principais valores que toda a empresa deve ter para desenvolver produtos de sucesso:

  • Não desperdice tempo buscando culpados, foque nos aprendizados.
  • Não compare situações de trabalho com guerra, ninguém quer matar ninguém.
  • Lucro e receita são consequência, não deve ser o foco principal.
  • Transparência, a fundação de um time de alta performance.
  • Diversidade, a base dos melhores produtos.

Nos próximos capítulos vamos ver mais dois valores que, com base em minha experiência, são o coração de uma cultura de produto digital.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Transparência, a fundação de um time de alta performance

No capítulo sobre “Dicas de liderança para um gestor de produtos” no meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software falo sobre duas dicas de liderança que um gestor de produtos, ou qualquer líder, deve usar para ajudar seu time a desempenhar melhor:

  • Explicar o contexto: para ter um time mais motivado e engajado, é importante as pessoas saberem por que elas estão fazendo algo. Estabelecer o contexto ajuda muito no engajamento de quem está envolvido com o produto. Eles vão entender a sua importância tanto para a empresa – que é dona do produto – quanto para os seus usuários.
  • Remover impedimentos: é fundamental para que as pessoas do time possam desenvolver o produto. Isso é importante para poder termos aquela gostosa sensação de progresso, de que estamos fazendo algo, construindo algo.

Para podermos explicar o contexto, é fundamental sermos transparentes, explicar os números da empresa, explicar as motivações por trás de cada decisão, incluir o time nas decisões. Eu sempre procuro incluir o time nas decisões e, para poder fazer isso, é muito importante ser transparente sobre o contexto em que a decisão será tomada.

Um exemplo que gosto de dar é a gestão de estrutura de time, sobre a qual vou falar em mais detalhes na parte sobre Ferramentas. Para definir e evoluir a estrutura de time, costumo fazer isso junto com os líderes do meu time. Nós nos reunimos periodicamente – mensalmente ou mais frequente, se necessário – para avaliar a estrutura de time, se estão faltando pessoas e se temos orçamento para trazê-las. Esse tipo de conversa só pode ser feito se eu mostrar claramente qual o orçamento disponível. Ou seja, é preciso ter transparência.

A transparência na gestão das empresas parece algo moderno, mas existe há algumas décadas. Vou contar sobre dois casos interessantes da década de 1980, um em uma empresa americana Springfield ReManufacturing Corp (SRC) e o outro em uma empresa brasileira chamada Semco, ambas indústrias. Portanto, a vanguarda da gestão participativa.

Gestão do livro aberto

Da mesma forma que existe o conceito de open source, ou código aberto, para desenvolvimento e distribuição de software em conjunto com seu código-fonte, existe um conceito em administração chamado de open-book management ou gestão do livro aberto. Esse conceito foi criado por Jack Stack, que escreveu o livro The Great Game of Business: The Only Sensible Way to Run a Company sobre como aplicou esse conceito na Springfield ReManufacturing Corp (SRC), um fabricante de equipamentos em Springfield, Missouri.

O conceito é simples. Os relatórios financeiros da empresa devem ficar abertos para todos os funcionários para que sirvam de insumo para tomadas de decisão mais conscientes em seu dia a dia. As regras básicas são:

  • Dê aos funcionários o treinamento necessário para que eles possam entender as informações financeiras;
  • Dê aos funcionários toda informação financeira;
  • Dê aos funcionários a responsabilidade pelos números que estão sob seu controle;
  • Dê aos funcionários participação financeira nos resultados da empresa.

Obviamente não dá para praticar open-book management de uma hora para outra, mas esse conceito faz bastante sentido para qualquer empresa. Em sua forma mais simples, trata-se de uma forma de administrar uma empresa que faz com que todos se concentrem em ajudar o negócio a ter sucesso. As metas e responsabilidades dos funcionários estão diretamente ligadas ao sucesso da empresa. Jack Stack ensina a todos os funcionários o que é fundamental para o sucesso e como eles podem fazer a diferença, tanto individualmente quanto sendo parte de uma equipe. Os funcionários sabem e compreendem como cada um contribui para o desempenho financeiro da empresa, de forma a entenderem verdadeiramente o funcionamento do negócio.

A SRC foi criada em 1983 quando 13 funcionários da International Harvester compraram uma parte daquela empresa que reconstruía motores de caminhão, com $100.000 de seu próprio dinheiro e $8,9 milhões em empréstimos, com o objetivo de salvar 119 empregos. O preço das ações em 1983 era de $0,10 e aumentou em 1988 para $13 por ação. Em 2015, a ação valia mais de $199.

Clóvis Bojikian, ex-diretor de RH da Semco, sobre como implementar a democracia organizacional

Em agosto de 2008, tive a oportunidade de conhecer e conversar com Clóvis Bojikian, diretor de RH da Semco desde o início dos anos 1980. Ele trabalhou com Ricardo Semler na implementação da estrutura de gestão participativa que fez da Semco uma das empresas brasileiras de maior sucesso no mundo. Vou contar aqui resumidamente o que Clóvis contou:

Definindo o contexto – Semco

Clóvis começou contando um pouco sobre a Semco, uma empresa de sucesso há 25 anos. Seu principal produto eram as bombas hidráulicas navais. A principal preocupação era a diversificação do portfólio de produtos uma vez que a indústria de construção naval estava dificuldades. A diversificação estava sendo feita por meio de:

  • novas licenças: para produzir e comercializar outros produtos como misturadores e agitadores;
  • aquisição de empresas brasileiras que eram operadas por multinacionais: geladeiras e máquinas de limpeza são exemplos;
  • joint ventures: foi assim que a Semco entrou no negócio de serviços. Manutenção industrial, conservação de edifícios, inventários são alguns exemplos.

Com essa diversificação, em 20 anos, a empresa cresceu de 300 para 4.000 funcionários.

DefiniNDO contexto – Clóvis Bojikian

Clóvis graduou-se em pedagogia. Algum tempo depois, ele estudou administração de empresas. Ele trabalhou pela primeira vez como diretor do “Colégio de Aplicação da USP”, uma escola experimental muito famosa nos anos 60 onde novos métodos de ensino foram experimentados, uma das escolas mais avançadas de sua época. Saiu devido a algumas pressões durante a ditadura militar iniciada em 1964. Em seguida, ingressou na Ford, na época com 4.000 funcionários, como gerente de RH. A Ford estava adquirindo a Willys, uma montadora de automóveis com 16.000 funcionários. Havia pouca liberdade para o profissional de RH trabalhar (“em uma equipe vencedora ninguém quer fazer mudanças”), então ele decidiu sair e se juntar a Bombas Hidráulicas KSB, onde pôde experimentar algumas ideias que tinha. Mas devido a uma mudança de CEO, a liberdade diminuiu. Naquela época, Clóvis foi conversar com Ricardo Semler, foram “muitas horas de conversa”, como Clóvis destacou. Ricardo tinha apenas 22 anos na época e acabava de assumir a presidência da Semco. Ele estava procurando um profissional de RH que pudesse ajudá-lo a implementar os conceitos de gestão participativa que ele estava pensando. Clóvis, 48 anos, adorou essa conversa e a sinergia com Ricardo e decidiu assumir a responsabilidade de dirigir o RH da Semco.

As raízes da gestão participativa

A Semco é uma fábrica e, como qualquer outra fábrica, os trabalhadores não gostavam de ir trabalhar. Toda semana eles contavam as horas até o próximo fim de semana. Esse foi o principal desafio de Clóvis: “Como motivamos as pessoas?” Algumas constatações de Clóvis:

  • Ninguém motiva ninguém.
  • A motivação vem da pessoa.
  • Precisamos criar condições para que as pessoas se sintam motivadas.
  • As pessoas que demonstraram mais interesse pelo trabalho são as que “estão no comando”.

E sua conclusão, com base nessas constatações, era de que:

As pessoas mais motivadas são os que mais participam.

É isso é fácil de entender. As pessoas que “estão no comando” são as pessoas que mais participam dos negócios tomando decisões e acompanhando os resultados de suas decisões. Mais participação significa mais interesse e mais motivação.

Exercitando a participação

Para exercer a participação, Clóvis recomenda começar com situações simples e não essenciais ao negócio. Ele deu dois exemplos da Semco:

Restaurante dos funcionários: os funcionários normalmente reclamavam do restaurante para o pessoal de RH. Essa reclamação era documentada e analisada pelo RH, mas nem sempre uma ação era tomada. Um dia, o RH resolveu retribuir a reclamação com uma pergunta: “O que você faria para mudar isso?”. Os reclamantes ficaram deslumbrados e, por recomendação do pessoal de RH, formaram uma comissão para estudar o que poderia ser feito melhor. A comissão acabou tendo ideias muito boas e voltou ao pessoal de RH, que perguntou: “Vocês conversaram com o pessoal do restaurante sobre suas sugestões?”. Eles foram ao restaurante, discutiram as sugestões e novamente voltaram para o pessoal de RH, que apenas disse: “Ok, siga em frente e implemente suas sugestões”. Desde então, o restaurante passou a ser administrado pelo próprio restaurante, com apoio da comissão de funcionários, sem interferência do pessoal de RH.

Uniforme de funcionários: o estoque de uniformes de funcionários estava acabando e uma nova compra se fazia necessária. Em vez de apenas fazer um pedido com o fornecedor de mais uniformes, eles decidiram fazer uma eleição com os funcionários para que decidissem a cor do uniforme. Lembrando, estamos falando da década de 1980, eleições não era algo muito comum nessa época. Alguns diretores não gostaram da ideia da eleição porque levaria tempo e provavelmente seria uma bagunça, mas o fato de que a democracia estava sendo exercida em uma situação não relacionada ao negócio principal deu início ao experimento. Duas cores tiveram muitos votos, e os próprios funcionários propuseram fazer uma segunda eleição, apenas com essas duas cores. Finalmente, uma foi escolhida.

Traci Fenton, da WorldBlu, uma organização que fomenta a gestão participativa, comentou certa vez que esse é o conceito de distribuição de liderança, distribuição de tomada de decisão de uma forma que faça sentido. Esse processo de tomada de decisão compartilhada pode ser mais lento. Mas a execução é muito mais rápida. E a razão disso é que as pessoas participaram da decisão. Elas têm propriedade nessa decisão. Elas querem ver o sucesso. E é isso que torna a execução muito mais rápida. E é aí que a maioria das empresas falha, na execução.

A próxima etapa – mais perto do core

Algum tempo depois, os funcionários passaram a definir suas próprias metas de produção, normalmente superiores às definidas anteriormente pelos executivos.

Isso mostra como, quando começamos a exercer a tomada de decisão participativa com questões não relacionadas ao negócio principal, é fácil e natural começar a nos mover para decisões mais perto do core do negócio.

No Brasil, há feriados às terças, quartas e quintas-feiras que as pessoas gostam de conectar ao fim de semana para terem um feriado mais longo. A famosa “emenda de feriado”. Normalmente é decisão da empresa definir quem vai emendar o feriado e quem vai trabalhar nesse feriado para compensar uma emenda de um feriado anterior. Após a experiência do processo de tomada de decisão participativa anterior, os próprios funcionários passaram a decidir e controlar suas emendas de feriado.

O próximo passo na Semco foi o desenho das novas funções, responsabilidades e plano de remuneração. Foi totalmente escrito pelos funcionários com a facilitação e ajuda do pessoal de RH. Quando o plano foi finalmente implementado, não apenas todos sabiam os salários dos outros, mas todos entenderam por que esses salários eram dessa forma e estavam totalmente de acordo com isso.

Outro exemplo interessante de tomada de decisão participativa foi a contratação de um novo gerente. Em vez de ser entrevistado apenas pelo pessoal de RH e pelo diretor, o gerente também foi entrevistado por outros gerentes e pela equipe que lideraria. O gerente escolhido teve um ótimo começo, pois era conhecido não apenas pelo seu diretor, mas também por todas as pessoas com quem trabalharia. A Semco também fez avaliações 360º para que os funcionários analisassem seus líderes.

Para permitir que os funcionários entendam mais de todo o negócio, eles decidiram mudar das linhas de montagem para pequenas células responsáveis por toda a peça. Nesse ponto, a Semco considerava que tinha uma estrutura de gestão participativa e decidiu passar para a próxima etapa.

A etapa final – uma fatia dos resultados

E a Semco estava pronta para a etapa final, a participação nos lucros. Os donos da Semco decidiram dar vinte e poucos por cento do lucro aos funcionários e todo o resto foi decidido de forma participativa. Os funcionários criaram um conjunto de princípios. Um dos princípios básicos diz mais ou menos assim: “Não basta ser transparente, é preciso educar”. A ideia é que não apenas todos os números da empresa sejam abertos a todos os funcionários, mas todos os funcionários devem ser treinados para serem capazes de ler esses números. A demonstração de resultados, o P&L e o fluxo de caixa requerem alguns conhecimentos para serem lidos e compreendidos. Esta é a base do open book management que comentei anteriormente.

Todos os meses eles fazem uma reunião na Semco para discutir os resultados e algumas situações muito interessantes aconteceram durante essas reuniões. Um dia, um funcionário questionou por que os executivos sempre tinham que se hospedar em hotéis cinco estrelas. Não seria possível se hospedar em hotéis quatro estrelas de vez em quando? Em outra revisão de relatório mensal, outro funcionário notou que a Semco gastou dinheiro pintando a fábrica em um mês em que os funcionários tiveram algum tempo livre e eles próprios poderiam ter pintado a fábrica.

Nesse ponto, a Semco implementou horários e locais de trabalho flexíveis, permitindo até que o trabalho fosse feito em casa. Lembro mais uma vez que isso aconteceu na década de 1980, mais de 30 anos atrás. Uma vez que todos têm interesse no sucesso da empresa, é possível implementar essa política. Claro, deve ser adotada onde fizer sentido. Por exemplo, não faz sentido para um recepcionista trabalhar em casa. Mas se houver dois recepcionistas para cobrir um determinado período de tempo, eles podem e devem decidir entre si quando cada um deve estar presente.

Gestão participativa em uma crise

A certa altura, Clóvis contou sobre uma crise na Semco, nos anos do presidente Collor (1990 – 92), em que o mercado foi abruptamente aberto para empresas estrangeiras. Isso impactou a Semco e os obrigou a fazer um downsize, o que é sempre doloroso. Clóvis discutiu com os funcionários como queriam fazer o downsize e os funcionários disseram que iriam fornecer uma lista de pessoas que não deveriam ser despedidas nem por idade nem por questões pessoais e disseram aos gestores que, preservando as pessoas dessa lista, os gestores poderiam selecionar quem deveria ser dispensado com base em critérios técnicos. Duas coisas que podemos ver neste episódio:

  • Mesmo em uma crise, não há necessidade de abandonar as inovações de gestão, como gestão participativa. É um bom teste para a inovação em gestão, para ver se ela é capaz de lidar com a crise em questão. Nesse caso, a gestão participativa conseguiu fazer frente à necessidade de dispensas por conta de uma crise de mercado.
  • Existem muitos números entre 0 e 1, ou seja, não é uma questão de delegação ou não delegação. Existem opções intermediárias, existem decisões que os trabalhadores estão dispostos a enfrentar e outras que eles não querem enfrentar e cada problema exigirá uma combinação diferente.

Concluindo a conversa

Ao final da conversa, Clóvis comentou que basta coragem para implantar a gestão participativa em uma empresa. Erros vão acontecer e devemos aprender com eles, mas o resultado final, uma empresa cheia de funcionários felizes em ir trabalhar todos os dias, vale todos os riscos.

Pedi a ele que nos contasse sobre um erro ou um momento em que pensaram que talvez todo esse processo de tomada de decisão participativa não pudesse ser uma boa ideia.

Ele nos contou uma história muito interessante sobre o sistema de relógio de ponto da folha de pagamento. Todos os funcionários tinham que fazer check-in na chegada ao trabalho, check-out e check-in durante o almoço e check-out novamente no final do expediente. Mas era um controle do que é regular, e o que uma empresa precisa mesmo saber é o que é irregular (horas extras, atrasos, faltas). O RH optou por alterar o sistema de relógio de ponto para que o funcionário apenas informasse horas extras, atrasos e faltas. E o mais importante, o funcionário deveria informar diretamente no sistema. Ela não precisava explicar nada ao chefe. No primeiro mês tudo correu bem, mas no segundo mês houve fraudes, as pessoas não informavam as irregularidades do horário de trabalho corretamente. Eles estavam aproveitando que ninguém estava verificando as informações. Muito preocupados, o pessoal de RH discutiu o assunto com um grupo de funcionários encarregados desse novo sistema. A resposta foi: “Deixe conosco!” Após essa conversa, o sistema funcionou muito bem sem nenhuma fraude relatada ou percebida. Clóvis comentou que os colaboradores perceberam que “quanto mais liberdade temos, mais responsáveis temos que ser” e agiram de acordo, para manter sua liberdade.

Minha visão sobre a importância da transparência na liderança

Sem transparência não é possível definir o contexto. Em minhas experiências, sempre busquei aumentar a transparência das informações sobre a empresa (como estão os números, quais são os processos) e a participação das pessoas de meus times no processo decisório.

Ao buscar aumentar a transparência das informações sobre a empresa, ajudando as pessoas a entenderem os números bem como os processos da empresa, quero dar ao time todas as informações necessárias para que elas possam conhecer o contexto onde estão inseridas e assim entender a motivação e o impacto de seu trabalho. É muito difícil alguém fazer um trabalho de qualidade sem ter clareza sobre por que aquele trabalho precisa ser feito e qual o impacto que ele terá na empresa, em seus funcionários e seus clientes.

Quando busco aumentar participação das pessoas de meus times no processo decisório, eu o faço por dois motivos. Primeiro, acredito que todas as pessoas têm o direito de tomar decisões sobre seu próprio trabalho, e por isso a transparência das informações sobre a empresa é tão importante. Sem essas informações é difícil para qualquer um tomar boas decisões. A segunda razão é que, quando as pessoas estão envolvidas no processo decisório, seu comprometimento com o resultado é muito maior. Consequentemente, as chances de obter bons resultados aumentam consideravelmente quando as pessoas participam do processo de tomada de decisão.

Resumindo

  • Toda líder, para ajudar seu time a desempenhar melhor, precisa explicar o contexto e remover impedimentos.
  • Para podermos explicar o contexto, é fundamental sermos transparentes, explicar os números da empresa, explicar as motivações por trás de cada decisão, incluir o time nas decisões.
  • A transparência na gestão das empresas parece algo moderno, mas existe há algumas décadas. Dois exemplos interessantes vêm da década de 1980. Um em uma empresa americana chamada Springfield ReManufacturing Corp (SRC), que criou o conceito de gestão do livro aberto. O outro em uma empresa brasileira chamada Semco, do Ricardo Semler, onde Clóvis Bojikian, seu diretor de RH, implementou a gestão participativa. Ambas são da década de 1980 e são indústrias, ou seja, a vanguarda da gestão participativa.
  • Com transparência, é possível dar às pessoas as informações necessárias para que elas entendam o contexto e motivação do trabalho que estão fazendo e consigam tomar melhores decisões sobre esse trabalho.

No próximo capítulo vamos entender por que diversidade é tão importante para o sucesso do time de desenvolvimento de produto.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Cultura e valores

Após falar dos meus princípios de liderança, vou falar de outro tema fundamental para uma head de produto, cultura organizacional e valores. São 5 os valores que considero críticos para o sucesso do produto:

  • Não desperdice tempo buscando culpados, foque nos aprendizados.
  • Não compare situações de trabalho com guerra, ninguém quer matar ninguém.
  • Lucro e receita são consequência, não devem ser o foco principal.
  • Transparência, a fundação de um time de alta performance.
  • Diversidade, a base dos melhores produtos.

Vamos começar definindo cultura.

O que é cultura?

A palavra cultura vem do latim cultus, que significa “cuidado”, e do francês colere, que significa “cultivar”. Edgar Schein, professor da escola de administração de empresas do MIT, foi uma das primeiras pessoas a falar sobre cultura organizacional nos anos 1970.

Segundo ele, cada empresa tinha sua própria personalidade, e sua própria forma de agir e reagir às situações; forma esta que é passada de funcionário para funcionário desde os fundadores da empresa.

Cultura Organizacional

Cultura é um conjunto de premissas que foram aprendidas e compartilhadas por um grupo de pessoas enquanto resolviam problemas de adaptação externa e de integração interna. Esse conjunto de premissas funciona bem o suficiente para ser considerado válido e, consequentemente, ser ensinado aos novos membros do grupo como a forma correta de perceber, pensar e sentir em relação a esses problemas.

Fonte: SCHEIN, Edgar. Organizational Culture and Leadership. Jossey-Bass, 2010

A cultura vem dos fundadores da empresa. Os fundadores têm sua própria cultura e é natural que a imprimam na organização que estão criando. Em função disso, é muito comum se pensar que ela é algo que emerge em uma organização. Schein alerta que isso é um engano. Culturas podem e devem ser planejadas e é papel do head de produto ajudar a planejar e promover a cultura da empresa.

Por esse motivo, estou compartilhando estes cinco valores que ao meu ver são críticos para o desenvolvimento de produtos digitais de sucesso.

Não desperdice tempo buscando culpados, foque nos aprendizados.

Quando erros acontecem é comum as pessoas tentarem buscar quem foi o responsável pelo erro. Isso pode acabar gerando uma cultura do medo de errar e, consequentemente, de querer esconder os erros, especialmente se houver alguma punição.

Os times que não só reconhecem seus erros como os usam como fonte de aprendizado e melhoria são os times com melhor performance. No livro The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition, Steven J. Spear, professor do MIT, explica que um time de alta velocidade tem quatro habilidades:

  • Estar preparado para capturar conhecimento e encontrar problemas em sua operação.
  • Entender e resolver esses problemas para construir novos conhecimentos.
  • Compartilhar o novo conhecimento com toda a organização.
  • Liderar para desenvolver habilidades 1, 2 e 3.

Segundo o prof. Spear, esse é o segredo por trás do sucesso da Toyota por tantos anos. Alcoa é outro bom exemplo. Tinha uma taxa de incidentes de trabalho que girava em torno de 2% ao ano. Em uma equipe de 40 mil funcionários, isso significa 800 funcionários por ano com algum incidente de trabalho, mais de 2 por dia. Para combater esse problema, eles implementaram uma política de tolerância zero a erros. Antes de implementar essa política, os erros eram vistos como parte do trabalho. Agora os funcionários são incentivados a relatar erros de operação em 24 horas, propor soluções em 48 horas e contar a solução encontrada para seus colegas para garantir que o conhecimento se espalhe por toda a organização. Isso fez com que o risco de incidentes caísse de 2% para 0,07% ao ano! Essa redução na taxa de incidentes significava que menos de 30 funcionários por ano tinham algum problema de incidente de trabalho depois que a política de zero tolerância a erro foi implementada e a Alcoa obteve um aumento de produtividade e qualidade semelhante ao da Toyota.

No livro Smarter Faster Better: The Transformative Power of Real Productivity, Charles Duhigg, autor e jornalista premiado com o prêmio Pulitzer, compara a performance de dois times de UTI, um deles que costuma se reunir diariamente para discutir problemas e como evitá-los e o outro que costuma punir funcionários que cometem erros. O time que discute e aprende com os erros tem performance melhor, o que, para um time de UTI, significa menos mortes e mais pacientes recuperados.

Esse tipo de ambiente que aprende com os erros é conhecido como ambiente psicologicamente seguro, ou seja, em que as pessoas do time podem fazer seu trabalho sem medo de consequências negativas. Como head de produto é seu papel criar um ambiente assim para seu time e para toda a empresa.

Não compare situações de trabalho com guerra, ninguém quer matar ninguém.

Vejo com alguma frequência o uso de analogias de guerra no dia a dia das empresas. Vamos derrotar esse competidor. Vamos criar esse war room para tratar desse problema. Isso é uma guerra, temos que vencer nossos inimigos. Existe um livro chamado A arte da guerra, atribuído um general chinês chamado Sun Tzu que viveu entre os anos 550 e 500 a.C., que é considerado um dos 10 livros de negócios mais influentes de todos os tempos. Esse livro tem frases como “Diante de uma larga frente de batalha, procure o ponto mais fraco e, ali, ataque com a sua maior força” e “A suprema arte da guerra é derrotar o inimigo sem lutar”.

Apesar de eu entender a imagem que se quer criar fazendo essa comparação de guerra com negócios, para gerar uma motivação maior no time de um inimigo comum a ser derrotado, fico profundamente incomodado com essa analogia. Guerra é algo muito feio e triste. Experimente escrever guerra no Google e clique na opção “Imagens”. Você verá muitas fotos de dor e de sofrimento. Em uma guerra, para alguém ganhar, alguém precisa perder.

No meu entendimento, negócios é oposto disso. Os negócios mais prósperos são aqueles que impactam positivamente todos à sua volta, funcionários, clientes, fornecedores, sociedade e até mesmo os competidores. Um bom competidor é aquele que o motiva a melhorar. Os competidores tiram as empresas da zona de conforto. Se não fossem por eles, as empresas evoluiriam de forma bem mais lenta. Além disso, competidores podem e devem se juntar em associações para irem atrás de objetivos comuns.

Lucro e receita são consequência, não deve ser o foco principal.

Sim, o objetivo de toda empresa é crescer e dar lucro, mas esse não deve ser o foco. O propósito principal de uma empresa deve ser ajudar de alguma forma seus clientes, e a receita e o lucro devem ser usados como métricas que indicam se o propósito está sendo cumprido. Mas não devem ser as únicas métricas, uma vez que sempre há o risco de se obter a má receita, o que pode acontecer quando mantemos o foco principal em ter mais receita.

Imagine uma situação onde você é assinante de um serviço com pagamento mensal e, por algum motivo, você precise cancelar sua assinatura. Ao tentar fazer isso, descobre que o processo de cancelamento é supercomplicado. Isso certamente vai deixá-la insatisfeita. A mesma coisa acontece quando você pega uma água no frigobar de um quarto de hotel e descobre que a garrafa de água custa 3 vezes mais do que em um supermercado. São situações que até geram receita para a empresa, mas é uma má receita, que deixa os clientes insatisfeitos e que provavelmente fará esses clientes não retornarem e até mesmo falar mal de sua empresa quando tiverem a oportunidade.

Por este motivo gosto de fazer uma analogia entre receita e lucro com comida:

Receita é como comida, é necessária, é vital para a saúde e para o sucesso de uma empresa, mas não é propósito da vida. Você não acorda de manhã e a primeira coisa que pensa é “como eu posso conseguir mais comida?”.

Contudo, tanto uma empresa quanto uma pessoa devem estar sempre atentas à qualidade da comida que está ingerindo, para ter certeza de que ela não vai causar nenhum mal à saúde.

Resumindo

  • Cultura é a forma como um grupo de pessoas reage às situações do dia a dia. É papel do head de produto ajudar no desenho e na promoção da cultura da empresa para garantir um ambiente propício para o desenvolvimento de produtos de sucesso.
  • Tem cinco valores que acredito serem essenciais para ajudar a criar uma cultura que propicie o desenvolvimento de produtos de sucesso. Neste capítulo falei de 3 desses valores: não desperdice tempo buscando culpados, foque nos aprendizados. Não compare situações de trabalho com guerra, ninguém quer matar ninguém. Lucro e receita são consequência, não deve ser o foco principal.

No próximo capítulo vamos conversar sobre a importância da transparência na criação de times de alta performance.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Como e quando delegar

Delegar é o ato de confiar uma tarefa e/ou uma responsabilidade a alguém, normalmente com menos senioridade do que a pessoa que está executando o ato de delegar. A liderança é um ato contínuo de delegação de tarefas e de responsabilidades. Parece um ato bastante simples mas tem vários aspectos importantes a serem considerados para aumentar as chances de sucesso.

Jurgen Appelo, autor do já mencionado livro Management 3.0: Leading Agile Developers, Developing Agile Leaders, comenta que delegar não é uma decisão binária em que você delega ou não delega. Existem outros níveis de delegação entre esses dois extremos e cada um desses outros níveis deve ser usado dependendo do contexto, ou seja, do problema a ser resolvido e de quem vai trabalhar nele. Segundo ele, são sete níveis:

  • Dizer: você toma decisões e as anuncia ao seu time. Na verdade, isso não é delegação. (=
  • Vender: você toma decisões, mas tenta “vender” sua ideia para sua equipe.
  • Consultar: você convida seu time para comentar e pondera suas contribuições.
  • Concordar: você convida seu time a participar de uma discussão e a chegar a um consenso como um grupo. Sua voz é igual às outras.
  • Aconselhar: você tenta influenciar o seu time dando-lhes conselhos, mas deixa que eles decidam o que fazer com sua opinião.
  • Perguntar: você deixa o time decidir. E depois você pergunta sobre suas motivações, ou pede que eles o mantenham ativamente informado.
  • Delegar: você deixa inteiramente para o time lidar com o assunto, e você nem mesmo precisa saber quais decisões eles tomam.

Confesso que no meu dia a dia não penso sobre que tipo de delegação estou fazendo em cada situação, é algo mais intuitivo do que pensado, mas é bom conhecer e relembrar essas diferentes formas de delegação. Tenho a impressão que entre “dizer” e “delegar” há mais do que 5 opções. Navegamos entre essas opções de forma fluida de acordo com a senioridade do time, a experiência específica do time com o assunto em questão e o quanto o tema em questão implica em riscos.

O conceito de delegação anda de mãos dadas com o conceito de microgestão:

Microgestão

Microgestão é o estilo de gestão em que o gerente observa ou controla de perto o trabalho de seus subordinados ou funcionários. A microgestão geralmente possui uma conotação negativa.

Fonte: https://pt.wikipedia.org/wiki/Microger%C3%AAncia

A microgestão mostra a incapacidade de delegação do líder. Normalmente há duas razões para um líder microgerenciar seu time:

  • Insegurança: o líder é inseguro, preocupado em fazer tudo certo, por isso ele quer acompanhar cada detalhe de tudo o que está sendo feito. Em alguns (muitos) casos, esse líder fará o trabalho de uma pessoa de seu time para garantir que esteja sendo feito “do jeito certo”. Esse tipo de líder costuma criar muitas regras e procedimentos para garantir que as coisas estejam sendo feitas do jeito que ele entende como certo.
  • Personalidade: é da personalidade do líder ter prazer em ver as pessoas sofrendo sob pressão. Esse líder tende a ser abusivo no dia a dia com a equipe. Ele não fará o trabalho de ninguém, mas acompanhará de perto todos os detalhes para vê-los desconfortáveis sob esse constante escrutínio.

O mais comum é encontrar líderes com insegurança, normalmente pessoas que estão liderando pela primeira vez, mas que eventualmente acabam entendendo seu papel e exercendo a delegação. Já líderes que microgerenciam devido à sua personalidade são mais raros e dificilmente vão mudar.

Pessoas que estão em um time que está sendo microgerenciado tendem a rapidamente se desengajar. Uma vez que estão fazendo as coisas do jeito do gestor, não se sentem responsáveis pelo resultado obtido, seja o resultado bom ou ruim. Se o resultado for bom, o líder provavelmente vai atribuir o sucesso ao seu jeito de fazer as coisas. Se der errado, a pessoa que fez o trabalho não se sentirá responsável, pois “apenas seguiu ordens”.

Maneiras de fazer

Uma das maiores barreiras para a delegação é a certeza que o líder tem de que seu jeito de fazer as coisas é o correto. Quando ele era um contribuidor individual ele fazia as coisas desse jeito e o resultado vinha. Tanto é que ele foi promovido a gestor por fazer as coisas daquele jeito. Então, o que ele entende que tem que fazer como gestor é garantir que todas as pessoas do seu time façam as coisas do jeito que ele faz. Nesse momento a necessidade de microgestão desse líder aparece.

Um líder deve sempre se focar no resultado esperado. A forma como esse resultado é atingido é menos importante do que obter o resultado. Se uma pessoa de sua equipe faz as coisas de forma diferente do que você costuma fazer, isso não significa que a forma como ela faz está errada (claro, desde que não seja uma forma ilícita e não prejudique as pessoas). É só uma forma diferente de fazer as coisas. Talvez até uma forma mais eficiente. O líder precisa respeitar essa diversidade de maneiras de se fazer as coisas e apenas apresentar a sua forma de fazer quando notar que a pessoa não está conseguindo evoluir sozinha.

Oportunidade de aprendizado

Toda vez que delegamos algo para alguém fazer, caso seja a primeira vez que aquela pessoa está fazendo, será uma oportunidade de aprendizado. Por esse motivo, é muito provável que a pessoa cometa alguns erros e aqui entra um dos trade-offs mais difíceis de um líder. Quanto de erro é aceitável? Isso depende muito de cada situação, cabe ao líder entender se os erros são aceitáveis para permitir o aprendizado, ou se dada a criticidade do trabalho a ser feito, erros devem ser minimizados. Devemos sempre criar um ambiente propício ao aprendizado a partir dos erros, pois esse será o aprendizado mais eficaz. É o que busco fazer com os times que lidero.

Resumindo

  • Delegar é o ato de confiar uma tarefa e/ou uma responsabilidade a alguém. A liderança é um ato contínuo de delegação de tarefas e de responsabilidades.
  • Entre não delegar e delegar existem vários níveis de delegação que são usados de acordo com o contexto, ou seja, do problema a ser resolvido e quem estará trabalhando no problema.
  • O conceito de delegação anda de mãos dados com o conceito de microgestão, estilo de gestão em que o gerente observa ou controla de perto o trabalho de seus subordinados ou funcionários.
  • Existem diferentes maneiras de se fazer as coisas para se atingir o mesmo resultado. Líderes novos costumam achar que só o seu jeito de fazer é o certo.
  • Erros são oportunidades incríveis de aprendizado. Daí a importância em tolerar erros no trabalho.

Pronto, com este capítulo concluímos a parte sobre meus princípios pessoais de liderança (pessoas: a prioridade nº 1, sempre; liderar é como ser um médico; liderando sob pressão; mentoria é uma via de mão dupla; e como e quando delegar). Nos próximos capítulos, veremos o que é cultura e quais são os valores que acredito serem obrigatórios para criar produtos digitais de sucesso.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Mentoria é uma via de mão dupla

A mentoria é uma das responsabilidades mais importantes de um head de produto: ajudar sua equipe a se desenvolver. Como já disse, entre 10% a 40% do tempo do head de produto deve ser focado em ajudar as pessoas de sua equipe a se desenvolverem. Quem me conhece sabe que gosto de termos claramente definidos, então aqui está a definição de mentoria da Wikipedia:

“A mentoria é um processo de transmissão informal de conhecimento, capital social e apoio psicossocial percebido pelo receptor como relevante para o trabalho, carreira ou desenvolvimento profissional; mentoria envolve comunicação informal, geralmente face a face e durante um período, entre uma pessoa que é percebida como tendo maior conhecimento, sabedoria ou experiência relevante (a mentora) e uma pessoa que é percebida como tendo menos (a mentorada)”.

A partir dessa definição, fica clara a natureza unidirecional da mentoria, ou seja, o conhecimento flui da pessoa “mentora” para a “mentorada”.

Recebi e dei orientação durante toda a minha carreira. Mesmo quando era estudante, dava e recebia orientação. Eu acho que alguém recebe orientação desde que nasce. Desde o início da minha carreira, tive a oportunidade de dar orientação às pessoas que lidero e, mais recentemente, tenho sido convidado a orientar empresários e gestores de produto para ajudá-los nas próximas etapas de seus empreendimentos e de suas carreiras. Fico muito feliz em saber que posso ajudar alguém compartilhando minha experiência.

Uma via de mão dupla

No entanto, minha experiência como mentor me mostrou que a definição da Wikipedia está incompleta. Wikipedia define mentoria como transmissão de conhecimento. Meu entendimento é que a mentoria é mais do que uma transmissão de conhecimento. É uma troca de conhecimento. Mesmo considerando que uma das pessoas envolvidas no processo de mentoria é mais experiente em determinado aspecto, tópico ou área, a outra pessoa pode ter experiência e conhecimento em outro aspecto, tópico ou área que pode trazer novos insights. Ou a outra pessoa pode usar sua novidade no tema em que está recebendo mentoria para trazer uma nova perspectiva que o mentor não percebeu.

Portanto, da próxima vez que você estiver em uma situação de mentoria, especialmente se estiver na posição de mentor, pense nisso como uma troca de conhecimento, capital social e apoio psicossocial relevante, útil e valioso tanto para o mentorado quanto para o mentor. Tenho a impressão de que você vai gostar ainda mais de sua próxima sessão de mentoria.

Resumindo

  • Mentoria é um dos papéis mais importantes de um head de produto. É através da mentoria que um head de produtos ajuda seu time a se desenvolver.
  • Mentoria é uma via de mão dupla. A pessoa no papel de mentora deve estar aberta a novos aprendizados vindos de suas sessões de mentoria com sua mentorada.

No próximo capítulo vamos entender um pouco mais sobre cultura, quais valores são essenciais para uma empresa ter produtos de sucesso e o papel do head de produto na criação e manutenção da cultura da empresa.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros: