先说一下背景，大厂和小厂都呆过。呆过野蛮生长的传统集团的互联网部门，呆过上市的中型二线互联网公司，呆过APPLE STORE行业APP排名第一的产品公司，现在呆在全球一万多员工的超级独角兽公司。
其实各个产品公司的迭代流程都大同小异，因为规范起来，迭代流程就是那一套。目前觉得差异比较大的就是使用的工具和具体管理的方式，这个也是很想跟大家一起讨论的，看看有没有更加高效的方式或工具。
这篇文章大概会从以下几个方面分开讲述，不排除我写着写着会修改大纲的可能：
一、需求收集
二、需求整理
三、优先级划分 及 需求交付（直白地说就是怎么写 PRD 文档）
四、需求评审 及 产品评审
五、需求变动（针对由于其他特殊问题导致的需求变动，产品经理该如何做到“不背锅”）
六、工具（滴答清单、为知笔记、confluence、JIRA、Axure）
如果感兴趣的话，还有……
七、写在最后
下面开始，是正文。
先看一下大概的流程图，每个环节再具体解释
其实不同类型的产品，需求来源会不太一样。这里会尽量列出所有可能的来源。
用户反馈：产品中包含『用户反馈』页面，用户通过『用户反馈』入口，直接反馈过来的一手信息。
用户研究：通过用户调研、用户访谈、用户拜访、可用性测试等方法获得的用户一手信息。
客服团队：通过客服团队收集并反馈的二手信息。
市场/商务/BD团队：通过市场/商务/BD团队接触用户时，获得的用户需求。
内部成员需求：测试团队、开发团队、运营团队，针对产品提出的需求。
战略型需求：来自竞品的竞争压力产生的需求，团队制定的产品发展方向下的需求。
其他需求：老板需求。（牛逼的产品经理可以忽略这一项……）
其实看似需求来源很多，再综合一下，分析出来就是两种：
1、外部需求；
2、内部需求。
针对于外部需求，又分为『一手信息』获得的需求和『二手信息』获得的需求。『一手信息』就是产品经理直接从用户方获得的需求信息，是未中途经人加工过的。经过其他职能岗（如客服、市场、商务等）转述给产品经理的信息称为『二手信息』，这类需求相对而言质量没有『一手信息』高，需要产品经理再进行处理和分析。建议产品经理都找到方式直接跟用户进行沟通，而不是要假借他人之耳去听取需求。
内部需求，就是我们非常熟悉的了，经常会从不同小组或者部门的同事那里获得新的需求内容，一般这些功能是针对于产品功能的可用性或者优化的。再就是根据产品战略制定的需求内容。
这两部分需求其实获取起来没那么难，外部需求就是，想尽一切方法去接触用户、然后跟用户沟通。内部需求就是，多跟同事们沟通，没事儿多聊聊，问问看他们对于产品的看法。战略型的需求内容就不说了，这个涉及到不同公司的管理方式，说出来又是长篇大论的东西，甚至免不了要吐槽……
如果需求收集做的比较到位，到手的需求是多且杂的，基本是千奇百怪什么都有。这种情况下，要做的流程图上已经比较详细的说明了。
1、只保留有效需求
剔除那些看上去很明显不合理的需求。这个步骤需要依赖产品经理自身的经验和对自己产品的了解程度。
『对自己的产品很了解』，这一条看上去简单但挺难做到的，需要的不仅仅是产品经理自身的能力，还需要行业的经验、在公司呆的时间足够长。只有满足这些条件后，产品经理才能够很高效准确地做到『只保留有效需求』。
2、需求分类
有效需求进一步分类就是：需讨论的需求、需开发的需求、已有功能支持的需求
其中，确定开发的需求就能顺利的进入到需求池了。需求池字面上来讲就是管理需求的大池子，我觉得这形容词挺形象的。在这个大池子里，你需要对需求进行优先级的维护，方案的制定、补充、完善。现在我是通过，JIRA + confluence 来进行管理和维护的，JIRA 和 confluence简直是神器好么，配合起来用简直无敌。这个之后会在【六，工具】篇中进行具体的介绍。
3、标签
当需求过多的时候，也可以给需求打上标签。如果说按照迭代排期来进行需求分类是基于时间线的纵向管理的话，打标签则是横向管理。可以让你更清晰的看到现在的需求在每一个模块所占的比例和待做的内容。
现在比较常用的标签大概是这几类，当然最好是根据自己的公司和产品的情况进行分类，我这里只是提供一个思路：
三、优先级划分及需求交付
这两步其实占据了很多产品经理的很大一部分工作量和思考时间吧……
1、优先级划分
其实关于这个模块，我之前写过一些 文章/回答 也有讲怎么进行优先级划分。然后一直有跟大家推荐过一本书 Jeff Patton 的《用户故事地图》，我从中受益很多，也希望这本书能帮助到大家的工作。关于这本书，还写过一系列的文章，算是我超级用心写的第一篇文章了，我把链接贴在下面，感兴趣的可以看一看：
这篇文章之前是分段发出来的，结果发现有些影响阅读体验，所以合成一篇了…大家将就看……
需求的类型在这里可以大致分为3种：
1、新功能；
2、迭代优化；
3、bug fix（这里的 bug，可能是开发代码 bug、可能是产品流程 bug）
针对1和2如何确定优先级呢？首先需要搞清楚以下内容：
对于3如何确定优先级呢？首先需要搞清楚以下内容：
比如我现在的公司，『安全』就是高压线，如果发现什么问题对于『安全』因素有影响，哪怕可能性不是那么大，优先级都是 P0。
再多说一句，我个人对于产品经理好坏的判断标准，其中有两个维度就是：
产品经理必须要能够很快速的收集到关于当前问题的尽可能多的『情报』，因为你所有的判断都是需要依靠这些情报的。
优柔寡断的产品经理，是我最忌讳的，不愿意深交。产品经理需要你能够基于当前的所有信息，尽量快、准地做出判断，并且你需要为你的判断承担相应的责任。
2、需求交付
应该有很多人期待这个部分？看到好多文章都是在教产品经理如何写需求文档。我这边就不细说了？列个大纲，大家看看有没有帮助吧，如果需要细说，请在评论区留言，我再根据留言补充一下内容……
目前，我们这边的最完整的需求内容包括：
不是所有的需求都需要进行需求评审的，只有一些相对『难搞』的需求才会进行需求评审。这个是需要靠产品经理自己进行把控的。
1、需求评审
（1）什么需求需要需求评审
（2）目的
确认需求的必要性；粗略地确认方案的可靠性和可行性。
（3）参与人
产品经理，主力开发，主力设计，其他和需求相关的、具有话语权的人
（4）准备内容
原型稿（着急的话），草稿也可以（厉害的话），方案装脑子里，白板现画也可以，总之，需要有一个相对全面的方案。不需要对细节进行描述，但各种情况需要考虑到。
（5）会议内容
产品经理可能会需要说到这些内容：
接下来就是，各种讨论咯……
2、产品评审
（1）什么需求需要进行产品评审
都需要，大需求大说，小需求小说。
（2）目的
让需求涉及到的所有成员，都能够全面的了解到这个需求的方案、流程、细节，并完全确定最终方案；开发的同事需要对需求进行评估，给出排期和工时；确定后续各方的工作内容；预知的风险点也需要暴露。
（3）参与人
产品经理，各执行开发，各执行设计，需求方（运营？业务方？等等），需求涉及到的协作方等。有些公司可能还会需要 leader 参会，这个就是看各个公司内部的协作方式……
（4）准备内容
（5）会议内容
产品经理可能会需要说到这些内容：
如果是由于自己考虑不周到导致的需求变动，那就只能自己想办法了，请开发兄弟们多吃顿饭，反思一下为什么会导致这个问题，然后让自己下次不再犯错。
但是，如果说你是作为服务方，需要对接多个公司内部的『甲方』，当需求方频繁的变更需求，又该怎么处理呢？
其实，说出来的话，方法挺简单的。
1、产品评审通过后，不再允许修改方案；
2、如果需求方需要再修改方案，很简单：填张表，邮件发送给产品经理，抄送开发 leader 及各部门领导。
表内容需要包括：需求变更功能点，需求变更原因，需要重新开发的人力（几人、天），需求变更人。
总结一下我自己比较常用的工具：
1、滴答清单
滴答清单是我现在正在使用的，类似的 GTD 工具还有奇妙清单、todoist、Microsoft to-do等，选择自己习惯的就好。
GTD 工具，能够归纳现在手头待做的事情，按顺序安排好你之后一周每一天的工作内容。
当工作内容太多了之后，就很容易就不知道做什么。每天花3分钟，排好今天需要工作的内容，工作效率就会高很多。并且，给任务设置好提醒时间，你也不容易漏掉重要的事情。
再有就是，可以根据项目或产品进行工作内容的整理，可以很清楚的知道，每个项目当前是什么进度，后续需要做什么。当你能够在视觉上区分各个项目/ 产品后，你的大脑里对于各个任务之间的关系和逻辑也就会更加清晰了。
再有就是，不知道大家的公司有没有需要写周报或者日报。是不是有时候不知道写什么？那是因为你从来没很好的记录你今天到底做了些什么。有了 GTD 工具，也很容易进行工作总结，能够很清晰的知道你这周做了些啥。回顾的时候，也会有成就感，感觉这周没白过。
2、为知笔记
这个没啥好说的了……笔记类的工具都差不多，关键是要找到合适自己的记录方式，并要坚持去维护。其实我身边有很多朋友做的比我好太多了。我就贴张图吧，大家看看就得。关键还是要自己去试去做。
3、confluence 和 JIRA
confluence 和 JIRA 是 Atlassian 这家公司出品的两个软件系统。
confluence 就是一个团队协作的文档管理软件，可以用于整理团队项目相关的所有文件内容。
类似于现在的在线文档协作平台，石墨啊、腾讯文档啊，N 个人可以同时对文档进行编辑。但是 confluence 的功能更加强大。
这些都是非常实用并且能提高效率的功能。
JIRA 是一个需求管理、开发管理、项目管理的平台。功能强大到可怕，随你怎么用。目前我还没发现我想做但是它做不了的。
由于这个截图太难打马赛克了，所以我直接从网上下载了一些图，也能够说明 JIRA 的强大。
直接可以通过Epic来管理项目，每个Epic还能看到每个Sprint的迭代。基本每个迭代需要完成的内容都能一眼都看清楚。
还能根据自己团队的迭代方式建立迭代阶段，比如常见的是：需求池——交互设计——视觉设计——开发分配——开发中——测试——回归。有些团队可能在开发阶段会再进行一些细分，这个根据团队来就好。
还能很好的进行版本管理，哪些版本现在处于什么状态、共有多少个需求/bug、完成了多少、还剩多少，都能一眼看清楚。
Axure 和 ZEN 我就不说啦~ 都是大家都非常了解的软件了。
如果你问我现在的迭代啊、管理啊、是不是完全按照上面说的内容来的，我肯定要说：当然不是啊……有一些项目还是没有按照这个方式走的……
每个团队和产品所处的状态都不一样，以上的方法不是一定都要按照这些东西做或者说这些方法就是最好的。
比如，当团队一共就一个产品经理、一个设计、两个开发，并且坐的很近回头就能看到的情况，用这些方式效率可能就会太低了。像小团队协作，如果大家都是靠谱的人，每天一个10分钟内的站会基本就能摆脱 jira 的需求了。产品经理文档也不需要写这么复杂，需求点说清楚、关键时间点标清楚就够了。
之所以写这些是希望，如果你在团队协作或者迭代方面存在一些问题或者疑惑的时候，这篇文章能够给到你一些参考。
希望每个产品经理都能够跟团队配合的好好地、不要吵架，能很顺畅的一起把产品越做越好~
最后，谢谢大家的支持！（鞠躬~）
