怎样才能写出征服开发测试的B端PRD文档？(组图)

怎样才能写出征服开发测试的B端PRD文档？(组图)

　　一、客观场景

　　据研究、开发和测试非常讨厌以下几类B端产品经理：

　　这些问题除了靠人脉和角力解决，还可以从严自律的角度出发，稳扎稳打的写PRD文档，写能征服开发和测试的PRD文档，然后公布需求只需按照文档的编写顺序即可。

　　《PRD文档怎么写》往往是培训机构做的，主要针对那些即将做产品经理的新人。我说的是“如何写B端PRD文档征服开发测试”。主要写给做B端产品经理2年以上的同学，目的是让B端产品经理通过PRD文档表达实力、提升能力、征服开发，从而提高效率产学研合作，树立产品经理的威信。

　　二、开发测试需求

　　那么我们如何编写一个 B 端 PRD 文档来征服开发和测试？

　　首先我们要通过开发和测试，通过PRD文档分析我们想知道什么，也就是他们的需求是什么，然后有效地满足他们的需求，最后，在宣讲需求的时候，使用通俗易懂的文字，让观众一目了然。 那么对于PRD文档的开发和测试，您想了解什么？

　　1.前端开发2.后端开发3.测试

　　要编写哪些清晰的用例。

　　三、八招征服

　　那么如何编写 PRD 文档来满足这些开发和测试的需求？

　　经过6年ERP和供应链相关产品的实际设计，我总结出了“八招”。读者在使用这八招时，需要实事求是，从实际出发。毕竟，这是非常困难的。为了让读者理解起来不那么枯燥，我分别讲解了这8个技巧，并配备了相关案例。

　　1. 更新标签

　　无论是创建一个新的大需求，还是增加、删除或修改现有的需求，都必须对需求进行标记，以便对需求进行追溯。如果你不这样做，有时产品经理会发现之前的逻辑是什么。尤其是之前的产品辞职后没有交代清楚，收到之后会很尴尬。

　　我提到的标记是文档内容中应该只有一个标记，这样开发测试只需要搜索这个标记就知道“这个需求”涉及到什么，而不是阅读全文。就好像你在监视下所做的事情已经被拍了下来。下面我列出了两个简单的案例。

　　1）修改字段名称

　　2）修改一段逻辑

　　2.业务领域

　　一定要把业务中遇到什么问题写清楚，然后你的产品计划就是解决这个问题，否则开发测试不知道为什么要做这个需求。还要写清楚问题是怎么来的，是实际业务来的，还是谁带头的，这样开发和测试就知道需求的真实性了。

　　如果你还有时间，可以把分析这个问题的过程以及这个问题的各种解决方案写下来，让开发和测试可以身临其境地了解这个需求的来龙去脉。

　　3. 计划概览

　　写好业务场景后，你需要写一个计划的概述。主要是用产品语言来概括以上问题是如何解决的，这个需求涉及到哪些业务模块，涉及到哪些核心逻辑。

　　这样，当需求公布时，开发就可以判断是否与自己有关。不会有“一个开发者参与了几个小时的需求评审，却发现自己什么都不用做，然后耽误了打代码的时间，晚上又加班”。而且，开发主管还可以根据计划的大纲来判断需要给予什么样的开发资源和开发周期。

　　4. 业务流程

　　写好计划大纲后，开发和测试只知道怎么做，不知道怎么做。这时候就应该开始写业务流程了。最好用泳道图把各种判断逻辑、涉及的用户角色、业务写清楚。模块等。在后端开发时，他们会考虑数据流，需要哪些接口以及使用哪个表。

　　业务流程就像驾驶时使用的地图导航，就像战争期间制作的路线图。对于B端产品经理来说，“业务再复杂，都可以用流程图来表达”是基本能力，这里就不放案例图了。一种对开发非常反感的B端产品经理是“需求没画清楚，流程不清楚”。

　　5.前端交互

　　只用业务流程来表达一个事物的解决过程，还是有些抽象的，所以这个时候应该用原型页面来直观的表达出来。这块UI和前端会关注页面有哪些增删改查，需要进行哪些交互，后端还要考虑前端调用需要封装哪些接口。

　　注意这里不是简单的用原型工具画几页，扔开发链接，而是把每一个交互和每一个字段都写成一定的格式（条件、动作、页面、结果），看详情以下案例。

　　有一个产品经理对开发测试很反感，就是“需求的输出方式是一个原型文件，点进去之后发现是基础列表页，新建编辑页，详情页和其他逻辑依赖于猜测。”

　　以我的方式编写前端交互的缺点是需要更多时间。最大的好处是你不能错过每一个交互逻辑和每一个领域。下面我只举两个非常简单的例子。

　　1）列表页的每一个字段名和排序顺序都要写出来，以免遗漏

　　2）新建和编辑页面中的每一次交互都以“条件、动作、页面、结果”的格式表示

　　6.表结构

　　市面上90%以上的B端产品经理都不会写这个，因为他们普遍认为这是一个开发问题。如果产品经理能写出需要设计哪些表，这个需求需要哪些字段，以及每个字段的相关信息，那么他们在开发设计表结构的时候就可以借鉴和确认，这样开发就真的佩服你。

　　这篇文章的基础是产品经理必须了解sql的基本查询语句。如果你理解它，它会更加强大。在写需求的时候，可以多从开发的角度考虑问题。以下情况下各个列名的使用需要有一定数据库知识的产品经理才能掌握。

　　7. 数据流向

　　从哪个表取数据插入或者更新到哪个表，用什么样的输入参数来请求哪个接口返回什么样的值，这个开发很关心。

　　开发代码操作表，也就是说在开发者眼中函数的本质是数据流，数据流的载体是表和接口，数据流是技术业务流程的理解。这篇文章需要有一定数据库和接口技能的B端产品经理来写。

　　8. 复习题

　　在产品展示或开发过程中，对开发中提出的一些重要问题的回答应记录在此，方便其他开发者查看，更明确的需求。尤其是产品文档中没有写的逻辑，是在审查中开发发现的，然后经过讨论最终确定。更重要的是写在这里。

　　这部分实际上是对需求文档的检查和填写。如果你不记录它，你可能会在一段时间后忘记这些重要的逻辑。记录应采用以下格式：“提供者、提出时间、问题、答案”。

　　四、Summary

　　当我到达这里时，我已经完成了。这八招对B端产品经理来说是严格的高标准。因此，在实际应用过程中，一切都需要以实际为准。毕竟通过口头需求、原型文件、一个PPT，再简单的写一段文字，甚至是一张草图进行开发，开发也能达到需求。

　　产品经理写的文档相当于你自己的作品。如果你对自己的作品有很高的标准，那么我相信时间长了你会成为开发和测试眼中的金字招牌，很乐意与你合作。

　　我不会写虚的文章，每一个文章都是ERP和供应链相关产品经理多年工作的总结。我不需要任何读者为我鼓掌或觉得我说的有道理。我需要的是，看完这篇文章后，你可以在工作中使用它，这样它才能帮助你变得更好。

　　本文由@产品老兵中杰原创发表，人人网是产品经理。未经许可禁止转载。

　　标题图片来自 Unsplash，基于 CC0 协议。

　　奖励作者，鼓励他努力！

　　欣赏