原创 产品经理和研发多年互喷的原因在哪？

根源就是你的→异常逻辑出了问题！在进入产品经理工作岗位的初期，大家普遍有这样的体验。觉得研发同学很容易不耐烦，“哪个地方没有说的很清楚，他们就开始提出这样或那样的问题。”

他们会有这种反应，主要是因为以下几个方面。

第一、开发后没人用，影响工作业绩。

要知道对于研发人员来讲，无论是公司内部职级晋升，还是跳槽换工作，历史的项目经验都起到至关重要的作用。所以，如果你项目并没有足够的吸引力，他们的配合程度自然不高。这件事情上，你的PRD提及到的项目背景需要着重体现这个项目的重要性。这个前期铺垫会给后面的配合带来很大的影响。

第二、反复修改需求，浪费研发人力。
如果觉得有些点并没有思考清楚，可以在产品设计阶段把所有的细节想清楚。要知道需求评审是个呈现设计结果的过程，不存在讨论的余地，所以在，PRD里面每一个细节都要以文字的形式描述清楚。不要让研发站出来说某某部分你自己再补充一下。这会降低研发对你的信任。

第三、上线前验收不通过，加班加点改代码。
如果PRD内容描述的不够详细，会引起两个方面的问题。一个是研发会在开发过程中不停的问你细节。这个时候你可能在准备下一个需求的内容。第二种情况是研发自由发挥，提测的时候，发现产品经理、研发同学和测试同学对设计的理解都不太一样，然后出现需求不对应的情况，从而陷入到无限的扯皮循环中。

总结来讲，以上提及的三个方面都会引起研发同学在会上会下吐槽产品经理的设计能力。只有把PRD里面的内容描述的足够详细，才能避免这种情况发生，进而提升工作的效率。

PRD文档的作用与价值

提到PRD的作用与价值，我们可以从一个比较实用的角度来了解一下。按照影响人群的维度来看，主要分以下三个部分。

第一，为视觉设计师和交互设计师提供设计参考。
首先交互设计师会依照你给的PRD进行交互设计，他们会非常认真的阅读你的文档，了解里面的流程与逻辑。然后给出交互文档。接下来，视觉设计师将依照PRD和交互文档来绘制静态设计图，并切图以备前端开发工程师调用。

第二，为开发工程师提供逻辑参考。

从研发的基础评估，到研发组织的技术评审，再到投入开发，全过程都强依赖PRD中描述的内容。这需要，PRD编写的要非常详尽，涉及到产品框架、业务流程、页面细节、数据交互，最后到数据埋点。

第三，为测试工程师提供验收参考。

对于测试工程师来讲，“标准参照”显得尤为重要，他们需要认真的阅读PRD，然后梳理每一个节点，整理出测试用例，用来把已提测项目与PRD文档中的每一个细节进行一一校对，并测试每一项细节。

总结来讲，需求文档需要由浅至深，由大到小，事无巨细的把整个产品项目描述清楚。

那么编写PRD方面，每个公司的标准多少会有些差异，但是核心的部分基本一致，主要包括下这几个部分，它们依次是：封面、PRD修改记录、目录、项目背景和项目目标、系统框架图、产品流程图、角色与权限对照表、功能详述和验收标准。

封面看似作用不大，但是在一份PRD的封面会标注该项目的优先级，这取决于评审后，是否可以立即进入开发较短，或者无限期延后。

PRD修改记录中记录着在评审及开发过程中针对需求的每一次修改的详细记录，它标记了修改的位置及内容。是后续产品功能核对的重要依据。

目录在PRD里面作为导引存在，可以清楚的看出文档的编写结构，方便阅读人员在前期形成概略的结构化内容，同时也便于指定查找定向的内容。

项目背景是在结束详细功能内容之前，需要研发人员了解该项目的重要性以及价值的重要环节，在某种程度上可以影响到研发人员的配合程度。

项目目标是基于项目背景之后，需要达成的最终目的。整个项目从设计到启动，将都围绕着这个目标来推进。

系统框架图是产品的骨骼，用来说明产品的重要组成部分和层级结构。

产品流程图通常会标注出产品的关键流程。便于研发人员了解不同角色的用户在产品中的操作路径。

角色与权限对照表，主要是用来说明产品中存在有哪些角色，每个角色的详细功能描述，以及不同的角色之间的差异情况。

功能详述是PRD中最核心的部分，借助原型体与文字描述，它将详细指出产品中的每一个细节的基础交互内容以及策略方面的设定。

验收标准是即将上线前的最后一个核对的环节，只有达到验收标准，产品才允许上线正式运行。验收标准的设定强依赖于产品的内在设计。

总结来讲，从全局上来看，每个部分都很重要，其中“功能详述”是整个PRD的核心所在。