非常に短い時間で重要な技術的意思決定を行う方法
WPFアプリケーションをLinux/Android/iOS whatnotに移植するために使用する予定のツールとプラットフォームについて、非常に真剣な決定を下すために2日間の猶予があります。
明らかに、すべての可能なオプションについて読んだり、試作品を作ったりするのに2日間では十分ではないことを先輩に指摘することができます。私はそれを言うことができます。少し助けにはなりませんが、2日間ありました。 2日後、決定が下されます。限目。
片方からはイライラし、もう片方からこのアプローチには一粒の真実があると思います。さもなければ、ダウンロードしたSDK、フレームワーク、API、ブログ記事など、ベンチワークを実行し、サンプルを実行している何十もの下に簡単に埋もれてしまいます。その過程でそれが何のためにあるのかを忘れてしまいました。
それでも私は、間違った決定が会社に多大な損害を与えることを恐れています。では、そのような決定を行うための「理想的な」プロセスは何だと思いますか？
あなたが持っているすべてが2日であり、プロトタイプを作る時間がないか、すべての代替案を読む時間さえない場合、実際には2つのオプションしかありません：
知っている人に聞いて、アドバイスに従ってください。これは必ずしも個人に質問することを意味するわけではありませんが、ブログや記事を検索して2日間かけて十分な情報を収集し、十分な情報を得られていない判断を下します。
すべての主流オプションについて少し調査してから、1つ選択してください。時々リーダーシップは間違った決定をすることを恐れないことを意味します、しばしば動揺することよりもしっかりした決定をすることがより重要です。
より分離された、変更が容易なアーキテクチャを考え出すことで自分自身をカバーできます。たとえば、クライアント/サーバーモデルを使用すると、中断を最小限に抑えてUIテクノロジを別のテクノロジに置き換えることができます。
私はストリームに反対しているように見えるかもしれませんが、私は最近Creativity、Inc。Ed Catmullの本を読み、この状況に対処する本当に素晴らしい段落がありました：
アンドリュースタントンが次に話しました。アンドリューは、人々はできるだけ早く間違いを犯す必要があると言っています。戦いで、2つの丘に直面していて、どちらを攻撃するかわからない場合は、急いで選択するのが正しい行動方針であると彼は言います。それが間違った丘だとわかったら、振り向いて、もう一方を攻撃してください。そのシナリオでは、受け入れられない唯一の行動はbetween丘を走ることです。
きっとあなたの状況にも応用できると思います。多分あなたは1つを選び、それに取り掛かることで今日の決定を下すことができます。うまくいけば、この2日間で何か準備が整い、「これを選んだので、いくつかのテストを実行したので、それで何ができるかをお見せできます...」と言うでしょう。選択したソリューションがまったく価値がないことに1日で気づいた場合は、別のソリューションを選択して、翌日にそれを処理できます。最悪のシナリオは、両方の日を使用して2つのプラットフォームをテストし、どちらも機能しないことを確認することです。しかし、それが最終的に正しい答えではありませんか。雑草を取り除き、考えられる間違った選択を取り除いてください。次の決定は前の決定よりもはるかに優れています。最良のシナリオは、すぐに適切なものを選択し、2日後に何かを表示できるようにすることです。
明らかに、2日間でプラットフォームを習得することはありませんが、できるだけ早く1つを選択すると、それがどのように機能するかについてのより良い見通しが得られ（それについて読むだけではありません）、より良い答えにつながります。
gbjbaanbは、いくつかの非常に優れた点を示しています。私は少し追加すると思いました。
完全な情報に基づいた決定を行うのに十分な時間がないことは明らかです。あなたの唯一の選択肢は、将来の痛みを最小限に抑える決定を試みることです。私はお勧めします：
状況の性質を明確に文書化します。マネージャーにメールを送信し、マネージャーと関係者にCCを送信します。割り当てられた問題はトリッキーな問題であることを説明しますが、問題をすべて解決してもかまいません。ただし、時間の制約が厳しい場合、結果が最適であることを保証することはできません。
大規模で活発なオンラインコミュニティでフレームワーク/プラットフォームを見つけます。あなたが望む最後のことは、あいまいなフレームワークだけをデバッグすることで立ち往生することです。
Gbjbaanbで前述したように、疎結合アーキテクチャーを使用することで、移植の痛みとリスクを軽減できます。テクノロジーの選択のいずれかですべてが洋ナシ形になった場合、これにより交換が容易になります。
私は以前あなたの状況にあったことがあり、それは最終的には政治的な悪夢に変わりました。システムが魔法のように機能しなかったとき、人々は指を指し始め、物事は醜くなりました。それが、私の＃1の推奨事項が明確に文書化することである不可能なオッズに対してあなたは最善を尽くした。
幸運を ：）
彼らはあなたに帽子から候補者を選ぶ以上のことをする少しの時間を効果的に与えたので、私は次のアプローチを採用します。
次のテクノロジーを選択してください。
- ユーザーベースが大きい
- 積極的なサポート（あらゆるチャネルを介して）
- 積極的に開発されている
定義により、これは最先端のテクノロジーを除外しますが、それがどれほど良いものであってもかまいません。
また、単に開発者が過去にそれを使用したという理由だけで、さらに分析せずに、テクノロジー[〜＃〜] x [〜＃〜]を使いたいという衝動に抵抗します。それが完璧な適合である可能性は低く、フレッドが緑の牧草地に移動する場合、ドメインの専門家がいます。
そのような決定をするのに2日間は非常に短い期間ですが、2日間で行う必要があるため、以下のリストを参照してください。
- ターゲットプラットフォームとは
- 現在のアプリで使用されているカスタム/サードパーティのコンポーネントは何ですか？例：グラフコンポーネント、グリッドコンポーネント、レポートコンポーネントなど。
- 現在のアプリは世界にどのように接続し、セキュリティはどのように処理されますか（データベース接続/ Webサービスなど）
- 配布方法と更新の提供方法
今、あなたはあなたがすべてのターゲット環境に使用できる選択肢を見つける必要があります
それぞれの選択肢について、現在のアプリが使用している接続性/セキュリティを使用するためのサポートを見つけます。
次に、カスタム/サードパーティの各コンポーネントについて、それぞれに使いやすい代替があるかどうかを確認します。
そして、見つけた代替案ごとにどのように配布を行うことができるかを考えます。
2日間、これはカバーできる範囲であり、結果に基づいてソリューションを提供できるはずです。
私が新しいものを学び、実験したいのと同じくらい、時間の制約の下で、最良のオプションは常に、何であれ、またはより快適に作業できると感じることです。 あなたが知っていることにこだわる。
長期的には、最良のオプションを選択しなかったことが明らかになったとしても、開発したものは価値があり続け、完全に使用可能で移植可能な一種のフィールド知識をラップします。そしてそれは、使用することを選択した快適なコンテキスト、ツール、プラットフォームが邪魔にならないようにして、本当に重要なことを確認できるようにするためです。
パフォーマンスセキュリティコスト使いやすさXを実行する能力Y開発者が慣れるまでの時間市場投入までの時間など、選択に入る要素のリストを作成します。
これには1時間もかからないはずです（実際には15分もかからないはずです）。その後、経営陣と一緒に座り、それらにこれらの要素を優先させます。 （それらの優先順位とあなたの優先順位が同じである可能性はほとんどありませんが、優先順位に関する提案をいくつか選択してガイドすることができます。）これで、テクノロジについて何を評価すべきかがわかりました。
インターネット検索に基づいて、問題の一般的な解決策を3つまたは4つ選択してください。
次に、十分に読んで、各選択肢が上位3〜4の優先度にどれだけ適合するかを推測してください。各選択肢に数値を割り当てます。各優先度の評価をその優先度に設定された値として掛け算して計算を行います（数値1の場合は10、数値2の場合は8、数値3の場合は6、数値4の場合は4、または任意の数値）。これで、各可能性の数値スコアが得られました。一般に、割り当てられた優先順位に最も適合するものは明らかです。さらに良いことに、あなたは今あなたの選択を証明するために彼らに連れて行く何か分析的なものを持っています。あなたはそれをサポートするための数を持っているので、彼らは通常あなたの選択で買い戻します。数値がそれをサポートしていない場合は、なぜ他の数値を好むのかを自問して、数値の最も高い数値を使用するか、割り当てられた数値を再検討する必要があります。
選択する本当の優先順位に集中することで、多くの研究時間を削減できます。おそらく1日以内に推測してから、残りの1日で、上位2つの可能性を試し、必要に応じて試用版をダウンロードして、少し試してみてください。