5 fatores (subjetivos) que tornam o software proprietário insustentável para as micro, pequenas e médio empresas
Talvez este artigo pareça uma crônica. Não é um texto técnico nem se aprofunda em investigações, mas baseado em experiências do cotidiano, em algum ponto, comparando com as próprias experiências do leitor, podemos concluir que a insustentabilidade do software proprietário vem aumentando, e quem vai sofrer mais não são as grandes empresas.
Parte 3: Não saber o que está fazendo
Esse fator é ao mesmo tempo consequência e causa do anterior, aliás, eu creio que todos os 5 fatores que eu me propus a expor são interligados, "interagem" entre si. Se vermos este fator numa escala sequencial, vindo logo após o anterior, até mesmo o administrador mais hábil na gestão financeira corre o risco de "levar uma rasteira" por não saber com o que está mexendo.
E isso parte de um princípio: software não é comércio, mas sim indústria, e proporcionalmente é um dos ramos mais complexos da "produção industrial". Quem simplesmente comercializa não necessariamente precisa saber como aquilo que comercializa é feito, no máximo precisa saber como funciona. Mas ninguém "vende" software, software é desenvolvido, não é simplesmente comercializado.
E está é uma indústria que produz serviços, assim o erro também consiste em encarar software como um produto. Mesmo que o sistema de automação usado por uma empresa não tenha erros, seja completo, ainda assim o consultor de suporte sempre vai precisar visitar seus clientes porque o produto-serviço fornecido interfere diretamente na gestão, nas vendas, no financeiro, no contábil, da administração da empresa atendida, sempre haverá algo a ser acompanhado.
Muito mais que um sistema de gestão informatizado, também devemos ter em mente que a função de quem trabalha na área é oferecer consultoria, em informática em si e até mesmo em gestão empresarial. Acontece que perde-se muito tempo focado no "produto" e acaba não se oferecendo um bom "serviço".
As pessoas também acham que basta saber de informática pra mexer com software. Ora, formatar uma máquina, gravar um CD, instalar um periférico, isso não tem nada a ver com gestão comercial. Um nerd não necessariamente será hábil para desenvolver um sistema para gerenciar uma empresa. Do mesmo modo que o mais entendido dos administradores não é necessariamente o mais indicado para ser responsável pelo desenvolvimento de um software voltado para a área administrativa.
É como se fosse assim: um mecânico ou engenheiro de Fórmula 1 não necessariamente será o piloto mais rápido e talentoso, da mesma forma que o melhor piloto pode não entender nada de mecânica, engenharia ou aerodinâmica. Ainda aproveitando esta analogia, isso demonstra a complexidade da coisa, para haver sucesso precisa haver uma interdependência, mas nem sempre é assim.
É por isso que temos sistemas que, do ponto de vista técnico, dos padrões de projetos etc, são modelo, mas não têm sucesso em sua aplicação prática; e, no outro lado, o mais comum, temos sistemas que procuram ser os mais práticos, funcionais, "amigáveis", todo aquele "papo de consultor", mas são um bomba relógio tecnicamente. Ah, sim, e tem também aqueles que são a mistura dos dois. A única certeza é que "um dia a casa cai".
Certa vez eu li que, na indústria, proporcionalmente, não existe nada mais complexo do que desenvolver software. Se você comparar com a indústria aeronáutica essa afirmação parece leviana e ridícula, mas se você levar em consideração isso, guardadas as devidas proporções, isso é fato.
O "não saber o que está fazendo" passa pela questão de metas, objetivos, foco. Os desenvolvedores de software podem até começar bem, mas ao longo do tempo perdem essa visão, e numa fixação pelo retorno financeiro rápido, fácil e exponencial acabam tentando abraçar o mundo.
Voltando à comparação, fazer um Boeing 747 é sim complexo, eu sei que não se compara a fazer um sistema de automação comercial, mas quando um Boeing desses é feito eles sabem o que estão fazendo, sabem que é pra transportar passageiros em voos de longa distância, existem especificações, ele deve ser operado corretamente, ele sai de lá com uma meta, objetivo, foco.
Agora, se os desenvolvedores de software que existem por aí fabricassem aviões, eles venderiam um Boeing 747 pra Esquadrilha da Fumaça, garantiriam que ele ele seria capaz de fazer as mesas manobras que um caça etc, ou melhor (ou pior), o que mais acontece é o contrário, as empresas de software pegam um monomotor, colocam duas espingardas penduradas em cada asa e dizem que aquilo é um caça de guerra, ou então vão fazendo "puxadinhos" nele até ele ter 300 poltronas, dão umas alongadas na asa e dizem que aquilo é um Boeing 747, ou então alguns fazem algumas adaptações e o "transformam" num foguete que vai até Marte... Tá achando exagero? Só mesmo metáforas pra poder explicar o que acontece.
Essa falha por parte da empresa que fornece abre precedente pro cliente. Ora, vou continuar na analogia. Qualquer pessoa que vá viajar de avião, ou seja, qualquer "usuário" do transporte aéreo, sabe que existe um padrão.
Você compra a passagem pra ir dentro do avião, sentado em sua poltrona, com o cinto de segurança apertado durante a decolagem, o pouso e eventuais turbulências. O fato de você ter uma passagem não te dá o direito de ir pendurado do lado de fora na asa, se você compra uma passagem do Rio de Janeiro para São Paulo não pode exigir que o avião te deixe no aeroporto de Belo Horizonte, se a vigem está marcada pras 15:00 horas deve estar no horário (aliás, tem que já fazer o check-in uma hora antes) e não pode exigir que o avião saia mais cedo ou mais tarde. Ah sim, e se você comprou uma classe econômica, não pode querer ir de executiva.
Lembra do que eu falei no primeiro fator, citando como exemplo as siglas TEF, SPED, PAF-ECF, NF-e... Além do custo financeiro os desenvolvedores não se tocam da complexidade que isso representa no processo de produção e manutenção de um software. Uso estes exemplos pois são o tema do momento. Muita gente coloca estas siglas como vantagem em sua estratégia comercial, mas isso são é vantagem, como já disse, é requisito, não é coisa pra que você diga "e não é apenas isso, nós também temos SPED, PAF...", tudo isso é coisa séria, mexe com a vida fiscal e contábil das empresas, erros geram multas, punições...
Não precisa também nem ir pra este lado, o próprio nível de complexidade dos processos envolvidos na gestão de uma empresa, mesmo sem estes requisitos que estão surgindo hoje, já são preocupação o suficiente, cada empresa trabalha de um jeito, cada ramo de atividade atendido pode ser totalmente nada a ver com o outro, e conciliar isso num sistema é uma tarefa árdua.
Está na hora de trabalharmos com mais responsabilidade nesse ramo, a motivação financeira deturpa tanto as coisas que acabamos esquecendo do nível de responsabilidade que é trabalhar com software hoje. A filosofia do software "amigável" e milagroso inverte as coisas, faz com que consideremos muito fácil aquilo que exige mais atenção e que compliquemos o que deveria ser simples.
Enfim, essa é a questão, cada vez mais temos nos ramos da informática, de um lado pessoas "vendendo" aquilo que não conhecem e do outro pessoas "comprando" algo sem saber o que querem. E isso aponta pra dois outros fatores que veremos em seguida. A maioria dos empreendedores que abre um negócio no ramo da informática tem motivações puramente financeiras (é claro que que todo negócio é aberto pra dar lucro), mas o essencial pra ter sucesso em algo é saber o que está fazendo.
E isso parte de um princípio: software não é comércio, mas sim indústria, e proporcionalmente é um dos ramos mais complexos da "produção industrial". Quem simplesmente comercializa não necessariamente precisa saber como aquilo que comercializa é feito, no máximo precisa saber como funciona. Mas ninguém "vende" software, software é desenvolvido, não é simplesmente comercializado.
E está é uma indústria que produz serviços, assim o erro também consiste em encarar software como um produto. Mesmo que o sistema de automação usado por uma empresa não tenha erros, seja completo, ainda assim o consultor de suporte sempre vai precisar visitar seus clientes porque o produto-serviço fornecido interfere diretamente na gestão, nas vendas, no financeiro, no contábil, da administração da empresa atendida, sempre haverá algo a ser acompanhado.
Muito mais que um sistema de gestão informatizado, também devemos ter em mente que a função de quem trabalha na área é oferecer consultoria, em informática em si e até mesmo em gestão empresarial. Acontece que perde-se muito tempo focado no "produto" e acaba não se oferecendo um bom "serviço".
As pessoas também acham que basta saber de informática pra mexer com software. Ora, formatar uma máquina, gravar um CD, instalar um periférico, isso não tem nada a ver com gestão comercial. Um nerd não necessariamente será hábil para desenvolver um sistema para gerenciar uma empresa. Do mesmo modo que o mais entendido dos administradores não é necessariamente o mais indicado para ser responsável pelo desenvolvimento de um software voltado para a área administrativa.
É como se fosse assim: um mecânico ou engenheiro de Fórmula 1 não necessariamente será o piloto mais rápido e talentoso, da mesma forma que o melhor piloto pode não entender nada de mecânica, engenharia ou aerodinâmica. Ainda aproveitando esta analogia, isso demonstra a complexidade da coisa, para haver sucesso precisa haver uma interdependência, mas nem sempre é assim.
É por isso que temos sistemas que, do ponto de vista técnico, dos padrões de projetos etc, são modelo, mas não têm sucesso em sua aplicação prática; e, no outro lado, o mais comum, temos sistemas que procuram ser os mais práticos, funcionais, "amigáveis", todo aquele "papo de consultor", mas são um bomba relógio tecnicamente. Ah, sim, e tem também aqueles que são a mistura dos dois. A única certeza é que "um dia a casa cai".
Certa vez eu li que, na indústria, proporcionalmente, não existe nada mais complexo do que desenvolver software. Se você comparar com a indústria aeronáutica essa afirmação parece leviana e ridícula, mas se você levar em consideração isso, guardadas as devidas proporções, isso é fato.
O "não saber o que está fazendo" passa pela questão de metas, objetivos, foco. Os desenvolvedores de software podem até começar bem, mas ao longo do tempo perdem essa visão, e numa fixação pelo retorno financeiro rápido, fácil e exponencial acabam tentando abraçar o mundo.
Voltando à comparação, fazer um Boeing 747 é sim complexo, eu sei que não se compara a fazer um sistema de automação comercial, mas quando um Boeing desses é feito eles sabem o que estão fazendo, sabem que é pra transportar passageiros em voos de longa distância, existem especificações, ele deve ser operado corretamente, ele sai de lá com uma meta, objetivo, foco.
Agora, se os desenvolvedores de software que existem por aí fabricassem aviões, eles venderiam um Boeing 747 pra Esquadrilha da Fumaça, garantiriam que ele ele seria capaz de fazer as mesas manobras que um caça etc, ou melhor (ou pior), o que mais acontece é o contrário, as empresas de software pegam um monomotor, colocam duas espingardas penduradas em cada asa e dizem que aquilo é um caça de guerra, ou então vão fazendo "puxadinhos" nele até ele ter 300 poltronas, dão umas alongadas na asa e dizem que aquilo é um Boeing 747, ou então alguns fazem algumas adaptações e o "transformam" num foguete que vai até Marte... Tá achando exagero? Só mesmo metáforas pra poder explicar o que acontece.
Essa falha por parte da empresa que fornece abre precedente pro cliente. Ora, vou continuar na analogia. Qualquer pessoa que vá viajar de avião, ou seja, qualquer "usuário" do transporte aéreo, sabe que existe um padrão.
Você compra a passagem pra ir dentro do avião, sentado em sua poltrona, com o cinto de segurança apertado durante a decolagem, o pouso e eventuais turbulências. O fato de você ter uma passagem não te dá o direito de ir pendurado do lado de fora na asa, se você compra uma passagem do Rio de Janeiro para São Paulo não pode exigir que o avião te deixe no aeroporto de Belo Horizonte, se a vigem está marcada pras 15:00 horas deve estar no horário (aliás, tem que já fazer o check-in uma hora antes) e não pode exigir que o avião saia mais cedo ou mais tarde. Ah sim, e se você comprou uma classe econômica, não pode querer ir de executiva.
Lembra do que eu falei no primeiro fator, citando como exemplo as siglas TEF, SPED, PAF-ECF, NF-e... Além do custo financeiro os desenvolvedores não se tocam da complexidade que isso representa no processo de produção e manutenção de um software. Uso estes exemplos pois são o tema do momento. Muita gente coloca estas siglas como vantagem em sua estratégia comercial, mas isso são é vantagem, como já disse, é requisito, não é coisa pra que você diga "e não é apenas isso, nós também temos SPED, PAF...", tudo isso é coisa séria, mexe com a vida fiscal e contábil das empresas, erros geram multas, punições...
Não precisa também nem ir pra este lado, o próprio nível de complexidade dos processos envolvidos na gestão de uma empresa, mesmo sem estes requisitos que estão surgindo hoje, já são preocupação o suficiente, cada empresa trabalha de um jeito, cada ramo de atividade atendido pode ser totalmente nada a ver com o outro, e conciliar isso num sistema é uma tarefa árdua.
Está na hora de trabalharmos com mais responsabilidade nesse ramo, a motivação financeira deturpa tanto as coisas que acabamos esquecendo do nível de responsabilidade que é trabalhar com software hoje. A filosofia do software "amigável" e milagroso inverte as coisas, faz com que consideremos muito fácil aquilo que exige mais atenção e que compliquemos o que deveria ser simples.
Enfim, essa é a questão, cada vez mais temos nos ramos da informática, de um lado pessoas "vendendo" aquilo que não conhecem e do outro pessoas "comprando" algo sem saber o que querem. E isso aponta pra dois outros fatores que veremos em seguida. A maioria dos empreendedores que abre um negócio no ramo da informática tem motivações puramente financeiras (é claro que que todo negócio é aberto pra dar lucro), mas o essencial pra ter sucesso em algo é saber o que está fazendo.
Isso ficou um tanto quanto contraditorio...
Seu artigo defende o software livre em detrimento do proprietario. No atual cenario o software livre seria o "pequeno" e o proprietario seria o "grande".
O que você frisou em diversos pontos do artigo foi o que voce disse no seu artigo anterior, a culpa é sempre dos usuários imbecis que não se interessam em aprender a utilizar o computador corretamente, mas lembre-se, isso não vai mudar...
Sabe qual é a fórmula do sucesso? Pergunta ao Bio Gades... ele vende (caro) um sistema muito pior(isso foi vc que disse) e obtem muito sucesso...
Acho que temos que rever muitos conceitos e não seguirmos apenas paixões..
Eu torço para o meu time e não para um sistema...