5 人の関係者に、複数の執筆観点に基づいた 1 つの明確な PRD を提供する

文章を整える前に、範囲を固定する

現在の決定をわかりやすい言葉で書きます。誰がどのような結果を必要とするのか、どの条件が適用されるのか、何が範囲外なのか、どの疑問が未解決のままなのか。提案された決定には、承認された決定とは異なるマークを付けます。そうしないと、洗練された書き直しにより、提案が静かに要件に変わってしまう可能性があります。

Atlassian は PRD を、製品の目的、機能、ユーザーのニーズ、成功基準を共有するための文書と説明しています。AI に表現を変えてもらうときも、その共通の目的を制約にします。関係者別の説明は同じ要件を理解するためのもので、同時には実現できない五つの製品を作るためではありません。

適切な質問を引き起こす架空の要件

架空のレポート製品で「ユーザーは簡単にレポートをエクスポートできる」という初稿を考えます。承認済みの範囲は、ワークスペース所有者が現在のフィルターに合う表を UTF-8 CSV ファイルに出力できることです。定時エクスポートは対象外です。ファイルサイズの上限、空の結果、失敗時の動作は未決定です。これは例示用の要件で、Colay の機能ではありません。

より明確な核心ステートメントは次のとおりです。ワークスペース所有者は、アクティブなテーブル フィルタに一致する行を UTF-8 CSV ファイルとしてエクスポートできます。除外項目と未回答の質問をその横に置きます。欠落しているパフォーマンスの決定を、モデルが発明した期間に置き換えないようにしてください。

8 つの視点をリクエストして統合

Ask separatelyで選択した対応可能なエージェントを使用して、最初の解釈を検査します。 8 つの要求された視点には 8 つの独立したモデルは必要ありません。実際の製品の選択を示す意見の相違はすべて保持してください。たとえば、空のテーブルがヘッダーのみのファイルを生成するかどうかは、平均化するためのスタイルの好みではなく、チームの決定です。

この PRD の抜粋を確認してください: [テキスト]。承認された決定: [事実]。提案: [まだ承認されていません]。範囲外: [リスト]。未解決の質問: [リスト]。ユーザーの結果、簡潔な範囲、テストのしやすさ、権限、障害時の動作、パフォーマンス、サポートのニーズ、経営層向けの背景を強調する 8 つの定式化を作成します。すべてのバージョンは、同じ承認された範囲を保持する必要があります。技術的な制限を考え出したり、未解決の疑問を黙って解決したりしないでください。バージョンごとに、そのバージョンで明らかになっているあいまいさを 1 つ特定します。次に、1 つの標準要件、受け入れケースの例、および提案された所有者を含む意思決定リストを提案します。すべての新しい提案を提案としてマークします。

1 つの要件に基づいてレビュー パケットを作成する

架空のエクスポート要件の場合、承認されたケースでは、所有者がアクティブなフィルターに一致する行を含む CSV を受信していることを確認できます。非所有者が期待するインターフェイスや空の結果応答については、チームが決定しない限り疑問が残ります。この区別により、AI が生成したテスト リストが偶発的な範囲になることを防ぎます。

1. 中心となる文案を一つ選び、承認済みの決定一覧と比較します。役割、条件、出力、対象外の範囲を一語ずつ確認します。
2. すでに行われた決定に対する受け入れケースの例を追加します。未解決の動作を含むケースには、合意されたテストではなく質問としてラベルを付けます。
3. 文言の編集を範囲の提案から分離します。新しい行制限、パーミッション ルール、またはリカバリ パスについては、たとえ文章が読みやすくなったとしても製品の決定が必要です。
4. 通常のレビュー手順で、正式な要件文、重要な変更点、担当者付きの未解決質問をレビュー担当者に渡します。

焦点を絞った文言パスには、macOS ショートカットを使用します

PRD を開いたまま、デフォルトの ⌘⇧K または設定したショートカットで Colay のオーバーレイを開きます。必要な抜粋と共有可能な文脈だけを貼り付けます。これは下書き用の画面を開く操作で、文書を自動で読んだり PRD を承認に回したりするものではありません。

レビュー後、どのコメントが文言を変更し、どのコメントが製品の決定を変更したかを記録します。正規の要件とその例を一緒に更新します。必要に応じて、PRD 全体を繰り返し書き直すのではなく、難しい段落のプロンプトを再利用します。有益な結果は、チームが下す実際の意思決定のセットがより小さく、より明確になることです。

質問と回答