实战：B2B端产品经理工作指南

有很多人或许会问，定义产品Roadmap的价值点是为什么，作为产品经理只需顾好当前的需求就行。但是，很多坑就是这样被产品经理埋下的，当然后面还得你自己去填坑。一个好的产品经理，首先站的角度一定是企业，其次才是用户，想歪了你就不是一个合格的产品经理。这种话不是废话官话，而是在跟你阐述你给自己在企业的定位，跟着企业发展走，你的产品才能走的更远。过度沉溺在自己的产品世界里，早晚会吃亏。

我自身的工作指南如下：

1. 梳理产品Roadmap计划。占比15%。

2. 将产品需求录入需求Backlog，定义Sprint。占比25%

3. 对开发需求进行优先级排序。占比15%。

4. 讨论任务细分、人员分工（不超过两天）。占比15%。

5. 确定迭代计划功能，启动sprint。占比10%。

6. 甘特图追踪任务进度，关键时间节点区分。占比10%。

7. 明确化迭代开发内容，时间安排及发布时间。占比10%。

3.2 负责迭代开发的过程管理

整体开发的过程管理包括启动过程、计划过程、执行过程、监控过程、收尾过程等诸多方面，作为产品经理，要能在每个环节融入到开发团队去，做好开发、测试、运营的配合，才是一个合格的有产品心的团队。

但是，或疏于自己工作职责划分的缘故，也有产品经理会置之这一块内容。现在网上有很多人在讨论开发与产品的矛盾，还有偏激的看法，但实际你是不参与实际的开发工作，而是你的角色从主导者变成了配合者，你参与的只是开发过程中的过程管理。还有，这个过程不等同于任务进度管理，也不同等于产品开发管理。

我自身的工作指南如下：

1. 每1周或2周按Sprint更新任务进度。占比20%

2. 组织每日晨会：昨天的工作，今天的工作，遇到的问题。占比35%。

3. 检查任务迭代情况。占比20%。

4. 控制迭代范围的变更。占比20%。

5. 其他事项管理。占比5%。

3.3 验收需求的实现情况

产品经理有验收需求的标准，是有助于大家对目标需求的一致理解、对目标需求的最终确认、对目标需求的实现验证。当然，需求实现的验证是通过测试来实现的，产品经理要最终根据预先需求定义以及给测试传递的预期结果进行划分和充分结合，验证和确认需求的完成度。必要时，还需要上线试运行，或者由客户来试运行测试和验收需求。

我自身的工作指南如下：

1. All tasks closed。占比20%。

2. 功能演示，核对产品功能。占比40%。

3. 确认功能符合预期。占比20%。

4. 迭代回顾会议，总结存在的问题。占比10%。

5. 下一步需求验证计划。占比10%。

4. 产品发布管理

（编辑：宿州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!