同僚/利害関係者に新しいテクノロジーを試すようにどのように説得しますか？
新しいテクノロジーの採用に関して非常に保守的な同僚、マネージャー、利害関係者がいます。私はその理由を完全に理解しています。Java、MySQL/Postgresなどに関する多くの社内専門知識があり、それらは十分に確立されており、多くの優れたサポートがあります。
しかし、テクノロジーは進化し、時にはより新しいテクノロジーが今日のタスクにより適している場合もあります。たとえば、Python + Numpyのようなもので重い数値処理を行うことは理にかなっています。いくつかの種類の単純なWebサイトは、Ruby/Railsでの実装がより高速で簡単です。 1日に数百ギガバイトのログを処理することは、Hadoop M-Rアーキテクチャに適しています。
しかし、私は新しいテクノロジーを導入することに強い抵抗があると思うときでさえ、多くの抵抗に遭遇します。最近のプロジェクトでは、サーバー側の重いJSPではなく、重いJavaScriptのフロントエンドとWebサービスを使用するなど、細かいところまで抵抗が及んでいます。最も一般的な反対意見は、私たちには技術に関する重要な専門知識がないため、自分でそれを行うことができない場合、それを維持することができないということです。
この種の異議を克服するために、このような人々とどのように協力しますか？
その証拠は、彼らが言うように、プリンにあります。場合によっては、サンプルの実装を行い、それに基づいてケースを作成する必要があります。あなたはそれを実証する必要があります：
- 問題は何か新しいものを使用して解決する方が良い
- ソリューションは維持が簡単です
- 学習曲線は最小限です
- お金は時間を節約して節約されます
- 新しいテクノロジーには、小さいながらも安定していて役立つコミュニティがあります
- これまでになかった新しい可能性が存在する
ハードデータを表示するのに少し時間がかかると、少なくとも、技術的なメリットに基づいて、新しいまたはエッジの効いた何かの採用が、先入観よりも低下したことがわかります。妥協するだけかもしれません。おそらく、あなたはこのプロジェクトにHadoopを使用しないでしょうが、彼らがプレイして触ることができるような方法で人々の前にそれを置くことは、それを将来のプロジェクトの候補にするかもしれません。
あなたが言ったように、これらのことは時間がかかり、成熟度とサポートの可用性の基準は非常に重要な考慮事項です。それでも、ハードデータで却下できる先入観が多ければ多いほど、可能性は高くなります。
更新
余談ですが、このアプローチにより、最近、Memcacheと一時テーブルの組み合わせの代わりにRedisを使い始めました。私はシンプルなメッセージングシステムを作成し、数分以内にそれをデモンストレーションしました。これは、リソースの使用とメンテナンスの点で、はるかに大きく、遅く、高価なものに取って代わりました。
これは、私が表現したかった利点の上昇を示し、他の開発者もそれを試してみたいという好奇心をかきたてました。注：Redisは実際にはnewまたは最新版ではありませんが、newです-）多くの人に。
最初に物事を彼らの視点から見てみましょう。
- 実際、さまざまなテクノロジーを使用することにはリスクがあることを認識してください。
- 追加のコストがあることを認識してください（トレーニング、ソフトウェア、従業員が複数の帽子をかぶることができ、コードを簡単に再利用できないためにかかるコスト）。
次に、特定のテクノロジーを使用することのリスクとコストが、そのテクノロジーが製品にもたらすメリットと節約よりも重要であることを客観的に実証できることを確認してください。最良の方法の1つは、小さなパイロット変更/プログラムを使用することです。新しい機能がある場合は、RubyパイロットまたはJavascriptパイロットの場合を想定してください。従来の方法で記述された同じ部分と結果を比較してください。理想的には、結果は一方向に表れますまたはその他。
そして、これらの新しい技術の半減期は何ですか？
上級開発者が経験したことの一部は、テクノロジーが行き来し、長生きするのはほんの数人であるということです。
約10〜15年前の "新しいVisual Basic 6でシンプルなGUIを使用してアプリケーションを作成するのは非常に簡単である"という記述を検討してください。
ソフトウェアはあなたが思っているよりも長持ちする傾向があります。
最初に、何かをするための訴訟を起こす際のスキルを向上させる必要があります。費用対効果と意思決定分析を行う方法を学びます。討論のクラスを受けてください。人前で話すスキルを習得します。友達を獲得して人々に影響を与える方法をご覧ください。テクニカルライティングクラスを受講してください。変化が物事を改善することを納得させない限り、人々は変化しません。あなたは自分のものではなく、彼らの視点から物事を見始める必要があります。 （それが、議論するまでわからない議論のクラスの提案であり、どちらの側がどちらを議論するかを議論するまでわからない。私が今まで取った中で最も有用なクラスである。）
次に、経験豊富な開発者は、新しい光沢のあるテクノロジーを使用することは危険であり、プロジェクト全体の失敗を引き起こす可能性があることを理解していることに注意してください。それらがこれらの失敗の1つ以上を徹底していた場合、それらは変更に対してはるかに抵抗力があります。彼らはまた、テクノロジーの出入りが非常に速いため、月の新しいおもちゃに切り替えるのではなく、しばらく待って何かが続くかどうかを確認することを知っています。彼らはまた、有効な製品を取り、それを新しいものに変更することがどれだけの作業であるかを認識しています。あなたは新しいバグを導入します（クライアントは嫌いですが）、クライアントは実用的なソリューションをやり直してほしくないので、請求できない時間にそれを行わなければなりません。私はこれらのことをあなたを落胆させるのではなく、提案を受け入れさせるために反論する必要があるポイントをあなたに知らせるためにあなたに言います。
悲しい真実は、あなたはしばしばそれらを納得させることができないということです。彼らが古いやり方で行き詰まっている場合、たとえ利益が学習曲線を上回っても、彼らは何か新しいことを試みることを強く求められます。それがただ怠惰なのか、何か新しいことに挑戦することを恐れているのかはわかりませんが、一方で新しいテクノロジーを採用する場所で働いた回数を数えることはできますが、彼らが使用していた現在のもの（または物事の具体的な方法）が古くなり、より効果的でより効果的な方法に置き換えられたとしても、新しいことを決して行わなかった場所。
人々は常に「ビジネス価値」を実証することについて話しますが、彼らが言及するのを怠るのは、多くの場合、ビジネスは近視眼的でその価値を見ることができないことであり、開発者は現在の習慣に精通しているため、古い方法は親しみやすく快適です。
常にそうであるとは限りませんが、多くの場合、これを行おうとすることは負けた戦いであり、それを追求すると、仕事を辞めたくなるだけです。私は私のキャリアの中で何度も行ってきました（そしておそらくそれを経験し続けるでしょう）。
あなたの最善の策は、特定の問題に対処するために新しいテクノロジーを使用することかもしれません。新しいものを使用して新しいプロジェクトを提案するのではなく、新しいものを使用して問題点を修正してください。 AJAXの代わりに純粋なJSPを使用しているために応答時間の問題が発生した場合は、AJAX呼び出しを追加して修正してください。小さなケースとして採用してください。それを見て、それがどのように機能するかを見て、最終的には標準的な技術になります！
管理者の観点から、彼らは$ Xで機能するソリューションを持っていることを認識してください。導入したいテクノロジーが$ X以上節約できるものはなく、機能しない場合の損失の可能性はほぼ確実に$ Xより大きくなります。新しいテクノロジーへの変更はそれ自体コストがかかり、物事はしばらくの間遅くなります。 （新しいテクノロジーがすぐに生産的になることはめったにありません。）これは、経営陣が保守的になる傾向が強くなり、変更する強力で説得力のある理由を提供する必要があることを意味します。上記に基づいて、使用できるいくつかの引数がありますが、それらのすべてがそれ自体で説得力があるとは限りません（または必ずしも適用可能です）。すべての議論の根拠を確固たる証拠にする必要があります。
新しいテクノロジーが失敗する可能性は無視できるほど低いか、あまりお金をかけないフォールバック計画を提供するか、新しいテクノロジーを最初は重要ではない領域にゆっくりと段階的に導入することができます。これは、最悪の場合の限界を提供していることを意味します。マネージャーは空白の小切手を書くことを嫌います。
この技術は、人員や設備の削減を可能にするか、さらに多くのことを実行できるようにすることで、時間の経過とともに$ Yを節約します。これはコストに見合う価値があります。 （$ Yが数年にわたって分散している場合は、会社が将来のお金の現在価値を計算する方法を見つけ、それを使用してください。）
現在行われていることのコストは、このテクノロジーなしでは大幅に上昇します（VB6を置き換えるためにVB.NETを導入する場合、または法的要件または規制要件が変更されており、既存のシステムを適合させることが難しい場合）。
新しいテクノロジーにより、他のことが可能になり、$ Zがもたらされます。 （これは本質的に投機的ですが、会社がすでに戦略的優位性のためにソフトウェアを使用している場合は、より簡単にすることができます。）
できるだけ具体的に、正直に。あなたが誤ってあなたの事件に不利な何かを省き、誰かがそれを見つけた場合、それは問題です。意図的に改ざんしたり隠したりしている場合は、だれもあなたを信頼したり真剣に受け止めたりすることはないので、おそらくあきらめるべきです。非技術的な管理者が理解できる議論を支持してください。
私の経験では、新しいテクノロジーを紹介したいときは、貿易調査を作成して、古いテクノロジーに対する新しいテクノロジーの利点を簡単な要約で示します。
次に、私は通常、機能の概念実証を行い、小さい機能を見つけようとします。新しい技術を使用して紹介するスケジュールリスクはありません。
新しい技術がそのシナリオで実証されると、プロジェクトのより大きな側面に組み込むことがはるかに容易になります。
新しいテクノロジーについてチームのメンバーをトレーニングするコストを比較検討する必要があると言われていることはすべてあります。ほとんどのソフトウェアチームは、チームメンバーにさまざまな程度の機能を備えており、それらのメンバーの一部にとっては、新しく馴染みのないテクノロジーを導入することは困難な場合があります。
プロジェクト/チームの単一の言語に焦点を合わせるために言われるべきものもあります。その言語のツールに特化することに焦点を当て、特定の言語が持つ可能性のあるすべての特異性（つまり、マルチスレッドの問題、メモリ管理など）を知ることができます。