如何针对客户的非技术意见抗辩Ruby on Rails？

我的客户是翻译企业所有者，他刚刚告诉我他一直在阅读有关Ruby on Rails的信息，并告诉我“ 那里有更多的PHP专家 ”，“ 似乎社区更喜欢它 ”。作为软件工程师和自由职业者，您会对客户说些什么，以实现这些目标：

• 卖
• 让他知道技术是我的专家决定，并且Rails在这个特定项目上比PHP（或其他框架）好或好。

更新：谢谢大家的建议！明天我将再与他见面，让我们看看进展如何，我将再次更新:)

更新2：最后，我告诉他阅读此主题，结果非常棒：他给了我这个项目，我们现在就开始。谢谢大家的帮助，如果有一天，您可以免费喝啤酒：)

顺便说一句：我学到了一个教训：尽可能透明，因为如果您相信自己和您的工作，那么毫无疑问会妥协地击败您。

问候

我认为您在选择技术只是纯粹的技术决定时犯了一个错误。

客户似乎担心选择特定技术对业务的影响。鉴于此，您需要提出一个解决他的业务问题的案例，至少要与您的技术意见一样重要。

• 雇主必须从特定的地理区域招募人才，并且某些区域的特定技术堆栈周围的社区特别活跃。例如，如果您要在美国西北太平洋地区开展业务，则对Microsoft堆栈会有强烈的偏见，这仅仅是因为Microsoft在该地区具有很大的影响力，因此您打算雇用的大多数开发人员都会有该堆栈的经验。其他地理区域具有非常不同的轮廓。
  与您的客户交谈，了解他为什么以及如何形成他的意见。也许他读到当地的PHP社区特别活跃，或者当地的大学教了很多PHP而没有Ruby。也许他有一个值得信赖的开发人员，可以召集他来应对偶尔发生的紧急情况，例如PHP专业人士和Ruby新手。当然，他也可能使用的指标很差，例如招聘广告或提及各种关键字的简历的数量。
• 雇主必须关注技术堆栈的长期可持续性。例如，几年前，许多公司投入了大量时间和精力来构建PowerBuilder应用程序（以及该类型的其他语言）。PowerBuilder经常使构建业务应用程序变得非常容易，而当时的开发人员通常对此非常着迷。不幸的是，PowerBuilder社区或多或少地崩溃了，使公司陷入了许多现有语言无法使用的语言的情况下，他们很难让有能力的开发人员维护现有代码和昂贵，耗时的项目将这些应用迁移到其他技术堆栈。PowerBuilder的相对技术优势是Java，C ++或C＃或当时迁移到的任何东西。
  相对而言，像Ruby这样的利基语言绝对有潜力为那些无法预测这种语言在几年内走向人们流行或是否具有持久力的公司逐渐消失的公司带来此类遗留问题。 。您可以通过指出Ruby不依赖一个公司或组织来减轻这种情况，因此没有人可以断定它不再是该公司的战略产品。如果您的客户过去曾因使用导致业务头痛的语言开发应用程序而被烧掉，您需要证明Ruby更像是Linux和其他没有公司支持的开源技术蓬勃发展的语言。多年来消失了。
• 雇主希望环境保持一致，因此为一个项目选择一种语言会迫使其他许多人选择。即使Ruby在您要推广的项目上在技术上是理想的，您也必须说明为什么该客户需要开发的每个其他应用都合适，或者说明您认为合适的技术组合（例如Ruby for X，其他一些东西）对于Y）。但是，处理异构技术不可避免地会转化为业务的额外成本。

首先，您可以在这里指导您的客户，以了解Rails周围的生态系统。您也可以指出成功的创业公司，例如LivingSocial，Shopify，37signals等，它们都是通过Ruby和Rails建立业务的。

您可以提到，AT＆T，SAP和Symantec等大型企业也在使用Rails（去年它们都在RailsConf上大量招聘）。

您可以指出，通过使用使Unicode支持和i18n相对轻松的语言/框架，翻译业务将大有收获。

最终，我认为您需要推销能够使用Rails是他通过雇用您而获得的一项高级功能：“当然，其他所有人都在使用PHP。但是您有机会拥有一个现代堆栈来为您的应用程序提供动力。”

归根结底，还需要明确的是，他最终购买的是您的技能和专长。如果他对服务器端Web技术非常了解，那么他就不需要您了。语言和框架是实施决策，不是要求。

PS不要提及Twitter。我们仍在努力消除不良的PR Rails。

我会解释说，这基本上是“可乐”与“百事可乐”的选择。两者都被广泛接受，都有可以为每个人而战和死亡的人，而且他们两个都非常合适。指出您更喜欢RoR的原因。

他在谈论人，在谈论一种语言和框架。他不会听到任何纯粹出于技术原因的原因，因此您应该关注人们在使用该语言时所做的事情。您可以谈论在Rails下的人力资源，一个人比PHP的人更容易做更多的事情，并且更快（如果您相信的话）。您可能会问，本田车手的盛行是否意味着它比劳斯莱斯汽车（这是鲜见的）更好。您可以讨论社区的实际组成，模块汤中是否有太多厨师（宝石与模块等），每个人是否患有NIH综合征等等。

无论如何，这需要以人为本，因为他想知道他可以代替您。帮助他知道这一点，因为他（可能）无论如何都不想离开。当您对某个给定的人所知道的事情的关心大大减少时，您的“专家决定”绝对没有任何意义。他只希望有更多了解同一件事的人。

归根结底，喊他的虚张声势是没有耻辱的。“好吧，使用PHP。祝您好运！”

指出PHP人群拥有更多成员，因为它的进入门槛最低，而且存在时间更长。请确保指出，较小的社区具有值得雇用的程序员比例，PHP可能有10,000个优秀程序员，而5,000个Rails程序员却如此，但是PHP程序员却藏在100,000个区块中，而Rails程序员则为20,000个。（这些数字组成了，但是很清楚。）然后，您需要解释一下，社区实际上在PHP和Rails之间没有偏爱。

您不能使用非技术人员的技术原因，也不能向只知道手机外观​​的人解释为什么iPhone不如其他智能手机。您需要他们理解的理由。

您的客户雇用了您，因此大概他相信您的专业知识。说明不同的专业人员可能会喜欢不同的工具，而您偏爱的工具恰好是RoR。指出社区的存在以及RoR和37signals这样的成功公司正在使用的社区，以及社区对社区的认可，从而消除了他对您推荐的某些未知技术的神秘技术的担忧。指出您将使用自己喜欢的工具提高工作效率（从而降低他的成本并改善他的成功改变），并且，如果您需要找到更多的RoR专家，这将不是一件容易的事。如果他的技术水平更高，那么您可能会指出RoR如何在他需要的任务中取得成功，这与他的首选解决方案相比还是要不少。

避免重复FUD并一般贬低PHP-如果您不是PHP专家，那么您很有可能会说出不准确，错误或极具争议性的内容，并且如果您的客户得知您错了，那可能会伤害您您在其他方面对他的信誉。

你的老板有道理。与RoR编码相比，PHP在努力跟踪此类事件的多个站点上更为流行。例如，请参阅http://lang-index.sourceforge.net和http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >。我认为忽略事实是愚蠢的。

我建议您承认他有观点，然后提醒他RoR也有很强的追随者。可以显示指向RoR的流行站点的链接不会有什么坏处。

毕竟，他确实在寻找您的保证，以确保他做出了正确的业务决策，并希望有证据支持该决策。俗话说：“没人推荐他们推荐微软。” Web开发中的PHP也是如此。给他扎实的事实，避开意见。你会做的很好。

将您的信念转化为可量化的经济术语（如果可能/有效）。他的业务专门针对翻译，这一事实表明RoR（或任何具有本地多语言支持的语言）在技术上优于PHP-但这必须抵消与这些平台相关的开发人员和服务器配置的成本。他们的业务持续的时间可能长于您的关系，他们希望保证他们正在奠定正确的基础。

IME承认，您的策略的弊端（以及优点）比任何形式的传播都更具说服力-这表明您比使用自己喜欢的锤子更感兴趣于解决他们的问题。

您的客户可能有一个有效的观点。供求影响价格。如果在客户地理区域内具有特定技能的开发人员的供应量较低，则与使用具有更大范围的流行语言的软件开发相比，要求使用稀有技能的软件的维护成本可能会随着时间的推移而增加更多。当地技术熟练的开发人员。因此，该问题也可能是长期成本风险管理之一。

当我有一个客户因为其“行业标准”而想要使用特定工具，具有“共识”或“每个人都在使用”时，我向他们指出，所有这些术语都是“行业平均水平”的代码。 ” 也就是说，该地区大多数其他人正在做什么。“平均”业务失败。根据工作要求而不是其他所有人的工作来选择工具。RoR编程人员的减少与系统完成时不需要的修补工作无关紧要。

当然，这对你们俩都是商业决策。

对您来说，问题是：

• 使用Ruby on Rails来实现客户需求会花多少钱？
• 在PHP中实现它们要花费多少钱？
• 使用首选环境对我有什么价值？

对于您的客户，问题是

• PHP对Ruby on Rails的PHP带来的好处对我来说有多少价值？

如果您为客户提供使用Ruby on Rails实施的价格和使用PHP实施的单独价格的报价，这两者都是基于您自己问题的答案，那么您的客户可以自行判断是否需要额外的报价。现在的成本值得将来节省。

这与他们决定是应将合同授予您还是应按要求使用PHP实现该合同的其他开发人员一样。

我能想到的最真实的比喻是：“仅仅因为宝马的市场份额较小，会购买福特而不是宝马吗？”。

最终，PHP程序员的成本是Rails程序员的一半，如果明天找到更好的工作，该怎么办？您的老板会全神入迷地争先恐后地寻找Rails开发人员，这需要时间和金钱，因为Rails开发人员供不应求。

老板会同意的唯一原因是，如果这会让您感到更快乐，并且允许您做出自己想要的决定，那么为他工作会更快乐，从而提高工作效率。