¿Cómo puedo defender a Ruby on Rails contra la opinión no técnica de los clientes?

Mi cliente, propietario de un negocio de traducciones, me dijo que había estado leyendo sobre Ruby on Rails y me dijo que " hay más tipos de PHP por ahí " y " parece que la comunidad lo prefiere ". ¿Qué le diría usted, como ingeniero de software y profesional independiente, al cliente para lograr estos objetivos:

• Vender
• Hacerle ver que la tecnología es mi decisión experta y que Rails es tan bueno o mejor que PHP (+ cualquier marco) para este proyecto en particular.

ACTUALIZACIÓN: ¡Gracias a todos por las sugerencias! Mañana tengo otra reunión con él, veamos cómo va, actualizaré nuevamente :)

ACTUALIZACIÓN 2: Finalmente le dije que leyera este hilo y el resultado ha sido fantástico: me dio el proyecto y vamos a comenzar ahora mismo. Gracias a todos por la ayuda, tienen cerveza gratis a mi cargo si nos vemos algún día :)

Por cierto: aprendí la lección: sé lo más transparente posible, porque si crees en ti mismo y en tu trabajo, no hay duda de que te comprometerás lo suficiente como para vencerte.

Saludos

Creo que comete un error al suponer que la elección de la tecnología es una decisión puramente técnica.

El cliente parece estar preocupado por las implicaciones comerciales de elegir una tecnología en particular. Dado eso, debe presentar un caso que aborde sus inquietudes comerciales al menos tan fuertemente como sus opiniones tecnológicas.

• Los empleadores tienen que reclutar de un área geográfica particular y ciertas áreas tienen comunidades particularmente activas en torno a pilas de tecnología particulares. Si está comenzando un negocio en el noroeste del Pacífico de los EE. UU., Por ejemplo, habría un fuerte sesgo hacia una pila de Microsoft simplemente porque Microsoft es muy influyente en el área, por lo que la mayoría de los desarrolladores que desea contratar tener experiencia con esa pila. Otras regiones geográficas tienen perfiles muy diferentes.
  Hable con su cliente y comprenda por qué y cómo formó su opinión. Quizás leyó que la comunidad PHP local es particularmente activa o que la universidad local enseña mucho PHP y no Ruby. Tal vez tiene un desarrollador de confianza al que puede llamar para emergencias ocasionales que es un PHP pro y un neófito Ruby. Por supuesto, también es posible que esté usando métricas deficientes como la cantidad de anuncios de trabajo o currículums que mencionan varias palabras clave.
• Los empleadores deben preocuparse por la sostenibilidad a largo plazo de las pilas de tecnología. Hace años, por ejemplo, muchas empresas invirtieron una gran cantidad de tiempo y esfuerzo en desarrollar aplicaciones PowerBuilder (y otros idiomas de ese género). PowerBuilder a menudo facilitó la creación de una línea de aplicaciones comerciales y los desarrolladores en ese momento a menudo estaban muy enamorados de ella. Desafortunadamente, la comunidad PowerBuilder se derrumbó más o menos, dejando a las empresas en una situación en la que tenían mucho código existente en un idioma que nadie realmente quería usar, donde tenían dificultades para lograr que los desarrolladores competentes mantuvieran el código existente y los proyectos costosos y que llevaban mucho tiempo. para migrar esas aplicaciones a otras pilas de tecnología. Los méritos técnicos relativos de PowerBuilder fueron vs. Java o C ++ o C # o lo que sea que migraron en ese momento;
  Los lenguajes relativamente específicos como Ruby tienen el potencial absoluto de crear este tipo de problemas heredados para las empresas que no pueden predecir si el lenguaje desaparecerá en unos años cuando las personas pasen a la próxima moda o si tienen un verdadero poder de permanencia. . Ciertamente, puede mitigar esto señalando que Ruby no depende de una compañía u organización, por lo que nadie puede decidir que ya no es un producto estratégico para la compañía. Si su cliente se ha quemado en el pasado al tener aplicaciones desarrolladas en idiomas que se convirtieron en dolores de cabeza comerciales, necesitará argumentar que Ruby se parece más a Linux y otras tecnologías de código abierto que florecieron sin una compañía que los respalde que los idiomas que tienen desapareció con los años.
• Los empleadores quieren consistencia en el entorno, por lo que elegir un idioma para un proyecto obliga a elegir otros. Incluso si Ruby es técnicamente ideal para el proyecto que está presentando, debe explicar por qué es apropiado para cualquier otra aplicación que este cliente necesite desarrollar o explicar qué combinación de tecnologías cree que es apropiada (es decir, Ruby para X, algo más para y). Sin embargo, tratar con tecnologías heterogéneas se traduce inevitablemente en un costo adicional para el negocio.

Para empezar, puede dirigir a su cliente aquí para ver el ecosistema que existe alrededor de Rails. También puede señalar las startups exitosas como LivingSocial, Shopify, 37signals, etc. que construyeron sus negocios con Ruby y Rails.

Puede mencionar que empresas masivas como AT&T, SAP y Symantec también están utilizando Rails (todas estaban reclutando en RailsConf el año pasado).

Puede señalar que un negocio de traducciones tiene mucho que ganar al usar un lenguaje / marco que hace que el soporte de Unicode sea relativamente sencillo.

En última instancia, creo que debes vender la idea de que poder usar Rails es una característica premium que obtiene al contratarte: "Por supuesto, todos esos otros tipos están usando PHP. Pero tienes la oportunidad de tener una pila moderna que alimente tu aplicación ".

Al final del día, también debe quedar claro que lo que finalmente está comprando es su habilidad y experiencia; si él fuera tan conocedor de las tecnologías web del lado del servidor, no lo necesitaría. El lenguaje y el marco son decisiones de implementación, no requisitos.

PD: no menciones Twitter. Todavía estamos tratando de deshacer las malas relaciones públicas que Rails tomó de eso.

Explicaría que es básicamente una opción de "Coca-Cola" versus "Pepsi". Ambos son ampliamente aceptados, ambos tienen personas que lucharán y morirán por cada uno, y ambos son perfectamente adecuados. Señale las razones por las que prefiere RoR.

Él está hablando de personas, tú estás hablando de un lenguaje y un marco. No escuchará ningún motivo que sea puramente técnico, por lo que debe centrarse en lo que la gente está haciendo con el idioma . Puedes hablar sobre el poder de las personas bajo Rails, cómo es más fácil para una persona hacer más que una persona PHP, más rápido (si esto es lo que crees). Puede preguntar si la prevalencia de los conductores de Honda significa que es un automóvil mejor que un Rolls Royce, que rara vez se ve. Puede hablar sobre de qué está compuesta realmente la comunidad, si hay demasiados cocineros en la sopa de módulos (gemas versus módulos, etc.), si todos tienen el síndrome NIH, etc.

De todos modos, debe ser en términos de personas porque quiere saber que puede reemplazarlo. Ayúdelo a saber esto, porque él (probablemente) no querrá cambiar de todos modos. Su "decisión experta" no tiene absolutamente ninguna relación cuando le da mucho menos cuidado a lo que una persona sabe. Él solo quiere que haya "más personas" que sepan lo mismo.

Al final del día, no hay vergüenza en llamarlo farol. "Bien, ve con PHP. ¡Buena suerte!"

Señale que la multitud de PHP tiene más miembros porque es la barrera de entrada más baja y ha existido por más tiempo. Asegúrese de señalar que las comunidades más pequeñas tienen porcentajes más altos de programadores que vale la pena contratar, PHP puede tener 10,000 buenos programadores en comparación con 5,000 programadores de rieles, pero los programadores de PHP están ocultos en un bloque de 100,000 en comparación con 20,000 para programadores de rieles. (Estos números están formados, pero se entiende). Luego, debe explicar que la comunidad realmente no tiene preferencia entre PHP y Rails.

No puede usar razones técnicas en una persona no técnica, no puede explicar por qué el iPhone es inferior a otros teléfonos inteligentes a alguien que solo sabe cómo son los teléfonos. Necesitas razones que ellos entiendan.

Su cliente lo contrató, por lo que presumiblemente confía en su experiencia. Explique que diferentes profesionales pueden preferir diferentes herramientas, y su herramienta preferida es RoR. Señale la presencia de la comunidad y la aceptación de la comunidad que existe para RoR y compañías exitosas como 37signals que lo usan, para eliminar su preocupación de que está recomendando alguna tecnología arcana que nadie más que usted conoce. Señale que será más productivo utilizando las herramientas que prefiera (reduciendo así sus costos y mejorando sus cambios en el éxito) y que si alguna vez necesita encontrar más expertos en RoR, no será difícil hacerlo. Si es más técnico, puede señalar cómo RoR puede tener éxito en las tareas que necesita, en comparación con su solución preferida.

Evite repetir FUD y, en general, menospreciar a PHP: si no es un experto en PHP, existe una alta probabilidad de que diga algo que no sea exacto, incorrecto o muy controvertido, y si su cliente se entera de que estaba equivocado, podría perjudicarlo. tu credibilidad con él en otros aspectos.

Tu jefe tiene un punto. PHP es mucho más popular que RoR según varios sitios que se esfuerzan por realizar un seguimiento de tales cosas. Por ejemplo, consulte http://lang-index.sourceforge.net y http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >. Creo que sería una tontería ignorar los hechos.

Le sugiero que reconozca que él tiene un punto y luego le recuerde que RoR también tiene muchos seguidores. No estaría de más tener algunos enlaces a sitios populares creados con RoR que pueda mostrarle.

Después de todo, él realmente está buscando su seguridad de que está tomando la decisión comercial correcta y quiere que la evidencia lo respalde. Como dice el viejo refrán: "Nunca se les dispararon flechas por recomendar a Microsoft". Lo mismo ocurre con PHP en el desarrollo web. Dale hechos sólidos y evita opiniones. Lo harás bien

Traduce tus creencias en términos económicos cuantificables (si es posible / válido). El hecho de que su negocio sea específico para la traducción sugiere que RoR (o cualquier idioma con soporte multilingüe nativo) es técnicamente superior a PHP, pero esto debe compensarse con los costos de los desarrolladores y el aprovisionamiento de servidores asociados con esas plataformas respectivas. Es probable que su negocio dure más que su relación, querrán asegurarse de que están sentando las bases correctas.

IME, admitir los inconvenientes (así como los pros) de su estrategia es más convincente que cualquier cantidad de evangelismo: sugiere que está más interesado en resolver su problema que usar su martillo favorito.

Su cliente podría tener un punto válido. La oferta y la demanda afectan los precios. Si la oferta de desarrolladores con una habilidad particular en el área geográfica de los clientes es baja, el precio por mantener el software que requiere un conjunto de habilidades más raro podría aumentar más con el tiempo que si el software se desarrollara usando un lenguaje más popular para el que había un nivel significativamente mayor grupo local de desarrolladores calificados. Por lo tanto, el problema también podría ser la gestión del riesgo de costos a largo plazo.

Cuando tengo un cliente que quiere usar una herramienta en particular porque es "estándar de la industria", tiene un "consenso" o es "lo que todos usan", les señalo que todos esos términos son código para "promedio de la industria". " Es decir, lo que están haciendo la mayoría de las otras personas en el área. El negocio "promedio" falla. Elija sus herramientas en función de los requisitos del trabajo, no de lo que todos los demás están haciendo. Que haya menos programadores de RoR no importa si el sistema no necesita tantos ajustes cuando se hace.

Seguramente esta es una decisión comercial para los dos .

Para ti las preguntas son:

• ¿Cuánto me costará implementar los requisitos de mis clientes usando Ruby on Rails?
• ¿Cuánto me costará implementarlos en PHP?
• ¿Qué valor le doy al usar mi entorno preferido?

Para su cliente, la pregunta es

• ¿Cuánto valen para mí los beneficios percibidos de PHP sobre Ruby on Rails?

Si le proporciona a su cliente una cotización con un Precio para la implementación usando Ruby on Rails y un Precio separado para la implicación usando PHP , ambos basados ​​en las respuestas a sus propias preguntas, entonces su cliente puede hacer su propio juicio sobre si el extra El costo ahora vale los posibles ahorros futuros.

Esto no es diferente a que tomen una decisión sobre si deben entregarle el contrato a usted u otro desarrollador que lo implementaría utilizando PHP según lo solicitado.

La mejor analogía del mundo real que se me ocurre es "¿Compraría un Ford en lugar de un BMW solo porque la cuota de mercado de BMW es menor?".

En última instancia, los programadores de PHP son la mitad del costo de los programadores de Rails, ¿y usted si encuentra un mejor trabajo mañana? Su jefe estaría totalmente jodido y luchando por encontrar un desarrollador de Rails, y eso lleva tiempo y dinero ya que los desarrolladores de Rails son escasos.

La única razón por la que su jefe estaría de acuerdo es si siente que lo haría más feliz a USTED, y eso al permitirle tomar las decisiones que desea, sería más feliz trabajando para él y, por lo tanto, sería más productivo.