Semana passada participei de um evento que me fez perceber algo que até então achava ser óbvio para a comunidade de desenvolvimento de software e simplesmente não é. Sei que muitos vão rir de mim em um primeiro momento, mas que se dane: vou jogar aqui de uma vez: as pessoas não sabem ou simplesmente ignoram o que é valor.
O que é valor?
Na Filosofia o conceito de valor está ligado diretamente à justificativa de uma escolha. Por que é bom ser correto ao invés de mentiroso? O que justifica optarmos por esta estratégia ao invés daquela? Esta justificativa precisa se apoiar em fatos, o que torna a definição do contexto em que a questão se coloca fundamental.
Nosso contexto é o desenvolvimento de software e a justificativa o que será agregado. A escolha diz respeito à opção por uma ou outra tecnologia/estratégia/processo/mentalidade. A questão é: agregar para quem? Há duas possibilidades: o desenvolvedor ou o cliente.
Se for um ganho para o desenvolvedor, este se dá sob a forma de conhecimento que pode ser aplicado a trabalhos futuros. Trabalhos futuros são executados para alguém: o nome deste “alguém” é cliente. Sendo assim, aqui está a minha definição de valor dentro do desenvolvimento de software:
Valor é a justificativa por trás de uma escolha visando agregar positivamente ao cliente.
É muito óbvio né? Então vou dar dois exemplos que mostram o quão longe da questão estão as pessoas da nossa área. São casos comuns e possívelmente o leitor já se deparou com algo assim ao participar destes eventos voltados para a nossa área. É só apertar um pouquinho a sua memória (se bobear, vai me ver em um dos exemplos).
Situação 1: afogando o ouvinte em escolhas
Um dos assuntos mais quentes últimamente diz respeito ao desenvolvimento de aplicações 100% baseadas em JavaScript tanto do lado cliente quanto servidor. Para cada uma das camadas há inúmeras possibilidades, que nosso palestrante alegremente nos expõe.
Terminada a palestra, sabemos que há um leque imenso de opções disponíveis ao desenvolvedor. Duas perguntas normalmente não são respondidas:
- O que meu cliente ganha quando uso esta tecnologia?
- Visto que tenho tantas opções, qual o comparativo entre estas que justifique a opção de uma ou outra?
Resumindo: opções foram jogadas na sua cara, mas justificativas que lhe ajudem a optar por uma ou outra não. Ter um monte de opções não é ter valor: ter um monte de justificativas aplicadas a cada uma sim. Importante mencionar que justificativa pode ser tanto a favor quanto contra uma opção.
Situação 2: afogando o ouvinte em detalhes
Há um ditado popular que diz ser o melhor médico aquele que está doente. Bom: eu já me curei. A melhor maneira de ilustrar esta situação é com a seguinte pergunta:
Imagine que você precise vender uma linguagem de programação em 40 minutos: o que você falaria?
Nosso palestrante podería tentar vender Groovy por exemplo mostrando alguns detalhes interessantes da linguagem, como o fato de ser dinâmica, podermos escrever Java Beans com menos linhas de código ou expondo o fato de termos closures. Há uma infinidade de aspectos interessantes em Groovy! Um ouvinte poderia se levantar e soltar uma frase como esta:
Minha equipe já possuí uma boa experiência com nossa linguagem corrente e o que você descreveu conseguimos fazer também com alguns subterfúgios.
O que este questionador – que aos olhos do palestrante normalmente é visto como um ser desagradável – está na realidade pedindo é o valor por trás da linguagem/tecnologia. Para cada um dos detalhes apresentados o questionamento a respeito do porquê devemos trocar nossa linguagem por esta se aplica e é válido, ou seja, implora por valor.
Entenda: não há valor em detalhes técnicos, mas sim no todo. Existir uma sintaxe mais bonitinha que me permita codificar algo com menos linhas de nada vale se o custo para o aprendizado for muito alto para minha equipe e não agregar nada para meu cliente. Talvez uma resposta válida fosse que a produtividade da equipe aumentaria significativamente por causa dos detalhes, mas neste caso teríamos de lidar com os pontos negativos também, como ausência de mão de obra qualificada.
E lembre-se: não há bala de prata. Toda tecnologia tem pontos positivos e negativos. Ah, sobre isto é importante falar sobre o quê e quem está nos desviando do que interessa, o valor.
O Hype e o “Hypista”
Conforme você fica mais velho se torna mais claro quando o hype ocorre. Hype é a super valorização de determinado objeto, você o usa por que basicamente é O objeto. Repare que normalmente não há muitos pontos negativos no que é vendido. Ele é lindo, é usado por pessoas inteligentes, e você normalmente é uma pessoa muito atrasada se ainda não usa. Mas claro, você é um cara bacana certo? Não???
Normalmente é vendido por algum imbecil disfarçado de hipster. Aquele tipo de pessoa que desperta o desejo adolescente de fazermos parte de um grupo seleto composto só por pessoas divertidas, descoladas, brilhantes e bem sucedidas. E sim: o “valor” que os caras te oferecem é apenas o de ter a chance de fazer parte deste grupo. Ah: e o ganho pro cliente? O ganho pro cliente é ter um desenvolvedor ultra hipster!
É muito fácil detectar o Hypista: ele é um cara ultra cool e já chega dizendo que todo caminho diferente do que está vendendo é errado, mainstream, antiquado, etc. Repare: ele não vai ver valor nas outras opções, é uma variante do fan boy. O problema é que estes caras são ultra férteis e tem procriado horrores.
Você destrói o Hypista com uma única pergunta. Assim que ele terminar sua apresentaçao, basta soltar algo do tipo:
Muito bonito isto tudo o que você me mostrou. Sabe, minha equipe já está acostumada a trabalhar com o modo antiquado (faça uma careta para parecer cool, eles sempre acreditam). O que nosso cliente ganha com a nossa mudança para o seu brinquedo novo e qual o custo disto?
Pronto: você criou um inimigo e garantiu alguns segundos de diversão. Normalmente a resposta vai ser precedida por algo do tipo “Ah… ahn…. bom: veja bem… é… sabe…”. Pronto: hypista detected. Outro aspecto interessante: repare que as apresentações destes caras normalmente são muito parecidas com aquelas vendas que vemos nos canais de compra. O bom profissional não vende, ele expõe valor. Jà parou pra pensar que houve alguma razão para criar todas aquelas opções descartadas pelo Hypista?
Importante: nem sempre o que está sendo vendido pelo Hypista é ruim. O problema é que o idiota não sabe o que é valor.
Concluindo
Da pra concluir duas coisas deste meu post. A primeira é que a questão do valor não é tão óbvia quanto pensamos. É preciso ter auto crítica e saber afogar o hypista que todos temos dentro de nós. Quando nos deparamos com alguma tecnologia ou linguagem nova é muito comum nos apaixonarmos por ela. O apaixonar-se normalmente é acompanhado de cegueira. Tá achando aquilo muito lindo? Seja como nós mineiros e desconfie: nada é tão lindo assim, sempre há um custo. Pra que aquele negócio serve de fato? Com o que já tenho já não resolvo o problema não? O custo vale à pena? Outro ponto importante é a quem o valor deve ser agregado: sempre, por mais que neguemos é o cliente direta ou indiretamente. Muitas vezes o valor de algo é sabermos que simplesmente não iremos usá-lo.
PS: e talvez eu esteja ficando meio rabugento com o tempo.
O engraçado é como eles defendem com unhas e dentes e te despreza se você não concorda com eles! hauahu
Já conheci vários assim! heheh
Realmente hoje na nossa área é o que mais se vê são desenvolvedores progressistas que vestem a camisa de certas tecnologias e sem se importarem com o objetivo final.
Você foi muito bem ao falar que esses caras estão apaixonados, e que normalmente ficamos cegos quando estamos nesse estado de transe. rs
Num é André? Eu fico de cara.
O importante é a auto crítica sempre.
Excelente post!
Poderia se chamar: “Porque nem todo desenvolvedor pode ser um arquiteto de sistemas”. :-D
Cito aqui o termo arquiteto que o RH contrata para a função de chancelar decisões técnicas em um projeto. O arquiteto que cito aqui é líder técnico e está disposto a tomar decisões junto com o time o auxiliando a não perder o foco nos direcionadores do projeto. Não estou me referindo ao famoso “cargo elevado”, pois como um verdadeiro líder, deve lavar os pés dos seus companheiros, conhece e faz tudo aquilo que exige, conhece e assume suas fraquezas e usa a força do próximo para se tornar um time forte, além de conhecer sua força e usá-la para o bem do time, da empresa e do cliente. Um exemplo latente é o “Ricardo” Eletro. :-D
Esta tomada de decisão técnica exige um amadurecimento que não está pautado na idade, mas sim no leque de experiências vividas, no entendimento dos direcionadores de negócio – tanto da corporação (o corpo formado por pessoas que trabalham juntas, e paga seu salário!) quanto do cliente (que espera uma solução para uma necessidade ou problema e não uma “tecnologia”), bem como na meritocracia do time quanto das tecnologias utilizadas, transformando paixões e tendências em opiniões bem formadas através de bons argumentos.
+1 Kico!
Nossa Wanderson, que bom que gostou cara, valeu!
Sabe, o que me assusta é a assolada de Hypistas que tenho visto por aí. Outro dia resolvemos checar o currículo de alguns deles pra ver quem eram, quais suas experiências e tal: a conclusão que chegamos foi a de que não tinham experiência alguma e os jovens, que estão começando agora, os vêem muitas vezes por causa dos aspectos que citei no post como líderes, exemplos a serem seguidos.
E isto gera consequências na nossa classe inteira, que passa a tomar decisões cada vez piores e, com isto, perder sua credibilidade com os clientes.
Estou trabalhando agora para reverter esta situação: não havia tido o “toque” de que o troço era tão grave assim. Mas é assim mesmo: um dia a gente percebe, começa a correr atrás e acaba virando o jogo. Valeu pelo apoio de novo!
A diferença entre o crítico e o rabugento é que o primeiro foca no comportamento e o segundo nas pessoas.
É só tomar cuidado pra não chamar o outro de ‘idiota’ (mau sentimento sobrepondo a boa razão) e deixar que a pessoa chegue a esta conclusão por ela mesma com base em argumentação e paciência.
Em tempo: acredito que não exista valor que não seja agregado. Ele está sempre agregado a algo. A nossa função é mostrar aquilo que sempre está agregado mas nem todo mundo enxerga.
Abraço!
Pois é: sabe, eu to tentando controlar esta tendência que tenho. Mas de vez em quando o negócio simplesmente foge de mim!
Vou manter o “idiota” e “imbecil” no texto só por honestidade intelectual, mas nos próximos vai diminuir, garanto! Valeu pelo toque!
Ótimo texto, kiko.
De fato, esses “gurus” fazem qualquer tecnologia consolidada e estável tornar-se motivo de vergonha para lideres técnicos/gerentes que acabam desperdiçando tempo, energia e dinheiro (as vezes público!) em “cursos oficiais” para subtituir o quanto antes as tecnologias “obsoletas” (que eram estáveis, tinham ótimo nível de produtividade pelo conhecimento da equipe, etc).
Lembro quando o JSF 1.x surgiu. Fiz testes de carga e análise de código gerado. O desempenho foi sofrivel e o volume de HTML/JS/CSS gerado era muito grande. Em 2 dias cheguei a conclusão que não seria tecnologia ideal para web sites e *talvez*, com muito esforço, viesse a ser boa para “sistemas web” (imitação de programa “desktop” mas via web). Dai os com mais tendência a acreditar em “hype” logo acharam que aquilo era a “bala de prata”. Afinal, a “IDE Visual” do Netbeans era “o Delphi pra Java” na visão de alguns… e o resultado muitos conheçem: alguém aí conhece um grande portal que seja caso de sucesso com JSF 1.x?
Que bom que gostou, valeu.
E cara, muito bem observado. O grande problema com os hypistas é que são incrívelmente caristmáticos, e é muito triste quando ocorre o que você descreveu.
Agora, sabe o que me anima? É que normalmente estas pancadas levadas pelo cliente alimentadas pela pura ignorância são poucas, e é o momento em que você infelizmente tem de chegar com aquele momento EA (Eu Avisei).
Se mesmo assim continuarem, é sinal de que a coisa ta mais preta que o imginado. Excelente comentário Yoshi, são eles que enriquecem o texto. Valeu!
Oi Kico,
Gostei muito do texto. Eu acho que a questão sobre valor vem com maturidade por parte de cada um de nós… Por exemplo, essa questão de valor é muito mais observada em profissionais de engenharia por exemplo, ou em profissões com conselhos de classe. Pois, caso o cara tem que agregar o máximo de valor possível para o cliente, com o menor custo e com segurança máxima, pois há vidas em risco. Hoje nas faculdades de ciência da computação por aí, o aluno se forma mas acha que o mundo de trabalho é uma brincadeira, pois ele desenvolve sistemas e isso não vai matar ninguém se der errado. Por exemplo, em grandes indústrias, onde precisam de desenvolvimento de software, para controladores de caldeiras de fundição e fornos de alta temperatura, são engenheiros que desenvolvem isso aí, porque eles tem noção do valor que tem que gerar ali naquele software, bem como todo risco agregado. Li esses dias no livro do sommerville “Engenharia de Software” 8 edição, uma coisa que você iria achar interessante, depois eu digito para você e mando. Esse é um assunto extenso, que ficaria conversando com você um tempão sobre.
Concordo com a visão do texto.
Um abraço.
Sabe Adriano, o que eu observo é que o grande problema relacionado ao conceito de valor na nossa área é a ausência do sentimento de responsabilidade.
É muito comum o desenvolvedor tirar fora a responsabilidade sobre o trabalho que está desenvolvendo com a desculpa de que “meu trabalho não afeta diretamente as pessoas de forma fatal”. Na realidade, eu discordo disto: indiretamente o que causamos é muito pior: trata-se de um evento acumulativo que sim, indireto, mas não menos culposo, acaba por gerar prejuízos enormes à comunidade.
Depois me passa este texto aí? Estou pesquisando mais a fundo o problema e provavelmente vai virar outro post aqui. :)
Kico,
Segue o trecho do texto do Sommerville. Eu acho que a maioria dos GPs na nossa área atrapalham demais, digo a maioria, não todos.
By Sommerville,
“Um problema com a garantia de qualidade baseada em processos é que a equipe de garantia da qualidade QA pode insistir em que os processos padrões devem ser usados independentemente do tipo de software em desenvolvimento. Por exemplo, os padrões de qualidade de processo para sistemas críticos, podem definir que a especificação deve estar completa e aprovada antes de se iniciar a implementação. Entretanto em alguns sistemas críticos podem requerer prototipação, na qual os programas são implementados sem uma especificação completa. Passei por situações em que a equipe de QA sugeriu que esse prototipo deve ser realizado porque a qualidade do prototipo não pode ser monitorada. Nessas situações, a gerência sênior precisa intervir para assegurar que o processo de qualidade apóie e não impeça o desenvolvimento do produto”.
Voltando a Adriano novamente.
O que ocorre na prática é que a maioria dos gerentes querem puxar saco da empresa e seguir o processo de forma igual para qualquer projeto, sendo que na nossa área T.I, software não é bolo, ou componente eletrônico, cada software tem uma particularidade e tem formas de desenvolvimento diferentes. Topamos com gerentes despreparados que não conhecem a fundo a nossa área e devido ao medo de serem “passados para trás” pela equipe de desenvolvimento, usam a ferro e fogo os processos. Processos são bons, mas tem que ser adequados para cada tipo de projeto. Enfiar processo garganta a baixo da equipe de desenvolvimento de fato não é uma opção saudável. Aí a equipe de dev, acaba desmotivada e fazendo um trabalho ruim, o projeto tende a não atender as expectativas do cliente e não gerando valor, e o pior, se entrar em produção pode ocorrer problemas críticos.
Repara que o Sommerville usou a primeira pessoa em uma parte do texto, ou seja, o próprio já passou por isso.
A mensagem que fica é: Processo é necessário, só que cada projeto tem que seguir apenas partes de um processo. Nem tudo de um processo será usado em um projeto de desenvolvimento de SW.
Abraço
Ou seja, é a questão do valor de novo né? O que justifica o uso do processo “as is” e como isto vai gerar algum ganho pra quem realmente importa que é o cliente.
Tá vendo? É uma questão básica, parece óbvia, mas as pessoas simplesmente não a colocam na mesa no dia a dia do desenvolvimento, o que gera todas estas monstruosidades que você citou acima.
Muito bom, Kiko!
“O ganho pro cliente é ter um desenvolvedor ultra hipster!” ~~> dei risada dessa parte;
Enfim, me lembrei de uma discussão que teve ontem no meu facebook: eu perguntei até quando iriam comparar médicos com programadores e uma das respostas claramente dizia que tanto o médico quanto o programador sabem o que fazem, e que o cliente ou paciênte deviam ficar quietos em seu lugar.
Código é uma arte? Creio que sim, mas o principal é que estamos servindo a alguém. Que adianta fazer tudo com o que se tem na moda se o nosso cliente não vai ganhar nada com isso?
:)
Nada contra aprender coisas novas. A-do-ro. Mas nem tudo dá para usar para nosso cliente.
Um adendo: valor não é só dinheiro, mas também objetivo :)
Tem um pessoal por aí que sonha com a imagem do “desenvolvedor solipsista”, ou seja, aquele profissional que só programa pra si e para si, e que ignora completamente a existência de um mundo externo ao seu cubículo. Muito triste.
Concordo, o valor não é só dinheiro: o importante é você ter em mente o conceito de valor sempre. É a razão que justifica a sua escolha com o objetivo de agregar (qualquer coisa) ao cliente.
Sabe, eu digo mais: eu tenho uma formulinha para o valor:
if (ganho > custo) {
valor vale à pena
} else {
fica como aprendizado não seguir este caminho
}
Ótimo texto! Parabéns.
Sempre defendi (http://elemarjr.net/2012/01/28/perseguindo-a-inovao/) que a inovação está relacionada a capacidade de gerar “dinheiro novo”. É o cliente aceitando pagar por estar percebendo valor “de fato” em algo que está recebendo. Novidade sem “dinheiro novo” é apenas isso – novidade.
No fim, acho que essa nossa dificuldade (me incluo) em resistir ao novo vem do fato de que achamos que nossa atividade é “fim”, quando, na verdade, “é meio”. É duro reconhecer, mas software é suporte para o negócio – e não o oposto. (http://elemarjr.net/2012/01/29/hora-de-pensar-em-enterprise-architecture/)
O que foi dito sobre tecnologias, também cabe a processos. No final, “boas práticas” são sempre aquelas que maximizam a entrega de valor, reduzindo o custo total de propriedade. (http://elemarjr.net/2011/08/23/afinal-o-que-so-boas-prticas/)
Era isso.
BTW, assinei o feed.
Opa, valeu.
Justamente: acho que há um problema de ego envolvendo nossa profissão (provavelmente ocorre em outros lugares, mas não tenho esta vivência) que nos impede de ver o óbvio: nosso software é meio, não fim (muito bem observado isto).
A pior parte de ler seu texto, foi ter reconhecido que já fui assim X-|…
Mas tudo bem, é passado… rsrsrs :D Excelente texto Kico, cada vez mais estou me despreocupando em ficar “por dentro” do que sai toda semana no mercado e buscando me aprofundar na base.
abs []
Que bom que gostou Adriano, valeu.
É: conforme eu ia escrevendo vi um pouco do meu “antigo eu” por lá também.
Mais um bom texto, né Kico? Já virou rotina. Parabéns.
Apesar de não ser da área de desenvolvimento de softwares, vou dar meus 10 cents aqui, levando o assunto para outra área onde não só os produtores (vou usar produtores ao invés de desenvolvedores pois a gama de profissionais envolvidos é bem mais eclética) mas também os CLIENTES são ou estão cada vez mais hypistas.
WEB (entenda-se agências e seus clientes)
Está se tornando cada vez mais difícil demonstrar o valor neste nicho, pois os próprios clientes tem comprado o que é “trend” e como não dão o braço a torcer, com todo bom hypista, ainda se enganam dizendo prá si mesmos que estão fazendo ótimos negócios.
O ó do borogodó do momento são as famigeradas estratégias de mídias sociais.
Então o que se vê na área, é uma enxurrada de agências vendendo especialização em social media e uma enxurrada de empresas comprando social media como se isto resolvesse todos seus problemas de marketing.
Não importa o segmento de atuação da empresa e seu público alvo.
Tome social media prá tudo quanto é lado.
Não interessa se a empresa é uma indústria do setor aeronáutico que produz parafusos específicos para turbinas, e seus consumidores sejam os departamentos de compras de montadoras de aeronaves.
Ao invés de se pensar num website tradicional, estilo catálogo, com um sistema de busca ágil e geração de pedidos em cima de uma base de dados técnica… tome aí uma fanpage.
Eu fico doente quando vejo casos parecidos com este exemplo hipotético que acabei de citar.
Fico pensando como é que tal empresa “comprou” tal estratégia.
Aí vou um pouco mais a fundo, e vejo que o depto. de marketing do cliente está abarrotado de hypsters que entraram na onda da agência que está pouco se lixando para a adequação da estratégia ao público.
Como demonstrar valor para quem não está apto e também não está disposto a perceber o valor?
Um exemplo real agora:
Há pouco tempo (talvez nem 3 meses) um grande loja varejista do segmento moveleiro, cujo público é escancaradamente das classes D e E, gastou uma puta grana, numa puta campanha baseada no Instagram.
Como assim? Quantas pessoas da classe D e E que vão comprar um guarda-roupas de 300 reais em 12 x de 25,00, tem acesso ao Instagram?
Desculpe por ter desviado da área central deste post, mas o intuito foi demonstrar que este movimento Hypster tem impregnado tudo por aí.
Nesta área de web voltada para marketing, os resultados são mais difíceis de serem mensurados e portanto, mais fáceis de serem mascarados.
A tábua de salvação do desenvolvimento de software, é que software precisa funcionar..rsrsr.. então mais cêdo ou mais tarde, o gato por lebre comprado pelos hypsters inevitavelmente irá mostrar seu fracasso.
Quanto aos hypistas, defensores das ondinhas sem valor da área de software, acho que tudo já foi dito no texto e também nos comentários.
Abs e mais uma vez, parabéns pelo texto.
Cara… você sabe que sou seu fã né? Pqp Moises! Você enriqueceu horrores este post agora. Muito obrigado por nos mostrar outra visão sobre o problema.
Se enriqueceu eu tenho lá minhas dúvidas, mas com certeza falei muito mais do que seria aceitável prá um comentário de post..rsrsr… ô texto longo!
Só tá faltando agora aquele nosso bate-papo-furado via skype, né? Tâmo sempre na correria… mas o dia que rolar, me lembre de falar sobre a “ingratidão” dessas nossas carreiras… acho que será um tema que vc irá curtir.
Abs.
Excelente post Henrique. Gostaria de compartilhar um modo de pensar sobre o assunto um pouco diferente.
Com o mercado de desenvolvimento de software tão competitivo e cheio de ferramentas e tecnologias, o que fazer para divulgar uma tecnologia recém criada? Na minha opinião o hype é necessário, pois, muitas vezes é através dele que certas tecnologias tornam-sem amplamente conhecidas. Isso é bom, pois, ajuda no próprio desenvolvimento da tecnologia e do mercado. O hype está presente em todas a áreas de nossa vida. Cinema, games, livros, cosméticos, vestuário, etc…
Dado essa necessidade de divulgar e “vender” tecnologias que, apesar de muitas vezes serem open source, tiveram muito investimento, na minha opinião o lado decepcionante da história somos nós, os consumidores das tecnologias. Cabe a nós sabermos escolher a caixa de ferramenta que adicione mais valor para o cliente. Se um desenvolvedor escolhe trabalhar com determinada ferramenta, apenas pela palestra do rapaz cool, ora, a falta de preparo é exclusivamente dele, o palestrante está fazendo o trabalho dele, evangelizar!
Nós vivemos em um mundo onde temos que fazer escolhas todos os dias, a nossa obrigação como profissionais, é estarmos preparados para sempre procurar fazer a melhor delas!
ps: Quero deixar claro que concordo com o argumento do texto, porém pra mim, nesse caso, o foco maior deveria ser na audiência da palestra e não no palestrante.
Oi Paulo, interessante isto: e muitas veze é papel do vendedor (repare, estou falando de *vendedor*). Agora: numa classe igual à nossa, desenvolvedores, tão estigmatizada pelo mercado, será que ainda seria válido?
E ai eu me pergunto: se parte do desenvolvedor para o desenvolvedor jr, que está em processo de aprendizado ainda, será que não estamos criando uma geração que simplesmente age de acordo com as emoções ao invés de pela razão que é o esperado de nós? Sinceramente, tenho muito medo de estar vendo a morte do pensamento crítico no pessoal mais novo.
Oi Kiko,
Muito interessante o seu texto, concordo com ele, mas uma coisa me incomodou. Ele é um forte argumento para o conformismo e a comodismo. A questão do valor sobre tecnologias não é algo fácil de ser medido mesmo para quem conhece profundamente a realidade de um cliente. Perguntar a um palestrante o que o seu cliente ganha com isso, não é uma pergunta “justa”. O palestrante não conhece o seu cliente, muito menos os problemas do seu cliente. O palestrante vai vender uma tecnologia. Cabe a nós, como profissionais, verificar se a tecnologia é mais adequada ao problema do cliente. A mudança é estressante para os desenvolvedores, não há fatos, apenas promessas, a decisão mais comoda é manter tudo como está e todo mundo fica conformado. Por outro lado temos que saber separar o que é hype e pode ser aplicado para resolver problemas recorrentes do seu cliente, do que é hype e é super legal e cool e a equipe adoraria aprender. Qualquer que seja a tecnologia que você adota hoje com sucesso, foi antes uma novidade, um hype. Tem gente que adota as coisas porque todo mundo está adotando e não quer nem saber porque. Outros querem padronizar tecnologias e frameworks como se existissem uma solução única para todos os problemas (busque sobre o anti-padrão martelo dourado e law of instrument). Eu penso o seguinte: se alguém perdeu tempo desenvolvendo algo novo é porque tinha um problema que não estava sendo resolvido a contento.
Vou dar uma olhada e ver se eu tenho esse problema. Se sim, vou estudar essa solução (recomendo fazer isso usando 3 fontes no mínimo). Após avaliar a solução não em 40 minutos, mas em 40 dias, poderia afirmar se ela é boa ou não.
No mais gostaria de parabeniza-lo pelo Blog.
Oi Alan, bacana que tenha gostado, valeu.
Mas basicamente o que você está dizendo é o mesmo que o post diz: que você usa a coisa porque te agrega valor, não porque é um hype brutal.
Com relação à pergunta ao palestrante, lógico, cada caso é único e o sujeito não vai saber o que te responder, mas o básico ele tem de saber: o que realmente aquela tecnologia agrega e não apenas os detalhes, como normalmente ocorre.
Inspiradora explanação, aprender a lidar com “nossas paixões” nos ajudará a ampliar nossos horizontes e a melhorar a qualidade daquilo que produzimos.
Que bom que gostou Julio, valeu. :)
Cara, comecei a ler seu blog hoje e já tô virando fã. rs
Bajulações à parte, digo que você conseguiu definir bem a situação. No início da minha vida como desenvolvedor isso me atrapalhou horrores. Por causa desses caras parecia que eu estava sempre atrasado, que meus projetos eram ruins e obsoletos por não estarem utilizando todas as tecnologias do momento, etc.
Com o tempo aprendi que o importante é focar no problema do cliente e entregar a solução com maior custo/benefício pra ele. Isso agrega valor.
Embora sejamos apaixonados por tecnologia, temos que entender que ela deve nos servir e não o contrário.
Grande abraço!
Oi Rodrigo, que legal ler isto, valeu!
Sabe: eu estou pensando em retornar a este tema em breve. Talvez nesta semana mesmo. :)