Como posso defender o Ruby on Rails contra a opinião não técnica dos clientes?

Meu cliente, proprietário de uma empresa de traduções, acabou de me dizer que estava lendo sobre Ruby on Rails e me disse que " há mais pessoas com PHP por aí " e " parece que a comunidade prefere ". O que você, como engenheiro de software e freelancer, diria ao cliente para alcançar esses objetivos:

• Vender
• Faça com que ele veja que a tecnologia é minha decisão de especialista e o Rails é tão bom ou melhor que o PHP (+ qualquer estrutura) para esse projeto em particular.

ATUALIZAÇÃO: Obrigado a todos pelas sugestões! Amanhã eu tenho outra reunião com ele, vamos ver como vai ser, vou atualizar novamente :)

ATUALIZAÇÃO 2: Finalmente, eu disse a ele para ler este tópico e o resultado foi fantástico: ele me deu o projeto e vamos começar agora. Obrigado a todos pela ajuda, você tem cerveja grátis à minha disposição se virmos algum dia :)

BTW: Aprendi a lição: seja o mais transparente possível, porque se você acredita em si mesmo e em seu trabalho, não há dúvida de comprometer o suficiente para vencê-lo.

Saudações

Eu acho que você comete um erro ao assumir que a escolha da tecnologia é uma decisão puramente técnica.

O cliente parece estar preocupado com as implicações comerciais de escolher uma tecnologia específica. Dado isso, é necessário apresentar um caso que atenda às preocupações de negócios dele pelo menos tão fortemente quanto as opiniões de sua tecnologia.

• Os empregadores precisam recrutar de uma área geográfica específica e determinadas áreas têm comunidades particularmente ativas em torno de pilhas de tecnologia específicas. Se você está iniciando um negócio no noroeste do Pacífico dos EUA, por exemplo, haveria uma forte tendência a uma pilha da Microsoft simplesmente porque a Microsoft é muito influente na área, portanto a maioria dos desenvolvedores que você gostaria de contratar tenha experiência com essa pilha. Outras regiões geográficas têm perfis muito diferentes.
  Converse com seu cliente e entenda por que e como ele formou sua opinião. Talvez ele tenha lido que a comunidade PHP local é particularmente ativa ou que a faculdade local ensina muito PHP e não Ruby. Talvez ele tenha um desenvolvedor de confiança que ele possa chamar para uma emergência ocasional que é um profissional de PHP e um neófito de Ruby. Obviamente, também é possível que ele esteja usando métricas ruins, como o número de anúncios de emprego ou currículos que mencionam várias palavras-chave.
• Os empregadores precisam se preocupar com a sustentabilidade a longo prazo das pilhas de tecnologia. Anos atrás, por exemplo, muitas empresas investiram muito tempo e esforço na criação de aplicativos PowerBuilder (e em outros idiomas desse gênero). O PowerBuilder frequentemente tornava muito fácil a criação de aplicativos de linha de negócios e os desenvolvedores na época eram frequentemente apaixonados por ele. Infelizmente, a comunidade do PowerBuilder quase entrou em colapso deixando as empresas em uma situação em que eles tinham muito código existente em um idioma que ninguém realmente queria usar, onde tinham dificuldade em obter desenvolvedores competentes para manter o código existente e projetos caros e demorados para migrar esses aplicativos para outras pilhas de tecnologia. Os méritos técnicos relativos do PowerBuilder foram vs. Java ou C ++ ou C # ou o que eles migraram naquele momento;
  Linguagens relativamente nichas como Ruby têm o potencial de criar esse tipo de problema legado para empresas que não conseguem prever se o idioma falhará em alguns anos quando as pessoas passarem para a próxima moda ou se ela tem um poder real. . Certamente, você pode atenuar isso apontando que Ruby não depende de uma empresa ou organização, para que ninguém possa decidir que não é mais um produto estratégico para a empresa. Se o seu cliente sofreu uma queimadura no passado por ter aplicativos desenvolvidos em idiomas que se tornaram dores de cabeça nos negócios, você precisará argumentar que o Ruby é mais parecido com o Linux e outras tecnologias de código aberto que floresceram sem uma empresa que os apoie do que os idiomas que possuem. morreu ao longo dos anos.
• Os empregadores desejam consistência no ambiente, portanto, escolher um idioma para um projeto força uma escolha para muitos outros. Mesmo que o Ruby seja tecnicamente ideal para o projeto que você está lançando, você precisa explicar por que é apropriado para todas as outras aplicações que esse cliente precisará desenvolver ou explicar qual combinação de tecnologias você acredita ser apropriada (por exemplo, Ruby for X, outra coisa). para Y). Lidar com tecnologias heterogêneas, no entanto, inevitavelmente se traduz em custos extras para os negócios.

Para iniciantes, você pode direcionar seu cliente aqui para dar uma olhada no ecossistema que existe ao redor do Rails. Você também pode apontar para as startups de sucesso, como LivingSocial, Shopify, 37signals etc. que construíram seus negócios com Ruby e Rails.

Você pode mencionar que grandes empresas como AT&T, SAP e Symantec também estão usando o Rails (todos eles estavam recrutando fortemente na RailsConf no ano passado).

Você pode salientar que uma empresa de traduções tem muito a ganhar usando um idioma / estrutura que torna o suporte a Unicode e o i18n relativamente indolor.

Por fim, acho que você precisa vender a ideia de que poder usar o Rails é um recurso premium que ele obtém ao contratá-lo: "É claro que todos os outros caras estão usando PHP. Mas você tem a oportunidade de ter uma pilha moderna alimentando seu aplicativo . "

No final do dia, também precisa ficar claro que o que ele está comprando no final é a sua habilidade e conhecimento; se ele conhecia tanto as tecnologias da Web do lado do servidor, não precisaria de você. Linguagem e estrutura são decisões de implementação, não requisitos.

PS Não mencione o Twitter. Ainda estamos tentando desfazer o mau PR Rails tirado disso.

Eu explicaria que é basicamente uma escolha entre "Coca-Cola" e "Pepsi". Ambos são amplamente aceitos, ambos têm pessoas que lutam e morrem por cada um, e ambos são perfeitamente adequados. Indique os motivos pelos quais você prefere o RoR.

Ele está falando de pessoas, você está falando de uma linguagem e estrutura. Ele não ouvirá nenhum motivo puramente técnico; portanto, você deve se concentrar no que as pessoas estão fazendo com o idioma . Você pode falar sobre o poder das pessoas no Rails, como é mais fácil para uma pessoa fazer mais do que uma pessoa PHP, mais rápido (se é nisso que você acredita). Você pode perguntar se a prevalência de motoristas da Honda significa que é um carro melhor do que um Rolls Royce, que raramente é visto. Você pode falar sobre o que a comunidade realmente é composta, se há muitos cozinheiros na sopa do módulo (gemas vs. módulos, etc.), se todo mundo tem a síndrome do NIH e assim por diante.

Independentemente disso, ele precisa ser em termos de pessoas, porque ele quer saber que pode substituí-lo. Ajude-o a saber disso, porque ele (provavelmente) não vai querer mudar de qualquer maneira. Sua "decisão especializada" não tem absolutamente nenhuma influência quando ele dá muito menos cuidado ao que uma determinada pessoa sabe. Ele só quer que haja "mais pessoas" que sabem a mesma coisa.

No final do dia, não há vergonha em chamá-lo de blefe. "Tudo bem, vá com PHP. Boa sorte!"

Saliente que o público PHP tem mais membros porque é a menor barreira à entrada e existe há mais tempo. Certifique-se de apontar que comunidades menores têm porcentagens mais altas de programadores que valem a pena contratar, o PHP pode ter 10.000 bons programadores em comparação com 5.000 programadores de rails, mas os programadores de PHP estão ocultos em um bloco de 100.000 em comparação com 20.000 para programadores de rails. (Esses números são constituídos, mas é claro.) Então você precisa explicar que a comunidade realmente não tem uma preferência entre PHP e Rails.

Você não pode usar razões técnicas em uma pessoa não técnica, não pode explicar por que o iPhone é inferior a outros smartphones para alguém que sabe apenas como os telefones são. Você precisa de razões que eles entendam.

Seu cliente contratou você, então, presumivelmente, ele confia nos seus conhecimentos. Explique que diferentes profissionais podem preferir ferramentas diferentes, e sua ferramenta preferida é RoR. Aponte a presença da comunidade e a aceitação da comunidade que existe para o RoR e empresas bem-sucedidas, como a 37signals, para remover a preocupação de que você está recomendando alguma tecnologia misteriosa que ninguém conhece. Saliente que você será mais produtivo usando as ferramentas de sua preferência (reduzindo os custos e melhorando as mudanças no sucesso) e que, se você precisar encontrar mais especialistas em RoR, não será difícil. Se ele for mais técnico, você pode apontar como o RoR pode ser bem-sucedido nas tarefas que ele precisa em comparação com a solução preferida.

Evite repetir o FUD e geralmente depreciar o PHP - se você não é especialista em PHP, há uma alta probabilidade de dizer algo que não é preciso, errado ou altamente controverso, e se o seu cliente descobrir que você está errado, isso pode prejudicar sua credibilidade com ele em outros aspectos.

Seu chefe tem razão. O PHP é muito mais popular do que a codificação RoR em vários sites que se esforçam para acompanhar essas coisas. Por exemplo, consulte http://lang-index.sourceforge.net e http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >. Eu acho que seria tolice ignorar os fatos.

Eu sugiro que você reconheça que ele tem razão e, em seguida, lembre-o de que RoR também tem seguidores fortes. Não faria mal ter alguns links para sites populares criados com o RoR que você pode mostrar a ele.

Afinal, ele está realmente procurando por sua garantia de que está tomando a decisão comercial certa e deseja que a evidência faça o backup. Como diz o velho ditado: "Ninguém nunca atirou flechas neles por recomendar a Microsoft". O mesmo vale para o PHP no desenvolvimento web. Dê a ele fatos sólidos e evite opiniões. Você vai se sair bem.

Traduza suas crenças em termos econômicos quantificáveis ​​(se possível / válido). O fato de o negócio dele ser específico de tradução sugere que o RoR (ou qualquer idioma com suporte multilíngue nativo) é tecnicamente superior ao PHP - mas isso deve ser compensado pelos custos de desenvolvedores e provisionamento de servidores associados às respectivas plataformas. É provável que os negócios deles durem mais do que o seu relacionamento; eles vão querer garantir que estão lançando as bases certas.

IME, admitir os contras (e também os profissionais) de sua estratégia é mais convincente do que qualquer quantidade de evangelismo - sugere que você está mais interessado em resolver o problema deles do que em usar o seu martelo favorito.

Seu cliente pode ter um ponto válido. Oferta e demanda afetam os preços. Se o suprimento de desenvolvedores com uma habilidade específica na área geográfica dos clientes for baixo, o preço para a manutenção de software que exija esse conjunto de habilidades mais raro poderá aumentar mais ao longo do tempo do que se o software fosse desenvolvido usando uma linguagem mais popular para a qual havia uma quantidade significativamente maior pool local de desenvolvedores qualificados. Portanto, a questão também poderia ser de gerenciamento de risco de custos a longo prazo.

Quando tenho um cliente que deseja usar uma ferramenta específica porque é "padrão do setor", tem um "consenso" ou é "o que todo mundo está usando", indico a eles que todos esses termos são códigos de "média do setor". " Ou seja, o que a maioria das outras pessoas na área está fazendo. O negócio "médio" falha. Escolha suas ferramentas com base nos requisitos do trabalho, não no que todo mundo está fazendo. Ser menos programadores de RoR não importa se o sistema não precisa de tantos ajustes quando é feito.

Certamente esta é uma decisão de negócios para vocês dois .

Para você, as perguntas são:

• Quanto me custará implementar os requisitos de meus clientes usando o Ruby on Rails?
• Quanto me custará implementá-los em PHP?
• Que valor eu atribuo ao usar meu ambiente preferido?

Para o seu cliente, a questão é

• Quanto os benefícios percebidos do PHP sobre o Ruby on Rails valem para mim?

Se você fornecer ao seu cliente uma cotação com um preço para implementação usando Ruby on Rails e um preço separado para implementação usando PHP , ambos com base nas respostas às suas próprias perguntas, seu cliente poderá fazer seu próprio julgamento sobre se os o custo agora vale a pena para possíveis economias futuras.

Isso não é diferente para eles tomarem uma decisão sobre se devem ou não conceder o contrato a você, ou a outro desenvolvedor que o implementaria usando o PHP, conforme solicitado.

A melhor analogia do mundo real que posso encontrar é "Você compraria um Ford em vez de um BMW apenas porque a participação de mercado do BMW é menor?".

Por fim, os programadores PHP custam metade do custo dos programadores Rails, e se você encontrar um emprego melhor amanhã? Seu chefe estaria totalmente ferrado e lutando para encontrar um desenvolvedor do Rails, e isso leva tempo e dinheiro, já que os desenvolvedores do Rails estão em falta.

A única razão pela qual seu chefe concordaria é se isso o deixaria mais feliz e, ao permitir que você tomasse as decisões desejadas, você ficaria mais feliz trabalhando para ele e, portanto, seria mais produtivo.