頻繁な要件変更にどのように対処しますか？
私の現在の職場では、かなりストレスの多い（私の意見では）状況に対処しています。
私たちは新しいプロジェクトの開発を開始し、いくつかの要件を取得して実装し、「ビジネスアドバイザー」と呼ばれる人（ビジネス要件を知っているがプログラムを使用しない人）に見せます。その人は顧客の視点からアプリケーションを評価し、それをテストすることになっています。
ここに「プロセス」がどのように見えるか：
- ビジネスアドバイザーは、Windowsメッセンジャーで1時間か2時間、上司と夕方話し合います
- 翌日、その会話のコピーをメールで受け取ります。私はそこからタスクを選択し、報告されたバグをチェックすることになっています（これは多くの場合、バグではなく、テストが不十分で、過去の施設を忘れています）。
- 私は変更を実装し、実装が受け入れられ、1〜2週間で、彼らが望んでいるのは望ましくないことが判明しました（彼らは5分間ソフトウェアを見てきた潜在的なクライアントと話し、彼は変更を提案しました）-私は新しい変更を行う必要があります
誤解しないでください。要件が変わる場合があることを理解しています。気が動転するのは、職場で変更が発生する頻度と、「管理」がいかに簡単かによって、新しい要件が与えられたり、既存の機能に根本的な変更が加えられたりすることです。
同時に、厳しい締め切りに取り組んでおり、ソフトウェアを進めるのではなく、サークルを運営している印象があります。
この状況への対処方法を教えてください。これは通常の状況であり、私はそれについて過敏になっていますか？
可能な場合は、メールで送信された会話を取り、それを要件文書にしてください。そこから収集できるタスクを一覧表示し、優先度であると思われるタスク順に並べ、それぞれに見積もりを割り当てます。次に、次のリリースでどの機能が必要かを尋ねます。
基本的に、管理者があなたが何を構築しようとしているのかを認識しているある種のフィードバックループを強制します。メッセージが届くまで、独自の要件文書を作成します。
ストーリーカード
あなたの状況は ユーザーストーリー の導入に適していると思います。これらは、マネージャーが優先順位を設定するための継続的でインタラクティブな方法を提供するのに非常に役立ち、1週間後にアイデアに戻ってそれが機能しないことに気付いたときに、それらを破棄することもできます。
現実の世界では、要件は定期的に変化します。プラス面としては、ソフトウェアの構築を完了して出荷する前に、それについて調べます。ソフトウェアの直接のユーザーからのフィードバックサイクルが厳しく、これは実際には素晴らしいことです。
ここでの最大の問題は、変更を管理するその場限りの方法にあるようです。あなたはアジャイル/スクラムが「製品の所有者」と見なし、フィードバックを提供しますが、プロセスは十分に文書化されておらず、よく考えられていません。
次のステップを知らせるために、おそらく Scrum のモデル、および 有効な製品の所有者 が何であるかについてのモデルを確認する必要があります。
したがって、この特別なプロセスではなく、「ビジネスアドバイザー」とより密接でより有益な関係があり、議論している変更の結果について誰もが同じページにいる世界に移動することを目指します。 。
あなたの現在のプロセスでは、これらの人々が消費するリソースとお金を取り戻さずにアイデアをブレインストーミングするのは簡単すぎます。これらすべての機能が必要な場合は、「ゲーム内のスキン」を入手する必要があります。
会話のメールを受け取り、それが単なるスプレッドシートであっても、何らかの機能/バグ追跡アプリケーションに入れます。新しい追加をビジネスアドバイザーに送り返して、各アイテムの承認または訂正を依頼してください。サインオフに加えて、優先順位を付ける必要があります（どれを最初に希望しますか？）。
彼らが承認した後、テストのためにアイテムが完了する予定のスケジュールを送り、テスト/完了の承認を行う時間にコミットするように依頼します。
このタイプのドキュメントを作成することが、プログラマーになった理由ではないことを知っていますが、これらのリストを捨てるリスクを冒すか、苦労して稼いだコードを捨て続けることができます。
押し戻す。担当者は、これらのリクエストのコストを確認する必要があります。
プロセスは、反復でロックされるなど、いくつかのアジャイル原則の恩恵を受ける可能性があります。あなたが説明しているそのようなペースの速い変更では、1週間は妥当だと思います。最終的には2週間でうまくいく場合があります。
十分に重要な要件が特定されたら、Project Ownerロールをサインオフして、ビルドする間、1週間ロックします。あなたが忙しいところにあなた自身のために十分な仕事を割り当てて、あなたの割り当てを力に知らせてください。つまり、週あたり16ポイントの作業を作成でき、16ポイントの作業がある場合、その週は完全に活用されます。 （ポイントのコンセプトはアジャイルなワークストリームから来ています）
変更が週の真ん中に来る場合は、次の魔法の言葉を発声します。
[この新しい機能]、[この新しい変更]、[その他]を実行できますが、何をしますかやりたくない？
つまり、あなたは限られた資源であり、あまり多くの仕事を受け入れることができません。新しい作業項目が入ってくると、あなたは自分がその限られたリソースであり、新しい項目にポイントを割り当て、この新しい入ってくる変更の代わりに他の項目をドロップ/変更することが許可されます。プロジェクトオーナーと一緒にイテレーションリストの優先順位を再設定すると、変更への対処に優れているはずです。
それよりも頻繁に要件が変更される場合は、環境の安定性について交渉する必要があるかもしれません。
要件の変更は必ずしも悪いことではありません。重要なことは、顧客を覚えておくことです。この場合、上司が顧客である可能性があります。これらの一定の要件の変更が上司に最も役立つ製品を生産する能力を制限していることを上司に通知する必要があります。絶えず変化に対応することで、ビジネスのメリットが得られる可能性は十分にあります。もしそうなら、それは彼らのビジネスモデルであり、あなたは何も悪いことをしていませんが、その場合は丘陵に走ることをお勧めします！
要件の変更に不満を抱いている人は、多くの場合、各変更をいかにうまく管理しているかを評価されます。 「十分に処理された変更の数」というこの測定基準は、おそらく本当の問題の原因です。 上司とより良いメトリクスについて話し合うことを検討してください。絶えず変化する要件に直面しているときは、絶えず変化する要件に適応できるコンテンツを書くように努めています。毎日シミュレーションを実行してデータを分析する代わりに、シミュレーションを実行してデータを分析するプロセスをより安価にするツールを作成し、時間の経過とともに報酬を獲得します。それでもクレイジーすぎる場合は、ツールを作成するためのツールを作成することもできます。
「要件の変更」というフレーズは、IT担当者によって悪用されることがあります。あなたが説明しているのは確かに要件の変更ですが、これは次の1つ以上が原因である可能性があります（あなたのケースについて十分に知らないため、以下が適用される場合と適用されない場合があります）。
エンドユーザーをできるだけ早く幸せにし、迅速な進捗を示すという経営者の野心。
詳細な分析の欠如。アナリストは、何だけでなく、なぜなのかについて質問する必要があることを覚えておいてください。アナリストは、注文を受けるだけでなく、「ソリューション」についてエンドユーザーと「考える」必要があります。
要件の検証と確認、その後の承認のための正式なプロセスの欠如。
正しくない人に、ビジネスアナリストやシステムアナリストの役割など、必ずしもトレーニングを受けているわけではない1つ以上の役割を実行するよう依頼する。
限定的なプロトタイピング。
それが迅速に行われなければならないとの仮定/恐怖とそうでなければITのせいです。
上記のすべてに適切に対応しない限り、ITとビジネス/エンドユーザーとの関係はストレスになります。これは、上記の点が結論であるとは限らないことに注意してください。あなたの状況に似たストレスの多い状況につながる他の要因がありますが、私はこのリストであなたがうまくいくと思います。
私はあなたがいくつかの方向からこれに取り組むべきだと思います：
すべての利害関係者（開発チーム全体を含む）にビジネスアドバイザーと（オフライン/オンラインで）会ってもらい、ドメイン、ビジョンを理解して、要件を一緒にブレインストーミングしてみてください。
要件/ユーザーストーリーを形式化し、それぞれを評価します。
a。優先度（緊急度/重要度）
b。成熟度（どの程度明確に定義されているか-大多数の利害関係者によって理解され、同意されている*）
c。複雑さ（概算）
次に取り組む要件/ユーザーストーリーを選択するときは、3つの要因すべてを考慮に入れてください。要件の成熟度が低い場合は、その前にリサーチミッションを追加します。このミッションでは、すべての利害関係者に連絡し、要件の背後にある理由を調査し、要件をより明確に定義します（ユースケースを作成するか、ワイヤーフレームを作成して提示する）。その上に。各実装の前に設計する際は、いくつかのステップを先に考えてください。変更に対応する余地のある柔軟なアーキテクチャを設計してください。
アジャイル開発プロセスを適応させるようにしてください。 SCRUMまたはかんばん-これは、要件が変化する製品を開発するためのツールキットを提供します。
また、この質問はここに当てはまるものの、より適切に当てはまるので、モデレーターにこのフラグをPM.stackexchange.comに（フラグを立てて）移動するよう依頼することも検討してください。
（*）合意の利害関係者：ビジネス、マーケティング、プロジェクト管理、開発、QA。