問題タブ [product-management]

私の会社は、スクラムの方法論を採用しようとしましたが、成功はまちまちでした。論文は、私たちが問題を抱えているいくつかの分野です。これらをどのように処理しますか？

1. 製品マーケティングから製品までの要件の追跡。すべての要件を個別に追跡するために JIRA を試しており、実装のために選択されたときにそれぞれにリリースを割り当てています。
2. ストーリーを作成するのは誰ですか? 効果的な小さなストーリーを作成するのに十分な知識がない製品管理者、ドメインの知識を持たない可能性のある開発者、その中間のアナリスト?
3. 機能仕様
   1. それらを書きますか、それとも単にストーリーの定義に取り入れようとしますか?
   2. ストーリーごとに機能仕様を書いていますか? 機能ごと？
   3. 機能仕様とストーリーの関係をどう捉えていますか？
4. 役職に VP が付いている人からの質問に答える: 「[今から 8 か月後] までに何が得られるでしょうか?」

私たちは、ソフトウェアでやらなければならないことの大量のバックログを、多くの異なるカテゴリで抱えています。たとえば、次のとおりです。

• 当社の製品が解決すべき新しい問題領域
• 既存の問題領域をサポートする新機能
• 既存のユーザーから要求された新しい機能
• 使いやすさと「見た目」の向上
• バックエンドへのアーキテクチャのアップグレード
• バグの修正

これらすべてを賢明な方法で管理することは、製品管理の仕事ですが、多くの理由で注意が必要です。まず、さまざまなものを保持するさまざまなシステムがあります (ファイル内の市場要件ドキュメント、バグ データベース内のバグ、ヘルプ デスク システム内の顧客要件、イントラネット上のエンジニアリングのウィッシュ リストなど)。次に、アイテムの多くは、サイズ、範囲、複雑さ、そしてもちろん価値が大きく異なります。つまり、選択は、リストを優先順位で並べ替えるほど単純ではありません。

現在、私たちはかなり大きく、複雑な製品と多くの顧客を抱えているため、基本的なソリューション (スプレッドシート、Google ドキュメント、ベースキャンプの To-Do リスト) だけでは、これに対処するには十分ではありません。物事をさまざまな方法でグループ化し、継続的に優先順位を付け、現在行っていることとこれから行うことを明確にする方法が必要です。ツールを管理するだけで誰かの時間を費やす必要はありません。

ビジネスが常に既存の顧客にとって最も価値のあることを行い、新しい顧客の獲得を支援し、ソフトウェアの内部を正常に保つことができるように、これをどのように管理しますか?

これは開発側とは異なることに注意してください。すべてを反復的かつアジャイルな方法で開発し、設計と実装のために何かを選択したら、それを実行できます。一番難しいのは、次に何をすべきかを考えなければならない部分です！

うまくいく方法やツールは見つかりましたか？もしそうなら、共有してください！(そして、答えも知りたい場合は、質問を評価して、表示されたままにしてください:)

補遺:もちろん、最初にすべてのバグを修正するのは良いことですが、顧客のマシンに実際にインストールされる実際のシステムでは、それは必ずしも実用的ではありません。たとえば、非常にまれにしか発生せず、修正に膨大な時間とアーキテクチャ上の大変動が必要なバグがある場合は、しばらく放置することがあります。または、誰かが何かを使いにくいと考えているバグがあるかもしれません。それを修正するには、その領域の大幅な改良を待つ必要があると考えています。そのため、すべてをすぐに修正するのではなく、忘れないように開いたままにしておく理由はたくさんあります。さらに、最も難しいのはバグ以外の優先順位付けです。何も持っていないと想像してみてください:)

私たちのチームは、どのようにして「プロダクト オーナー」から要求を収集し、摩擦をできるだけ少なくしながらも使いやすい方法で収集できるでしょうか?

ここにガイドラインがあります-それができない、またはビジネスが品質を気にするという決定を下す必要があるという投稿はありません、やだやだ。私が働いている製品は、何年にもわたって成功を収めてきた小さなグループです。私は彼らがそれを一段と高めるのを手伝いたいだけです。

基本的に、私は 1 人のプロダクト オーナーを含む 6 人か 7 人のチームに所属しています。彼女は素晴らしい仕事をしていますが、いくつかの異なる役割をこなしています (非常に小さなチームではよくあることだと思います)。通常、要件は散発的に与えられます (電子メールのやり取り、対面でのディスカッション、ミーティングなど)。それらはシステムに入力されることはなく、必要な機能を誰もが忘れたため、機能がリリースされなかったり、リリースが延期されたりすることがあります。

似たような状況で、これを克服する方法を見つけた場合は、ぜひお知らせください。この状況を緩和するためのコードを喜んで書きますが、プロダクト オーナーが何かを成し遂げるために行かなければならない Web サイトにはなりません。彼女は非常に忙しいので、これらの要件を収集するためにチームとして協力する方法が必要です。

私は現在、次のようなことを考えています: 開発者とチーム メンバーは、面と向かって議論された要件を収集し、wiki ページで議論された機能について簡単なメモを書きます。これらのページが更新されるたびに製品所有者に通知され、正確性を確保する責任は製品所有者にあります。

長所: 機能の記録がいくつかあります。短所: 開発者は、通常なら責任を負わないことに対して責任を負うことになります。私はここでそれで大丈夫です。こういう時こそチームワークだと思います。

もちろん、これを行うと、製品所有者が機能の正確さを保証するのに十分な時間がないことがわかります。最終的に彼女は過負荷であり、これはその事実を示すのに役立つと思いますが、最初にそのことに注意を引くことができる必要があります.

提案はありますか？

PS 彼女の時間は非常に限られているため、話し合いの後に要件を入力する必要があると期待するのは合理的ではないと考えられます。彼女には、それらについて一度話し合って先に進む時間しかありません。

私は Web ベースの製品を持っており、それをファイアウォール内でホストできる (または) クライアントによってローカルにホストされる製品に変換しようとしています。

私が予見する課題のいくつかは次のとおりです。

1. 海賊行為の防止
2. サポート
3. パッチとバージョン (リリース) の維持
4. ソース管理 (カスタマイズの場合)

これに関するあなたの経験のいくつかを共有してください..

私たちは、クライアントが顧客に配布する製品を開発します。クライアント企業の管理者がインストーラーをエンドユーザーに送信する前に、構成を変更できるようにする必要があります。この場合の構成の変更は、エンド ユーザーのコンピューターでいくつかのレジストリ エントリを作成することを意味します。どうすればいいですか？

クライアントのヴィンテージ ツールのコレクションを管理するための、ユーザー フレンドリーな PHP アプリを探しています。彼のコレクションを単に整理するだけのものは何も見つかりません。私が見つけることができる最も近いものはショッピング カートですが、コレクションを売りたくないので、それは彼が必要としているものではありません。私はこれを自分でコーディングする時間がなく、約束したよりも時間がかかっているため、彼は動揺しています。

助言がありますか？私はそこに何かがあると確信しています。

以下の理由により、製品開発に携わるオフショア分散環境で働く従来の大規模なソフトウェア製品組織が、スクラムでのアジャイルの精神に従うことは容易ではありません。

1. 彼らの製品開発は反復的ではありません。製品エンジニアリング チームは、反復的なシステム エンジニアリングを数回繰り返した後、特定のリリースの製品要件、製品アーキテクチャ、および設計を事前かつ正式に最終決定します。これに対する変更は発生する可能性がありますが、大規模ではありません。

2. 製品エンジニアリング チームは、作成された仕様に基づいてオフショア チームがこの製品を構築するようになりました。これらの大規模なオフショア チームは、ここでは保証されていないため、反復的で経験的なモードで作業することはできません。

3. ただし、製品マネージャーは、オフショア チームによる製品開発を定期的に確認するために、短いイテレーションで段階的な納品を要求する場合があります。

4. これらのオフショア チームが、定義された正式なプロセス (経験的ではない)、管理者が管理する環境 (権限が与えられていない)、漸進的な開発アプローチ (反復的で適応的ではない) を使用してスクラムの変形に従うことができれば、彼らにとって非常に役立つでしょう。

5. この状況で実装された真のスクラム アプローチは、非常に偽善的に見えるかもしれません。ただし、従来のウォーターフォールのようなシナリオ向けのスクラムの正式な変形を彼らに提供できれば、彼らはそれを全員の利益のために使用する可能性があります。

このコンテキストについては、 scrumtales.blogspot.comのブログで詳しく説明しようとしました。

これはできますか？

プログラム マネージャーとプロダクト マネージャーの違いは何ですか? 実際に役割/責任に違いがありますか、それとも私たちの用語はほとんど同じ意味で使用されていますか.

現在、Webベースのソリューションを構築しており、展開の準備がほぼ整っていますが、解決しようとしている問題ドメインに関する最初の仮説を実際に検証していないと感じました。そこで、ほとんどの参加者がターゲットユーザーである会議に参加することにしました。会議から抜け出したいのは

1）最初の仮説が正しいかどうかを確認します

2）仮説が正しい場合、私たちのソリューションはユーザーフレンドリーな方法で問題に対処しますか。

3）彼らはそれを使用するか、最終的に購入しますか。

私は約半日しかありません。私はここでいくつかのオプションを考えています：

a）歩き回ってデモを人々に見せます。

b）もっと聞いて質問する。

c）できるだけ多くの名刺を集め、会議後に接続します。

これらを最も効果的に行う方法についての提案はありますか？ありがとう

ここには多くのエキスパートデータベースコアデザイナーがいることを知っているので、stackoverflowについてこの質問をすることにしました。

私は、デジタルカメラ、プリンター、冷蔵庫など、現実の世界で入手可能なすべての製品のインデックスを作成することを主な目的とするWebサイトを開発しています。ご存知のように、各製品には独自の仕様があります。たとえば、デジタルカメラには、重量、レンズ、シャッターの速度などがあります。各仕様にはタイプがあります。たとえば、価格（スペックのように見えます）は数値です。

最も標準的な方法は、特定の製品に必要な仕様を適切なタイプで作成し、それを製品に割り当てることだと思います。したがって、製品ごとにPRICEを作成し、タイプ番号を設定する必要があります。

これが私の質問です。たとえば、番号のタイプのPRICEが以前に作成されており、テーブルで価格を検索して製品に割り当てるだけで、すべての仕様を含む仕様のテーブルを作成できますか。この方法の問題は、ユーザーが重複したエントリを作成するのを防ぐ良い方法が見当たらないことです。彼は必要な仕様を見つけることができなければなりません（以前に追加されている場合）。また、同じ名前の仕様がいくつかある可能性があるため、彼が見つけた仕様が実際に必要なものであることを知ってもらいたいです。異なるタイプと使用法。彼がそれを見つけられない場合、彼はそれを作成します。

何か案は？

- - - - - - - - - - - - - - アップデート - - - - - - - - - - - -------

私の質問はdbの柔軟性についてではありません。2番目の方法では、ユーザーは仕様表を台無しにするだろうと思います。彼らは何千もの重複したエントリを作成します、そしてまた私は彼らが彼らの適切なスペックを見つけられないと思います。