Escolar Documentos
Profissional Documentos
Cultura Documentos
6 1 2 -P 1 1
OCTOBER 16, 2009
DAVID M. UPTON
BRADLEY R. STAATS
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
Servios de software
O processo de desenvolvimento de software era similar em muitos aspectos ao processo de
construo de uma casa. O primeiro passo para construir uma casa era especificar os requisitos
necessrios para a soluo. Isso poderia incluir determinar o nmero de metros quadrados, andares,
quartos, banheiros etc. Uma vez que os requisitos tenham sido especificados, ento os arquitetos e
engenheiros criam designs detalhados, que no apenas especificam a localizao dos quartos e da
estrutura geral (tomadas, torneiras, interruptores etc.), como tambm o posicionamento da
infraestrutura eltrica e de encanamento. Somente depois disso comea o processo de construo.
Durante a construo, falhas encontradas nas plantas so corrigidas e o trabalho constantemente
inspecionado em busca de defeitos. Quando sistemas so concludos (por exemplo, o sistema de ar
condicionado), eles so testados, e quando todo o trabalho est concludo, toda a casa inspecionada,
2
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
primeiro pelo construtor e depois pelo cliente que compra a casa. No desenvolvimento de software,
os mesmos passos bsicos so tomados na maioria dos projetos, embora estes passos tenham nomes
diferentes: especificao de requisitos, design detalhado, teste de cdigo e unidade, teste de sistemas
e, finalmente, teste de aceitao do usurio. Uma diferena entre construir uma casa e desenvolver
um software que o progresso ou a forma do que est por vir so frequentemente invisveis para o
usurio at que ele possa ver o produto ou servio final em funcionamento.
Servios de software so um negcio diferente de softwares direcionados para o consumidor final
(como Microsoft Word) ou sistemas de software para empresas (por exemplo, sistemas integrados de
gesto empresarial, ou ERP). Muito do trabalho da Wipro no era desenvolvimento do comeo, mas
envolvia adaptar, conectar e apoiar sistemas de software existentes. Incertezas tcnicas e de mercado
eram menores para a Wipro do que para um desenvolvedor de softwares aplicativos, pois a empresa
no iniciava um projeto at que um cliente solicitasse o trabalho. No entanto, a complexidade do
processo costumava ser alta, j que a empresa trabalhava em centenas de projetos com altos
requisitos de qualidade ao mesmo tempo. Deb descrevia o negcio dizendo: Ns no construmos
uma casa inteira para algum. Ao invs disso, ns adicionamos a varanda nos fundos. Ns
precisamos, no entanto, ter um bom conhecimento da casa em questo e da sua fundao e design
antes de adicionar a varanda.
Havia duas outras importantes distines no tipo de trabalho que a Wipro fazia. A empresa
dividia-se em trs unidades de negcios: Solues de Engenharia de Produtos (PES, que consistia em
telecomunicaes e sistemas embutidos), Solues Empresariais (ES) e Bancos, Finanas, Poupanas e
Seguros (BFSI). Originalmente, projetos em PES envolviam fornecer suporte para o software em um
produto (por exemplo, os drivers em uma impressora). Com o tempo, a empresa comeou a realizar
servios de desenvolvimento de software. Mais recentemente, clientes passaram a terceirizar subsistemas inteiros ao invs de apenas softwares. A Wipro estava comeando a assumir
responsabilidade pelo gerenciamento tanto da manuteno quanto da melhoria de produtos maduros
ou em fim de linha.
Embora o trabalho realizado pela Wipro na rea de PES costumava ser de responsabilidade do
Diretor de Tecnologia do cliente, o trabalho feito nas reas de ES e BFSI tipicamente era de
responsabilidade do Diretor de Informao do cliente. Projetos nestas duas unidades de negcio eram
geralmente de um entre dois tipos: manuteno ou desenvolvimento. Projetos de manuteno
envolviam apoiar e melhorar os sistemas existentes de um cliente. Por exemplo, apoiar o sistema
integrado de gesto empresarial de um cliente era um projeto de manuteno comum. A Wipro podia
consertar falhas identificadas pela empresa e criar software para adicionar novas funcionalidades ao
sistema. Por outro lado, um projeto de desenvolvimento envolvia construir, integrar ou atualizar
sistemas de TI. Exemplos de projetos de desenvolvimento incluem criar um novo website altamente
interativo, transferir o aplicativo mvel de vendas de uma empresa do sistema Palm OS para o
Windows CE e o desenvolvimento de um novo sistema de gerenciamento de distribuidores para
rastreamento, relatrios e pagamentos.
3
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
Antes de comear na Wipro, minha impresso era de que se tratava de uma organizao focada
na qualidade no sentido geral e em performance ideal em todos os contextos. Em vrias ocasies,
percebi que a viso externa da situao melhor que a viso interna. Mas este no era o caso na
Wipro. Tipicamente, as pessoas que odeiam seu nvel de qualidade so as equipes de vendas, porque
eles so aqueles que esto em contato com o cliente, ouvindo reclamaes sobre tudo que est dando
errado. Mas isso no acontece aqui; as equipes de vendas adoram nosso nvel de qualidade.
Muito do foco em qualidade veio da descrena inicial que a empresa enfrentou quando estava
entrando, e depois competindo, no mercado internacional de servios de software no final dos anos
80 e incio dos anos 90. Clientes globais demonstraram ceticismo de que uma pequena empresa na
ndia poderia fornecer o software de alta qualidade de que seus negcios precisavam. Assim, a
empresa se concentrou em abordagens pblicas para melhoria de processos para demonstrar seu
compromisso com a alta qualidade. Em 1995, a Wipro foi uma das primeiras empresas de software a
receber a certificao ISO 9000 (veja no Anexo 2 uma tabela das iniciativas de melhoria de processo
da empresa).
Nos anos 80, o Departamento de Defesa dos EUA fundou o Instituto de Engenharia de Software
(SEI) na Carnegie Mellon University, com a inteno de avanar o estado da prtica de engenharia
de software1 O instituto estabeleceu o Modelo de Amadurecimento de Capacidade (CMM) para
softwares e, em 1998, a Wipro tornou-se a primeira empresa de servios de TI a conquistar o nvel 5
do modelo. Em 1997, inspirada por uma joint venture entre outra subsidiria da Wipro Ltda. e a
General Electric (GE), a empresa foi a primeira a introduzir o sistema Six Sigma aos servios de
software. Em 2000, o sistema era um sucesso na Wipro Technologies. A Motorola originalmente
introduziu Six Sigma em um contexto de manufatura e a GE rapidamente tornou-se sua mais famosa
adepta. O sistema Six Sigma usava tcnicas estatsticas, professores chamados de faixas pretas e
normalmente um processo DMAIC (Definir, Medir, Analisar, Melhorar [Improve] e Controlar) para
tentar reduzir o nmero total de defeitos para 3,4 por milho de oportunidades.
Mais tarde em 2002, quando o SEI introduziu uma nova verso do CMM, CMM Integrated
(CMMI), a Wipro novamente tornou-se a primeira empresa do mundo a receber a certificao de
nvel 5. As iniciativas de melhoria de processo da empresa levaram a melhorias consistentes em
qualidade, aderncia a prazos e aderncia a esforos (veja no Anexo 3 detalhes de 1995 a 2004). Em
2004, a Wipro percebeu que suas iniciativas de melhoria de processo estavam empacando. Um lder
snior de qualidade da empresa afirmou:
Iniciativas de qualidade duram de 18 a 24 meses, talvez 36 meses se voc tem sorte. A razo
para isso que ou cada iniciativa se concentrava em processos de controle mais avanados
quando comparadas s anteriores, ou em novas tcnicas, como o uso de controle estatstico de
processos no sistema Six Sigma, e cada uma destas fornecia retornos menores com o tempo. Ns
sabamos que era hora de comear a procurar algo novo.
Desafios em 2004
Em 2004, a Wipro estava enfrentando tanto desafios estticos quanto dinmicos. Havia dois
fatores estticos que todos os fornecedores de servios de software enfrentavam. Primeiro, o principal
fator para o desenvolvimento de software era engenheiros de software talentosos. O esteretipo era
de que os engenheiros de software eram pessoas cabea dura e independentes, que acreditavam que
1 Software Engineering Institute, About the SEI, website do Instituto de Engenharia de Software,
http://www.sei.cmu.edu/about/about.html.
4
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
seu trabalho era uma arte e gostavam de fazer coisas de sua prpria maneira. Muitos engenheiros de
software concordavam que esta reputao era merecida. Segundo, servios de software era
inerentemente um negcio varivel. Projetos eram customizados para cada cliente e, portanto, eram
idiossincrticos por natureza. Como a maior parte do trabalho da Wipro era unir diferentes sistemas
de TI, os desafios enfrentados por um projeto em particular eram fortemente impactados por no
apenas que sistemas estavam sendo integrados (algo mais ou menos consistente em todos os
projetos), mas tambm por como o cliente havia implementado estes sistemas dentro de seus
negcios (algo idiossincrtico em todos os projetos). Alm destas questes constantes, havia tambm
mudanas dinmicas acontecendo no mercado.
Questes organizacionais
Alm do sentimento da empresa de que sua iniciativa de qualidade atual (Six Sigma) estava se
estagnando, havia vrios outros desafios organizacionais sendo enfrentados pela Wipro. No final de
2003, a empresa tinha quase 18 mil funcionrios, um aumento de 40% com relao ao ano anterior.
Alm do aumento geral de funcionrios, a taxa de sada de funcionrios na maioria das empresas de
servios de software da ndia (incluindo a Wipro) era de em mdia 10% a 20% por ano. A rpida
entrada e troca de pessoal significava que qualquer processo de software utilizado na empresa
precisava ser robusto o suficiente para fornecer a orientao necessria para novos membros de
equipes e controles de monitoramento de performance para gerentes.
Adicionalmente, o trabalho na Wipro era tradicionalmente feito a partir de uma abordagem de
cima para baixo. Os gerentes de projeto eram responsveis por criar um detalhado planejamento do
projeto usando Microsoft Project e, em seguida, designar tarefas especficas para os membros da
equipe. Como disse Alexis Samuel, com nossa configurao atual, o poder latente dos engenheiros
no aproveitado, e a empresa queria uma abordagem processual que iria capturar alguns dos
benefcios de dar poder aos membros das equipes.
Finalmente, a Wipro vivenciava variaes substanciais em performance atravs das diferentes
unidades de negcio da empresa. Embora parte desta variao fosse resultado de caractersticas
bsicas das indstrias que as unidades de negcio serviam, uma quantidade significativa no era. A
empresa tinha um sistema de gerenciamento de conhecimento que foi usado com algum sucesso, mas
ainda havia uma crena de que melhores prticas em uma rea da empresa no estavam sendo
reproduzidas com sucesso em outras unidades de negcio.
Questes de competitividade
Alm dos desafios organizacionais, a empresa enfrentava um contexto estratgico dinmico. A
Wipro havia tradicionalmente se diferenciado no mercado como um fornecedor de baixo custo e alta
qualidade. Embora seus custos fossem menores do que os de seus principais concorrentes
internacionais (por exemplo, IBM, Accenture e EDS), esta diferena estava diminuindo, j que a alta
demanda por engenheiros de software talentosos na ndia estava aumentando seu valor (salrios
cresciam em mdia 12% ao ano), e concorrentes internacionais estavam expandindo sua presena na
ndia para tirar vantagem de alguns dos recursos de baixo custo que a Wipro utilizava. Alm disso,
embora houvesse empresas menores em outros pases com baixos salrios pressionando a Wipro (por
exemplo, China, Filipinas, Vietn e Rssia), uma das maiores ameaas vinha de novas empresas
indianas. Deb descreveu o desafio da seguinte forma: A ndia forma mais de 380 mil engenheiros de
5
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
software qualificados, que falam ingls, por ano. Os recursos para executar uma estratgia simples,
de baixo custo, esto se renovando constantemente na ndia.
Adicionalmente, embora o mercado reconhecesse a Wipro como lder em qualidade, seus
concorrentes estavam diminuindo esta diferena. Diz Alexis: Um grande desafio para ns que, em
comparao com trs anos atrs, as pessoas esto alcanando a Wipro.
Finalmente, a Wipro acreditava que estava acontecendo uma mudana significativa no mercado.
Havia uma viso interna de que o setor de TI estava deixando a produo artesanal para trs e havia
uma oportunidade para se tornar lder em processos. Anurag descreveu assim a situao:
Na minha opinio, TI est na mesma situao que a indstria automobilstica em 1910-1920.
Hoje, cada organizao faz seu trabalho de forma nica; ainda estamos na fase da produo artesanal.
No entanto, h tanta ineficincia que pode ser eliminada e o mercado muito competitivo para que
ela no seja eliminada. Ns vemos isso acontecendo. Toda a onda de terceirizao e globalizao
prova de que a transio est acontecendo. Hoje, voc deve ser capaz de fornecer consistentemente
para diversos tipos de clientes. No sabemos como fazer isso com software ainda, mas o setor de
manufatura sabe. A chave para o sucesso de uma fbrica no comprar mquinas gerenciar
pessoas. Ento, agora, a chave torna-se fazer dez mil pessoas trabalharem juntas. Assim, se voc
supe que isso vai acontecer, voc lidera ou voc segue? Se voc decide liderar, h duas formas de
fazer isso. A primeira usar sua marca, como uma IBM, e a segunda ser a empresa mais eficiente.
No podemos ser o lder de marca atualmente, por isso no temos escolha a no ser sermos os mais
eficientes.
6
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
Precisamos conectar foco em negcios e foco em processos. Atravs de sistemas como CMM, nos
tornamos bastante bons em gerenciamento de processos. No entanto, no sabemos como gerenciar
pessoas. Em nossas pesquisas de satisfao de clientes, nossos clientes nos dizem: Vocs so muito
bons em fazer o que eu peo. Se eu peo para vocs construrem uma mesa com trs ps, vocs fazem
isso, mas vocs nunca perguntam porque a mesa tem apenas trs ps. Nossos clientes querem que a
gente fornea ideias inovadoras. Eles podem no saber ainda [o que eles querem], mas eles sabem
quando a Wipro no est fazendo-o.
7
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
No fim das contas, a Wipro acabou trazendo do Japo alguns consultores que tinham
familiaridade com o sistema Lean no ambiente de manufatura. Como descreveu Anurag: Eles foram
muito teis em abrir nossos olhos. Eles no forneceram solues, mas estimularam discusses.
Quanto mais perguntas fizemos, melhor ns ficamos. Cada interao ajudou-nos a fazer
descobertas.
Deb resumiu o principal aprendizado da equipe durante o processo, No se trata de teorizar,
trata-se de fazer. Ento, para comear, eles decidiram que cada membro da equipe iria encontrar um
projeto, comear a implement-lo e fornecer resultados em dois a trs meses. A equipe tinha que fazer
isso ao mesmo tempo em que continuavam a realizar seu trabalho normal. Eles no tinham
autoridade formal para obrigar a participao de um gerente de projeto, mas cada um tinha capital
organizacional suficiente para alistar um projeto. Um gerente de projeto descreveu o processo:
Ele [o membro da equipe lean] me procurou e disse que eu iria usar o sistema Lean para esse
projeto. Ele me disse para comprar dois livros sobre Lean2 e ns tivemos discusses a respeito por
dois dias. Ele me ajudou a me desfazer do plano original para o projeto e criar um plano de projeto
lean. Durante as primeiras trs semanas, eu estava muito confuso e no sabia dizer minha equipe
o que era Lean. Eu tinha reunies semanais com a equipe e passei de 3 a 4 horas ensinando-lhes sobre
o sistema. Nas reunies, eu listava ideias do TPS para eles discutirem.
A equipe Lean montou uma sala de estratgia eletrnica para compartilhamento de experincias
dos vrios projetos. No final de outubro de 2004, eles analisaram os resultados e descobriram que este
primeiro experimento havia resultado em oito sucessos dentre dez projetos. Um projeto era
considerado um sucesso se resultasse em mais de 10% de melhoria na(s) medida(s) de performance
pr-especificada(s) do projeto. Com taxa de 80% de sucesso, a equipe decidiu continuar com a
implementao.
O prximo passo, em novembro de 2004, foi realizar uma sesso de treinamento de um dia com 35
gerentes de qualidade. Na Wipro, cada projeto tinha um representante do setor de garantia de
qualidade do software (SQA) designado, para oferecer assistncia com qualidade e produtividade,
alm de monitorar a conformidade do processo. O representante de SQA normalmente trabalhava em
cinco a dez projetos por vez. Depois da sesso de treinamento, os membros da equipe de SQA
deveriam encontrar um projeto lean no qual trabalhar. Alm disso, neste momento, Azim Premji, o
presidente da Wipro, anunciou publicamente que a empresa estava usando uma abordagem lean para
servios de software e estava esperando obter uma significativa vantagem competitiva com a
mudana. Como disse um gerente snior: Ele anunciou que ns estvamos usando Lean. Isso
demonstrou compromisso da diretoria, mas pode ter sido prematuro. De qualquer forma, agora ns
temos que ir em frente.
Em agosto de 2005, vinte meses aps o incio da iniciativa lean, a Wipro tinha 112 projetos lean
concludos ou em processamento, e em janeiro de 2006 este nmero tinha aumentado para 235 (veja
no Anexo 4 um histrico da implementao dos projetos Lean e Six Sigma). Algumas unidades de
negcio j tinham realizado sesses de treinamento lean de meio perodo para seus gerentes de
projeto. Ravishankar Kuni, diretor de produtividade da empresa, descreveu desta forma o progresso:
Lean um processo lento uma mudana no estilo de gerenciamento uma mudana de
cultura.
8
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
Lean na Wipro
Procedimento operacional padro
Como discutido anteriormente, CMMI era a abordagem geral de melhoria que a Wipro usava3.
Alm disso, houve vrios ciclos de vida para desenvolvimento de software (SDLC) em conformidade
com CMMI que a empresa empregou para concluir projetos individuais. Exemplos incluram
cascatas, modelos iterativos e abordagens especficas para clientes. De longe o ciclo de vida mais
usado na Wipro foi a abordagem cascata. Nela (similar a um modelo stage-gate em desenvolvimento
de produtos), uma equipe determinava requisitos de clientes, desenvolvia um documento de design
detalhado, escrevia cdigos, realizava testes nas unidades, integrava as diferentes partes do projeto,
conduzia testes de sistema e, ento, fornecia-o a um cliente. O processo continuou linearmente e se
havia feedback no sistema, era apenas entre estgios sucessivos. A abordagem cascata foi reconhecida
como previsvel e escalonvel, mas havia alguma troca em termos de flexibilidade.
Esperava-se que todos os projetos na Wipro seguissem a estrutura definida de CMMI. Gerentes de
projeto usavam o sistema interno da empresa, Veloci-Q, para submeter planos de projetos, gerar
documentos e outros procedimentos necessrios.
Projetos Lean
A empresa achou que a conformidade com o nvel 5 do CMMI continuava a ser um importante
padro externo, ento, em sua forma inicial, Lean foi operacionalizado no nvel de projeto como um
ciclo de vida que ia de encontro aos requisitos de CMMI. No havia requisitos centralizados para um
projeto ser considerado lean, mas a expectativa era que um projeto lean usasse vrias das diferentes
contramedidas lean. O setor de produtividade mantinha uma lista dos projetos lean e todos os meses
eram feitas revises destes projetos, em que as equipes apresentavam seu progresso. Algumas
unidades de negcio incluam lderes de negcio nestas reunies, enquanto outras deixavam-nas a
cargo do representante de SQA. A expectativa inicial era que os projetos lean precisavam mostrar
3 Neste momento, havia uma batalha metodolgica acontecendo entre proponentes do CMMI e de mtodos geis de
programao (por exemplo, Extreme Programming (XP), Scrum, Crystal). Alguns proponentes dos mtodos geis
argumentavam que CMMI criava processos sem razo de ser e entregava software confivel e de alta qualidade que no
satisfazia as necessidades do cliente. Por outro lado, alguns proponentes do CMMI respondiam que mtodos geis resultavam
em hacking indisciplinado e eram apropriados somente para projetos pequenos. Como na maioria dos casos, a verdade estava
no meio termo e algum trabalho havia sido feito para unir as duas abordagens. Em agosto de 2005, inspirada em parte por
pedidos de clientes, a Wipro estava experimentando com dez projetos-piloto geis para ver se havia alguma circunstncia em
que o uso deles poderia ser apropriado em seu negcio.
9
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
resultados em dois a trs meses. Projetos que estavam abertos a mais de seis meses sem demonstrar
nenhum impacto deixavam de ser considerados projetos lean. Esta expectativa de prazo fazia com
que muitos dos projetos lean iniciais fossem ou uma parte menor de um projeto grande ou uma
interveno onde um projeto enfrentava um choque externo e precisava de uma nova abordagem
para reagir (por exemplo, um cliente adiantando o prazo final ou uma equipe se atrasando). O
objetivo da iniciativa lean era demonstrar aumento de 10% ou mais nas medidas pr-especificadas de
projeto (agenda, esforo ou qualidade). A empresa rigorosamente rastreava medidas de performance
em todos os projetos e, por isso, podia medir quantitativamente o impacto de projetos lean. Deb
descreveu assim o raciocnio por trs do objetivo de 10% ou mais:
Se estabelecssemos um objetivo muito baixo, por exemplo melhoria de 2% a 3%, um gerente de
projeto poderia fazer uma equipe trabalhar muito para atingir a meta. No entanto, isso no seria
sustentvel. Precisvamos estabelecer um objetivo que s poderia ser atingido realmente mudando
como trabalhamos.
Se um gerente de projeto quisesse lanar um projeto lean, o representante de SQA e um membro
do setor de produtividade forneceriam apoio, incluindo reunies, conversas telefnicas e artigos
sobre contramedidas lean. Normalmente, quando uma nova equipe comeava um projeto lean, era
data ao gerente de projeto a opo de ter o representante de SQA conduzir uma curta sesso de
treinamento para a equipe ou o gerente podia faz-lo sozinho. Cada gerente podia escolher as
contramedidas lean que ele ou ela considerava mais apropriadas para seu projeto. Em janeiro de 2006,
gerentes no eram obrigados a conduzir projetos lean. Unidades de negcio tinham metas com
relao ao nmero de projetos lean que deveriam ser concludos, mas isto no havia sido diretamente
transferido para alvos e objetivos individuais. Havia algum debate interno sobre se concluir um
projeto lean deveria fazer parte dos alvos e objetivos de cada gerente de projeto para o ano fiscal de
2007.
Contramedidas Lean
Em janeiro de 2006, a Wipro havia tentado muitas abordagens diferentes para resolver problemas
(contramedidas)4 Embora no houvesse uma abordagem nica para Lean na Wipro, vrias das
contramedidas listadas abaixo eram comumente usadas em cada projeto lean.
Just in time/Fluxo nico Todo projeto na Wipro era just in time e usava fluxo nico, j que o
trabalho no comeava em um projeto at que fosse requerido pelo cliente. No entanto, dentro de um
projeto havia a oportunidade de concluir cada um dos passos de produo necessrios em sequncia,
um de cada vez, ao invs de utilizar o processamento em srie.
Em um projeto de converso de um website, a Wipro estava atualizando e melhorando o site de
uma grande empresa. O site antigo consistia de pginas construdas em cima de 680 pginas de
servidor Java (JPSs). Cada pgina do site podia levar a mltiplas JPSs. No passado, em um projeto de
converso como este, o gerente de projeto designava alguns indivduos para converter todas as JPSs,
enquanto outros membros da equipe trabalhavam nas pginas do site que levariam a elas. Ao invs
disso, neste projeto a equipe moveu cada pgina em um processo de fluxo nico, trabalhando em
uma JPS somente quando uma pgina do site levava a ela. Ao usar esta abordagem, a equipe
Ao descrever suas diferentes ferramentas e tcnicas, a Toyota usa o termo contramedidas ao invs de solues.
Isso porque cada resposta vista como um meio para um fim (por exemplo, reduo de desperdcio) ao invs de
uma resposta por si s. Para mais informaes, consulte Steven Spear e H. Kent Bowen, Decoding the DNA of
the Toyota Production System, Harvard Business Review (Setembro/Outubro 1999): 97-106.
10
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
percebeu que 200 das JPSs (aproximadamente 30%) no estavam ligadas s paginas do site e, por isso,
no precisavam ser convertidas.
Matriz da estrutura de design Um dos principais desafios para a Wipro com um modelo
iterativo era definir o que deveria fazer parte de cada iterao. A literatura sobre engenharia de
software no fornecia uma recomendao conclusiva, mas a empresa adaptou a matriz da estrutura
de design (DSM) tarefa.
Uma DSM uma matriz binria, quadrada, que no caso da Wipro usava a atividade ou
funcionalidade requeridas como dados. Um nmero um colocado na matriz para indicar uma
dependncia futura (colocada abaixo da linha diagonal) ou um loop de feedback (colocado acima da
linha diagonal). Depois que a DSM inicial preenchida, o prximo passo dividir a matriz. Esta
diviso feita para que tarefas independentes (isto , tarefas upstream) sejam programadas antes de
suas correspondentes dependentes (isto , tarefas downstream) e funcionalidades conjuntamente
dependentes sejam programadas para o mesmo momento. Embora haja diferentes abordagens para a
diviso da matriz, o objetivo transform-la em uma forma triangular inferior ou, se isso no
possvel, pelo menos em uma forma triangular blocada. Finalmente, a DSM combinada para que
tarefas que devem ser programadas simultaneamente sejam destacadas 5. Um representante de SQA
descreveu o valor da DSM:
11
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
Todas as abordagens de melhoria que utilizamos foram um gerente de projeto a planejar melhor
e monitorar mais de perto, e ambas estas atividades melhoram a performance. Com a DSM, o gerente
tem uma ferramenta para tirar o conhecimento de sua cabea e coloc-lo no papel. No d para fazer
tudo de cabea.
O impacto da DSM pode ser visto em sua utilizao em um contexto de interveno na Wipro.
Um grande cliente da empresa convocou uma pequena equipe para transferir o aplicativo de vendas
mveis da empresa de Palm OS para Windows CE. O cliente inicialmente solicitou entrega em quatro
semanas e o gerente de projeto desenvolveu um plano. Antes do trabalho comear, o cliente pediu
que a equipe entregasse o trabalho em trs semanas. O gerente procurou o representante de SQA e
um membro do setor de produtividade querendo saber como poupar tempo. Eles sugeriram o
sistema Lean e, alm de outros princpios lean (por exemplo, iteraes e quadro de controle visual),
eles recomendaram usar uma DSM. Os trs sentaram-se com o lder tcnico do projeto e preencheram
a matriz DSM (veja no Anexo 5 uma cpia das DSM inicial, dividida e combinada). A DSM inicial
mostra que o primeiro plano do gerente no levava em considerao todas as dependncias do
projeto (por exemplo, doze depende de quinze, mas doze est programado para antes de quinze). O
gerente identificou estas contradies no processo de planejamento e as corrigiu com a DSM
combinada. Com a aplicao da DSM e outros princpios lean, a equipe finalizou o projeto em duas
semanas, cumprindo o novo prazo solicitado pelo cliente.
A maioria dos projetos lean na Wipro usava a DSM. A ferramenta havia se tornado to popular
que Navneet Bhushan, um funcionrio do setor de produtividade, disse: Lean tornou-se sinnimo de
DSM para muitas pessoas. O apelo que a DSM oferece uma ferramenta onde algum insere os
dados, aperta um boto e, ento, recebe uma resposta. Alm da DSM, a Wipro usou sua prpria
experincia para desenvolver uma ferramenta similar, um estimador de complexidade. Esta
ferramenta permitia que os usurios considerassem a complexidade da funcionalidade quanto esto
criando um plano de projeto.
Quadro de controle visual Quadros de controle visual (VCB) so usados no sistema Lean para
aumentar a comunicao e destacar determinadas questes, para que o problema e a soluo
permaneam juntos. Na Wipro, um VCB comeava com o gerente de projeto dividindo o trabalho em
sesses de um ou dois dias. A seguir, em uma grande folha de papel, o gerente desenhava uma tabela
e escrevia os dias da semana no alto das colunas e os nomes dos engenheiros no incio das linhas. O
gerente ento pregava o VCB na parede para que todos os membros da equipe pudessem v-lo. O
trabalho que um engenheiro deveria concluir em um determinado dia era inserido na clula
apropriada. No final de cada dia, um engenheiro anotava a porcentagem do trabalho que ele ou ela
havia concludo. Se fosse menos de 100%, o nmero era escrito em vermelho. Se os engenheiros
terminassem seu trabalho cedo, eles podiam comear o trabalho do dia seguinte. (O Anexo 6 mostra
um VCB hipottico que a equipe havia concludo at quarta-feira.)
Com o VCB, o gerente de projeto agora tinha um lugar para visualizar o status da equipe, ao invs
de ter que ir at os lderes de mdulos ou fazer pesquisas com os membros da equipe. Alm disso, o
quadro forava o gerente a dividir o trabalho a ser concludo em sesses de um ou dois dias. Estes
pedaos menores tornavam mais fcil monitorar o progresso e perceber problemas mais cedo. Para os
membros da equipe, o quadro fornecia uma viso geral do projeto como um todo. Assim, eles sabiam
onde o seu trabalho se encaixava dentro do projeto. Eles tambm ficavam sabendo de quem o seu
trabalho dependia e podiam ir at esta pessoa diretamente se necessrio. Finalmente, o VCB podia ser
usado para que os membros da equipe iniciassem novos trabalhos se o trabalho atual havia sido
concludo antes do previsto.
12
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
Autonomao/Jidoka Outro dos princpios do sistema Lean criar testes simples e confiveis
para identificar problemas. A Wipro lidou com isso de duas formas. A primeira foi atravs de
revises de cdigo peridicas. Embora estas j fossem parte do processo mandatrio h bastante
tempo, sua utilizao aumentou aps a introduo do sistema Lean. Idealmente, as revises ocorriam
diariamente, mas em alguns casos elas aconteciam com menor frequncia. Como o nome sugere, em
uma reviso diria de cdigo algum confere o cdigo a cada dia. Esta reviso poderia ser uma
anlise visual em busca de erros ou um checagem de conformidade com os padres de design.
Algumas vezes, membros snior da equipe faziam a reviso, enquanto outras vezes pares ou grupos
de membros checavam o trabalho uns dos outros. A segunda forma era fazer com que a equipe
compilasse todo o seu trabalho atual a cada dia e, em seguida, realizasse testes automticos, criados
individualmente. Os membros da equipe construam esses casos de teste para checar se os mdulos
cumpriam as metas estabelecidas.
Heijunka/Nivelamento Outra ideia Lean incorporada pela Wipro era heijunka, ou
nivelamento. O conceito de heijunka nivelar a carga de trabalho, para que o sistema funcione a
uma taxa constante. Por exemplo, se uma fbrica tem demanda de 72 unidades por dia, um tempo de
ciclo de 10 unidades por hora e opera por oito horas, o mtodo tradicional seria operar a fbrica a
velocidade mxima por 7,2 horas para cumprir a demanda e a gerar inventrio extra ou encerrar as
atividades do dia. Usando o princpio de heijunka, uma empresa iria, ao invs disso, operar a fbrica
a uma taxa de 90% para cumprir a demanda ao longo de todo o dia. Este espalhamento do trabalho
reduz picos de demanda e uma parte importante dos sistemas lean de uma maneira geral,
reduzindo variabilidade na carga de trabalho enquanto aumenta a capacidade de responder s
necessidades dos clientes.
A necessidade de nivelamento na Wipro surgiu em um dos primeiros projetos lean da empresa.
Durante este projeto, a Wipro no estava apenas trabalhando com seu cliente, mas tambm com um
integrador de sistemas e outros desenvolvedores terceirizados. Usando outras contramedidas lean, a
Wipro foi capaz de concluir seu trabalho com muito mais rapidez, mas como seus parceiros no
estavam preparados para aceitar as recomendaes da Wipro no incio, a empresa perdeu sua
vantagem enquanto esperava por seus parceiros. No projeto seguinte, os outros princpios lean foram
incorporados, mas ao invs de tentar terminar o trabalho rapidamente, eles concluram o trabalho
com menos recursos. O nivelamento do trabalho ajudou a Wipro a manter as vantagens obtidas com
o sistema Lean no segundo projeto.
13
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
lentamente. Um bom exemplo da dificuldade de mudar a mentalidade para identificar novas formas
de fornecer valor ao cliente ocorreu em uma sesso de treinamento lean. A equipe estava
desenvolvendo drivers de impressora e tentou definir o que significava valor para o cliente. Depois
de uma longa discusso, eles acabaram determinando que o driver de impressora representava valor.
Com a iniciativa em seu 24 ms, a diretoria queria ver resultados. Havia um desejo de ver e
validar resultados reais. Uma comparao de projetos prximos com e sem a interveno lean indicou
que os projetos lean podiam ser capazes de lidar melhor com volatilidade de requisitos, com menos
revises de agenda. Embora as coisas estivessem indo em uma direo positiva, uma melhoria
explosiva de produtividade ou grande reduo de esforos no eram visveis. Olhando para trs,
Alexis e Deb acharam que o sistema Lean precisava impactar pores maiores de um projeto e
tambm ser utilizado no nvel de contas.
Prximos Passos
Deb e Alexis se despediram e entraram em seus carros. Enquanto se preparavam para enfrentar o
trnsito de Bangalore, eles continuaram a pensar sobre quais deveriam ser os prximos passos para a
empresa. Embora a implementao havia sido bem-sucedida at ento, eles sabiam que ainda tinham
muito cho pela frente. Havia outras contramedidas que eles deveriam introduzir na empresa? Se a
chave do sistema Lean era incorporar mltiplas contramedidas em um sistema coerente, eles estavam
fazendo isso? Lean era o melhor caminho a seguir e, caso fosse, como deveria ser adaptado? Eles
deveriam estar tentando criar algo diferente de Lean: um Jeito Wipro completamente diferente?
Finalmente, era hora de criar uma estrutura lean formal? Qual seria a melhor abordagem para
estabelecer a diferena entre impor melhores prticas e deixar espao para a experimentao?
14
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
-15-
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
-16-
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
-1-
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
-1-
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
-1-
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
20
612-P11
--
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
--
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.
612-P11
--
This document is authorized for use only in Hands On Management - Transformando Estrat?gia em Gest?o - 787 by Orlando Cattini Junior, FGV - EAESP from July 2015 to December 2015.