分析はテクノロジーにとらわれないべきですか？[閉まっている]

昨日、同僚の一人と議論をしました。彼（ビジネスアナリスト、以前はプログラマー）は、システムを実装するために使用されるテクノロジーを知っておく必要があると考えているため、より適切な設計上の決定を下すことができます。私の意見では（私はプログラマーです）、分析はテクノロジーと決して結び付けられるべきではなく、優れたアナリストは実装の詳細を気にせずに素晴らしいデザインを作成できると信じています。

そのように考えるのは正しいですか？ビジネスアナリストがシステムの実装に使用されるテクノロジーを知る必要がある理由はありますか？

編集：私は言っているときに間違った用語を使用したと信じていますbusiness analyst。多分私は建築家、またはシステムアナリストを意味した。私はこれらの用語に慣れていません。必要に応じて、建築家やシステムアナリストのようなものを意味しました。

素晴らしい回答をありがとうございました！私はまだあまり経験がなく、これに目を開いてくれてうれしいです。

特定の機能がどれほど重要であるかについてビジネスユーザーに質問するのが理にかなっていることを理解するのに少なくとも十分に十分に技術を理解することがビジネスアナリストにとって理にかなっている場合が確かにあります。たとえば、新しいアプリケーションがWebベースになりつつあるときに、ビジネスがファットクライアントアプリケーションの動作に慣れている場合、ファットクライアントでは些細であるが比較的難しい多くの「要件」がある可能性がありますウェブベースのアプリケーションで。ビジネスアナリストが、ビジネスチームからのリクエストが開発チームにとってささいなものになるのか、それとも20時間のAJAX開発を伴うのかを理解している場合、

どのプロジェクトでも、実際にはさまざまなトレードオフを行うことでビジネスを満足させる多数の要件が存在する可能性があります。ビジネスアナリストがどのようなトレードオフを行っているかを理解するほど、コストを最小限に抑えながらビジネスへの利益を最大化する一連の要件を提供する可能性が高くなります。

この問題の両側で働いたので、私はアナリストに同意しなければなりません。私は、テクノロジーの機能に対する理解の欠如に起因するいくつかの見事に貧弱なデザインを見てきました。場合によっては、それはマーケティングの誇大宣伝を真実として受けた結果でした。一般的に、問題は技術的な能力と一致しない仕様を生成することです。

アナリストは、何を行う必要があるのか​​、いつ、誰によって指定する必要があります。彼らはなぜそれが行われているのかを知る必要があります。開発の優先順位は、他の要因よりもなぜに依存する必要があります。設計および開発チームは、Howを処理する必要があります。費用対効果の高いシステムを開発するために、アナリストは利用可能な技術の境界を押し広げない用語で何をする必要があるかを指定する必要があります。

境界を押し広げると、さまざまな方法でコストが増加する可能性がありますが、場合によっては大幅な利益が得られることがあります。コスト要因には次のものがあります。

• 実用的なソリューションを開発するには、実験が必要になる場合があります。
• 専門知識のある新しい従業員またはコンサルタントを取得する必要がある場合があります。
• 新しいテクノロジーに関するトレーニングが必要になる場合があります。
• 開発は遅くなり、バグ率が高くなる傾向があります。そして
• 余分な努力は、より即効性のある単純なソリューションを遅らせる可能性があります。

使用するテクノロジーがわかっている場合、設計者はデザインを作成するときに考慮に入れる必要があります。テクノロジーによって処理方法が異なるため、それらの違いを考慮しない設計では問題が発生します。

ただし、ビジネスアナリストは、使用されているテクノロジを気にする必要はありません。彼らの仕事は、ビジネスルールを収集し、技術チームが理解できるようにすることです。システムアナリスト/アーキテクト/デザイナー、または与えられる他の名前は、ビジネスアナリストではなく実際の設計を行うものでなければならないため、使用されている技術とその周辺の設計を知っている必要があります。

おそらく、より現実的な2つの考え方の間にポイントがあると思います。高度な設計は、テクノロジーにとらわれない場合に最適かもしれませんが、設計に組み込む必要がある既知の現実の制約と要件を考慮する必要があります。このデザインはどのレベルですか？十分な要件がありますか？環境はどの程度柔軟ですか？経営陣は特定の技術的方向性に投資していますか？

特定の方向にあなたを駆り立てる運用パラメーターはありませんか？技術スタックにソリューションを実装できる幅広いリソースがありますか？他のシステムへのアクセスを必要とする相互運用性の問題はありますか？

テクノロジーを方程式の一部とすべきか、設計がテクノロジー選択を推進すべきかどうかを明確に言う前に、これらの質問に対する答えが必要です。

制約がなく、非常に高度な設計であるため、設計は本当に不可知論的であるというあなたの考えに同意するかもしれません。しかし、20年以上の経験の中で、選択を制限する制約がない状況に陥ることはほとんどありませんでした。これにより、特定のテクノロジまたはテクノロジファミリに向けて設計が進められました。

理想的なユーザーインターフェースは、ユーザーが考えを考えて、そして彼らが行わwantedがするだけで行われているところだろう。それよりも短いものは、私たちが自由に使える技術の制限によって不自由になるので、もちろん、BAはシステムを設計できるコンテキストを理解する必要があります。

特定の問題を解決するために、さまざまなテクノロジーが非常に異なるコストと効率の構造を持つことができます。これらのコストには、ローカルエリアでの雇用コスト、特定のシステムのエネルギーおよび冷却コスト、既存のコードおよび既存の機器の再利用の可能性などが含まれます。コストと効率が他の考慮事項（航空安全、原子力発電所の制御、医療インプラントなど）ほど重要ではないプロジェクトに取り組んでいる場合。しかし、ほとんどのビジネスの状況では、管理者はシステムの実装の利点に対して、潜在的なソリューションのコスト構造に注意を払うかもしれません。

ビジネスアナリストは、開発するアプリケーションの種類を知っている必要があります* Webアプリケーション/コンソールアプリケーション/モバイルアプリケーション/レポートアプリケーションなど * アプリケーションの優れた機能セットを思いつくか、ユーザーを押し戻すために第3レベルのネストされたドラッグアンドドロップ（例）のような不可能な期待に。

彼/彼女は、Java / C＃/ Python / SQLなどのテクノロジーを認識する必要はありません。

分析プロセス自体は、完全にテクノロジーに依存しない必要があります。クライアントとそのニーズを調査するときは、完全にオープンな心で調査する必要があります。コインのもう一方の側面は、アナリストが推奨事項を提供するように求められることが多く、システムアーキテクチャを処理することも必要になる場合があることです。これは、利用可能な技術をより広く理解することが重要である役割のまったく異なる側面です。プロジェクトを開始する能力だけでなく、顧客の長期的なニーズ、およびプロジェクト自体の持続可能性について。

ソフトウェアの設計の大部分は、使用する技術に関係なく本質的に同じであることは事実ですが、設計が技術の選択によって影響を受ける領域は常に存在します。プラットフォームの選択は、言語とAPIの選択に影響を与える可能性がありますが、専門知識、サポート、さらにはコストの可用性も、選択に影響を与えます。したがって、ある観点から見ると、実際の分析は特定の技術の影響を受けずに実施されるべきであるというあなたの立場の一部は正当化されますが、分析を使用して設計を決定するには常により広範な技術知識が必要であるため、アナリストは推奨事項を作成できますこれにより、顧客のニーズを満たすことを目的とした設計の適用が可能になります。

各テクノロジーには制限と制約があるため、アナリストがこれらの制限を検討することはある程度理にかなっています。一方、.netをよく知っているが、90年代後半からJavaを見ていないアナリストは、Java（またはRoRなど）であっても、.netの用語と設計パターンを使用して.netソリューションを設計する可能性が高いです。問題によりよく適合します。そのような設計を後で別のテクノロジーに実装することは比較的困難です。

したがって、技術がまだ選択されていない場合、アナリストは不可知論者である必要があると思いますが、選択がすでに行われている場合は経験があります。