ANAIS FERRAMENTAS DO MODELO DE GESTÃO LEAN APLICADAS EM UMA FÁBRICA DE SOFTWARE

Transcrição

1 FERRAMENTAS DO MODELO DE GESTÃO LEAN APLICADAS EM UMA FÁBRICA DE SOFTWARE FELIPE SANTOS BATISTA DE SOUZA ( fsbs2003@gmail.com ) USP - FEA - FACULDADE DE ECONOMIA, ADMINISTRAÇÃO E C. CONTÁBEIS ALVAIR SILVEIRA TORRES JUNIOR ( alvair@usp.br ) USP - FEA - FACULDADE DE ECONOMIA, ADMINISTRAÇÃO E C. CONTÁBEIS Resumo Este caso de ensino tem por objetivo retratar uma situação ocorrida em uma fábrica de software que se viu pressionada a reduzir custos. A solução adotada foi a utilização ferramentas do modelo de gestão Lean para aumentar a eficiência de seu processo produtivo e diminuir possíveis impactos sobre suas margens. Neste processo de implementação de melhorias foram utilizadas ferramentas como o Kaizen e também o formulário A3. Ao final do processo de implementação das melhorias foi possível verificar através de indicadores qual foi o ganho obtido com a utilização do modelo de gestão Lean e suas ferramentas. Palavras chave: Lean, Agile, TI, Fábrica de Software, Kaizen, Formulário A3 Introdução Este caso se passa em uma empresa brasileira especializada no desenvolvimento de software ou como alguns preferem Fábrica de software. Esta empresa, chamada aqui através do nome fictício Pontual, possuia uma estreita relação de mais de 10 anos com um grande cliente nacional (da área de Telefonia) que realiza o outsourcing da manutenção e evolução de alguns de seus sistemas de informação com a Pontual. Esta relação duradoura sempre foi marcada por grandes projetos, em geral de alta complexidade e prazos agressivos impostos pelo cliente dada a natureza de seu negócio. Neste contexto, dentro do portfólio de sistemas mantidos pela fábrica havia um deles (que será chamado Sistema ABC ) caracterízado pela sua alta complexidade e projetos de alto esforço de implementação e em geral com prazos curtos, estas características estiveram presentes desde que o sistema passou a ser mantido pela Pontual em meados de O time de desenvolvedores envolvido com o on-going (manutenção evolutiva e corretiva) do Sistema ABC era composto por cerca de 15 funcionários dedicados exclusivamente à manutenção da aplicação. Comparativamente em relação aos outros times da fábrica, estes funcionários possuiam razoável especialização (em média, indivíduos com mais de 3 anos de experiência no sistema). 1/16

2 O Desafio Em meados de Novembro de 2013 o cliente introduziu uma forte demanda para a redução dos custos dos contratos com os fornecedores (incluindo a Pontual). Desta forma, os gerentes se viram obrigados a cortar custos a fim de que as margens fossem mantidas sem que houvesse comprometimento com a qualidade e presteza na entrega do software ao cliente. Sendo assim, algumas medidas a nível gerencial foram tomadas para promover restruturações em todas as equipes tornando-as menos custosas. Porém, no caso da equipe dedicada ao Sistema ABC diversos recursos chave (em geral experientes) da equipe tiveram que ser mantidos o que dificultava economias relevantes para a gerência. A ideia dos gestores então foi a de aumentar a eficiência/produtividade dos processos envolvidos com a manutenção do Sistema ABC. Existia ainda um fator complicador à situação, a forte pressão da alta gerência da empresa para que alterações fossem realizadas em curto prazo (cerca de 3 meses no máximo) em função do fechamento dos resultados da Pontual para aquele ano fiscal (as alterações já deveriam surtir algum efeito nos resultados). Para implementar estas melhorias necessárias, algumas questões precisariam ser respondidas: Por onde começar? O que deveria ser feito? Existiria alguma metodologia que poderia ser utilizada para guiar o trabalho a ser realizado? A ideia da gerência então foi a de reunir dois dos líderes de desenvolvimento mais experientes da fábrica que atuam com o Sistema ABC e montar uma equipe que iria conduzir um programa de melhoria da eficiência da fábrica (porém neste primeiro momento restrito ao sistema ABC). O trabalho da equipe era o de propor alternativas viáveis e factíveis para melhoria dos processos da fábrica e implementá-las de tal forma que fossem gerados resultados concretos (que pudesem ser quantificados) e em curto espaço de tempo. O modelo de Gestão Lean Para responder às questões levantadas, uma das sugestões/alternativas que surgiu dentro da equipe do programa de melhoria, foi a de adotar algumas das ideias do modelo de gestão Lean e aplicá-las ao processo de desenvolvimento de software. O termo Lean foi criado por uma equipe de pesquisa liderada por Jim Womack Ph.D do MIT, para descrever o modelo/filosofia de produção existente (Toyota Production System - TPS) na companhia automotiva Toyota em meados do final da décade de Posteriormente, as características de uma organização Lean foram descritas por Womack e Dan Jones no livro Lean Thinking eles também foram os fundadores do Lean Enterprise Institute. O modelo de gestão LEAN propõe uma forma diferenciada de se enxergar as organizações procurando promover o fluxo de valor contínuo e a diminuição do desperdício, principalmente através do engajamento das pessoas. O objetivo, portanto, é maximizar o valor entregue enquanto o desperdício é reduzido, ou seja, com menor quantidade de recursos. Para tal, o modelo LEAN também apresenta algumas ferramentas e métodos. 2/16

3 Segundo este modelo, a forma ideal para se chegar ao melhor resultado (alto valor gerado e baixo desperdício), é procurar ao invés de atuar em pontos isolados da produção como máquinas ou tecnologias, melhorar todo o fluxo de produtos e serviços através de todo o fluxo de valor. Isto irá propiciar processos com menor dependência humana, esforço e tempo para produzir produtos com menor custo e maior qualidade (comparativamente à abordagem tradicional). Segundo Bell e Orzen (2011), o modelo de gestão Lean possui 5 princípios que podem ser usados em uma vasta gama de campos de atuação (de desenvolvimento de software à produção automotiva). São eles: Valor ao cliente (entender o que o cliente valoriza); Fluxo de Valor (processos que ligados geram o produto/serviço desejado pelo cliente); Fluxo Contínuo (manter o fluxo do processo de forma contínua evitando desperdícios e tempos de espera); Produção Puxada (fazer/produzir o que e quando o cliente demanda, evitando estoques); Perfeição (melhoria contínua dos processos). Uma das ferramentas mais importantes do modelo de gestão Lean é o Kaizen (que em japones significa melhoria) trata-se da ideia de que melhorias incrementais sejam realizadas nos processos de trabalho (BELL; ORZEN, 2011). Segundo Bell e Orzen (2011), existem duas categorias/tipos de Kaizen: O Kaizen de sistemas, em geral conduzido pela gerência, no qual se busca a melhoria no fluxo de valor como um todo, através de ajustes nos fluxos de materiais, informação, etc. O Kaizen de processos, realizado muitas vezes por times e indivíduos, no qual o foco é a redução do desperdício em áreas específicas dentro do fluxo de valor. Especificamente no contexto de uma fábrica de software, algumas formas de desperdício e suas consequências são: Defeitos, causados por má execução do trabalho e que podem ter como consequência a realização de re-trabalho; Espera, pode ser gerada por aplicações lentas e afeta a produtividade dos trabalhadores; Transporte, pode ocorrer em função do deslocamento excessivo de pessoas gerando custos altos; Conhecimento não utilizado, os funcionários realizam tarefas que não agregam valor ou atividades repetitivas. Isto os previne de contribuir mais com seu conhecimento para atividades que poderiam gerar mais valor ao produto. 3/16

4 Processos de Desenvolvimento Ágeis Uma abordagem alternativa e/ou complementar ao Lean que também foi sugerida para se aumentar a eficiência da fábrica de software é a utilização de metodologias de desenvolvimento de software ágeis (amplamente conhecidas como metodologias Agile ) que vem tendo uma rápida disseminação desde os anos A filosofia de desenvolvimento Agile compreende um conjunto de metodologias/técnicas que se baseiam em desenvolvimento iterativo e incremental em que os requerimentos e soluções são analisados e pensados dentro de equipes que em geral são autogeridas e com diferentes bagagens funcionais (desenvolvedores, especialistas no negócio relacionado ao software sendo desenvolvido, etc.). Os valores, princípios e métodos do Agile foram compilados e publicados em 2001 no Manifesto Agile que entre outras coisas diz que Indivíduos e Interações são mais importantes que processos e ferramentas. A colaboração do cliente é mais importante que a negociação de um contrato. Software funcionando é mais importante que uma documentação completa. (BECK et al., 2001). O Scrum, particularmente, é um das formas de implementação do processo de desenvolvimento de software Agile, com um foco direcionado para a flexibilidade em que a realidade de que o cliente pode desejar alterar requisitos ou a sequencia em que os mesmos devem ser entregues é incluída no processo de desenvolvimento de software. Isto é possível através da característica do Scrum (derivada da filosofia Agile) de ser um modelo de desenvolvimento iterativo (com feedbacks/testes frequentes para cada um dos requisitos sendo implementados) e incremental (em que os requisitos podem ser desenvolvidos e entregues de forma menos acoplada, ou seja, o cliente não recebe uma versão final do software com todos os requisitos implementados, mas sim versões que vão agregando mais requisitos/funcionalidades com o decorrer do processo de desenvolvimento). Estas características permitem uma maior flexibilidade nas decisões sobre o que e quando os requisitos devem ser implementados. Comparação entre os modelos Agile e Lean Duas questões que surgiram dentro da equipe do programa de melhoria ao analisar os diferentes modelos: Até que ponto um modelo se relaciona com o outro e qual seria o mais adequado em cada situação. Realizando-se uma análise entre as abordagens Agile e Lean, concluiu-se que existiam algumas características que determinariam qual das duas mais se adequaria a uma determinada necessidade. O modelo de gestão Lean seria mais amplo abrangendo toda a cadeia de valor dentro de um processo organizacional focando na redução ou remoção de tarefas que não agregam valor ao produto (inclusive em áreas de apoio). De forma similar, o modelo/técnica Agile busca otimizar (através de boas práticas e métodos parecidos com aqueles presentes no modelo Lean como redução do desperdício de esforço em atividades que não agregam valor), porém especificamente no processo de desenvolvimento do software em si, ou seja, um escopo mais restrito. 4/16

5 Em uma situação hipotética em que uma fábrica de software necessita entender como o todo está funcionando, o mapeamento do fluxo de valor (proposto pela modelo de gestão Lean) poderia permitir identificar etapas que geram desperdício e que, mesmo com a implementação de processos de desenvolvimento Agile, poderiam fazer com que o resultado final (software a ser produzido) ainda fosse criado/desenvolvido de forma ineficiente. A ideia de utilizar a metodologia Lean Levando-se em consideração todas as características mencionadas acima, a equipe do programa de melhoria concluiu que a alternativa de utilização de metodologia Agile não seria a mais adequada pois o modelo de desenvolvimento por si só não era um ofensor à eficiência da fábrica, já que vinha sendo utilizado e aperfeiçoado há muitos anos. Não que isso excluísse qualquer possibilidade de uma mudança futura. Restava então, como uma saída, analisar o processo de desenvolvimento de software como um todo (não apenas a metodologia de desenvolvimento) na busca de possíveis melhorias para o aumento da eficiência da fábrica de software. Sendo assim, o modelo de gestão Lean (pelas suas características já mencionadas acima) e suas ferramentas permitiria realizar este estudo de forma orientada e sistemática. A utilização do modelo Lean aplicado à Tecnologia da Informação se mostrou interessante por algumas razões principais, como: sua ampla utilização em outras áreas relacionadas à produção (e geração de valor); possuir uma metodologia bem definida direcionando as etapas a serem seguidas desde a identificação das possíveis fontes de desperdício até a forma com que a implementação de melhorias poderia ser realizada. Através desta metodologia, portanto, seria possível obter todo um direcionamento para o trabalho a ser realizado e com relativo baixo custo já que os conceitos são amplamente divulgados e não seria necessário (pelo menos para a adoção da metodologia) a adoção de ferramentas ou softwares específicos. As considerações foram então coletadas pela equipe do programa de melhoria e levadas à gerência, como uma forma de mostrar que o trabalho estava sendo realizado e também para obter o consentimento (e também comprometimento) dos gerentes sobre o caminho a ser seguido. Tomada a decisão conjunta (equipe do programa de melhoria e gerência) pela utilização da metodologia Lean para a resolução do referido problema, passouse a verificar quais características/aspectos do Lean Thinking poderiam ser transportados para a realidade da fábrica de software e em particular para a equipe do Sistema ABC. Aplicando o Lean Thinking O Lean Thinking é um forma de se pensar subjacente ao modelo Lean segundo à qual, deve-se buscar, entre outras coisas: a definição de valor sob a ótica do cliente, alinhar da melhor forma possível as atividades que criam valor para o cliente e realizar estas atividades da forma mais eficiente (menor desperdício) possível. Inicialmente, como prega a abordagem de desenvolvimento Lean, o primeiro passo foi realizar o Genchi Genbutsu, ou seja, a equipe do programa de melhoria voltou seus olhos para o processo de desenvolvimento atualmente utilizado pela equipe que mantém o Sistema ABC. Procurou-se neste momento abrir um canal de comunicação com os desenvolvedores e 5/16

6 entender quais eram suas maiores dificuldades e colher sugestões sobre como seu trabalho poderia se tornar mais eficiente/produtivo. Esta interação preliminar se mostrou fundamental, pois os desenvolvedores se engajaram com o esforço da gerência pela redução dos custos. Buscou-se então verificar quais das ferramentas deste modelo melhor se aplicariam à situação enfrentada pela empresa. O modelo de gestão Lean apresenta duas ferramentas que, na visão da equipe do programa de melhoria, poderiam ser utilizadas para que as fontes de desperdício fossem identificadas: o formulário A3 e o mapeamento do fluxo de valor. A questão que se seguiu foi então qual ferramenta utilizar: ambas ou apenas uma delas? O mapeamento do fluxo de valor consiste em mapear através de um diagrama os fluxos de informação, materiais e trabalho que ocorrem entre células funcionais do processo sob análise, incluindo-se outros dados como a qualidade e o tempo necessário para cada processo. Além disso, durante sua concepção é possível, e por vezes necessário, envolver e integrar equipes de áreas funcionais distintas na tarefa de caracterizar e posteriormente melhorar os processos existentes. Já o A3 não é apenas um formulário, mas antes um modelo/framework de pensamento que acaba por forçar a utilização de um método estruturado científico para a resolução de problemas. Este método inclui as fases de observação, descrição de causa e efeito (hipótese), predição, teste e avaliação. Alguns dos benefícios do A3 são: decisões baseadas em fatos, consenso entre as áreas envolvidas na análise do problema, definição de metas e formas de acompanhamento para garantir que as melhorias serão alcançadas. A partir das conversas preliminares com os desenvolvedores, foi constatado que o problema principal não era externo ao ambiente de desenvolvimento do software, ou seja, não envolvia outros entes como o cliente, processos/procedimentos internos da empresa, problemas com transferência de informação (requisitos de software, por exemplo) entre diferentes elementos do processo de desenvolvimento, etc. Aparentemente o gargalo existia dentro dos times de desenvolvimento na rotina de trabalho que os mesmos realizavam. Sendo assim, entendeu-se que o mapeamento de todo o fluxo de valor do processo de desenvolvimento, apesar de válido, poderia representar um esforço maior, dada sua abrangência, do que o necessário para o problema de eficiência atualmente existente dentro da fábrica. Parecia claro para a equipe após a analise realizada até o momento que, dentro da caixa de ferramentas Lean, uma forma de realizar este trabalho seria a execução de um Kaizen de processos, já que seria envolvido um escopo menor (interno ao fluxo de valor) buscando-se a redução de desperdício. Esta atividade então, poderia seria suportada pela criação de um formulário A3, pois a partir do mesmo seria possível entender quais as possíveis fontes de desperdício, soluções e um plano de mudança (inclusive com indicadores que permitiriam acompanhar a transição). Identificando as fontes de desperdício A partir do retorno recebido durante as interações preliminares com os envolvidos no processo de desenvolvimento, foi possível identificar algumas reclamações recorrentes e que indicavam possíveis fontes de desperdício. 6/16

7 Historicamente, o Sistema ABC sofre diversas modificações ao longo de cada ano sendo que em média 20 projetos inserem alterações no código fonte do sistema. Sendo assim, o código-fonte da aplicação posssui milhares de alterações realizadas ao longo do tempo. Em fábricas de software uma atividade crucial é o versionamento do código-fonte, ou seja, armazenar as alterações realizadas no código da aplicação em um repositório (servidor) e disponibilizar o acesso a estas alterações, através deste repositório (que contém a última versão do código), para todos os outros desenvolvedores envolvidos em um dado projeto/desenvolvimento. No dia-a-dia cada desenvolvedor deve obter a versão mais atual do código-fonte e realizar a suas alterações e ao final do dia subir, ou seja, atualizar o código contido no repositório com suas alterações de tal forma que os outros desenvolvedores possam considerálas também em seu trabalho. Esta atividade é ainda mais crítica no caso do Sistema ABC devido ao alto paralismo de trabalho entre desenvolvedores (em média, 10 desenvolvedores realizam alterações simultâneas no mesmo código-fonte). Uma consequência destas características foi a de que o repositório se tornou lento, tornando o trabalho dos desenvolvedores menos eficiente. A equipe do programa de melhoria então entendeu que o repositório do código-fonte, poderia ser uma das fontes de desperdício dentro do processo. Outro ponto destacado pelos desenvolvedores foi o tempo necessário para que a aplicação fosse executada na estação de trabalho dos mesmos. Isto ocorria pois o servidor de aplicação (software/sistema utilizado para executar aplicações) utilizado nos ambientes de desenvolvimento era o mesmo utilizado pelo cliente no ambiente de produção (que é efetivamente aquele utilizado pelos usuários finais do sistema). A cada vez que o sistema era executado nos ambientes de desenvolvimento, o desenvolvedor precisava esperar 10 minutos para que pudesse realizar seus testes. Adicionalmente, a estação de trabalho como um todo fica em seu limite de consumo de memória RAM, o que dificultava ao programador realizar outras tarefas de forma paralela. Este foi outro ponto identificado como um ofensor à eficiência do trabalho dos desenvolvedores. As duas fontes de despedício identificadas podem ser enquadradas na categoria de Espera em uma das categorias de desperdício em desenvolvimento mencionadas por Taiichi Ohno. A Erro! Fonte de referência não encontrada.erro! Fonte de referência não encontrada.erro! Fonte de referência não encontrada.erro! Fonte de referência não encontrada.figura 1 apresenta de forma macro as atividades que compõem a rotina do desenvolvedor, conforme descrito acima. 7/16

8 Cliente Envia requisitos do software a ser desenvolvido Servidor de Aplicação Realiza testes Codifica o software e o executa Programador Atualiza o repositório com códigofonte alterado Obtém o código-fonte mais atualizado Repositório Cliente Software desenvolvido é entregue ao cliente Figura 1: Fluxo do processo de Desenvolvimento de Software Elaboração do A3 Para a elaboração do A3, foram promovidos alguns encontros no decorrer de duas semanas entre um representante da equipe que estava envolvida com a condução do programa de melhoria e os desenvolvedores (não líderes) mais experientes da fábrica. Vale ressaltar que o contato poderia ter sido realizado apenas com os líderes de desenvolvimento, mas houve o entendimento que essa abordagem poderia inserir filtros entre o chão de fábrica e os gestores o que não seria ideal do ponto de vista do Gemba. Após o entendimento de que algumas atividades específicas poderiam ser as fontes de desperdício no processo, foram definidas variáveis que permitiriam avaliar quantitativamente qual seria esse desperdício e se de fato estas atividades seríam responsáveis por uma perda de eficiência da fábrica: Tempo médio para a realização do gravação de um arquivo no repositório (T gravação ); Tempo médio para download de um arquivo do repositório (T download ); Tempo médio de inicialização da aplicação (T inicializaçao ); Consumo médio de memória RAM da estação do desenvolvedor com a aplicação sendo executada (C estação ). A partir daí realizaram-se as medições necessárias para a aferição de cada uma delas. Para tal, foi solicitado que alguns dos desenvolvedores medissem os tempos envolvidos nas atividades durante 3 dias (a escolha por medir os tempos durante mais de um dia, foi feita para que se evitasse que circunstâncias/instabilidades de infra-estrutura pudessem contaminar os resultados medidos). Os dados obtidos foram: 8/16

9 Variável T gravação Resultados antes da implementação das mudanças 85 segundos (s) T download 45 s* T inicializaçao 10 min 1 Gbyte C estação Tabela 1: Métricas anteriores ao processo de melhoria de eficiência * Tempo para o download de um arquivo individualmente, quando o download era de todo o código-fonte a taxa era de aproximadamente 0,2 segundos por arquivo Com os dados em mãos era necessário compreender qual o impacto que estas esperas causavam na eficiência da fábrica. Isto pôde ser realizado através da análise da frequência com que cada uma destas atividades era realizada. Foram então, identificados os seguintes números: A partir de uma extração das métricas do repositório de código que estava sendo utilizado, foi identificado que para cada novo projeto do sistema são realizadas em média aproximadamente 0,6 gravações de código / hora de desenvolvimento; Desenvolvedores atuando num mesmo projeto precisam sempre atualizar o códigofonte presente em suas máquinas a cada novo arquivo que é criado/atualizado no repositório por outro desenvolvedor, como em geral os projetos são desenvolvidos por 2 desenvolvedores cada gravação no repositório gera a necessidade de pelo menos um download, ou seja, 2 x 0,6 downloads / hora de desenvolvimento (já que um desenvolvedor precisa se atualizar com o código gerado pelo outro). Ao se analisar o histórico de projetos desenvolvidos pela fábrica chegou-se à conclusão que são realizadas em média aproximadamente horas de desenvolvimento mensal. Neste ponto já se poderia estimar o tempo total de espera causado pelo repositório: Tempo Total de Espera de Gravação por Mês: T gravação x 0,6 x = 28 horas mensais ou aproximadamente 1,8 horas mensais por desenvolvedor; Tempo Total de Espera de Download por Mês: T download x 1,2 x = 30 horas mensais ou aproximadamente 2 horas mensais por desenvolvedor. Ou seja, duas das atividades que poderiam estar tornando o processo ineficiente consumiam no total 58 horas mensais (ou aproximadamente 4 horas mensais por desenvolvedor). Faltava ainda analisar o tempo de espera gerado pelas variáveis T inicializaçao e C estação. Através das observações realizadas durante a coleta de informações junto aos desenvolvedores foi possível verificar que em média a aplicação era inicializada no ambiente de cada desenvolvedor 4 vezes por dia. Logo, 9/16

10 Tempo Total de Espera para Inicialização da Aplicação = 4 x T inicializaçao x ( h / 8 horas de trabalho diário) = 166 horas mensais (considerando-se toda a equipe de 15 desenvolvedores) ou 11 horas mensais por desenvolvedor. Com relação ao consumo de memória, o maior impacto era gerado pelo fato que os desenvolvedores tinham a capacidade das estações de trabalho comprometidas já que as mesmas contavam com 4 Gbytes de memória, quando considerado o consumo de memória do próprio sistema operacional, do ambiente de desenvolvimento e outras aplicações, a estações de trabalho tinham em média um consumo de cerca de 95% da memória Ram quando a aplicação era executada nas estações de desenvolvimento. A conclusão foi que aproximadamente 15 horas mensais (ou quase dois dias de trabalho) por desenvolvedor eram consumidas em espera (algo que não agrega valor ao produto a ser desenvolvido). Ficou mais claro então para todos os envolvidos que estas atividades elencadas pelos desenvolvedores representavam um volume de esforço/tempo relevante dentro do contexto da equipe de desenvolvimento. Porém, antes de continuar a busca pela eficiência combatendo o desperdício nestas atividades, foi necessário realizar uma consulta prévia junto à equipe de infra-estrutura para determinar o quanto seria possível melhorar em relação à situação atual. Após conversas com este time ficou claro que havia sim espaço para melhorias com uma possível troca do software utilizado para gerenciar o repositório do código-fonte. Esta sinalização foi importante para manter a confiança dos agentes responsáveis pelo programa de melhoria e também para justificar a continuidade da linha que vinha sendo seguida pela do programa de melhoria junto à gerência Foi interessante notar durante as interações com os desenvolvedores que a ideia de mudar a situação atual e implementar mudanças que facilitariam o trabalho dos mesmos foi muito bem aceita. Havia inclusive um sentimento de alívio por parte deles pois naquele momento eles poderiam externar todas as suas críticas e também propor sugestões. Em geral, havia abertura na fábrica de software para que as pessoas trouxessem novas ideias e formas de trabalho. Porém a diferença desta vez foi o comprometimento da gerência em patrocinar um programa estruturado de mudanças e que provavelmente (essa era a esperança de todos) seria aplicado, não se tratava mais, portanto, de uma conversa de corredor com o líder imediato ou com algum outro colega sobre ideias ou reclamações relacionadas à rotina de trabalho. Posteriormente, seguindo o plano de análise traçado anteriormente, passou-se a elaboração de um A3 focado nas duas fontes de desperdício mencionadas acima (o repositório e o servidor de aplicação). Mais importante do que a criação do A3 foi o processo para a análise das fontes de desperdício e quais as possíveis saídas para solucionar o problema, bem como o plano e cronograma para a implementação das mudanças. Como mencionado anteriormente, todo este processo permitiu um grande engajamento por parte das equipes envolvidas o que também gerou ganhos durante a criação efetiva do A3, pois todos já haviam tido algum contato com o trabalho que vinha sendo realizado, sabendo de sua importância no dia-a-dia da fábrica e também para com a gerência (que estava patrocinando esta iniciativa). 10/16

11 A seguir serão descritos brevemente alguns detalhes relacionados à cada uma das partes do formulário A3 criado durante este programa de melhoria da eficiência da fábrica. Condições Atuais Inicialmente foram identificadas as atividades que poderiam ser afetadas/impactadas pelos processos que haviam sido criticados pelos desenvolvedores. A partir deste ponto foram coletados os tempos necessários para a realização destas atividades (processo já descrito anterioremente neste texto). Metas e Objetivos De forma conjunta entre a equipe do programa de melhoria, desenvolvedores e equipe de infra-estrutura da empresa, procurou-se determinar quais seriam os tempos adequados para as atividades comprometidas com elevada espera. Análise Neste momento, o objetivo foi entender porque a situação havia chegado aquele ponto e quais os motivos principais levavam a fábrica a ainda utilizar ferramentas que não se mostram mais tão eficientes. A equipe de infra-estrutura trouxe à discussão, quais seriam as opções viáveis para a substituição das ferramentas atuais. Vale ressaltar que existe um conjunto limitado de ferramentas homologadas disponíveis para a utilização na fábrica de software. Isto poderia ter sido um complicador (restrição) à escolha da solução ótima. Os desenvolvedores também puderam coloborar na escolha de novas ferramentas, propondo opções com as quais já haviam trabalhado em outras ocasiões. Contramedidas propostas A partir do entendimento da situação atual e do que levou à mesma, foram analisadas as opções disponíveis e as contra-medidas foram acordadas entre a equipe do programa de melhoria e os desevolvedores, com uma definição clara do que deveria ser feito e quais os benefícios esperados pelas ações a serem tomadas. Isto também trouxe um maior engajamento entre os envolvidos. Plano Para a definição do plano a ser seguido foi necessário estabelecer quem seriam os responsáveis por cada uma das ações, prazo e como a execução das mudanças seria acompanhada (estabelecimento de indicadores). O envolvimento nas atividades anteriores fez com que o comprometimento dos envolvidos na execução do plano fosse conseguido com maior facilidade (logo não houve resistência ou conflito na atribuição das equipes responsáveis pelas ações) e como era de consentimento geral dos envolvidos que as melhorias trariam benefícios para todos, foi geral a determinação em fazer a mudança acontecer o mais rápido possível, desta forma o tempo para a implementação foi aquilo que todos entendiam como o sendo o melhor possível. Acompanhamento 11/16

12 Para a realização do monitoramento a proposta foi realizar reuniões com as equipes envolvidas e acompanhar os indicadores previamente estabelecidos. O A3 desenvolvido pode ser verificado na seção de anexos do presente trabalho. Implementação das mudanças Com a aprovação da gerência o plano contido no A3 foi colocado em prática pela equipe do programa de melhoria, as equipes envolvidas foram reunidas e com o suporte da gerência o processo de mudança foi iniciado. O acompanhamento por parte da equipe do programa de melhoria era diário e desde o início da implantação das alterações, foram realizadas análises dos tempos envolvidos nas atividades ofensoras. A melhora observada foi significativa em todas as variáveis. A seguir serão detalhados brevemente alguns aspectos do processo de mudança que foi realizado. Troca do Repositório Existia uma diferença conceitual na utilização do novo repositório em relação ao antigo, desta forma inicialmente foi necessário envolver os líderes de desenvolvimento para que fosse estabelecida uma política de utilização do novo repositório de acordo com suas características particulares (por exemplo, qual seria o procedimento em caso de projetos concorrentes entre si, qual seria o procedimento quando uma versão do software que estava sendo desenvolvida fosse colocada em produção pelo cliente, etc.). Isto foi importante para evitar que os líderes tomassem decisões divergentes quando situações como estas ocorressem. O que seria muito ruim pois abalaria a confiança dos desenvolvedores no trabalho que estava sendo realizado. Posteriormente foi elaborado um guia de utilização do novo repositório explicando como realizar as tarefas cotidianas. Após os devidos esclarecimentos junto aos desenvolvedores, o novo repositório do codigo-fonte foi liberado para utilização, e os desenvolvedores envolvidos com novos projetos foram solicitados a utilizar o novo repositório. Todo o trabalho preparatório contribuiu para que o nível de resistência à mudança fosse baixo. Os desenvolvedores perceberam que os líderes e os agentes responsáveis pelo programa de melhoria de eficiência sabiam o que estavam fazendo e propondo. Troca do Servidor de Aplicação A troca do servidor de aplicação foi mais tranquila, já que a nova aplicação era mais leve e simples. Logo no início da utilização do novo software os desenvolvedores perceberam o ganho de tempo obtido e se mostraram bastante satisfeitos com a nova situação. Como resultado a resistência à alteração foi mínima ou até inexistente. O papel da liderança no processo de implantação das mudanças O acompanhamento da transição pela gerência foi realizado através de reuniões com a equipe do programa de melhoria e os líderes de desenvolvimento onde eram revisados os 12/16

13 indicadores principais delineados no A3 (como: percentual de sistemas migrados para o novo repositório e percentual de desenvolvedores utilizando o novo servidor de aplicação ). O suporte da gerência patrocinando a iniciativa foi de fundamental importância para a aceitação das alterações realizadas. Desde o início do processo a gerência deixou claro que os envolvidos na mudança que contribuíssem para que a mesma ocorresse de forma suave e com sucesso seriam reconhecidos. Adicionalmente, era clara a grande expectativa da liderança com relação ao sucesso da empreitada, o que motivou os envolvidos (desenvolvedores e equipe de infraestrutura) a trabalhar com afinco e dedicação nesta mudança. Resultados das alterações implementadas Apesar dos ajustes pontuais necessários no processo de trabalho para que os desenvolvedores passassem a utilizar as novas ferramentas (servidor de aplicação e repositório), a transição ocorreu dentro do cronograma previsto no A3, em cerca de um mês todos os desenvolvedores envolvidos com novos projetos para o Sistema ABC já estavam utilizando o novo ferramental. Na Tabela 2 é possível verificar os valores aferidos ao final do processo de implantação das mudanças para melhoria do processo de desenvolvimento: Variável Resultados antes da implementação das mudanças Resultados após a implementação das mudanças T gravação 85 segundos (s) 3 s T download 45 s 3 s T inicializaçao 10 min 3 min C estação 1 Gbyte 0,7 Gbyte Tabela 2: Comparação de métricas (antes x pós) processo de melhoria de eficiência Desta forma, os novos tempos totais mensais apurados foram: Tempo Total de Espera de Gravação por Mês: T gravação x 0,6 x = 1 hora mensais ou aproximadamente 4 minutos mensais por desenvolvedor; Tempo Total de Espera de Download por Mês: T download x 1,2 x = 2 horas mensais ou aproximadamente 8 minutos mensais por desenvolvedor; Tempo Total de Espera para Inicialização da Aplicação = 4 x T inicializaçao x ( h / 8 horas de trabalho diário) = 50 horas mensais (considerando-se toda a equipe de 15 desenvolvedores) ou 3 horas mensais por desenvolvedor. Na situação original, o tempo total de espera de cada desenvolvedor era de 15 horas mensais, após a implementação das melhorias este tempo caiu para 3 horas e 12 minutos mensais, uma redução de 80% no tempo de espera dos desenvolvedores, em outras palavras, os desenvolvedores tem agora pouco mais de 10 horas produtivas a mais por mês para trabalhar em atividades que irão agregar valor aos produtos (softwares) desenvolvidos pela fábrica. Adicionalmente, houve uma redução de 300 Mbytes no consumo de memória RAM das estações o que representa um ganho de 30% em relação à situação anterior e um 13/16

14 comprometimento da memória das estações de aproximadamente 87,5% (próximo ao objetivo inicial de 85% presente no A3). Os resultados impressionaram a gerência da fábrica. Apesar de o tempo de inicialização da aplicação não ter alcançado os 2 minutos estabelecidos como alvo no A3, a melhora nos indicadores e no tempo total foi bastante satisfatória. Os funcionários ficaram entusiasmados pelo fato de terem sido ouvidos, que melhorias em sua rotina de trabalho foram implementadas na prática e em um curto espaço de tempo. Isto pode trazer ganhos a longo prazo na medida em que eles agora entendem a importância de se fazerem ouvir e a gerência que agora entende a importância de ouvir os funcionários que estão na linha de frente no dia-a-dia. A utilização do formulário A3 (ferramenta obtida do modelo Lean) foi de importância vital para o processo, pois auxiliou a definir a linha de pensamento a ser seguida pelos agentes de mudança, auxiliou a engajar os funcionários e equipes envolvidos através do consenso do que precisava ser alterado, como, quando e por quem. Apesar de o processo ter sido aplicado pontualmente para a resolução de uma situação específica e não nos processos da fábrica como um todo, ficou evidente para a gerência que a adoção da metodologia Lean na fábrica (inclusive com o mapeamento do fluxo de valor e a realização de um Kaizen de sistema) pode trazer benefícios ainda maiores a médio e longo prazo através de ganhos de eficiência. Os funcionários agora estão mais motivados a realizar sugestões e os líderes de desenvolvimento entendem que a partir de ideias originadas no chão da fábrica podem surgir inovações que podem vir a gerar ganhos operacionais. Questões para Discussão Considerando os ganhos de eficiência obtidos na experiência de aplicação da metodologia Lean pela fábrica, pode se dizer que o processo foi exitoso? O mapeamento do fluxo de valor seria aplicável à esta situação? Além do A3 e do Mapeamento do Fluxo de Valor, existe alguma outra ferramenta Lean que poderia ter sido aplicada nesta situação? A razão para não utilização da metodologia Agile como uma possível forma de melhoria de eficiência é válida? Existem outras formas de desperdício mencionadas no caso que poderiam ser abordadas no programa de melhoria de eficiência? 14/16

15 Bibliografia BELL, Steven C.; ORZEN, Michael A.. Lean IT: Enabling and Sustaining Your Lean Transformation. Chicago: Productivity Press, p. BECK, Kent et al. Manifesto for Agile Software Development Disponível em: < Acesso em: 04 mar LOCHAN, Rupesh. Lean or Agile? A Comparison of Approach Disponível em: < Acesso em: 25 fev /16

16 Anexos Formulário A3 Desenvolvido Título: Melhoria na eficiência do processo de Desenvolvimento de Software I. Contexto Existe uma previsão de desenvolvimento de projetos grandes com prazos agressivos. Porém existe baixa produtividade atualmente: Repositório de códigos fonte lento; Interface de desenvolvimento lenta e que demanda alto consumo computacional; Especificações com pouco nível de detalhe do que deve ser realizado. Problemas de produtividade podem comprometer os prazos e qualidade da entrega. II. Condições Atuais Dados sobre versionamento e ambiente de desenvolvimento Tempo médio para a realização do gravação de um arquivo no repositório: 1 min e 45 segundos Tempo médio para download de um arquivo do repositório: 45 segundos Tempo médio de inicialização da aplicação: 10 min Consumo de memória da estação do desenvolvedor com a aplicação sendo executada: 95% Alto custo (em termos de tempo) para a realização de análises (em que é necessário que a aplicação esteja sendo executada) pelo analista Alto custo (em termos de tempo) para a realização de testes pelo desenvolvedor 50% do tempo de correção de defeitos durante o projeto é devido à inicialização da aplicação para testes e versionamento no repositório. III. Metas e Objetivos Vesionamento: Download / Upload de arquivos em 5 s Ambiente de Desenvolvimento: Inicialização da aplicação em 2 min Máximo consumo de memória durante execução da aplicação: 85% Redução do tempo gasto com inicialização e versionamento durante correções em 50% IV. Análise V. Contramedidas propostas Causa Contramedida Descrição Benefício A B VI. Plano Troca da ferramenta de versionamento Troca do servidor de aplicação Efetuar a troca da ferramenta Migrar arquivos em manter histórico de versões com mais de 3 meses Melhoria no tempo necessário para versionamento dos arquivos. Responsável/ Suporte Aréa de Infraestrutura Não é necessária a utilização Redução no tempo necessário Equipe de do mesmo servidor de para a execução da aplicação no Desenvolvim aplicação da produção no ambiente de desenvolvimento. Portanto, pode ser utilizada uma alternativa mais "leve". ambiente de desenvolvimento ento Troca do repositório Responsável: Ação a ser realizada pela equipe de infra-estrutura Prazo: 100% migrado em 1 mês a partir da solicitação Indicador de progresso: Percentual de sistemas migrados para o novo repositório,. Alteração no ambiente de Desenvolvimento Responsável: Equipe de Desenvolvimento Prazo: 100% migrado em 1 mês a partir da solicitação Indicador de progresso: Percentual de desenvolvedores utilizando o novo servidor de aplicação. VI. Acompanhamento Monitorar semanalmente os indicadores de progresso; Manter reuniões com os líderes de desenvolvimento sobre o progresso da alteração. Vesionamento (Causa A): Ferramenta de Versionamento utrapassada e com histórico dos arquivos muito antigo o que aumenta o tempo necessário para a utilização dos mesmos. Ambiente de Desenvolvimento (Causa B): O servidor de aplicação* (mesmo utilizado no ambiente de produção) demanda muita capaciadade computacional para a execução da aplicação em ambiente de desenvolvimento. * Software utilizado para a execução de aplicações em ambiente WEB. Figura 2: A3 desenvolvido durante o programa de melhoria de eficiência 16/16