顧客の技術的意見ではなく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が1つの会社や組織に依存しているわけではないため、Rubyがもはや会社の戦略的な製品ではないと判断できないことを指摘することで、これを緩和できます。過去にビジネス上の頭痛の種になった言語で開発されたアプリケーションを使用して顧客が燃え上がった場合、RubyはLinuxや他のオープンソーステクノロジーに似ていると主張する必要があります。長年にわたって死にました。
• 雇用主は環境の一貫性を求めているため、1つのプロジェクトで言語を選択すると、他の多くのプロジェクトで選択を余儀なくされます。提案しているプロジェクトにRubyが技術的に理想的であっても、この顧客が開発する必要がある他のすべてのアプリケーションに適切である理由を説明するか、適切と思われるテクノロジーの組み合わせを説明する必要があります（X向けRubyなど） Yについて）。ただし、異種技術に対処することは、必然的にビジネスの追加コストにつながります。

手始めに、Railsの周りに存在するエコシステムを見るために、ここにクライアントを導くことができます。また、RubyとRailsでビジネスを構築したLivingSocial、Shopify、37signalsなどの成功したスタートアップを紹介することもできます。

AT＆T、SAP、Symantecなどの大企業もRailsを使用していることに言及できます（これらはすべて、昨年RailsConfで大々的に採用されていました）。

Unicodeビジネスをサポートし、i18nを比較的簡単にする言語/フレームワークを使用することで、翻訳ビジネスに多くのメリットがあることを指摘できます。

もちろん、すべてのこれらのうち、」：最終的に、私はあなたがRailsのを使用することができるというという考えを売却する必要があると思うが、彼はあなたを雇って取得するプレミアム機能で、他の人がPHPを使用している。しかし。あなたは持っているの機会持つ近代的なアプリケーションに電力を供給スタックを」

結局のところ、彼が最終的に購入するのはあなたのスキルと専門知識であることも明確にする必要があります。もし彼がサーバーサイドのウェブ技術に精通していれば、彼はあなたを必要としないでしょう。言語とフレームワークは実装の決定であり、要件ではありません。

PS Twitterについては言及しないでください。私たちはまだ、そこから得た悪いPR Railsを取り消そうとしています。

基本的には「コークス」と「ペプシ」の選択だと説明します。どちらも広く受け入れられており、どちらもそれぞれのために戦って死ぬ人々を持ち、どちらも完全に適切です。RoRを好む理由を指摘してください。

彼は人々について話している、あなたは言語とフレームワークについて話している。彼は純粋に技術的な理由を聞くつもりはないので、あなたは人々がその言語で何をしているのかに集中すべきです。Railsの下での人の力、ある人がPHPの人よりも簡単に、より速く（これがあなたが信じているのであれば）について話すことができます。ホンダのドライバーの普及は、めったに見られないロールス・ロイスよりも優れた車であるかどうかを尋ねることができます。コミュニティが実際に何を構成しているか、モジュールスープにコックが多すぎるかどうか（宝石とモジュールなど）、誰もがNIH症候群かどうかなどについて話すことができます。

とにかく、彼はあなたに取って代わることができることを知りたいので、それは人々の観点からする必要があります。彼は（おそらく）とにかく乗り換えたくないので、これを知るのを助けてください。あなたの「専門家の決定」は、彼が与えられた人が知っていることに対してあまり注意を払わない場合には絶対に関係ありません。彼はただ同じことを知っている「より多くの人々」がいることを望んでいます。

一日の終わりに、彼のブラフを呼ぶことに恥はありません。「ファイン、PHPを使用してください。幸運を祈ります！」

PHPの観客はより多くのメンバーを持っていることを指摘してください。これは、入場に対する最も低い障壁であり、以前から存在しているためです。小規模なコミュニティには採用する価値のあるプログラマーの割合が高く、PHPには5,000人のレールプログラマーと比較して10,000人の優秀なプログラマーがいる可能性がありますが、PHPプログラマーはレールプログラマーの20,000人と比較して100,000のブロックに隠れていることに注意してください。（これらの数字は構成されていますが、それが意味を成します。）それから、コミュニティはPHPとRailsの間の好みを本当に持っていないことを説明する必要があります。

非技術者には技術的な理由を使用することはできません。iPhoneが他のスマートフォンよりも劣っている理由を、電話の外観だけを知っている人に説明することはできません。彼らが理解する理由が必要です。

あなたの顧客はあなたを雇ったので、おそらく彼はあなたの専門知識を信頼しています。さまざまな専門家がさまざまなツールを好む場合があり、あなたの好むツールはたまたまRoRであることを説明します。コミュニティの存在と、RoRおよびそれを使用する37signalsのような成功した企業に存在するコミュニティの受け入れを指摘し、誰も知らない難解な技術を推奨しているという彼の懸念を取り除きます。好みのツールを使用することで生産性が向上するため（コストを削減し、成功時の変更を改善する）、RoRの専門家をさらに見つける必要がある場合は難しくありません。彼がより技術的なものであれば、彼が好むソリューションと比較して、彼が必要とするタスクでRoRがどのように成功するかを指摘できます。

FUDを繰り返したり、一般的にPHPを軽parしたりすることは避けてください。PHPの専門家でない場合は、正確ではない、間違っている、または非常に物議を醸すものを言う可能性が高く、他の面での彼に対するあなたの信頼性。

あなたの上司にはポイントがあります。PHPは、こうしたことを追跡しようとするいくつかのサイトでRoRコーディングよりもはるかに人気があります。たとえば、http：//lang-index.sourceforge.netおよびhttp://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >を参照してください。事実を無視するのは愚かなことだと思います。

彼にポイントがあることを認め、RoRにも強い支持者があることを思い出してください。RoRで構築された人気のあるサイトへのリンクをいくつか表示して、彼に見せることは問題ありません。

結局のところ、彼は本当に彼が正しいビジネス上の意思決定をしており、それを裏付ける証拠を望んでいるというあなたの保証を探しています。古いことわざにあるように、「Microsoftを推薦するために矢を放った人は誰もいなかった」。Web開発のPHPについても同様です。彼に堅実な事実を与え、意見を避けてください。大丈夫です。

あなたの信念を定量化可能な経済用語に変換します（可能な場合/有効な場合）。彼のビジネスが翻訳固有であるという事実は、RoR（またはネイティブの多言語サポートを備えた任意の言語）が技術的にPHPより優れていることを示唆していますが、これはそれぞれのプラットフォームに関連する開発者とサーバープロビジョニングのコストと相殺する必要があります。彼らのビジネスはあなたの関係よりも長く続く可能性が高く、彼らは彼らが正しい基盤を築いているという安心感を望むでしょう。

IMEは、あなたの戦略の短所（および長所）を認めることは、伝道よりも説得力があります。それは、お気に入りのハンマーを使用するよりも、問題を解決することに関心があることを示唆しています。

顧客は有効なポイントを獲得できます。需要と供給は価格に影響します。顧客の地理的領域で特定のスキルを持つ開発者の供給が少ない場合、まれなスキルセットを必要とするソフトウェアを維持するための価格は、ソフトウェアが非常に大きな人気のある言語を使用して開発された場合よりも長くなる可能性があります熟練した開発者のローカルプール。したがって、この問題は長期的なコストリスク管理の1つである可能性もあります。

「業界標準」、「コンセンサス」、または「誰もが使用しているもの」であるため、特定のツールを使用したいクライアントがある場合、これらの用語はすべて「業界平均」のコードであると指摘します。 」つまり、この地域の他のほとんどの人々がしていることです。「平均的な」ビジネスは失敗します。他の全員が行っていることではなく、ジョブの要件に基づいてツールを選択してください。RoRプログラマーの数が少なくても、システムが完了した時点でシステムをいじり回す必要がないかどうかは関係ありません。

確かに、これはあなたとあなたの両方にとってのビジネス上の決定です。

質問は次のとおりです。

• Ruby on Railsを使用して顧客の要件を実装するには、どれくらいの費用がかかりますか？
• それらをPHPで実装するにはどれくらいの費用がかかりますか？
• 好みの環境を使用することにはどのような価値がありますか？

お客様の質問は

• PHPがRuby on Railsよりも優れていると感じる価値はどれくらいありますか？

あなたと二重引用符を使用して顧客に提供する場合はRuby on Rails使用して実装のための価格および個別のPHPを使用してimplmentationための価格を、両方のあなた自身の質問に対する回答に基づいて、その後、あなたの顧客が作ることができ、自分の余分か否かの判定コールを現在のコストは、将来的に節約できる価値があります。

これは、彼らがあなたに契約を与えるべきか、または要求に応じてPHPを使用してそれを実装する別の開発者に契約を与えるべきかを決定する彼らと違いはありません。

私が思いつくことのできる最高の現実世界の類推は、「BMWの市場シェアが小さいという理由だけで、BMWではなくフォードを買うでしょうか？」です。

最終的に、PHPプログラマーはRailsプログラマーの半分のコストであり、明日より良い仕事を見つけたらどうしますか？あなたの上司はRails開発者を見つけるために完全にねじ込まれ、急いでいるでしょう。そして、Rails開発者が不足しているので、それは時間とお金がかかります。

上司がそれに同意する唯一の理由は、それがあなたを幸せにするだろうと感じている場合、そしてあなたが望む意思決定を行うことにより、あなたが彼のために働いて幸せになり、それにより生産性が上がるということです。