“产品文档是产品经理交出的第一个产品。” —— 邱岳
我们之前的两次分享，聊到了产品文档以及图例的类型和作用，当时我说文档也是产品经理设计出来的一种“产品”，所以做好产品文档的诀窍其实跟做好产品的诀窍一脉相承，也讲究用户、场景、目的和体验。接下来我就结合自己的经验，跟你分享写好一份产品文档的诀窍。
第一次写产品文档的时候，我拿来文档模板就开始照葫芦画瓢，模板上有什么就写什么，好像只要把模板中所有的空位填满就能写出好文档了。
其实不然，好的产品文档应该有非常强的针对性。就像做产品要先明确用户一样，写产品文档的第一步就是要明确文章的目标受众是谁。知道谁是文档的主要受众或者读者，结合他们的思考维度，才能知道该用什么样的语言、逻辑和形式。
之后，我们是要清楚每个文档的目的，而不是把写文档本身当做目的。去设想一个文档的读者在读之前的状态和读完之后的状态，你希望他能获得什么信息，做出什么决定，以及有些什么后续的动作。
弄清楚受众和目的之后，你就可以判断用什么形式来呈现文档，是静态的产品原型，动态的 Demo，一张流程图，幻灯片还是一篇 PDF 或一封邮件，大概是什么长度等等。
比如 BRD 通常面向管理层和业务部门，目的一般是要获得支持和授权，申请到足够的资源，那就应该避免说产品实现细节，不要用技术的语言，而是从潜在的市场机会和风险解释要做什么，文档的形式可能是幻灯片。
幻灯片也分阅读型和演讲型的，阅读型要把逻辑写下来，演讲型则写提纲或放图，通常要准备两份，因为很多时候是既要做演讲，也有时候是发邮件的。
而 PRD 通常是面向工程师，让他们知道要做什么，以及为什么做，进而驱动他们设计和实现具体功能。PRD 通常是写成文档，PDF 或者写在 Wiki 上（建议不要用 Word，很多工程师如果不用 Windows 系统，排版会失控），工程师不喜欢长篇大论，最好能图文并茂，如果有机会能给现场给他们讲解一下，就更好了。
在面向职能部门的文档中，目的主要是为了推进执行，所以很多人只在文档中交代其“然”，不交代其“所以然”。比如只告诉开发要做什么功能，只告诉运营要推什么入口，却不交代为什么。很多文档模板里有“项目背景” 一项，结果产品经理只是随便写一两句话就算充数。
这是个非常糟糕的习惯，有句话叫做：“想让人造船，应该先激起他们对大海的向往”，执行层面的策略如果不能跟宏观的判断一脉相承，就很容易在落地的过程中走样。
另外交代背景和原因还有个好处是可以得到职能部门的建议和反馈。没有人比一线的工程师更了解系统实现，他们或许可以给你更好的解决方案。
比如我曾经设计一个订单项的排序规则，目的是为了让销售可以更灵活地安排订单行的位置。我把场景讲给工程师听之后，他给我做了一个直接用鼠标拖动排序的功能（那个年代这个交互效果在 Web 上还很罕见）。
文档的阅读体验也非常重要，有的文档逻辑杂乱无章，东一榔头西一棒子，不忍卒读。要保证文档的可读性，不能随性起笔写到哪儿算哪儿，而应该有提前的谋篇布局。
有个著名的方法论叫金字塔原理，就是从一个论点出发（通常是文档的目的），找到支持它的三到五个方面，每个方面再向下拆分，形成一个逻辑上的金字塔。每一层的拆分都要尽可能保证观点是相互独立，同时又完全覆盖的。
写文档就是一个不断拆分，再向上合并的过程。比如我们举个常见的例子，现在要给 ATM 机写 PRD，首先第一层拆分是 ATM 机的不同角色，用户、维护管理人员、系统（有时我们会将系统也当做一个角色）等。
从用户这里拆分下来，有存钱、取钱、汇款、账户管理之类的用例，继续从存钱这个用例去拆解，可以分解出“校验身份，完成取款，退出系统”的主流程。
如果我们看“完成取款”的流程，可以继续拆到“用户输入金额，系统从账户上扣款，系统吐出钞票，用户取走钞票”的具体交互步骤，任何一个交互步骤又可以长出各种分支流程，比如系统扣款失败，或者扣款成功后，吐出钞票失败等等。
如果像写故事一样，想到哪里写哪里，这就很容易遗漏关键流程，也会让读文档的人陷入混乱，不知所云。对于上面的拆解过程，我们通常的做法是：对每个角色给出一系列用例，每个用例有一个用例文档，用例文档中先描述正常流程逻辑，然后单独描述正常流程每个节点上可能出现的异常情况。
在文档描述过程中可能会出现一系列商业规则，比如取款每次不得超过 3000 块钱，每天每张卡不得超过 20 万等等，这些规则在流程中即便阐述了，也最好可以单独在某一个地方列出来，一来方便工程师查漏补缺，二来也方便测试时去设计测试用例，提高效率。
最后还要重点提一下格式，好多人写文档完全不注意格式，包括字体排版之类。虽说这不是关键，可还是建议处理处理，不一定要多好看，起码看起来易读一些，比如增加一点段间距和页边距，该对齐的对齐，该加粗的加粗，这是文档的第一印象，最好还是正儿八经收拾收拾。
写文档通常不是一蹴而就的，写的过程也是整理思路，查漏补缺的过程。所以一开始的时候可以尽量多写一点，然后不断重读，不断裁剪、重构、修改和调整。可能在写主流程的时候会突然意识到遗漏了分支流程，那就立刻写下来，等到修改的时候再把它摘出来放到分支流程的文档结构里。
另外是写的过程中可能没注意遣词造句，会写得比较啰嗦，或存在二义性。这些都需要在修改的过程里不断地提炼，这个过程跟写作很像，都是先堆后理，先厚再薄的过程。
在堆和理之间，可以尝试引入一个“冷静期”，我在之前的文章中提到过，我会建议同事在写完文档后不着急定稿和评审，而是搁置在那里，放一晚上，睡一觉或者忙一点别的事情之后，等思路开始从深陷其中抽离出来了，再把文档翻出来重读和修改。我们把这个过程叫做文档的发酵。
当你全力写的时候，很容易陷入在写作者的角度抽不出身，有些东西会在你脑子里，但没有落到文档中；而文档的写作最主要的目的还是为了读，当你放下文档晾它一会儿，重新再捡起来的时候，你会更容易站到读者的角度。
另一个更简单的办法是把写出的文档给熟悉的自己人先读读看，获得一些从读者角度来的反馈。就像白居易写完诗会念给隔壁大妈听一样，这也是一个精进文档写作的方法。
我以前偶尔会把初稿文档发给我媳妇让她帮我看看，一来她之前在业务部门工作，大概能理解业务，二来她不太会担心我的自尊心，会比较直接地指出她看不懂的地方。
正如同我们做产品的套路一样，我们从用户、场景出发，通过挖掘文档读者的需求和背景来撰写文档。强调了文档逻辑结构的完整和条理，最后又一次建议你不要急于求成，写好的东西放下来冷静发酵一下，进行一个二次加工。
我们今天的分享就到这里，你在做产品文档的过程中有没有什么心得可以分享？欢迎在留言区讨论，谢谢你，我们下次见。
评论