Minha jornada pessoal lean, como a de muitos profissionais, começou na manufatura. Foi no chão de fábrica que encontrei o pensamento lean pela primeira vez e aos poucos aprendi a descobrir seus segredos. Ao longo de minha carreira como coach lean, também comecei a me concentrar no desenvolvimento lean de produtos e processos, e quanto mais trabalho nele, mais pontos em comum encontro entre ele e a manufatura lean. O que observo é que o trabalho lean que fazemos na engenharia não é diferente do que fazemos na produção.

Confira a seguir as 3 dicas do autor para acelerar o processo de desenvolvimento de produtos com o lean.

1. Tarefas menores são o caminho a seguir

Antes de nos aprofundarmos neste tópico, deixe-me dar um contexto sobre uma empresa cuja transformação LPPD tenho apoiado. Antes de o lean ser introduzido lá, o gerente responsável por cada novo produto determinava o que cada membro da equipe deveria fazer – em colaboração com o departamento de planejamento de produtos. Claro, ele precisava desenvolver um plano enorme, que devido às dificuldades encontradas ao longo do caminho, nunca era concluído. Era como se estivéssemos em um avião cuja trajetória de voo não poderia ser alterada mesmo quando o mau tempo chegasse. Não havia escolha a não ser atravessar a turbulência.

Em resposta a isso, criamos uma linha de tempo de alto nível na obeya exibindo os principais marcos do projeto em vez de várias tarefas detalhadas. Em seguida, dividimos o projeto em sprints, estabelecendo entregas para cada sprint e traduzindo cada entrega em tarefas. Isso facilitou a adaptação do plano à realidade em constante mudança (seguindo na analogia do avião, isso significava que, quando a turbulência fosse detectada, poderíamos contorná-la ou voar a uma altitude diferente).

Como não sabemos o que o futuro reserva, não faz sentido planejar em detalhes o que acontecerá só daqui três semanas. Em vez disso, nos concentramos em pequenas entregas para as próximas três semanas com base em uma condição de destino futura. Para estabelecer as entregas, entretanto, primeiro tivemos que explicar o que é uma entrega – qual entrada é necessária, qual saída é esperada e qual é o risco inerente a cada tarefa que compõe a entrega. Descobrimos que, gerenciando adequadamente o risco, conseguimos garantir a qualidade e a entrega no prazo de nossos produtos.

Atribuir as entregas de tarefas a cada sprint (uma responsabilidade do gerente de projeto) usando um quadro visual na obeya significava saber que entregar todos esses elementos do trabalho no prazo, por sua vez, garantiria o alcance dos marcos do projeto em tempo hábil. Além disso, dizia a cada sprint o que exatamente eles tinham que entregar, aumentando seu senso de propriedade.

A grande revelação aqui é que, para concluir as tarefas mais rapidamente, devemos nos esforçar para torná-las menores – ou, se preferir, mais curtas e mais frequentes. Vamos usar o teste de produtos como exemplo. Uma sessão de testes que dure uma semana é muito longa: um motivo para os engenheiros quererem reservar uma semana para seus testes é o risco “de as coisas correrem mal”. Mas e se elas correrem bem? Vale a pena causar um atraso na próxima tarefa do processo apenas pela possibilidade de ocorrer um problema? Essa grande tarefa não poderia ser dividida em outras menores para que qualquer problema em potencial viesse imediatamente à tona?

2. Estabeleça um marcador e relações entre cliente e fornecedor

Ao desenvolver um produto ou serviço, devemos tentar separar claramente o sistema de seus subsistemas e ativos. Ao criar subsistemas, podemos estabelecer uma relação entre fornecedor e cliente dentro do sistema principal, que atuará como um marcador do processo de desenvolvimento. Isso ajudará a reduzir seu lead time e seu time to market.

Aqui, vemos imediatamente um paralelo com a manufatura, onde o processo marcador determina o ritmo do trabalho. No LPPD, assim como na manufatura, essa abordagem permite a puxada e garante que o trabalho ocorra no ritmo definido pelo cliente, atendendo às suas necessidades. À medida que o programa é executado (ou seja, o produto é desenvolvido), os fornecedores são solicitados a oferecer soluções – por exemplo, um ativo específico a ser adicionado ao produto. Esses ativos – na produção, nós os chamamos de peças – podem ser construídos sob encomenda, caso ainda não tenham sido desenvolvidos, ou vir de um supermercado de soluções existentes.

Quer estejamos em um cenário sob encomenda ou de estoque, para estabelecer essa relação entre cliente e fornecedor e regular o sistema, utilizamos um “kanban de entrega”. No caso que usamos de exemplo, o sistema principal envia um kanban para o subsistema ou para uma equipe de ativos (qualquer um que for a esse quadro encontrará o kanban lá). A equipe de ativos, então, assume a entrega e cria um plano de tarefas para tornar essa entrega possível e entregar o ativo necessário (geralmente usando engenharia simultânea baseada em conjunto). Exatamente a mesma coisa que acontece na manufatura com os componentes! Se o marcador estiver próximo do cliente final e puder puxar dos supermercados fluxo acima, o lead time será menor do que seria em uma situação em que o marcador está no início do processo.

Reduzir os prazos de entrega é fundamental para uma organização de desenvolvimento de produtos (o tempo de colocação no mercado é um indicador-chave para eles), e isso pode ser alcançado simplesmente colocando o marcador mais para o fim do processo, e não no início. O mesmo acontece na manufatura: a Toyota nos ensinou que, em vez de construir grandes lotes do mesmo produto, precisamos tornar nosso sistema flexível o suficiente para seguir o ritmo estabelecido pelos pedidos dos clientes. Portanto, reduzir nossos tempos de troca para que possamos produzir rapidamente lotes menores e entregar aos clientes. Este é o poder do marcador.

3. Torne o conhecimento reutilizável

Para a empresa do nosso exemplo, foi muito importante esclarecer aos gerentes de produto quais soluções já estavam disponíveis no supermercado e quais alternativas já existiam. No caso deles, já que estamos falando de engenharia, o supermercado é um repositório não apenas de peças físicas, mas também de conhecimento passado (reutilizável) – tanto de sucessos quanto de fracassos. Para trazer essa clareza, melhoramos a maneira como eles visualizavam as curvas de trade-off, para que as equipes soubessem que, dentro de certas margens, as soluções já estavam disponíveis. Isso não é puro kanban? Seja um pedido de pizza em um restaurante, um pedido de maçaneta na fabricação de portas ou um pedido de um subsistema necessário para o desenvolvimento de um novo produto, o plano não muda. A única diferença é que os prazos de entrega no desenvolvimento de produtos são mais longos.

Ao implementar o kanban, conseguimos reduzir esses prazos de entrega ao mesmo tempo em que ajudamos os membros da equipe a entender por que estavam fazendo o que estavam fazendo. Isso deu um propósito mais claro ao seu trabalho: entregar a informação ou produto certo ao cliente, na quantidade certa, no momento certo.

Como vimos, se já há soluções desenvolvidas e disponíveis em seu supermercado, você tem a oportunidade de levar o produto ao mercado mais rapidamente e, em seguida, liberar atualizações à medida que avança – usando curvas de trade-off ou engenharia simultânea baseada em conjuntos. Isso, entretanto, força você a gerenciar o conhecimento que você já possui.

Na verdade, à medida que você progride no trabalho de desenvolvimento, não obtém somente um produto, mas também novos conhecimentos. Aprender a aproveitar ao máximo esse conhecimento no futuro é realmente revolucionário: para a empresa do meu exemplo, isso significava que menos subsistemas precisavam ser desenvolvidos do zero. Quando precisar de certas funcionalidades, um novo produto agora pode contar rapidamente com ativos existentes (ou seja, reutilizar o conhecimento existente) e concentrar os esforços de desenvolvimento nos recursos que ainda não existem. O mecanismo que torna tudo isso possível é o kanban.

Antes do kanban, programas e subsistemas eram muito separados: a equipe de produto não era vista como um cliente interno, e os subsistemas trabalhavam no modo de empurrada. Depois que montamos o quadro, entretanto, as pessoas entenderam o que o sprint exigia e entregaram exatamente isso.

Para concluir

Como você garante que os aprendizados sejam mantidos no sistema, tanto os sucessos quanto os fracassos, para que possam ser usados no futuro, permitindo reduzir os prazos de entrega? Gostaria de encorajar aqueles que estão começando sua transformação a dividir grandes tarefas em pequenas entregas mais fáceis de gerenciar, a enxergar o desenvolvimento de produtos como uma relação entre clientes e fornecedores e a aproveitar melhor o conhecimento que já existe na sua empresa.

Espero que este artigo ajude aqueles que estão participando de uma transformação lean no LPPD a entender como o pensamento lean pode ser aplicado ao seu ambiente e como as lições de manufatura lean podem orientá-lo na virada do seu departamento de engenharia.