《从点子到产品经理》摘3

需求管理：有三类需求不记

没有说清楚原因，不记（你做个XXX出来，别管那么多。）

不说清逻辑的需求，不记（啊，这里我也没有搞懂，你先看看）

不是实际遇到的需求，不记（哎，我觉得可能有人会这么用）

分析需求时，先梳理逻辑再出方案。能画流程图的画流程图，能画逻辑图的画逻辑图，能画脑图的话脑图，穷举整体的逻辑。

讨论方案时，产品经理一起探讨。

做可行性评审时，技术人员多从逻辑角度提问题。

需求文档，建议要把完整的功能描述文档整理好，而不是每次都迭代一份文档，只关注当前修改的内容。

针对跟业务部门的合作，制定的规范如下：

1、所有需求必须通过邮件发出，否则，不予理会。（目的：为了记录内容和明确责任人）

2、业务方的需求提出者是固定接口人，不接受其他人的需求。（目的，避免业务未内部达成一致的情况下提需求）

3、产品这方也设立固定接口人。（目的，防止需求重新设计）

4、需求的状态每周固定时间发布。（目的：让需求来源方放心，了解需求正在推进的状态）

5、有延期的需求，发送邮件给相关需求方，告知原委。（目的：让需求方了解延期的原因）

《纸牌屋》里面有句话，“你得先学会划船，再去学掌舵”。作为船长，可以不去做水手的工作，但不能不理解水手的工作。

//待续