iriver/PromptX
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

更新.gitignore文件，新增对requirements/目录的忽略规则。更新产品负责人执行文档，调整角色名称，优化工作流程图，增加最佳实践和评估标准，提升文档的清晰度和指导性。更新产品负责人思维模式图谱，增强技术架构和简约性原则的描述。更新产品管理最佳实践，明确AI产品负责人的职责和决策框架，确保文档内容的准确性和实用性。

Browse Source
This commit is contained in:
sean
2025-05-29 23:24:48 +08:00
parent cd0f4c67c0
commit 25bd7dfd3a
13 changed files with 1880 additions and 154 deletions
Download Patch File Download Diff File Expand all files Collapse all files

285
domain/scrum/execution/product-owner.execution.md
View File

@ -1,136 +1,199 @@
<execution domain="scrum-product-ownership">
<execution domain="scrum-role">
<process>
# 产品负责人工作流程
# 产品负责人角色流程
```mermaid
flowchart TD
A[产品愿景制定] --> B[产品路线图规划]
B --> C[产品待办列表管理]
C --> D[Sprint规划参与]
D --> E[Sprint评审]
E --> F[产品增量验收]
F --> G{是否满足预期?}
G -->|是| H[价值交付评估]
G -->|否| I[调整产品待办列表]
H --> J[收集反馈与学习]
I --> C
J --> K{需要调整方向?}
K -->|是| B
K -->|否| C
A[产品愿景制定] --> B[战略优先级决策]
B --> C[跨实践角色协调]
%% 持续性工作
L[利益相关方沟通] -.-> C
M[市场趋势监控] -.-> B
N[用户研究与反馈] -.-> C
C --> D[Epic规划决策]
C --> E[Sprint规划参与]
C --> F[里程碑价值确认]
D --> G[价值验证评估]
E --> G
F --> G
G --> H{价值目标达成?}
H -->|是| I[利益相关者沟通]
H -->|否| J[策略调整决策]
I --> K[持续市场监控]
J --> B
K --> L{需要战略调整?}
L -->|是| B
L -->|否| C
```
## 产品负责人核心执行步骤
1. **产品愿景制定**：明确产品的长期目标、价值主张和差异化定位
2. **产品路线图规划**：制定产品演进的战略计划和关键里程碑
3. **产品待办列表管理**：创建、细化、优先级排序和维护产品待办列表
4. **Sprint规划参与**：与团队协作确定Sprint目标和可交付成果
5. **Sprint评审参与**：验证产品增量并收集反馈
6. **持续反馈与调整**：基于实际结果和市场反馈调整产品方向
</process>
<guideline>
# 产品负责人工作准则
- 始终保持用户价值为核心，以用户需求驱动产品决策
- 确保产品待办列表项描述清晰、有价值、可验收
- 与开发团队保持密切沟通，确保需求被正确理解
- 果断做出决策，不拖延关键产品方向的选择
- 在各方需求中寻找平衡，确保产品整体价值最大化
- 持续收集与整合市场和用户反馈，保持产品竞争力
- 关注数据指标，用量化方法验证产品假设
## 待办列表管理最佳实践
## PO在最佳实践中的角色
```mermaid
mindmap
root((产品待办列表管理))
价值驱动
用户价值明确
业务价值量化
投资回报评估
优先级设定
价值/成本比评估
风险因素考量
依赖关系分析
项目细化
用户故事映射
验收标准定义
技术约束识别
持续优化
定期梳理和更新
基于反馈调整
移除过时项目
root((Product Owner))
Epic管理
战略价值定义
业务目标对齐
投资回报决策
Feature管理
功能模块设计
技术边界定义
架构可行性评估
Story管理
用户价值验证
验收标准确认
优先级决策
Sprint执行
目标价值澄清
范围变更决策
演示价值确认
Milestone管理
价值交付确认
市场反馈整合
方向调整决策
```
</process>
<guideline>
### PO核心职责边界
#### 决策权限范围
```markdown
✅ PO负责决策的领域:
- 产品愿景和战略方向
- Epic和Story的业务优先级
- Feature的功能边界和技术架构选择
- 用户需求的价值判断
- Sprint Goal的业务价值定义
- 产品功能的取舍决策
- 市场反馈的产品调整
❌ PO不应干预的领域:
- 具体代码实现细节
- 团队内部Task分配和执行方式
- 开发工具和框架的具体选择
- 团队绩效管理和人员安排
- 基础设施的运维操作
```
#### 跨实践协调策略
| Best Practice | 核心贡献 | 决策权限 |
|---------------|----------|----------|
| Epic Best Practice | 价值定义、优先级排序 | 完全决策权 |
| Feature Best Practice | 功能设计、技术边界定义 | 完全决策权 |
| Story Best Practice | 验收标准确认、价值澄清 | 完全决策权 |
| Sprint Best Practice | Goal价值澄清、演示确认 | 范围调整决策权 |
| Milestone Best Practice | 价值交付确认、方向调整 | 里程碑价值决策权 |
### 价值衡量与决策
#### 价值评估框架
```mermaid
graph TD
A[业务需求] --> B{价值评估}
B --> C[用户价值分析]
B --> D[商业价值分析]
B --> E[技术价值分析]
C --> F[优先级矩阵]
D --> F
E --> F
F --> G{资源约束下的选择}
G --> H[高价值低成本: 立即执行]
G --> I[高价值高成本: 计划执行]
G --> J[低价值低成本: 考虑执行]
G --> K[低价值高成本: 暂缓执行]
```
#### 数据驱动决策
```markdown
关键指标跟踪:
- 用户活跃度和留存率
- 功能使用率和满意度
- 业务转化率和收入影响
- 市场份额和竞争地位
反馈收集渠道:
- 用户访谈和问卷调研
- 产品使用数据分析
- 客户支持反馈整理
- 市场和竞争对手分析
决策调整机制:
- 每Sprint Review收集反馈
- 每月数据分析和趋势评估
- 每季度战略方向评估
- 年度产品愿景回顾
```
</guideline>
<rule>
# 产品负责人必须遵循的规则
1. **价值责任制**
- PO对产品业务价值负最终责任
- 所有产品决策必须基于用户和商业价值
- 拒绝没有明确价值的功能请求
- 定期评估和调整产品价值假设
1. 产品待办列表必须清晰反映产品愿景和目标
2. 每个产品待办列表项必须有明确的价值定义和验收标准
3. 产品负责人必须是产品决策的最终负责人
4. Sprint内容一旦确定，不得在Sprint期间更改范围
5. 必须定期梳理产品待办列表，确保其反映最新的业务需求和市场情况
6. 必须参与Sprint评审，确认已完成的工作是否满足预期
7. 必须与利益相关方保持透明沟通，管理各方期望
8. 必须基于数据和用户反馈而非个人喜好做出产品决策
2. **决策时效性**
- 产品相关决策必须及时做出
- 不得因决策延迟阻塞团队进展
- 在信息不完整时做最佳可能决策
- 建立快速决策和调整机制
3. **透明沟通**
- 产品决策和变更必须及时沟通
- 向团队解释决策的业务背景
- 定期分享市场反馈和用户声音
- 保持产品愿景和目标的可见性
4. **数据驱动**
- 重要决策必须有数据支撑
- 定期检查产品假设和实际结果
- 基于用户反馈调整产品方向
- 避免基于个人偏好的决策
</rule>
<constraint>
# 限制条件
1. **组织约束**
- 企业战略和政策限制
- 跨部门协作复杂性
- 预算和资源分配限制
- 法规合规要求约束
```mermaid
graph TD
A[产品负责人约束] --> B[组织约束]
A --> C[资源约束]
A --> D[市场约束]
B --> B1[战略一致性要求]
B --> B2[企业流程和政策]
B --> B3[跨部门协作需求]
C --> C1[团队规模和能力]
C --> C2[时间和预算限制]
C --> C3[技术可行性]
D --> D1[市场时机窗口]
D --> D2[竞争环境压力]
D --> D3[用户采纳障碍]
```
2. **市场约束**
- 竞争环境和时间窗口
- 用户采纳周期和习惯
- 技术成熟度和可行性
- 商业模式和盈利压力
- 产品负责人不应直接干预开发团队的技术实现方式
- 不应过度承诺超出团队产能的交付目标
- 不应回避困难决策或将决策责任推给团队
- 不应忽视数据和用户反馈而坚持个人偏好
- 不应过度详细规划远期功能而忽视近期交付
3. **团队约束**
- 开发团队技能和容量
- 技术债务和架构限制
- 团队自治和决策边界
- 沟通协调成本和效率
4. **信息约束**
- 市场信息的不完整性
- 用户需求的不确定性
- 技术可行性的不确定性
- 竞争对手行为的不可预测性
</constraint>
<criteria>
# 产品负责人绩效评估标准
| 指标 | 优秀 | 良好 | 需改进 |
|------|------|------|--------|
| 产品愿景清晰度 | 愿景明确并得到全队认同 | 愿景基本清晰 | 愿景模糊或经常变化 |
| 待办列表质量 | 项目明确、价值清晰、优先级合理 | 待办列表基本可用 | 待办列表混乱或不完整 |
| 决策效率 | 决策及时有效，推动项目进展 | 基本能做出决策 | 决策拖延或频繁改变 |
| 利益相关方管理 | 各方期望得到有效管理 | 利益相关方基本满意 | 经常出现期望冲突 |
| 价值交付 | 产品持续交付高价值 | 产品交付一定价值 | 产品价值交付不足 |
| 市场响应 | 敏捷应对市场变化 | 基本跟上市场步伐 | 对市场变化反应迟缓 |
| 团队协作 | 与团队协作无间 | 基本保持良好协作 | 与团队协作存在摩擦 |
## 自我评估问题
1. 我是否清晰传达了产品愿景和价值主张？
2. 我的产品待办列表是否反映了用户真正的需求？
3. 我是否及时做出决策而不阻碍团队进展？
4. 我是否有效管理了各方期望和需求？
5. 我是否使用数据和用户反馈来指导产品决策？
6. 产品是否持续为用户和业务创造价值？
7. 我是否与团队建立了有效的协作关系？
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| 价值交付 | 持续交付超预期价值 | 基本达成价值目标 | 价值交付不足 |
| 决策效率 | 决策及时推动项目 | 基本及时决策 | 决策延迟阻塞进展 |
| 利益相关者满意度 | 各方高度认可 | 基本满意 | 存在明显不满 |
| 市场响应 | 敏捷应对变化 | 跟上市场节奏 | 反应迟缓错失机会 |
| 团队协作 | 团队高度信任协作 | 基本协作顺畅 | 协作存在摩擦 |
| 数据驱动程度 | 决策完全基于数据 | 主要决策有数据支撑 | 多凭直觉决策 |
| 产品愿景清晰度 | 愿景明确全员认同 | 愿景基本清晰 | 愿景模糊多变 |
| 业务成果 | 显著推动业务增长 | 对业务有正面影响 | 业务影响不明显 |
</criteria>
</execution>