作为产品经理，最大的痛苦可能就是产品需求的管理，既要广泛的听取用户和小伙伴们对产品的意见，又要不时地应付老板突如其来的奇思妙想。而这些还只是需求的收集，还有需要评审的，评审中的，评审过了等待开发的，开发完成了的等到测试的等等。此外还有版本的管理，bug的管理等。如果没有对需求进行很好的管理很有可能造成工作上的疏漏甚至是产品重大功能的缺失，所以对需求的有效管理势在必行。
第一步，广泛的收集需求
#截图来自teamin示例，略有修改，下同
需求的收集不是越多越好，但是在不知道是不是必需的时候全部搜收集过来，从里面找到符合产品定位和功能需求的也不失为一个方法。把收集到的需求用列表的方式列出来，列的时候可以采用标签的方式标明需求的来源，方便后期的管理。
第二步，需求分解
在把所有的需求列出来后，需要对收集到的需求进一步进行分解细化，比如常见的注册登录功能，用户可以使用那些工具进行注册，注册完成后后可否与第三方账号绑定，登录时可以用那些方式进行登录等这些都是需要产品经理去考虑，而且需求的粒度划分的越细，对于后期开发的实现难度就越低，换句话说产品更容易做成功。
第三步，需求计划安排
对收集到的需求进行评审，是否采用，采用的需要在哪个版本里实现，并将评审通过的需求添加到相应的实现产品版本里，没有通过的放在另一边。通过评审的需求可以指定不同的执行者来负责这条需求的最终实现，也可以给需求制定截止时间并通过添加标签的形式来标明需求的重要紧急程度，以示区别。
第四步，需求跟踪
需求评审通过后，需要技术哥哥去开发实现了，需求的开发进展是怎么样的呢，这个可以通过看板的方式来实现。这个流程也是可以自定义的，添加你认为是必须的环节，比如测试验收，产品验收环节等。通过这个看板，需求甚至是整个产品的进展一目了然，再也不用为纷繁复杂需求感到头疼了。
看到这里是不是发现产品的需求管理其实也没有那么难？
心得：
1，政治任务永远优先级P0，学会在劝阻失败的情况下，帮老板证明他是对的。
2，每一期产品需求的收集是不可能完善的，因为需求发起者会忘，或者老板们会临时起意，所以要搞严格的需求冻结时间来保护开发的工作。不冻结就永远有需求，而且其实所有的需求都有自己存在的价值和道理，你要拒绝是千难万难。
3，即便你冻结了需求，他们也会找老板走特殊审批来新增需求，而老板一般不会拒绝，除非你哭着对他说已经真的不能再加了——也没什么鸟用。最好是在他们走特批之前就打消他们的念头，或者许诺下一期一定做这个需求。
4，P2的需求永远不会有人想起来去做，所以你希望看到上线的功能尽量放P1。做一小部分需求，拒绝一大部分需求，拒绝不了就拖着，需求自然会消失。LESS IS MORE，做产品能解决业务问题就可以了，70分就行，不要老想打造完美的产品。
5，你想象中的那个100分产品在用户看来也就70分，你那些天才一样的创意多半是YY，即便你做了数据分析和用户调研。100个创意里有一个能被用户用起来就不错了，其实做产品跟搞艺术很像，你信不信？
6，如果一个产品功能比较刚需，而用户能用，只是产品设计比较垃圾，他们会用下去。除非出现一个超越你10倍的对手。如果你的产品没有刚需功能，却有很多用户，那一定是走了狗屎运。我见过太多设计一流却没什么刚需或者没什么长期需求价值的产品。
7，一般那个超越你10倍对手叫苹果，还好他们老板已经死了，暂时安全了。
8，一次超越对手一大截很容易，每天每年都超越对手一点点很难，做产品要有耐性——当然一般公司老板没什么耐性。By UC老板，阿里移动总裁 俞永福。
9，需求管理混乱的本质是你没什么话语权。
