機能のリクエストとソフトウェアの変更をどのように管理しますか？
私はソフトウェアエンジニアです。過去数年間、私は事実上存在しないソフトウェアプロジェクトマネージャーになりました。したがって、R＆D /エンジニアリング部門で私たちの正気を保つために、顧客は自分の要求に私に来ることに慣れています。私はこの分野での経験がないため、ソフトウェアプロジェクトのプロジェクトマネージャーとして働くのは初めてです。私は他のものを管理しましたが、ソフトウェアは管理していませんでした。
では、ソフトウェアプロジェクトをどのように管理し、優先順位を付けるのですか？リクエストはまれな間隔で届くため、他の誰かのために何かに取り組んでいる可能性が非常に高く、次に、別の人が取り組む必要のある「急ぎ」の仕事にやって来ます。先着順、先着順と言う方が簡単ですか、それとも、お金が最も多い人ですか。
私たちが思いついたのは、現在のプロジェクトと今後のまたは将来の機能要求について話し合うために、隔月で営業/エンジニアリング会議を開催することでした。セールスエンジニアはプロジェクトマネージャーになり、少なくとも最新の製品と調和します。以前は、エンジニアリングにそれを渡し、それを忘れるのは簡単でした。これにより、ソフトウェアエンジニアが行う必要のある負荷が軽減され、時間を賢く使用するために販売と管理に負担がかかることになります。
お客様がリクエストの緊急性について不満を言うほど、お客様自身が開発者でもない限り、通常はリクエストに緊急性がないことを示しています。大学の教授の一人は、緊急事態が重要なことを妨害しないようにいつも私たちに言っていました。
通常、リクエストは次の順序で分類します（YMMV）：
- 最近のアップグレードまたは移行に関連する問題（最も重要）。
- セキュリティ修正。
- 既存のシステムの機能が壊れています。
- RC機能とベータ機能の機能が壊れています。
- 有料機能のリクエスト。
- ユーザーベースの大部分からの研究開発機能のリクエスト。
- 1人または2人のユーザーからのR＆D機能リクエスト。
この最後のリクエストは、「緊急、昨日必要です」というリクエストになる傾向があるため、実際にはもっと時間がかかります。実際には、ユーザーが実際に何が必要か、またはビジネスモデルをどのようにサポートするかを完全に検討することはほとんどありません。ほとんどの場合、これらの緊急の要求は、一度配信されると、最終的には1回または2回使用されて忘れられます。そして、一度忘れられると、セキュリティホールと予期せぬ結果の終わりのない頭痛になります。
好き 
の原則：
- QI-重要かつ緊急
- QII-重要だが緊急ではない
- QIII-重要ではないが緊急
- QIV-重要ではなく緊急ではない
- 機能/バグ/リクエスト追跡システムをセットアップし、顧客/同僚にチケットを提出してもらいます。彼らがチケットを提出しなければ、あなたはそれをしていません。チケットは十分に詳細であり、実行可能である必要があり、「緊急度」を指定する必要があります（「今すぐ必要」vs「必要な情報」）。
- 新しいチケットを確認し、慎重にスコープします。チケットの費用を、ドル、開発者、リソース、時間で入力します。これは必須です。顧客が何かに実際に費用がかかることを確認すると、「緊急度」フィールドに非常に異なる選択肢が表示されます。
- 毎日、提出されたチケットとその緊急度に基づいてスケジュールを把握します。スケジュールを他の人に見えるようにして、自分が何をしているのか、そして将来のリクエストに対応できるかどうかを明確にします。
要件の変更が非常に重い変更管理システムによって管理されるプロジェクトを見てきました。これは悪いです。顧客が変更管理を提出する煩わしさを経験したくないため、ソフトウェアが彼らのニーズに適合しないため、多くの重要な変更は起こりません。プロセスを回避するために、いくつかの小さな変更が「レーダーの下」でずれてしまいます。そのため、ソフトウェアはあなたが思っていることとさえ一致しません。
逆に、プロジェクトマネージャーが「リアクティブ」とは、ユーザーからのすべてのリクエストにプログラマーが応答することを意味するプロジェクトを見たこともあります。ハック。基本的に、開発者は何もいなくて、資格のあるセールスエンジニアのチームがあります。
したがって、これらの2つの極の間にうまく機能する状況があることを期待するかもしれません。私は、あなたにとって最適なのは個人的な選択と位置付けの両方だと思います。各変更のコストを把握することには、確かに価値があります。スクラムのようなフレームワークでは、コストをストーリーポイントで表すことができ、チームは各反復で実行する作業と、利用可能な総作業量とをトレードオフできます。プロダクトマネージャーがいる場合は、その人に変更または機能リクエストの予想されるメリットを数値化させることができます。これは通常、保護された収益（これを行わなかった場合に離脱する顧客の数）と引き付けられた収益（これを実行した場合に到達する顧客の数）の観点から行われます。これは優先順位付けに役立ちますが、製品マネージャーの偏見や個人的な好みを反映することもできます。
ここにいくつかの考え...
市場にはたくさんのソフトウェアがあります http://www.fogcreek.com/ with Fogbugz、GeneXus USA with XPM http://www.genexususa.com/xpm など.
これは、新機能のリクエストとバグ修正や独自のアイデアとのバランスをとる芸術のようなものです。あなたは次の冬のために食べ物を手に入れる必要がありますが、今日も食べる必要があります。
時間、リソース、範囲があり、それを最大限に活用します。
ヘンリーフォードもかつて有名に言った、「もし私が顧客の言うことを聞いていたら、彼らにもっと速い馬を与えたでしょう」...
個人的に：動的であり、あなたが言ったようなルールを置かないでください...そして他の人のルールに注意してください...彼らは彼らのコンテキストではうまくいくかもしれませんがあなたのルールではうまくいかないかもしれません。
私が働いている会社は、JIRAと呼ばれるWebベースのツールを使用してプロジェクト関連の側面を処理し、ヘルプデスクシステムを使用して、RFC機能を介して変更要求を処理しています。
これまでに見た答えは良いです。私が具体的に説明する1つのことは、いくつかの要求に対して「いいえ」と言うのが上手でなければならないということです。
お客様に緊急度の設定を許可すると、ほとんどの場合、緊急度は「高」（またはそれ以上）になります。
あなた（あなた自身、またはセットアップに応じてチーム）は、これらの要求を評価し、独自の基準に基づいて優先順位を付ける必要があります。