De todos os termos que eu já ouvi, sobre TI, talvez nenhum me dê tanto frio na espinha quanto o termo “Fábrica de Software”. Não se sabe ao certo a origem desse termo, mas não tenho dúvidas que teve como base principal o modelo industrial de produção. Ou, como muitos conhecem, o famoso waterfall.
Mas o que torna esse conceito tão nocivo no mercado de TI?
A cena acima, se você recém chegou na Terra, é do filme “Tempos modernos”, de Charlie Chaplin. Ele é uma ilustração perfeita do modelo nocivo de indústria, que imperou por muitos anos: supervisor, cobrança, rotina, repetição, desmotivação.
Os tempos mudaram. E a linha de montagem se modernizou. Porém, a segmentação de trabalho se manteve. E pior: foi entendida como a forma correta de se trabalhar, e acabou sendo incorporado ao mundo de TI. E chegamos, então, ao termo “fábrica de software”.
Normalmente é fácil de identificar uma fábrica de software. É aquela empresa com cargos extremamente especializados. Temos arquitetos de software, programadores de interface, programadores back-end, analistas, gerentes de projetos, supervisores, designers, executivos de conta, testador, engenheiro e por aí vai. E o pior: estes cargos não são apenas orientações sobre o domínio de cada um, eles também limitam o trabalho de cada pessoa.
E isso acaba levando o que nós já conhecemos: o testador testa; o analista analisa; o arquiteto arquiteta, o programador programa; o gerente de projetos sofre. E só. Ninguém se mete o bedelho onde não deve.
No mundo industrial talvez isso funcione relativamente bem. Mas num mundo onde o principal ativo é o conhecimento, limitar a empresa a este modelo de fábrica é ceifar a criatividade, inovação e, principalmente, a motivação.
Ao criar um modelo de trabalho desta forma, você acomoda o seus funcionários, além de criar silos que geram conflitos. Mas esses talvez sejam os menores dos problemas.
O problema principal, sem dúvida nenhuma, é você incentivar o retrabalho, a baixa qualidade e a falta de engajamento com o resultado final, ao limitar a visão que cada funcionário terá do projeto. Pense: o que motivará um programador a fazer um bom trabalho ou a dar uma sugestão de melhoria, se ele já recebe um documento de 100 páginas com especificações e orientações de analistas e arquitetos. Para ele, o cliente é uma incógnita.
Se, por ventura, esse programador for uma pessoa que deseja melhorar o seu produto, ele apontará uma solução diferente do que lhe foi passada. E daí sua idéia fará o caminho inverso: o arquiteto, o analista, o executivo e todos os que trabalharam antes, terão que aprovar ou não sua sugestão. E adaptar todo o sistema. Fora o custo (de tempo e dinheiro), quem se motivará a rever todo o sistema “por sugestão de um programador que nem sabe nada de arquitetura de software”?
O resultado final é uma cascata (waterfall!) de desmotivações e conflitos. Gerente gritando para o trabalho andar, programador tendo que viver do “pânico do último minuto”, cliente insatisfeito com a demora e a qualidade, diretor esbravejando que a equipe não é responsável.
Eu defendo aqui neste blog a utilização de equipes multidisciplinares. E se, ao invés de linha de produção, você tivesse uma equipe multidisciplinar (arquiteto, analista, programador, gerente, etc.) que recebesse o projeto e desde o início se engajasse com o resultado? Onde todos pudessem discutir abertamente, desde o inicio, as melhores soluções? Ok, vai. Se você quiser pode ATÉ criar uma pseudo-linha de produção dentro dessa equipe. Mas apenas o fato de fazer todos envolvidos participarem desde o início (se possível, até nas reuniões com o cliente), o resultado final já terá uma qualidade bem superior. E, me atrevo a dizer, entregue com muito maior rapidez e menor custo.
Se tudo parece fácil, o que faz com que as empresas mudem? Simples. Aversão à mudança.
Mudança sempre causa dor. A partir do momento em que se sai da rotina e da inércia, você começa a mexer em um vespeiro de pessoas-zumbis que se acomodaram com o sistema e farão o possível para boicotar o resultado. Você escutará muito: “por que mudar algo que funciona?” ou “este processo é assim desde que o fundador criou a empresa. Não podemos mudar”.
E é por isso que os métodos ágeis são mal utilizados, mal interpretados ou simplesmente ignorados no mundo de TI. Quebrar paradigmas, oferecendo uma forma de trabalho orientada ao CONHECIMENTO, INOVAÇÃO, COLABORAÇÃO e MOTIVAÇÃO não agrada a todo mundo.
Principalmente àqueles que ainda usam o nome “fábrica de software” ou que modelam os processos das suas empresas usando waterfall.
O processo de migração é difícil de ser feito, como você disse, a aversão por mudança existe e esta tão presente em empresas de TI que algumas chegam a ser “Fábricas de Software”.
Desde que entrei para empresa que estou venho tentando trabalhar alguma metodologia ágil, mais existe obstáculo em tudo que é proposto, mais não irei desistir facil afinal é meu local de trabalho.
Post muito bom.
Considerações perfeitas.
O que mais me tira a motivação:
Fazer coisas que você nem sabe muito bem porque deve fazer (não pode conversar com cliente)
Não pode escolher ou opinar o que fazer (recebe o que fazer de um gerente ou vem pelo sistema de processos)
Não conhece o impacto e importância do que faz. (simplesmente faz e passa para frente sem ver a coisa rodando)
Estou começando a estudar metodologias ágeis agora, consigo perceber as mudanças e melhorias que a utilização de uma metodologia ágil traz, mas ainda não consegui botar em prática.
Olá,
Leia o livro Fabrica De Software de Aguinaldo Aragon Fernandes. Aplicamos metodologias ágeis na minha empresa, e somos uma Fábrica de Software.
Porém me parece que defensores do método tentam fazer as outras metodologias parecerem péssimas, apenas para promover o ágil.
É algo do tipo: o nosso é melhor porque o deles é pior.
Fábrica de software não tem nada a ver com o que foi citado aqui neste artigo. Não tem nada a ver com linha de montagem, mas sim com reutilização e padronização de códigos. Ganho de produtividade. Conceitos de uma fábrica.
Não sei da onde tiram que todas as fábricas são linhas de montagem.
Mas acredito que esse seja o problema de todos que se aprofundam em apenas um assunto, e não lê sobre os outros.
Métodos ágeis são ótimos, estamos tendo ótimos resultados na empresa.
Porém se informe mais a respeito de outras metodologias, para poder realmente compará-las. E Fábrica de software não é uma metodologia!!!
Abraço!
[...] Flávio Steffens, em Fábrica de Software [...]
[...] Flávio Steffens, em Fábrica de Software [...]
[...] dos próprios desenvolvedores. O nome “artesanato” é usado para contrastar com as abordagens “industriais”, muito utilizadas para software na década [...]
Olá Flavio!
Concordo com o que você disse no seu post, e também compartilho da preocupação que o termo “fábrica” vem causando no nosso mercado, fazendo até a passarmos a competir por preço.
Mas a razão do meu comentário, é tirar uma dúvida com você, a respeito de equipes multidisciplinares.
- Como ter uma equipe multidisciplinar? Você está formando a sua equipe agora, você está conseguindo contratar pessoas que possuem experiências e conhecimentos em mais de uma área e essas experiências e conhecimentos se complementam?
- Uma equipe multidisciplinar é geralmente formada por profissionais mais experientes? Como incluir profissionais juniores e estagiários em tal equipe e como incentivar a multidisciplinaridade neles?
- Na sua opinião, qual o caminho mais fácil para ter uma equipe multidisciplinar: por meio de contratação de profissionais experientes ou formação de profissionais?
- Os profissionais de uma equipe multidisciplinar são mais caros, mas ao mesmo tempo a equipe é menor, você concorda com isso?
- Você teve dificuldades em montar uma equipe multidisciplinar? É difícil encontrar bons profissionais?
Bem, me desculpe pelo grande número de questões. Sinta-se à vontade em responder as que lhe parece mais pertinentes ou que você possa contribuir mais.
Abraços! E melhoras!
ahh.. eu tinha falado que seria uma dúvida, e foram várias (rsrs).
Acredito que vocês esteja misturando conceitos.
O que você critica é o modelo Waterfall, que não é a mesma coisa que Fabrica de Software.
Em 1969, o termo “software factory” foi empregado pela primeira vez pela japonesa Hitachi, mas só começou a ficar popular no início dos anos 90.
A idéia era aplicar conceitos da indústria em geral em ambientes de desenvolvimento de software, de forma a aumentar a produtividade e diminuir prazos e custos.
No artesanato, os produtos inteiros são criados desde o início por indivíduos ou pequenas equipes
Na fabricação uma larga gama de produtos é montada rapidamente com componentes reutilizáveis. As máquinas automatizam as repetições ou as tarefas subalternas.
Existem muitas Fábricas de Software que utilizam Scrum. Porém desenvolvem seus próprios Frameworks, padrões de desenvolvimento, geradores de código para coisas básicas, reutilizam códigos, …
Ou seja, deixam de ser algo artesanal e amador, para algo mais industrial e profissional.
Tem um livro muito bom a respeito de Fabricas de Software do Descartes De Souza Teixeira.
Abraço