A Alienação Tecnologica e as Fábricas de Software
“Uma boa empresa não é aquela que usa a tecnologia para construir Softwares, mas sim a que usa a tecnologia para destruir problemas. Talvez por isso muitas Fábricas de Software não são boas empresas.”
Coloquei as frases acima no Twitter, mas acho que a reflexão merece mais do que um micro-post.
Gosto também de duas outras frases cujo sentido apontam na mesma direção. A primeira, de autor desconhecido, é mais ou menos assim: “A Informática surgiu para resolver problemas que não existiam antes dela”. A segunda, do Jamie Zawinsk, diz: “Ao ver um problema algumas pessoas poderiam pensar: ‘acho que posso resolver com regular expressions’. Agora elas têm dois problemas”.
O que todas estas frases têm em comum? Elas sintetizam bem a Alienação Tecnológica que as empresas e os profissionais de TI têm ajudado disseminar com bastante afinco – e que tem um pouco a ver com o que tenho falado aqui e aqui.
A Alienação Tecnologica é a utilização da tecnologia como um fim em si e não como um meio para a solução de problemas. Em outras palavras, o pessoal de TI começa com o intuito de resolver um problema do mundo real, mas acaba voltando as prioridades para um código fonte, uma arquitetura, um banco de dados, um Design Pattern, uma técnica nova ou uma documentação os deixam felizes, mas não o usuário. Isso acontece porque no meio do caminho estas pessoas de TI estavam tão preocupadas com o TI-Centrismo que já não sabem mais o que realmente importa. E não estou falando apenas da burocracia que os movimentos ágeis tão na moda atualmente estão tentando derrubar. Estou falando daqueles casos (não raros) onde as pessoas pouco se importam com a utilização de fato do Software pois seus artefatos (código, arquitetura, Banco, etc) são seu motivo de orgulho.
Por inúmero fatores isso acontece com muitas Fábricas de Software. Aliás, vamos pensar por um instante sobre o termo Fábrica. Qualquer tipo de fábrica, exceto a de Software, é definida por uma linha de montagem que produz algo que já existe (escopo mais que fechado e técnicas já conhecidas e testadas). Mas as Fábricas de Software são as únicas Fábricas que precisam produzir algo que ninguém sabe o que é ainda.
A Fábrica de Software é, em minha opinião, uma tentativa exagerada de industrializar ao extremo algo que por natureza têm muitos elementos que tendem a ser “artesanais” (soluções específicas para problemas específicos). Não estou dizendo que não devemos ter métodos e técnicas que facilitem este processo, mas voltando ao início do post, o problema é quando estas técnicas e métodos passam a ter razão de existir em si: a Fábrica fabrica o que não se conhece, mas o que importa é algo foi entregue.
Isto é como se a Ford se orgulhasse mais do seu processo de produção do que dos carros que as pessoas compram por escolha própria. Um engenheiro ou o Designer de carros da Ford deve se orgulhar ao ver as pessoas passeando em seus carros pelas ruas do mundo. Por outro lado, muitos profissionais de TI se contentam com algo que só eles conseguem enxergar. Isso é ou não é um caso evidente de alienação?
Tweet
Eu não gosto do rótulo “fábrica” porque me lembra pé-no-chão, baixo clero, mão-na-massa (como se o trabalho do desenvolvedor não fosse um trabalho intelectual).
E tem essa questão também de que as fábricas reais produzem o que já foi projetado. As fábricas de software, na maioria das vezes, vão descobrindo o que vai ser produzido a medida que o projeto avança. Não sei se a substituição da “engenharia de requisitos” pelos métodos ágeis (também não gosto desse rótulo – quem não quer ser ágil? não ser ágil é ser “lerdo”; não usar um “método ágil” é usar um “método lerdo”) são a solução ou só mais papagaiada do mercado. Acho que os métodos ágeis são métodos para melhoria da gestão de projeto, mas não do projeto. A avaliação do sucesso de um projeto, segundo os critérios de gestão de projetos (conformidade com custo, prazo e escopo planejados) são bem diferentes dos critérios do negócio e dos usuários (conformidade dos resultados alcançados com os objetivos planejados).
Acho que um dos problemas é o tipo de demanda que as fábricas de software recebem. Muitas vezes, o software é uma solução (ou faz parte de uma solução) dada por uma pessoa ou equipe de uma empresa que passou pra equipe de TI resolver que passou pra fábrica de software desenvolver. Ou seja, do problema até o software, a solução ou os objetivos reais do projeto (que não são os objetivos do gerente do projeto) já não são nem mais mencionados. O objetivo do software acaba se perdendo (ou se alienando) no projeto…
Faço das suas minhas palavras, ah a boa e velha vaidade inracional e a culpada, software e feito pra resolver problemas, não para satisfazer a VAIDADE de programador, e nen encrementar seus curriculos!
Fico puto !!!!
Acho que é isso que acontece aqui em meu setor com alguns desenvolvedores, eu pelo contrário sempre pensei em fazer software para o usuário. Um professor meu sempre dizia, “Quando faço meus sistema, primeiro mostro a minha avó para ela testar”, é claro que o buraco é bem mais em baixo, mais temos que mudar essa questão do TI-centrismo. Enfim mais um belo posto Beck.
abraços
[...] Novaes, em A Alienação Tecnologica e as Fábricas de Software [...]
[...] Novaes, em A Alienação Tecnologica e as Fábricas de Software Veja o post original no blog do autor [...]
[...] Suponho que muitos que estão lendo este texto também são apaixonados por seus códigos, seus algoritmos, suas implementações de MVC (verbo “to be” da programação), suas Best Practices e, principalmente, suas tecnologias favoritas. O problema é que quando eu estava apaixonado esqueci a minha “origem”, esqueci o que havia me motivado realmente a entrar neste mundo: fazer programas de computador. O código, limpo, inteligente e bonito era o que importava agora. Eu havia me tornado um “alienado tecnológico“. [...]