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.
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.
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
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
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.
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.
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
(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:
Estrutura Departamental - Até Maio/2005 Equipe Fases: 1, 2, 3, e 4 Produto: Z Equipe Φ Equipe Ψ Fases: 1, 2, 3, e 4 Produtos: X e Y Fases: 1, 2, 3, e 4 Produto: W
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:
Competência 3 Produtos: X, Y, W e Z Competência 1 Produtos: X, Y, W e Z Competência 5 Produtos: X, Y, W e Z E st ru tu ra I n ic ia l d a F á b ri ca A A n o I Competência 4 Produtos: X, Y, W e Z Competência 6 Produtos: X, Y, W e Z Competência 2 Produtos: X, Y, W e Z
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
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:
Competência 4 Produtos: X, Y, W e Z Competência 5 Produtos: X, Y, W e Z E st ru tu ra F á b ri ca A A n o I I Competência 1 Produtos: X, Y, W e Z Competência 2 Produtos: X, Y, W e Z Competência 3 Produtos: X, Y, W e Z X Y W Z
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.
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.
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