Dificuldades das empresas de TI em atingir a excelência

LIB: Mary, você pode se apresentar para nossos leitores?

Mary: Comecei minha carreira como programadora. Trabalhei por 20 anos na Universidade de Wisconsin lidando com equipamentos de processo de controle. Depois, tornei-me gerente de TI na área de manufatura de fitas de vídeo, quando participei da transformação do sistema de manufatura clássico para o just-in-time. Decidimos adotar um sistema puxado, inventado por nós mesmos na época, para mantermos nossa competitividade frente ao mercado japonês. Eventualmente, saí da 3M e decidi olhar para o mercado. Resolvi participar de um projeto de software do governo chamado “Waterfall”, que foi um desastre. Então, por volta de 2001 ou 2002, comecei a estudar o lean na área de desenvolvimento de software, Tom se juntou a mim, e escrevemos nosso primeiro livro, “Lean Software Development”. A ideia do livro era descrever o porquê da ideia do projeto não ter sido muito boa e como o lean se aplica à área de desenvolvimento de software. Desde então, escrevemos mais três livros.

LIB: Quais foram os benefícios que os princípios e técnicas lean trouxeram para a área de engenharia de software?

Mary: Em qualquer área onde se desenvolve algo novo, você não aplica o lean como na manufatura; você precisa, entretanto, aprender. Então, no desenvolvimento de produtos em geral, particularmente no desenvolvimento de software, tenho que aparecer com alguma solução para um problema e, como engenheira de software, tenho de pensar qual é o problema que precisamos solucionar. E, se você olhar para a forma como o lean foi aplicado no desenvolvimento de software, que começou somente no final da década de 90, foi um pouco diferente da produção: tem a ver com ir devagar, com adiar as decisões até você ter o máximo de informação que puder, tem a ver com trabalhar com pequenos lotes e, basicamente, tem a ver com fluxos de informação em oposição aos processos de desenvolvimento. E precisamos fazer esses fluxos de informação mais da forma mais suave e rápida possível e constantemente fazer inovações. E também é necessário garantir que construamos algo com qualidade. Há um costume no desenvolvimento, que criamos há algum tempo, que diz: “vamos construir nosso sistema e, depois, vamos reservar 30 ou 40% do processo de desenvolvimento para testá-lo”. Isso é completamente contrário ao conceito de desenvolvimento lean de software, que diz: “vamos construir o software e testá-lo a todos os momentos”. Esses tipos de princípios são os que funcionam bem no desenvolvimento de software.

LIB: Em sua opinião, como um departamento ou organização de TI deveria começar a aplicar o pensamento lean?

Mary: Eu prefiro falar de uma organização de TI em vez de um departamento de TI. E é por uma boa razão: quando eu era engenheira, fazendo sistemas de controle de processos, eu não era parte de um departamento de TI. Na verdade, nunca trabalhei em um departamento de TI. E sempre fico confusa quanto aos departamentos de TI; quero dizer, não fico confusa com a engenharia de software em geral, mas com o fato de o departamento de TI ter péssimos resultados. Considere a ideia de desenvolvimento tecnológico. Tudo melhorou quando os executivos e gerentes seniores começaram a entender a tecnologia. Você não encontra empresas assim até o final da década de 90. Uma empresa que precisamos citar é a Amazon. O departamento de TI da Amazon é revolucionário. Uma coisa que você realmente precisa saber quanto ao lean é entender o problema do cliente, e não é exatamente isso que um departamento de TI faz, ele pensa em seus colegas, que também são clientes, mas não os clientes do negócio. O que é necessário fazer é entender o problema do negócio, do cliente do negócio, em vez de pensar em seus colegas da organização como seus clientes.

Tom: Uma coisa que acontece em um departamento de TI é que as pessoas devem fazer o que mandam que elas façam, e isso não é um papel muito excitante. A tendência emergente é que as pessoas que têm competência em áreas técnicas se tornam parte de algo que se chama a “chave de todas as estatísticas”, que é responsável por toda a experiência do cliente, tudo que o produto fornece ao cliente final; isso inclui pessoas que entendem o mercado, a tecnologia, a entrega, o marketing de vendas, esses elementos. Se todos trabalharem juntos para fornecer valor para o cliente externo – e a empresa fica com uma parte disso – esse é o paradigma que hoje domina no que chamamos de TI.

Mary: Existem alguns CIO que entendem isso, e eles estão levando suas empresas para o caminho certo para melhorar o negócio em si e a experiência do cliente.

LIB: Quais são as dificuldades que são encontradas quando aplicamos o lean na área de TI?

Mary: Vamos falar de desenvolvimento de produtos em vez de TI, porque penso nessa empresa que tem capacidade técnica, que pode ou não se chamar departamento de TI. Se você quiser aplicar os princípios lean, há muitos aspectos do lean que são contraintuitivos. Pensávamos que para ter uma qualidade alta, tínhamos que ser muito lentos e deliberativos, para nos dar tempo para descobrir quais são os defeitos de nosso software no final do processo. Se você quiser aplicar o pensamento lean no desenvolvimento de software, você perceberá que há algo errado com esse conceito. Por que procuramos pelos defeitos apenas no final do processo, em vez de procurá-los conforme desenvolvemos o software? O fato quanto ao lean, pelo menos no que se refere à engenharia de software, é que precisamos automatizar tudo desde o começo para que possamos testar o software conforme o desenvolvemos. A segunda coisa que é contraintuitiva é o fato de adiar as decisões o máximo possível. Precisamos criar softwares que sejam mutáveis e que possibilitem o teste imediatamente após as mudanças. Então não precisávamos saber de tudo logo no começo, mas adiávamos as decisões o máximo possível. Esses conceitos de facilidade para mudança, de fazer experimentos em vez de escrever exigências e de descobrir o que é útil conforme o processo evolui em vez de saber tudo logo no início são difíceis para pessoas que passaram todas as suas carreiras em processos diferentes.

LIB: Falando sobre sua apresentação no Lean IT Summit, você pode nos contar sobre o que falará?

Mary: Acreditamos que seja sobre a diferença entre eficiência do fluxo e eficiência dos recursos. Há um livro chamado “This is Lean”, que é um dos mais vendidos na Suécia. Não é um livro sobre software, mas sobre o negócio. Ele explica que o que ele faz tem que ser para garantir a eficiência – você não define eficiência garantindo que todos estejam ocupados, todas aquelas pessoas com tanto trabalho a fazer não é eficiência. Se você olhar para o lean, ele tem uma noção muito clara sobre o que é fluxo. O lean entende que grandes lotes criam muita variação. Vamos usar uma estrada como analogia: se você lotar uma estrada com carros, o que acontece? O trânsito para. Então esse conceito de criar um congestionamento ao deixar todos ocupados é algo que os gerentes parecem não entender; eles dizem: “vamos deixar todos lotados de serviço; dessa forma, usaremos melhor nossos recursos”. Se você lotar as pessoas com coisas para fazer, a consequência é o estresse, é a mudança de uma atividade para outra; é muito melhor se você tiver a quantidade certa de coisas para fazer no tempo certo. No desenvolvimento de software – ou em qualquer outro processo –, se você olhar para a unidade lenta e maximiza a velocidade que ela passa pelo fluxo, isso é muito melhor do que manter todos ocupados. Pense em um hospital: queremos garantir que todos os médicos, todos os equipamento de Raio-X, todos os equipamentos caros estejam sempre ocupados, enquanto pacientes esperam, ou queremos pegar um paciente da emergência e movê-lo pelo sistema o mais rápido possível? No lean, você vê o paciente como a unidade de fluxo; no outro paradigma, você vê o médico, ele tem de estar sempre ocupado. No lean, dizemos: “teremos o melhor fluxo, o melhor uso de todos os nossos recursos se não tivermos, constantemente, longas filas e grandes lotes, se conseguirmos mover o paciente pelo sistema o mais rápido possível”. Você deve olhar para o problema do paciente e solucioná-lo o mais rápido possível, em vez de garantir que todos estejam ocupados. Você deve olhar para a unidade do fluxo, para o problema do cliente. E, quando você faz isso, consegue uma qualidade maior e soluções melhores.

Tom: O conceito de fluxo está bem no centro do pensamento lean. Há uma conversão interessante recentemente, nos últimos anos, entre o pensamento lean e o pensamento de design. Designers não falam em fluxo, falam em fricção, que é um antifluxo. Acho que uma alternativa muito boa para falar de fluxo é identificando as fontes da fricção. O objetivo do designer, quando projetando um novo produto, é identificar onde está a fricção. Qual é o problema que o cliente está enfrentando? Onde está o desperdiço de tempo? Onde está o desperdiço de recursos? Achar soluções potenciais para esses problemas é bem mais provável com o pensamento lean do que, por exemplo, criar uma hipótese e testá-la. Essa é a direção para a qual a TI está se encaminhando. Se você for a conferências sobre tecnologia de hoje em dia, notará que elas são muito padronizadas quanto aos processos, práticas, ferramentas. O mercado do software está mudando de grandes modelos para algo que um sistema que previne que um pequeno grupo de pessoas forneça um serviço muito rapidamente, eles têm de cuidadosamente encontrar interfaces.