上文提到了产品经理要频繁跟工程师沟通需求，这种需求的沟通是有迹可循的。绝不是漫无目的、东榔头西锤子，一有什么想法就跑过去吧啦吧啦说一大通。

需求沟通要做到有迹可循，离不开需求管理。

互联网上有各种资料和文章论述如何需求管理，每家公司每个团队的工作方式各有不同，需求管理的具体实现方式也有差别。

不需要过于拘泥形式，只要遵循一些基本要点，结合实际情况去实施，能帮助团队提高效率就行。毕竟，鞋子合不合适，自己说了才算。

以下，笔者结合工作经验和Scrum的一些原则，粗略谈谈对需求管理的理解。

需求管理涉及了需求池、产品需求、迭代需求列表、需求优先级划分。

1. 需求池

需求池记录了各种来源的需求，不仅仅是产品经理，团队任何人都可以记录。

比如头脑风暴时，研发部、市场部、运营部、客服部、管理层的人员会提各种想法，这时候鼓励他们都记录下来。我们用Confluence建立了需求池，里面有基本的书写格式，包括编号、需求描述、提交时间、备注等等，需求提出者按格式填写就行。

Confluence记录的好处是，团队里每个人都能在需求池编辑，并且所有的内容都是公开、可追溯的。这就相当于提供了一个公共场所，在里面大家可以畅所欲言，有助于激发团队沟通需求的活力。

而如果用Excel之类的，往往就产品经理一人在维护，即使把Excel发给成员填写，这邮件一来一回，然后产品经理还要统一归整，效率和效果都大打折扣。

当然，需求池里面的内容，主要还是产品经理在操心。

用户调研的材料收集、用户的反馈意见、竞品分析时看到有价值的点或者解决方案，产品经理都要一一记录，提防遗忘。

2. 产品需求

需求池记录的是原始的需求材料，来源五花八门，这些材料是无法直接交给程序员的。产品经理通过对原始材料的加工提取，写成一个一个的用户故事，就形成了产品需求。按照Scrum的说法，个人理解产品需求列表对应于Product Backlog。

产品需求，就完全由产品经理写了。

产品需求，书写格式包括了编号，需求池编号，迭代版本号，用户故事，需求优先级，行动项，备注，需求状态，Jira工作项等等。

编号

编号就是需求列表的顺序号，主要是作为当前需求的唯一性标识。

需求池编号

产品需求对应的需求池来源。

迭代版本号

需求被纳入在哪个版本里实现。

用户故事

按照惯例，三段式写法：“作为……，希望……，以便……”，作为后面是角色，有些产品可以细化到游客、注册用户、付费用户、不同级别的用户等，希望后面写用户想要的功能，以便后面写价值，即实现了功能，能够给用户带来什么价值。

比如朋友圈的某个用户故事，“作为旅行达人，希望用照片和文字记录我的足迹，以便查看和分享”

需求优先级

这部分后续文章重点叙述

行动项

记录实现用户故事需要的条件和步骤，这部分内容主要给工程师查阅。

备注

其它任何信息，如：需求期望完成时间、被拒绝原因、暂缓原因。

需求状态

我们只用了两个状态记录需求的完成情况，TBD表示待办，DONE表示完成。

Jira工作项

用户故事对应的开发内容。Jira工作项里面详细描述了需求内容，UI和交互细节，这些信息是经过团队需求评审后的终稿，不但程序员的开发，测试工程师的验证工作也严格依照Jira工作项进行。

Jira是任务跟踪的好工具，同上面提到的Confluence一样，都出自Atlassian公司，不少企业喜欢用Confluence+Jira的组合进行知识库管理和项目管理。

3. 迭代需求列表

这部分工作项内容来源于产品需求，对应于Scrum的Sprint Backlog。另外还有各种Bug，有些是产品经理从以前遗留的Bug里挑选的、需要在本次迭代解决的，有些来自测试人员在本次版本发现而提出的。在这个需求列表里所有工作项和Bug，理论上都需要在本次迭代发布前全部解决。

按照Scrum的工作方式，产品经理从Product Backlog里移动产品需求到一个Sprint里，一个Sprint就是一个迭代周期。

在一个迭代周期里，产品需求是确定的。这种确定性体现在：

第一、工期、任务范围、干系人是明确的

第二、产品需求是经过团队评审确定的

总之，有了确定性，产品经理和工程师的沟通就能够在一个频道上进行，剩下的，就是工作过程中细节的推进了。

4. 结语

产品经理跟程序员能不能愉快的沟通，需求管理这个环节是少不了的了。整个研发、测试团队后续的工作都依赖于产品需求，产品验收、发布的标准也依赖于此。

当然，需求管理不是固化的板块，它是动态更新的。我们基本上是每天更新，因为除了有源源不断的需求进来，研发每天在Jira完成的工作状态也会反映到需求管理里，这样，产品迭代的进度就一目了然。