Fábrica de Software: Até Que Ponto Fordista?

Fundação Getulio Vargas
Escola Brasileira de Administração Pública e de Empresas

Centro de Formação Acadêmica e Pesquisa
Curso de Mestrado em Gestão Empresarial
CRISTINA DEORSOLA XAVIER
FÁBRICA DE SOFTWARE: ATÉ QUE PONTO FORDISTA?
DISSERTAÇÃO DE MESTRADO
Orientador: Prof. Dr. Fernando Guilherme Tenório
Rio de Janeiro
2008
2
DEDICATÓRIA
Aos meus pais, que desde sempre incentivaram e apoiaram

integralmente todas as minhas empreitadas.
À minha filha Luísa, sempre compreensiva e colaborativa

durante todo o curso.
Ao Adymar, companheiro de todas as horas, fonte de inspiração

e grande responsável por eu ter mantido o foco e logrado êxito
na concretização desse sonho.
3
AGRADECIMENTOS
A Ele, por me proporcionar a oportunidade e as condições de

vencer esse desafio.
Ao Professor Doutor Tenório, pela orientação tão enriquecedora

e serena, e pelas inestimáveis horas de discussão com o grupo de
estudo, que tanto me ajudaram a encontrar o caminho.
A todos os professores do curso de mestrado em gestão

empresarial da FGV-RJ, pelos preciosos ensinamentos, e
sobretudo por ampliarem de forma tão significativa minha visão.
Aos colegas do mestrado, pelo companheirismo, apoio e

estímulo demonstrado durante todo o curso.
4
RESUMO
Com a crise da automação rígida (década de 60), têm sido paulatinamente flexibilizados os
modelos de gestão outrora de cunho fordista; porém, as fábricas de software, ao surgirem nos
anos 90, fabricando produtos tecnologicamente os mais avançados e adotando controles
eminentemente fordistas, parecem estar seguindo na contramão do ciclo de evolução das
organizações.
A alternância de características de rigidez e flexibilidade dos modelos de gestão dessas

fábricas, observados sob o continuum fordismo (0) ______(1) pós-fordismo, bem como as
limitações dessa metáfora dada a natureza do produto software, constituem o objeto do
estudo.
Palavras-chave: fábrica de software; fordismo; flexibilização; metáfora; gestão do

conhecimento
5
ABSTRACT
Due to the crisis over rigid automation that occurred around 1960, management models
essentially fordist, have gradually become more flexible. The software factories, however,
that emerged in the nineties manufacturing the most advanced technological products,
adopted eminently fordist controls and seem to be going contrary to the evolutionary cycle
that organizations tend to follow.
The alternation between rigid and flexible management models of these software factories,
observed under continuum fordism (0) ______ (1) post-fordism, as well as the limitations of
the metaphor that emerges given the nature of the software they manufacture, constitutes the
object of the study.
Key Words: software factory, fordism, flexibility, metaphor, knowledge management

6
LISTA DE ABREVIATURAS E TERMOS
ASD Adaptative Software Development – Desenvolvimento de Software

Adaptado
CMM Capability Maturity Model
CPD Centro de Processamento de Dados
ERP Enterprise Resource Planning – Planejamento dos Recursos da Empresa
ISO International Organization for Standardization – Organização
Internacional para Padronização/Normalização
JAVA Linguagem de programação orientada a objeto, pertencente à plataforma
de desenvolvimento de sistemas de mesmo nome
LD Lean Development - Desenvolvimento “leve”
MTM Method Time Measurement – Método de Medição do Tempo
.NET Plataforma de desenvolvimento de sistemas, da Microsoft (lê-se dot net)
OO Orientação a Objetos (metodologia de desenvolvimento de sistemas)
PL1 Linguagem de programação procedural
Ponto de Função Métrica de mensuração de porte de software (FPA)
PMI Project Management Institute – Instituto de Gerenciamento de Projeto
RUP Rational Unified Process - Processos Unificados da Rational (empresa
IBM), metodologia de gestão de desenvolvimento de software
SLA Service Level Agreement - Acordo de Níveis de Serviço
SPL Software Product Line - Linha de Produto de Software
TI Tecnologia da Informação
UML Unified Modeling Language – linguagem de modelagem de sistemas, que
permite aos desenvolvedores visualizarem seu trabalho através de
diagramas padronizados
XML eXtensible Markup Language – linguagem de marcação (formatação de
textos ou dados)
XP eXtreme Programming - metodologia de desenvolvimento de sistemas
do tipo “ágil”
7
LISTA DE ILUSTRAÇÕES
FIGURA 1 Evolução do Desenvolvimento do Software ------------------------ 14

FIGURA 2 Gráfico Produtividade x Flexibilidade ------------------------------16
FIGURA 3 Fotografia 1 da Ambientação da Fábrica -------------------------- 31
FIGURA 4 Fotografia 2 da Ambientação da Fábrica -------------------------- 32
FIGURA 5 Diagrama da Esteira de Produção da Fábrica -------------------- 33
FIGURA 6 Escopo de Fornecimento da Fábrica ------------------------------- 35
FIGURA 7 Fronteira Projeto – Execução ---------------------------------------- 37
FIGURA 8 Diagrama da Pré-Estrutura da Fábrica A ------------------------ 50
FIGURA 9 Diagrama da Estrutura Inicial da Fábrica A --------------------- 51
FIGURA 10 Diagrama da Estrutura da Fábrica A durante o Estudo ------- 52
FIGURA 11 Comparativo de Competências - Fábricas A e B ----------------- 56
FIGURA 12 Atribuições x Competências - Fábrica B --------------------------- 57
8
LISTA DE TABELAS
TABELA 1 Resultado Tabulação Questão 1 -------------------------------------- 58

TABELA 2 Resultado Tabulação Questão 2.1 ------------------------------------ 66
TABELA 14 Resultado Tabulação Escolaridade Superior ---------------------- 72
TABELA 15 Resultado Tabulação Área Curso Superior ------------------------ 72
TABELA 16 Resultado Tabulação Sexo --------------------------------------------- 72
TABELA 17 Resultado Tabulação Faixa Etária ----------------------------------- 73
TABELA 18 Resultado Tabulação Faixa Salarial --------------------------------- 73
TABELA 19 Resultado Tabulação Tempo Experiência em TI ----------------- 74
TABELA 20 Resultado Tabulação Tempo Experiência Fábrica Software --- 74
9
SUMÁRIO
1 Introdução--------------------------------------------------------------------------- 11
2 Fundamentação Teórica---------------------------------------------------------- 19
2.1 Metáfora ----------------------------------------------------------------------------- 19
2.2 Taylorismo -------------------------------------------------------------------------- 21
2.3 Fordismo ---------------------------------------------------------------------------- 23
2.4 Pós-Fordismo ----------------------------------------------------------------------- 28
2.5 Fábricas de Software -------------------------------------------------------------- 30
2.5.1 Conceituação ----------------------------------------------------------------------- 30
2.5.2 Processos de Desenvolvimento de Software ---------------------------------- 37
2.6 Gestão do Conhecimento -------------------------------------------------------- 42
3 Metodolgia ------------------------------------------------------------------------ 46
3.1 Tipo de Pesquisa ------------------------------------------------------------------ 46
3.2 Universo da Amostra ------------------------------------------------------------- 47
3.2.1 Fábrica A --------------------------------------------------------------------------- 48
3.2.1.1 Origens da Fábrica A ------------------------------------------------------------- 48
3.2.1.2 Estrutura da Fábrica A ----------------------------------------------------------- 52
3.2.2 Fábrica B --------------------------------------------------------------------------- 53
3.2.2.1 Origens da Fábrica B ------------------------------------------------------------- 54
3.2.2.2 Estrutura da Fábrica B ----------------------------------------------------------- 54
3.3 Seleção dos Sujeitos -------------------------------------------------------------- 58
3.4 Coleta de Dados ------------------------------------------------------------------- 59
3.5 Tratamento dos Dados ------------------------------------------------------------ 60
3.6 Limitações do Método ------------------------------------------------------------ 61
4 Apresentação dos Dados -------------------------------------------------------- 62

4.1 Dados Globais ---------------------------------------------------------------------- 66
4.1.1 Dados Sobre Gestão do Conhecimento ----------------------------------------- 66
4.1.2 Dados Sobre Origem da Formação Requerida---------------------------------- 68
4.1.3 Dados Sobre Percepção do Modelo Fabril -------------------------------------- 68
10
4.1.4 Dados Sobre Público Alvo -------------------------------------------------------- 72
5 Conclusões e Recomendações --------------------------------------------------- 75
Anexo I - Questionário Aplicado na Fábrica A ------------------------------------------- 81

Anexo II - Questionário Aplicado na Fábrica B ------------------------------------------ 85
Anexo III - Roteiro das Entrevistas --------------------------------------------------------- 89
Bibliogafia ------------------------------------------------------------------------------------ 92
11
1 – Introdução
Com a crise da automação rígida (década de 60), têm sido paulatinamente

flexibilizados os modelos de gestão outrora de cunho fordista; porém, as fábricas de software,
ao surgirem nos anos 90, fabricando produtos tecnologicamente os mais avançados e
adotando controles eminentemente fordistas, parecem estar seguindo na contramão do ciclo
de evolução das organizações.
Para Cusumano (1989), um processo fabril produz em massa, através de operações

centralizadas de larga escala, sob controles padronizados; é baseado na divisão do trabalho, na
mecanização e automação dos processos; os trabalhadores são especializados, mas com
poucas habilidades.
A associação metafórica dos termos fábrica e esteira de produção a desenvolvimento

de software sugere a aplicação de técnicas para produção em larga escala, de forma
coordenada e com qualidade.
A alternância de características de rigidez e flexibilidade dos modelos de gestão dessas

__________
fábricas, observados sob o continuum fordismo (0) (1) pós-fordismo, bem como as
limitações dessa metáfora dada a natureza do produto software, instigaram o presente estudo
considerando que:
• O produto software é de natureza abstrata praticamente durante todo o ciclo de
desenvolvimento;
• Cada software desenvolvido é um produto único, que uma vez pronto serve de
matriz para inúmeras cópias, que por sua vez são fabricadas através de processo
extremamente mais simples que o de construção do software original;
• A qualificação exigida da mão-de-obra de uma fábrica de software vem
acompanhada do inconformismo com tarefas repetitivas.
Segundo Fernström et alli (apud Medeiros et alli: p. 2), a fábrica clássica, onde as
pessoas atuam como máquinas na realização de tarefas pré-determinadas, não é um modelo
nem desejável nem correto para fabricação de software. No contexto de software, a analogia
com a fábrica pode ser aplicada apenas aos objetivos da produção baseada no estilo industrial,
12
e não na sua implementação. A manufatura de software envolve pouca ou nenhuma produção

tradicional: todo sistema é único, apenas partes individuais podem aparecer repetidamente em
mais de um sistema.
Para melhor contextualizar o estágio da indústria de TI - Tecnologia da informação,

em que a força de uma metáfora impulsionou organizações a reestruturar seu modelo de
produção, apostando em maiores lucros, vamos a um breve histórico.
Quando surgiram os computadores e a Informática, a maioria da mão-de-obra alocada

nos serviços de desenvolvimento e manutenção de sistemas1 (software) era percebida como
pessoas “diferentes” das demais.
Analistas de sistemas2 e programadores3 eram vistos como “seres iluminados”,

altamente criativos. Muitas inclusive eram identificadas pela sua forma de vestir, descontraída
e despojada, não raro excêntrica, quase sempre destoando daquela dos empregados de outros
departamentos da organização onde trabalhavam. O horário de trabalho deles também era
diferenciado dos demais, mais flexível em função das inúmeras “noites viradas”, e “finais de
semana dobrados”.
Tinha-se a impressão de que os serviços que lhes eram encomendados, tanto pela
complexidade como pela extensão, sempre extrapolavam o prazo requerido, dada a
permanente tensão fruto do empirismo e da inexistência, na época, de métodos de apoio ao
raciocínio nem de otimização de tarefas. Essa era a realidade observada nos centros de
processamento de dados (CPD), sítio na época desse serviço. A esses profissionais eram
exigidas boas idéias a cada momento, o que lhes conferia o bônus do reconhecimento, mas
também o ônus do desgaste físico e emocional.
____________________________
1
Sistema (software) corresponde a um conjunto de programas
2
Analistas de Sistemas projetam lógica e fisicamente o software, e especificam cada programa (regras de
negócio a serem implementadas, modelos de telas, relatórios, dados de entrada e de saída)
3
Programadores modelam o fluxo lógico de cada programa, criam algoritmos e implementam a solução,
codificando o programa na linguagem de programação pré-determinada pela arquitetura do software
13
Gradativamente, as metodologias de programação e modelagem de sistemas foram

disciplinando o processo de desenvolvimento, e os analistas e programadores passaram a
depender cada vez menos da inspiração. A utilização de técnicas estruturadas passou a ser
fundamental para viabilizar a contínua manutenção dos sistemas desenvolvidos, tanto
corretiva como evolutiva, dado que os sistemas precisam refletir as mudanças do campo das
necessidades dos usuários.
Indo aos extremos, aquela criatividade que anteriormente chegou a ser “endeusada”,
passou a ser “mal-vista”, pois produzia aqueles sistemas e programas que muitas vezes só o
desenvolvedor era capaz de dar manutenção.
Conforme descrito por Jean-Dominique Warnier (1986), a especificação do programa

a ser desenvolvido que o analista de sistemas repassava ao programador, às vezes
acompanhada de uma vaga descrição do problema, usualmente consistia apenas de um
fluxograma, que demonstrava a seqüência de instruções a codificar na linguagem de
programação.
Um grande avanço ocorreu em meados dos anos 60: a abordagem top-down enunciada
pelo professores italianos Boehm e Jacopini, Dijkstra dos Países Baixos, e Wirth da Suíça.
Porém, foi já nos anos 70 que a teoria de programação top-down ou estruturada, método dos
refinamentos sucessivos ou “método em cascata”, influenciou na prática o trabalho dos
programadores, fruto dos estudos de Mills, Baker, Yourdon, Constantine, Jackson e Orr. Os
programas se tornaram mais claros, escritos mais rapidamente e mais fáceis de modificar. O
processo inicialmente empírico de modelagem de sistemas também evoluiu bastante, a partir
do advento das metodologias de Análise Estruturada (abordagem funcional) e Análise
Essencial (abordagem orientada a eventos).
Ainda no campo das técnicas aplicadas a desenvolvimento de software, a metodologia

de Análise Orientada a Objetos (OO) que vem sendo praticada desde os anos 90, parte dos
paradigmas de que o mundo é formado de objetos e de que desenvolver um sistema nada mais
é do que criar uma simulação dos objetos e de seu comportamento.
14
A evolução da Informática a partir dos anos 60 pode ser representada pelo quadro a
seguir, cujas siglas se encontram descritas na Lista de Abreviaturas e Termos:
Evolução do Desenvolvimento de Software

Século
1960-1970 1970-1980 1980-1990 1990-2000
XXI
Fábrica Sw
Operações Artesanal Artesanal Fábrica Sw Integrated SPL
Outsourcing
PMI, ASAP, XP, ASD,
Processos Processos Proprietários CMM
RUP, ISO LD
JAVA,
Fortran, Natural, C, VB, Delphi,
Plataformas Cobol, PL1 .NET,
Assembler C++, Clipper Oracle
XML
Estruturada, Estruturada, OO, UML,
Metodologias Waterfall ?
Essencial Essencial Componentes
Figura 1 - Evolução do Desenvolvimento do Software (Fernandes, 2004: p. 23)
Esse mercado cresceu e continua crescendo muito, à medida que software vem sendo
incorporado a quase todos os produtos e atividades da sociedade moderna. Além da evolução
do grau de formalismo das técnicas de execução, conforme viemos relatando, o crescimento
desse mercado tornou necessário também que a gestão do processo de desenvolvimento de
software viabilizasse produção em larga escala, com qualidade e a menor custo.
As iniciativas de organização do modelo fabril baseado nos preceitos do taylorismo e

do fordismo, vindos desde o século XIX, têm tentado mapear conceitos de produção em larga
escala para o mercado de software, com qualidade, aumentando a produtividade e reduzindo
os custos de produção. (Tartarelli, 2004).
Com a crescente disseminação das práticas de Gestão de Qualidade Total (Total

Quality Management) nos Estados Unidos da América nos anos 80, começou um forte
movimento por parte do governo americano, mais notadamente o Departamento de Defesa,
para introduzir esses conceitos na gestão de software. Dos trabalhos de Watts Humphrey junto
com o Software Engineering Insititute da Carnegie Mellon University, nasceu o modelo de
maturidade de software denominado Capability Maturity Model (CMM), que é hoje a
principal referência em gestão de processos de software em nível mundial. (Fernandes, 2004).
15
O CMM define níveis de maturidade (capacidade) para organizações que têm por
objetivo produzir software, que variam de 1 a 5 da seguinte forma:
• Nível 1: processo inicial
• Nível 2: processo gerenciado
• Nível 3: processo definido
• Nível 4: processo gerenciado quantitativamente
• Nível 5: processo em fase de melhoria contínua
Com o crescimento e amadurecimento das Fábricas de Software da Índia (Kripalani,

2003), as iniciativas brasileiras têm se multiplicado e apresentado um crescimento
considerável nos últimos meses (Cesar, 2004), especialmente devido a fatores competitivos,
uma vez que o próprio mercado nacional tem se tornado mais exigente em termos de
qualidade do produto e de redução de custos (Tartarelli, 2004).
De acordo com Lai apud Zahran (1998) apud Fernandes (2004), o desenvolvimento de
software tem progredido através das seguintes ondas:
• Primeira Onda: ciclo de vida representado pelo modelo cascata e métodos
estruturados;
• Segunda Onda: movimento de maturidade do processo de software (CMM),
motivado pelas altas taxas de insucesso em projetos de software desenvolvidos na
primeira onda;
• Terceira Onda: industrialização do software viabilizada pela evolução da
tecnologia de orientação para objetos.
O desafio que a engenharia de software vem enfrentando desde os primórdios

permanece o mesmo, ou seja, como construir um software que atenda satisfatoriamente às
necessidades dos usuários, principalmente nos aspectos de qualidade, prazo e custo de
desenvolvimento, custos de produção e manutenção, sendo que a dificuldade aumenta quando
se pretende ampliar a escala de produção. Isso exige que, na busca da esperada alta
produtividade, o formalismo e o controle do processo sejam rigorosos, bem como sejam
especializados os técnicos que vão atuar em cada uma das etapas de fabricação.
16
Entre processos, ferramentas e organizações alternativas, a literatura consolida

experiência e inovação resultantes do trabalho de pesquisadores motivados a descrever (e
prescrever) formas mais eficazes de lidar com os problemas inerentes à construção de
software. Resulta destes esforços um conjunto de modelos e normas, como o CMM.
Tais modelos, ao decompor e colocar em seqüência processos, remetem ao modelo
fordista. Porém, diferentemente do modelo fordista, onde a qualidade do produto era de
responsabilidade do supervisor/gerente, o CMM se baseia no princípio de que cada
empregado é diretamente responsável por isso.
Estudos demonstram que a busca da produtividade restringe a flexibilidade e vice-

versa, conforme ilustra o gráfico abaixo, que aponta ganho de flexibilidade e conseqüente
perda de produtividade, quando se evolui de um arranjo físico de fábrica linear
(especialização dos operários) para um arranjo celular (operários multifuncionais):
Figura 2 – Gráfico Produtividade x Flexibilidade

Fonte: notas de aula da disciplina Organização do Trabalho, do Prof. Mauro R. Côrtes, DEP/UFSCar
E especificamente na produção de software onde, por mais que tenham sido

padronizadas técnicas e procedimentos, ainda não se conseguiu erradicar das soluções os
componentes criatividade e conhecimento do negócio que vai ser apoiado pelo software, a
busca desse grau ideal de flexibilidade para maximizar a produtividade é permanente.
Enquanto o layout linear favorece a exploração do conhecimento da equipe quanto às técnicas
e ferramentas utilizadas, e permite o compartilhamento desse recurso humano entre vários
17
projetos, o layout funcional faz fluir o conhecimento do negócio mais facilmente, conferindo
maior velocidade à produção.
O presente trabalho versa sobre o modelo fordista de produção aplicado a

desenvolvimento e manutenção de software, e busca elementos para contribuir na elucidação
da seguinte questão: Processos de produção criativos, e baseados no conhecimento que
extrapola técnicas e ferramentas, se adaptam a mecanismos de controle fordistas?
Constitui o objetivo geral desse trabalho verificar como as fábricas de software, ao

adotar princípios e mecanismos de controle fordistas, solucionam a questão da necessária
passagem de conhecimento de uma etapa de produção para a etapa seguinte. Fato é que ao
longo do desenvolvimento de um software, vai sendo tanto adquirido como também
produzido um conhecimento que extrapola o próprio software, que diz respeito ao negócio ao
qual vai estar atrelado e ao ambiente que cerca seus futuros usuários.
Como objetivos específicos, podemos elencar:

• Posicionar o sistema de produção teórico de fábricas de software entre os modelos
fordista e pós-fordista, identificando os pontos em comum com cada um desses
modelos;
• Verificar, nas fábricas de software estudadas, tanto para as atividades de
desenvolvimento como de manutenção de software, nas circunstâncias de
aderência ao modelo fordista:
Como são viabilizados o registro, a disponibilização e a transmissão do
conhecimento entre as várias etapas da cadeia;
Que ferramentas são utilizadas para planejar e controlar a produção.
• Avaliar, do ponto de vista dos desenvolvedores de sistemas, operários das fábricas
de software estudadas, quão confortáveis eles se sentem ao executar seu trabalho
obedecendo a um processo rígido de produção, tanto do ponto de vista de
realização pessoal, como de garantia de espaço no mercado.
No cenário contraditório das fábricas de software, onde a natureza do produto é

aparentemente inadequada ao modelo de produção, desperta interesse explorar como se
conciliam controles de produção que remetem ao modelo fordista com as atividades de
18
desenvolvimento e manutenção de software, cujas tarefas, não raro, exigem criatividade e

inovação na concepção de soluções.
Esse estudo, ao identificar pontos conflitantes desse cenário que estejam prejudicando
a produtividade, pretende colaborar com os gestores da indústria de TI, especialmente com
aquelas que, além de desenvolver, também prestam serviço de manutenção evolutiva de
sistemas.
Como especificamente uma das fábricas estudadas encontra-se em fase de

consolidação de estrutura bem como de seus processos, esse trabalho poderá conferir aos seus
gestores um novo ângulo de observação dos fenômenos estudados, e quem sabe permitir tanto
a validações como possíveis correções de rumo das diretrizes adotadas.
19
2 – Fundamentação Teórica:
2.1 – Metáfora
Em sendo o ser humano um indivíduo social, vivendo em comunidades e

relacionando-se com seus semelhantes, com eles precisa inevitavelmente se entender através
da linguagem. A complexidade da linguagem se evidencia nas próprias palavras, que
exprimem sentimento ou idéia (Curras, 1995, p.15):
Para A. Martinet, a linguagem é um simples meio de comunicação. Ferdinand
Saussure já fazia distinção entre a linguagem e a língua, na qual esta última
resulta ser um sistema arbitrário de símbolos fônicos que satisfaz a
necessidade de comunicação de uma comunidade humana. Por sua vez,
Helmut Felber define a linguagem como um sistema de símbolos que serve
para expressar idéias por meio de conceitos. Bruner considera a linguagem
como um instrumento por intermédio do qual os seres humanos criam,
constituem ou convencionam um mundo social do qual possam compartilhar.
Tem, pois, a finalidade de construir um mundo social e poder “operar”,
mover-se, desenvolver suas atividades dentro dele. Para Saussere, a linguagem
é uma faculdade humana, propriamente humana, absolutamente necessária
para seus fins comunicativos. Também faz uma distinção entre linguagem e
língua. Este é um produto social da faculdade da linguagem.
A metáfora, figura de linguagem semântica, estudada normalmente como uma

instancia lingüística assemelhada à comparação, consiste na analogia implícita entre dois
elementos através de seus significados imagísticos, atribuindo, de forma inesperada ou
improvável, significados de um deles ao outro; fala-se de algum ser utilizando-se
características de outro ser diferente. Pode ser entendida como o emprego de uma palavra fora
do seu sentido usual, com caráter comparativo, substitutivo ou interativo.
Para Souza (2003), além de ser uma espécie de jogo lingüístico, a metáfora é um modo
de raciocinar típico do gênero humano, uma maneira muito corriqueira de conceituar o
mundo. Através das metáforas, o homem manifesta sua visão sobre as coisas do mundo e
revela as relações entre elas, da maneira como são processadas em sua mente. Ainda segundo
Souza (2004. p. 6):
A visão de Aristóteles sobre a metáfora como uma espécie de ornamento da
linguagem vem perdurando por muitos séculos, e nem se pode dizer que não
haja resquícios desse pensamento, ainda hoje, nos estudos lingüísticos – prova
disso são os conceitos para essa forma de sentido figurado veiculados nos
manuais didáticos e em algumas gramáticas, fora a própria visão que se tem
sobre esse recurso no âmbito dos estudos literários. No entanto, considerada
como um procedimento que vai além do nível do enunciado e atinge as
20
instâncias da enunciação, o entendimento da metáfora sob o prisma da teoria

de Lakoff e Turner permite vislumbrar com maior acuidade vários fenômenos
da língua “viva”, aquela utilizada na comunicação diária, corriqueira e, não
somente, a língua criada para o bel-prazer dos falantes.
Metáforas são utilizadas para gerar uma imagem que permita estudar um objeto; essa
imagem (parcial e unilateral) pode fornecer a base para uma pesquisa científica fundada nas
tentativas de descobrir até que ponto as características da metáfora podem ser encontradas no
objeto da investigação, (Morgan, 2005, p. 63):
A metáfora é, então, baseada numa realidade parcial; ela requer das pessoas
que utilizem uma abstração um tanto unilateral em que determinadas
características sejam enfatizadas e outras, suprimidas, em uma comparação
seletiva.
Quanto mais a imagem que a metáfora pretende criar sugere o objeto, ao invés de
identificá-lo, maior seu sentido. Se a imagem criada pela metáfora aproxima-se demais da
“realidade”, ela se torna uma identificação extra, deixando de ser uma comparação, ou seja,
deixando de ser metáfora.
A discussão acerca dos limites do sentido metafórico na linguagem é recorrente nos

estudos de Lingüística Cognitiva, que não apartam os fenômenos língua e raciocínio,
considerando a língua mais do que apenas uma das facetas do pensamento humano: um
importante elemento – embora não único – para a compreensão do aparato cognitivo do
homem. Nesse campo surge o conceito dos “espaços mentais”, domínios cognitivos de
natureza significativa, ativados durante o raciocínio, ligados a alguma forma de
conhecimento, seja em nível cultural, psicológico, histórico ou ficcional.
Para Souza (2003), ainda que tais estudos não sejam definitivos, apontam para a idéia
de que o elemento “contexto” é um fator imprescindível numa análise lingüística, dado que
interfere decisivamente na produção do sentido da palavra. Ou seja, a determinação
fronteiriça do sentido literal e do figurado na linguagem não pode ser resolvida como uma
simples questão binária, sendo mais adequado, nesse caso, inserir a categoria “sentido” numa
escala gradativa.
A metáfora é um fenômeno natural da comunicação diária, seja oral ou escrita (e até

gestual), refletindo a maneira de pensar do homem. A comunicação humana é metafórica por
21
excelência, dado que a todo momento operamos transferência de idéias de um domínio

cognitivo para outro, inter-relacionando elementos de diferentes espaços mentais, o que
constitui a essência da metáfora. Em expressões simples do nosso dia-a-dia, como “combater
a inflação”, “vencer o medo”, “espantar a preguiça”, “esperar a morte”, “lutar contra a fome”,
“ser derrotado pelo desafio” e outras, projetamos a idéia de anima (alma) para o espaço
mental de elementos que nem corporeidade possuem (inflação, medo, etc.). Assim, esses
elementos passam a ser conceptualizados como pessoas, tanto que até incorporam
características humanas, tais como: benéficos, amigáveis, inimigos, fortes (Souza, 2003).
. Observamos, na definição a seguir, a adoção no sentido metafórico explícito do termo

fábrica: Como o nome já diz, a fábrica de software para ser considerada dessa forma deve
possuir alguns atributos oriundos de uma fábrica industrial (Fernandes, 2004: p. 116).
Identificamos nessa definição tanto a utilização do espaço mental “conhecimento do modelo
fabril industrial”, como a alusão aos limites dessa metáfora, a fronteira entre a literalidade e a
metaforização, ou seja entre sentido literal e figurado do termo fábrica quando ligado à
produção de software.
2.2 – Taylorismo
Na obra de Adam Smith, final do século XVIII, encontram-se as origens do sistema de

produção em massa. Observando a possibilidade de divisão do trabalho em uma fábrica de
alfinetes, Smith verificou que um ganho de produtividade poderia advir da subdivisão de uma
tarefa em diferentes etapas, o que permitiria especializar trabalhadores e máquinas em tarefas
específicas, tornando-os mais eficazes.
Tal princípio foi explorado posteriormente por teóricos industriais como Charles
Babbage, que em 1832 escreveu On the Economy of Machinery and Manufactures,
apresentando a fábrica como uma máquina complexa abrangendo trabalho divisível,
organograma e relações do trabalho. Babbage “foi talvez o mais direto precursor de Taylor,
que deve ter sido freqüentador da obra de Babbage, muito embora jamais tenha se referido a
ele” (Braverman, apud Tenório: p. 135).
22
Frederick Winslow Taylor (1856-1915), o “Pai da Organização Científica do

Trabalho”, através de seu livro Princípios de Administração Científica, publicado em 1911,
definiu a administração como um conhecimento sistematizado que abrange da organização da
produção à organização do trabalho, e disseminou as vantagens da separação do trabalho em
manual e intelectual.
Na parte central deste livro esclarecemos, de acordo com as leis científicas,
que a administração deve planejar e executar muitos dos trabalhos de que até
agora têm sido encarregados os operários; quase todos os atos dos
trabalhadores devem ser precedidos de atividades preparatórias da direção,
que habilitam os operários a fazerem seu trabalho mais rápido e melhor do que
em qualquer outro caso. E cada homem será instruído diariamente e receberá
auxílio cordial de seus superiores, em lugar de ser, de um lado coagido por seu
capataz, ou em situação oposta, entregue à sua própria inspiração.
(Taylor: 1971. p.34)
Ele defendia que todo o raciocínio deveria ser retirado do chão de fábrica e centrado
em departamentos de planejamento e controle da produção, dotados de técnicos capacitados
em plantas e estudo de tempos e movimentos. Sendo partidário da necessidade de permanente
luta patronal contra o ócio operário, acreditava que os homens têm uma tendência inata e
instintiva a fazer as coisas com calma; segundo essa percepção, salvo honrosas exceções,
todos os homens cedem à tendência natural de trabalhar num ritmo lento e cômodo.
Taylor selecionava e estudava grupos experimentais de trabalhadores particularmente

hábeis, analisava seus comportamentos indo até a decomposição da execução de suas tarefas
em movimentos elementares individuais, e sua posterior recomposição (segmentada). Dessa
forma, o saber empírico extraído da habilidade operária transformava-se em saber codificado,
voltando aos operários sob a forma de normas imperativas. A idéia de tarefa talvez seja o mais
importante elemento na administração científica, e deve ser sempre programada de forma que
o homem possa realizá-la durante muitos anos, feliz e próspero, sem sentir os prejuízos da
fadiga.
Seus estudos evidenciaram a drástica separação entre projeto e execução (um dos
princípios fundamentais da administração científica), entregando tudo o que faz parte do
projeto e da organização a especialistas no assunto, enquanto aos operários só sendo exigido
que executem o trabalho atendo-se rigorosamente às prescrições técnicas recebidas.
23
A Administração Científica, em sua essência, consiste e, certa filosofia que resulta em

uma combinação de quatro princípios fundamentais:
• Desenvolvimento de uma verdadeira ciência, ao invés do empirismo;
• Seleção científica do trabalhador;
• Instrução e treinamento científico do trabalhador, desenvolvendo cada um deles no
sentido de alcançar maior eficiência e prosperidade;
• Cooperação íntima e cordial, harmonia entre a direção e trabalhadores, buscando
rendimento máximo.
Para Durand (1978), o taylorismo, com ênfase na eficiência, propõe para determinação
do “one best way”, ou seja do como melhor executar uma tarefa:
• Definição precisa dos movimentos elementares, das ferramentas e materiais
necessários para execução de cada tarefa;
• Mensuração (por cronometragem, por exemplo) do tempo de execução de cada um
desses movimentos;
• A partir da análise crítica de cada movimento, busca da simplificação e economia
de gestos, considerando a seqüência e o conjunto de movimentos de cada tarefa.
As idéias de Taylor foram desenvolvidas e aplicadas em diferentes indústrias ao longo

das décadas seguintes. Para Tenório (2000), o fordismo como modelo gerencial somente
existiu ou existe pelo fato de antes dele ter aparecido o taylorismo; sem taylorismo não
existiria fordismo.
2.3 – Fordismo
Ninguém simboliza tanto a produção em massa como Henry Ford (1863-1947),

considerado o pai da linha de montagem, que preconizava a padronização de produtos e
componentes visando maximizar a economia de escala e, com isso baixar custos e ampliar o
mercado. Ao fazer propaganda de seu carro produzido em massa, Ford brincava dizendo que
se poderia ter qualquer modelo de carro desde que fosse o T, em qualquer cor desde que fosse
preta (Tigre, 1997). O modelo T foi líder de mercado durante 15 anos, até que a General
Motors resolveu inovar, oferecendo opções de cores e modelos.
24
Segundo Habermas (apud Tenório, 2000), no capitalismo, a força de trabalho torna-se

mercadoria, e a dependência dos produtores imediatos em face dos proprietários dos meios de
produção, é garantida, no plano jurídico, pela instituição do contrato de trabalho e, no plano
econômico, pelo mercado de trabalho. O fordismo pode ser associado à manifestação de uma
determinada etapa do capitalismo (Tenório, 2000).
Para Tenório (2000), a empresa implementa suas ações a partir da percepção de que a
mão-de-obra, como fator de produção, participa do sistema-empresa como um insumo –
matéria-prima. A partir do taylorismo-fordismo, paradigma técnico-econômico iniciado na
década de 30, filho predileto da “razão instrumental”, a divisão do trabalho tem sido
implementada por meio de vários instrumentos gerenciadores de suas ações: estrutura
decisória através da disposição hierárquica, definição de atribuições a partir de plano de
cargos e salários, programas de treinamento padronizados conforme modismo vigente,
definição de tarefas através de manualização, etc. Tais mecanismos, apresentados aos
empregados como isentos de interesse e científicos, são utilizados para demarcar o
comportamento do empregado, dificultando a manifestação dos elementos estruturais do seu
mundo da vida.
O fenômeno da “razão instrumental”, também conhecido como formal, funcional,

técnica ou tecnológico é visto pela Escola de Frankfurt como um fator inibidor da
emancipação do homem, seja nos espaços reservados à cultura, onde se denomina indústria
cultural, seja naqueles reservados à produção, denominados tecnificação do homem ou a sua
unidimemsionalização.
O fordismo se caracteriza como um modelo micro-econômico que surge no início do

século XX (1910) e se estende também como modelo macro-econômico até os anos 1970,
cuja substância social é determinada pela técnica, e que pode ser visto também como um
método de organização de produção complementar ao taylorismo, visão que mais interesse
desperta no presente estudo. Tal método, “que se caracteriza pelo gerenciamento tecno-
burocrático de uma mão-de-obra especializada sob técnicas repetitivas de produção de
serviços ou de produtos padronizados”. (Tenório apud Tenório, 2000, p. 140).
25
Segundo Ferreira et alli (apud Tenório, 2000, p.140) o paradigma fordista se

caracteriza por:
• Rigidez organizacional;
• Racionalização taylorista do trabalho: profunda divisão (horizontal e vertical) e
especialização do trabalho;
• Desenvolvimento da mecanização através de equipamentos altamente
especializados;
• Produção em massa de bens padronizados;
• Salários relativamente altos e crescentes, incorporando ganhos de produtividade,
para compensar o tipo de trabalho predominante.
Além da “linha de montagem”, outra de suas principais contribuições foi a “produção

em massa” que, ao contrário do que se pensa não decorre da linha de montagem, mas da
“completa e consistente intercambialidade das peças e na facilidade de ajustá-las entre si.”
(Tenório, 2000: p. 142). Podemos perceber, no caso das fábricas de software, o quanto essa
intercambialidade e ajuste entre si das peças são perseguidos, pela disseminação das práticas
de encapsulamento de funcionalidades e componentização norteando as ferramentas de
desenvolvimento ditas de “alta produtividade”.
A produção de grandes volumes de produtos padronizados foi viabilizada pelo modelo

fordista de organização do trabalho que emprega matéria-prima, máquinas, equipamentos,
desenho e mão-de-obra pré-definidos com o menor custo possível, e que diferencia os que
pensam dos que executam sob normas de supervisão imediata e no ritmo de trabalho ditado
pela máquina.
Entre 1892 e 1896, Henry Ford havia construído um automóvel peça por peça. Em 16
de Junho de 1903, com mais 11 sócios e um capital inicial de US$ 28 mil, fundou a Ford
Motor Co., com aproximadamente 125 empregados, colocando à venda quatro meses depois
o primeiro carro. Cada modelo projetado era identificado, na seqüência, por uma letra do
alfabeto, e em 1908 nasceu o modelo T conhecido no Brasil como Ford Bigode (TENÓRIO,
2000).
26
Em 1913, na planta fabril do Parque Highland, em Michigan, sua nova técnica

permitia que cada operário permanecesse num lugar fixo, executando repetidamente a mesma
tarefa, nos múltiplos veículos que passavam por eles. Essa linha de montagem mostrou-se
tremendamente eficiente, produzindo 800 carros por dia. Em 1926 haviam sido fabricadas 15
milhões de unidades. Nessa ocasião, a Ford Motor Co. possuía 88 usinas e empregava 150 mil
pessoas, fabricando 2 milhões de unidades por ano (Tenório, 2000).
Foram três princípios básicos elaborados por Ford que viabilizaram essa rápida
evolução:
• Intensificação: redução do tempo de produção (emprego imediato de
equipamentos e matéria-prima);
• Economicidade: redução do estoque de matéria-prima;
• Produtividade: aumento da capacidade de produção (especialização e linha de
montagem).
Segundo relato de Gounet (1999), Henry Ford, dez anos depois de ter formado sua
empresa, elaborou um novo método de produção superando o método artesanal destinado a
fabricar um veículo, modelo T, por um preço razoavelmente baixo de forma que fosse
comprado em massa. Esse veículo sem complicações excessivas, e inicialmente projetado
para romper o isolamento de sitiantes nas áreas agrícolas americanas, deveria ser acessível ao
bolso dos consumidores.
As principais transformações impostas pelo novo paradigma gerencial surgido no setor

secundário da economia, foram:
• Produção em massa, reduzindo consequentemente custos de produção e preço de
venda através da racionalização extrema das operações e do combate ao
desperdício, principalmente de tempo;
• Parcelamento das tarefas, projetadas para serem repetidas continuamente durante
a jornada de trabalho, contemplando pequena quantidade de gestos, dispensando o
operário de conhecer de mecânica e dessa forma exigindo menor qualificação da
força de trabalho;
27
• Introdução da linha de montagem (esteira), ligando os trabalhos individuais

sucessivos e fixando a cadência regular da produção sob o controle da direção da
fábrica;
• Padronização das peças, minimizando as variantes no processo produtivo e
viabilizando a sua reutilização noutros modelos.
Nas fábricas fordistas, a adoção da esteira de produção pressupunha que:

• Cada etapa da produção possuía fronteiras bem definidas; isto é, a configuração da
peça recebida, o procedimento a adotar e a nova configuração da peça repassada
estavam claramente especificados;
• Quem trafegava na esteira era apenas a peça em produção, que vai sendo acrescida
ou modificada segundo um processo pré-definido e que não varia de peça para
peça;
• Para a execução de sua tarefa, além de possuir a requerida habilidade, bastava ao
operário conhecer bem as técnicas e ferramentas que lhe cabiam utilizar, não lhe
sendo exigido conhecer sobre o produto para o qual a peça que estava sendo
fabricada, muito menos conhecer sobre o contexto da utilização daquele produto;
• Cada operário precisava conhecer muito bem o seu papel no processo, mas apenas
o seu papel;
• Além de seguir o procedimento pré-estabelecido, não cabia a um operário da
esteira repassar qualquer conhecimento adquirido durante a execução da sua tarefa
para o próximo executante;
• As tarefas eram repetitivas e individuais;
• Os controles da produção eram focados na execução do processo: cronometragem
do tempo de execução, métricas de produtividade individuais (metas), verificação
da aderência a padrões de qualidade adotados;
• A esteira da linha de montagem corria em mão única, isto é, não estavam previstos
retornos da peça, via esteira, à etapa anterior para complementar algum processo
inacabado ou mal-feito.
O fordismo, não apenas uma teoria organizacional mas um modelo de acumulação, é

visto também como aplicação do taylorismo em grande escala (Bianchi e Sacerdoti: 1986), a
28
partir da introdução da linha de montagem e conseqüente necessidade do operário respeitar os

tempos determinados pela velocidade da esteira.
No entanto, nos anos 60, o fordismo entrou em crise pela sua inflexibilidade em aderir
a novos parâmetros que não exclusivamente técnicos, porém sócio-econômicos, com
conseqüência direta na relação capital trabalho (Tenório, 2000). Os sinais da crise, segundo
Harvey (1994), foram:
• Insatisfação dos trabalhadores quanto às condições e conteúdo do trabalho;
• Crises sociais causadas pela desigualdade salarial (grandes Organizações x
pequenas, homens x mulheres, etc);
• Incapacidade do Estado de distribuir os benefícios do Fordismo;
• Queda da qualidade dos produtos e serviços oferecidos.
Passaram a ocorrer desde então mudanças de atitude gerencial (monológica para

dialógica) propiciando um maior envolvimento do trabalhador na gestão da produção. Tais
mudanças podem ser exemplificadas com as experiências inovadoras suecas (na Volvo, a
participação do sindicato na organização do trabalho), bem como dos modelos alemão
(comissão paritária com amplos poderes) e japonês (retroalimentação dos efeitos e resultados
da produção pela especificidade da demanda). Surgia então um novo paradigma técnico-
gerencial, o pós-fordismo à semelhança da flexibilização organizacional.
2.4 – Pós-Fordismo
Nas décadas de 1960-1970, sendo que especificamente no Brasil mais a partir dos anos
90, profundas alterações no cenário sócio-econômico (mercados mais volúveis e
imprevisíveis) têm provocado mudanças nos modelos de gestão das organizações, que de
modo geral foram construídos seguindo os preceitos do fordismo.
Essas mudanças se traduzem: na busca de melhoria contínua dos processos produtivos,

dos produtos e dos serviços associada à redução de custo; no esforço de aproximação com
fornecedores e clientes; no uso estratégico de tecnologia para obtenção de vantagens
29
competitivas; na diminuição de níveis hierárquicos bem como da compartimentalização; na

inovação das políticas de recursos humanos (Boddy, apud Tenório, 2000, p. 163).
Na visão de Tenório, apoiado nas percepções de Habermas e Boaventura de Souza

Santos, a flexibilização organizacional apenas ocorreria se, e somente se, houvesse a interação
consensual entre a evolução científico-técnica, a globalização da economia e a cidadania; o
gerenciamento apenas das duas primeiras varáveis caracteriza uma mudança sob a perspectiva
neofordista (Tenório, 2000, pg. 182).
Esse recente paradigma, ainda em transição no Brasil, tornou-se “um compromisso

social, aceito – por bem ou por mal – pelos dirigentes e trabalhadores” (Leborgne & Lipietz
apud Tenório, 2000, p. 130), cuja substância social seria determinada não mais
exclusivamente pela técnica, mas pela interação. Nessa mudança de paradigma de
organização da produção e do trabalho, o estudo das organizações passou a considerá-las
sistemas orgânicos enquanto no fordismo eram consideradas sistemas mecânicos:
O pós-fordismo ou modelo flexível de gestão organizacional caracteriza-se
pela diferenciação integrada da organização da produção e do trabalho sob a
trajetória de inovações tecnológicas em direção à democratização das relações
sociais nos sistemas-empresa. Concepção que contraria a fordista na medida
em que esta se baseia na previsão de um mercado em crescimento, o que
justificava o uso de equipamentos especializados a fim de obter a economia de
escala. Agora surgem equipamentos flexíveis cuja finalidade é atender a um
mercado diferenciado, tanto em quantidade quanto em composição.
(Tenório: 2000. p.163)
A flexibilidade organizacional, assemelhada ao sistema de produção pós-fordista, se

manifesta também em termos tecnológicos. E essa flexibilidade na produção corresponde à
flexibilidade dos mercados de trabalho, das qualificações e das práticas laborais, sendo “o
trabalho em equipe um dos elementos centrais do paradigma flexibilização organizacional”
(Tenório, 2000, p. 138).
Segundo Malamut (2002), para atender às novas condições de trabalho, é exigido do

trabalhador ampliar sua qualificação (seja por iniciativa própria ou subsidiado pela
organização) não apenas no campo onde é especialista, mas em diversos ramos (multi-
funcionalidade).
30
As organizações, para aumentar a produtividade, investiram em tecnologia cada vez

mais sofisticada. A primeira revolução industrial adveio da energia a vapor, e com a
eletricidade e o petróleo, aconteceu a segunda; já a informação e a comunicação foram os
propulsores da terceira revolução industrial. Para recuperar o necessário investimento em
tecnologia e aumentar suas margens de lucro (reduzindo seus custos), as organizações estão se
reestruturando e se tornando mais flexíveis, isto é, vêm adotando as seguintes políticas:
• Eliminação de níveis de gerência;
• Criação de equipes multidisciplinares e auto-geridas;
• Simplificação/redução dos processos de produção;
• Descentralização e dinamização da administração;
• Teletrabalho.
Convém observar que, uma vez reduzida a intensidade de supervisão hierárquica,

postos de trabalho foram extintos com a flexibilização. O trabalho em si também tem sido
flexibilizado, através da redução da jornada semanal de trabalho, da subcontratação com
menores encargos e adequação às flutuações de mercado, da utilização de banco de horas, da
implantação de horário de trabalho flexível, e da oferta de vagas temporárias consoantes com
o ciclo de produção.
2.5 – Fábricas de Software
2.5.1 – Conceituação
Ao visitar uma fábrica de software, não vamos encontrar operários uniformizados

operando maquinários ruidosos, nem esteiras pelas quais se vê circular o produto inacabado
em seus diversos estágios de produção. Não vamos identificar tampouco um supervisor
circulando pelas estações de trabalho para verificar a produtividade.
Ao contrario, de modo geral vamos nos deparar com um salão silencioso, subdividido
por divisórias que delimitam o espaço de pequenos grupos de empregados (no máximo
quatro), onde na mesa de cada um deles existe um computador no qual estão trabalhando.
Também não é possível distinguir uma das outras as diversas equipes que atuam na fabricação
31
do software, que no caso dessas fabricas são chamadas de competências. O fato da

composição (tamanho e/ou integrantes) dessas competências poder variar bastante ao longo
do ciclo de desenvolvimento de um software, é uma fator decisivo para que a planta física da
fábrica não esteja atrelada a sua estrutura organizacional; isso dada a facilidade, provida pela
tecnologia, do empregado poder continuar instalado na mesma mesa quando transferido para
outra competência
Dificilmente se consegue identificar como estão estruturadas as equipes/competências,

qual delas atua em que etapa da produção, quais seriam essas etapas, nem qual o papel de
cada empregado no processo produtivo, uma vez que todos parecem estar fazendo o mesmo,
isto é observando a tela e digitando no teclado do computador. Virtualmente, porém, estão
certamente presentes tanto a esteira de produção como a figura do capataz. Para ilustrar,
seguem fotos de uma das fabricas objeto desse estudo:
Figura 3: Fotografia 1 da Ambientação da Fábrica (fonte: própria)

32
Figura 4: Fotografia 2 da Ambientação da Fábrica (fonte: própria)
O capataz se materializa num software que monitora, através da rede de comunicação

de dados que interliga todos os computadores, a tarefa a qual cada empregado está se
dedicando, o quanto dela já foi realizado, quanto tempo foi nela despendido. Nesse caso,
através de relatórios que o próprio software disponibiliza, os lideres de cada equipe bem como
o gerente da fabrica podem acompanhar o andamento do trabalho, sem precisar se levantar de
suas mesas. No caso dessa fábrica, se utiliza a plataforma Microsoft, com o Team Foundation
integrado com Visual Studio, Excel e MS Project.
E a esteira, por sua vez, é a própria rede de comunicação de dados sendo utilizada para
transferência dos artefatos4 produzidos por cada empregado, seja de uma competência para
outra, seja dentre os diversos ambientes também virtuais que coexistem numa fábrica de
software.
____________________________
4
Artefato é um produto criado ou modificado durante um processo. Tal produto é resultado de uma atividade, e
pode ser utilizado posteriormente como matéria-prima para a mesma ou para outra atividade a fim de gerar
novos produtos (Rocha, 2005).
33
Tais ambientes virtuais, onde se desenrola todo o ciclo de desenvolvimento de um

software, ficam hospedados em computadores denominados “servidores de
desenvolvimento”, e no caso dessa fábrica são eles:
• Ambiente de desenvolvimento onde residem os artefatos enquanto estão sendo
desenvolvidos ou corrigidos;
• Ambiente de testes, onde os artefatos dados como prontos são submetidos aos
testes;
• Ambiente de homologação, onde os artefatos prontos e aprovados nos testes são
submetidos à aprovação do cliente.
O percurso dessa esteira pode variar de fabrica para fabrica, seja na subdivisão de
responsabilidades e atribuições por mais estações, seja na nomenclatura. Basicamente são
encontradas as estações representadas na figura abaixo, que ilustra inclusive o modelo de uma
das fábricas estudadas (Fábrica B):
Figura 5: Diagrama da Esteira de Produção da Fábrica (fonte: própria)
Em cada uma das estações dessa esteira são produzidos artefatos, que desempenham o
papel de “pacotes” circulando virtualmente. Até o momento da programação, quando é enfim
produzido o software propriamente dito (representado na figura pelo “pacote” já embrulhado
como se fosse para um presente), os artefatos produzidos apenas registram concepções, por
34
exemplo, de: atores do mundo real que vão interagir com o software, regras de negócio a
serem observadas em cada uma das funcionalidades que vão ser disponibilizadas para os
usuários, modelos lógico e físico dos dados armazenados nas bases, descrição de algoritmos,
configuração de ambiente de produção (onde vai ser executado o software). Finda a fase de
testes, o software já pronto é submetido ao processo de geração de cópias, repetido tantas
vezes quanto necessário for e infinitamente mais simples do aquele de construção.
Para Greenfield (2003), o conceito de fábrica de software pressupõe o

desenvolvimento de sistemas baseado em componentes, direcionado a modelos e a linhas de
produto de software, caracterizando uma iniciativa de fábrica, barateando a montagem de
aplicações por conta de reuso sistemático que possibilitam a formação de cadeias de
produção.
As fábricas de software, para Fernandes (2004, p. 117), podem ser definidas como:
Processo estruturado, controlado e melhorado de forma contínua,
considerando abordagens de engenharia industrial, orientado para o
atendimento a múltiplas demandas de natureza e escopo distintas, visando à
geração de produtos de software, conforme os requerimentos documentados
dos usuários e/ou clientes, da forma mais produtiva econômica possível.
E, requerem os seguintes atributos:

• Processo definido e padrão (desenvolvimento, controle e planejamento);
• Interação controlada com o cliente (entradas e saídas da fábrica);
• Padronização das solicitações de serviço;
• Estimativas de custos e prazos baseadas no conhecimento real da
capacidade produtiva através de registros históricos;
• Controle rigoroso dos recursos alocados em cada demanda da fábrica;
• Controle e armazenamento, em bibliotecas de itens de software, dos
artefatos e do conhecimento produzido em cada etapa;
• Controle permanente e em tempo real de todas as demandas;
• Produtos gerados de acordo com os padrões estabelecidos pela
organização;
• Equipe treinada e capacitada nos processos organizacionais e produtivos;
• Controle da qualidade do produto;
• Processos de atendimento ao cliente;
• Métricas definidas e controle dos acordos de nível de serviço (SLA)
definidos com o cliente.
Fernandes (2004, p. 116)

35
No resultado das fábricas de software, interferem diretamente os fatores: gestão de

pessoas, gestão empresarial, processos de desenvolvimento de software, padrões de qualidade
de software, ferramentas e frameworks de soluções fabris. Nesse contexto, este trabalho vai
estar focado no fator Processos de Desenvolvimento de Software.
As fábricas de software obedecem à classificação abaixo, de acordo com o seu escopo

de atuação ao longo das fases de desenvolvimento de um projeto de Software:
Figura 6 - Escopo de Fornecimento da Fábrica (Fernandes, 2004: p. 118)
A fábrica de programas consiste na menor unidade de fábrica, conseqüentemente a

menos complexa. Tem por objetivo principal codificar e testar programas de computador. No
seu processo produtivo engloba exclusivamente as fases de construção e testes unitários.
A fábrica de projetos físicos atua num âmbito mais amplo do processo de produção,
englobando além das atividades inerentes à fábrica de programas, uma fase anterior de projeto
detalhado e fases posteriores de testes de integração e de aceitação. O conhecimento do
negócio do cliente nessas fábricas não é tão requerido, dado que tal fábrica já recebe como
entrada um projeto lógico (projeto conceitual e especificação lógica).
A fábrica de projetos de software estende sua atuação, iniciando seu processo já a

partir das fases de projeto conceitual e especificação lógica. Para isso é fundamental que essa
fábrica domine o conhecimento do negócio dos seus clientes; daí a gestão do capital
intelectual ser muito mais importante do que a de outros recursos, justificando a preocupação
permanente de minimizar a rotatividade de sua mão-de-obra.
36
A fábrica de projetos ampliada atua desde a concepção da arquitetura da solução até

a entrega do software pronto e testado, apto a entrar em produção. Isso requer o conhecimento
de soluções mais abrangentes na área de TI, relativas a configurações de hardware e software
básico, redes de comunicação, plataformas de desenvolvimento e de produção, soluções de
gerenciamento de bases de dados. No ocaso dessas fábricas, o software é apenas um dos
produtos fabricados.
Quanto à classificação fábrica de componente, apenas citada por Fernandes (2004)

na discussão sobre SPL, se estivesse representada na figura 2, deveria constar como um
subconjunto da fábrica de programas. Cabe colocar que, a viabilidade de sua individualização
com interfaces diretamente ligadas ao cliente dependente diretamente, do grau de rigor desse
cliente na adoção do conceito reuso, proveniente da metodologia Análise Orientada a Objetos.
Considerando o cenário atual de comercialização de produtos de software, onde

desponta como realidade o mercado de software livre, que é alvo de grande discussão no meio
acadêmico e comercial, devemos reconhecer a smart factory. Esse tipo de fábrica é composto
por uma equipe fixa, geograficamente distribuída, que será responsável pela captação de
negócios e desenvolvimento inicial de um produto de software livre, que poderá ser
posteriormente disponibilizado para que uma comunidade de desenvolvimento que participará
do processo de melhoria do mesmo. (Spíndola, 2004).
Uma fábrica de software, independente do seu tipo, quando dedicada a um único

cliente é dita especializada e atende ao modelo de outsourcing de sistemas. Seu diferencial
reside:
• nas interfaces de entrada e saída da fábrica com o cliente, regidas por regras,
restrições, procedimentos para o caso de mudança de escopo e critérios de
avaliação pré-estabelecidos conjuntamente, de modo geral estabelecidos através de
um SLA;
• na possibilidade de negociar com o cliente a demanda, o que permite estabelecer a
capacidade da operação.
Fazendo uma analogia com a racionalização taylorista do trabalho, aplicada aos

modelos de fábrica de software que atuam nas fases de efetivo desenvolvimento do software
37
(o que exclui a fábrica de projetos ampliada), podemos observar a clara separação entre
projeto e execução, identificando a seguinte fronteira:
Projeto Execução
Fábrica de Projetos de Software
Fábrica de Projetos Físicos
Fábrica de Programas
Projeto Especificação Projeto Teste Teste de

Construção e Teste Unitário
Conceitual Lógica Detalhado Integrado Aceitação
Figura 7: Fronteira Projeto-Execução (fonte: própria)
Para o perfeito funcionamento das atividades de uma fábrica de software, é

fundamental a adoção de um processo de desenvolvimento onde, uma vez determinado seu
ciclo de vida, estejam definidas as tarefas e os produtos (artefatos) gerados em cada etapa,
bem como os responsáveis por cada uma delas.
À luz do modelo fordista, cumpridos tais requisitos e com a alta especialização dos
profissionais alocados, a produtividade de cada estação da esteira de produção estaria
garantida, bem como garantida estaria também a qualidade do artefato produzido para a etapa
seguinte.
Cabe observar que essas questões surgem com intensidade diretamente proporcional
ao escopo da fábrica de software. Isto é, fábricas de programas estão menos sujeitas a elas,
enquanto nas fábricas de projeto de software tal risco é alto. Sob outro aspecto, a fábrica de
programas requer controle rigoroso de tarefas e recursos, visando obter flexibilidade de
entrega e de volume, sendo a gestão de produtividade crucial nesse caso.
2.5.2 – Processos de Desenvolvimento de Software
O conceito de fábrica de software baseia-se na idéia de prover uma linha de produção

de soluções que atendam às necessidades específicas de cada cliente. Isto se dá através da
38
formalização de todas as atividades e seus produtos, trabalhando em forma de linha de

produção, com etapas e tarefas bem definidas para cada tipo de profissional, indo das tarefas
básicas da linha de produção até rotinas de controle de qualidade (Brito 2004).
Em uma fábrica de software, diferentes processos podem co-existir, adequados a

diferentes projetos. Para organizar e disciplinar o desenvolvimento de software é importante
determinar as atividades fundamentais que deverão estar presentes em qualquer processo
definido. A definição de um processo padrão estabelece uma estrutura comum a ser utilizada
pela organização nos seus projetos de software e constitui a base para a definição de todos os
processos (Rocha, 2001).
Assim sendo, o processo padrão estabelecido deve ser tomado como referencial no
necessário planejamento e definição das estratégias de cada fábrica e deve ser genérico o
suficiente para atender na maioria dos casos. A existência desse padrão também proporciona
economia de tempo e esforço a cada necessidade de customização do processo de
desenvolvimento dadas as particularidades de cada Projeto.
Segundo Humphrey (1989), um processo de desenvolvimento de software pode ser

entendido como um conjunto de passos (atividades) necessários para transformar os requisitos
do usuário em software. Ele aponta, porém, distinções entre um processo de desenvolvimento
de software e um processo de manufatura típico:
• O produto software geralmente é mais complexo que outros produtos
manufaturados;
• Em virtude da engenharia de software ser relativamente recente, o mercado não
dispõe de muitos gerentes e profissionais com o necessário conhecimento, nem
com a devida experiência para avaliar e calibrar um processo de desenvolvimento
de software;
• O custo insignificante de reproduzir o software leva à descoberta tardia de
problemas.
Fernandes (2004) acrescenta outra importante distinção: embora estejam definidos, em

termos de método de construção, forma de apresentação, precedência de construção e
agregação, os produtos gerados em cada passo do processo de software, a tangibilidade deles
39
fica a dever àquela de outros produtos manufaturados. Contribui para isso o fato de, durante
as fases que antecedem à codificação dos programas (produto concreto), os artefatos gerados
serem representações de idéias, donde com grande cunho subjetivo, cujo nível de detalhe
varia conforme a profundidade da análise realizada.
Até então, tratamos o processo de software no nível de “engenharia do produto”, ou

“construção do produto”, ou “processo produtivo de operação”, denominações adotadas por
Fernandes (2004), que ressalta o fato de um processo produtivo estar sempre associado a um
processo gerencial. Esse nível gerencial se traduz na gestão de uma ou de múltiplas
demandas, bem como na gestão de uma ou mais operações estratégicas.
Para Zahran (1998), o processo é o elo entre pessoas, equipes, tecnologia, estruturas
organizacionais e a gestão em um todo coerente que focaliza os objetivos e as metas de um
negócio. Portanto:
• O processo e a forma de apoiá-lo devem nortear a definição dos papéis
organizacionais e suas responsabilidades, das práticas gerenciais, das habilidades
requeridas e da seleção e instalação da tecnologia;
• A organização deve especificar as funções a desempenhar e monitorar as
atividades do processo;
• A gerência deve prover a direção estratégica e gerenciar o desempenho do
processo;
• Os técnicos devem ter habilidades para desempenhar com competência as
atividades do processo, e a tecnologia automatizá-las e apóia-las.
Para Lonchamp (1993), um processo de software é formado por um conjunto de

passos (atividades) parcialmente ordenados, associados a papéis, ferramentas e artefatos,
tendo como objetivo produzir e manter os produtos de software requeridos, ou seja, gerar ou
modificar um conjunto de artefatos. Atividades incorporam e implementam procedimentos,
regras e políticas; podem ser executas por agentes humanos com o apoio de ferramentas, ou
executados de forma totalmente automática (sem a intervenção humana).
Uma atividade aloca recursos (por exemplo, máquinas e orçamento), é escalonada,

monitorada e atribuída a desenvolvedores (agentes), que podem utilizar ferramentas para
40
executá-las. Um agente está relacionado com as atividades de um processo e pode ser uma
pessoa ou uma ferramenta automatizada. Diferentes agentes terão percepções diferentes
acerca do que acontece durante o processo de software. Por sua vez, cada artefato resulta de
uma atividade. (Rocha, 2005).
A descrição abstrata do processo de software caracteriza um modelo de processo de

software. Vários tipos de informação devem ser integrados em um modelo de processo para
indicar quem, quando, onde, como e por que os passos são realizados.
Segundo Conradi (1994), projeto é a instância de um processo, com objetivos e

restrições específicos. Pode-se dizer que um projeto é um esforço para desenvolver um
produto de software, ou seja, envolve uma estrutura organizacional, prazos, orçamentos,
recursos e um processo de desenvolvimento.
Podemos classificar um processo de desenvolvimento de software em dois tipos,

segundo sua forma de sua execução:
• O processo tradicional (ou processo pesado) tem como foco principal o
levantamento e o detalhamento rigoroso dos requisitos do sistema, antes do início
do desenvolvimento. Nesse levantamento, todas as necessidades do cliente são
definidas e documentadas, sendo que para cada um dos requisitos são gerados
documentos agregados, tornando o processo de análise e projeto bastante
demorados e de difícil manutenção, caso alguma especificação seja alterada. É
caracterizado pelo planejamento detalhado das fases seqüenciais de processo, e
pela disponibilização de artefatos gerados numa fase para a fase seguinte
(Pressman, 2000). Um exemplo de processo tradicional é o RUP – Rational
Unified Process (Krutchen, 2003).
• O processo ágil (ou processo leve) tem como foco principal a eficiência, ficando
no meio termo entre a inexistência e o rigor de um processo tradicional. Tem como
premissa que as mudanças são inevitáveis e propõe que a análise de requisitos seja
extremamente mutável (Beck, 2000). Sendo assim, os re-planejamentos são
constantes, não havendo uma etapa exclusiva para isso, e o foco está na
versatilidade da codificação. Pressupõe que cada atividade deve agregar valor ao
processo, comunicação, adaptabilidade e aprendizado constante. Em sendo sua
41
gestão orientada a pessoas, é esperado um ciclo de vida curto, durante o qual a

rotatividade seja mínima. Como exemplo de processo ágil temos o XP (Jeffries,
2001).
Quanto ao processo tradicional, que pode ser instanciado e customizado de acordo

com o porte da aplicação ou da Organização, a burocracia lhe agrega uma quantidade de
tarefas maior do que aquelas previstas no processo ágil, com previsível impacto no prazo de
execução. Porém, a informalidade do processo ágil é um dificultador quando do
desenvolvimento de software cujas regras de negócio são complexas, ou cujo escopo é
grande, ou que é desenvolvido por equipe numerosa e/ou distribuída geograficamente, uma
vez que a arquitetura do software pode ser redefinida e refinada a todo o momento.
Visando um ganho maior de produtividade e o alcance dos objetivos da fábrica, é

importante adotar o processo de desenvolvimento mais adequado ao seu perfil, pois a
alternância de processos não é recomendada, embora a possibilidade de flexibilização do
processo seja desejável e analisada caso a caso.
As fábricas que atendem ao modelo de outsourcing de sistemas são orientadas ao

processo tradicional. Em muitos casos, o próprio cliente exige a certificação da fábrica em
um modelo de qualidade reconhecido mundialmente, o que reforça a necessidade de clara
definição dos processos bem como da metodologia de coleta e acompanhamento das métricas
de produção. Cabe fazer referência a uma experiência relatada por Fowler (2004) de
implantação de um processo ágil em outsourcing de sistemas.
Assim sendo, a concepção desse processo de desenvolvimento em cada fábrica de

software não é genérico, e deve estar adequado ao tipo e ao contexto dessa fábrica,
considerando:
• Finalidade da fábrica de software: desenvolver pacotes (tais como sistemas de
gestão- ERP) ou software sob encomenda;
• Processos básicos de produção de software: desenvolvimento e/ou manutenção
(corretiva, evolutiva ou legal);
• Características do cliente, como por exemplo sua precisão ao enunciar requisitos;
42
• Perfil das equipes, em termos de conhecimento e experiência não apenas nas

ferramentas utilizadas na fábrica, mas no negócio do cliente;
• Disponibilidade de recursos x paralelismo de projetos encomendados à fábrica;
• Diversidade das plataformas de desenvolvimento.
Tais fatores também são determinantes na escolha das ferramentas automatizadas de

apoio aos processos de construção e gestão de software, do tratamento de defeitos e falhas a
ser adotado, da infra-estrutura computacional e de rede necessária.
2.6 – Gestão do Conhecimento
A complexidade do significado da palavra conhecimento pode ser rastreada até os

antigos filósofos, e sua natureza varia desde a filosofia, sociologia, economia e, mais
recentemente, ciência da informação.
Segundo Fernandes (2004), numa fábrica de software deve haver mecanismos para a
criação de conhecimento (explícito), armazenamento, referenciamento e disseminação,
conforme privilégios de acesso. A gestão desse conhecimento, um fator de impulso da
produtividade, ele entende por:
Gestão das habilidades dos colaboradores da fábrica e dos parceiros, gestão da
documentação e informações relativas à técnica de gestão de projetos, técnicas
de engenharia de software, documentação dos processos da fábrica,
documentação de sistemas da qualidade, componentes reutilizáveis,
informações bibliográficas, metodologias, e outras informações disseminadas
pela web, por exemplo.
Para Leary (2001), a gestão do conhecimento consiste em coletar e armazenar

sistematicamente o conhecimento adquirido, compartilhar este conhecimento através de uma
memória organizacional e promover o surgimento de novos conhecimentos. Para atingir esses
objetivos, a gestão do conhecimento envolve recursos humanos, organização e cultura, além
de tecnologia da informação, métodos e ferramentas para o seu apoio.
43
Bell (1974) define conhecimento como um grupo de idéias ou fatos organizados,

apresentando um julgamento sensato ou resultado de uma experiência, que é transmitido
através de algum meio de comunicação, de alguma forma sistemática.
Stewart (1998) conceitua conhecimento explícito como aquele que você sabe que tem,
e tácito como aquele que você não sabe que tem.
O dicionário Aurélio define aprender como “tomar conhecimento de algo, tornar-se

apto ou capaz de alguma coisa”. Kim (1993) atribui dois significados para aprendizagem:
aquisição de habilidades ou know-how, que implica capacidade física de produzir alguma
ação; aquisição do know-why, que implica na capacidade de articular uma compreensão
conceitual de uma experiência.
A aquisição do conhecimento foi revestida de enorme importância quando se percebeu

que os processos de criação, organização, aprendizagem e retenção são estratégicos e podem
ser utilizados contra a concorrência e a favor do desenvolvimento dos métodos de trabalho.
Pois, tais processos, advém de experiência única e própria da empresa, sendo portanto
dificilmente copiáveis já que os fatores inerentes à solução dos problemas são intimamente
ligados à cultura organizacional.
As formas como as organizações geram, disseminam e usam seu capital intelectual

constituem uma fonte de vantagem competitiva para as organizações desenvolvedoras de
software, permitindo que as experiências anteriores auxiliem a tomada de decisão. Nessas
organizações, para minimizar as dificuldades de implantação e posterior acompanhamento do
processo de desenvolvimento de software, são utilizados os sistemas computacionais ADS –
Ambientes de Desenvolvimento de Software (Vilela, 2002).
Segundo Natali (2003):

Implementar gestão do conhecimento em qualquer organização é um desafio
por conta do tempo e do esforço necessários antes que se comece a obter
retorno do investimento, o que no caso das fábricas de software se agrava por
conta da urgência cultural que permeia o setor, onde o tempo para registro e
recuperação do conhecimento é escasso. O maior desafio, porém, nas fábricas
de software, é que a maior parte do conhecimento na engenharia de software é
tácito, e assim pode permanecer, seja pela falta de tempo ou pela dificuldade
de explicitá-lo.
44
A engenharia de software é uma disciplina complexa, cujo conhecimento é

complexo e crescente, envolve um grande número de pessoas trabalhando em
diferentes fases e atividades. Constantes mudanças de tecnologia tornam o
trabalho dinâmico: novos problemas são solucionados e novo conhecimento é
criado todos os dias. Fábricas de software têm dificuldade de controlar que
conhecimento é esse, onde ele se encontra e quem o possui. Pois, além do
conhecimento do seu próprio domínio, é indispensável o conhecimento sobre
o domínio para o qual o software está sendo desenvolvido (área bancária,
hospitalar, trabalhista dentre outras); quando esse domínio é complexo, uma
dificuldade adicional é o entendimento do problema em questão.
A primeira linha de Gestão do Conhecimento, baseada em tecnologia da informação,

está focada no gerenciamento da informação. A segunda linha está baseada nas pessoas, cuja
valorização é fundamental nessa gestão.
Durante o processo de desenvolvimento de software, é fundamental que estejam

explicitados e documentados os conhecimentos:
• Inerentes ao produto (software);
• Produzidos a cada etapa do desenvolvimento, útil e necessário à etapa seguinte;
• Imprescindíveis para a posterior manutenção do produto, porém suplementares ao
gerado naturalmente no processo de desenvolvimento, como por exemplo
justificativas de adoção e descarte de soluções, documentação integral da versão
em produção, ao invés de documentações incrementais versão a versão do
software.
No caso da Indústria de TI, o parcelamento do trabalho (buscando abreviação e

simplificação de cada fase) confiado a cada operário (prática fordista), torna-se um
complicador da integração das diversas fases, se considerarmos a variável conhecimento do
produto, que muitas vezes é incrementado a cada fase e necessário à fase seguinte.
A dificuldade reside em explicitar, na documentação que tramita entre as diversas

competências de uma fábrica de software, todo o conhecimento construído durante aquela
fase.
No processo de desenvolvimento de um software, a compartimentação das

competências reflete a natureza distinta dos processos de cada uma delas, mas não restringe o
45
fluxo de conhecimento que as perpassa. Isso nos leva a refletir sobre as conseqüências de não
subdividir o trabalho apenas em duas fases, projeto e execução, tendência taylorista.
Outra questão a considerar é a posterior necessidade desse software recém

desenvolvido passar a sofrer manutenções corretivas (ajustes) e/ou evolutivas (mudanças de
regra e escopo). E, para que se independa nessa hora dos conhecimentos (tácitos e explícitos)
de quem os desenvolveu, um banco de conhecimentos deveria conter vários tipos de
conhecimento (segundo classificação listada em sistemas de informação por Alavi & Leidner,
em 2001), cujo registro nem sempre é necessário ao processo de desenvolvimento
propriamente dito, a saber:
• Declarativo: saber sobre
• Procedural: saber como
• Causal: saber o porquê
• Condicional: saber quando e sob que condições
• Relacional: saber a quem afeta e por quem é afetado
• Pragmático: útil para a organização
46
3 – Metodologia
O presente estudo tomou como base pesquisa realizada em duas fábricas de

software de uma mesma organização, ambas do tipo fábrica de projeto de software, que
atendem cada uma delas a um cliente em particular, e têm a mesma finalidade: atender
simultaneamente a demandas distintas, relacionadas a vários projetos do seu único cliente.
Tais fábricas, ambas em funcionamento, foram implantadas com defasagem de dois

anos a contar da implantação da primeira, as duas com a finalidade de, num futuro próximo
passar a atender grandes demandas externas.
A pesquisa realizada teve por finalidade estudar:

• Como processos de produção criativos e dependentes de conhecimento se adaptam
(ou não) a mecanismos de controle fordistas tomando como base a primeira
fábrica;
• Por que, apesar da linha assemelhada ao fordismo sugerida pela literatura e
induzida pela metáfora fábrica, a segunda fábrica com base na experiência da
primeira adotou soluções semi-flexíveis.
3.1 – Tipo de Pesquisa
Essa pesquisa pode ser classificada segundo a taxonomia de tipos proposta por
Vergara (2005), da seguinte forma:
Quanto aos seus fins:

• Descritiva, pois se propõe a expor estrutura organizacional, processos e
controles adotados em duas fábricas de software, permitindo a identificação e
análise de pontos em comum de cada uma delas com os modelos de produção
fordista e pós-fordista.
• Explicativa, na medida em que permitirá identificar causas e efeitos das
medidas de flexibilização sabidamente adotadas na segunda fábrica.
47
Quanto aos meios propostos:

• Bibliográfica, para permitir a elaboração de referencial teórico e metodológico
do estudo, a partir da investigação em materiais publicados em livros, revistas,
“sites” da web especializados em material acadêmico, dissertações e teses, que
versem sobre: metáfora, taylorismo, fordismo, pós-fordismo, fábricas de
software e gestão de conhecimento.
• Documental, pois se valerá de documentos que descrevem os processos
adotados em cada uma das fábricas, e de relatórios de desempenho e análises
críticas internos não disponíveis ao público em geral.
• Estudo de Caso, dado que será uma investigação empírica sobre um fenômeno
contemporâneo, inserido no contexto da vida real, para responder a questões
“como?” e “por que?” (Yin, 2001: pg 19). Trata-se de um estudo de caso do
tipo que enfoca duas sub-unidades (espaços diferenciados) que pertencem a
uma unidade maior, variam no tempo, são distantes geograficamente, e serão
analisadas em momentos distintos de modo comparativo (Gerring apud
Gondim at al, 2005: pg 50).
3.2 – Universo da Amostra
Esse par de fábricas, identificadas doravante como Fábrica A e Fábrica B, foi

selecionado pelo fato singular da determinação do modelo da segunda ter sido fruto das lições
aprendidas com os acertos e erros da primeira e, peculiarmente, pelo distinto grau de rigidez
dos respectivos modelos de gestão, tendendo cada um deles à semelhança com o fordismo e
com o pós-fordismo. Em se tratando de eventos recentes e presentes, todas as informações
requeridas estavam de fácil acesso.
Além disso, as fábricas escolhidas eram candidatas a permitir extensa análise do

fenômeno, dado que possuem escopo de atuação significativamente mais completo do que a
maioria das fábricas de software atualmente em funcionamento no país: de modo geral
encontramos fábricas de programas, ou quando do tipo fábrica de projeto de software, são
customizadas para as necessidades de um único projeto.
48
Essa característica escopo mostra-se um diferencial porque, quanto mais amplo o

escopo de uma fábrica de software, mais conhecimento do negócio onde vai estar inserido o
software ela requer. Assim sendo, uma primeira fábrica exclusivamente de programas requer
menos conhecimento de negócio do que uma segunda de escopo mais amplo, só que dedicada
a um único projeto, que por sua vez também requer menos conhecimento do que uma terceira
fábrica de mesmo escopo da segunda, mas que por sua vez atenda a diversos projetos
simultaneamente, e assim sucessivamente.
Para ilustrar, nas visitas realizadas em tais fábricas, o recorrente problema de

rotatividade de mão-de-obra que sazonalmente lhes afeta conforme o mercado fica mais ou
menos aquecido, traz para cada uma delas diferente grau de dificuldade:
• Numa fábrica de programas, além do prazo de substituição ser menor, menos
tempo o novo empregado demora a render plenamente, dado que é suficiente que
ele conheça as ferramentas utilizadas no processo de desenvolvimento, pois todo o
serviço a executar já vem especificado num nível de detalhe tal que dispensa saber
a que usuário se destina, em que rotina operacional a funcionalidade a se
desenvolvida vai se encaixar, nem o porquê das regras aplicadas;
• Analogamente, em sendo uma fábrica de projeto de software, onde por
característica o conhecimento do negócio é um pré-requisito, se existe um único
projeto a se dedicar, o conhecimento envolvido é mais restrito do que quando são
vários os projetos, cada um deles com seu cabedal específico de conhecimentos.
3.2.1 Fábrica A
3.2.1.1 Origem da Fábrica A
Essa fábrica nasceu em Maio de 2005, a partir da reestruturação de um departamento

da organização dedicado à manutenção e ao desenvolvimento de software, distribuído pelas
capitais Belo Horizonte, Rio de Janeiro e Brasília, que já funcionava há mais de 20 anos.
Tal departamento sempre se dedicou a um único cliente da área de governo, no

segmento de crédito imobiliário, desenvolvendo e dando manutenção a diversos produtos
49
(sistemas) que atendem a gestores distintos no ambiente desse cliente. Cada um desses
gestores atua num ramo diferente do negócio, porém os sistemas têm de modo geral alguma
interligação.
Antes da reestruturação, a responsabilidade da manutenção desses sistemas, alguns

deles desenvolvidos há décadas, estava basicamente a cargo de equipes que haviam, inclusive,
atuado na fase de desenvolvimento, e dominavam o conhecimento requerido para tal
atividade, tanto das regras do negócio como da solução em si e do seu histórico de evolução.
Nessa época, o grau de completeza e atualização da documentação desses sistemas

antigos era inversamente proporcional à sua idade, donde a alocação de técnicos com o
conhecimento tácito tornava-se imprescindível para as tarefas de manutenção. Convém
explicitar que ainda hoje, parte dos empregados da Fábrica A tem muitos anos de casa, e
inegavelmente é detentora de significativa parcela do conhecimento (negócio e produtos)
requerido para seu funcionamento.
Antes da migração para um modelo fabril, existiam equipes multifuncionais por

produto ou conjunto de produtos afins (que atendiam aos mesmos gestores), e cada equipe era
completa o suficiente tanto para dar manutenção como para desenvolver novos módulos
desses produtos, ou mesmo novos produtos daquele contexto. Isto é, cada equipe era
responsável pelo ciclo completo de desenvolvimento, e seus membros, multifuncionais,
atuavam praticamente durante todo esse ciclo. Quando muito a distinção de responsabilidades
se resumia ao cargo formal; nesse caso, apenas a distinção de analista e programador, cabendo
aos analistas desde o levantamento de requisitos até a especificação dos programas, depois
testes e disponibilização do software para produção, e aos programadores a etapa de
implementação.
A figura a seguir ilustra a estrutura do departamento nesse período pré-fábrica,

considerando o ciclo de desenvolvimento de quatro fases adotado na época, bem como as três
equipes, uma em cada capital, cada uma delas dedicada e responsável pelos produtos que lhe
cabiam:
50
Estrutura Departamental - Até Maio/2005
Equipe Φ Equipe Ψ Equipe Ω

Fases: 1, 2, 3, e 4 Fases: 1, 2, 3, e 4 Fases: 1, 2, 3, e 4
Produtos: X e Y Produto: W Produto: Z
Figura 8: Diagrama da Pré-Estrutura da Fábrica A (fonte: própria)
Com a perspectiva de perda desse antigo cliente, e daí evidente necessidade de sua
substituição em médio prazo por outros clientes, que provavelmente serão ligados a outros
ramos de negócio, foi decidida a reestruturação do departamento visando a criação de uma
fábrica de software, migrando assim radicalmente, de produto para processo, o foco da
estrutura. Tal mudança foi também estimulada pela possibilidade do departamento passar a
atrair outras demandas da organização, que estavam sendo direcionadas a fábricas de software
indianas.
Assim sendo, as equipes existentes foram dissolvidas e seus membros realocados em

novas equipes denominadas “competências”, considerando sua experiência mais expressiva
ou afinidade com cada uma das fases do ciclo de desenvolvimento, que por sua vez também
foi revisto a partir da subdivisão das fases consideradas anteriormente. Com isso, cada
competência passou a atuar indistintamente em todos os produtos.
Vale comentar que, segundo os entrevistados, tal ruptura de paradigma foi uma
experiência traumática tanto para os empregados como para o corpo gerencial, uma vez que
ao mesmo tempo foram mudadas chefias, composição de equipes, atribuições e processos de
trabalho, enquanto as solicitações de serviço continuavam a chegar sem tréguas, no mesmo
ritmo de antes. Ressaltaram, porém, nessas entrevistas que nesse momento de tantas
dificuldades, o espírito de corpo de um grupo trabalhando junto há tantos anos como aquele,
fez com que fossem envidados todos os esforços para não permitir que o cliente fosse afetado
de forma significativa.
Uma vez reestruturado o departamento, a Fábrica começou a operar com a seguinte

estrutura:
51
Competência 1
Produtos: X, Y, W e Z
Competência 2
Estrutura Inicial da Fábrica A
Competência 3
Ano I
Competência 4
Competência 5
Competência 6
Figura 9: Diagrama da Estrutura Inicial da Fábrica A (fonte: própria)
Durante o ano de 2006, apareceram dificuldades na operação da fábrica que tiveram

por conseqüência atrasos nas entregas e enfileiramento de solicitações de manutenção, tanto
corretiva como evolutiva. Segundo os entrevistados, tais problemas não estavam restritos a
uma competência específica, sendo o desconhecimento por parte dos integrantes de cada
competência, tanto da arquitetura do produto, das respectivas regras de negócio como do
contexto nos usuários, a principal causa identificada. As solicitações de manutenção de
sistemas, tanto corretivas como evolutivas, eram mais críticas do que as solicitações de
desenvolvimento, onde por ser uma situação nova, o conhecimento necessário deveria surgir
mesmo ao longo do serviço; ao passo que, num serviço de manutenção, até que fosse
identificado o quê e como alterar, muito tempo se despendia estudando a documentação
(ainda falha), ou interrompendo colegas de outra competência para pedir esclarecimentos.
Outra causa identificada foi a inexistência de uma gerência de solicitações dedicada a

cada produto, que acompanhasse essas solicitações enquanto ela trafegava de uma
52
competência para outra, não apenas apoiando a questão do conhecimento mas também
atuando na priorização da execução dos serviços.
Assim sendo, a Fábrica A adentrou o ano de 2007 com as seguintes novas orientações:
• Superpor à estrutura vigente, matricialmente, uma gerência por produto
perpassando todas as competências;
• Investir fortemente na atualização e complementação da documentação de todos os
sistemas já prontos, de modo a agilizar a execução das solicitações de manutenção,
não apenas registrando como também democratizando o acesso a esse
conhecimento;
• Redução da quantidade de competências.
3.2.1.2 Estrutura da Fábrica A
Com isso, na época do nosso estudo, a estrutura vigente na Fábrica A era a seguinte:
X Y W Z
Competência 1
Competência 2
Estrutura Fábrica A
Ano II
Competência 3
Competência 4
Competência 5
Figura 10: Diagrama da Estrutura da Fábrica A durante o Estudo (fonte: própria)

53
Contava com 128 empregados, e estava realizando serviços de desenvolvimento,

manutenção evolutiva e corretiva de sistemas, em alta (mainframe) e baixa plataforma.
Continuava atendendo ao mesmo cliente da área governamental, e ao contrário do que se
supunha (perda desse cliente) em 2005, tal contrato havia sido renovado, com escopo ainda
maior, motivo pelo qual havia sido necessário aumentar as equipes.
O tipo dessa fábrica, pela classificação de FERNANDES (2004) traduz-se num híbrido
entre Fábrica de Projeto de Software e Fábrica de Projetos Físicos, dado que o primeiro
processo de desenvolvimento a seu cargo é a Especificação Lógica. Está subdividida nas
seguintes competências, que atuam em seqüência:
• Requisitos e Escopo (RE)
• Projeto Lógico e Físico (PLF)
• Implementação (IM)
• Testes (TE)
• Disponibilização (DI)
Desde a sua criação, foi previsto na Fábrica A que as competências Projeto Lógico e
Físico, e Implementação estariam subdivididas cada uma delas em células dedicadas às
plataformas de desenvolvimento alta e baixa, e que todas as competências atenderiam a todos
os produtos.
Como os gestores estão sediados em Brasília, os técnicos adicionais contratados para

atuar na competência Requisitos/Escopo foram contratados já nessa cidade. Como a equipe
responsável pelo Disponibilização também interagem bastante com os gestores na fase de
homologação do software, essa competência também está radicada em Brasília.
Assim sendo, a competência Requisitos/Escopo é suportada por duas equipes, uma

sediada em Belo Horizonte outra em Brasília; a cada uma das demais competências
corresponde uma única equipe, sendo que Disponibilização está sediada em Brasília e as
demais em Belo Horizonte.
No Rio de Janeiro encontram-se parte das competências requisitos/Escopo e Projeto

Lógico e Físico.
54
3.2.2 Fábrica B
3.2.2.1 Origem da Fábrica B
A segunda fábrica, denominada Fábrica B e situada no Rio de Janeiro, foi criada a

partir da cisão de um departamento que já estava desde 1998 dedicado a um único cliente a
quem prestava serviço de manutenção de sistemas (corretiva e evolutiva). Aplicava-se a esse
departamento exatamente o mesmo modelo representado na Figura 6 para a Fábrica A, uma
vez que estava organizado em equipes multifuncionais, cada uma delas alocada a um produto
ou conjunto de produtos afins e integrados. E esse cliente, também da esfera governamental,
milita na área de trabalho e emprego.
No início de 2007, o escopo do contrato com esse cliente aumentou

significativamente, uma vez que ficou firmado o compromisso de, em paralelo à manutenção,
serem redesenvolvidos os mesmos sistemas e criados novos, numa plataforma mais moderna,
um desafio muito grande considerando o prazo acordado. Cabe explicar que a estratégia
adotada pela organização, na negociação desse novo serviço, foi oferecer um prazo mais curto
que a concorrência, contando já deter o conhecimento do negócio, o que permite acelerar o
processo de desenvolvimento.
Mesmo contando com a contratação de novos empregados para fazer frente ao novo
serviço, estava instalada a necessidade de repartir os empregados que detinham tal
conhecimento entre os serviços de manutenção e desenvolvimento, para continuar garantindo
prazo e qualidade. Isso porque até que o novo sistema esteja pronto e em produção, a
organização está contratada para continuar mantendo os sistemas atuais.
Para fazer frente à manutenção dos sistemas atuais, foram reservadas duas equipes
multifuncionais, cada uma delas dedicada a um conjunto de produtos definido com base na
identificação das duas linhas principais do conhecimento do negócio. No caso desse
departamento, o fato da documentação desses sistemas estar atualizada e completa, contribuiu
bastante para que, sem prejuízo do andamento dos serviços, fossem complementadas as
equipes com novas contratações.
55
Atendida a vertente do serviço de manutenção, não restaram empregados suficientes

para sustentar a estrutura anterior, alocando uma equipe completa para cada produto a ser
desenvolvido, cada uma delas com pelo menos um membro detendo o conhecimento do
negócio requerido em cada fase do processo de desenvolvimento.
Então, a solução adotada foi estruturar uma linha de produção única, dedicada ao
desenvolvimento em paralelo dos diversos produtos encomendados, distribuindo os
empregados que detinham o conhecimento do negócio pelas várias estações dessa “esteira”,
surgindo nesse momento a Fábrica B, com 36 empregados, 16 dos quais recém contratados.
Cabe acrescentar que essa solução veio ao encontro de uma diretriz da organização.
Visando aumentar a produtividade e baixar os custos, ela pretende que esse novo modelo,
devidamente validado, posteriormente se estenda ao serviço de manutenção, e em seguida aos
demais Projetos contratados por esse mesmo cliente, atualmente a cargo de outras equipes
(multifuncionais) também sediadas no Rio de Janeiro.
3.2.2.2 Estrutura da Fábrica B
A tipologia da Fábrica B se enquadra perfeitamente na classificação fábrica de

projeto de software de FERNANDES (2004), e encontra-se subdividida nas seguintes
competências:
• Projeto Lógico (PL)
• Projeto Físico (PF)
• Implementação (IM)
• Administração de Dados e Componentes (DC)
• Testes
As competências Projeto Lógico, Projeto Físico e Implementação atuam

rigorosamente em seqüência, mas as duas últimas atuam permanentemente ao longo do
processo, conforme são demandadas.
56
Na ocasião dessa subdivisão, foram consideradas as seguintes lições já aprendidas a

essa altura com a Fábrica A, ou seja:
• Quanto mais incompleta estiver uma etapa do serviço, ao ser transferida de uma
competência para a outra, mais conhecimento se perde, mais defeitos surgem e se
propagam;
• Explícita e acompanhada gestão do conhecimento, na passagem de serviço entre as
competências, é fundamental;
• A definição precisa das raias de atuação de cada competência (atividades,
artefatos), evita retrabalho e lacunas;
• A falta de documentação completa e atualizada compromete a esteira de produção,
dado que o conhecimento fica retido na memória do criador; na primeira
oportunidade em que esse conhecimento for requerido, esse empregado precisará
estar disponível no mínimo para prestar esclarecimentos.
Na figura abaixo está representado, para cada Fábrica, o âmbito de atuação previsto
para cada competência conforme as fases do processo:
Figura 11: Comparativo de Competências – Fábricas A e B (fonte: própria)

57
É possível observar a redução de cinco para quatro competências atuando em

seqüência, bem com no caso da Fábrica B, a fronteira entre projeto e execução passando a
coincidir com o limite da competência Projeto Lógico.
Para determinação dessas competências, conforme relato dos coordenadores da

Fabrica A, foi necessário partir da correlação entre os artefatos a produzir em cada fase e as
atribuições previstas para consecução desses objetivos. A seguir, tais atribuições foram sendo
agrupadas segundo a expertise requerida, associada a cargos e perfis.
A figura abaixo descreve as atribuições previstas para cada competência, sendo qu,
pelo relatado, essa versão que está sendo apresentada foi fruto de um período de 2 meses de
sucessivos ajustes, de modo a precisamente definir o raio de ação de cada competência:
Figura 12: Quadro Atribuições x Competências (fonte: Fábrica B)

58
A preocupação constante nesse período era evitar que uma competência, para executar
seu trabalho, dependesse de um conhecimento que efetivamente não estivesse registrado nos
artefatos que recebeu ou que não lhe tivesse sido transmitido explicitamente durante a
passagem de serviço pela outra competência.
Para prevenir falhas de documentação, esse processo instituiu que a equipe de testes,
por amostragem, revisaria os artefatos gerados durante o processo de desenvolvimento,
verificando completeza e coerência com os demais artefatos.
3.3 – Seleção dos Sujeitos
Foram entrevistados os responsáveis por cada fábrica e os respectivos coordenadores

de cada competência, conforme o previsto, totalizando 12 convidados.
Foram aplicados dois modelos de questionário, absolutamente análogos, customizados

segundo o conjunto de competências de cada uma das fábricas. Tais questionários foram
repassados a todos os respectivos empregados de cada fábrica, a menos dos coordenadores e
responsáveis, tendo sido devolvidos 92 questionários preenchidos. Os modelos de
questionários, bem como o roteiro da entrevista constam dos Anexos, e abaixo, na Tabela 1,
está a distribuição dos respondentes desses questionários, por fábrica e competência:
Fábrica A Fábrica B
Competências Total
Qtd % Qtd %
Escopo e Requisitos 12 20.3% 0 0.0% 12
Projeto Lógico 0 0.0% 7 21.2% 7
Projeto Físico 0 0.0% 5 15.2% 5
Implementação 23 39.0% 7 21.2% 30
Testes 14 23.7% 8 24.2% 22
Banco de Dados 1 1.7% 0 0.0% 1
Dados e Componentes 0 0.0% 6 18.2% 6
Projeto Lógico e Físico 7 11.9% 0 0.0% 7
Disponibilização 2 3.4% 0 0.0% 2
Totais 59 33 92
Tabela 1: Resultado Tabulação Questão 1 (fonte: própria)
A realização de um pré-teste dos questionários (aplicação de três questionários em

cada uma das fábricas) nos permitiu adequar o formato de apresentação das questões do grupo
59
2, onde o respondente tinha que tomar por base a competência assinalada na primeira questão,
pois foi verificado que a redação não estava clara. Nenhum dos questionários respondidos foi
invalidado, sendo que as perguntas que ficaram sem resposta foram contabilizadas em
separado.
3.4 – Coleta de Dados
Sob a ótica do processo, a pesquisa no campo foi realizada através de visitas de

observação, entrevistas e análise documental em cada uma das fábricas, sendo cumpridas as
seguintes etapas:
• Levantados, em cada fábrica, os processos de produção, de gestão do
conhecimento agregado aos processos, bem como as ferramentas de supervisão e
planejamento utilizadas;
• Levantados, em cada fábrica, como se dá a passagem de conhecimento de uma
competência para outra, e como esse conhecimento é formalizado;
• Levantados, em cada fábrica, indicadores de produtividade, cumprimento de
prazos e satisfação do cliente;
• Confrontados, em cada fábrica, os processos levantados com os modelos fordista e
pós-fordista, estabelecendo as interseções, bem como identificando as soluções de
flexibilização praticadas.
Sob a ótica do empregado (operários), foram verificados, através da aplicação do

questionário, no universo de cada uma das fábricas:
• o perfil (grau de escolaridade, competências em que atua, formação específica para
atuar em cada competência, tempo de experiência em TI, cargo, salário) dos
operários;
• se os operários consideram o conhecimento produzido na sua fase do trabalho
necessário e útil também nas fases subseqüentes, e nesse caso, se consideram que
ele foi todo explicitado na documentação gerada;
• com que frequência, durante a execução de uma fase de trabalho, os operários
precisam recorrer ao conhecimento tácito das equipes que trabalharam nas fases
anteriores;
60
• a percepção (tanto daqueles que têm experiência pregressa no modelo de

desenvolvimento tradicional como daqueles que já ingressaram no mercado
trabalhando em Fábricas de Software) quanto à sua satisfação pessoal com a
função exercida, com o resultado do trabalho e com sua possibilidade futura de
recolocação no mercado.
• se os operários consideram criativo o trabalho que realizam;
• se os operários sentem sua criatividade tolhida pela rigidez do processo.
Os dados coletados foram consolidados e analisados, possibilitando uma análise

comparativa das Fábricas A e B sob os pontos de vista de modelo de produção e gestão do
conhecimento agregado aos processos, bem como da visão dos operários.
3.5 – Tratamento dos Dados
Na etapa inicial, os dados levantados pelas pesquisas bibliográfica e documental foram

analisados e concatenados, de modo a constituir referencial teórico para esse trabalho,
identificando aspectos relevantes que ajudaram a distinguir a essencialidade da aparência, no
fenômeno estudado.
As entrevistas permitiram colher as interpretações dos diversos participantes sobre os

processos vivenciados. Tais percepções, bem como os pontos positivos e negativos
observados concederam a impressão pessoal de cada um deles sobre o objeto do estudo. Os
pontos mais citados ou aqueles com maior grau de afinidade, indicaram os fatores
preponderantes a estudar e direcionaram a seleção de perguntas a constar dos questionários.
Os dados levantados através dos questionários sofreram tratamento estatístico,

buscando identificar padrões comuns e possível correlação entre os fatores observados, que
pudessem auxiliar nesse estudo.
61
3.6 – Limitações do Método
Por serem apenas duas fábricas a estudar, com modelos discrepantes, a

instrumentalidade do estudo se restringe, na medida em que tal universo não permite
generalizar as conclusões para construção de modelos teóricos que suportem a generalização
teórica no futuro.
Por serem por sua vez fábricas do mesmo tipo, fábricas de projeto de software, e que
portanto englobam a fase de concepção de projetos lógicos, ficou bastante evidente nesse
estudo a faceta da flexibilidade incorporada ao sistema produtivo. Isto porque, não apenas
essa fase inicial do processo de desenvolvimento de software é a que exige maior criatividade,
como também as mudanças de regra e de escopo que acontecem no ambiente do cliente
eclodem dentro do ambiente da fábrica, acentuando a característica de mão-dupla da esteira
de produção. Os dados da pesquisa, ao demonstrar que na competência implementação são
mais fortes os traços repetitividade das tarefas e a especialização do empregado, nos permitem
inferir novamente que se objeto de estudo fossem fábricas de programas, as características de
flexibilidade seriam menos acentuadas.
A segunda fábrica estava em operação há apenas cinco meses, período esse em que
seus processos ainda estavam sofrendo otimização, isto é, não estavam completamente
estáveis, o que pode ter produzido um viés nos resultados observados.
Embora a redação das perguntas do questionário sempre frisasse que as respostas

deveriam levar em conta apenas a experiência do operário na atividade de desenvolvimento,
como na Fabrica A também é desenvolvida a atividade de manutenção, atividade essa com
problemas mais evidentes, existe a possibilidade dessa influência quando do preenchimento
dos questionários.
Quanto ao tratamento dos dados, mesmo partindo do pressuposto da inexistência de

neutralidade científica, há que se considerar a inserção da autora no contexto de um dos
objetos pesquisados, a Fábrica B, e os possíveis reflexos dessa atuação em sua interpretação
dos dados obtidos, apesar do consciente esforço para o necessário distanciamento.
62
4 – Apresentação dos Dados
Em ambas as fábricas foi possível observar que, com o uso das novas ferramentas de
desenvolvimento de software, explicitamente chamadas de “ferramentas de alta-
produtividade”, o processo está sendo automatizando de tal forma, com base no conceito de
encapsulamento de funcionalidades, que a atividade de programação, por exemplo, se
restringe, em muitos casos, a um esforço de montagem de componentes prontos; isto é, já
estão previamente definidos que componentes devem ser utilizados, em que seqüência e
circunstância, ficando com isso o programador dispensado de conhecer a inteligência
embutida nesses componentes. Só que com isso, o programador tem cada vez menos
oportunidades de criar, e cada vez fica mais distante do conhecimento do negócio do cliente, o
que reduz seu valor agregado ao seu grau de especialização nas ferramentas utilizadas naquela
fase do processo. Em contrapartida, programadores podem ser substituídos com ônus de prazo
menor.
A criação desses componentes, por sua vez, também pode ser semi-automática, a partir
de padrões pré-estabelecidos, com auxílio da mesma ferramenta. Em princípio, sem entrar no
mérito da complexidade de gerenciamento de uma biblioteca de componentes, quanto mais
componentes especializados estiverem disponíveis no ambiente de desenvolvimento daquele
produto, maior a velocidade da esteira em seus estágios finais.
Em termos de supervisão e controle, na composição do próprio ferramental de

desenvolvimento, em ambas as fábricas observamos procedimentos similares: cada vez que
um desenvolvedor de software acessa um artefato, é contabilizado automaticamente o tempo
dedicado à atividade em curso até que o artefato seja liberado, sendo que é esperado do
desenvolvedor que ele declare as eventuais interrupções. Na prática, a cada interrupção do
trabalho, cabe ao desenvolvedor acionar botões “Parar” e “Reiniciar” presentes na tela de sua
estação de trabalho; se ele omitir a interrupção, o tempo continua sendo contabilizado como
se ele estivesse trabalhando nesse artefato e os relatórios que a própria ferramenta emite, vão
acusar sua baixa produtividade, dado que investiu mais tempo do que o esperado naquela
atividade. Por outro lado, sucessivas interrupções não justificadas pela dedicação a outras
tarefas que lhe foram designadas em paralelo também penalizam o desenvolvedor.
63
Também está implantada nas duas fábricas, bem como nos clientes, uma ferramenta
própria da organização, o sistema SIARQ – Sistema Integrado de Administração dos
Registros da Qualidade, que tem por finalidade registrar, acompanhar e gerenciar cada
solicitação de serviço desde sua emissão até o aceite final, gerando automaticamente
indicadores de qualidade (cumprimento de produtividade, cumprimento de prazo e satisfação
do cliente), que permitem buscar a contínua melhoria dos serviços prestados. Integrado ao
SIARQ está implantado o Sistema Gênesis, outra ferramenta desenvolvida pela organização,
que permite distribuir e alocar recursos, acompanhar execução de tarefas e alocação de
esforço, monitorar a tramitação das ocorrências registradas nos testes até sua solução,
passando pelas medições, em ponto de função, do porte de cada uma das versões de sistema
antes e depois das manutenções.
Os empregados alimentam o Gênesis diariamente com as horas gastas em cada tarefa,

uma vez que o controle citado anteriormente se atém àquelas atividades executadas através
das tais ferramentas de alta produtividade, ao passo que no Gênesis são lançadas todas as
tarefas, inclusive participação em reuniões, de modo que todo o esforço possa ser coletado.
Apenas na Fábrica B está implantado o conceito de Iteração5, que identifica cada

“pacote” que trafega na esteira, e permite aos coordenadores de cada competência, e ao
responsável pela fábrica, visualizar através do acompanhamento do planejamento (executado
via Microsoft Project ) em que estágio do percurso se encontra cada “pacote”. Para facilitar o
acompanhamento, os coordenadores das competências e o responsável pela Fábrica utilizam
um painel de cores, que demonstra, de cada funcionalidade:
• o estágio da evolução no processo de desenvolvimento;
• as horas previstas segundo a metodologia de Pontos de Casos de Uso, que estima o
porte de uma funcionalidade antes dela estar pronta o suficientes para ser medida
com mais precisão através dos pontos de função;
• as horas realizadas por ponto de Caso de Uso.
Esse painel permite ainda estimar prazos com base nos históricos de horas por ponto
de caso de uso, considerando a realidade dessa fábrica.
____________________________
5
Iteração é um subconjunto das funcionalidades que compõem o software, também denominadas Casos de Uso.
64
Na Fábrica A, controle análogo é realizado, só que por tarefa, através do Gênesis, que
por sua permite o perfeito rastreamento de todo o processo de execução.
As duas fábricas atribuem grande importância a esses controles, pois além de

viabilizar o acompanhamento do dia-a-dia, permitem manter um registro histórico capaz de
calibrar as métricas de produtividade adotadas, para conferir maior precisão tanto a futuras
estimativas de prazo de custo, bem como à avaliação dos resultados alcançados. Tais métricas
se baseiam nas horas gastas em cada etapa do processo, a exemplo do MTM – Method Time
Measurement das linhas de produção fordistas.
Nas entrevistas ficou claro que esses controles consomem significativo tempo dos
executantes. Mas como esse tempo não está ainda precisamente quantificado, os prazos
concedidos ainda não são sistematicamente ajustados a essa necessidade.
Quanto à gestão do conhecimento, nas duas fábricas, a coleta e armazenamento

sistemático do conhecimento adquirido ao longo do processo de desenvolvimento de software
seguem os padrões de documentação definidos pela organização, estando esse acerto
disponível em meio eletrônico, com adequado controle de versões.
Para a atividade de manutenção, no entanto, segundo o resultado das entrevistas, esse

padrão adotado não favorece a adoção da esteira de produção, no caso por exemplo das
especificações de programa. Ao proceder uma alteração de programa, qualquer membro de
uma competência deveria, sem nenhum conhecimento pregresso e apenas consultando a
documentação, estar apto a realizá-la sem precisar analisar a codificação para se situar, o que
nem sempre acontece. Isto porque, embora estejam documentadas todas as sucessivas
alterações que foram originando cada nova versão, não se dispõe da documentação completa
da versão atual propriamente dita, e sim da documentação de cada um dos incrementos a
partir da versão original.
Aprofundando a análise da gestão do conhecimento nessas fábricas, verificamos que,

na Fábrica B, durante o percurso da esteira de produção, ocorrem várias sessões que
propiciam o compartilhamento e a ampliação desse conhecimento, sob a forma de:
65
• Reunião de verificação/validação, onde representantes das demais competências

são convidados a questionar os artefatos produzidos e apresentados por uma delas,
contribuindo com sugestões, esclarecendo dúvidas inclusive sobre aspectos que
impactaram ou impactarão seu futuro trabalho.
• Reunião de passagem de conhecimento, Iteração a Iteração, da qual participam as
competências que estão entregando e recebendo o serviço, tendo sido distribuído
todo o material (artefatos) para análise prévia. Nessa reunião se procura explicar o
porquê das soluções adotadas, e se for relevante o motivo do descarte de outras
soluções; além disso, aqueles pontos já identificados como mais complexos são
revistos, de modo a garantir que o entendimento seja completo e preciso. Dúvidas
de redação também são esclarecidas.
Nas entrevistas, os coordenadores da Fábrica B afirmaram que essas práticas têm

minimizado bastante as interrupções e principalmente o retrabalho, e ressalvaram tais sessões
não impedem as competências mantenham contato informal, se necessário for. Na Fábrica A,
não chega a ser realizada, e nem mesmo está prevista, uma comunicação formal entre as
competências que estão entregando e recebendo cada “pacote”; assim sendo não é transmitido
qualquer conhecimento que transcenda os artefatos.
Outro ponto importante a registrar, sobre as entrevistas realizadas na Fábrica B, é o

fato de ter sido intencional, e conscientemente remetida a Taylor, a subdivisão clara do
trabalho em projeto e execução, ao serem definidas as competências. Explicaram ter levado
em conta a constatação de que o parcelamento do trabalho (buscando abreviação e
simplificação de cada fase) confiado a cada operário (prática fordista), complica a “passagem
do bastão”, quando considerada a variável conhecimento obtido em cada fase e necessário à
fase seguinte.
A subdivisão nas competências definida na Fábrica B não apenas foi guiada pela
preocupação de restringir ao interior de cada competência o tráfego de conhecimentos, mas
também para criar espaços onde pudessem ser alocados os novos contratados, possibilitando
assim que pudessem render apesar da falta do conhecimento prévio do negócio.
Exemplificando, as competências Projeto Físico e Implementação, da forma que o processo
66
foi concebido, prescindem desse conhecimento, donde as alterações nessas equipes são mais
simples de efetuar.
4.1 – Dados Globais
Os 92 questionários válidos foram tabulados de forma a permitir a análise comparativa

das Fábricas, competência a competência.
4.1.1 – Dados Sobre Gestão do Conhecimento
Tabela 2: Resultado Tabulação Questão 2.1 (fonte: própria)
Conforme demonstra a tabela 2 acima, na percepção de todos os respondentes, o

registro do conhecimento que surge durante a execução do seu próprio trabalho é falho.
Apenas 11,9% dos respondentes na Fábrica A, e 9,1% na Fábrica B consideram que as que as
soluções eleitas e adotadas estão detalhadamente documentadas. Do provável conhecimento
obtido durante o processo de desenvolvimento, por ocasião das discussões onde foram
descartadas outras soluções, não é feito registro.
Mediante o fato da tabulação ter apontado o pior resultado coincidentemente nas

competências que lidam com bases de dados nas duas fábricas, nova entrevista foi realizada
67
na Fábrica B, diretamente com os empregados alocados na competência DC (administração de

dados e componente). Houve uma surpresa inicial quanto à convergência de opiniões, dado
que esse assunto até então não havia sido discutido, nem mesmo por ocasião do
preenchimento do questionário.
Instigados a apontar que conhecimento percebiam estar se perdendo, explicaram de

pronto que os artefatos a produzir previstos na atividade de modelagem das bases de dados,
Dicionário de Dados e Diagrama de Entidades e Relacionamentos, não comportam o registro
dos necessários cuidados a tomar quando da implementação, a fim de melhor explorar os
recursos e respeitar as restrições do modelo construído. Os coordenadores da Fábrica B
decidiram então aprofundar essa análise com o grupo, depois com as demais competências,
para em seguida proceder alterações nos formatos dos artefatos, ou mesmo acrescentar um
novo artefato a ser produzido nessa fase do processo de desenvolvimento.
A questão 2.2 indaga sobre esse conhecimento que não chegou a ser registrado (tabela
3). Na Fábrica B, 27,3% estão convictos de que esse conhecimento chega a ser transmitido
para a próxima competência, e o risco percebido de perda mais evidente está na competência
de Testes. Na Fábrica A, esse risco se apresenta principalmente nas competências
Implementação e Testes.
A questão 2.3 (tabela 4) versa sobre o impacto causado pelas lacunas de conhecimento
no ritmo de trabalho dos empregados, uma vez que lhes obriga a interromper a execução do
serviço para garimpar tal conhecimento. Acusam prejuízo 28,8% na Fábrica A, e 3% na
Fábrica B. Novamente, as competências mais afetadas são aquelas que lidam com as bases de
68
dados em ambas as fábricas, onde tais lacunas são efetivamente críticas, pela própria natureza
do serviço ali realizado.
4.1.2 – Dados Sobre Origem da Formação Requerida
Os dados abaixo, sobre a origem da formacao requerida para atuar no modelo de

fábrica de software, indicam que ela não se encontra no ensino superior, especialmente no Rio
de Janeiro (fábrica A).
2.4 Origem da formação requerida Competências Subtot Competências Subtot Total
ER PLF IM TE BD DI Qtd % PL PF IM TE DC Qtd %
1 - Curso superior 2 0 3 8 0 0 13 22.0 0 0 1 0 1 2 6.1 15
2 - Repasse equipe 2 3 6 3 1 1 16 27.1 2 3 2 4 1 12 36.4 28
3 - Trein. custeio próprio 1 0 3 2 0 0 6 10.2 2 0 0 1 1 4 12.1 10
4 - Trein pago empresa atual 3 2 2 0 0 0 7 11.9 0 0 0 1 0 1 3.0 8
5 - Trein pago ex-empresa 1 1 1 0 0 1 4 6.8 0 0 0 0 0 0 0.0 4
6 - Auto-instrução 3 1 4 1 0 0 9 15.3 2 2 3 1 2 10 30.3 19
Em Branco 0 0 4 0 0 0 4 6.8 1 0 1 1 1 4 12.1 8
Totais 12 7 23 14 1 2 59 7 5 7 8 6 33 92
4.1.3 – Dados Sobre Percepção do Modelo Fabril
Conforme mostra a tabela 6 a seguir, na Fábrica B, 60,6% dos respondentes declara

conseguir visualizar por inteiro o produto que está sendo desenvolvido, enquanto na Fábrica
B, apenas 22% alcançam essa percepção.
69
Em ambas as fábricas, a percepção de repetitividade das tarefas está configurada na

tabela 7 abaixo, onde apenas 18,6% na Fábrica A e 15,2% não Fábrica B não consideram
repetitivas as tarefas que executam; contudo, essa repetitividade reconhecida permite
oportunidades de decidir e/ou criar. Sendo que as competências de Implementação das duas
Fábricas, e a competência de Testes da Fábrica B são as que mais se ressentem.
Nessas fábricas, os operários não se vêem obrigados a continuar atuando sempre na

mesma competência, conforme ilustra a tabela 8:
2.7 Possibilidade de atuar noutra Competências Subtot Competências Subtot Total
competência?
1 - Sim 2 4 10 8 1 1 26 44.1 4 3 3 0 1 11 33.3 37
2 - Não 3 1 6 2 0 0 12 20.3 1 0 1 1 1 4 12.1 16
3 - Não sei 7 2 7 4 0 1 21 35.6 2 2 3 7 3 17 51.5 38
Em Branco 0 0 0 0 0 0 0 0.0 0 0 0 0 1 1 3.0 1
Totais 12 7 23 14 1 2 59 7 5 7 8 6 33 92

70
Mediante o resultado apurado na tabela 9 abaixo, foi apurado, na competência Escopo

e Requisitos (ER) da Fábrica A, o motivo da percepção de baixa contribuição com o processo
produtivo: seus componentes consideram de pouca utilidade a tarefa de documentação do
legado que lhes foi designada, uma vez que observam que os documentos produzidos nem
sempre são consultados. Isto é, como o foco da pesquisa foi a atividade de desenvolvimento e
não de manutenção, esse dado configura um viés.
Em ambas as fábricas, os respondentes consideram positivo o impacto da

padronização de processos nas suas carreiras profissionais, conforme tabela 10:
3.1 Impacto da padronização de Competências Subtot Competências Subtot
Total
processos
1 - Positivo 10 4 12 13 1 0 40 67.8 7 5 6 4 4 26 78.8 66
2 - Negativo 0 3 4 0 0 1 8 13.6 0 0 1 4 0 5 15.2 13
3 - Não Impacta 2 0 2 0 0 1 5 8.5 0 0 0 0 1 1 3.0 6
4 - Não tem opiniao formada 0 0 5 1 0 0 6 10.2 0 0 0 0 0 0 0.0 6
Em Branco 0 0 0 0 0 0 0 0.0 0 0 0 0 1 1 3.0 1
Totais 12 7 23 14 1 2 59 7 5 7 8 6 33 92
Já com relação ao impacto causado na carreira pela divisão das equipes por
competência, enquanto na Fábrica B ninguém afirma ser negativo e 75,6% afirmam ser
positivo, na Fábrica A a visão é menos otimista: 27,1% afirmam ser negativo e apenas 50,8%
consideram tal impacto positivo (tabela 11, a seguir).
71
3.2 Impacto da divisao por Competências Subtot Competências Subtot
Total
competências
1 - Positivo 7 2 7 13 1 0 30 50.8 6 4 6 5 4 25 75.8 55
2 - Negativo 2 4 10 0 0 0 16 27.1 0 0 0 0 0 0 0.0 16
3 - Não Impacta 3 1 4 1 0 2 11 18.6 1 0 0 1 1 3 9.1 14
4 - Não tem opiniao formada 0 0 2 0 0 0 2 3.4 0 1 1 1 0 3 9.1 5
Em Branco 0 0 0 0 0 0 0 0.0 0 0 0 0 2 2 6.1 2
Totais 12 7 23 14 1 2 59 7 5 7 7 7 33 92
Quanto à realização profissional, o resultado também diverge nas duas fábricas, tendo sido
obtido na Fábrica B um resultado mais positivo (tabela 12).
Em ambas as fábricas, é significativo o percentual daqueles que não estão convictos de que
seu trabalho individual possa ter visibilidade (tabela 13):

72
4.1.4 – Dados Sobre Público Alvo
Conforme mostram as tabelas 14, 15 e 17 abaixo, dada a faixa etária mais alta do
público da Fábrica A, há mais tempo seus empregados estão formados, e muitos (28,8%)
formados noutra área que não TI.
A tabela 16 mostra a preponderância do publico masculino nas duas fábricas.
Competências Subtot Competências Subtot
Escolaridade Total
1 - Curso superior não iniciado 0 0 0 0 0 0 0 0.0 0 0 0 1 0 1 3.0 1
2 - Curso superior interrompido 1 0 1 1 0 1 4 6.8 0 1 1 1 1 4 12.1 8
3 - Cursando superior (área TI) 0 0 5 4 0 0 9 15.3 1 0 3 2 2 8 24.2 17
4 - Cursando superior (outra área) 0 0 0 2 0 1 3 5.1 0 0 0 2 0 2 6.1 5
5 - Superior concluído (área TI) 11 2 9 2 1 0 25 42.4 5 4 3 2 3 17 51.5 42
6 - Superior concluído (outra área) 0 5 8 4 0 0 17 28.8 1 0 0 0 0 1 3.0 18
Em Branco 0 0 0 1 0 0 1 1.7 0 0 0 0 0 0 0.0 1
Totais 12 7 23 14 1 2 59 7 5 7 8 6 33 92
Tabela 14: Resultado Tabulação Escolaridade Superior (fonte: própria)
Tempo Médio de Formado (anos)

Área Curso Superior Fábrica A Fábrica B
Desvio Desvio
Média Média
Padrão Padrão
Área de TI 8.96 7.15 8.06 4.99
Outras Áreas 19.56 7.41 16 0
Qualquer Área 12.9 9.98 8.53 5.2
Tabela 15: Resultado Tabulação Área Curso Superior (fonte: própria)
Competências Subtot Competências Subtot
Sexo Total
Feminino 7 2 6 6 0 0 21 35.6 3 1 0 6 1 11 33.3 32
Masculino 5 5 17 8 1 2 38 64.4 4 4 7 2 5 22 66.7 60
Totais 12 7 23 14 1 2 59 7 5 7 8 6 33 92
Tabela 16: Resultado Tabulação Sexo (fonte: própria)

73
Tabela 17: Resultado Tabulação Faixa Etária (fonte: própria)
Conforme demonstrado na tabela 18, embora os cargos e a progressão de faixas

salariais sejam os mesmos nas duas fábricas, a Fábrica A remunera maior percentual de
empregados na faixa mais alta por conta, principalmente, do tempo de experiência em TI e da
antiguidade deles na organização:
Tabela 18: Resultado Tabulação Faixa Salarial (fonte: própria)
Nas duas tabelas a seguir constam os dados sobre a experiência em TI do público da

pesquisa, sendo que o tempo especificamente trabalhado no modelo de fábrica de software
está retratado na tabela 20. É interessante observar que na Fábrica B, com experiência
superior a 5 anos no modelo fabril não existe ninguém, e nesse caso, na Fábrica A,
encontramos apenas 5,1%.
74
Tabela 19: Resultado Tabulação Tempo de Experiência em TI (fonte: própria)
Tabela 20: Resultado Tabulação Tempo de Experiência em Fábrica de Software (fonte: própria)
75
5 – Conclusões e Recomendações
Perseguindo o objetivo de produção em massa a baixo custo, verificamos que as

fábricas de software vêm se encaixando nos mesmos modelo e controles daquelas fordistas,
embora possuam características próprias (limitação da metáfora).
As ferramentas de controle adotadas nas duas fábricas assumem o papel de “capataz

virtual”, um substituto menos intrusivo que o supervisor do modelo fordista, porém mais
eficaz, dado que reúne as qualidades da imparcialidade, da permanente atividade sem repouso
e da não sujeição à falhas.
A especialização cobrada dos empregados, de modo que estejam adequados à

estruturação das equipes segundo o conceito de competências, e a repetitividade das tarefas
remetem ao modelo fordista. Assim como também, a presença inequívoca de uma esteira de
produção virtual, que percorre tais competências, e pela qual trafegam os produtos em
construção/manutenção reforçam a aderência a tal modelo.
Identificamos, portanto, sinais do ressurgimento do fordismo na indústria de TI

(Tecnologia da Informação), observados nas fábricas de software, principalmente naquelas
estruturadas em competências, em contraponto ao reconhecido movimento em curso de busca
pela flexibilização por parte das organizações (pós-fordismo).
Quanto à gestão do conhecimento, os resultados obtidos no item 4.1.1, favoráveis à

Fábrica B, apontam que estão dando resultado as medidas lá tomadas com o objetivo de
garantir uma documentação de melhor qualidade, que faça fluir melhor o conhecimento entre
as competências,
Todavia, foram também constatadas discrepâncias básicas entre uma linha de

produção fordista e a linha de produção de uma fábrica de software:
• Software é um produto único, em termos de objetivos, escopo e contexto; donde
não constitui objetivo dessas fábricas produzir, através da linha de produção, o
mesmo software em larga escala; por conseqüência, através de uma mesma esteira
(processo padrão) de produção da fábrica de software circulam produtos distintos;
76
• Por mais que o processo de desenvolvimento tenha sido automatizado e

decomposto em unidades menores, quanto mais inicial é o estágio da esteira de
produção da fábrica de software, maior a inteligência e a criatividade requerida
para sua execução; embora o processo executado seja o mesmo, não há repetição
do artefato que circula na esteira dado que cada software é um produto único,
inédito.
Também convém ressaltar as seguintes questões intrínsecas à natureza do processo

de desenvolvimento de software, que podem afetar o bom funcionamento dessa esteira de
produção, pois limitam os benefícios esperados:
• Em cada etapa, além do artefato produzido, um novo conhecimento que extrapola
esse artefato foi gerado e precisa ser transmitido às estações seguintes, sendo que
no modelo fordista trafegam pela esteira apenas artefatos; não é rara a necessidade
das equipes alocadas numa etapa interromperem as equipes alocadas nas etapas
anteriores, em busca desse conhecimento que se perdeu na esteira;
• Muitas vezes, só o conhecimento adquirido numa determinada etapa torna visíveis
defeitos do artefato que obrigam seu retorno às estações anteriores.
• Embora estejam formalmente definidas, nas descrições dos processos, as fronteiras
de cada etapa de produção, na prática não é viável verificar se elas foram
efetivamente alcançadas/ultrapassadas ou não, apesar de ter sido gerado o artefato
previsto. Isso porque, além da forma (facilmente verificável), o artefato produzido
em cada etapa sempre embute um conhecimento imprescindível para a execução
da próxima etapa Porém, a completeza desse conhecimento não é objetivamente
mensurável; e mesmo que esteja completo, se não foi precisamente registrado
(especificação superficial, incompleta, e/ou inconsistente) vai comprometer a
qualidade da fase seguinte;
• O produto de cada etapa da linha de montagem (competências) não apenas desliza
na esteira para ser complementado na próxima etapa. Muitas vezes esse produto é
a especificação da próxima etapa a ser executada ou no mínimo precisa conter
informações determinantes dessa execução;
• Quanto mais o executor de uma etapa conhece sobre o produto que está sendo
construído e não apenas sobre o processo que lhe compete, mais ele pode validar o
77
que recebeu como insumo e, mais ainda, com mais eficácia ele vai executar a sua
parte;
• Para a execução da sua tarefa, além das especificações que foram geradas na etapa
anterior, é necessário que o executante recorra a um “banco de conhecimentos”
dinâmico, compartilhado e atualizado por todos os “operários da esteira”;
• As tarefas de uma fábrica de software embora repetitivas, também embutem
processos eminentemente criativos, sendo que muitas delas exigem inclusive
discussões para determinação da solução a ser adotada em cada caso específico;
• Os controles adotados exigem a disponibilidade de uma parafernália de sistemas
informatizados de apoio à produção, bem como exigem a colaboração do próprio
executante.
• Pelas freqüentes alterações de regras e escopo determinadas por mudanças que vão
ocorrendo no ambiente do cliente em paralelo ao desenvolvimento do software,
não raras vezes o artefato precisa voltar a etapas anteriores da linha de montagem,
quebrando o ciclo previsto e interferindo na cadência dessa linha.
Dessa forma, tendo observado o funcionamento das duas fábricas e analisado os dados
obtidos, podemos estabelecer comparações e apontar os limites da metáfora esteira de
produção:
• Enquanto na esteira fordista a fronteira de cada etapa de produção é bem definida,
e se dispõe de especificações claras e precisas do procedimento a adotar e das
configurações da peça recebida e da peça repassada, numa fábrica de software a
subjetividade das especificações impacta o ritmo da esteira e a conformação da
peça repassada. Isso se deve à intangibilidade do produto durante a maior parte do
seu percurso na esteira, estando ele, como agravante, sujeito a mudanças e a
circunstâncias inesperadas durante sua fabricação.
• Se no modelo fordista, quem trafegava na esteira era apenas a peça em produção,
que ia sendo acrescida ou modificada segundo um processo pré-definido,
repetitivo, que não variava de peça para peça e era executado individualmente por
cada empregado, nessas fábricas de software as peças trafegam junto com
conhecimento e não guardam similaridade entre si. Isto é, embora o processo se
repita em termos de procedimentos, cada par (peça, conhecimento) que trafega é
distinto, o que já confere singularidade a cada tarefa executada.
78
• Para o empregado de uma fábrica fordista executar sua tarefa, além da requerida
habilidade, bastava ao operário conhecer bem as técnicas e ferramentas que lhe
cabiam utilizar, não lhe sendo exigido conhecer sobre o produto para o qual a peça
que estava sendo fabricada, muito menos conhecer sobre o contexto da utilização
daquele produto. Já nessas fábricas de software, todo o conhecimento sobre o
produto que surge em cada etapa da fabricação precisa ser identificado, registrado
e transmitido às etapas seguintes, e também necessita ser internalizado pelos
empregados.
• Nas fábricas fordistas, cada empregado precisava conhecer muito bem o seu papel
no processo, mas apenas o seu papel. Já no caso das fábricas de software, quanto
mais uma equipe conhecer das etapas posteriores, mais e melhor vai explicitar esse
conhecimento dado que terá a sensibilidade de discernir o que é relevante e útil.
Isso por ser alto o grau de subjetividade da descrição de cada processo, e a sua
perfeita execução depender bastante dos conhecimentos, habilidades, atitudes e
experiência do executor.
• No modelo fordista, além de seguir o procedimento pré-estabelecido, não cabia a
um empregado repassar qualquer conhecimento adquirido durante a execução da
sua tarefa para o próximo executante. Ao passo que nessas fábricas de software,
verificamos que o conhecimento gerado numa etapa é insumo para etapa seguinte,
donde trafegam por essas esteiras tanto a peça (artefato) como o conhecimento.
• Os controles da produção da esteira fordista eram objetivos e focados na execução
do processo: cronometragem do tempo de execução, métricas de produtividade
individuais (metas), e verificação da aderência a padrões de qualidade adotados. Já
nessas fábricas de software, onde em que pese tais controles sejam eminentemente
automáticos e virtuais, a posterior análise dos indicadores obtidos encerra a
subjetividade decorrente da intangibilidade do produto.
• A esteira da linha de montagem fordista corria em mão única, isto é, não estavam
previstos, via a mesma esteira, retornos da peça à etapa anterior para
complementação de algum processo inacabado ou defeituoso. Porém considerando
que um software deve ser aderente ao mundo real que sofre constantes mudanças,
a concepção desse produto está sujeita às mesmas mudanças, ainda em tempo de
desenvolvimento, daí a necessidade da mão dupla para retorno do artefato. Como
agravante, pela sua intangibilidade do produto, muitos defeitos produzidos em
79
etapas iniciais frequentemente só se manifestam posteriormente, posto que a

subjetividade das especificações mascara sua possível incompleteza. Assim sendo,
na esteira de uma fábrica de software, os retornos não podem ser tratados como
exceção.
Em contrapartida, inequívocos sinais de flexibilidade aplicada ao sistema produtivo

foram também verificados em ambas as fábricas de software, uma vez que sem exigir
mudanças físicas nesse sistema mostram-se capazes de:
• Produzir elementos diferentes, muitas vezes até simultaneamente, através da
mesma esteira;
• Aceitar mudanças ou melhoramentos do produto durante o processo produtivo;
• Presta-se à produção de versões ou variantes diversas em proporções diferentes.
Concluímos que tais fábricas, inicialmente concebidas para tirar o máximo proveito
das vantagens oferecidas pelo modelo fordista, produção em massa a baixo custo, na prática
precisam ser flexíveis pelo menos o suficiente para tolerar inconvenientes sem interromper
completamente a produção. Cabe lembrar que numa linha rígida de produção fordista bastava
o bloqueio de uma estação para parar toda a produção.
Tal flexibilidade, além de garantir o fluxo da produção quando ocorrem falhas ou

imprevistos, também acaba permitindo um trabalho menos vinculado a ritmos rígidos e
repetitivos, e dá lugar à necessária criatividade.
Reforçando a caracterização da flexibilidade identificada, a supervisão automática

praticada nas fábricas de software libera o supervisor para desempenhar as funções de
determinar as estratégias produtivas, planificar o uso de recursos, prever demandas e/ou
pedidos. Concorre também para configurar um sistema produtivo flexível, a presença da
automação de escritório racionalizando a comunicação e a transmissão de informações.
A exemplo de outros trabalhos de pesquisa que não se esgotam em si mesmo, surgiram

algumas questões ao longo desse trabalho que mereceriam ser aprofundadas, porém as lacunas
geradas não puderam ser respondidas no universo dessa pesquisa.
80
Assim sendo, deixamos algumas sugestões de pesquisas futuras que complementem ou

dêem continuidade ao presente estudo:
• Seria bastante enriquecedor explorar o ambiente das duas fábricas daqui a um ou

dois anos, quando na Fábrica A o conhecimento dos sistemas em manutenção
estaria registrado, e na Fábrica B os resultados alcançados com o novo processo de
desenvolvimento poderiam ser mensurados;
• Considerando que nas duas fábricas é baixo o percentual de empregados que
reconhece na formação superior a fonte de conhecimentos para atuar no modelo
fabril de desenvolvimento de software, seria interessante pesquisar o nível de
aderência dos diversos currículos universitários do país ao modelo fabril de
desenvolvimento de software, bem como caracterizar a fonte desse ensino que vem
provendo tal mercado;
• Uma vez verificada a complexidade dos controles para mensuração de
produtividade, cumprimento de prazos e de satisfação dos clientes, surge a
questão: quanto do tempo dos executores é consumido por tais controles?
81
ANEXO I
(Questionário Aplicado na Fábrica A)

82
1 - Marque com X as competências onde atuou nos últimos 12 meses, sublinhando aquela em que atuou
com maior freqüência:
Requisitos/Escopo
Projeto Lógico e Físico
Implementação
Testes
Disponibilização
2 - Responda às questões abaixo tomando como base seu trabalho na competência sublinhada acima:
2.1 - Durante o processo de desenvolvimento, em cada uma das competências surgem conhecimentos
relativos ao negócio do cliente e ao produto (software). Na sua avaliação, o quanto desse
conhecimento, que surge nessa competência que você mais atua, fica retido na memória dos técnicos,
isto é, não chega a ser documentado?
Tudo é formalizado nos mínimos detalhes, tanto os motivos de cada solução adotada como o
porquê de não terem sido adotadas as demais alternativas cogitadas.
As soluções adotadas são formalizadas nos mínimos detalhes.
Até 10% do conhecimento gerado nessa fase fica restrito à memória da equipe.
Mais de 50% do conhecimento gerado nessa fase fica restrito à memória da equipe.
2.2 - Esse cohecimento que de modo geral não fica documentado é explicitado, de forma ordenada, na
passagem de serviço para as outras competências?
Sempre
É previsto porém, na prática, nem sempre acontece
Às vezes
Nunca
2.3 - Na sua avaliação, o quanto do conhecimento necessário para execução de suas tarefas está disponível
na documentação/artefatos que sua equipe recebeu da fase anterior?
Atuo principalmente na competência Requisitos/Escopo, etapa inicial do processo.
Tudo está sempre disponível no material que recebemos.
Raramente preciso perguntar alguma coisa aos colegas responsáveis pela fase anterior
Frequentemente preciso esclarecer dúvidas com os colegas da fase anterior, mas isso não
prejudica meu ritmo de trabalho.
Meu ritmo de trabalho é impactado pelas interrupções para recuperar informações .
2.4 - Como você adquiriu a formação requerida (conhecimento das ferramentas e processos utilizados)
para atuar nessa competência? Marque apenas uma opção, aquela que mais contribuiu.
Durante o curso superior.
Por meio de repasse de conhecimentos pela equipe de trabalho.
Treinamentos formais custeados com seus recursos.
Treinamentos formais custeados pela empresa em que está trabalhando.
Treinamentos formais custeados pela(s) empresa(s) anterior(es).
Aprendizado (auto-instrução).
83
2.5 – Atuando nessa competência, você:

Visualiza por inteiro o produto que está sendo construído, tanto lógica como fisicamente.
Visualiza por inteiro o produto que está sendo construído, porém apenas logicamente.
Visualiza por inteiro o produto que está sendo construído, porém apenas fisicamente.
Consegue visualizar apenas parcialmente o produto que está sendo desenvolvido.
Não consegue visualizar o produto.
2.6 – Atuando nessa competência, suas atividades:

São repetitivas, sem possibilidade de decisão e/ou criação.
São repetitivas, porém existem oportunidades de decidir e/ou criar.
São repetitivas, porém com muitas oportunidades de decidir e/ou criar.
Não são repetitivas.
2.7 - Existe a possibilidade de você, a curto ou médio prazo, atuar noutra(s) competência(s)?
Sim
Não
Não sei
2.8 – Atuando nessa competência, você tem a clara percepção do quanto seu trabalho contribui para o
produto final?
Sim, e percebo que contribui muito.
Sim, e percebo que contribui.
Sim, mas percebo que contribui pouco.
Sim, mas percebo que não contribui.
Não percebo se contribui.
3 - Agora pensando apenas em você perante o mercado, considerando a possibilidade de uma futura
recolocação, responda às seguintes perguntas:
3.1 - Como a padronização do processo de desenvolvimento de “software” impacta o seu desenvolvimento
profissional?
Positivamente
Negativamente
Não impacta
Não tenho opinião formada.
3.2 - Como a divisão das equipes por competências impacta o seu desenvolvimento profissional?
Positivamente
Negativamente
Não impacta
4 – Você se sente realizado profissionalmente, trabalhando no modelo de fábrica de software?

Sim
Não
Parcialmente
84
5 – Trabalhando no modelo de fábrica de software, você acha que seu trabalho individual tem visibilidade,
isto é você pode se destacar na sua equipe?
Sim
Provavelmente
Dificilmente
Não
Escolaridade Superior:
Curso superior não iniciado
Curso superior interrompido
Cursando nível superior (área de TI)
Cursando nível superior (outra área)
Curso superior concluído (área de TI), formado há ..... ano(s)
Curso superior concluído (outra área) , formado há ..... ano(s)
Se estiver cursando/concluiu o Mestrado, informe o Curso: -----------------------------------------
Sexo: Feminino Masculino
Faixa Etária: Faixa Salarial:

Até 25 anos Até Até 1.200,00 reais
De 26 a 30 anos De 1.200,01 a 2.500,00 reais
De 51 a 60 anos Mais de 7.000,01 reais
Mais de 60 anos
Tempo de experiência em TI (desenvolviment e manutenção de sistemas):

menos de 1 ano
de 1 a 3 anos (inclusive)
mais de 20 anos
Tempo de experiência em Fábrica de Software:

menos de 1 ano
mais de 5 anos
85
ANEXO II
(Questionário Aplicado na Fábrica B)

86
1 - Marque com X as competências onde atuou nos últimos 12 meses, sublinhando aquela em que atuou
com maior freqüência:
F1 - Projeto Lógico (requisitos, casos de uso, prototipação de telas )
F2 - Projeto Físico (arquitetura do software – componentes, páginas e rotinas de comunicação com
as bases de dados; especificação de programas)
F3 - Implementação (programação)
Testes
Banco de Dados, Gerência de Configuração/Ambiente (modelagem lógica e física, dicionário de
dados)
2 - Responda às questões abaixo, tomando como base seu trabalho na competência sublinhada acima:
2.1 - Durante o processo de desenvolvimento, em cada uma das competências surge um conhecimento
relativo ao produto (software). Na sua avaliação, o quanto do conhecimento que surge nessa
competência fica retido na memória dos técnicos, isto é, não chega a ser documentado?
Tudo é formalizado nos mínimos detalhes, tanto os motivos de cada solução adotada como o
porquê de não terem sido adotadas as demais alternativas cogitadas.
As soluções adotadas são formalizadas nos mínimos detalhes.
Mais de 50% do conhecimento gerado nessa fase fica restrito à memória da equipe.
2.2 - Essas informações que de modo geral não ficam documentadas, são repassadas de forma ordenada
durante a passagem de serviço para as outras competências?
Sempre
É previsto porém, na prática, nem sempre acontece
Às vezes
Nunca
2.3 - Na sua avaliação, o quanto do conhecimento necessário para de suas tarefas está disponível na
documentação/artefatos que sua equipe recebeu da fase anterior?
A pergunta não se aplica, porque atuo principalmente na competência Projeto Lógico, etapa
inicial do processo.
Tudo está sempre disponível.
Raramente preciso perguntar alguma coisa aos colegas responsáveis pela fase anterior
Frequentemente preciso esclarecer pequenas dúvidas com os colegas da fase anterior.
Meu ritmo de trabalho é impactado pelo volume de informações que não estão documentadas.
2.4 - Como você adquiriu a formação requerida (conhecimento das ferramentas e processos utilizados)
para atuar nela? Marque apenas uma opção, aquela que mais contribuiu.
Durante o curso superior.
Por meio de repasse de conhecimentos pela equipe de trabalho.
Treinamentos formais custeados com seus recursos.
Treinamentos formais custeados pela empresa em que está trabalhando.
Treinamentos formais custeados pela(s) empresa(s) anterior(es)
Aprendizado (auto-instrução)
87
2.5 – Atuando nessa competência, você:

Visualiza por inteiro o produto que está sendo construído, tanto lógica como fisicamente.
Visualiza por inteiro o produto que está sendo construído, porém apenas logicamente.
Visualiza por inteiro o produto que está sendo construído, porém apenas fisicamente.
Consegue visualizar apenas parcialmente o produto que está sendo desenvolvido.
Não consegue visualizar o produto.
2.6 – Atuando nessa competência, suas atividades:

São repetitivas, sem possibilidade de decisão e/ou criação.
São repetitivas, porém existem oportunidades de decidir e/ou criar.
São repetitivas, porém com muitas oportunidades de decidir e/ou criar.
Não são repetitivas.
2.7 - Existe a possibilidade de você, a curto ou médio prazo, atuar noutra(s) competência(s)?
Sim
Não
Não sei
2.8 – Atuando nessa competência, você tem a clara percepção do quanto seu trabalho contribui para o
produto final?
Sim, e percebo que contribui muito.
Sim, e percebo que contribui.
Sim, mas percebo que contribui pouco.
Sim, mas percebo que não contribui.
Não percebo se contribui.
3 - Agora pensando apenas em você perante o mercado, considerando a possibilidade de uma futura
recolocação, responda às seguintes perguntas:
3.1 - Como a padronização do processo de desenvolvimento de “software” impacta o seu desenvolvimento
profissional?
Positivamente
Negativamente
Não impacta.
3.2 - Como a divisão das equipes por competências impacta o seu desenvolvimento profissional?
Positivamente
Negativamente
Não impacta
4 – Você se sente realizado profissionalmente, trabalhando no modelo de fábrica de software?
Sim
Não
Parcialmente
88
5 – Trabalhando no modelo de fábrica de software, você acha que seu trabalho individual tem visibilidade,
isto é você pode se destacar na sua equipe?
Sim
Provavelmente
Dificilmente
Não
Escolaridade Superior:
Curso superior não iniciado
Curso superior interrompido
Cursando nível superior (área de TI)
Cursando nível superior (outra área)
Curso superior concluído (área de TI), formado há ..... ano(s)
Curso superior concluído (outra área) , formado há ..... ano(s)
Se estiver cursando/concluiu o Mestrado, informe o Curso: -----------------------------------------
Sexo: Feminino Masculino
Faixa Etária: Faixa Salarial:

Até 25 anos Até Até 1.200,00 reais
De 51 a 60 anos Mais de 7.000,01 reais
Mais de 60 anos
Tempo de experiência em TI (desenvolvimento e manutenção de sistemas):

menos de 1 ano
mais de 20 anos
Tempo de experiência em Fábrica de Software:

menos de 1 ano
mais de 5 anos
89
ANEXO III
(Roteiro das Entrevistas)

90
Fábrica:
Entrevistados (Nome e Cargo):
1) Mapeando a Fábrica:
• Tipo de Fábrica (Programas, Projeto Físico, Projetos de Software ou Ampliada)?
• Desenvolvimento e Manutenção de Software correm pela mesma esteira de

produção ou por esteiras separadas?
• A fábrica atende a demandas/projetos distintos? E a plataformas de

desenvolvimento distintas?
• Passou a funcionar em:
• Histórico de evolução dos processos:
• A equipe técnica da fábrica está dividida em que competências? Quantos

funcionários em cada competência?
• Todas as competências trabalham no mesmo local?
• Qual o perfil técnico/habilidades requeridos do funcionário em cada competência?
• As competências estão subdivididas por célula de conhecimento ou plataforma?
• Em cada competência, a delegação de serviços atende à fila ou segue algum

critério de conhecimento prévio exigido?
• Que conjunto de artefatos uma competência passa para a seguinte?
• Mais de uma competência mantém contato com o usuário final?
• Quais os principais problemas da fábrica hoje?

91
2) Conhecimento :
• Toda a documentação produzida é plenamente utilizada nos processos?
• Essa documentação é suficiente para abastecer os processos ou parte do

conhecimento do negócio ou dos processos reside nas pessoas?
• Além da disponibilização dos artefatos, na transição de serviço entre as

competências, é praticado algum “rito de passagem” formal? Por que?
3) Gestão de Pessoal:
• Os serviços são distribuídos “em fila” ou existe algum mecanismo de controle que
permita, no momento da delegação de cada tarefa, verificar as habilidades de cada
técnico para direcionar a passagem do serviço?
• Qual o % médio de rotatividade mensal? Quais as principais causas? Tem impacto

negativo?
• Na gestão de pessoal, quais os principais conflitos a administrar?
4) Ferramentas de Supervisão e Planejamento:
• Quais as ferramentas de planejamento utilizadas?
• No caso das fábricas de múltiplas demandas, como são conciliados os

planejamentos de cada competência?
• Quais as ferramentas de Supervisão utilizadas (disponibilidade dos recursos,

delegação de tarefas originais e de retrabalho, acompanhamento de prazos)
5) Indicadores:
• Produtividade (coleta, mensuração, histórico, ações)?
• Cumprimento de prazos (coleta, mensuração, histórico, ações)?
• Satisfação do cliente (coleta, mensuração, histórico, ações)?

92
Bibliografia
BALDUINO, R. Implementação de um Processo de Desenvolvimento de Software: Uma

Abordagem Passo-a-Passo. Rational Software White Paper: 2002
BASILI, V. R. Facts and Myths affecting Software Reuse, Maryland, IEEE:1994
BECK, K. Extreme Programming Explained, Addison-Wesley: .2000
BIANCHI, S. e SACERDOTI, B. A Fábrica Automática e a Organização do Trabalho.

Petrópolis: Vozes, 1985
BRITO, J. A. J. Metodologia para Gestão do Processo de Qualidade de Software para

Incremento da Competitividade da Mobile, http://www.mct.gov.br/
CESAR, R. Fábrica de Software: Uma vocação nacional?,

http://www.siscorp.com.br/imprensa/computerworld02.htm?documento=24655&Area=51,
(2004)
CÔRTES, M. R. Notas de aula da disciplina Organização do Trabalho. DEP/UFSCar
CURRAS, E. Tesaurus – Linguagens Terminológicas; tradução de Antonio Felipe Corrêa

da Costa. Brasília: CNPQ IBICT, 1995
CUSUMANO, M A (1989). The Software Factory: A Historical Interpretation. IEEE

Software, 6(2), p 23-30, Cap. 14
DURAND, C. Le Travail Enchaîné. Paris: Seuil, 1978
FERNANDES, A.A.e TEIXEIRA, D. S. Fábrica de Software: Implantação e Gestão de

Operações. São Paulo: Atlas, 2004
FORD MOTOR COMPANY. History

http://www.ford.com/en/heritage/history/default.htm?source=rt&referrer=company_default
FRANCINI, Willian Sampaio. A Gestão do Conhecimento – Uma Análise Através de

Estudo de Caso. FGV-ESAESP, 2003
FOWLER, M. Using a Agile Software Process with Offshore Development.

http://www.martinfowler.com/articles/agileOffshore.html, Abril de 2004.
GOUNET, Thomas. Fordismo e Toyotismo. São Paulo, recursos humanos e qualidade

como fatores críticos de sucesso nas empresas de software: uma modelo transacional.
São Paulo: FGV-ESAESP, 2004
GREENFIELD, Jack and SHORT, Keith. Software Factories: Assembling Applications

with Patterns, Models, Frameworks and Tools. Indianapolis, IN: Wiley Publishing, Inc,
2004
93
HUMPHREY, W. Managing the Software Process. Reading, Mass.: Addison-Wesley, 1989

JEFFRIES R. What is Extreme Programming?
www.xprogramming.com/xpmag/whatis.html, 2001
KRIPALANI, M. Engardio P. e HAMM, S. The Rise of India,

www.businessweek.com/magazine/content/03_49/b3861001_mz001.html, Business Week
Online: 2003.
KRUTCHEN, P. Introdução ao RUP – Rational Unified Process, Rio de Janeiro: Editora

Ciência Moderna Ltda, 2003
LEBORGNE, D. e LIPIETZ, A. O Pós-Fordismo e seu Espaço. Espaço & Debates: 1988
LONCHAMP J.. A Structured Conceptual and Terminological Framework for the

Software Process Engineering. International Conference on the Software Process. Berlim:
Proceedings, 1993
MALAMUT, Gilberto. Dissertação “A Flexibilização Organizacional Através de Sistemas

Integrados de Gestão no Setor de Serviços”, Rio de Janeiro: FGV, 2002
MARTINS, Gilberto de Andrade. Manual para Elaboração de Monografias e

Dissertações. 2.ed. São Paulo: Atlas, 2000.
MEDEIROS, Viviane et alli. Construindo Uma Fábrica de Software: da Concepção às

Lições Aprendidas. XXX Latin American Center of Studies in Computer Science (CLEI),
Arequipe: 2004
MOLLERSTRAND, Riccardo Jorgen. Gestão do Conhecimento. São Paulo: FGV-ESAESP,

2003
MORGAN, G. Paradigmas, Metáforas e Resolução de Quebra-Cabeças na Teoria das

Organizações. In: RAE-Clássicos, v. 45, n. 1, Jan./Mar. 2005
NATALI, A. C. C., FALHO, R. A. Gestão do Conhecimento em ODE. Departamento de

Informática, Universidade Federal do Espírito Santo: 2003
O’LEARY D. E., STUDER, R. Knowledge Management: An Interdisciplinary Approach.

IEEE Intelligent Systems, v.17, n. 1, Jan./Fev. 2001
PFLEEGER, S. L. Software Engineering: Theory and Practice. Upper Saddle River, New
Jersey: Prentice-Hall, 2001.
PRESSMAN, R. S. Software Engineering: A Practioner’s Approach. MacGraw-Hill

International Edition, 2000
PRESSMAN, R. S. Engenharia de Software. São Paulo: Makron Books, 2002.
ROCHA, A. R. C. et al . Qualidade de Software: Teoria e Prática. São Paulo: Prentice

Hall, 2001
94
ROCHA, Thayssa Águila et al. Adequação de Processos Para Fábrica de Software.

www.simpro.com.br São Paulo, 2005
SILVA. Elizabeth Bortolaia Silva. Refazendo a Fábrica Fordista – Contratastes da

Indústria Automobilística no Brasil e na Grã-Bretanha. São Paulo: Ed. HUCITEC, 1991
SANCHEZ, Antonio Carlos. Os impactos das novas tecnologias na indústria de software.

São Paulo: FGV-ESAESP, 2001
SOUZA, H. P. Metáforas do Cotidiano: A Política como Ato de Guerra. In:

Nunciopolítica, Ano 1, n.1, 2004
-----------------------As Metáforas na Linguagem e no Pensamento. In: Tablado

Acadêmico, Ano 1, n. 4, 2003
SPÍNDOLA, B. et all. Definição e Melhoria de Processo de Software em uma Fábrica de

Software Livre. VI Simpósio Internacional de Melhoria de Processo de Software. São Paulo:
2004
TAYLOR, F. W. Princípios de Administração Científica; tradução de Arlindo Vieira

Ramos. São Paulo: Atlas, 1990
TEIXEIRA, Jayme. Gerenciando o Conhecimento. Rio de Janeiro: Ed. SENAC, 2000
TENÓRIO, F. Flexibilização Organizacional – Mito ou Realidade?. Rio de Janeiro: FGV,

2000
TIGRE, P. B. Paradigmas Tecnológicos. In: Revista Estudos em Comércio Exterior v. 1,

n. 2, jan./jun. 1997
VERGARA, Sylvia Constant. Métodos de Pesquisa em Administração. São Paulo: Atlas,

2005
VIEIRA, Marcelo Milano Falcão; ZOUAIN, Débora Moraes. Pesquisa Qualitativa em

Administração. Rio de Janeiro: Editora FGV, 2005
VILELA. K. et al. Melhoria de Processos de Software e Evolução de Ambientes de

Desenvolvimento de Software com Base no Conhecimento do Domínio e na Cultura
Organizacional. Simpósio Brasileiro de Qualidade de Software, Gramado, Brasil: Outubro de
2002
WARNIER, Jean-Dominique. Computers and Human Intelligence. Englewood, USA:

Prentice-Hall, 1986
YIN, R. K. Estudo de Caso: Planejamento e Métodos. Tradução: Daniel Grassi. Porto

Alegre: Bookman, 2001
ZAHRAN, S. Software Process Improvement: Practical Guidelines for Business Success.

Harlow, Inglaterra: Addison-Wesley, 1998.

Fábrica de Software: Até Que Ponto Fordista?

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Fábrica de Software: Até Que Ponto Fordista?

Enviado por

Direitos autorais:

Formatos disponíveis

Fundação Getulio Vargas

Escola Brasileira de Administração Pública e de Empresas

CRISTINA DEORSOLA XAVIER

FÁBRICA DE SOFTWARE: ATÉ QUE PONTO FORDISTA?

Aos meus pais, que desde sempre incentivaram e apoiaram

À minha filha Luísa, sempre compreensiva e colaborativa

Ao Adymar, companheiro de todas as horas, fonte de inspiração

A Ele, por me proporcionar a oportunidade e as condições de

Ao Professor Doutor Tenório, pela orientação tão enriquecedora

A todos os professores do curso de mestrado em gestão

Aos colegas do mestrado, pelo companheirismo, apoio e

A alternância de características de rigidez e flexibilidade dos modelos de gestão dessas

Palavras-chave: fábrica de software; fordismo; flexibilização; metáfora; gestão do

Key Words: software factory, fordism, flexibility, metaphor, knowledge management

LISTA DE ABREVIATURAS E TERMOS

ASD Adaptative Software Development – Desenvolvimento de Software

FIGURA 1 Evolução do Desenvolvimento do Software ------------------------ 14

TABELA 1 Resultado Tabulação Questão 1 -------------------------------------- 58

4 Apresentação dos Dados -------------------------------------------------------- 62

4.1.4 Dados Sobre Público Alvo -------------------------------------------------------- 72

5 Conclusões e Recomendações --------------------------------------------------- 75

Anexo I - Questionário Aplicado na Fábrica A ------------------------------------------- 81

Com a crise da automação rígida (década de 60), têm sido paulatinamente

Para Cusumano (1989), um processo fabril produz em massa, através de operações

A associação metafórica dos termos fábrica e esteira de produção a desenvolvimento

A alternância de características de rigidez e flexibilidade dos modelos de gestão dessas

e não na sua implementação. A manufatura de software envolve pouca ou nenhuma produção

Para melhor contextualizar o estágio da indústria de TI - Tecnologia da informação,

Quando surgiram os computadores e a Informática, a maioria da mão-de-obra alocada

Analistas de sistemas2 e programadores3 eram vistos como “seres iluminados”,

Gradativamente, as metodologias de programação e modelagem de sistemas foram

Conforme descrito por Jean-Dominique Warnier (1986), a especificação do programa

Ainda no campo das técnicas aplicadas a desenvolvimento de software, a metodologia

Evolução do Desenvolvimento de Software

Figura 1 - Evolução do Desenvolvimento do Software (Fernandes, 2004: p. 23)

As iniciativas de organização do modelo fabril baseado nos preceitos do taylorismo e

Com a crescente disseminação das práticas de Gestão de Qualidade Total (Total

Com o crescimento e amadurecimento das Fábricas de Software da Índia (Kripalani,

O desafio que a engenharia de software vem enfrentando desde os primórdios

Entre processos, ferramentas e organizações alternativas, a literatura consolida

Estudos demonstram que a busca da produtividade restringe a flexibilidade e vice-

Figura 2 – Gráfico Produtividade x Flexibilidade

E especificamente na produção de software onde, por mais que tenham sido

O presente trabalho versa sobre o modelo fordista de produção aplicado a

Constitui o objetivo geral desse trabalho verificar como as fábricas de software, ao

Como objetivos específicos, podemos elencar:

No cenário contraditório das fábricas de software, onde a natureza do produto é

desenvolvimento e manutenção de software, cujas tarefas, não raro, exigem criatividade e

Como especificamente uma das fábricas estudadas encontra-se em fase de

Em sendo o ser humano um indivíduo social, vivendo em comunidades e

A metáfora, figura de linguagem semântica, estudada normalmente como uma

instâncias da enunciação, o entendimento da metáfora sob o prisma da teoria

A discussão acerca dos limites do sentido metafórico na linguagem é recorrente nos

A metáfora é um fenômeno natural da comunicação diária, seja oral ou escrita (e até

excelência, dado que a todo momento operamos transferência de idéias de um domínio

. Observamos, na definição a seguir, a adoção no sentido metafórico explícito do termo

Na obra de Adam Smith, final do século XVIII, encontram-se as origens do sistema de

Frederick Winslow Taylor (1856-1915), o “Pai da Organização Científica do

(Taylor: 1971. p.34)

Taylor selecionava e estudava grupos experimentais de trabalhadores particularmente

A Administração Científica, em sua essência, consiste e, certa filosofia que resulta em

As idéias de Taylor foram desenvolvidas e aplicadas em diferentes indústrias ao longo

Ninguém simboliza tanto a produção em massa como Henry Ford (1863-1947),