PRD文档很见产品经理的基本功。好的PRD文档开发人员阅读起来如沐清风，手脚麻利，干活利索。延期？不存在的！

　　一份考虑不够周全的PRD文档，让开发人员二丈摸不到头脑，在需求评审会上，悄然酝酿着撕逼大战。或者是，产品经理善于挖坑，需求评审会上居然过了，在实际开发过程中才发现问题，严重时候可能需要返工，浪费人力物力财力。

　　细节考虑不清楚，测试同学也无法发现潜在的问题，可能导致产品缺陷。不靠谱！

　　为了不翻车，在写完PRD的时候，对于每个用例，都应该仔细去考虑下面的细节内容。武汉松蓝云认为一个优秀的产品经理在写PRD文档时要在速度、效率、质量三方面都表现出色。

　　和产品经理打一辈子交道的可能不是程序猿，也可能是产品文档。

　　产品文档是产品经理设计思路的输出表现形式，可以理解为打仗的武器、吃饭的家伙。

　　如此重要的产品文档却也可能成为一个产品经理的诟病——技术对于文档的可读性的质疑、测试工程师对于细节场景的疑问等。

　　那让我们看看我们怎么才能“武汉APP开发程序员旁边说话不腰疼”？

　　一、 PRD输出效率

　　那我们先来聊下现实工作中不同等级的产品经理处理文档的效率吧。

　　我们根据出文档质量和速度两个维度进行效率评估，把文档能力分为3个等级：

　　Level1：PRD输出速度慢+低质量Level2：PRD输出速度快+低质量Level3：PRD输出速度快+高质量

　　二、PRD速度能力

　　现实工作中我们可能会遇到很多异常情况：“加急需求”、“头脑风暴短期敏捷开发需求”……

　　简单地说就是：时间短任务重。可能整体的需求方向和做法都没有确定，基础的逻辑框架都没有搭建时已经逼近输出时间节点。

　　这时我们就需要注意提升我们的速度能力——“快”。

　　当然，并不能说快就不管质量。我们在提升速度能力时最低的底线是：保持你之前文档的质量水平的基础上提升文档完成速度，这样的训练提升结果才是可量化的。

　　训练思路：减少思考你一定要思考的内容。

　　这句话听着很奇怪，其实就是把之前你需要用时间去思考的内容变成工作经验，变成你的一部分，不需要做额外的思考也可以完成。

　　简单的举个栗子，新手产品经理在写文档的思考步骤：先写标题、再写需求的设计目的、然后我们详细描述下需求内容（需求内容第一条要写什么呢？第二条要写什么？）。

　　你会发现他的思考路径很长，什么都要想用不用写，写什么。

　　如果我们心里很清楚一个产品的生成哪些内容一定要写，那我们就不用去浪费时间在想上面，而是直接写 1、2、3、4，最后看是否又遗漏需要进行补充。

　　总结起来：“速度训练”就是把工作中文档输出的经验形成方法论，来缩短文档输出的路径，加快文档输出速度的刻意训练。

　　三、PRD质量

　　对于文档质量的定义：什么是一个好的产品文档？

　　起码“程序看的懂，测试不骂你”吧！

　　这里玩笑归玩笑，但是一个产品文档如果写的好一定会大大减少工作中的沟通成本，提升工作效率与环境。

　　文档质量的不仅仅是产品思维的体现，也是产品架构、复用准则、逻辑思维、异常处理以及可读性体现等。

　　1. 替程序员着想：“体谅”而不是“妥协”

　　体谅

　　很多时候我们写好文档和程序同学沟通时都会出现这样的问题：哎呀，这个东西不好搞啊，不是不能搞，就是需要时间长点，要不咱们换个方案？

　　这种情况如果我们按鲁迅先生的性格（我向来不惮以最坏的恶意来揣测国人的）来思考问题的话，那么可能是我们提的需求的实现方式违背了技术的框架结构，比如：代码的延用性、可维护性、安全性等。

　　这种情况下，我们就需要体谅和自我提升，体谅是体谅程序员是在为产品着想；而不是跟你作对才说不好做，我们要理解技术有技术的规则。

　　你不会全部了然，提升是指要学会以技术的思维去思考。

　　你不一定要会写代码，但要了解起码的代码运作的机制，这样可以在和程序沟通之前就筛除掉一部分有实现逻辑问题的方案。

　　不妥协

　　刚才说了体谅，我们先礼后兵，现在我们说不妥协。

　　如果产品经理认定这个需求对于整个产品的数据起着至关重要的作用，我们绝对不要因为技术实现问题而妥协去修改方案，违背最初方案的目的。

　　无论是什么原因，我们最后的目的是提升产品的数据盈利，当然我们也要帮程序同学想办法一起解决这件事，我们拥有共同的目标。

　　2. 逻辑思维清晰，可读性强：会讲故事

　　考验产品经理语文水平的时间到了，如何让程序员看了你的文档就明白：我们的目的是提升A，我们通过B路径去提升A，我要把B路径做出来，B路径由1、2、3、4、5、6、7等构成。

　　清楚明了，知道产品为什么要做这个是很关键的。

　　只有知道出发点，他才会顺着你的思路去完成；不然极端情况会做出和你设计的内容很像，但和出发点不同的产品，就像我们大家都会玩的谁是卧底一样。

　　3. 细节以及异常情况不要放过

　　刚入行产品经理的小伙伴可能会发现：即使仔细完成的文档程序还是会有问题要问你，还是会有你没写到或想不到的地方，往往会问到你怀疑人生，难道程序都比我想的多吗？

　　遇到这种情况不需要陷入怀疑自己能力的怪圈，因为产品输出文档时更注重的是整体产品的合理性、用户的体验和目的达成度；而程序在制作过程中需要了解到每一个细节，他们写着写着写到你没说的地方就不知道怎么做了。

　　作为一个身体力行的实践者当然要比“纸上谈兵的我们”更清楚。

　　不过这些都是不是产品经理放弃追求细节的理由，如果细节足够可以为程序、测试小伙伴节省非常多的沟通成本，也是提升产品经理工作能力的必经之路。

　　这里我们给几个输出PRD注重细节的建议吧。

　　培养文档输出时的清晰逻辑，把一定要写的内容铭记于心。文档概述完成后写一遍流程图（流程图真的非常重要）——画流程图可以帮助我们查缺补漏，整个产品的流程实现闭环，减少场景情况遗漏的情况。异常边际情况标注：一般产品的设计中会有很多程序异常或者边际设计的情况出现。比如：如果数据配置加载失败，前端应该显示什么；活动隔日刷新时，用户正在活动中应该怎么都是常见的异常边际问题；在写完文档时，我们要格外注意是否会有这些情况、对这些情况进行梳理和标注。凡事不要懈怠。文档偷懒一时爽，技术测试疯狂找。尽量一次强迫自己一次性把内容写清楚，不要总指望第二次的修改，长此以往对我们的进步没有任何帮助。

　　四、结语

　　PRD的输出速度和质量会根据我们的工作经验的完善逐步提升，希望小伙伴们也不要有太大的压力。只要我们把每一次的文档输出都当作一次试炼，对文档保持敬畏，相信一段时间后对于产品文档的质量提升会有奇效。