おそらく簡単なもの：
政治的要件を認識するのに役立つ経験則や指針はありますか？
利害関係者の1人（上司、別の部門の責任者、または実際のユーザー）が、自分自身またはチームによって開発されているソフトウェアの機能または特定の特性を要求したとします。要件が政治的であるかどうかを判断するためのリトマス試験はありますか？
この質問は本当に単純であり、政治的要件にどのように対処するか、またはそれらがソフトウェアにとって悪いか良いかについてではありません。あなたがするように頼まれたことは、誰かの暗黙の、または実際に公然と述べられた政治的議題を追求することであるとどのように言いますか？
それは本当にあなたが知るのに役立ちますか？つまり、すでに政治ゲームに巻き込まれている場合は、とにかく知っているでしょう。そうでなければ、それはあなたが使うことができるものではありません。
とにかく機能を実装する必要がある場合は、そのまま使用してください。それがいくつかの管理ゲームの一部であることを知ることはあなたをやる気にさせるだけです。
とは言うものの、それが実際のユーザー機能なのか、ある種の政治的手段なのかわからないほどのアプリケーションに取り組んでいる場合は、おそらくすべてが政治的であるという安全な仮定です。
最善のアイデアは、すべての機能が何に使用されるかを知ることです。つまり、機能をどのように実装するかだけでなく、なぜそれを実行する必要があるのかを知ることです。目的のソリューションの背景を知ることは本当に役立ちます。それはあなたがあなたの顧客によりよく合うかもしれない代替の機能セットを提案することさえ可能かもしれません（多分あなた自身の政治的なゲームをすることさえあります）。
わからないことがある限り、プロジェクトをやらないでください。ある時点でのみ問題が発生します。
すべての要件は政治的なものであると想定する必要があります。
実装する一連の機能の決定に複数の人が責任を負う状況にある場合、すべての機能は事実上それらの人々の間の交渉です。その交渉は、それらの機能を政治的なものにします。
ただし、どの機能を出荷するかを決定する人が 1 人しかいない場合でも、それらの決定が政治的なものである可能性はかなり高いです。妥当な規模の組織 (たとえば 10 人以上) では、政治が行われます。その状況での政治は、「委員会の状況による設計」とは異なります。彼らは、委員会のシナリオに存在する「あなたが私の機能をサポートするなら、私はあなたの機能をサポートします」よりも、どの機能を出荷するかを決定する人の好意をカレーすることに焦点を当てます. しかし、そのプロセスはまだ政治的です。
私は政治から解放された開発環境を持つことが不可能だと言いたいのではありません。です。ただし、それをやってのけるために必要なことは次のとおりです。
これらのいずれかが欠けていると、社内政治の洪水が繰り返される運命にあります。
明らかに、それはトリッキーな質問であり、「政治的」の定義に大きく依存します。簡単な質問から始めます。*要件の作成者/作成者は、実際に問題のソフトウェアを使用していますか？
要件は上司からのものである可能性がありますが、実際のユーザーの翻訳された有効な要件である可能性があります
これが私が見たものです：
注意...これは、ユースケースが間違っているか不完全であることが原因である場合があります。また、これらの一部を意図的に開発に進めることを許可しました（たとえば、製品を販売しているが役に立たない、または少なくとも一般的にはオペレーターが使用しないアイキャンディー）。
SCRUM アプローチを使用します。機能を次のように説明しないでください。
「これとそれを次のように行う必要があります」
上記の文は、機能を実装するために知っておく必要があることをすべて説明していますが、機能を正当化するものではありません。私の SCRUM の本には、機能はストーリーとして書き留めるべきだと書かれています。ストーリーは次のようになります。
「<user-role> として、
<functionity> が必要です。
これにより、<business value> を取得できます」
そのようなストーリーを使用して正当化できない機能は、不当な機能であるため、実際に実装する必要はありません。
例えば
" Web ポータルの訪問者として、認証する方法が必要です。そのため、自分の顧客データにアクセスできますが、他の誰もアクセスできません"
これで、Web ポータルの認証が必要であることだけでなく、誰がそれを必要としているか (訪問者、基本的にはより集中的に使用することを計画しているすべての人) もわかり、なぜそれが必要なのかがわかります。いくつかの値。
その他の例:
"乗客として、予約したすべての旅程のリストが必要です。これにより、いつどこに旅行するかを把握し、概要を失うことはありません。"
「簿記係として、請求書を印刷するたびに手動で入力する必要がないように、顧客データに基づいて各請求書に消費税が自動的に印刷されるようにしたいと考えています」
すべての機能をそのように記述する必要がある場合、その機能が顧客向けであるか、それが本当に必要なのか、それとも単に上司/会社が必要としているものであり、なぜそれを必要とするのか (何が必要なのか) が自動的にわかります。その背後にある全体像?なぜ彼らはそれをしているのですか?)。