ANAIS
FERRAMENTAS DO MODELO DE GESTÃO LEAN APLICADAS EM UMA
FÁBRICA DE SOFTWARE
FELIPE SANTOS BATISTA DE SOUZA ( [email protected] )
USP - FEA - FACULDADE DE ECONOMIA, ADMINISTRAÇÃO E C. CONTÁBEIS
ALVAIR SILVEIRA TORRES JUNIOR ( [email protected] )
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 2006.
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
ANAIS
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 1980.
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
ANAIS
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
ANAIS
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 2000.
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
ANAIS
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
ANAIS
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
ANAIS
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
ANAIS
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
Repositório
Obtém o código-fonte mais
atualizado
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 (Tgravação);
• Tempo médio para download de um arquivo do repositório (Tdownload);
• Tempo médio de inicialização da aplicação (Tinicializaçao);
• Consumo médio de memória RAM da estação do desenvolvedor com a aplicação
sendo executada (Cestaçã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
ANAIS
Tgravação
Resultados antes da implementação das
mudanças
85 segundos (s)
Tdownload
45 s*
Variável
Tinicializaçao
10 min
Cestação
1 Gbyte
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 2.000 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: Tgravação x 0,6 x 2.000 = 28 horas
mensais ou aproximadamente 1,8 horas mensais por desenvolvedor;
• Tempo Total de Espera de Download por Mês: Tdownload x 1,2 x 2.000 = 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 Tinicializaçao e Cestaçã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
ANAIS
•
•
Tempo Total de Espera para Inicialização da Aplicação = 4 x Tinicializaçao x (2.0000 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
ANAIS
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
ANAIS
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
ANAIS
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:
Tgravação
Resultados antes da
implementação das mudanças
85 segundos (s)
Resultados após a
implementação das mudanças
3s
Tdownload
45 s
3s
Tinicializaçao
10 min
3 min
Cestação
1 Gbyte
0,7 Gbyte
Variável
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 2.000 = 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.000 = 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 (2.0000 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
ANAIS
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
ANAIS
Bibliografia
BELL, Steven C.; ORZEN, Michael A.. Lean IT: Enabling and Sustaining Your Lean
Transformation. Chicago: Productivity Press, 2011. 370 p.
BECK, Kent et al. Manifesto for Agile Software Development. 2001. Disponível em:
<http://www.agilemanifesto.org/>. Acesso em: 04 mar. 2014.
LOCHAN, Rupesh. Lean or Agile? A Comparison of Approach. 2011. Disponível em:
<http://www.processexcellencenetwork.com/lean-six-sigma-businesstransformation/articles/using-lean-in-agile-software-development-a-compari/>. Acesso em: 25
fev. 2014
15/16
ANAIS
Anexos
Formulário A3 Desenvolvido
Título: Melhoria na eficiência do processo de Desenvolvimento de Software
I. Contexto
V. Contramedidas propostas
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.
Causa
A
Contramedida
Descrição
Benefício
Troca da
Efetuar a troca da ferramenta Melhoria no tempo necessário
ferramenta de Migrar arquivos em manter
para versionamento dos
versionamento histórico de versões com mais arquivos.
de 3 meses
Responsável/
Suporte
Aréa de
Infraestrutura
Problemas de produtividade podem comprometer os prazos e qualidade da entrega.
Troca do
servidor de
aplicação
B
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%
VI. Plano
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
•
•
IV. Análise
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 ento
ambiente de desenvolvimento.
Portanto, pode ser utilizada
uma alternativa mais "leve".
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