Um dos principais desafios de expansão para uma empresa é desenvolver as equipes de produtos e engenharia. Parece que as equipes de tecnologia nunca são suficientemente rápidas: o produto fica cheio de recursos a serem desenvolvidos, e os vice-presidentes da empresa – de vendas, marketing, suporte ao cliente, operações… – querem sempre levar seus próprios pedidos ao topo da lista. Isso cria um desafio difícil para o CEO e um muito difícil para o gerente de produtos.
A princípio, parece um problema de produtividade: como podemos fazer com que os desenvolvedores entreguem mais rapidamente? Após uma inspeção mais detalhada, muitas vezes parece que:
- Os desenvolvedores gastam uma quantidade excessiva de tempo lidando com especificações incompletas ou incoerentes, devido ao fato de que as necessidades do usuário não são totalmente compreendidas.
- As mudanças são frequentemente solicitadas durante o desenvolvimento, aumentando o custo de novas evoluções e desperdiçando um precioso tempo de desenvolvimento.
- As evoluções geram novos problemas para os usuários dentro e fora da empresa, porque detalhes importantes eram deixados de lado quando os recursos eram especificados ou porque a equipe corria para entregar recursos e gerava defeitos. Isso, por sua vez, cria a necessidade de novos “recursos” para corrigir a situação.
- Apesar de todo o esforço, os resultados comerciais são decepcionantes.
Na verdade, o problema não é a entrega ou a organização de pessoas e tarefas para obter um resultado com mais eficiência. É uma questão de descoberta: explorar e definir qual deve ser o produto para fazer uma aposta menos arriscada.
O que o lean nos ensina sobre descoberta?
ENTENDENDO O VALOR: UMA QUESTÃO DE TRABALHO EM EQUIPE
Por uma perspectiva lean, descoberta é, primeiramente, aprender como o produto cria valor para o cliente e, em segundo lugar, como projetar e construir o produto para que não adicionemos o custo de nossos desperdícios ao cliente.
O valor e o desperdício precisam ser considerados em toda a cadeia de valor, e não apenas no produto tecnológico essencial. Como consequência, a descoberta abrange todo o produto, desde a experiência do cliente até os processos internos da empresa.
Vamos usar um serviço de compartilhamento de carros como exemplo. O produto principal talvez seja o aplicativo usado para pedir uma carona ou o sistema que aloca serviços aos motoristas. Por outro lado, o produto é muito maior e abrange a gama inteira de sistemas e serviços que formam a experiência do usuário. Nesse caso, um elemento importante de desempenho pela perspectiva do cliente é o tempo de espera por um carro. Isso depende do algoritmo de alocação, mas também do número de motoristas disponíveis no momento. Isso significa que, para projetar um serviço que cumpra totalmente sua promessa aos usuários, você também deve levar em consideração toda a experiência do motorista e persuadir milhares deles a usar a plataforma. Isso, por sua vez, cria a necessidade de um serviço de integração escalável para os motoristas, assim como muitas pessoas responsáveis por lidar com os problemas diários.
Para que o produto seja um sucesso, você precisa projetar um conjunto completo de produtos e processos. Como consequência, a equipe de produto deve incluir representantes de todos os departamentos da empresa: produto, tecnologia, marketing, vendas, operações, jurídico etc.
É difícil conseguir que todas essas pessoas trabalhem juntas em direção a um objetivo comum: elas geralmente têm prioridades diferentes e geralmente não enxergam o impacto de suas decisões locais no “todo”. Não há receita a seguir para alinhar todos eles. Tradicionalmente, isso é gerenciado como uma questão organizacional, tratada em termos de papéis e processos, mas o lean o enquadra como um exercício de aprendizagem: “Quem precisa aprender o que para que o produto seja um sucesso?”. Mas como você consegue que um grupo tão diverso, buscando diferentes agendas, aprenda junto e siga na mesma direção?
O ENGENHEIRO-CHEFE
A Toyota soluciona esse problema nomeando um engenheiro-chefe (EC) responsável por todas as dimensões do produto. Pense no engenheiro-chefe como um empreendedor, um indivíduo motivado e apaixonado pelo produto e pelos clientes. Uma pessoa com conhecimento suficiente para se aprofundar em questões técnicas e com habilidades de liderança suficientes para lidar com as políticas do projeto. Steve Jobs, apesar de também ser CEO da Apple, era o arquétipo de um engenheiro-chefe.
A principal tarefa do engenheiro-chefe é criar as condições para uma profunda colaboração entre especialistas de domínios muito diferentes. O EC não tem autoridade hierárquica sobre eles à medida que passam de um projeto para outro, mas ele tem autoridade total para tornar o produto um grande sucesso. Portanto, é importante que sua competência seja reconhecida e respeitada para que as pessoas sigam sua visão. O EC precisa trabalhar duro para “vender” suas ideias, e não pode apenas impor seu ponto de vista às pessoas.
Engenheiros-chefes são uma raça rara, e não há dois deles que sejam iguais. Eles certamente têm traços pessoais específicos, mas também são desenvolvidos ao longo dos anos para adquirir uma ampla gama de habilidades, trabalhando em muitas atividades diferentes em toda a empresa. Eles continuam aprendendo e conduzindo o aprendizado da equipe do produto com uma ferramenta específica: a obeya.
A OBEYA
No início dos anos 90, Takeshi Uchiyamada, engenheiro-chefe da Toyota, recebeu um desafio difícil: projetar o carro do século 21, com metas de consumo de combustível muito agressivas. Em menos de três anos, o primeiro carro híbrido, o Prius, foi lançado no mercado – 15 anos à frente da concorrência. Para realizar tal feito, o engenheiro-chefe também teve que inventar uma nova abordagem de desenvolvimento de produtos e processos. Ele projetou um novo tipo de gestão visual, que, desde então, se espalhou pelos escritórios de engenharia da Toyota: a obeya.
Obeya significa “quarto grande” em japonês. É um grande escritório onde as paredes são cobertas com informações: gráficos, desenhos, planos e assim por diante.
Uma obeya não é apenas outra ferramenta de gestão de projetos. O objetivo não é revisar o progresso nem priorizar os recursos. O objetivo é, antes de mais nada, pensar profundamente, conversar e discutir sobre os principais problemas do projeto. É um espaço para descoberta.
Os engenheiros-chefe tornam a informação e o conhecimento visíveis na obeya, porque é uma maneira poderosa de alinhar as pessoas. Mal-entendidos são rapidamente revelados para que as pessoas possam falar sobre eles e desenvolver um entendimento compartilhado da situação. Isso leva a longas discussões acaloradas, mas esse é o processo pelo qual as pessoas entram na mesma página e aprendem juntas. O tempo gasto no alinhamento das pessoas logo cedo compensa nas fases posteriores do projeto.
Não há regras definidas para o que o engenheiro-chefe e sua equipe devem exibir nas paredes. Cada obeya é única, porque depende da maturidade da equipe e do estágio do projeto. No entanto, existem alguns tópicos que precisam ser explorados, qualquer que seja o produto. Esses tópicos vêm na forma de quatro perguntas:
- Qual é o problema que queremos resolver e para quem?
Construir um produto de sucesso é menos um problema de construção (“vamos adicionar esse recurso”), e mais um exercício de solução de problemas (“o que devemos fazer para obter esse resultado?”). O problema é que geralmente corremos para a solução antes de definir o problema a ser resolvido.
Os profissionais lean usam o método científico com o ciclo de planejar-fazer-verificar-agir (PDCA) para resolver problemas de negócios. O desenvolvimento de produtos não é exceção. Construir um produto é, em si, um ciclo PDCA:
- Planejar: defina o problema do cliente a ser resolvido, desenvolva um entendimento profundo da situação e identifique as principais características do produto-alvo.
- Fazer: construa o produto.
- Verificar: analise os resultados da empresa para ver o que funciona e o que não funciona.
- Agir: tire lições para melhorar o próximo ciclo de desenvolvimento de produtos.
Uma boa declaração do problema descreve um objetivo ambicioso. Por exemplo, o desafio de Shinkansen era permitir que as pessoas viajassem de Tóquio a Osaka em três horas é fazer isso em menos de cinco anos.
A próxima coisa a aprender e explorar na obeya é como os clientes percebem o valor. Esse tipo de aprendizado é o resultado de uma imersão profunda na vida dos clientes. Começa com as reclamações dos clientes, tentando descobrir o que eles estavam tentando fazer com as soluções atuais e de que maneira essas soluções falharam. Também significa passar um tempo com eles para entender melhor como eles tentam resolver seus problemas hoje.
O engenheiro-chefe e a equipe de produto precisam ter uma noção de:
- Quem são os clientes-alvo e qual é o estilo de vida e o gosto deles?
- Qual é o problema concreto que eles querem resolver?
- Em que contexto e circunstâncias específicas?
- Que alternativas eles podem escolher para obter o que querem?
- Por que eles escolhem uma alternativa em detrimento de outra?
- O que eles amam e o que odeiam nas soluções existentes?
- Que problemas específicos eles enfrentam com as soluções existentes?
- Que preferências devemos satisfazer plenamente para não decepcioná-los?
- Que aspecto(s) podemos/devemos melhorar para atrair a atenção das pessoas?
Por exemplo, para um serviço de compartilhamento de carros, o cliente deseja ir do ponto A ao ponto B e, para conseguir isso, pode escolher entre serviços concorrentes e uma empresa de táxi regular, mas também possuem como opção serviços de trem ou ônibus. Sua decisão será baseada em um conjunto de preferências para cada solução:
- Facilidade de reserva.
- Não ter que esperar muito.
- Uma carona confortável.
- Uma boa experiência com o motorista.
- Preço não muito caro.
O mesmo vale para os motoristas, que precisam escolher entre plataformas diferentes. A questão decisiva que guiará a visão do produto é: qual é a principal preferência dos clientes-alvo? Como podemos diferenciar a próxima geração do produto em algo alinhado com o que é mais importante para os clientes? Essa é a chave para concentrar os esforços de desenvolvimento de produtos no que mais importa.
- O que a empresa espera obter com o projeto?
Alguns anos atrás, uma empresa de publicidade começou a desenvolver um sistema interno de gestão de fluxo de trabalho. O objetivo era fornecer aos fotógrafos, designers gráficos, gerentes de produto e tipógrafos uma solução para evitar perder tempo com uma enxurrada de emails e arquivos de Excel. O projeto foi difícil, principalmente porque a equipe de produto não tinha acesso aos principais representantes de vários departamentos, que estavam focados em outras prioridades. Dois anos depois, o produto estava em funcionamento, mas a equipe de liderança enfrentava um problema: eles investiram a maior parte dos lucros da empresa nessa ferramenta, mas não conseguiram descobrir quais benefícios ela trazia para o negócio.
Uma das primeiras perguntas de descoberta que o engenheiro-chefe e sua equipe precisam responder no início do projeto é: quais são os ganhos esperados para a empresa? O objetivo aqui é criar um caso de negócios atraente que ajude a:
- torná-lo um item de alta prioridade para todas as partes interessadas.
- definir a estrutura correta de custos para o projeto.
- verificar se os ganhos são realmente colhidos quando o produto sai.
Neste exemplo, o objetivo de negócios poderia ter sido reduzir a rotatividade de clientes, oferecendo uma interação mais agradável com eles. Também poderia ter sido reduzir pela metade o tempo de espera de novas campanhas publicitárias ou aumentar a produtividade da equipe de design gráfico, medida como o número de projetos de design gerenciados por pessoa por mês. Também poderia contribuir para o crescimento da empresa, desbloqueando vendas que não eram possíveis sem esse produto.
- Que decisões técnicas precisamos tomar para criar um produto coerente e lucrativo?
O engenheiro-chefe e sua equipe desenvolvem sua compreensão do produto, explorando como suas diferentes funções contribuem ou não para o valor percebido pelos clientes e como essas funções interagem entre si. Eles tentam descobrir quais problemas precisam ser resolvidos antes de criar o produto.
Considere os preços em horário de pico, por exemplo. Essa função ajuda a reduzir o tempo de espera dos passageiros, pois atrai mais motoristas quando a demanda for alta. No entanto, isso também prejudica a experiência do usuário, pois os preços ficam mais altos no momento em que mais precisa do serviço. Isso também torna os preços menos claros para os motoristas, que podem se sentir enganados quando tiverem a impressão de que a demanda deve ser alta, mas não enxergam aumento em suas receitas. Na escala de um serviço, isso significa centenas ou milhares de chamadas adicionais para equipes de suporte a usuários e motoristas e, portanto, um grande impacto nos custos operacionais.
Para captar e resolver esses tipos de problemas antes que eles sejam desenvolvidos, o engenheiro-chefe começa fazendo com que a equipe mapeie como as funções do produto se relacionam com as preferências do cliente e procure as compensações a serem resolvidas. O objetivo é descobrir como melhor atender a essas preferências, mantendo o custo-benefício. A equipe também tenta entender como as funções do produto interagem entre si, a fim de encontrar atritos que podem tornar o produto mais complexo e difícil de construir e manter.
A equipe pode aprender sobre maneiras de resolver esse balanço, tentando muitas combinações diferentes, analisando seu desempenho e resumindo seus aprendizados na obeya.
Nesse estágio, um dos principais riscos é alterar os aspectos dos produtos que não devem ser alterados – o que chamamos de “tecnologia herdada” –, mantendo aspectos que criam complexidade desnecessária e impedem a inovação – o que chamamos de “tecnologia de legado”. Para a equipe de produto, esse é um desafio real, pois nem sempre é fácil distinguir entre os dois.
A tecnologia herdada é tudo que define a própria essência do produto e justifica sua existência. Um exemplo comum são os teclados QWERTY e AZERTY, que não mudaram em 150 anos, desde que as máquinas de escrever foram inventadas. Esses layouts estranhos foram criados originalmente para compensar um desafio mecânico: fazer com que as teclas mais usadas não ficassem grudadas entre si. Desde então, algumas empresas de teclados tentaram propor velocidades mais altas de digitação com layouts mais eficientes, mas elas não estão mais aqui para contar a história. Pessoas de todo o mundo se acostumaram a esse layout estranho e resistiram fortemente à mudança. Essa é a essência da tecnologia herdada.
Em contraste, o sistema de molas que faz as teclas saltarem pode ser considerado uma tecnologia de legado, pois novas abordagens resultam em digitação mais silenciosa e rápida. Empresas como a Apple investem constantemente em outros aspectos da tecnologia – a forma e o espaçamento entre as teclas, a distância vertical etc. – para melhorar as soluções de legado, mantendo o mesmo layout herdado.
Mas, novamente, talvez até o layout possa um dia ser considerado “legado”, especialmente se a tecnologia de reconhecimento de voz se tornar confiável o suficiente para substituir a digitação por completo. Essa é uma discussão interminável dentro de uma equipe de produtos, e é por isso que ela precisa estar acontecendo na obeya.
- Estamos construindo um produto de qualidade a tempo para vencer a concorrência?
A descoberta também se aplica ao processo de desenvolvimento do produto. O engenheiro-chefe e a equipe do produto concordam em:
- como eles definem e rastreiam a qualidade ao longo do projeto.
- quais marcos eles precisam alcançar para cumprir o prazo.
- como medir os custos.
A qualidade se refere ao próprio produto. Os indicadores de qualidade fornecem informações para decidir se as funções do produto atendem plenamente às expectativas dos clientes em termos de confiabilidade, desempenho e usabilidade. Para escolher os indicadores corretos que guiarão os produtos por todo o seu ciclo de vida, o engenheiro-chefe e a equipe de produtos precisam se colocar no lugar de seus clientes-alvo: o que NÃO pode dar errado? Pegue uma lâmpada LED como exemplo: um indicador de qualidade pode ser o respeito pela vida útil, o brilho e a cor esperados, o superaquecimento ou a resistência a choques. Esses indicadores de qualidade geralmente são o resultado de trocas técnicas que a equipe de produto teve que resolver com antecedência. Portanto, faz sentido acompanhá-los ao longo dos estágios de projeto e desenvolvimento, para que a equipe possa descobrir todas as maneiras pelas quais ela não está conseguindo criar um produto de qualidade.
Além da qualidade, o engenheiro-chefe e a equipe de produtos normalmente acompanham o lead time usando um plano de projeto grande e visível. Esse plano é usado para alinhar todos os principais marcos do produto e ver como as atividades e decisões de cada equipe afetam as outras. O plano do projeto permite que os membros da equipe antecipem melhor os problemas e discutam maneiras de resolvê-los antes que comprometam a entrega. Mas, acima de tudo, o plano do projeto é uma maneira de o engenheiro-chefe e a equipe de produtos descobrirem maneiras de intensificar a colaboração entre as várias equipes e partes interessadas, dentro e fora da organização.
Por fim, uma obeya normalmente inclui indicadores para monitorar os custos (não apenas os custos de desenvolvimento do produto, mas também os custos necessários para dar suporte aos clientes quando o produto estiver ativo). Isso inclui infraestrutura, equipes de suporte e operações diárias. Por exemplo, para uma empresa de comércio eletrônico, quanto tempo levará para adicionar um novo produto ao site, reabastecer um estoque ou propor uma nova promoção. Aqui, o objetivo é descobrir o impacto das opções de engenharia da equipe em todo o processo, e não apenas no desenvolvimento.
Nas últimas duas décadas, o movimento ágil se espalhou amplamente como uma contramedida para as metodologias em cascata, onde os produtos viam a luz somente após meses de especificação, projeto, desenvolvimento e teste. A consequência inesperada dessa mudança de paradigma é que as equipes de desenvolvimento de produtos agora tendem a avançar nas fases iniciais de um projeto. Indo de um extremo ao outro, criamos novas fontes de custos, na forma de retrabalhos ao longo do desenvolvimento, que agora são considerados parte normal do processo iterativo.
O problema é que construir o produto rapidamente para validar sua utilidade e, em seguida, refazê-lo continuamente até atingirmos o alvo certo é uma maneira muito cara de aprender. Várias startups queimaram seus fundos de investimento sem encontrar um mercado suficientemente bom para seu produto. A obeya fornece uma abordagem inovadora para reduzir as incógnitas antes de iniciar o desenvolvimento, que tem o duplo efeito de ser mais barato e acelerar a entrega, para que você possa abandonar uma ideia enquanto ainda não é tarde demais ou decidir continuar com ela e ser o primeiro a introduzir seu produto no mercado. Nesse sentido, a obeya é uma ferramenta mais de descoberta do que de entrega.