Fábrica de Software

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.