作为产品经理，总会遇到：
- 开发出来的功能和设计的规则不一致
- 看起来很简单的功能开发评估好几天
- 负责的项目经常延期
- 不知道开发进展问题
这些问题，80%原因是因为开发评估工作没有做好。
对于中小企业，特别是敏捷开发为主的团队中，产品经理往往需要承担部分项目管理，其中最重要的就是需求评审后的开发评估工作了。在评估会议上，开发团队会对本期需求制定实现方案，并会根据方案的难易程度评估具体每个开发活动的开发时间。评估会议代表整个开发工作的起点，只要评估得准确，那么后续按照计划执行即可，能够减少很多风险。可是现实情况却不尽人意，常常会遇到：
- 开发对功能规则理解有偏差
- 需求遗漏或需求蔓延
- 评估的工时和实际所用的工时差距过大
并且这类问题往往在开发后期才会暴露出来，轻则导致改动方案，费时费力；重则导致项目延期，影响整体目标。
尽管经过需求评审会，团队成员已经对设计方案达成了共识，但仍不能保证每个人都记住和理解。因此在开发评估会前，还需要通过一种结构化的方式全局呈现需求，这种方式就是WBS（工作分解结构），也可以理解为详细的功能列表。
对于产品经理，功能列表肯定不会陌生，在需求之后原型之前，我们就会通过功能列表梳理产品结构。但此处的功能列表则需要拆解的越详细越好，因为它是给开发看的，便于他们对要做之事有一个整体的了解，同时又可以避免需求遗漏、蔓延和理解不一致的情况出现。如同去菜市场买菜，相比于提前列出购买清单，如果是到了菜市场才决定买什么，那大概率会多买或少买。
给自己看：
一级功能：查看试卷列表
二级功能：选择试卷
三级功能：
- 在线作答、保存。
给开发看：
一级功能：查看试卷列表
二级功能：选择试卷
三级功能：
- 上/下一篇，备注切换题目时需要自动保存
- 标记/取消标记
- 在线作答
- 保存，备注：主动保存
- 返回试卷列表，备注：自动保存
可以看到，给产品经理自己看的功能列表会相对简单一些，只需写出大致的功能架构，为后续的原型设计提供指引。而给开发看的WBS则需要遵循MECE原则，将各功能分解地很详细，并且需要把重要的规则补充完整，这样有助于开发进行评估。比如对于“切换题目”功能，如果不写出“切换时需要自动保存答案”这一规则，前端人员仅看功能列表时就会忘记调用保存接口。
总结：
- 产品经理对结果负责，有好的过程才有好的结果
- 保姆式产品经理：做开发的倾听者、支持者和引导者
- 通过WBS引导开发正确分解活动
- 通过敏捷扑克引导开发准确估算活动
- 把控进度，及时调整