O Termo nos diz tudo: Fábrica, material, estoque, linha de produção, pessoas executando a mesma tarefa, término, executa novamente, exaustão, problemas de saúde, etc. Se levarmos essa analogia para a área de desenvolvimento de software seria mais um grande equivoco que estaríamos cometendo. Coisa que ocorre com muitos CIOs e gerentes.
Quando disse que isso seria uma analogia equivocada, vamos primeiro definir o termo analogia. Segundo a Wikipedia, a analogia é uma relação de equivalência entre duas relações. Segundo o Wiktionary, analogia é a explanação de uma relação entre dois elementos, comparando o mesmo com outros relacionamentos.
Segundo o termo descrito, quando tentamos fazer uma comparação de um processo completamente dinâmico e complexo com uma definição, que não se sabe ao certo quem definiu, sendo Taylorista partindo do início do século, estamos cometendo um erro. Pois, quando pensamos em uma Fábrica, especificamente de sapatos, dá para compreender no mínimo que lá se produz sapatos, a mesma coisa para software, porém, com uma diferença enorme.
Ao iniciar a produção de um software, estamos entrando em um dos ciclos mais dinâmicos e complexos que existe. Produzir software não significa executar, como a analogia define, e sim projetar. O software é o resultado de um conjunto de tarefas completamente intelectual onde não há repetição. Ao falar em software devemos ter em mente a existência de pessoas extremamente gabaritadas com conhecimento em hardware, linguagens de programação, frameworks, bancos de dados e no problema na qual o software destina a resolver. Quando produzimos um software, não estamos produzindo uma cópia, e sim um produto específico, original e suscetível a mudança.
Portanto, fazer analogias de atividades que pertencem a segmentos distintos, coisa que é normal na ciência da computação, torna-se um processo equivocado. Cada área segue um princípio que é apoiado por uma base de conhecimento que é adequado ao seu segmento de atuação. Atribuir analogias de uma atividade para uma área distinta pode ocultar muitos detalhes específicos de uma atividade, fazendo com que a identidade de seu segmento seja mal compreendida por pessoas que seguem um paradigma.
A utilização de paradigmas em acesso é extremamente prejudicial para a disciplina de desenvolvimento de software. Isso porque são conhecidos, erroneamente, como boas práticas de desenvolvimento. Na verdade, muitos são dignos de levar o nome de “boas práticas”, já outros, são casos de sucesso que deram certo apenas para um determinado segmento ou situação.
Utilizar paradigmas sem questionamentos sobre seu benefício na solução do problema significa que estamos bitolados. Não critico a utilização de paradigmas, critico a utilização de paradigmas sem o questionamento de sua real utilidade. Isso se aplica de forma extravagante na engenharia de software, pois demonstra total dependência de técnicas e procedimentos que é resultado da evolução da ciência.
O fato de utilizar uma abordagem, sem questiona-la, sobre sua real utilidade estará nos encorajando a sempre seguir as mesmas regras, até mesmo para segmentos distintos. Um dos principais remédios para isso são as mudanças.
A mudança é o elemento crucial para o sucesso no desenvolvimento de software. O dinamismo e a colaboração andam lado a lado com esse princípio. Ser dinâmico é ser funcional. Não é atoa que existe uma área específica na engenharia de software para gerenciar mudanças. Então, porque não torna-la mais dinâmica do que já são.
Além das mudanças, outro quesito que as complementam são as interações e colaborações. Característica encontrada em abundancia no mundo de open source. Nos primeiros contatos com essa idéias normalmente ficamos encantados e surpresos ao vasculhar os fontes do kernel (ou apenas Linux, já que é o nome do núcleo). Já outros questionam sobre o processo utilizado pela Apache para dar conta de tantos projetos. A resposta para tudo isso está na colaboração, interação e contantes modificações. Não existe um processo burocrático que limite o pensamento e a criatividade dos desenvolvedores. Todos são livres para pensar e expor idéias. Esse é o segredo.
No mundo open source não existe processos que regem as regras e normas para desenvolver um software. Existe sim muita colaboração entre os envolvidos no projeto. Colaborar é o segredo. Isso mantém as pessoas motivadas e livres para pensar. O que eu quero dizer com isso é que: quanto menos nos preocuparmos com documentações excessivas, modelagens, processos, entre outras coisas burocráticas, sempre teremos problemas com prazos e qualidade. Isso inibe a criatividade de quem participa está participando da atividade pois, sempre haverá uma atividade planejada posterior a que você esta exercendo. Coisa comum em uma fábrica de software.
Defendo que o desenvolvimento de software é 80% arte, resultado de uma inspiração motivada por um despertar criativo, e o resto é o resto. Defendo também as palavras de Domenico de Masi quando diz que o “ócio também pode ser criativo”. Também guardo a célebre frase: “A Imaginação é mais importante que o conhecimento”, proclamada por ninguém menos que Albert Einstei.
O resultado de todo esse alvoroço é que algumas empresas de tecnologia mudaram a sua visão e muitas já nasceram com isso. Uma delas é a Google. Fundada por dois jovens geeks, decidiram incluir o conceito de liberdade e colaboração em sua empresa, ou seja, resolveram fazer da empresa algo semelhante a um compus universitário. O resto você sabe o resultado.
As metodologias ágeis seguem o mesmo conceito. Além do mais, incluem o conceito de colaboração em suas atividades principais, como codificação, reuniões, interações e até mesmo nas comemorações de entrega de release. Já participei de coisas como essas e garanto que é bem divertido.
Fazer analogias entre elementos distintos quando não há compreensão de suas raízes é uma atividade normal, porém, fazer analogias de forma copiosa, isso se torna um problema. A área da informática faz isso frequentemente e muitas das vezes não apresenta um resultado óbvio. Tentamos ser como a industria automobilística, construção civil ou até mesmo com acadêmicos de filosofia porém, nos esquecemos de quem somos, de nossas particularidades e raízes.
Fabricas não são lugares para interações e muito menos para a criatividade. São lugares que exigem que faça o mesmo serviço para montar um mais produtos, apenas isso. Portanto, afirmar que uma empresa de desenvolvimento de software se assemelha a uma mera fábrica é resultado de uma errónea analogia, que tem como base uma área pouco compreendida em comparação com a áreas de segmentos distintos.
Bom, acho que falei demais. Tomei cuidado para que esse texto não soasse com um tom de desabafo e ao mesmo tempo pejorativo e sim esclarecedor, pelo menos tentei.
Nenhum comentário:
Postar um comentário