コミュニケーションギャップ:ユーザー vs アナリスト兼デザイナー

Question

通常は、ケーススタディを使用し、ワークフローやデータフローを構築するなどします。しかし、これは必ずしもユーザー/スポンサーとアナリスト/デザイナーの間で共通の語彙を生み出すわけではありません。通常、どちらかが、相手の専門分野の「内部」についての用語や見解を習得する必要があり、これにより通常、誤解や明確にするための会議（進化的プロトタイピングなどの RAD テクニックの導入）などが発生します。 。

ユーザー/スポンサーは自分のニーズ/環境に焦点を当てており、彼らの観点から無関係な「プログラミング用語」を習得することを望んでいませんし、習得することを強制されるべきではありません。新しい環境を学習する責任はアナリスト/デザイナー(/プログラマー)にあります。

学習曲線をどのように克服しますか?ソフトウェア ソリューションを求めるユーザーに直面した場合、何が効果的ですか?

Answer 1

できるだけ多く排除してみてください 中間ステップ 可能な限りユーザーと最終実装者の間で。そのようなステップごとに情報が曖昧になり、失われます。あなたのチームで最も価値のあるメンバーは、次のようなことを身につけることができる人々かもしれません。 どちらのスーツも - ユーザーとの「インターフェイス」を作成し、実際に実装します。

そうでない場合は、持っていることを確認してください 迅速な反復 そして物事を反復的に実装します。インクリメンタルと混同しやすいです。違いは、反復アプローチでは、広範囲の機能を小さいながらも均一な程度で実装できることです。インクリメンタルアプローチでは、大きな機能を次々に実装します。

反復的なアプローチには次のような利点があります。 機敏。 ユーザーの気が変わったのか、それとも何か誤解があったのでしょうか?問題ありません。まだ変更の余地があります。うまくいけば、それほど多くの努力は費やされていません。

Answer 2

コメントを利用させていただいております

「バーテンダーに自分の物理学を説明できないなら、それはあまり優れた物理学とはいえない」そして「おばあさんに説明できない限り、何かを本当に理解したとは言えない」（ラザフォードとアインシュタインによる）

私が顧客と要件について話すときのマントラとして。

パワーポイントまたはホワイトボードによる概要のプレゼンテーションと、POC またはモックアップでユーザーを自由にできるかどうかの 2 つのアプローチを採用します。

次に、詳細な要件を行ごとに実行します。悪魔は細部に宿る。これらの詳細を承認してもらいます。行ごとに分析できるように、ラベルと番号を付けます。

高レベルのセットの前に詳細な要件を作成すると、ユーザーは設計の概念をまったく理解できず、最も小さな詳細仕様で行き詰まってしまいます。フレームワークやコンセプトなしで、ユーザーはピンの頭に描かれた天使の数だけ回転します。

顧客と開発チームが同じような言語で会話できる限り、機敏性と反復性は良好です。期待が設定され、満たされていることを確認します。

Answer 3

優れたインタラクション デザイナーは、ソフトウェアの動作を分かりやすく説明できる必要があります。そうでないなら、彼はフロントエンドをやるべきではない、私見です。

Answer 4

それにはさまざまなテクニックが必要であり、双方とも相手のビジネスをある程度理解することを学ぶ必要があります。つまりアナリストはユーザーの領域を理解する必要があり、ユーザーはアナリストのテクニックの一部に精通する必要があります。

プロセス フローは、ビジネスの運営方法について高いレベルで合意するために始めるのに良い方法だと思います。データ モデル (ERD など) を得意とするユーザーもいますが、一般的にはそうではないと思います。ルールがテキストで詳しく説明されている場合、彼らはよりよく反応することがよくあります。

• 注文は 1 つ以上の注文明細で構成できます
• 各注文には固有の 10 桁の参照番号が付いています。

彼らは、ERD の品質をチェックするよりもはるかに簡単に、それらを読んでチェックを入れたり交差させたりすることができます。

次に、ユーザーが必要とする内容の詳細に集中できるようにするには、入力画面とレポートのスケッチに勝るものはありません。