综上，基本一个PRD文档就算完成了，但在工作中一个功能模块或一个版本的迭代往往还需要涉及其他需求，涉及人力、财务资源的需求，以及对于每次评审或小团队沟通的记录。这里我也一并同步出来自己在工作中做的一些需求描述，也可以集中放置于项目文档或该PRD文档中。

性能需求

服务需求

营销需求

安全需求

法务需求

帮助需求

异常场景

沟通记录

风险描述

性能需求可以以表格的形式对相应的功能模块进行要求，如红包点击弹出的时间在3S内，成功率是99%，并发数是20000。

2.服务需求

这个涉及到产品客服，产品人员需要知道要占用客服时间、相应问题解决的方案是什么？每个问题的优先级是什么？产品需要从客服人员中得到什么信息？这个需要PM对当前产品数据分析，才能更好的对接资源，总不能要求其他部门把全部资源用在你手上吧。

这里首先要说明的是关于成本建议做一个标准，如果是按照价钱就统一为钱；如果为时间就统一为时间；预知服务频率需要PM进行数据分析，给予一个恰当的范围。

3.营销需求

营销需求和上方的服务需求同样，也是需要产品经理进行数据分析，为达到目标计划一个预计营销需求，当然其营销的平台与方式可以和营销部进行策划沟通。

4.法务需求

法务需求与以上2点需求类似，建议可以合成为一张表格，将分别的需求资源供应方分类，这样可以更快的在一张表中了解该项目的资源消耗情况。

5.财务需求

同法务需求一样

6.帮助需求

帮助需求可以解释为FAQ培训，将产品上线后对于该项目涉及人员和部门进行培训，建立相应的FAQ，并且对于活动类模块也需要运营提供活动FAQ。

7.项目风险

如果是功能模块迭代可以说明为版本风险，但是对于产品的迭代中，其需要明确新增、取缔的风险，将其可能存在的风险隐患进行描述

提前说明一些风险能够给予BOSS一些心理的准备，当然这个风险的预测也不是万能的，如果出现一些技术无法解决的问题也需要PM注意埋坑。但将能够预测的风险进行预测，也是PM的一个硬战。

以上就是关于我3年产品进阶中，目前PRD文档的撰写，关于交互与字段的描述相信能够为产品新人提供帮助

最后关于评审中的沟通会议记录，我也同步一下模板

这样有了会议沟通记录之后，相信产品人能够减少一些坑或者识别一些坑，避免一些人冤枉PM说：领导这是你之前说的！XX这是你说的！

#专栏作家#

kevin，微信公众号：Kevin改变世界的点滴，人人都是产品经理专栏作家。曾从事腾讯云产品设计与中兴通讯产品研发，现金融产品经理一枚。欢迎交流