これはどこから来たの
過去6年間、私は開発を管理してきました。 過去3年間、私もアドバイスします。 そして、もちろん、「どの言語で書くのか？」 または「どのデータベースを使用しますか？」。 そのような質問への回答がプロジェクトの主題分野によって決定される場合、それは良いことです。 PHPがドライバーに適していないことは明らかであり、C ++はプロモーションランディングバックエンドには不合理です。 これにより、選択肢が絞り込まれます。 しかし、残りの選択肢では、言語、ソリューション、フレームワーク、およびプラットフォームの「ノアの箱舟」全体が積み重ねられていることが多く、各クリーチャーはペアからはほど遠いものです。
過去の人生で、私が単純な線形プログラマーまたはリードだったとき、私は気にしませんでした。 私はこれをよく知っていて、それについて書くのが好きです。 私はこれについて多くの良いレビューを読み、興味があります。 しかし、どういうわけか試してみましたが、ひどく判明したので、私は誓いました。 私の責任には、発行するコードの品質と個人的な期限のみが含まれていました。 責任範囲の拡大に伴い、新しい頭痛の中心が追加され始めました。チームコード全体の品質、技術的負債の蓄積率、製品のユーザー特性などです。 しかし、その年、私が最初にSTOに指名されたとき、最も苦しい場所が現れました-予算。 私は突然、すべて例外なくソフトウェア製品の開発を繰り返すことに気付きました。それはお金に関するものです。 古いGPRSラップトップで祖母の村にいたとしても、次のENPのために不要な限界プロジェクトに飽き飽きして賄willを贈ります。 時は金なり、人気は金なり、コード品質は金なり、納期に収まる能力は金なり、人件費の予測精度は金なり...
そしてお金については、人類は多くの知識を蓄積しています。 それでは、なぜそれらを使用しないのですか？ 私にとって、このアプローチは完全に論理的かつ自然なものでしたが、毎回、経営陣（程度は低い）と開発者の両方からさまざまな驚きに出くわしました。
選択は投資です
字幕の公理を詳細に開示する価値はないと思います。 製品の予算、タイミング、最終コストは、テクノロジーの選択に依存します。 それで十分です。
用語「投資」におけるすべての微妙さ。
投資（Eng。Investments）-利益のための資本の配置。 投資は現代経済の不可欠な部分です。 投資は、投資家（貸し手）のリスクの程度によってローンとは異なります-ローンと利子は、プロジェクトの収益性に関係なく、合意された時間内に返済する必要があります。 プロジェクトが採算の取れていない場合、投資の全部または一部が失われる可能性があります。 ウィキペディア
投資に関する多くの文献を研究した結果、1つのことに気付きました。この情報の99.9％は自明であり、ロケット科学はここにはありません。 しかし、大部分の人々は、これらの自明で平凡なことをすべて無視するだけであり、トリックはこれを知らないことです。 秘trickはそれを念頭に置くことです。
投資の本質は簡単です。プロジェクトから何らかの価値を得るために、プロジェクトにリソース（お金、時間、労力）を投資します。 価値は利益になる可能性があります。 または知識。 または喜び。 主なことは、この値を自分で正しく決定することです。 価値の定義を伴う商業開発の場合、質問はありません-これはお金です。 したがって、投資の魅力を判断する上での重要な問題はここにはありません。
そして、はい、ハムスターのための手作りの襟の販売のためのあなたの素晴らしいサイトプロジェクトの技術ライフサイクルは、プロジェクト内のプロジェクトです。 すべての結果で。
利益とリスク
投資の魅力の評価は常に比較可能です。 投資の観点から球状真空プロジェクトを測定するオウムはいません。 はい、プロジェクトが1つしかない場合でも、投資するかどうかを選択できます。 この状況では、実際には2つのプロジェクトがあるため、「お金を枕の下に保つ」プロジェクトが常にあります。
投資の観点から見ると、プロジェクトにはリスクを考慮した投資の規模と利益の予測という2つの要素があります。 多くの場合、リスクは完全に忘れられるか、評価に深く入り込みません。 しかし、無駄に。 プロジェクトの投資の魅力を主に決定するのはリスクだからです。
テクノロジーを選択する場合、すべてがまったく同じです。 したがって、技術の選択は、望ましい価値を認識することに加えて、この選択のリスクの評価に変換されます。 ええ、はい、投資にはまだサイズ要因があります。はい。
これらの同じリスクの評価
一般的に投資の魅力を評価することと、特にリスク評価を評価することの全体的な難しさは、十分な正確さで価値を単一の基準（金額）にすることです。 これらの推定のために経済学者が使用する公式のほとんどは、数学者として個人的に恐ろしいものです。 妥当な精度で事後的にしか計算できない同じROIを採用します。 一方、2つの量の比較評価の精度は、これらの2つの量の値の近接度に依存し、これらの距離を比較するために国境までの距離と最寄りの食料品店までの距離を知ることは必ずしも必要ではありません。
同じC ++とPHPを使用します。 明らかに、同じ機能で、最初の製品は2番目の製品よりも生産性が高くなります。 しかし、時間と給料の点ではるかに費用がかかります。 そして、ここで理解するために、1日、1日、そして1日あたりのユニークさを数える必要はありません。C++でのプロモーションのバックエンドは面白くないです。
しかし、ポイントは特定の特性の評価の正確さでさえありません。 与えられた例では、リスクに関する言葉はまったくありません。 ポイントは、すべてのリスクの最も完全な因子分析です。 私の意見では、完全なリストを作成しましたが、完全なリストではありません。
人事リスク
検索語 -希望するレベルの履歴書で労働市場がどれだけ満たされているか。 COBOLプログラマーは、長くて高価な時間を探す必要があり、検索用語には大きなばらつきがあります。 1か月で見つけることができますが、1年で見つけることはできません。 そして、雇用の毎日の遅れは、プロジェクトのリターン値を減らします。
雇用の審査 -雇用主が候補者をどの程度適切に評価できるか。 これは複雑なリスクであり、候補技術の雇用者の専門知識のレベルだけでなく、この技術のコミュニティで開発された伝統（はい、一部の専門家は他の専門家よりも誤った情報を伝える可能性が高い）、およびこの技術の規模も含まれます-「よく知っていますC ++「と」PHPをよく知っている」は2つの完全に異なるステートメントです。 このリスクは、雇用コスト-不適切なスクリーニング、評価スキームの作成などの両方に影響します。 -そして、最終的な値（彼らは間違った値を採用しました）。
規律は、さまざまなテクノロジーではコードにさまざまなレベルの規律があり、両方ともテクノロジー自体（こんにちは、JavaScript！）と専門家コミュニティの伝統によって決定されることは秘密ではありません。 規律の計画レベルを確保することは、将来の管理コストです。
コードの所有権 -プロジェクトにとって、開発者の突然の失isがいかに潜在的にトラウマになるか。 これは、労働市場の充実度とコードの認識の複雑さを考慮します（perl -e '$ ?? s :; s：s ;; $？:: s ;; =] =>％-{<-|} <＆| {;;y; -/:-@[-
{-}; `-{/"-;; s ;; $ _; see '）など。
コミュニティのダイナミクス -持続可能なコミュニティまたは成長しているコミュニティは、将来の労働市場に対する信頼度を意味します。 もちろん、コミュニティが数か月で崩壊した場合もあります。
戦略的リスク
技術の成熟 -原則として（常にではないが）、何十年もの間存在し、多くの熊手を経てきた技術は、より安定、安定、信頼性が高い。 そして、この意味で、多くの場合、最高は本当に善の敵です。
コミュニティの規模 -スタッフのリスクを反映しますが、ここでは別の側面に存在します。原則として、コミュニティの規模は貢献者の数に影響します。 貢献者が多いほど、テクノロジーの改善により多くの労力が費やされます。
安定性 -技術の安定性とコミュニティの安定性で構成されます。 テクノロジーの歴史に「ホルスの異端」がいくつかあった場合、将来そのようなテクノロジーから静かな港を期待するべきではありません。 コミュニティが常にセグメント化されている場合、新しいバージョンが古いバージョンと互換性がなく、本質的に完全に異なる製品である場合、そのような技術は非常に短いセグメントでのみ興味深いものです。
整合性 -技術がいかに不可欠であるか、基本概念がどの程度明確に定式化されているか、および衛星技術/サブテクノロジーのコミュニティとコミュニティの両方によって共有されているか。 ドキュメントと知識ベースはどの程度一貫していますか。 ドキュメントの代わりにフレームワークのgithubに、常に最新情報とは限らないみすぼらしいwikiがあり、主要な知識がYouTubeの何百ものビデオに分散されている場合、アプローチと意味の説明で互いに矛盾している場合、整合性について話す必要はありません。
参入の閾値 -特定の技術の所有権がゼロレベルである人が、許容できる所有権に達するのがどれほど難しいか。 はい、ほとんどの場合、スタッフのリスクはそのような[再]トレーニングの必要性/適切性につながります。
合計
これらのリスクは、プログラミング言語やフレームワークからライブラリやユーティリティに至るまで、ほぼあらゆるサイズと重要性のテクノロジーを選択するときに存在します。 もちろん、それぞれのケースでそれぞれに重要性がありますが、それらはすべて検討する価値があります。 もちろん、このリストは完全ではなく、私が絶対的な真実であると主張しているわけではありませんが、開発を管理するという困難な作業に個人的に役立つのはこのリストです。
加算
コメントの中で、 AquahawkはGoogle Trendsがテクノロジー周辺のアクティビティを測定することの有用性を指摘しました。 私も個人的にGTを使用していますが、むしろ技術に対する幅広い視聴者の関心を評価するために使用しています。 かなり長期間にわたる着実な成長は、安定性の優れた兆候です。 しかし、これに加えて、GTから他の側面のアイデアを得ることができます。