ビジネスパーソンからの要求の調整？
非技術系ビジネスマンの要件をうまく解決するには、どの方法が最も効果的と思われますか？プロジェクトの仕様をまとめようとしているチームと協力しています。私たちが会って、次の会議の期待に帰着するたびに、私たちはビジネスマンに彼らの要件を取り戻すように求めます。彼らは通常、次のような反応を示します。「さて、皆さんはプロトタイプを作成して来週私たちが好きなものを見ることができると思いますか？わかりました。プロトタイプなので、データや何かではなく、機能だけです。」これは6か月以上のプロジェクトであるため、明らかに実行不可能であり（全体を開発する必要があります！）、なんらかの仕様なしにプロトタイプを作成することすらわかりません。率直に言って、私はほとんどの人と同じように、彼らは自分が何を望んでいるのかについて何らかの考えを持っていると思います。単に彼らに伝える代わりに、「あなたが欲しいものを私たちに与えてください、または私たちは何もできない/できない」（彼らが結果に満足することを望んでいます）、彼らが望むものを決定するのを助ける方法があります？たとえば、次のように伝えることができます。
「表示したいすべてのデータとマージンの機能の説明を表示したいUIを表示するいくつかの画面（PowerPoint、ナプキンなど）を引き出します。これから、私たちはそれを磨き、この一連の動作要件に基づいてバックエンドを構築します。」
OR
「それが今どのように見えるか心配する必要はありません（番号1が電話を切った）。プログラムが追跡する各項目について必要なすべてのデータのリストを提供してください。したがって、「顧客」には、名前、住所、電話番号、注文などをリストすることができます。これは完全なデータベース構造である必要はありませんが、これから何かを導き出し、あなたが探しているもののアイデアを得ることができます。」
これらの代替アプローチのいずれかを使用して、ビジネスパーソンが望むものに集中できるようにしますか？実際に見た代替案はありますか？
それらから何かを得ることができない場合は、何かを書いて承認を得てください。 「これはあなたがやるべき方法です」よりも、技術者でない人にとっては「いいえ、私はそれが好きではない」と言う方がはるかに簡単です。
多くの場合、彼らが望んでいることと彼らがあなたに言っていることは、2つの非常に異なるものです。少し時間を取って、現在知っている情報を記載した仕様の最初のドラフトを作成してください。関係者にそれを読んで承認するよう依頼してください。彼らがそれを読むとき、彼らはおそらく彼らが好きでないか同意するものを見るでしょう。彼らのフィードバックを得て修正してください。
あなたが何らかの方法で進むことができる何かがある場合は、両方のオプションをオンラインにして、意思決定者に選択をさせてください。彼らがそうするまで彼らを一人にしないでください。
プロトタイプについては、画面のモックアップを作成し、代わりにどのように機能するかを説明します。繰り返しになりますが、何かを見ると、何が起こっているのかを視覚化するのに役立ちます。新しい画面のモックアップを会議に持って行き、答えを入手してください。
過去に、私は実際にFireBugを開いて、顧客がそれらの前に要求した変更を追加して、それがどのように見えるかを確認できるようにしました。彼らは彼らのフィードバックを与え、私はスクリーンショットを撮ってから変更を実装しました。彼らは変更がどのように見えるかを見ることができることを本当に気に入っていました、そして私はそれがb/c速いのが好きで、私はその会議で私の答えを得ました...次の会議ではありませんでした。
アプリケーションについてではなく、ビジネスについて話してもらいます。実際の問題とは何かを調べてください。月末のレポートに時間がかかりすぎ、データ入力エラーが発生し、現在のアプリケーションを超えており、会社の成長は手に負えなくなっています。
これらのミーティングは、購入を行う人々との会合であり、アプリケーションに関連する作業を実際に行う人々との会合ではないと思います。あなたがこれらの人々の選ばれた数人と会うことができるかどうか尋ねてください。彼らは物事が実際に行われている方法を示すことができます。時間とコストを予算に入れているクライアントと取引していることを確認してください。
現在使用しているか、使用したいレポートがあるかどうかを確認します。データを適切に収集しないと、レポートを作成できないことは明らかです。これがまだ開始していない事業分野でない限り、彼らは何かをしている必要があります。
多くの人があなたがプログラマーであるというこれらの一般的な概念を持っているため、すべてのプログラムを構築する方法を知っています。 eコマースサイトはすべて同じですよね？
小さなものから始めましょう。残念ながら、その前に何かを見つけるまで、プロセスは登録されません。何もすることがない場合は、それを偽ってください。
これの多くは、一般的な対人スキルと、そもそもクライアントとのコミュニケーション方法に関係しています。それについては、私が言えることはあまりありません。プロセスをインタラクティブなプロセスとして説明するようにしてください。クライアント側にもフィードバックと努力が期待できます。
具体的には、ここで説明したシナリオについて、さらにアドバイスをいくつか紹介します。まず、知っておくと便利なことを説明し、技術的な専門知識やノウハウを必要としない用語で情報を説明する手段を提供します。
ユーザーストーリー/ユースケースユーザーが何を期待しているか、そのために必要な情報、およびユーザーが自分で入力する必要があることと期待できることの詳細な説明を尋ねます。この情報を入手したら、それらについて説明し、すべてがストーリーで覆われていることを確認します。アプリケーションに入る内容はなく、ユーザーがそこで何をするかをカバーするストーリーはありません。
説得力のあるデモンストレーション顧客を獲得するために何がより重要ですか？プログラムまたは機能のどの部分を目立たせる必要があり、完全に洗練する必要がありますか？投稿したいメモ、段ボール箱、または他の代役を使用して、モックアップデモを提供していただけますか。
市場/競争情報各ユーザーストーリーについて、競合他社と同様に何をしていますか？違う？競合他社はどのような話をしていますか。また、意図的に異なるものをコピー/エミュレート/改善/革新/差別化しようとしていますか？
未解決の質問要件と設計の中で、あなたが確信している情報は何ですか、そして実験とは何ですか？どちらが機能するかを確認するために、代替手段をどこで試しますか？複数の選択肢を検討していて、そのうちの1つしか教えていない場合、検討している他の選択肢は何ですか？
次に、いくつかの境界を描画します。
私に技術的な制限を課さないでください。ビジネスマンは、「Linuxよりも優れているため、Windowsを使用する」と言ってはなりません。ただし、「対象となるすべての市場でWindowsを使用しているため、アプリケーションをWindowsで実行する必要があります。
デザインについては気にしないでください特に、販売やマーケティングを重視する人とやり取りしている場合、デザインの問題に悩まされる傾向があります。繰り返しますが、情報の範囲を彼らが専門とするものに絞り込みます-「ここでは青がより美しい」はおそらく適切ではありません。 「私たちの競争相手は青い色のテーマを使用しており、80年代から出回っています。私たちのプログラムの革新的でない部分については、私たちが新しくないことを伝えるために青いスキームを使用する必要があります」とおそらく適切です。 「名前が画面の上部にあるはず」はおそらく適切ではありませんが、「このページで最も重要な情報はユーザーの名前と銀行口座の残高です」と思われます。これらの要件をUIに変換することにデザイナーが関与していることを確認してください。
決定を書き留めるできれば、契約またはその他のコミットメントにこれらを組み込んでください。ただし、顧客が理解していない決定は、書面にした文書に値しないことを覚えておいてください。 「アプリケーションはポート1521で実行されます」にサインオフする顧客は、「アプリケーションがカスタムの構成可能なポートで実行されます。デプロイ時にファイアウォールとセキュリティに特別な構成が必要になる場合があります」ほどの価値はありません。 」
あなたの観点から、プロセスを続けるように奨励するために：
同じレベルの抽象化でフィードバックを提供するこれは、たとえばユニットの場合、全面的です。顧客が毎月のユーザーのボリュームについて話している場合は、ギガビットの帯域幅で応答しないでください。または、ユースケースの場合-モジュールやバグ修正や機能ではなく、実際のユースケースの観点から機能を説明します。
有意義なコミュニケーションを提供する提供された情報に関して、あなたが持っている質問、およびあなたが発見した、または探している追加情報をフレーズしてください。 「Linuxを使用する」はフィードバックが不十分である可能性がありますが、「Linuxマシンでホストし、IE Windowsで）を使用してアクセスすると、アプリケーションがよりスムーズに動作することがテストで示されています。
迅速に反復するクライアントの関与を維持するには、迅速で意味のある更新と反復を提供します。プロセスの開始時に入手できなかった、または入手が容易ではなかった仕様と情報は、顧客からの多大な労力を費やす可能性があります。クライアントを関与させ、プロセスに投資させることは、仕事が最終的に時間と労力を費やす必要のあるものになる場合に役立ちます。
クライアントであるビジネスマンは、ある種の問題を抱えており、ある種の技術的な解決策を望んでいるが、解決策がどのように機能するかについてほとんど理解していないため、潜在的な解決策を特定する方法についてほとんど考えていない。その場合、欠落している役割は、顧客、その問題、ワークフローなどを調査できるビジネスソリューションアナリストの役割、および考えられるソリューションが企業の手順、文化などにどのように適合するか、および特定のソリューションは、時間内、予算内などで実装できる可能性があります。これは、学際的な役割であり、ビジネス手法（法律、会計、ロジスティクスなど）、ユーザー心理学、およびソフトウェア技術の両方についてある程度の知識が必要です。
顧客を自分のビジネスソリューションアナリストにしてもらいたいようです。これは、合理的な仕様を保証するのに十分な専門知識を持っている役割ではない可能性があります。そして、あなたもこの役割を引き受けたくないようです。あなたもあなたの顧客もこの役割を果たすための専門知識を持っていない場合、プロジェクトを成功させるために必要なすべての人がいない可能性があります。
顧客が試せる一連の迅速なプロトタイプが、顧客の（有声と無声）ニーズに対応するある種の使用可能なソリューションを実験的に発見して収束させる唯一の方法である場合があります。これは、あらゆる種類の無制限の契約に適している場合とそうでない場合があります。
追加：必要な専門知識を持たない顧客から要件ドキュメントを強制しようとする場合、これは潜在的な災害を示す巨大な赤旗になる可能性があります。
UIやデータの要件は要求せず、機能性の要件を要求します。
アプリケーションに何をしてほしいか尋ねます。アプリケーションの使用方法について説明してもらいます。最初は、UI、データなどの詳細は省略します。
ユーザーがUIやデータに関して何を求めているのかわからないことがよくありますが、機能に関してはユーザーは何を求めているのかを知っています。たとえば、「ログインしてすべての顧客情報を表示したい」と言われます。画面がどのように表示されるか、またはどのようなデータが必要かを理解するのではなく、画面から機能を取得してください。
それができたら、簡単なモックアップを行います（私は Balsamiq が好きです）。 UI /データがどうなるかを想定し、それにあまり時間をかけないでください。次に、そのモックアップをお客様に返却します。そこから、「これらのフィールドは必要ありません」、「実際には電話番号のリストが必要ですが、1つだけではありません」、または「これはリストボックスではなくドロップダウンである必要があります」と伝えることができます。
開始点を取得すると、データとUIを具体化するのがはるかに簡単になり、機能性を決定することが最良の開始点であることがわかります。
何よりもまずビジネスプロセスに集中することをお勧めします。ドキュメントまたはディスカッションで、ソフトウェアで処理されるタスクを現在どのように実行するかを定義してもらいます。次に、プロセスのどの部分を変更してもらいたいか（彼らがソフトウェアを必要としている理由）に焦点を当てます。ソフトウェアを使用して、プロセスの他のどの部分が改善されるか、または完全に削除されるかを検討するための開始点としてそれを使用してください。
クライアントがソフトウェア要件の提供に慣れていない場合、チームはクライアントの要件を起草する必要があります。複数のリビジョンを通過することを期待しますが、少なくとも何を探しているのかを伝えるために、最初のドキュメントを提供する必要があります。
ソフトウェアを組み込む予定の最終結果プロセスの機能要件についての良い考えを得たら、インターフェースのモックアップの作成を開始できます。彼らが最初に刺すことを許可したい場合は可能ですが、通常は最初のアイデアを提供し、それらを微調整することをお勧めします。これには関数コードは必要ありません。開発中のUIのスクリーンショット、静的フィラーテキストを使用したレイアウトのHTML表現、または描画（スタッフに適切なアーティストがいる場合）でも、最初のUIディスカッションに使用できます。
いくつかの修正を経て、誰もが提示された内容に同意したら、顧客の書面による承認を得る！彼らがどれだけ抵抗しても、このステップは重要です。要件にサインオフしても、プロジェクトにそれ以上の入力ができないことを意味するわけではないこと（クライアントとの関係の性質によって異なります）を安心させる必要がある場合があります。その場合、要件の改訂方法の概要を説明する必要があります。処理されます（たとえば、レビューと承認の対象、次のバージョンにプッシュされる、拡張機能として個別に価格設定されるなど）。
機能ごとにプログラムを開発することを伝えます。次の会議まで、1〜2週間でX個の機能を使用するとします。これは1、2、3、またはそれ以上になります。
最初に、最も重要な機能性を開発することから始めます。コア機能から始める必要があります。あなたがテラーマシンを作っているとしましょう（議論のために）。大事な機能のリストの最初（または次）の最初の（または次の）は、大規模な引き出しを行うときに確認としてユーザーの生年月日を尋ねることです（プロジェクトの機能の代わりに、主要なコア機能の1つではないことがわかっています）。次に実装されます）。
この素朴な主張は、クライアントからの反応を引き出すはずです。それが彼らに次に何をするか尋ねるとき？プロジェクトでまだ行われていない最も重要な機能は何ですか？.
前の例を再利用すると、クライアントは、ユーザーのカードを検証したり、預金をしたりすることを通知する場合があります。次に、クライアントに定義を依頼します。多くの質問をすることを恐れないでください。必要に応じて素朴な質問でさえも。
これについてクライアントと話し合った後、この1つの機能性に関するいくつかの要件が必要になります。あなたは複数の機能を定義することができますが、私はその数を非常に低く保ちます。
1〜2週間で、クライアントと再び会って、あなたがしたことを彼らに提示し、それについて彼らの意見を得ます。それをクライアントに提示し、変更または追加が必要な場合は入力を取得します。
次に、前の演習を繰り返して、次の一連の機能を実行します。プロジェクトの残りの部分では、このプロセスを繰り返して続行します。必ずクライアントと連絡を取り、定期的に会議を行って作業を示し、次に何をするかを計画するようにしてください（常に小さなチャンクにとどまります）。
あなたはエンジニアリングの話をしていて、私の経験では彼らはそれを気にしません。彼らはまた、何かをすることをコミットしたくはありません（特に書面で）、彼らは実際には何もしたくありませんが、それはビジネスの種類に固有ではありません-誰も彼らがドメインでたくさんの仕事をしたくありません知らない、知らなくてもいい。それはあなたの仕事です（彼らの心の中で）。
私がやっていることは、彼らが望むことを彼らのドメイン言語で彼らに話してください。彼らはあなたが望む方法（ユースケース、契約による設計など）を正確にできるわけではありませんし、喜んでそうしませんが、-yoは曖昧でさわやかなリストの種類を正確に翻訳できますdesiderataを実際の設計に組み込み、その結果、設計ドキュメントを作成します。彼らがあなたにこれを正式に行う時間を予算に入れるなら、それははるかに良いです。そうでない場合は、反復可能な即席の非公式なものを作成します。
これはとても喜ばしい答えではありませんが、クライアント（または実際には誰でも）が私の世界に足を踏み入れて私の言語を話そうとするのをやめた方が、人生が楽になることがわかりました。ドメインと要件（クライアントが漠然としか理解していないことが多い）について理解するようになると、何度も同じ質問を繰り返してしまいますが、直感に反するのは、議論がイライラしないことです。実際、クライアントとの関係はより強くなる傾向があります。人々は彼らが知っていることについて話したいと思うので、より厳密なデザインのアプローチに任せた場合よりも、POVをより丸く理解するようになると思います。
プログラマーは、プログラムがビルドされる前にどのように見えるかを想像する能力が優れていると思います。 紙のプロトタイピング は、これを克服するための効果的なテクニックである可能性があります。紙のプロトタイプは、比較的「安価」に作成できます。簡単な紙のプロトタイプをクライアントに紹介することで、「真の要件を収集するために必要な焦点を絞った方法で」考える必要性を示します。そして、それは特定の焦点を合わせる方法を提供します：実際にあなたの頭の中にあるアプリケーションを使用しようとしています！
また、クライアントが何を望んでいるかという最良の推測から、クライアントが本当に望んでいるアプリケーションまで、非常に迅速に繰り返すことができますが、伝えるのが困難です。プロトタイプを見て、それが頭の中で理想的なアプリケーションと一致しない理由を判断する方が、そのアプリケーションのすべての要件をリストするよりも簡単です。
他のパートナーがよりビジネス志向のWebサイトで作業しました。私はさまざまな方法で特定の要件を求め続けました。彼らの反応は、基本的には「あなたはコンピューターの男だ。私たちはあなたがこのことを理解することを期待している。私たちはビジネスのことをしたい」と述べた。彼らは具体的な詳細に関心がありませんでした...最初のバージョンがリリースされるまで！彼らはリリース後の要件にはるかに熱心で、私が最初に尋ねたとき、私に多くの時間を前もって節約していたであろうあらゆる種類のフィードバック。
だから、反復が鍵であると判断しました：最小限の実行可能なバージョンを構築し、フィードバックに基づいてそれを改善します。要件が曖昧で一般的である場合は、 「最も単純で最速の実装は何ですか？」 （基本的なシステム設計/アーキテクチャを除く）。あなたが「正しい」と考えるものに基づいて、仮定を重視しすぎないでください。あなたの思考プロセスがクライアントとは異なる可能性が高いので、それは時間を無駄にするだけです。
例：クライアントが画像アップロード機能を要求します。より具体的な要件については詳しく説明しません。できるだけ素朴に作成します。クライアントが望んでいることだと思っていても、自動トリミング、サイズ変更、サムネイル機能を追加しないでください。最小限の実行可能なバージョン（非ナイーブバージョンよりもはるかに速く開発できる）をクライアントに表示すると、「これは現在のバージョンの問題です」という要件が流れ始めます。これらの新しい要件をそれぞれ「バグ」として記録します。最も優先度の高いものから優先順位を付けることができます。
実際に私に起こりました：特別な招待コード付きのサインアップフォームのリクエスト。アイデアは、新しいユーザーがそれぞれいくつかの招待状を受け取るバイラル登録プロセスを作成することでした。私は多くの時間をかけて、コードが一意であり、一度しか使用できないことを確認しました。また、姓名フィールドをオプションにすることで、プロセスをできるだけスムーズにするために多くの努力をしました。最後に、パートナーはこれらの変更を求めました：何かがフィールドに入力された場合に有効な姓と名のサインアップ「コード」... sigh〜
プログラミングのことを知っているマネージャーがいないと、これで少し成功したことはありません。むしろ、私が見つけた唯一のアプローチは、実際に何が起こっているのかを観察することです。