• Nenhum resultado encontrado

Fábrica de software: até que ponto fordista?

N/A
N/A
Protected

Academic year: 2017

Share "Fábrica de software: até que ponto fordista?"

Copied!
94
0
0

Texto

(1)

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

(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.

(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.

(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.

(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.

(6)

LISTADEABREVIATURASETERMOS

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)

(7)

LISTADEILUSTRAÇÕ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

(8)

LISTADETABELAS

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

TABELA 2 Resultado Tabulação Questão 2.1 --- 66

TABELA 3 Resultado Tabulação Questão 2.2 --- 67

TABELA 4 Resultado Tabulação Questão 2.3 --- 68

TABELA 5 Resultado Tabulação Questão 2.4 --- 68

TABELA 6 Resultado Tabulação Questão 2.5 --- 69

TABELA 7 Resultado Tabulação Questão 2.6 --- 69

TABELA 8 Resultado Tabulação Questão 2.7 --- 69

TABELA 9 Resultado Tabulação Questão 2.8 --- 70

TABELA 10 Resultado Tabulação Questão 3.1 --- 70

TABELA 11 Resultado Tabulação Questão 3.2 --- 71

TABELA 12 Resultado Tabulação Questão 4 --- 71

TABELA 13 Resultado Tabulação Questão 5 --- 71

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

(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

(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

(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.

(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)

(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).

(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:

1960-1970 1970-1980 1980-1990 1990-2000 Século XXI

Operações Artesanal Artesanal Fábrica Sw

Fábrica Sw Integrated Outsourcing

SPL

Processos CMM PMI, ASAP,

RUP, ISO

XP, ASD, LD

Plataformas Fortran,

Assembler Cobol, PL1

Natural, C, C++, Clipper VB, Delphi, Oracle JAVA, .NET, XML

Metodologias Waterfall Estruturada, Essencial Estruturada, Essencial OO, UML, Componentes ? Processos Proprietários

Evolução do Desenvolvimento de Software

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).

(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.

(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

(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.

(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):

(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.

(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.

(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.

(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

(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.

(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.

(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;

(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.

(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.

(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).

(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.

(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:

(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

(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)

(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.

(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).

(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.

(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:

Fábrica de Projetos de Software

Fábrica de Projetos Físicos

Teste Integrado

Teste de Aceitação

Fábrica de Programas

Projeto Conceitual

Especificação Lógica

Projeto

Detalhado Construção e Teste Unitário

Projeto Execuçã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

(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.

(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).

(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).

(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);

(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.

(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):

(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.

(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

Imagem

Figura 1 - Evolução do Desenvolvimento do Software (Fernandes, 2004: p.  23)
Figura 2 – Gráfico Produtividade x Flexibilidade
Figura 3: Fotografia 1 da Ambientação da Fábrica (fonte: própria)
Figura 4: Fotografia 2 da Ambientação da Fábrica (fonte: própria)
+7

Referências

Documentos relacionados

Controlador de alto nível (por ex.: PLC) Cabo da válvula Tubo de alimentação do ar de 4 mm Pr essão do fluido Regulador de pressão de precisão Regulador de pressão de

Da mesma forma que o fotógrafo domina o aparelho fotográfico sem entender por completo o que se passa dentro da caixa, o jogador também se relaciona com o jogo sem visualizar

Os estudos também indicam haver variação da espessura do músculo masseter entre os indivíduos, tanto durante o repouso quanto nas atividades de contração..

O candidato e seu responsável legalmente investido (no caso de candidato menor de 18 (dezoito) anos não emancipado), são os ÚNICOS responsáveis pelo correto

A espectrofotometria é uma técnica quantitativa e qualitativa, a qual se A espectrofotometria é uma técnica quantitativa e qualitativa, a qual se baseia no fato de que uma

Entrando para a segunda me- tade do encontro com outra di- nâmica, a equipa de Eugénio Bartolomeu mostrou-se mais consistente nas saídas para o contra-ataque, fazendo alguns golos

Embora isso seja mais do que sabido, ainda falta compreensão clara de como tal resistência vem de fato bloqueando a formação da maioria requerida para aprovação da reforma

Implementar um plano de intervenção com vistas à redução da incidência da Diabetes mellitus descompensada na Unidade Básica de Saúde Vilas Reunidas tem uma grande