機能のリクエストとソフトウェアの変更をどのように管理しますか？[閉まっている]

私はソフトウェアエンジニアであり、過去数年間、事実上ソフトウェアプロジェクトマネージャーになりました。そのため、R＆D /エンジニアリング部門の健全性を維持するために、お客様はリクエストに応じて私に来ることに慣れています。私はこの分野での経験がないので、ソフトウェアプロジェクトのプロジェクトマネージャーとして行動するのは初めてです。私は他のものを管理しましたが、ソフトウェアは管理していません。

それでは、ソフトウェアプロジェクトをどのように管理し、優先順位をマークしますか？リクエストはまれにしか届かないため、他の人のために何かに取り組むことができ、その後、別の人が「急いで」仕事をする必要があります。ファーストカム、ファーストサーブと言う方が簡単ですか、それとも最もお金を持っている人ですか？

顧客が自分のリクエストがどれほど緊急であるかについて不満を言うほど、それ自体が開発者でもない限り、通常はリクエストが緊急ではないことを示す良い兆候であることがわかりました。私の大学の教授の一人はいつも、私たちに緊急のせいで重要なものを中断させないように言っていました。

通常、リクエストは次の順序で分類します（YMMV）：

1. 最近のアップグレードまたは移行に関連する問題（最も重要）。
2. セキュリティ修正。
3. 既存のシステムの機能が壊れています。
4. RCおよびベータ機能の機能が壊れています。
5. 有料の機能リクエスト。
6. ユーザーベースの大部分からのR＆D機能のリクエスト。
7. 1人または2人のユーザーからのR＆D機能のリクエスト。

この最後のものは、「緊急、昨日必要です」というリクエストになる傾向があるため、実際にはもっと時間がかかります。実際には、ユーザーが実際に必要なものや、ビジネスモデルをサポートする方法を完全に検討することはほとんどありません。ほとんどの場合、これらの緊急リクエストは、一度配信されると、1回または2回使用されて忘れられます。そして、忘れられると、セキュリティホールと意図しない結果の果てしない頭痛になります。

私はの原則が好きです：

1. QI-重要かつ緊急
2. QII-重要だが緊急ではない
3. QIII-重要ではないが緊急
4. QIV-重要ではなく、緊急でもない

1. 機能/バグ/リクエスト追跡システムをセットアップし、顧客/同僚にチケットを提出してもらいます。彼らがチケットを提出しない場合、あなたはそれをしていません。チケットは、実用的であるように十分に詳細である必要があり、「緊急性」（「今すぐ必要」と「持っている必要がある」）を指定する必要があります。
2. 新しいチケットを調べて、慎重にスコープします。チケットのコストをドル、開発者、リソース、および/または時間で入力します。これは不可欠です。顧客が実際に費用がかかるものを確認すると、「緊急度」フィールドに非常に異なる選択肢が表示されます。
3. 毎日、提出されたチケットとその緊急度に基づいてスケジュールを把握します。スケジュールを他の人に見えるようにして、あなたが何をしているのか、そして将来のリクエストのために空いているかが明らかです。

要件の変更が非常に重い変更管理システムによって管理されているプロジェクトを見てきました。これは悪いです。多くの重要な変更は発生しません。これは、顧客が変更管理を提出するという面倒な作業をしたくないため、ソフトウェアがニーズに合わないためです。プロセスを回避するために、いくつかの小さな変更が「レーダーの下」に潜り込んでしまうため、ソフトウェアはあなたが思っていることとさえ一致しません。

逆に、プロジェクトマネージャーが「リアクティブ」とは、ユーザーからのすべての要求にコーダーを応答させることを意味するプロジェクトを見たこともあります。ハック。基本的に、開発者はいませんが、優秀なセールスエンジニアのチームがいます。

したがって、これら2つの極の間でうまく機能する状況があることを願うかもしれません。あなたにとって最適なのは、個人的な選択と状況の両方であると思います。各変更のコストを把握することには間違いなく価値があります。スクラムのようなフレームワークでは、コストをストーリーポイントで表現でき、チームは各反復で行う作業と利用可能な総作業量をトレードオフできます。プロダクトマネージャーがいる場合は、その人に変更または機能要求の予想される利点を定量化してもらうことができます。これは通常、保護された収益（これを行わなかった場合に離脱する顧客の数）と引き付けられた収益（これを行うと到着する顧客の数）の観点から行われます。これは優先順位付けに役立ちますが、製品マネージャーの偏見や個人的な好みを反映することもできます。

ここでいくつかの考え...

あなたを助け、市場でたくさんのソフトウェア、ありhttp://www.fogcreek.com/は FogBugzの、XPMとのGeneXus米国でhttp://www.genexususa.com/xpmなど、

これは、新機能のリクエストとバグ修正および独自のアイデアのバランスをとる芸術のようなものです。あなたは次の冬に食べ物を手に入れなければなりませんが、今日も食べなければなりません。

時間、リソース、範囲があり、それを最大限に活用してください。

ヘンリー・フォードはかつて有名に言った、「もし私が顧客に耳を傾けていたら、私は彼らにもっと速い馬を与えていただろう」...

個人的に：動的であり、あなたが言ったようなルールを置かないでください...そして他の人のルールに注意してください...彼らは彼らの文脈ではうまくいくかもしれませんが、あなたではありません。

私たちが思いついたのは、隔月で営業/エンジニアリング会議を開催し、現在のプロジェクトと今後の機能要求や今後の機能要求について話し合うことでした。セールスエンジニアはプロジェクトマネージャーになり、少なくとも彼らが最新の製品に合わせて調整します。過去には、それをエンジニアリングに引き渡し、それを忘れるのは簡単でした。これにより、ソフトウェアエンジニアの負担が軽減され、時間を賢く使用するために販売管理に負担がかかる可能性があります。

私が働いている会社は、プロジェクト関連の側面を処理するJIRAと呼ばれるWebベースのツールと、rfc機能を介して変更要求を処理するヘルプデスクシステムの2つの主要なアプリケーションを使用しています

これまでのところ私が見る答えは良いです。具体的に説明することの1つは、一部の要求に対して「いいえ」と言うことを得意とする必要があるということです。

顧客が緊急度を設定できるようにすると、ほとんどの場合「高」（またはそれ以上）になります。

あなた（あなたの設定に応じて、あなた自身、またはチーム）は、これらのリクエストを評価し、独自の基準に基づいて優先順位を付ける必要があります。