Texto escrito em 2013
Enquanto escrevia meu trabalho de conclusão de curso sobre assédio moral em fábricas de software fiz algumas descobertas que mudaram profundamente minha visão a respeito do nosso mercado. Dentre estas descobertas está a curiosa história que vou relatar neste post do termo "fábrica de software".
Eu precisava de relatos de assédio moral (bullying) ocorridos fora do Brasil e simplesmente não os encontrava. Ainda mais interessante, ao buscar a tradução literal do termo, "software factories" encontrava uma série de softwares a venda. Ora, software não gera assédio. Meu segundo passo foi buscar uma tradução para o termo e, para minha surpresa, também não encontrava algo que pudesse me satisfazer.
Questionei diversas pessoas em busca de uma tradução para o termo e, ainda mais curioso, ninguém me dava uma tradução que não fosse a literal. A minha antiga percepção de que nosso grande problema em desenvolvimento de software é linguístico se mostrava cada vez mais forte. Uma mera percepção não era suficiente: eu precisava de fatos. E eis que começa minha pesquisa. Segue a história.
Japão: a Hitachi em 1969
Em 1969 enquanto o mundo se maravilhava com o homem chegando à Lua a Hitachi japonesa cunhava o termo "software factory" com extremo sucesso na sua divisão "Software Works". É interessante que o termo "fábrica" (factory) neste momento já é considerado polêmico. O objetivo da Hitachi era maximizar sua produtividade e qualidade através do reuso de componentes de software tirando máximo proveito da sua escassa mão de obra.
Toda peça de software escrita pela Hitachi a partir deste momento só é gerada se pode ser reaproveitada em mais de um contexto. "Fábrica" aqui diz muito mais a respeito do modo como estes componentes são combinados de forma a atender as necessidades dos clientes do que com linha de montagem. Aliás, não há linha de montagem como nas brasileiras, que se materializam sob a forma do modelo em cascata.
A inspiração por trás da fábrica de software japonesa é a produção de chips, área na qual a Hitachi já possuí alguma experiência. Quando um circuito integrado é projetado, normalmente são usadas estruturas chamadas ASICs (Application Specific Integration Curcuit), que são como componentes eletrônicos na forma de circuitos integrados. Estes possuem funções muito bem definidas, como por exemplo processar determinado tipo de sinal. A idéia básica era: se conseguimos criar circuitos integrados desta forma, por que não aplicar o mesmo princípio à produção de software?
Surgem na Hitachi iniciativas como a criação de workbenches para documentar e construir componentes. Sabe o que estes workbenches influenciaram na criação? A IDE que você usa ao programar. Surgem também novas práticas de componentização, melhorias na documentação e diversas outras técnicas que de uma forma ou outra acabaram por entrar em nosso dia a dia.
E o sucesso da Hitachi é absoluto: 90% de reuso. Mas como isto é possível? A partir de um esforço gigantesco voltado à componentização e foco nos nichos em que a empresa atuava: componentes eletrônicos/elétricos. Todo o desenvolvimento é voltado para um nicho específico: o da empresa. Leia este artigo de 1987 publicado pelo MIT sobre o assunto:"Hitachi: pioneering the "Factory" Strategy and Structure for Large Scale Software Development". Nota: repare no termo que é incluido entre áspas.
1986: Europa e sua iniciativa Eureka
Em 1986 iniciou-se um projeto europeu chamado "Eureka Software Factory", também conhecida como "fábrica de software genérica". O objetivo era obter o mesmo sucesso dos nossos amigos japoneses incentivando a construção de componentes reutilizáveis de software.
Foi uma iniciativa que tinha como visão um mercado europeu composto por uma série de produtores de componentes que seriam vendidos para as empresas, que por sua vez teríam apenas a função de integrá-los a fim de satisfazer suas necessidades. Teríamos empresas especializadas, por exemplo, na construção de componentes responsáveis por geração de notas fiscais eletrônicas, validação de dados, e por aí vai.
O projeto durou aproximadamente 10 anos e em seu desenvolvimento criou-se uma série de protocolos e interfaces padronizadas que permitissem aos consumidores adquirir componentes compatíveis que pudessem fácilmente ser integrados em um sistema maior. Você provávelmente não encontrará muito material sobre a iniciativa Eureka pois esta "falhou" miserávelmente. Ao negar o foco em um nicho específico a construção de componentes se torna muito vaga: consequentemente os desenvolvedores europeus não compraram a idéia.
O fracasso não quer dizer que a Eureka tenha sido em vão, muito pelo contrário. Diversas abordagens que vemos hoje como por exemplo SOA têm suas raízes (mesmo que muito indiretamente) nos padrões arquiteturais desenvolvidos pelo projeto. O melhor texto que encontrei sobre a iniciativa Eureka é também a melhor descrição da história da iniciativa das fábricas de software. Trata-se do texto "The Software Factory: Contributions and Illusions", cujo capítulo 17, que trata da iniciativa Eureka e também da fábrica japonesa pode ser acessado neste link.
Década de 1990: Estados Unidos e CMM
O Departamento de Defesa dos EUA tinha prejuízos gigantescos com seus fornecedores de software, e com isto cria a iniciativa CMM (Capability Maturity Model) que dará origem ao nosso conhecido CMMI. O objetivo era padronizar os processos dos seus fornecedores a fim de minimizar a possibilidade de enfrentarem prejuízos nestes contratos. Básicamente a primeira forma do CMM era um formulário usado pelo contratante na análise do fornecedor a fim de, entre outras coisas, verificar se este era compatível com suas necessidades.
Repare que interessante: o CMM surge graças a uma necessidade do cliente, não do fornecedor. Ao contrário das iniciativas européia e japonesa, o foco não está mais nas ferramentas usadas, mas sim no processo desenvolvido. O componente adquire uma natureza menos técnica e mais epistemológica: vêmos claramente o foco na gestão do conhecimento. Conhecimento é sempre compatível. É a palavra tecnologia levada ao seu literal, ou seja, como conhecimento (logos) a respeito da técnica (technos).
A idéia básica é a de que com um processo que vise sempre o seu próprio aprimoramento você consiga mais fácilmente repetir a execução de projetos e com isto entregar com maior qualidade e dentro do prazo o software que seu cliente precisa. A fábrica de software brasileira é profundamente influenciada pelo modelo CMMI (basta ver o MPS.br).
Ainda aqui vêmos o foco em nichos específicos de mercado. Os fornecedores normalmente possuem expertise em uma área de conhecimento que os possibilita construir softwares para uma área específica. Apesar de lindo na aparência, o CMMI é alvo de diversas críticas atualmente, dentre as quais o fato de que possuir um belo processo não implica em ganho de qualidade necessáriamente, e também o fato de muitos se certificarem apenas para conseguir clientes, e não para obter qualidade. Uma crítica muito bem fundada a este modelo pode ser lida neste link.
E no Brasil?
No Brasil fábricas de software desenvolvem para qualquer nicho. Aliás, desenvolvem para um nicho específico: se chama mercado ( :) ) ao contrário do que ocorre nos três modelos que apontei acima. O termo fábrica é levado em seu sentido fordista literal, ou seja, como uma linha de montagem que se inicia nos requisitos e termina no teste sob a forma do modelo em cascata. A idéia do especialista em tudo, tal como se observa na prática se formos analisar friamente é um contra-senso: especialista requer foco, se você não o possuí então se torna o famoso "especialista em nada".
Apesar do CMMI apresentar a política de reuso como uma das práticas a serem atingidas pelas empresas que queiram se certificar nos níveis mais elevados, não vêmos a sua produção e manejo tal como ocorreu no modelo japonês, europeu e norte-americano. E não: comprar componentes para o seu Delphi ou Visual Studio não caracterizaria sua fábrica no mesmo nível, pois esta não está criando componentes específicos para o mercado.
O mais próximo que vêmos do termo originário "fábrica de software" são empresas como a TOTVS que realmente constróem componentes para seus ERPs. Tirando isto, a fábrica que atende qualquer um está bem longe daquela que vemos na Hitachi de 1969. Ainda pior, vêmos na visão literal da fábrica brasileira a adoção de práticas claramente tayloristas, como o exagero de foco em índices e a alienação do profissional do processo produtivo o que propicia enormemente a ocorrência do assédio moral.
E fora do Brasil? O que houve com as reais fábricas de software?
Aparentemente o conceito de fábrica de software como técnicas visando máximo reuso de componentes não se popularizou. Elas com certeza existem, porém não há uma grande produção de artigos nos últimos seis ou sete anos sobre esta técnica. O mais próximo que pude encontrar da realidade brasileira no exterior foi um folheto da HP de 2003 no qual a ênfase se dá mais ao termo outsourcing do que fábrica ao oferecerem serviços de desenvolvimento de sistemas baseados nas práticas CMMI. Porém, lendo com atenção este documento você percebe características do modelo europeu sob a forma de ferramentas e técnicas de desenvolvimento.
O conceito de fábrica de software focado em componentização aparentemente adquiriu uma nova cara: integração de serviços, como pode ser visto, por exemplo, nesta apresentação da IBM aonde o termo é aplicado novamente. No mais, o termo basicamente caiu em desuso até onde pude observar, ou então simplesmente adquiriu outras formas como por exemplo SOA e outras práticas de integração de sistemas.
Conclusões
O que chamamos de fábrica de software não é uma fábrica de software, mas sim um serviço de outsourcing de desenvolvimento de sistemas, o que é bastante diferente. A partir do momento em que adotamos metáforas ruins para descrever o que fazemos acabamos por nos enganar a respeito dos nossos reais objetivos profissionais, mas já falei algo sobre isto anteriormente.
Top comments (0)