頻繁な要件の変更にどのように対処しますか？

現在の職場ではかなりストレスの多い状況（私の意見では）を扱っています。

私たちは新しいプロジェクトの開発を開始し、いくつかの要件を取得して実装し、「ビジネスアドバイザー」と呼ばれる人（ビジネス要件を知っているがプログラムを使用しない人）に見せます。その人は顧客の視点からアプリケーションを評価し、それをテストすることになっています。

ここに「プロセス」がどのように見えるか：

1. ビジネスアドバイザーは、Windowsメッセンジャーで1〜2時間、上司と夕方話し合います
2. 翌日、その会話のコピーをメールで受け取ります。私はそこからタスクを選択し、報告されたバグをチェックすることになっています（これは多くの場合、バグではなく、テストが不十分で、過去の施設を忘れています）。
3. 私は変更を実装し、実装が受け入れられ、1〜2週間で、彼らが望んでいないことが判明しました（5分間ソフトウェアを見た可能性のあるクライアントと話し、変更を提案しました）-新しい変更を行う必要があります

誤解しないでください。要件が変わる場合があることを理解しています。気が動転するのは、職場で変更が発生する頻度と、「管理」がいかに簡単かによって、新しい要件が与えられたり、既存の機能に根本的な変更が加えられたりすることです。

同時に厳しい締め切りに取り組んでおり、ソフトウェアを進めるのではなく、サークルを運営しているという印象を受けます。

この状況への対処方法を教えてください。これは通常の状況であり、私はそれについて過敏になっていますか？

可能な場合は、メールで送信された会話を取り、それを要件文書にしてください。そこから収集できるタスクをリストし、優先度であると思われるタスク順に並べ、それぞれに見積もりを割り当てます。次に、次のリリースでどの機能が必要かを尋ねます。

基本的に、管理者があなたが何を構築しようとしているのかを認識しているある種のフィードバックループを強制します。メッセージが届くまで、独自の要件文書を作成します。

ストーリーカード

あなたの状況は、ユーザーストーリーの紹介に適していると思います。それらは、マネージャーが優先順位を設定するための継続的でインタラクティブな方法を提供するのに非常に役立ち、1週間後にアイデアに戻ってそれが機能しないことに気付いたときに、それらを捨てることさえできます。

現実の世界では、要件は定期的に変化します。プラス面としては、ソフトウェアの構築を完了して出荷する前に、それについて調べます。ソフトウェアの直接のユーザーからのフィードバックサイクルが厳しく、これは実際には素晴らしいことです。

ここでの最大の問題は、変更を管理するその場限りの方法にあるようです。あなたはアジャイル/スクラムがフィードバックを提供する「製品所有者」と見なすものを持っていますが、プロセスは十分に文書化されておらず、十分に考えられていません。

おそらく、スクラムのモデルと、効果的な製品所有者が何であるかについての彼らの見方を見て、次のステップを知らせるのに役立つでしょう。

したがって、この特別なプロセスではなく、「ビジネスアドバイザー」とより密接でより有益な関係があり、議論している変更の結果について全員が同じページにいる世界に移動することを目指します。

現在のプロセスでは、これらの人々が消費するリソースとお金を取り戻さずにアイデアをブレインストーミングするのが非常に簡単になります。これらすべての機能が必要な場合は、「ゲーム内のスキン」を入手する必要があります。

会話のメールを受け取り、それが単なるスプレッドシートであっても、何らかの機能/バグ追跡アプリケーションに入れます。新しい追加をビジネスアドバイザーに送り返し、各アイテムの承認または訂正を依頼します。サインオフに加えて、優先順位を付ける必要があります（どれを最初に希望しますか？）。

彼らが承認した後、テストのためにアイテムが完了する予定のスケジュールを送り、テスト/完了の承認を行う時間にコミットするように依頼します。

このタイプのドキュメントを作成することがプログラマーになった理由ではないことを知っていますが、これらのリストを捨てるリスクを冒すか、苦労して稼いだコードを捨て続けることができます。

押し戻す。担当者は、これらのリクエストのコストを確認する必要があります。

要件の変更は必ずしも悪いことではありません。重要なことは、顧客を覚えておくことです。この場合、上司が顧客である可能性があります。これらの絶え間ない要件の変更が上司に最も役立つ製品を生産する能力を制限していることを上司に通知する必要があります。絶えず変化に対応することで、ビジネスのメリットが得られる可能性は十分にあります。もしそうなら、それは彼らのビジネスモデルであり、あなたは何も悪いことをしていませんが、その場合は丘を走ることをお勧めします！

要件の変更に不満を抱いている人は、多くの場合、各変更をいかにうまく管理しているかを評価されます。「十分に処理された変更の数」というこの測定基準は、おそらく本当の問題の原因です。 上司とより良い指標について話し合うことを検討してください。 絶えず変化する要件に直面しているとき、私は絶えず変化する要件に適応できるコンテンツを書くよう努めています。毎日シミュレーションを実行してデータを分析する代わりに、シミュレーションを実行してデータを分析するプロセスを安価にするツールを作成し、時間の経過とともに報酬を獲得します。それでもクレイジーすぎる場合は、ツールを作成するためのツールを作成することもできます。

プロセスは、反復でロックされるなど、いくつかのアジャイル原則の恩恵を受ける可能性があります。あなたが説明しているそのようなペースの速い変更では、1週間は妥当だと思います。2週間は最終的にはうまくいくかもしれません。

十分に重要な要件が特定されたら、Project Owner役割を担当している人にそれらを承認してもらい、それらを構築する間、1週間ロックしてもらいます。あなたが忙しい場所に自分のために十分な仕事を割り当て、あなたの割り当てを力に知らせましょう。つまり、週あたり16ポイントの作業を作成でき、16ポイントの作業がある場合、その週は十分に活用されます。（ポイントの概念はアジャイルなワークストリームから来ています）

変更が週の真ん中に来る場合は、次の魔法の言葉を発声します。

[この新しい機能]、[この新しい変更]、[その他]を実行できますが、何をしたくないですか？

つまり、あなたは限られた資源であり、あなたは多くの仕事を受け入れることができるだけです。新しい作業項目が入ってくると、あなたはあなたがその限られたリソースであり、新しい項目にポイントを割り当て、この新しい入ってくる変更の代わりに他の項目をドロップ/変更することが許可されます。プロジェクトオーナーと一緒にイテレーションリストの優先順位を再設定すると、変更への対処に優れているはずです。

それよりも頻繁に要件が変更される場合は、環境の安定性について交渉する必要があるかもしれません。

「要件の変更」というフレーズは、IT担当者によって悪用されることがあります。あなたが説明しているのは確かに要件の変更ですが、これは次の1つ以上が原因である可能性があります（あなたのケースについて十分に理解していないため、以下が適用される場合と適用されない場合があります）。

1. エンドユーザーをできるだけ早く幸せにし、迅速な進捗を示すという経営者の野心。

2. 詳細な分析の欠如。アナリストは、なぜ何だけでなくなぜなのかについて質問する必要があることを覚えておいてください。アナリストは、注文を受けるだけでなく、「解決策」についてエンドユーザーと「考える」必要があります。

3. 要件の検証と確認、その後の承認のための正式なプロセスの欠如。

4. 正しくない人に、ビジネスアナリストやシステムアナリストの役割など、必ずしもトレーニングを受けているわけではない1つ以上の役割を実行するよう依頼する。

5. 限定的なプロトタイピング。

6. それが迅速に行われなければならないとの仮定/恐怖とそうでなければITのせいです。

上記のすべてに適切に対応しない限り、ITとビジネス/エンドユーザーとの関係はストレスになります。これは、上記の点が結論であるとは限らないことに注意してください。あなたの状況と同様にストレスの多い状況につながる他の要因がありますが、私はこのリストであなたがうまくいくと思います。

私はあなたがいくつかの方向からこれに取り組むべきだと思います：

1. すべての利害関係者（開発チーム全体を含む）にビジネスアドバイザーと（オフライン/オンラインで）会ってもらい、ドメイン、ビジョンを理解して、要件を一緒にブレインストーミングしてみてください。

2. 要件/ユーザーストーリーを形式化し、それぞれを評価
   します。優先度（緊急度/重要度）
   b。成熟度（どの程度明確に定義されているか-ステークホルダーの大多数によって理解され、同意されている*）
   c。複雑さ（概算）
   
   次に取り組む要件/ユーザーストーリーを選択するときは、3つの要素すべてを考慮に入れます。要件の成熟度が低い場合は、その前に調査ミッションを追加します。このミッションでは、すべての利害関係者に連絡し、要件の背後にある理由を調査し、要件をより明確に定義します（ユースケースを作成するか、ワイヤーフレームを作成して提示する）。その上に。

3. 各実装の前に設計する際は、いくつかのステップを先に考えてください。変更に対応する余地のある柔軟なアーキテクチャを設計してください。

4. SCRUMやKanbanなどのアジャイル開発プロセスを適応させてください。これにより、要件が変化する製品を開発するためのツールキットが提供されます。

また、この質問はここに当てはまるものの、より適切に当てはまるので、モデレーターにこの質問を（フラグを立てて）PM.stackexchange.comに移動するよう依頼することも検討してください。

（*）合意の利害関係者：ビジネス、マーケティング、プロジェクト管理、開発、QA。