私たちは、ソフトウェアでやらなければならないことの大量のバックログを、多くの異なるカテゴリで抱えています。たとえば、次のとおりです。
- 当社の製品が解決すべき新しい問題領域
- 既存の問題領域をサポートする新機能
- 既存のユーザーから要求された新しい機能
- 使いやすさと「見た目」の向上
- バックエンドへのアーキテクチャのアップグレード
- バグの修正
これらすべてを賢明な方法で管理することは、製品管理の仕事ですが、多くの理由で注意が必要です。まず、さまざまなものを保持するさまざまなシステムがあります (ファイル内の市場要件ドキュメント、バグ データベース内のバグ、ヘルプ デスク システム内の顧客要件、イントラネット上のエンジニアリングのウィッシュ リストなど)。次に、アイテムの多くは、サイズ、範囲、複雑さ、そしてもちろん価値が大きく異なります。つまり、選択は、リストを優先順位で並べ替えるほど単純ではありません。
現在、私たちはかなり大きく、複雑な製品と多くの顧客を抱えているため、基本的なソリューション (スプレッドシート、Google ドキュメント、ベースキャンプの To-Do リスト) だけでは、これに対処するには十分ではありません。物事をさまざまな方法でグループ化し、継続的に優先順位を付け、現在行っていることとこれから行うことを明確にする方法が必要です。ツールを管理するだけで誰かの時間を費やす必要はありません。
ビジネスが常に既存の顧客にとって最も価値のあることを行い、新しい顧客の獲得を支援し、ソフトウェアの内部を正常に保つことができるように、これをどのように管理しますか?
これは開発側とは異なることに注意してください。すべてを反復的かつアジャイルな方法で開発し、設計と実装のために何かを選択したら、それを実行できます。一番難しいのは、次に何をすべきかを考えなければならない部分です！
うまくいく方法やツールは見つかりましたか？もしそうなら、共有してください！(そして、答えも知りたい場合は、質問を評価して、表示されたままにしてください:)
補遺:もちろん、最初にすべてのバグを修正するのは良いことですが、顧客のマシンに実際にインストールされる実際のシステムでは、それは必ずしも実用的ではありません。たとえば、非常にまれにしか発生せず、修正に膨大な時間とアーキテクチャ上の大変動が必要なバグがある場合は、しばらく放置することがあります。または、誰かが何かを使いにくいと考えているバグがあるかもしれません。それを修正するには、その領域の大幅な改良を待つ必要があると考えています。そのため、すべてをすぐに修正するのではなく、忘れないように開いたままにしておく理由はたくさんあります。さらに、最も難しいのはバグ以外の優先順位付けです。何も持っていないと想像してみてください:)