Sempre quando vou apresentar uma plataforma de desenvolvimento que não seja “mainstream” topo com argumentos do tipo “aonde vou encontrar mão de obra que saiba lidar com isto?”, “ninguém que eu conheço usa isto!” ou mesmo “para nos mantermos competitivos temos de usar as ferramentas que o mercado adota”. Papo furado!
“Competitividade”
“Gente em terno” adora usar a palavra competitividade. Não é a toa que sinto calafrios, dado que raras vezes os vejo usar o significado real do termo. Competitividade vêm de competição: é você contra um ou mais adversários que possuem um objetivo em comum. Seu objetivo não é estar “ao lado”, mas sim “na frente”.
Um pouco de papo furado
“Aonde vamos encontrar mão de obra qualificada para isto?”
Se a ferramenta não possuir uma documentação adequada, provavelmente este argumento se sustenta. Infelizmente, o que observamos é o fato deste negar uma capacidade básica do ser humano: as pessoas aprendem.
Então, a partir do momento em que você adota este tipo de postura sua única possível vantagem competitiva ao adotar o que seus concorrentes usam desaparece: você não precisa mais de pessoas que queiram e gostem de aprender: você precisa de pessoas que já saibam. Se elas gostam de aprender ou não passa a ser uma espécie de brinde.
Na minha opinião a melhor maneira de se testar a capacidade de um profissional é ver como este se porta no contato inicial com tecnologia alienígena. É neste tipo de situação que você capta como a pessoa lida com as dificuldades que surgem no trabalho. “Curioso” usarem tão pouco isto em processos seletivos.
“Não é padrão de mercado”
Então padrão de mercado é fazer igual seus competidores? Você acaba de negar a capacidade de aprender da sua equipe (vide “aonde vamos encontrar mão de obra”), logo o máximo que você tem é a média. A não ser que seja definido em contrato pelo seu cliente, você possuí liberdade para escolher o que usar: e se for possível com a “Arma X” obter um resultado superior, pergunto: por que não? Maria vai com as outras?
Compatibilidade com os padrões de mercado não implica em ser igual ao resto: implica em funcionar com este. Pegue a JVM por exemplo: é um maravilhoso padrão de mercado. Realmente, é difícil pensar em plataforma superior, no entanto quem disse que você precisa usar como linguagem de programação apenas Java? Eu por exemplo tenho usado muito Groovy e Clojure. Estou dentro do padrão de mercado e com competitividade superior.
Também não é porque é um “padrão de mercado” que a coisa seja ruim. Na maior parte das vezes estamos lidando com um padrão bacana: o diferencial está no relacionar-se com este. Chutar porque é mainstream é burrice.
“Aonde eu vou arrumar emprego com isto?”
Este é o argumento mais triste e normalmente parte do próprio desenvolvedor. A questão não é aonde você vai arrumar emprego, mas sim o que você vai agregar no seu atual (e futuro) com o conhecimento que você adquire com tecnologias “fora do mapa”. Veja o meu exemplo com Lisp citado acima. Mesmo que você jamais use sua arma secreta na prática, o simples fato dela ter te agregado conhecimentos novos já te enriquece.
E outra: procurando bem você sempre encontra alguma coisa. Afinal de contas, normalmente o brinquedo não foi inventado por você, então ALGUÉM usa. Você que é o responsável pelo seu futuro profissional, não a empresa em que você trabalha.
“O ambiente para o qual desenvolvemos é incompatível com isto”
Se realmente for, por que você está perdendo tempo avaliando uma tecnologia que não vai funcionar? É função intelectual básica saber escolher a ferramenta certa para o trabalho correto. Se nem isto você consegue fazer, não perca tempo e pule fora da área. Simples assim.
Armas secretas
Se você trabalha com desenvolvimento e quer se diferenciar você precisa de armas secretas mesmo que jamais as use na prática. Chamo de arma secreta toda tecnologia/conhecimento que não seja usada em massa mas que de uma forma ou outra te agregue algum conhecimento. Muitas vezes elas oferecem alternativas interessantes para problemas comuns que seus adversarios, por estarem usando todos as mesmíssimas coisas, gastam um tempo danado para resolver.
Um exemplo de arma secreta que possuo mas raríssimas vezes usei na prática foi Lisp. Não programo tão bem nesta linguagem como faço em Groovy ou Java (minhas especialidades), mas o simples fato de ter tido contato com Lisp me tornou um programador melhor. Quando o hype das linguagens funcionais surgiu, por exemplo, não era novidade pra mim: já programava em Java daquela forma por muitos anos e não enfrentava a maior parte dos problemas que os “funcionais” gritavam por aí.
É interessante observar hoje que, enquanto vejo a maior parte das pessoas programando para as plataformas Java ou .net eu conheça pouquíssimas que estejam ficando ricas de fato com estas plataformas. Em contrapartida, vejo pessoas ficando muito ricas com (prepare-se…) Delphi, VB6 e Autolisp. Justamente plataformas que são ignoradas pelo mainstream. O mais interessante é que vejo pessoas pequenas se tornarem grandes, e os grandes que se mantém no senso comum se manterem, bem: apenas grandes, com pouco crescimento.
Armas secretas abrem sua mente: elas tiram da sua cabeça a idéia de que um ou outro objetivo é inatingível, porque muitas vezes é a tecnologia mainstream que o mostra como desta forma.
Exemplo histórico interessante: Apple
Não há nada de novo no que estou falando: a Apple só surge e se torna um sucesso devido às suas armas secretas. Enquanto em 1975 as pessoas acreditavam que computadores pessoais seriam algo extremamente caro de se produzir devido ao modo como computadores eram construídos na época por empresas como IBM ou DEC, Steve Wozniack percebeu que usando componentes de prateleira como memória de televisores e um tal de processador Zilog Z80 meia boca era possível construir alguma coisa. Há duas armas secretas em ação aqui: a genialidade de Wozniack e o uso de componentes eletrônicos alternativos.
Resultado: um PC de US$ 666,00 que foi a base para que a Apple por muitos anos estivesse à frente da IBM. Davi vs. Golias clássico.
(depois eu sei que o IBM PC bateu o Apple II, mas foi por força bruta, com um investimento bilionário contra um outro que estava na casa dos milhares de dolares (mesmo perdendo a Apple ganhou em eficiência))
Exemplo próximo: itexto
Que tal agora um exemplo de uma empresa realmente pequena: a minha. Vocês sabem como eu ganho diversas concorrências? Usando minha principal arma secreta: Grails. Dado que a maior parte das demandas que chegam a mim são basicamente CRUDs, quando entro em uma competição as ganho por oferecer um preço significativamente menor: enquanto os outros estão focados em JSF, com Groovy e Grails obtenho uma produtividade ordens de magnitude maior. Não perco tempo com integração de componentes ou construção de CRUD: customizo meu scaffolding e foco apenas na lógica de negócios que é essencial ao sistema. Quando meus concorrentes terminam os CRUDs normalmente já entreguei o sistema funcionando.
Resultado: ofereço algo a um preço menor, qualidade e valor superior ao meu cliente, que sempre volta querendo mais. E sinceramente, se o desenvolvimento do Daft Lisp der certo, o vejo como talvez A minha arma secreta profissional. Ah: e quando o pessoal estiver usando Grails pra tudo?Aí eu com certeza vou estar em outra. É sempre assim. :)
Concluindo
Armas secretas não são um luxo: são condição essencial para a sobrevivência e desenvolvimento dos pequenos empreendedores. O argumento de que só devemos usar o que é “adotado pelo mercado”, conforme expus acima, é furado e baseado no pessimismo em relação à própria equipe (“ninguém vai querer aprender”). E mais: se você trabalha com as ferramentas que ama, automaticamente já vai ser mais produtivo que o resto, afinal de contas, você vai correr atrás. Na sua equipe tem gente que é contra e não apresenta contra-argumentos? Ótimo: identificou quem não deveria fazer parte do seu time.
É óbvio que você vai basear suas escolhas em algum raciocínio bem fundamentado, o que não podemos deixar acontecer é o minimizar do homem: um ser que aprende, evolui, constrói coisas maravilhosas e, ainda mais importante: CRIA. Termino este post com uma palestra do Viktor Frankl em que ele diz basicamente isto: quando você espera o mediano do homem, você o faz um ser pior, quando nivela por cima, obtém o seu melhor. Mas ele fala isto melhor que eu. Segue o link: http://www.youtube.com/watch?v=fD1512_XJEw :)
PS: e em muito breve vocês terão uma arma secreta nova para brincar. Devo escrever a respeito nesta semana mesmo. Aguardem! :)
Concordo com muita coisa que você disse kiko. Mas acho que a grande questão que está intimamente relacionada com boa parte desse assunto é que os caras de terno são quase sempre aqueles que tomam as decisões, e a primeira preocupação deles está em buscar a possibilidade de se contratar mão de obra barata no mercado. São muitas das vezes ignorantes quando o assunto é tecnologia e não se preocupam em inovar mas sim em fazer o básico pelo menor custo.
Se a tecnologia utilizada é padrão, a chance de existir certificações no mercado são grandes, havendo muita oferta também. O “aonde eu vou arrumar emprego com isso” também acaba sendo uma questão relevante quando você esta procurando por trabalho e percebe que muitas empresas oferecem bom salários para especialistas em determinadas tecnologias, mas pouquíssimas querem investir no seu potencial.
Mas acredito que tudo o que eu afirmei não vai contra nenhuma das suas opiniões: é apenas meu ponto de vista.
Oi Christiano, eu concordo com você: o grande problema ao meu ver é que ao adotarem o caminho “mais fácil”, acabam perdendo grandes chances de se tornarem mais competitivos com relação ao mercado.
Aliás, olhando por outro lado: esta é a grande vantagem em ser pequeno. Nós temos uma liberdade muito maior do que empresas maiores. :)
Não é só questão de mão de obra barata, mas de:
a) Dar a garantia de que a tecnologia é estável – e não só uma aposta do desenvolvedor que possa ser descontinuada em poucos anos;
b) Ter continuidade em manutenções, mesmo que o desenvolvedor da arma secreta saia da empresa;
c) Pode estabelecer padrões de qualidade e prever políticas de certificação e treinamento.
d) Evitar aumentar a complexidade do ambiente;
Eu posso citar projetos em que já presenciei prejuízos em todos os casos. Em muitos casos, não se trata de subestimar a capacidade de aprender, e sim, de não pagar in-house o custo desse aprendizado ou, pior que isso, dos erros que a falta de aprendizado irá certamente gerar. Pior do que isso, é apostar que a tecnologia alegada não trará surpresas, que podem impactar dramaticamente no cronograma, e gerar um prejuízo significativo.
Quando se toma decisões, fala-se em valores expressivos de dinheiro. Uma decisão errada pode custar um cliente, ou mesmo, a saúde financeira da empresa toda. Gostaria de saber quem em são consciência sairia apostando.
Inovar exige planejamento e investimento. Se você realmente quer apostar em armas secretas ou, pelo menos, convencer o seu gestor sobre uma nova tecnologia, precisa antes fazer uma boa pesquisa e mostrar dados sólidos. Precisa mostrar qual é a economia gerada, quais são os ganhos de curto, médio e longo prazo e dar a ele a segurança de que está fazendo um bom investimento.
Na informática, há uma cultura muito feia de criticar os gestores como se fossem ignorantes, sendo que somos que chegamos só com argumentos técnicos, sem dar o devido respaldo financeiro ou administrativo. Ou seja, somos nós que somos os ignorantes sobre o que quer o gerente e o que a empresa precisa.
Oi Vinícius, eu concordo com você.
Não pode ser meramente “amo isto, vou usar”, mas sim opiniões baseadas em uma análise bem feita conforme você falou.
a) Dar a garantia de que a tecnologia é estável – e não só uma aposta do desenvolvedor que possa ser descontinuada em poucos anos;
Esse tipo de garantia não existe, e além de tudo, as empresas na hora de anunciarem uma vaga já definem qual tecnologia virá a tiracolo
b) Ter continuidade em manutenções, mesmo que o desenvolvedor da arma secreta saia da empresa;
Descordo totalmente. Isso é sinal de que o gestor está delegando todas as responsabilidades a uma única pessoa. Se apostar em algo inovador, a equipe inteira deverá acompanhar essa evolução.
c) Pode estabelecer padrões de qualidade e prever políticas de certificação e treinamento.
Padrões de qualidade podem ser estabelecidos em tecnologias inovadoras. Novamente, o que está falando mais alto é a lei do menor custo: sai mais barato pagar um cursinho ou pegar algum cara pronto no mercado do que criar um
d) Evitar aumentar a complexidade do ambiente;
Discordo totalmente. Até com bloco de notas você aumenta a complexidade. Organização, planejamento e visão de mercado são teorias que os gestores devem colocar em prática. Se não colocarem, qualquer tecnologia pode ter essas consequencias.
Em todas as áreas, existe a cultura de se levar as opiniões e colocações técnicas para o lado pessoal, e não sei ao certo qual o objetivo disso. Não estou aqui para bater boca, e muito menos para me achar o dono da razão, mas confesso que todos os gestores com quem trabalhei no passado eram sim ignorantes em muitos tópicos de tecnologia. Uma dessas empresas que trabalhei faliu. Logo, pretendo manter o foco na parte técnica aqui nessa discussão, que ao meu ver é desde o início o motivo pelo qual o kico escreveu esse post.
a) Como não? Algumas tecnologias pertencem a empresas (GWT, Dart, TypeScript). Outras estão restritas a pequenos núcleos ou nichos específicos (Haxe, boa parte das linguagens funcionais). Como dizer que isso é tão garantia quanto usar linguagens consagradas, com comunidades formadas, como o próprio Java?
b) Exatamente, e esse é o problema da gestão disso. O texto fala justamente de você ser o dono da arma secreta. Se a empresa como um todo apostar, ok. Mas o problema é que muitas vezes o desenvolvedor ou uma equipe, apostam sozinhos.
Mesmo assim, a gestão disso realmente tem um custo muito alto. Uma idéia de um desenvolvedor pode representar o treinamento da equipe inteira, para evitar o que você falou.
E a tecnologia nova, vendida como panaceia, pode não ser tão melhor assim. E aí, o que vc faz com o tempo de uma equipe toda parada? Do custo de todo treinamento jogado fora? E com os contratos que você perdeu no processo?
Ainda assim, isso só vai fazer a migração tecnologica e logo você estará engessado novamente. Tornar isso uma política, em que haja renovação frequente e permanente é um assunto muito mais complexo.
c) Nem sempre. O processo de certificação está associado a um modelo de maturidade. Especialmente quando se trata de certificações oficiais, exigidas por processos públicos e licitações de governos, ou por clientes grandes. Para garantir qualidade, existe a necessidade de frameworks e processos acessórios consagrados (como é o caso do JUnit, para o Java). Dependendo do quão exotérica for a sua tecnologia, você não terá nada disso e terá que reconstruir tudo do zero. E isso representa custo e risco para a empresa.
d) Não entendi o que quis dizer sobre o bloco de notas. O que estou falando é sobre a co-existencia de várias e várias tecnologias na empresa, que é o que uma política de inovação gera. E pessoal para dar manutenção nisso tudo. Você acabará tendo que ter interoperabilidade e isso gera complexidade no seu próprio ambiente interno.
E, sim, no final sempre vai valer a lei de menor custo. Não só o custo da contratação do desenvolvedor, mas o custo geral. De manter a equipe funcionando, de dar manutenção, de dar garantias, etc.
Novamente, não é o papel do gerente ser especialista em tecnologia. É o papel do desenvolvedor. Nós temos urgentemente, que aprender a nos comunicar melhor com os gerentes. O papel dele é avaliar riscos e tomar decisões, e nós não estamos sabendo promover nossa tecnologia suficientemente bem para convence-los de que o risco é menor do que o benefício.
a) O fato de ter uma empresa grande por tras de um projeto não é garantia alguma. A alcaltel por exemplo descontinuou o openplug e não deu satisfação para ninguém. E quem apostou nele ficou a pé.
b) Pelo que eu entendi, o que o kico quis dizer com ser o dono a arma secreta é o de ter a visão de qual a melhor ferramenta para uma tarefa, mesmo que essa ferramenta esteja fora do menu tecnológico da empresa. Essas idéias é que fazem a grande diferença. Além disso, você já está partindo do princípio que a nova tecnologia será uma panacéia, falando que não será tão melhor de algo que nem conhece. Não seria melhor avaliar primeiro? Quase todas as suas prerrogativas partem do princípio que tudo vai dar errado: dinheiro jogado fora, contatos perdidos. Se eu partir do princípio que vai dar certo, todos os seus argumentos vão por terra. E as chances são 50% a 50%, já que ambos estamos discutindo sem citar um exemplo prático. Politicas de renovação frequentes e permanentes é um tema que normalmente é evitado pelos gestores, mas não tem nenhum bicho de sete cabeças.
c) Exatamente, custos… Sempre os custos, que inclusive foram a prerrogativa do meu primeiro post: menor custo, que é a maior preocupação de muitos gestores. Esses itens pontuados em licitações públicas podem sim representar um ponto de atenção relevante. Mas falando sobre inovação, não será esse o seu diferencial entre seus concorrentes. A Apple por exemplo se tornou uma das empresas mais lucrativas no mundo, e apostou forte na inovação. Correu riscos, que foram diretamente proporcionais ao seu sucesso. Steve Jobs tinha visão técnica e tecnológica (além de ser genial). Amazon é outro caso que aposta forte em inovação. O exoterismo existe apenas na cabeça de quem é contra o tipo específico de tecnologia.
d) Desordem, desorganização podem ser causadas até mesmo pela mais elementar das tecnologias. Pouco importa se é padrão do mercado ou não. A co-existencia entre as tecnologias deve ser de fato uma preocupação, e nesse ponto concordo com você. Mas ao mesmo tempo, o mercado é competitivo e exige novas soluções e adaptações o tempo todo. E muitas empresas se adaptam, inovam e saem na frente (enquanto outras fecham suas portas). Não estou falando por você, pois mal lhe conheço, mas a minha experiência é a de que quando a aposta em uma determinada tecnologia dá certo na empresa, os méritos vão para os gestores; quando dá errado, sobra para os desenvolvedores. Logo, sou a favor de que existam gestores com perfil técnico, e tenho visto cada vez mais pessoas com esse perfil em algumas empresas.
Sim cara, sempre custos. E isso não é necessariamente ruim. Afinal, para um negócio ter sucesso, ele precisa dar lucro. É isso que paga o meu e o seu salário. Sem lucro a empresa fecha.
E para se ter lucro, tem que ter custos sob controle. É impossível gerir sem pensar em custos e prazos. Mas como falei, gerentes pensam em custos de curto, médio e longo prazos.
Eu não falei em ter empresa grande por trás. Falei em ter garantias baseado em tecnologias consolidadas. Mesmo que a Oracle abandone o Java hoje, o Java não morrerá no dia de amanhã – do contrário do que ocorreria com outras tecnologias que citei. Ainda assim, é menos arriscado optar por uma tecnologia com alguém grande por trás do que a tecnologia de um projeto open source tocado por um desconhecido.
E, novamente, não adianta saber da “melhor tecnologia” se você não puder comprovar que essa tecnologia é a melhor do ponto de vista financeiro também. Se ela vai gerar um caos na gestão, se ela não terá continuidade, se será difícil contratar ou treinar, provavelmente seu gerente vai se negar a utiliza-la. Os desenvolvedores devem, necessariamente levar isso em conta.
Quanto a supor que dá errado. O ônus da prova de que dará certo, cabe a quem propõe a tecnologia. A quem defende a mudança. Estou falando das preocupações dos gestores, e lógico, elas serão pessimistas. É parte da sua argumentação mostrar que essas preocupações são infundadas, não a parte dele comprovar que o negócio que já dá certo irá desempenhar melhor do que quer que você esteja propondo.
O argumento de 50/50 não é um bom argumento para seu gestor. Para ele, a tecnologia atual atende 100 ou 90. Sua tecnologia terá que superar esses 100 ou 90, com margem suficiente para valer o investimento da mudança. Isso significa, que as chances costumam a ser inferiores a 50%. Nem todas as empresas são milionárias como a Apple ou a Google e podem se dar ao luxo de financiar erros consecutivos.
A melhor tecnologia do ponto de resolver um problema imediato pode ser uma catástrofe do ponto de vista estratégico: e é isso que seu gestor pode estar preocupado.
Veja, eu não estou indo contra o que o Kiko diz. Mas contra o que nós programadores geralmente argumentamos. O gestor não está preocupado se é fácil, se existem patterns lindos. Ele está preocupado em manter o negócio funcionando, em poder estimar, em poder prever e dar garantias. É isso que ele quer ver em sua argumentação.
É bem fácil usar um discurso otimista sobre inovação, quando o dinheiro que estamos arriscando não é o nosso próprio, e sim o da empresa.
Eu concordo com o VinyGodoy no tocante à necessidade do desenvolvedor saber apresentar a nova tecnologia ao seu gestor. Isso certamente exigirá um estudo profundo dela, e não é em uma ou duas reuniões que se vá convencer, ainda mais um gestor tradicionalista. E uma mudança assim acho que jamais deve ocorrer de uma hora para a outra, a nova tecnologia tem de ser muito bem avaliada e a equipe adaptada a ela.
Mas realmente o que faz falta, como bem disse o Christiano, são gerentes com perfil mais técnico. Lamento discordar, Viny, mas eu até hoje não entendo como um indivíduo manda em outros e toma decisões sobre o que esses outros devem fazer, sabendo mais do que eles sobre mercado, planejamento, estratégia, etc. e **menos** sobre o ofício em si!!!
Porque o que o Kico falou tem grande fundamento sim, sei disso porque (sem querer tomar partido, apenas baseando-se nos posts dele) é um cara que costuma escrutinar o código fonte de todos os frameworks que usa, usando apenas os de qualidade comprovada e usando somente as partes que sabe que não lhe trarão problemas depois.
As tecnologias mainstream (.net e Java, dando a cara a bater rsrsrsrs) são, definitivamente, travadas em produtividade em comparação com N outras que ainda não tiveram seu lugar ao sol ou outras que já tiveram porém perderam por erro de seus criadores (ex.: Delphi). Somente um gerente com capacidade técnica para tal poderá avaliar de maneira certeira o uso de uma “arma secreta”, usando critérios técnicos. O lado líder serviria para motivar a equipe e coisas assim.
Um gerente vai ter 5, 10, 15 funcionários. Um bom gerente irá contratar uma equipe multidisciplinar, com pontos fortes diferentes, que se complementam. Seria impossível que ele conhecesse bem tecnicamente o que seu time todo faz.
Os melhores gerentes que já tive tinham apenas uma boa noção de tecnologia, mas não conheciam a fundo e não programavam. E tive péssimos gerentes que eram técnicos, pois se atinham a detalhes de implementação, entrando em minúncias do “como fazer” (do jeito deles) no lugar de “o que fazer”, dando a sensação de que deviam confiar mais em seus funcionários.
Gerenciar envolve habilidades humanas: lidar com conflitos, assumir riscos, defender um ponto de vista, confiar nas pessoas, negociar e ser político. Ao mesmo tempo, ele tem que se preocupar com custo, com gargalos, com eficiência. E ele também tem um chefe, o diretor, que vai cobra-lo de suas decisões.
Engana-se quem acha que o erro da equipe não resvala no gerente. O erro de QUALQUER funcionário da equipe é culpa do gerente. E a diretoria não vê de outra forma. Só porque muitas vezes ele repassa a bronca, não significa que ele saiu ileso.
Eu concordo que o cara também não pode ser um zero a esquerda em TI. Se ele é gerente da área, no mínimo se informar um pouco ele tem. E, se for o caso dele entender pouco, tem que pelo menos saber ouvir. Mas volto a falar que os especialistas em TI somos nós, e é papel nosso saber quais aspectos da TI tem valor para nosso gerente – coisa que temos feito muito mal.
Estar alheio as preocupações dele, e taxa-lo imediatamente de ignorante só porque ele não entendeu nossa argumentação técnica é uma falha nossa, não dele. Eu tenho visto MUITA gente reclamar, sendo que não sabe argumentar direito com a gerência, e nunca para pensar em qual é a visão da empresa sobre os fatos.
Mas se há alguma disparidade entre a “visão da empresa” e a visão técnica, algo está muito errado. O conhecimento técnico não é simplesmente “coisa de peão”, ele é intrínseco DO QUE A EMPRESA FAZ.
A proposta do desenvolvedor vai resolver/evitar que problema? Dificuldades na manutenção? Velocidade de desenvolvimento? Integração? Etc., etc., etc.?
A parte técnica do “como fazer” é que vai resolver o problema de fato, porém apenas sabendo o básico um gerente não vai avaliar direito e normalmente vai preferir ficar naquela tecnologia que, embora não seja a melhor, é a que ele conhece os problemas e se sente seguro ao lidar. Muitas vezes, o argumento técnico do desenvolvedor será “bem” técnico mesmo, coisa para iniciados. O desenvolvedor está apresentando algo que ele sabe que é bom, que tem capacidade para resolver o problema X. Mas por mais que este se esforce, o gerente não vai entender qual a vantagem de convenções sobre configurações, por exemplo, e pode achar que sem configurações terá menos “controle”. Sem experiência técnica, falta-lhe o ***feeling*** que só o peão, de mão na massa, tem.
Claro, ninguém vai sair migrando N aplicações de Struts para Grails, VRaptor ou Ruby On Rails. E ninguém quer ter mais bases tecnológicas na empresa para dar manutenção e achar mão-de-obra (como se fosse possível basear todo o trabalho da empresa em uma única tecnologia por toda a eternidade). Mas a simples constatação: “estamos fazendo do jeito errado, vamos mudar” já é um avanço. Cabe à empresa escolher se quer, dali para a frente, usar uma alternativa melhor de verdade e reduzir de verdade os custos nos próximos projetos (redução de custo causada pela eficiência TÉCNICA) ou se quer continuar tendo nos próximos projetos os mesmos problemas que têm com os atuais. Isso só um gerente altamente capacitado tecnicamente pode.
Minha argumentação não é diferente dessa. É só que o desenvolvedor muitas vezes não sabe falar com a gerência.
Veja bem, não há dúvida que nós possamos reconhecer que tal tecnologia é melhor. Mas só reconhecer isso sem saber justificar, vai levar à frustração certa de ter um gerente discordando de você.
Como dizer que o que está sendo feito é “errado” se até hoje está resolvendo o problema da empresa? A outra coisa é certa em que parâmetros? Vai poupar o que? Vai custar quanto para implantar? O que farão com o legado? Como darão continuidade ao cliente?
Ninguém usou o termo “peão” antes, e não sei de onde veio essa conotação pejorativa.
“Peão” é só uma alusão ao que sabe e faz acontecer, em oposição ao que manda porém não sabe.
Dizer que o que está sendo feito hoje é “errado” se atende bem é uma coisa; dizer que é “errado” porque está errado mesmo, é outra. E até no primeiro caso, pode não estar errado mas haver algo melhor. Claro que as ferramentas mainstream (leia Java e .NET) atendem bem, se não atendessem não seriam mainstream. E não que eu seja radicalmente contra “mainstream”, mas acho que na época atual já está na hora do “mercado” mudar de paradigma e perseguir mais pragmatismo. Claro que uma ferramenta obscura é cilada, mas ferramentas de nicho também podem ter qualidade e suporte.
O texto do blog nem sugere que as empresas saiam trocando de tecnologia sem mais nem menos, ele vê a arma secreta como algo pessoal do desenvolvedor. Mas o que acontece é que, uma vez que o desenvolvedor se amplia com ela, logo começa a perceber os limites da ferramenta “consagrada” que ele tem de usar no serviço. E embasado no texto novamente, se as empresas querem ter bons profissionais, têm de esperar que eles gostem de estar sempre aprendendo, preferir aqueles que mostrem coisas novas (até aí tudo óbvio). Elas têm de estar preparadas para contar com os serviços de bons programadores de outras linguagens e plataformas. Se eu pegar um bom programador Ruby On Rails e tiver de treiná-lo na minha plataforma Java, esse custo vai compensar? Claro, dependerá da capacidade desse programador.
Veja bem, em momento nenhum eu discordei do texto. Eu realmente concordo com tudo o que o Kiko diz, e ele mais uma vez elucida bem o porque de mudarmos de tecnologia, ou pelo menos, estarmos preparados para a mudança.
Eu mesmo sou responsável por emplacar novas tecnologias em diversas empresas onde trabalhei.
Eu só estou ressaltando UM PONTO. É que a nossa argumentação, ao falar com gerentes, NÃO PODE ser a técnica. Resolvi tomar partido da gerência por dois motivos:
a) Eu já percebi ao longo de anos de experiência, que falar informatiquês não adianta;
b) Que os gerentes e a empresa não estão tão errados assim ao apresentar preocupações financeiras e de negócio.
Estava passando apenas uma dica, para aqueles que realmente querem emplacar essa nova tecnologia em sua empresa, e não se frustrar com um “não” seco da gerência. Se você analisar o que seu gerente analisa, e argumentar como ele gostaria que você argumentasse você tem dois benefícios:
a) Será bem visto pela gerência, como alguém com visão estratégica;
b) Poderá usar sua arma secreta.
E, muitas vezes, nessa análise, você percebe que sua empolgação era só empolgação mesmo e que, do ponto de vista de negócio, é melhor esperar a oportunidade mais apropriada para sugerir uma mudança.
Há muito mimimi na informática contra os gerentes. Facilmente taxamos todos que não entendem de computador de ignorantes, e por causa dessa arrogância não percebemos que o problema não é necessariamente da pessoa, mas nosso mesmo. Me ajudou muito perceber que para falar com gerentes, EU é que tinha que aprender a língua deles, e não o contrário.
Bem, eu já defendo que um gerente **tem** de ser conhecedor além do nível básico. Se vai gerir uma equipe que fabrica tecidos, tem que entender de tecidos. Largar do “informatiquês” é na comunicação com o CLIENTE, não na comunicação com a equipe. Os argumentos por que nós faremos um serviço melhor, mais ágil, de melhor manutenção e etc. têm origem indiscutivelmente técnica.
Se eu também aprendi algo com a experiência, é que ser gerido por alguém sem conhecimento técnico irá me prender em um conservadorismo sem sentido, que pode até não prejudicar muito quando se está tudo bem, mas que vai tornar um parto trabalhar algo que pode e deve mudar.
Facil mesmo e colher os louros da vitoria quando tudo da certo em um projeto que voce foi contra. Mais facil ainda e tentar se isentar dessa responsabilidade quando da errado.
Se sou otimista demais, voce e pessimista demais. E quando falei sobre custos, fiz questao de frisar: MENOR CUSTO… esse e o grande problema. E mesmo projetos que usam as tecnologias padrao do mercado podem dar prejuizo. Logo, a empresa paga essa conta de qualquer jeito, e corre riscos. Botar a culpa toda no tipo de tecnologia utilizada e no minimo precipitado (para nao ser rude).
O que mais vejo acontecer são gerentes **sem** perfil técnico tomarem suas “decisões” baseando-se apenas no que vai gerar menor curso/maior lucro no curto prazo e ignorando que sua decisão vai engessar a equipe de tal forma que no LONGO prazo os prejuízos irão pipocar. Se o gerente tivesse o conhecimento técnico necessário (ou pelo menos levasse a sério argumentos técnicos), dava para ele entender a besteira que estava fazendo.
Posso dar N exemplos pequenos em todos os lugares em que trabalhei, mas o mais emblemático foi um em que toda a santa lógica de negócio estava programada “no Click e no Change”, por assim dizer. Não havia UMA procedure (coisa BÁSICA) definida pelo programador para empacotar algum código! Sugeri recriar a estrutura daquela coisa, mas o dono precisava daquilo “funcionando” no novo SGBD o mais rápido possível. Resultado: pau atrás de pau, e cada corrigido SEMPRE gerava outros (sistema espaguete).
Esse pensamento de “a gerência e a diretoria” não estão preocupados com detalhes técnicos é, no mínimo, inconsequente. Repito, o detalhe técnico é intrínseco DO QUE A EMPRESA FAZ. Ignorá-lo é pisar na razão de ser da empresa, qualquer um faria o que eu faço. Relegá-lo a uma categoria do tipo “o desenvolvedor que me convença se for capaz” sempre levará ao desastre – é como tentar convencer uma criança.
É por isso que eu acho o pensamento mainstream conservador uma bateria de absurdos. Sim, “mimimi”. Fundamentado, mas mimimi!
Concordo contigo.
Hoje trabalho em uma empresa onde tenho o privilégio de ter um gestor técnico. E conversar com ele é muito fácil, já que ele entende o que os técnicos falam e sabe balancear boas idéias dentro do orçamento da empresa.
Conversar com líderes não técnicos é muita das vezes uma tortura. E por melhor e mais razoável que seja a sua idaia, os critérios desse tipo de gerente são muitas das vezes outros: é muito mais uma questão de você entrar “no esquema”, “na panela” do que a qualidade das suas idéias. E o pior de tudo é que esse tipo de gestor costuma sempre ver os bons profissionais como uma ameaça a sua posição.
E isso não quer dizer que esse tipo de gestor representa a alta gerencia da empresa, mas sim que a alta gerencia da empresa acredita nele ( mesmo que temporariamente) .
A receita de ter um gestor técnico tem obtido muito sucesso na empresa onde trabalho, e acredito que também é papel do gestor identificar e valorizar os talentos da sua equipe. Logo, discordo totalmente desse discurso de “temos que aprender a conversar com nossos gestores”. Temos que saber conversar é com qualquer um, gestor ou subordinado. Mas o bom gestor tem que ter um diálogo nivelado com os seus subordinados.
Saindo um pouco em off, mas acreditando que vai enriquecer a discussão, é que essa história de “armas secretas” vs. tecnologias mainstream, depois gerentes técnicos vs. não-técnicos, acaba caindo sempre no velho embate “IDEALISTAS VS. CONSERVADORES”. Eu sei que não tem nada a ver com o assunto inicial, mas eu tenho que verbalizar!
(Kico, se vc achar que estou extrapolando, sinta-se à vontade para excluir meu post!)
Em todos os debates de que participo, percebo que o **conservador** é aquela figura que se ADAPTOU ao mundo como ele é e, encontrando-se confortável em sua situação atual, cospe conselhos defendendo essa situação: para se adaptar, faça assim, assim, assado. O importante é que isso NÃO PODE MUDAR! É assim que funciona e ponto final. O perigo é que nisso pode haver (e sempre há) a defesa de situações injustas, dado que nem todos podem “adaptar-se” da mesma forma, já que muitas vezes, para um estar confortável na situação, outros passam por cada uma do arco-da-velha (caso dos gerentes que não sabem o ofício e o pessoal da área técnica subordinada a ele).
Já o **idealista** muitas vezes é aquele que ainda não encontrou seu “lugarzinho ao sol” e, portanto, defende a mudança no estado de coisas atual (depois que ficam ricos, quase sempre tornam-se conservadores). O mundo é assim, mas que tal sensibilizar um grande número de pessoas para manifestar-se contra? Se a coisa estiver feia mesmo, haverá muita gente tendo o mesmo problema que eu.
Qual dos dois posicionamentos tem mais relevância ética, inclusive? Eu estou com os idealistas, desde que continuem idealistas depois de alcançar posição confortável. O idealismo deve estar a serviço de defender causas nobres para todos, e não somente para si mesmo. São os idealistas que provocam, ainda que a conta-gotas, as melhorias do mundo. Se fosse depender dos conservadores, ainda teríamos escravidão!
Sabe Éderson, acho que você enriqueceu a discussão. :)
Sobre isto, eu sempre me lembro deste vídeo da Carly Fiorina: tudo se resume ao gerenciamento do medo.
http://www.youtube.com/watch?v=w3IbKbDhfKw
Mr. Kico, simplesmente GENIAL. Eu tenho uma intuição, um negócio no estômago, toda vez que um homem de terno vem falar de “mercado”, “competitividade” e sei lá o que mais (é por isso que não leio Info Exame XD).
A minha constatação é que esse pessoal não sabe trabalhar, sabe apenas FALAR e se vender. Se soubessem de fato executar bons trabalhos, na minha humilde opinião o Java EE e o .NET nem seriam mainstream e nem teriam o sucesso que têm por simples investimento das suas empresas criadoras.
Veja o meu caso: para desktop eu sempre escolhia o Delphi (e estou migrando para o Lazarus, o primeiro projeto neste já está em produção); para web eu uso PHP. Comodismo? Não, porque eu venho praticando horrores em Java, tanto para desktop quanto para web. Se eu tiver que trabalhar com Java eu sou capaz, sim, de fazer o serviço. Mas os meus projetos pessoais sempre acabo optando por fazer nas linguagens antigas, porque até hoje ainda não consegui ser tão produtivo em Java quanto eu era nelas. Quanto ao .NET, estou desenvolvendo meu primeiro projeto em C#. É cedo para dar opinião, mas estou achando algo entre o Java e o Delphi ;)
O segredo é que, assim como vc, eu tenho quilos de código que desenvolvi ao longo do tempo justamente para gerar CRUD de maneira mais ágil, tanto em Delphi quanto em PHP. Eles são meu scaffolding customizável, por assim dizer. Eu já tentei fazer algo parecido em Java, mas se mostrou algo bem mais complicado do que nas outras. Podia ter continuado, mas preferi continuar usando o que já tenho pronto e funciona.
Desculpe pelo longo desabafo.
Oi Éderson, que bom que gostou, valeu!
Eu compartilho o mesmo sentimento que você. Sabe: a impressão que tenho é que estes que ditam com o peito estufado usando palavras como “mercado”, “competitividade” na realidade são deslocados. São infelizes que ainda não perceberam que não sabem aonde de fato estão, que software é feito com a ferramenta certa, e não com aquela que o hype domina.
(muito bom ver alguém usando Lazarus!)
Então são praticamente todos deslocados, uns 99,99999999…% eu diria :D
E o Lazarus, vou te falar, ainda é uma ferramenta na infância e que teve um parto difícil (+ de 10 anos até sair a versão 1.0), mas com o auxílio de bons pediatras e muito amor e carinho, irá crescer fortinha e saudável! Uma ferramenta de nicho, claro, mas assim que é bom. Melhor ter que competir com poucos do que competir com a multidão. É a realização do sonho de desenvolver em Delphi e ver rodando em Linux.
Mr. Kico, simplesmente GENIAL. Eu tenho uma intuição, um negócio no estômago, toda vez que um homem de terno vem falar de “mercado”, “competitividade” e sei lá o que mais (é por isso que não leio Info Exame XD).
A minha constatação é que esse pessoal não sabe trabalhar, sabe apenas FALAR e se vender. Se soubessem de fato executar bons trabalhos, na minha humilde opinião o Java EE e o .NET nem seriam mainstream e nem teriam o sucesso que têm por simples investimento das suas empresas criadoras.
Veja o meu caso: para desktop eu sempre escolhia o Delphi (e estou migrando para o Lazarus, o primeiro projeto neste já está em produção); para web eu uso PHP. Comodismo? Não, porque eu venho praticando horrores em Java, tanto para desktop quanto para web. Se eu tiver que trabalhar com Java eu sou capaz, sim, de fazer o serviço. Mas os meus projetos pessoais sempre acabo optando por fazer nas linguagens antigas, porque até hoje ainda não consegui ser tão produtivo em Java quanto eu era nelas. Quanto ao .NET, estou desenvolvendo meu primeiro projeto em C#. É cedo para dar opinião, mas estou achando algo entre o Java e o Delphi ;)
O segredo é que, assim como vc, eu tenho quilos de código que desenvolvi ao longo do tempo justamente para gerar CRUD de maneira mais ágil, tanto em Delphi quanto em PHP. Eles são meu scaffolding customizável, por assim dizer. Eu já tentei fazer algo parecido em Java, mas se mostrou algo bem mais complicado do que nas outras. Podia ter continuado, mas preferi continuar usando o que já tenho pronto e funciona.
Desculpe pelo longo desabafo.
Lembro de ler o Pragmatic Programmer e o autor usar muito a expressão “caixa de ferramentas”. A nossa caixa de ferramentas é responsabilidade nossa, não de gerentes ou diretores – é a responsabilidade pela minha carreira e capacidade profissional.
Hoje há duas “armas secretas” que me atraem: Python e Scala. Se o Daft Framework der certo, Kico, darei uma olhada séria em Clojure, heheh.
sabe que há a posdibilidade de incluir no futuro scala la dentro né?
Massa!
Ouh, só pra completar o que eu escrevi inicialmente, quero dizer que acabei de ver o vídeo no fim do post e achei, como diria nosso amigo Paulo Valadares, top da balada! :-D
Cara, que nego foda aquele palestrante! Que foda a mensagem que ele passou para as pessoas!
ótimo post Kiko… Isso vale não só pra desenvolvedores mas pra muitos profissionais que escolhem suas ferramentas por imposição do mercado sem experimentar nvoas possibilidades. Ao meu ver, linguagem de programação é também uma ferramenta pra se chegar a um determinado objetivo. A única coisa que acho que deve ser levada em conta são as conexões que essa ferramenta terá com as outras, ou seja, compatibilidade com sistema, máquinas e outras questões de uma organização. Se encaixa, se é mais produtiva e se trás uma performance melhor, proque não usar? Mas quem decide não quer correr risco de algo novo. Só que essa nova geração de empreendedores está mudando isso… ou deveria.
Abraços!
erros e mais erros de digitação… é a correria.
Oi Wagner, legal que tenha gostado, valeu!
Esta é a vantagem em ser pequeno: você pode ousar sem medo (não há tanto a perder), então fica mais fácil ter suas próprias armas secretas.
Mas a partir do momento em que você cresce – é minha teoria – você é obrigado a ver as pessoas que trabalham com você como recursos não pensantes e, portanto, o medo em usar algo menos conhecido aumenta. É um puta tiro no pé: como disse, a grande vantagem das pessoas é que elas *aprendem*.
Eu gostei muito do artigo. É sempre bom conhecer mais de uma linguagem e paradigma e estar antenado fora do seu mundinho feliz.
Até para saber quando deixar a sua tecnologia atual e migrar para outra ou mesmo para ter aquela linguagem “canivete suiço” que permite que você monte scripts rapidamente e resolva problemas pontuais.