Casos de Ensino/ Gestão: O Motim da Kanchedata

TAC, Rio de Janeiro, v. 3, n. 1, pp. 62-78, Jan./Jun. 2013

Casos de Ensino / Gestão:

O Motim da Kanchedata

The Kanchedata Mutiny

Mauro Oddo Nogueira

Era uma vez...

Lima (02h40min). A essa hora da madrugada de uma quinta-feira, a despeito do bairro de

Miraflores concorrer em sua vocação boêmia com o Barranco, e mesmo estando-se em pleno verão de 2009, suas ruas estão praticamente desertas. Miraflores é o bairro comercial nobre da capital peruana. Sua artéria central, a Av. Jose Larco, caminha em direção ao sul, em direção ao mar, para desaguar em uma praça sob a qual se esconde o Larco Mar Shopping Center. Esse shopping é uma moderna e bela

construção incrustada nas falésias da capital peruana, debruçado sobre uma deslumbrante vista do oceano Pacífico. Nessa avenida, situam-se os mais modernos prédios da cidade, que abrigam os escritórios das principais empresas do país. Quem porventura passe pela avenida Av. Jose Larco nessa hora, certamente, está ou apressado demais ou alegre demais para observar que, no penúltimo andar

de um dos prédios da esquina com a Calle Alfredo Benevides, as luzes ainda estão acesas.

Nesse prédio de oito andares, funciona a Kanchedata(2)_{. As luzes acesas devem-se ao fato de}

uma reunião da diretoria da empresa, iniciada por volta das 14 horas, estar estendendo-se até esse horário. Mesmo sendo uma empresa na qual a área de produção funciona ininterruptamente, não é um fato corriqueiro em sua cultura que reuniões de diretoria atravessem as madrugadas. De modo geral, veem-se luzes acesas ao longo de toda a noite apenas no primeiro e segundo andares, onde se localizam o CPD, as áreas de impressão e de preparo de documentos. Eventualmente, também, podem ser vistas luzes nos três andares acima desses, onde estão instaladas as equipes de desenvolvimento e manutenção de sistemas: é razoavelmente comum que essas equipes virem noites trabalhando a fim de conseguirem entregar algum produto ou modificação dentro do prazo acordado com o cliente. Porém, no sexto andar, área administrativa, e nos dois últimos, destinados à diretoria, isso praticamente nunca acontece. O fato é que a Kanchedata está vivendo aquele que talvez seja o momento mais crítico de sua história. Impasses em uma negociação trabalhista ameaçam a empresa de perder seu principal produto. Nessa noite, pode estar sendo decidia sua própria sobrevivência.

Há um mês a empresa havia iniciado uma negociação de reajuste salarial com seus cerca de 2.500 empregados. Após algumas rodadas preliminares de negociação, realizadas através do sindicato, o acordo esperado apontava para um percentual de reajuste linear para todos os níveis do Plano de Cargos e Salários da companhia, que se situaria entre 4,3% de aumento, escalonado em 3 parcelas trimestrais e 11,0% a ser pago em parcela única. Evidentemente, o primeiro índice correspondia à proposta da empresa, enquanto o segundo representava a proposta apresentada pelo sindicato.

Tudo indicava que essa seria uma das negociações de reposição salarial mais tranquilas dos últimos anos. O sindicato dos profissionais de informática do Peru está entre os mais organizados, politizados e aguerridos do país. Assim como na maioria dos países latino-americanos, em virtude de suas características socioeconômicas e mão de obra de alto nível de qualificação técnica, que é algo consideravelmente escasso no mercado peruano. Portanto, o poder de barganha da categoria de profissionais de informática é enorme e sua escolaridade elevada contribui para uma maior politização e uma maior capacidade de organização. O fato é que, historicamente, as negociações salariais do segmento têm sido complicadas, com frequentes confrontos e greves. As dificuldades nas negociações sempre foram maiores nos acordos da Kanchedata, uma vez que se trata da maior empresa nacional do setor. A palavra rudeza talvez seja a que melhor descreva o ambiente de negociações que vinha sendo

estabelecido até o ano passado. Contudo, um cenário econômico mais estável, com uma inflação razoavelmente controlada jogando a favor dos empregados e uma lucratividade crescente animando a direção da empresa, tudo indicava que desta vez o processo transcorreria de forma mais serena. E era nisso que todos apostavam até há pouco mais de uma semana.

No entanto, uma reviravolta nesse quadro estava em processo de fermentação. Há exatos doze dias, a direção da Kanchedata foi surpreendida por uma reivindicação em separado por parte de um pequeno grupo de seus empregados. A equipe de analistas responsáveis pelo sistema Sistema de la Seguridad Social (SS-Sys) apresentou ao Diretor de Recursos Humanos, Ramon Gutierrez, uma carta

Plano de Cargos e Salários em que aquele conjunto específico de profissionais deveria ser enquadrado. Os salários propostos para esse quadro especial representariam reajustes médios de 250% para os

solicitantes. No documento formalmente apresentado não constava nada além da reivindicação apresentada e de seu detalhamento, ou seja, nenhuma condição de negociação era apresentada; nenhuma indicação do cacife colocado em jogo era desvelada. A barganha posta na mesa foi revelada em off; isto é, verbalmente: o analista sênior, Pedro Caballero, portador do documento e representante

do grupo, comunicou fria e secamente ao Sr. Ramon Gutierrez que, caso a reivindicação não fosse prontamente atendida em sua íntegra, todos os que haviam firmado o documento pediriam de imediato seu desligamento dos quadros da empresa.

— Chantagem imoral! - Foram as palavras utilizadas por Gutierrez, quando apresentou o malfadado documento à diretoria.

Para se entender as questões envolvidas na situação e sua gravidade para a empresa, é necessário percorrer um pouco da história da Kanchedata.

A Kanchedata

A Kanchedata é a mais antiga empresa de informática do Peru. Foi fundada na década de 60 - quando ainda se utilizavam as expressões processamento de dados e cibernética - produzindo as

primeiras folhas de pagamento automatizadas no país. Eram, então, utilizadas as máquinas Hollerit

(equipamento eletromecânico que funcionava com cartões perfurados). Os bons resultados obtidos pela empresa permitiram que essas máquinas fossem logo substituídas por modernos computadores Unisys, aposentando os velhos equipamentos, assim como as expressões citadas.

Criada por dois importantes empresários peruanos, o objetivo inicial da empresa era o de processar as folhas de pagamento das empresas de seus grupos. Gabriel Francia, um dos sócios, era proprietário de uma das principais redes de lojas de departamentos do país; Pedro Lopez controlava algumas das principais construtoras. Ambos os grupos atuavam em setores intensivos em mão de obra, o que tornava a operação das respectivas folhas de pagamento uma das atividades administrativas mais críticas para suas organizações. A partir do desenvolvimento de tecnologia para o processamento de um nascente sistema de crédito direto ao consumidor, a Kanchedata iniciou, na década de 1970, um processo de diversificação de produtos, ampliando a carteira de clientes para diversas outras empresas peruanas.

Em meados dos anos de 1970, uma conjunção de fatos acabou por criar as condições que alavancaram a Kanchedata para a primeira posição no ranking da Tecnologia de Informação no Peru.

O primeiro fato foi o falecimento de um de seus sócios, o Sr. Pedro Lopez. Seus herdeiros, que já residiam no exterior, decidiram não assumir a condução dos negócios e colocaram à venda suas participações nas empresas do pai. Diante desse fato e das perspectivas que se desenhavam para o negócio, Gabriel Francia decidiu transformá-la em uma Sociedade Anônima dessa maneira visando a um aumento de Capital Social que capitalizasse a empresa ao mesmo tempo em que assegurasse para si seu controle administrativo. Assim, as ações da Kanchedata - tanto as novas emissões quanto as que pertenciam à família Lopez - foram vendidas em pequenos lotes para inúmeros empresários peruanos.

1973, a partir da integração de diversos programas de seguridade social existentes no país. O SS-Sys, produto desenvolvido para atender esse contrato, tornou-se o principal produto da Kanchedata. A partir desse momento, teve início uma rápida e significativa expansão da empresa; processo que culminou por guindá-la, como citado, à posição de maior empresa nacional no setor.

Nesse conjunto de acontecimentos, há ainda um fator que, segundo muitos afirmam, contribuiu para que a sucessão de fatos ocorresse dessa maneira. Quando da venda das ações da empresa, a oferta foi feita para o que se poderia chamar de elite econômica nacional. Em outras palavras, os adquirentes

dessas ações eram, em grande parte, membros das famílias mais tradicionais e empresários de grande porte no país. Essa elite econômica também representava aquilo que poderia ser chamado de elite política peruana. Isso significou que passaram a ter interesses na empresa, uma vez que se tornaram

sócios minoritários dela, destacados membros das mais diversas tendências da classe política peruana. Muitos analistas sustentam que esse quadro foi determinante para que a Kanchedata não apenas obtivesse os contratos citados, mas que também assegurasse sua contínua renovação. Sendo essas suspeitas fundadas ou não, o fato é que a composição societária da empresa dá amplas margens para tais especulações.

Assim, a história da Kanchedata acaba por se confundir com a própria história do SS-Sys. E é essa história a primeira referência para que se compreenda a complexidade desse sistema, característica que está na gênese da criticidade da situação que sua diretoria enfrenta no momento.

O SS-Sys

No ano de 2009, o Peru tinha uma população aproximada de 29 milhões de habitantes. Destes, cerca de 26% eram contribuintes do sistema de previdência social estatal (a Seguridad Social) – ou

seja, aproximadamente 7,5 milhões de filiados. Além desses, a Seguridad Social atendia, na época, a

mais 2 milhões de pessoas que não contribuíam regularmente: uma parte significativa da população indígena, trabalhadores eminentemente rurais e de baixíssima renda. Em seu banco de dados, estavam armazenados cerca de 9,5 milhões de registros primários. Cada um desses registros evolui mensalmente com informações relativas aos atendimentos de seguro de saúde e às sistemáticas de pensão e de aposentadoria. A complexidade do sistema, contudo, não se origina apenas do volume de dados tratados pelo SS-Sys, mas principalmente da diversidade de tratamentos a que estes são submetidos. Essa diversidade origina-se de duas fontes principais: a dinâmica inerente a um sistema de previdência social e a história da previdência social no Peru. Na dinâmica intrínseca do sistema, cada

contrato– entende-se por contrato cada cidadão do país inscrito no sistema público de seguridade

social – deve evoluir, ou seja, ser atualizado mensalmente, ao longo de um prazo médio de 47 anos, isto é, desde a inscrição no sistema até sua aposentadoria e, a partir de então, até o falecimento do indivíduo. Ao longo desse período, o sistema deve incorporar todas as mudanças na legislação que ocorram durante o período e que afetem o sistema previdenciário. Nessa situação incluem-se as leis e regulamentos específicos da previdência, os acordos sindicais e as leis que regem as relações de trabalho, a evolução salarial e que regulamentam diversos aspectos do sistema financeiro nacional. Existem também os casos de aposentadorias antecipadas em virtude de problemas de saúde ou acidente de trabalho e que são objeto de regulamentações específicas.

Quando um segurado falece, o contrato adquire nova situação, sujeita a outra regulamentação,

situações especiais, como, por exemplo, antigos presos políticos que adquiriram direito à aposentadoria.

Finalmente, deve se ter em conta que os trabalhadores raramente seguem uma carreira profissional única ao longo de toda sua vida. Desse modo, as situações aplicáveis a cada contrato podem ser modificadas conforme o segurado muda de categoria profissional.

Ao se acrescentar, ainda, a histórica instabilidade institucional do Peru – característica típica dos países latino-americanos desde a sua independência – é possível que se faça uma ideia da variedade de modificações nos requisitos de tratamento que foram sendo introduzidas no SS-Sys ao longo dos anos.

Do ponto de vista institucional, o SS-Sys é impactado pela evolução da seguridade social no país. Em agosto 1936, foi criada a Caja Nacional del Seguro Social Obrero, inaugurando a

Seguiradade Social no Peru. Em 1973, os diversos programas então existentes foram fundidos e integrados, dando origem ao Instituto Peruano de Seguridad Social (IPSS). Em 1993, o Presidente Alberto Fujimore dá início a um processo de privatização parcial do sistema, deixando a cargo do IPSS a responsabilidade sobre os sistemas de saúde, auxílio doença e acidentes de trabalho e criando a

Oficina de Normalización Previsional (ONP), responsável pelas pensões e aposentadorias e pela

regulamentação e controle do sistema privado de Fundos de Pensão. Em 1999, o IPSS foi transformado no Seguro Social de Peru (Essalud Peru).

Essa é a primeira parte da história do SS-Sys, a história de seu modelo de negócios. Vejamos

agora a segunda parte: sua história tecnológica.

Desenvolvido no início dos anos de 1980, a tecnologia utilizada pelo SS-Sys foi a que poderia ser considerada a mais moderna para a época. Vivia-se a época áurea dos computadores de grande porte. A microinformática ainda era apenas o sonho de meia dúzia de nerds norte-americanos que

tentavam convencer o mundo de que aquela máquina esotérica, que deveria ser ligada a um televisor portátil e a um gravador K-7, tratava-se, na verdade, de um eletrodoméstico revolucionário. O SS-Sys foi, portanto, projetado para ser executado em main frames da extinta Burroughs. Em 1986, essa

empresa fundiu-se à Sperry Corporation para dar origem à atual Unisys, fabricante dos computadores ainda hoje utilizados pela Kanchedata. O ambiente computacional utilizado era baseado no sistema operacional Master Control Program

(

Burroughs para seus computadores. A linguagem empregada em seu desenvolvimento foi evidentemente o padrão vigente na época para os sistemas administrativo-financeiros: o Cobol.

Quando da concepção do SS-Sys, a Engenharia de Software ainda engatinhava como disciplina.

Documentação de sistemas era vista como uma atividade que tomava tempo, esforço e, principalmente, uma atividade burocrática indigna de profissionais criativos. À época, o prazo era o fator

determinante e os princípios de Engenharia de Software eram vistos como aumento de custos que não

traziam resultados práticos. Produziu-se, então, um sistema com mais de 4 milhões de linhas de código sem uma documentação consistente que registrasse o intrincado arcabouço de conhecimento do negócio incorporado ao produto. O resultado foi que suas regras de negócio se originam de um emaranhado jurídico cuja memória não está sistematicamente registrada e que poucas pessoas seriam capazes de reconstituir. Assim, a manutenção evolutiva do SS-Sys – que, pela natureza de seu contexto, era uma atividade quotidiana de sua equipe de desenvolvimento – depende visceralmente do conhecimento acumulado pelo pequeno grupo de analistas que acompanhava o produto desde a sua criação. Pedro Caballero faz parte desse grupo e no momento se apresenta como seu porta-voz perante a diretoria da organização.

No final dos anos de 1990, a Kanchedata deixou escapar uma excelente oportunidade para que o monopólio da equipe do SS-Sys sobre o domínio do sistema fosse rompido. O bug do ano 2000

própria posição no cargo era, em certa medida, refém daquele grupo de profissionais. Incomodava-o particularmente a liderança exercida por Affonso Marques.

Affonso é um dos mais antigos membros da equipe, mas talvez o menos capacitado tecnicamente, e, por isso, não poderia ser classificado como um dos técnicos mais brilhantes da empresa (é preciso que se admita que essa equipe reúne alguns dos melhores profissionais do país). Na verdade, a habilidade de Affonso está no trato pessoal. Atuando como elemento de ligação entre a Kanchedatta e os diversos órgãos que já foram responsáveis pela Previdência no país (atualmente são o Essalud Peru e a ONP), transita com desenvoltura em todos os seus corredores. Sua simpatia e liderança fazem com que suas portas se abram com extrema facilidade. Essa posição atribui-lhe um considerável poder político no contexto da Kanchedata e é a base de uma evidente liderança em relação ao restante da equipe de profissionais.

Na década de 1990, Raul Garcia vislumbrava na reengenharia do SS-Sys a possibilidade documentar integralmente o sistema, quebrando assim a espinha dorsal desse poder político, uma vez que retiraria do grupo o monopólio do conhecimento. Raul defendeu, junto à diretoria, que o sistema fosse integralmente refeito em uma plataforma mais moderna, o que os obrigaria a mapear todo o conhecimento nele incorporado, além de tornar as manutenções tecnicamente mais simples e o processamento mais eficiente do ponto de vista do consumo de recursos computacionais. A diretoria da Kanchedata, contudo, considerou o projeto demasiadamente custoso em relação ao que seria gasto na simples adaptação do sistema existente e não considerava os argumentos técnicos e políticos apresentados por Raul relevantes, pois acreditava que o SS-Sys era um produto cativo do governo e

não via necessidades mercadológicas que justificassem o investimento.

No início dos anos 2000, nova oportunidade foi perdida. Naquela época, a Gestão da Qualidade adquiriu importância no cenário empresarial e a Engenharia de Software começou a firmar-se como

um dos fundamentos do desenvolvimento de sistemas. Acompanhando essa onda, a Kanchedata implantou um Programa de Gestão da Qualidade com vistas à certificação ISO 9001 de seu parque de processamento e de diversos setores de desenvolvimento. Raul defendeu então que o SS-Sys fizesse parte do projeto. Mas mais uma vez a diretoria considerou que não havia determinantes mercadológicas nesse produto que fizessem com que merecesse tal distinção. Há cerca de 3 anos, a

Kanchedata expandiu seus investimentos em Qualidade e Engenharia de Software, deu mais um passo

em direção à modernização tecnológica de seus processos, iniciando um programa de certificação CMMI nível 3 e de implantação do modelo PMBOK em alguns de seus grupos de desenvolvimento. Mais uma vez, Raul tentou incluir o SS-Sys na iniciativa, argumentado que qualidade não é uma questão de marketing, mas uma questão de gestão. Novamente, Raul foi voto vencido.

Essa acomodação da diretoria não pode ser vista como negligência. Desde 1973, quando venceu a primeira concorrência para o sistema, a Kanchedata tornou-se a única empresa no Peru a deter o conhecimento necessário à prestação do serviço. Caso outra organização viesse a assumir o contrato, a estabilidade do Seguro Social Peruano estaria em risco. A complexidade do sistema tornava o governo peruano praticamente refém da Kanchedata e sua diretoria sabia disso. Ninguém imaginaria a possibilidade de um dia a empresa vir a perder o contrato. Todas as renovações contratuais foram feitas com dispensa de concorrência pública, tendo como justificativas a expertise técnica e as

questões de Segurança Nacional envolvidas no produto. O risco de uma paralisação no SS-Sys deixava o governo – qualquer que fosse – de cabelos em pé. Problemas no SS-Sys significariam a paralisação

do sistema de saúde pública peruano e o atraso no pagamento de pensões e aposentadorias. Era fácil prever que quarenta e oito horas de paralisação seriam capazes de lançar o país em uma convulsão social, colocando a própria estabilidade do governo em risco. Ou seja, o SS-Sys sempre foi um verdadeiro barril de pólvora.

Há cerca de uma década, uma empresa canadense decidiu tentar abocanhar uma parcela do mercado peruano. Entrou com todas as suas fichas na disputa de vários contratos com o governo,

minoritários da empresa. Assim, a despeito do tamanho do cacife da empresa canadense e do peso que imprimiu à disputa, não conseguiu que as renovações de contrato ocorressem através de concorrência pública. A Kanchedata saiu ilesa da ameaça e com uma confiança reforçada na estabilidade de sua posição.

O que ninguém imaginava é que o rastilho dessa mesma pólvora seria usado como poder de barganha contra ela própria. Raul não tem dúvidas de que Affonso é o principal líder e articulador do movimento reivindicatório, visto que o legado tecnológico e a complexidade no modelo de negócios são a origem da ideia dos amotinados de que a Kanchedata é refém de sua expertise.

O Motim

Desde a apresentação da reivindicação dos empregados, a Kanchedata mobilizou todos os recursos que dispunha para tentar neutralizá-la. Isso envolvia mais uma vez seus estreitos laços com o governo. Através de uma colaboração informal do Servicio de Inteligencia Nacional del Perú – SIN,

descobriu-se que não havia blefe na ameaça dos empregados. Sua intenção era de, no caso de não ver suas reivindicações atendidas, montar sua própria empresa de serviços de TI e assumir o contrato junto ao governo. Os empregados consideram que, a despeito do poder político da Kanchedata, não restaria alternativa para o governo senão transferir o contrato para eles. O que não pôde ser descoberto foi a fonte do capital necessário para estruturação dessa nova empresa. As suspeitas recaíram sobre uma nova investida da companhia canadense. O que se supõe é que há uma associação clandestina entre o grupo e essa empresa, e que o que está acordado entre eles é o estabelecimento de uma joint venture

informal.

Com esse quadro diante de si que a Diretoria da Kanchedata está reunida nesta madrugada no sétimo andar de sua sede.

Neste momento, Raul Garcia tomou a palavra:

— Eu sempre temi que algo assim ocorresse! Há mais de dez anos que eu peço recursos para fazer a reengenharia do SS-Sys, mas vocês todos sempre acreditaram que isso seria jogar dinheiro fora. Agora, está aí o quadro: não temos saída, Gabriel, se esses caras realmente saírem da empresa, o sistema não fica nem um mês no ar! E aí... Bem, acho bom começarmos a atualizar nossos currículos...

— Pois eu acho que, se cedermos, aí sim teremos de arrumar nossas coisas e procurar outro emprego. - interveio Gutierrez. — Ou você acha que vamos segurar o restante dos empregados depois de um precedente desses? Além do mais, o sindicato virá direto em nossa carótida, exigindo isonomia!

Juan Hernandez, Diretor Financeiro, que vinha tentando se manter calmo até aquele momento, explodiu:

— Não venha agora você querer jogar essa conta no nosso colo, Garcia! Você sempre defendeu essa sua reengenharia, ou seja lá como isso se chame, falando em modernização tecnológica, capacitação para a competitividade e outras baboseiras do gênero! E sempre acompanhando seu discurso com uma fatura maior que este prédio. Eu nunca na minha vida vi reengenharia para aumentar custos! Em nenhum momento, você nos disse que o SS-Sys era, na verdade, propriedade de meia dúzia de analistas metidos a besta. Sempre acreditamos que o sistema fosse nosso, da Kanche, e

que sua diretoria tinha competência técnica para dar conta dele, independentemente dos nerds que

estivessem apertando os parafusos!!!

ajudar em nada. Deixem a crucificação em praça pública para depois que passar o temporal, senão vamos todos juntos para o cadafalso e não vai ter nem praça pública para crucificação.

Nesse momento, o celular de Gabriel Francia tocou. Olhando o identificador, sua expressão ficou ainda mais carregada do que já estava.

— Salve, Presidente! Fazendo hora extra? - Tentou gracejar Francia para quebrar a tensão que percebera no cumprimento do Presidente da República ao telefone.

A informalidade no tratamento entre Francia e o Presidente da República não causava espanto. Ambos filhos da classe alta da cidade de Lima e com exatamente a mesma idade, não havia como não se conhecerem desde a primeira infância. Há quem diga que seu primeiro encontro foi no escorregador da pracinha perto de onde moravam. Não chegam a ser propriamente amigos íntimos, mas são o que se chamaria de velhos conhecidos. Esse fato certamente tornava tudo muito mais fácil para a Kanchedata.

— Gabo, a situação está complicando. Liga para mim para aquele número. - Atalhou secamente o Presidente da República e, em seguida, desligou o telefone sem mais uma palavra.

Aquilo foi como que uma senha para que Francia acendesse a luz vermelha. Seu rosto, sua expressão falou por ele. Todos ficaram de pé. Gabriel fechou o telefone e, sem uma palavra, dirigiu-se à antessala, sendo logo seguido por todos os demais. Parou diante da mesa de sua secretária:

— Mercedes, vamos continuar a nossa conversa na sala de reuniões do quarto andar. Preciso de um grande favor seu. Consiga emprestado para mim um celular de algum de nossos empregados da produção. Mas é preciso que seja uma linha pré-paga. Avisa ao dono que colocarei uma boa carga nele.

— Pode deixar, Dr. Francia, em cinco minutos estarei lá.

Após descerem para o quarto andar, Francia esclareceu o que estava acontecendo:

— Acho que, como imaginávamos, há mais coisa nisso do que parece. O Presidente me pediu para ligar para seu número reservado. É um celular completamente limpo que ele tem; isso é garantido

pelo SIN. É o número que ele usa para tratar dos assuntos mais sensíveis. Sempre há suspeita de grampos... Fico achando que eles sabem algo sobre estarmos grampeados ou, quem sabe, tenham plantado escutas por aqui. Por isso pedi um celular de alguém da produção e transferi nossa conversa para esta sala.

Após alguns minutos de um constrangedor silêncio, a Sra. Mercedes chegou à sala trazendo o aparelho pedido. Depois de cumprir a promessa de efetuar uma carga de créditos na linha, Francia ligou para o Presidente.

— Alô, sou eu. Desculpe pela demora, mas precisei conseguir um telefone limpo.

— Estou aqui com o Diretor da SIN, vou passar para ele.

— Olá, Dr. Francia. As notícias não são boas...

— Bem... vamos a elas. Estou reunido com minha diretoria e vou colocar o telefone na viva-voz.

— Tudo bem, não tem problema. Os fatos são os seguintes: não conseguimos nada de concreto que ligue os caras daí aos canadenses ou a qualquer outro grupo. Mas temos certeza de que não estão sozinhos. Primeiro, juntando tudo que todos eles têm, não conseguem levantar nem 20% do capital para montar a estrutura para processar o SS-Sys. Só que não há nenhum pedido de financiamento deles em nenhum dos bancos que operam regularmente no país, e o dinheiro é grande demais para entrar por um financiamento por fora do exterior. Além disso, há aqui um detalhe que nos chamou muito a

temos certeza que não estão blefando, porque já estão negociando com a Unisys a compra dos equipamentos. Portanto, Dr. Francia, o jogo deles é pesado e é pra valer!

— É... Já imaginávamos isso.

— Bem, vou passar de volta para o Presidente. Boa noite, Dr. Francia.

— Boa noite e muito obrigado pela ajuda.

— Pois é, Gabo. A situação de vocês é essa. Agora, vou contar a nossa situação. Se houver qualquer problema mais sério de processamento com o SS-SYs, todos os prognósticos são de convulsão social. A oposição vai montar em cima disso e atiçar o povo para rua. Daí para frente, não dá para prever o que pode acontecer. A questão é que, se isso acontecer, vocês estão liquidados. Vou ser bem objetivo: preciso de uma resposta até amanhã de manhã sobre que atitude vocês vão tomar.

— Pode deixar, Presidente. Esta noite tomamos uma decisão.

— Certo, Gabriel. Boa noite e, bem, acho que não preciso dizer mais nada.

— Não, não precisa. Boa noite e até amanhã de manhã.

Depois de desligar o telefone e dar um profundo suspiro, Francia falou para todos:

— Bem, senhores, a situação é essa. E então, o que fazemos?

— Garcia, que chance temos de assumir a operação sem esses caras e manter o sistema funcionado? _— Perguntou Ramon Gutierrez.

— Complicado... Mas não impossível. Em outros produtos nossos, temos técnicos da melhor qualidade e que conhecem muito bem o ambiente onde o SS-Sys roda e fazem mágicas em Cobol. Só que não conhecem nada do Modelo de Negócio. Na equipe do SS-Sys, temos uns garotos novos que são muito bons e que já conhecem razoavelmente o sistema e que não acredito que tenham muita participação nesse movimento. No máximo foram convidados como coadjuvantes. Ajudariam a fazer uma engenharia reversa, mas não acho que segurariam sozinhos. Precisaríamos ficar com pelo menos um dos caras da velha-guarda. Se conseguíssemos, teríamos uma chance razoável de montar uma

força-tarefa para segurar o produto no ar.

— Acho que dá para resgatar o Toledo. É um analista da velha-guarda. Conhece tudo do sistema, dizem que dorme abraçado com os manuais. É um profissional muito íntegro e fiel à empresa. Entrou aqui ainda como estagiário na faculdade e vê a Kanchedata como sua família. Tenho absoluta certeza de que está nessa levado de roldão pelos colegas. Se oferecermos a ele uma chance concreta de segurar o sistema, ele fica conosco. - ponderou Gutierrez.

Carmen Carvajal, a Diretora Comercial, que não dissera uma palavra até então, não se mostrou tão otimista:

— O problema é o Affonso. Mesmo que você consiga resolver a questão técnica, ele monopolizava os contatos com os clientes. Não vamos ter ninguém que consiga transitar como ele por lá. Sem falar que tenho sérias desconfianças de que alguns de nossos contatos no governo, se não são sócios dessa aventura, estão na mão (ou no bolso) dele. E se isso for verdade, vamos ter algumas pessoas-chave dentro dos clientes sabotando a gente. Aí, senhores, não vai ter como manter a coisa funcionando...

— Concordo com você em parte, Juanito. Na verdade, sabemos que a coisa não funciona bem assim. Nem aqui na Kanchedata, que é privada, conseguimos fazer o pessoal lá de baixo fazer tudo o que queremos. A distância entre a cabeça e os membros é grande e tem um monte de gente no caminho. Se não quiserem que aconteça, não fazem acontecer e é muito difícil conseguir impor... Até aqui entre nós, mesmo trabalhando diretamente comigo, que sou o dono disso aqui, quantas vezes, vocês não me sabotam?

— Mas acho que, neste caso, o jogo e o risco são muito pesados, Gabriel. E há interesses de muita gente do governo aqui. Acredito que, se for preciso, eles arrombarão todas as portas...

— O Ramon já deixou claro que não podemos ceder a eles, senão, não seguramos o resto da empresa. E, se arriscarmos e não segurarmos o sistema, como é que fica? - Perguntou Carmen.

— Nesse caso, não sobra um tijolo em pé aqui dentro. E eu já estou muito velho para recomeçar a vida. – ponderou Francia.

— E se deixarmos os caras saírem? Perdemos o SS-Sys, mas salvamos o resto. Quem respondeu foi Juan Hernandez:

— Nesse caso, perdemos de uma hora pra outra 30% do faturamento da empresa, além do impacto que isso representa na nossa imagem, e isso você é capaz de avaliar melhor do que eu, não é Carmen? Nessa situação, o que sobrar das paredes não vai ser capaz de segurar o resto da casa em pé.

Notas de Ensino

Resumo

Trata-se do motim dos empregados da Kanchedata: empresa fictícia que seria a maior no Peru no setor

de processamento de dados. Com capital nacional e profundas ligações com a elite do país, tem como principal cliente o Governo. Seu principal produto é o SS-Sys. Desenvolvido nos anos de 1970, seu modelo de negócios é bastante complexo, porém sua abrangência social o torna estratégico para o país. Supondo estabilidade institucional, a empresa deixou de modernizar o sistema, que se encontra

tecnologicamente obsoleto e sem documentação. Acreditando que a empresa é refém de seu domínio quanto aos conhecimentos incorporados (não documentados) ao sistema, alguns empregados decidem colocar a companhia em xeque, então, solicitando um aumento salarial acima do que seria normal. Ameaçam, por conseguinte, criar outra empresa e assumir o contrato do SS-Sys caso tal reivindicação não seja atendida. Como complicador, há pressão pessoal do Presidente do Peru, visto que um problema no sistema criaria um caos social. A questão colocada para a diretoria é atinente à qual atitude tomar perante uma crise que ameaça sua sobrevivência e que poderia ter sido evitada se um conjunto de boas práticas tivesse sido utilizado. O objetivo do caso é o de evidenciar a importância

estratégica dos fundamentos de Gestão da Qualidade em geral e da Engenharia de Software e Gestão

de Projetos no caso particular desse ramo de atividades.

Palavras-chave: gestão da qualidade; qualidade de software; gerenciamento de projetos; gestão do

conhecimento; planejamento estratégico.

Abstract

This case tells the story of a mutiny carried out by some Kanchedata employees: fictional company

envisioned to be the biggest in Peru in data processing. With state-owned capital and deep connections

with country’s elite, the company’s main customer is the Government. Its main product is the SS Sys.

Developed in the ‘70s, its business model is quite complex. However, its social scope makes it strategic for the country. Because of supposed institutional stability, the company failed to modernize

their product, which is technologically obsolete and undocumented. Believing that the company is hostage to its domain of embedded knowledge (undocumented/tacit knowledge), some employees decided to put the company in a difficult situation by requesting a salary increase above what would be normal. They threatened to create another company and take over the SS Sys contracts. As a complication, there is personal pressure from the Peruvian President on the company, as a problem in the system would launch social chaos. The question for the board is what attitude to take towards a crisis that threatens the company’s survival and that could have been avoided if a set of best practices

had been used. The goal of this case is to highlight the importance of the strategic fundamentals of Quality Management in general and Software Engineering and Project Management in the case of this particular line of business.

Key words: quality management; software quality; project management; knowledge management;

strategic planning.

Objetivos

Trata-se de um armchair case– em forma de ficção – no qual são descaracterizadas diversas

situações vivenciadas pelo autor ao longo de sua vida profissional. Assim, quaisquer semelhanças com pessoas, fatos, situações, nomes, datas ou acontecimentos reais são mera coincidência.

O caso foi escrito com o objetivo de evidenciar a importância dos procedimentos formais da Gestão da Qualidade nas atividades de desenvolvimento de software. A proposta inicial é de que seja

Gerenciamento de Projetos. Para seu desenvolvimento é necessário que os alunos já tenham adquirido os conhecimentos fundamentais acerca da Gestão Formal de Projetos, ou seja, já tenham cursado as disciplinas que apresentam os modelos de Ciclo de Vida de Projeto, com seus respectivos processos fundamentais, bem como os aspectos relacionados à sua formalização. Assim, o caso atua como elemento introdutório para o estabelecimento do relacionamento entre os preceitos da Gestão de Projetos e os da Gestão da Qualidade. Deve, portanto, ser empregado antes de serem ministrados os conceitos de Gestão da Qualidade e seus respectivos modelos formais.

A partir da evidência do nível de dependência da empresa em relação aos profissionais envolvidos na manutenção do sistema, os alunos são levados a discutir a questão dos custos relacionados às atividades de documentação de sistemas versus os custos potenciais decorrentes da

não realização dessa atividade. É importante que o termo custos seja entendido em suas diversas

formas de manifestação; isto é, tanto no que concerne aos recursos alocados diretamente nessas atividades quanto aos impactos no quotidiano da organização que delas decorrem. Nesta discussão, devem ser abordados também os fatores políticos internos das organizações que podem fazer com que os princípios de Gestão da Qualidade e de Engenharia de Software acabem por ser negligenciados.

Assim, tratar-se-ia de um caso especificamente destinado à análise das decisões já tomadas pela empresa. Todavia a situação de crise na qual o caso se situa permite que seja utilizado para a definição de uma decisão a ser tomada. Essa abordagem permite que o mesmo seja também empregado no ensino de diversas outras disciplinas, tais como Gestão de Projetos, Gestão de Pessoas, Gestão do Conhecimento, Planejamento Estratégico, Gerenciamento de Riscos, Gerenciamento de Crises, entre outras.

Questões para discussão

1. De que modo a ideia de Gestão Formal de Projetos pode ser associada à questão da Qualidade na organização (incluir, nas considerações, uma análise da dicotomia formalidade X informalidade tanto na GP quanto na GQ)?

2. Como correlacionar a dependência da Kanchedata em relação a seus analistas com os preceitos da Gestão da Qualidade e da Engenharia de Software?

3. Que medidas deveriam ter sido tomadas para que a empresa não chegasse a tal situação? Em que momentos?

4. Que fatores impediram que tais ações fossem efetivadas? O que poderia ter sido feito para que isso não ocorresse?

5. Que lições a empresa deve levar para a condução futura de seus negócios?

Análise

Conforme citado, o caso pode ser utilizado para a discussão de uma série de temas relacionados à Gestão. Entretanto seu tema central relaciona-se a questões situadas no âmbito da Gestão da Qualidade, particularmente, da Qualidade de Software.

O caso situa-se no contexto de um dos pontos mais controversos da Qualidade de Software: o

volume de esforços necessários para a adoção das práticas preconizadas por essa disciplina, bem como pela Engenharia de Software; disciplina que lhe é complementar, assim como os impactos de tais

práticas no quotidiano do desenvolvimento de sistemas.

O que se observa é que a indústria do software tem sido muito reativa à implantação dos

Duas são as origens explícitas dessa reação: a primeira está associada aos aspectos de custo; a

segunda ao prazo de desenvolvimento e manutenção de software.

O fato é que as práticas consagradas da Gestão da Qualidade, de modo geral, pressupõem um considerável grau de formalização de suas atividades. Isso significa que exigem o estabelecimento de procedimentos escritos para sua realização e, principalmente, a elaboração de registros formais das tarefas realizadas. A questão controversa leva em conta a necessidade, na concretização dessa formalização, de uma significativa quantidade de recursos, o que se traduz, consequentemente, em uma elevação imediata dos gastos em mão de obra nos projetos e em uma significativa dilatação dos prazos de entrega dos sistemas. O tratamento desses gastos como custos diretos de produção, sem a contraposição dos custos potenciais que são evitados a partir de seu emprego, resulta em um impacto negativo nas planilhas de custos e, como decorrência, uma elevação dos preços finais dos produtos e perda de competitividade.

O principal argumento apresentado pelos desenvolvedores que se posicionam contra tais práticas é o de que seus resultados somente se mostram visíveis em longo prazo, mas sua adoção leva a uma perda de competitividade no curto prazo que inviabilizaria o negócio. Argumenta-se que o mercado consumidor de produtos de software, particularmente de produtos sob encomenda, não se

encontra maduro o suficiente para valorizar adequadamente os aspectos de qualidade dos produtos. Sustenta-se que as decisões de compra são definidas primordialmente a partir dos critérios de preço e prazo; ou seja, os clientes, de modo geral, compram o produto daquele fornecedor que apresentar o menor preço final. Considerações em relação ao fato de que preços baixos e prazos reduzidos implicam em produtos que exigirão um considerável volume de manutenções corretivas posteriores, cujos impactos nos custos do produto e nas operações da organização adquirente superariam o baixo preço inicial, não são levadas em conta pelos contratantes. Acredita-se que o mercado de software é

pautado eminentemente por uma perspectiva de curto prazo.

Assim sendo, mesmo admitindo que a utilização dos modelos de Qualidade e Engenharia de

Software implicam em uma importante eliminação de fontes de problemas futuros, esses profissionais

sustentam que os clientes não levam esses fatores em consideração quando contratam o desenvolvimento de um produto. Portanto a empresa que decidir por adotar tais práticas acaba por se deparar com uma encruzilhada: incluir os custos de tais práticas nos preços, tornando-os mais altos do que os concorrentes e se arriscando a não conseguir vender seus serviços; ou assumir os custos sem incorporá-los ao preço, arriscando-se a inviabilizar a margem de lucros do negócio.

Ainda no mesmo contexto, há a argumentação que se baseia numa característica peculiar dessa indústria, que é a premência de tempo. A situação mais comum nesse mercado é a de exigências de prazos muito apertados, em que os clientes solicitam que o produto seja entregue o mais rapidamente possível. Práticas de Qualidade e Engenharia de Software implicam em um aumento do prazo de

desenvolvimento ou manutenção do produto – isto é, do prazo de entrega. Situação que, via de regra, não é aceita pelos clientes. Mais uma vez coloca-se a Gestão da Qualidade e a Engenharia de Software

como fatores potencialmente comprometedores da competitividade da empresa frente a um mercado consumidor insuficiente maduro para elas.

Em outras palavras, ambos os argumentos baseiam-se na tese de que o cliente não está preocupado com qualidade, mas com preços e prazos. Entretanto o que se observa no mercado é uma insatisfação generalizada por parte dos compradores de serviços de desenvolvimento de software em

relação aos resultados alcançados pelos produtos adquiridos.

Na condução do estudo do caso proposto, essa dicotomia entre custo e prazos X preços deve

ser tratada como um dos eixos centrais de discussão. O caso evidencia essa situação particularmente através das posições assumidas pelo Sr. Juan Hernandez, Diretor Financeiro.

O segundo fator explícito importante que alimenta essa controvérsia é que a formalização das

questões associadas à própria história do desenvolvimento e da afirmação dessa atividade que não cabem aqui ser discutidas – tendem a perceber seu trabalho como fundamentalmente criativo, análogo

a outras áreas da criação humana, tais como as atividades de criação em publicidade, de Design de

Produtos, de Pesquisa & Desenvolvimento, etc. Assim sendo, a imposição de formalização de processos é rejeitada culturalmente como elemento inibidor e constrangedor da liberdade necessária aos processos de criação. O paralelo entre a atividade de desenvolvimento de software com os diversos

ramos das engenharias, que também incorporam consideráveis parcelas de trabalho criativo, mas que,

a despeito disso, são estritamente submetidos a normatizações e a sistemáticas de formalização, é negligenciado.

Esses são os aspectos que se constituem no pano de fundo para a discussão da primeira questão colocada. A partir dos conceitos de Gestão Formal de Projetos, a discussão deve conduzir ao estabelecimento dos paralelos entre esta e os Modelos de Gestão da Qualidade, de modo especial aos aspectos relacionados à formalização e registro de processos. Esse paralelo deve evidenciar a superposição de conceitos e a complementaridade que se observa entre esses dois paradigmas. A partir disso, o caso evidencia as dificuldades normalmente enfrentadas quando se tenta substituir uma cultura de condução informal e ad hoc de projetos por sistemáticas formalizantes.

Para a discussão da segunda questão, deve ser considerada uma outra motivação para a reatividade citada e que lhe é subjacente. Sua origem também se fundamenta nos aspectos culturais da indústria de software e dificilmente é explicitada por alguém. Trata-se do controle do processo como

um todo. As práticas de Gestão da Qualidade e de Engenharia de Software levam à retirada do controle

do processo e o domínio do conhecimento incorporado ao produto da mão dos indivíduos que o executam para colocá-los sob o controle da organização. Desde seu surgimento, a informática colocou-se de certo modo como uma ciência esotérica, restrita aos iniciados. Uma vez que seu objeto

é a informação, essa característica transformou-se um uma importante fonte de poder. É evidente que

formalizar processos e registrar atividades não somente retira o controle do processo das mãos dos profissionais diretamente envolvidos no processo de desenvolvimento e/ou manutenção, como cria mecanismos para que esses sejam controlados por outras instâncias das organizações. Assim, nada mais natural do que uma reação à adoção de tais métodos por parte daqueles que detinham seu controle.

É exatamente esse fenômeno que produz toda a situação vivida pela Kanchedata. Consciente ou inconscientemente – a situação descrita não permite qualquer ilação a esse respeito – os profissionais da área de desenvolvimento não deram suporte às iniciativas de implantação de modelos formais de Gestão da Qualidade. Isso impediu a apropriação, por parte da companhia, isto é, a apropriação institucional e não individual, do conjunto de conhecimentos necessários à manutenção do produto. Assim sendo, em função da complexidade do SS-Sys, tanto no que diz respeito às dimensões do produto (cerca de 4 milhões de linhas de código, o que evidencia o grau de complexidade do modelo) quanto em relação à sua longevidade em um contexto historicamente conturbado, esses conhecimentos foram sendo monopolizados por um grupo restrito de profissionais. Isso se transformou no principal instrumento de pressão e de barganha utilizado por esses profissionais no processo de negociação salarial descrito.

Assim, o caso da Kanchedata ilustra uma situação muito comum nessa indústria, na qual a adoção de modelos de Gestão da Qualidade e de Engenharia de Software foram sistematicamente

adiadas e descartadas quase que a priori, sem que fossem mesmo submetidas a uma discussão e

avaliação consistentes e conscientes. No caso, verificam-se as três situações descritas: as questões relacionadas a preços e prazos e as questões culturais. O resultado é o que se esperaria: o comprometimento no longo prazo do processo como um todo em função de decisões tomadas (ou não tomadas) a partir das perspectivas no curto prazo.

Em relação à terceira questão, podem ser identificados pelo menos dois momentos importantes nos quais a direção da empresa poderia ter utilizado como oportunidade para a implantação das práticas de Gestão da Qualidade. O primeiro deles foi quando da ameaça do bug do ano 2000. Naquela

necessariamente, foi efetuado um completo mapeamento do sistema. Uma vez que esse trabalho deveria ser feito de qualquer maneira e que o volume de mão de obra exigido seria significativo, este seria o momento propício para realizar uma reengenharia completa do produto. Essa reengenharia permitiria a migração do produto para uma plataforma tecnológica mais moderna, que possibilitaria uma modelagem mais eficiente dos processos, maior manutenibilidade e uma maior eficiência no processamento. Ou seja, a partir de um relativamente pequeno investimento agregado ao custo da tarefa de adequar o SS-Sys ao bug do ano 2000, obter-se-ia uma redução nos custos gerais de operação

do sistema, tanto em mão de obra para suas futuras manutenções adaptativas e evolutivas quanto em recursos computacionais para sua operação, além de um aumento geral na confiabilidade do produto.

Entretanto essa questão do ganho nos custos diretos do produto não seria a única vantagem. Aliás, Raul Garcia, o Diretor Técnico, tinha absoluta clareza desse quadro e percebeu a oportunidade para documentar o sistema e formalizar seu processo de manutenção, reassumindo, a partir disso, o controle político daquela equipe, que ele percebia estar esvaindo-se. Porém não foi capaz de sustentar politicamente seus argumentos, sendo sobrepujado pela argumentação do custo e por uma perspectiva de autoconfiança decorrente de uma situação de suposto monopólio.

A segunda grande oportunidade perdida ocorreu pouco depois da virada do milênio. Acompanhando a tendência geral do mercado na época, a Kanchedata implantou um programa de Gestão da Qualidade baseado no modelo ISO 9001 com vistas à certificação de parte da organização. Nesse momento, o Sr. Garcia vislumbrou uma nova oportunidade para que a organização reassumisse o controle sobre o sistema. O modelo ISO 9001 tem a documentação dos produtos e a formalização dos processos como um de seus fundamentos. O Sr. Garcia entendeu que, através da implementação dessas práticas, seria possível que a Kanchedata incorporasse institucionalmente o conhecimento agregado ao longo dos anos ao produto, o qual vinha sendo monopolizado por sua equipe. Sendo a implantação de um Sistema de Gestão da Qualidade uma ação necessariamente tratada no âmbito estratégico da organização – caso contrário, dificilmente se consegue obter um Certificado de Conformidade – as possíveis (e prováveis) reações internas da equipe do SS-Sys às praticas formalizantes seriam facilmente sobrepujadas. Assim sendo, a extensão do programa de certificação para a área de manutenção do SS-Sys solucionaria plenamente as angústias do Diretor Técnico.

Novamente, a diretoria da empresa não foi capaz de compreender a gravidade dos riscos que se delineavam e manteve sua perspectiva de tomada de decisões tendo como premissa um quadro de suposto monopólio, e, mais uma vez, o Sr. Raul Garcia não foi capaz de fazer com que seus pares compartilhassem das suas preocupações.

A quarta questão trata dos fatores que impediram que a Kanchedata implantasse, nos processos relacionados ao SS-Sys, as citadas práticas de Gestão da Qualidade e as de Gestão Formal de Projetos a elas associadas. Nas duas oportunidades identificadas, esses fatores foram essencialmente os mesmos: uma perspectiva baseada em análises de fluxo de caixa (presente e pretérito); e uma avaliação do mercado, do produto e de seu relacionamento com o Governo do Peru que pressupunha a existência de um virtual monopólio por parte da empresa.

Na essência, a posição reiteradamente assumida pela diretoria da Kanchedata decorre da ausência de uma compreensão clara de todos os possíveis desdobramentos e de toda a abrangência que são inerentes à questão da Gestão da Qualidade. No caso específico, foram negligenciados os impactos que seriam esperados a partir da implantação de um modelo de Sistema de Gestão da Qualidade particularmente nos aspectos concernentes ao contexto político da empresa (interno e externo), aos aspectos comportamentais e aos operacionais da organização, bem como suas consequentes repercussões nos custos totais.

A utilização, por exemplo, da ferramenta denominada Custos da Qualidade poderia ter

evidenciado esses equívocos. O modelo de Custos da Qualidade, diferentemente da sistemática tradicional da Contabilidade de Custos, incorpora não somente os fatos geradores efetivamente

possibilidades concretas de virem a ocorrer. Esse modelo se baseia em uma sistemática específica –

associada a um Plano de Contas também específico – para a consolidação dos chamados Custos de Prevenção, Custos de Avaliação, Custos de Falhas Internas e Custos de Falhas Externas. A

combinação e comparação desses custos é um instrumento extremamente eficaz para a tomada de decisões relativas aos investimentos em Qualidade.

O modelo por si só já teria sido provavelmente suficiente para evidenciar as vantagens financeiras que teriam advindo da implantação do Sistema de Gestão da Qualidade. Porém, além disso, uma formulação consistente dos Custos de Falhas, particularmente dos Custos de Falhas Externas

exige a realização de uma acurada Análise de Riscos. É de se supor que essa análise evidenciaria os riscos associados, por um lado, ao monopólio das informações relativas ao produto que era detido pela equipe do SS-Sys; e, por outro, da fragilidade do monopólio comercial que era assumido como assegurado pela diretoria.

A última questão trata das lições aprendidas. Essa questão representa, na verdade, uma síntese

das questões anteriores. A partir dos percalços vivenciados pela empresa e que são resultados de decisões equivocadas ou inadequadas e ações que não foram tomadas no momento correto ou aproveitando-se de uma oportunidade propícia, é possível definir uma postura que deve ser adotada para a empresa no futuro. Assim, devem ser avaliadas as alternativas e possibilidades que estão colocadas no presente para que a empresa supere a crise e desenvolva mecanismos para evitar que situações como essa venham a se repetir.

Finalmente, deve ser observado que as cinco questões apresentadas para discussão do caso em sala de aula tratam de uma análise pretérita da organização e sempre tendo como objeto de estudo as questões relacionadas à Gestão da Qualidade. Elas têm por objetivo evidenciar situações vividas pela empresa a partir de decisões que já foram tomadas e possibilitar uma discussão atinente aos fatos ocorridos, motivações da empresa para conduzi-los da forma que o fez e possibilidades existentes para que a situação presente descrita não tivesse ocorrido. A perspectiva de futuro coloca-se, também, no mesmo contexto teórico e a partir de uma referência ao passado: trata-se da discussão das atitudes que devem ser tomadas no futuro para que se evite que fatos como os narrados venham a se repetir. Todavia, conforme citado na parte introdutória da presente Nota de Ensino, o caso da Kanchedata oferece outras oportunidades de estudo em diversos outros temas. Uma dessas possibilidades considera o fato de que a empresa vive uma crise de extrema gravidade no presente e que exige uma tomada de decisão em uma situação crítica. Assim, o caso pode ser empregado com a abordagem de um caso para tomada de decisão, podendo ser utilizado dessa maneira como instrumento didático

para diversas disciplinas da área de Gestão Organizacional.

Indicações bibliográficas

Associação Brasileira de Normas Técnicas. (2003). NBR ISO 10006:2003 – Gestão da qualidade – Diretrizes para a qualidade no gerenciamento de Projetos. Rio de Janeiro: Autor.

Associação Brasileira de Normas Técnicas. (2008). NBR ISO 9001:2008 – Sistemas de gestão da qualidade – Requisitos. Rio de Janeiro: Autor.

Brocka, B., & Brocka, M. S. (1994) Gerenciamento da qualidade. São Paulo: Makron Books.

Carnegie Mellon University, Software Engineering Institute. (2012). Capability maturity model integration. Pittsburgh. Recuperado de http://www.sei.cmu.edu/cmmi

Carvalho, A. M. B. R., & Chiossi, T. C. S. dos (2001). Introdução à engenharia de Software.

Campinas: Editora da Unicamp.

Cerqueira, E. P., Neto de (2011). Gestão de mudanças. São Paulo: All Print Editora.

Demarco, T., & Lister, T. (1990). Peopleware: como gerenciar equipes e projetos tornando-os mais competitivos. São Paulo: Makron Books do Brasil / McGraw Hill.

Feigenbaun, A. V. (1991). Total quality control. New York: McGraw-Hill International Editors.

Fleury, M. T. L., & Oliveira, M. M., Jr. de (Org.). (2001). Gestão estratégica do conhecimento: integrando aprendizagem, conhecimento e competências. Rio de Janeiro: Atlas.

Heldman, K. (2006). Gerência de projetos: guia para o exame oficial do PMI. Rio de Janeiro: Ed.

Campus.

International Organization for Standardization. (2004). ISO/IEC 90003:2004 – Software engineering – Guidelines for the application of ISO 9001:2000 to computer software. Geneva: Author.

Juran, J. M. (2009). A qualidade desde o projeto: novos passos para o planejamento da qualidade em produtos e serviços. São Paulo: Cengage Learning.

Juran, J. M. (2010). Juran’s quality control handbook. New York / Singapure: McGraw-Hill, INC.

Kerzner, H. (2011). Gerenciamento de projetos: uma abordagem sistêmica para planejamento, programação e controle. São Paulo: Blucher.

Meredith, J. R. (2003). Administração de projetos: uma abordagem gerencial. Rio de Janeiro: Ltc

Editora.

Pfleeger, S. L. (2004). Engenharia de software: teoria e prática. São Paulo: Prentice Hall.

Pressman, R. S. (2002). Engenharia de software. Rio de Janeiro: McGraw-Hill.

Rocha, A. R. C. da, Maldonado, J. C., & Weber, K. C. (2001). Qualidade de software: teoria e prática. São Paulo: Prentice HalL.

Sommerville, I. (2011). Engenharia de software. São Paulo: Pearson Education do Brasil.

Vergara, S. C. (2012) Gestão de pessoas. São Paulo: Atlas.

Agradecimentos

Gostaria de agradecer ao Prof. Kleber Fossati por seus valiosíssimos ensinamentos, conselhos e comentários. Contudo registro que todas as responsabilidades sobre as inevitáveis falhas deste texto são integralmente minhas.

Notas

1 _{Este caso é uma obra de ficção. Sua ambientação no Peru deveu-se a uma escolha aleatória por parte do autor. Quaisquer}

semelhanças com pessoas, fatos, situações, nomes, datas ou acontecimentos reais, exceção aos acontecimentos históricos de conhecimento público, são mera coincidência.

2