产品经理的日常工作中，常常需要接触或撰写各类文档，那么你知道如何输出规范且合格的文档吗？这篇文章里，作者总结了自己在文档中踩过的那些坑，并总结了相关的技巧，一起来看看吧。

文档本身是产品经理日常工作中最基础的一部分，我们几乎每天都在写文档，但是这些产出物真的合格吗? 如果我们想提升文档能力，可以采用哪些“拿来即用”的简单方法呢?

今天我便以自己这些年在写文档中踩过的坑，以及在工作中总结出的技巧逐一介绍~

首先说文档的重要性，提升重要意识，是做好一件事的前提条件。

我发现很多文档写的不合格，甚至比较烂的同学，在重视程度上就做的很差。

对于我们日常产出的文档来说，无论是需求说明书、产品手册、产品介绍、甚至于平时一个普通的日报、周报、月度总结、季度总结、年度复盘……或者项目进程中、验收过程中的各项产出物，或者售前过程中的诸多物料。

都能客观反映出一个人、一个团队、甚至于一家公司的专业性。

• 早在几年前，我自己就因为文档中的错别字和结构导致被老板嫌弃工作不严谨；
• 也因为简历中的错别字错失心仪 offer ；
• 还遇到过因为错别字在申请专利时被专利局退稿；
• 曾因为合作机构所提供的文档经常含有错别字而建议公司更换合作方；
• 也经常遇到在工作中提交的文档被客户一顿嫌弃，打回重写等情况。

所以，如果我们真的只把这些文档当做团队内部的“应付材料”，或者觉得反正这么多字，也没人细看而长期没有形成好的规范习惯，那后续会踩到的坑一定不会比我少。

因此，我总结了四点文档规范的重要性供大家参考，希望能引起我们真正的重视：

1. 体现个人、团队、公司的专业性，能够得到对方的认可，同时不要因为这些“所谓的小事”被别人挑毛病
2. 好的文档能够提升“可读性”和“易读性”，对阅读者产生良好印象的同时，也能尽量避免错误理解，在后续的工作推进中产生不必要的麻烦
3. 作为客观的可参照物，在双方扯皮时，文档是最有利的佐证。（如果文档中出现模棱两可，或者对自身团队不利的内容，前期如果没发现，后期会不会挖坑那就只能自求多福了）
4. 最后则是我上文中提到的一些关键性问题，一旦这些材料用于一些重要途径，便很容易产生重大的负面影响。

在文档的重要性了解清楚之后，我们来看看今天的主题【文档规范】，看具体如何清晰的进行文档交流，规范我们从 3 方面去说，分别是文档清晰交流的原则、文档的格式规范和内容规范，另外，在文档的末尾，我们也会以产品 PRD 文档作为案例给大家实际演绎文档的撰写标准。

文档应该按照金字塔原则进行编写，力求让阅读人在最短时间获取关键信息。不是要让阅读的人挑出他想看的，而是你把想要他看的、他需要看的用最准确的语言放在最恰当的位置上。不要假设所有人都会认真完整的读完文档，不要力图做到“多”和“全”，反而要做到“少”而“精”。

注意：写文档前要先问自己这样几个问题：

1. 背景是已经充分了解了吗？
2. 目标（方向）理解对了吗？和各方达成一致了吗？
3. 现状中各种数据都清楚了吗？资源配置合理吗（包括人员的投入和时间）？
4. 核心问题分解清楚了吗？子问题有针对性的解决方案吗？
5. 所有可能的方案都考虑过了吗？资源投入性价比可以接受吗？

请谨记：任何没有搞清问题时提出的解决方案都是耍流氓，任何不从目标出发分解得出的问题都没有解决的必要。宁可多花时间在思考上，也不要花时间和精力做没有意义的事。

因为思考可以让你之后的行动事倍功倍，而陷入做事之中只会浪费资源，耽误之后的规划。

写文档之前先问自己，谁会看这篇文档？是怎么样的角色和立场？他们都想知道什么信息？泛泛来分，大致有六类。

第一类：客户

问题：什么项目？优劣势是什么？你们打算怎么办？需要我们做什么？怎么盈利？客户一般在意的是你是什么项目，你需要干什么事情，对方需要干什么事情，他们可能会多个对比，选择对他们最优的合作伙伴，所以对他们来说，他所关心的是信息清晰的基础上，要体验你的专业性。

第二类：老板（比如CEO）

问题：什么项目？结论是什么？你们打算怎么办？由于每天要处理的事物过多，他们第一时间可能无法反应过来是什么文档，这就是为什么我们需要在标题和正文明确给出项目的名称和简练的背景。当明确了项目后，他们只会用很少的时间阅读最关键的结论信息，对于详尽的分析过程并不是关注。如果文档中有问题的暴露，那么请注意老板们不愿意仅仅知道问题，他们还希望知道问题将会如何被解决，如果不能解决，那么需要什么资源才能解决？或者目前有什么思路、要做什么尝试？

第三类：相关方-管理者（比如直属leader）

问题：结论是什么？你怎么得出结论的？咱们之后怎么办？文档结论与他们的工作直接相关，因此他们会非常关注结论是什么，而且会关注你如何得到这个结论、是否严谨、有没有其他解读方式？对于文档暴露的问题，大概率需要他的资源配合去解决，所以要让他在问题和目标上和我们达成一致，再明确那些是他要去协调解决的。最好在文档发送之前先私下和对方确认一些关键内容。

第四类：相关方-执行者（比如产品、市场）

问题：结论是什么？接下来需要“我”做什么？ 文档结论与他们的工作直接相关，因此他们也会很关注结论本身，但比起这个他们更关注接下来需要他们具体做什么事情来配合，这就是为什么to do一定要责任到人。

第五类：周知相关部门（比如财务、设计、技术、测试等）

问题：什么事？怎么样？对我有什么影响？我需要做什么？周知部门可能不完全清楚背景，因此他们的第一个问题是这个项目是什么？当从标题和背景中知道了是什么项目后，他们会浏览一下结论然后思考是否对他们的工作有影响。因此即便文档本身的内容和这些相关部门无关，但我们感知到之后需要他们的一些配合，也可以比较早的同步文档，让对方有所准备。

第六类：自己人（比如team小伙伴）

问题：谁做了什么？目前进度怎么样？需要什么帮助？ 自己人肯定会逐字逐句好好看文档的内容，然后了解信息之余会思考有什么信息或者资源可以给到帮助，万一有临时的一些情况，可以火速支援。

强烈建议非涉及保密数据和结论的文档，组内要同步。

背景：

1~2句话说明是什么项目。如果是数据分析一定要解释原始数据的范围。

a. 不是每一个项目都需要写背景，但明确背景有利于我们理解项目本身，从而更好定位自己在项目中的角色。

b. 项目背景很复杂，可适当延展说明，秉持严谨和精炼的原则快速把事情讲清楚。延展部分用括号括起来，给不了解项目背景的人阅读。

现状：

简明扼要把问题现状说清楚。按顺序描述（时间顺序、重要性顺序等等）。

a. 不要写全部现状，大家都知道的就不用写了，跟本文内容无关的也不用写，只写最关键的转折节点以及和本文内容有关的现状。

b. 告诉别人你对现状曾有过哪些尝试和思考，可行的话结论是什么，如果不可行阻力是哪些。让大家知道哪些问题是接下来可以被解决的，哪些问题是接下来没必要完全没办法处理的。

c. 列出项目当前的资源配置，包括人员的投入和时间。

决策：

根据现状，现在需要上级做出哪些决策。（老板/领导们不愿意仅仅知道问题，他们还希望知道问题将会如何被解决，如果不能解决，那么需要什么资源才能解决？或者目前有什么思路、要做什么尝试？）

a. 不要轻易对现状下结论，想象一下随便在街上拉一个路人，让他看这个问题，会给出什么答案。一旦这个答案跟你现在想的一样，你就要警惕了。

b. 判断一定要有充足的事实依据，如果依据不充足或者这个判断不适合由我们来说，可以仅仅反应事实。

c. 可以量化的一定要量化，类似于“下降”、“上升”后面一定要加上具体的幅度。

d. 用词要尽可能准确，少用类似于“受影响”、“大概”、“可能”这样的中性词。

e. 避免过于冗长的文字，如果文字过长可以用加粗和颜色来突出重点。尽量使用结构化的方法来呈现，如果是一组数据可以用表格呈现。

to do：

根据现状，现在需要别人配合你做些什么。

a. to do要指向文档中的问题，最好有逻辑明确的对照关系。尽量责任到人，交付日期也要标明。

b. 写to do一定要注意不要挖坑，承诺的事要负责，能确切做到的才用确定的口吻。如果有资源问题，要提前暴露，（例如，待xxx给出排期，待xxx核查问题后给出方案）。

分析过程（附在文末，给需要的人看）

写分析过程的目的是为了证明结论为什么正确。要与结论对应起来，不是完全按照实际分析的顺序去写。

a. 不用把所有工作都一一体现，大家都知道你的结论是经过大量计算提炼的。与结论无关的工作要简略甚至不体现在正文。

b. 避免使用excel大篇幅的表格，不利于大家发现信息，次要的内容可以删除不展现，原始数据放在附件里就可以了。

c. 多个维度要拆分成多个表格（如日期、城市），一次只对比一件事情。

d. 对于保留的指标一定要精炼，非常用指标要解释其计算方法和意义，不要希冀对方可以直接看懂。

e. 当计算方法不确定的时候，从业务的角度去思考数值背后的意义。（比如，应该是“平均之后再求和”还是“求和之后再平均”？）

f. 多个“口径”可表达的数据，只列出我们分析后认为最科学的一种。附件上可以有所有的计算，但文档内不要全部列出来，除非你要说明的结论不同。否则阅读人会很困惑。

由于这一部分可能比较长和复杂，为了看文档的人更好理解，可以在分析之前把逻辑简要进行说明。也可以在分析中用小标题进行引导。目标是看了结论立刻就能在下文找到依据。

这方面大多数产品同行应该都会注意，但很多时候文档写多了，我们也会变得“麻木”而忽略一些细节。而其他岗位的同事很多就不太注意文档格式的规范性，最终的交付物让人“一言难尽”。格式规范性主要包含字体、段落标题、段内标题、图片、目录这几类内容。

字体最关键是需要全文统一，我们可以按“正文字体”、“小标题字体”、“表格内字体”、“补充说明字体”、“重点突出字体”来分类，并保证每个类别的全文字体一致。

表格内的字体还要考虑字体大小是否会让表格排序“失真”或“凌乱”，表格的首行标题建议加粗、居中。章节的各级标题一定要使用格式刷来统一维护。很多文档不同的段落字体大小、样式都会有些偏差，究其原因还是作者没有检查的意识，也没有在完成复制粘贴后顺手用格式刷统一的习惯。

各级标题在用格式刷统一的过程中，非常容易出现一些小错误。 举个例子 eg1：下图就是典型的级别错误，是将四级标题，搞成三级标题。

eg2：下图就是典型的编号错误，是将内容复制过来之后，没有重新编号。

另外，一个文档中段落内的小标题也尽量保持一种格式，比如选择使用 (1） （2） （3) ，就不要再使用①②③，除非在文档中有多处不同级别的排序需求再考虑多种小标题样式。

文档中的图片要居中，如果某个章节有多张图片连续，则需要给每个图片附上文字说明

而且图片的大小也需要微调，尤其是一些图片复制进去之后很大、很模糊，此时就需要把图片缩小成尽量全文统一的大小展示。尤其是一些移动端截图，复制到文档之后可能会“又细又长”，这时我们一定要随手调整大小，尽量统一宽度。

目录一定要记得及时更新，我们经常会遇到内容修改之后没有更新目录直接提交的情况。也要记得把目录的字体、间距调整到适当，尤其是 Word 撰写的话，很多默认的目录格式都挺丑的。

以上这些细节，都是文档的格式规范要求，每一条单独来看可能都知道要这样做，或者也很简单觉得可以做到，在写文档时不要觉得这是小事就不用在意，细节决定专业，试想一下，这上面说的各个“小问题”汇聚到一个文档中，对阅读者来说是不是“灾难现场”。

关于文档的内容，因为不同的行业和用途有不同的内容要求，本文侧重点不在于内容如何整理，而是无论哪种内容，我们都需要检查、规避的常见问题。

首先，也是最最重要的一点，就是错别字在智能输入法普及的今天，我们日常的文字交流中充满了错别字，而这些错别字一旦在产品工作者的产出物中出现，会非常影响“印象分”，同时也会被质疑此人的细心、认真程度。大家都知道出现错别字不好，但苦于难以察觉，但这并不是我们任由错别字存在的理由。所以对于错别字，我有以下几点建议：

1）换一个相对智能的输入法

毕竟一个好的输入法能够记住我们常用的专业术语，能够在拼写错误时给出智能提示，系统默认的输入法很难达到这个效果。我曾经发现一位经常打错别字的小伙伴，就是一直在使用mac的默认输入法，换了搜狗之后能降低大约60%的错字情况。经常写错别字，虽然不是什么大毛病，但是一定是个比较烦人事，对自己个人也会有影响。试想一下，你在看其他人的文档时，看到对方有错别字以及有顿句和语句不通顺的问题，你是什么感受？

2）在日常生活中多注意

平时打字聊天的时候要养成不打错字的习惯，要发出去的内容自己扫一眼再发，如果出现了错别字及时改正，我认为这是每个产品人应该培养的习惯，这是一件很基础的事情。但是很多人都不在意，甚至被人多次指出之后也只是呵呵一笑，找个宽慰自己的理由，那么，这些人一定写不出合格的产品文档。

3）团队内可采取一些奖惩措施

这个是从领导层上要要求大家遵守的规则，就像小时候刚开始学习写字时，老师有权利将字写的不好的人的做作业撕掉重新写。奖惩措施很多，比如在关键文档中出现错别字之后，在团队内部发红包，或者当你看到其他同学的文档有错别字时及时提醒。总之一定要采取一些措施，让大家重视起来，养成日常检查的习惯，渐渐地错别字一定会越来越少。

4）自己一定要通读几遍

一个大段落写完之后，一定要重新读至少一遍，一方面检查错别字，另一方面检查是否存在语义表达等问题.自己要对自己的结果负责

5）可以让同事帮忙检查

有时很难发现自我产生的错误，因为会陷入惯性思维怪圈。因此找同事帮忙检查也是不错的方式。而且相互帮助，去识别对方的错误，也能在很大程度上检视自己，提升错字意识。

以上这些方法多管齐下，配合使用都可以快速运用起来，在刻意练习的过程中，逐渐我们会提升错别字的敏感程度，快速识别错误，并且能够总结出一些“高频错字”

在内容规范性上，除了上面说的，还有一点很重要—书面语的表达虽然经过几百年的发展，文字表达从最初的文言文变成了白话文，但白话文也不代表等同于口语化。用书面语，不口语化表达的好处在于这八个字：正式、规范、严肃、严谨。如果是团队内部的文档，只要领导没意见，大家愿意怎么搞就怎么搞。

但是一旦涉及到对外输出，逻辑严谨、 表达清晰、 结构明确的内容便是基础。在此我列举几个关键点，建议大家在写文档时尽量规避这些问题。

1）表达简洁易懂

当然，可能有些文档就是需要复杂严谨（比如专利申请文档），读起来非常拗口但确实挑不出逻辑漏洞。不过我们大部分接触的文档，还是要尽量简单、 易懂，让读者尽快理解你想表达的意思。比如：

1. 善于使用逻辑连接词：“因此”“进而”“所以” “反而”“除非”；
2. 简化短语，将“什么什么的时候”改为“什么什么时”；
3. 复杂逻辑采用分段、编号、配因等方式更直接地展现。

2）避免歧义用词

“一千个人心中有一千个哈姆雷特”，很多词语都有多面性，当使用不怡当时，非常容易造成读者的歧义。所以我们在使用这些词语时，要脱离自己的惯性思维，以用户视角来审视这段话是否准确。

a. 比如“xx等功能”，这个等宇就很微妙。如果是售前类的文档，“等”没问题。如果是交付类的文档，“等”就很容易给后续的验收挖坑；

b. 比如“单位”这个词，既可代表计量单位，又能代表公司、用工单位。当然结合文档的上下语境能够体会出其中的含义，但在一段文字内，如果出现同一个词代表不同含义的，一定要加以说明，或者换一种表达形式。

c. 我还在一本书中发现“资产管理”这个名词很有歧义。大多数人会认为是办公资产、固定资产之类的“资产”管理系统，而作为金融从业者，第一反应会是“资金类的金融资产”管理系统，这两种系统完全不同，

所以避免内容的“二义性”是内容规范中非常重要的一点。

语义要直接，别让对方反复理解

这里和表达简洁易懂有几分类似，但更倾向于别说废话+业务逻辑尽量直接。比如：

1. 把双重否定词 （不得不）改为肯定（就）；
2. 把“穷举”改成“除了”（在条件1、2、3、4、5、6、7、8的情况下，改成除了条件9、10的情况）

最后，关于内容规范性需要强调的是：文件命名规范文件名一定不能随便起，尤其是要发给客户的文档。最好能够通过文件名能让读者明白此文档的目的或核心内容。而且文件名最好能够和正文内的大标题保持一致，尽量在文件名中包含客户的简称、版本号、或者修改日期，其中修改日期一般出现在后续版本修改之后再添加。比如：

1. 【公司简称】产品名称 + 用途 + 版本号
2. 【客户名称】+ 公司简称 + 产品名称 + 用途 + 版本
3. 产品名称 + 用途 + 日期 – 备注

总之，不要忽略文档名称的重要性，如果起一个不专业的名字，可能对方都不会打开看就驳回了．

以上 是内容规范的总结，希望大家刻意练习，尽量规避。

除了上文提到的，还有一些其他通用注意事项，供大家参考。

我们在写文档时，有些没写完的内容会习惯性标注出来，等到后续再完善，此时标注一定要很方便的让你快速找到。比如采用特定的关键词(todo、待完善），或者插入批注。不要仅仅增加一个字体颜色或者背景色来标注。因为文档如果很长、如果没有逐行检查，很有可能会遗漏。

文档内容如果不是特别多，在多人协作时尽量使用【修订模式】，避免协作过程中出现冲突或疏忽而产生内容问题。最终合并时再把修订内容逐一核对，可以避免很多协同过程的麻烦。当然，如果文档较长，修订模式会很卡，多人协作要么采用一些其他协同工具，要么做好分工，避免同一部分多人修改的情况。

最好有“版本修订记录”，但不是必须。毕竟修改记录后期维护起来非常繁琐。如果文档版本变动频繁或者有追湖的必要性时，再增加修订记录也可以。关于修订记录还需要注意一点：修订的内容需要适合让接收人看到？至于为什么，我就不多说了，各位自行细品。

可以日常维护一个“关键词词库”，包含其他客户的名称、其他产品的名称、以及易错的关键词。待文档完成后，进行全局检索，大概率会有“惊喜”。

有些章节如果没有内容，或者不知道怎么写，可以标注“不适用”。但是如果你直接把章节删掉，后续交付、审核时可能会被纠错。当然，删掉的前提也要和客户沟通清楚。

接下来我们以产品常写的 PRD 文档为例，给大家一个参考模版，但是仅供参考，里面的细节可以根据实际情况酌情调整。

目录前面文章中有说过，这里不在展开细说，总而言之，目录的价值就是展示文档的具体结构，方便查找。

版本信息：

变更日志：

主要展示文档的更新日志，一般是需求评审后需要补充的内容或者确认说明信息等等，需要会后在原文档更新，留下记录，避免后期相互扯皮。更新补充的内容最后加上标题，并且以不同颜色或者字体区分，或者加以引用，总之是为了和之前的内容做区分，方便快速定位。

会议记录：

一般在PRD评审时要记录主要矛盾问题及待解决问题，并在会后列好todo ，责任到人，把具体的目标和时间量化。至于会议记录的模版，网上任意一个在线文档类的工具都能找到，下面是提供的一个简易模版，供大家参考。

展示当前版本需求的相关干系人，作用是快速找到相关方以及查看需求排期，需求排期也可以用需求甘特图来代替。下图是相关负责人和需求排期的记录表格，一般是需求评审后，去跟进设计、前端、后端测试等相关负责人的具体排期，如果排期不能当下出来的话，就确认好排期出来的时间，后续在跟进。

名词解释：

列出本文档中所用到的专门术语的定义和缩略语的全称和解释。尤其如果你的项目是新开发，有很多新定义的情况下需要特别注明你的概念。

需求背景：

背景前文中有详细介绍，这里就不详细说明了，总之核心内容为简要展示当前需求在什么样的情况下，需要干什么事情。

参考文档/相关文档：

列出本文档的所有参考文档；以及本文档中所牵连到的其他文档。比如需要多方对接以及牵连到其他同事的需求时，对方的文档就需要加以引用。 举个例子：

a. 本文档引用XXXX平台的XXXX需求情况下，就需要加以引用，【引用文档：“文档名称：XXXXXXXXXXXXXXX ” 相关负责人：XXX】

b. 本文档有对应的用户端需求，不是一个产品或者一波技术负责的情况下，就需要加以引用，【引用文档：用户端相关需求：“文档名称XXXXXXXXXXXXXXX” 相关负责人：XXX】

用户调研：

用户调研主要简要说明调研方法、样本情况及关键结论。如果需求有用户调研的情况下，需要再次附上详细的数据分析报告并添加在最后相关文档【附录】中。（用户调研不是PRD文档中非必要的，没有的话可以不写）

竞品分析：

竞品分析主要列出竞品对比的主要信息和关键结论，如果需求复杂，需要有相关竞品对比的情况下，需要在此附上详细的竞品分析报告，并添加在最后相关文档【附录】中。

（竞品分析不是PRD文档中非必要的，没有的话可以不写）

目标：

简要说明本文档的整体目标及阶段性目标。整体目标可以笼统说明，阶段性目标要定量（确定任务、时间、优先级等等） 举个例子：以用户端新增作业需求为案例。

影响范围：

简要说明该需求的调整或新增后，对其它现有的功能模块、用户、相关部门、相关系统都有啥影响。

产品 / 数据现状：

主要针对目标，简要说明当前的产品现状及数据现状。

功能入口：

功能入口偏C端产品，中后台相对比较少，尤其是C端多入口的功能点，需要分别说明入口细节（必要的话用现有产品功能截图标注说明，具体加在那个位置）。

?举个例子：

1. 下面是以某个C端活动为例，梳理他的功能入口。

2. 图例参考：下图是以【课程笔记功能】为例，以现有产品功能截图+标注方式说明。

整体流程/逻辑关系：

简要说明关于本次需求文档所描述的产品或组件的总体流程图或逻辑关系图，可以用流程图、思维导图、或者状态图来、业务流转图表示。注意这里是整体需求的流程图，如果有多个子流程的话，就需要在相关的子流程去展示对应子流程的流程图。 举个例子：

如图为某课程笔记购买流程图

此图为某课程笔记购买各业务流转图

页面交互图：

页面流程一般是偏用户端的需求需要特别说明，需要清晰的说明页面与页面之间的流转关系和逻辑关系。 举个例子：

某课程转介绍活动页面交互图

功能细节：

功能细节是按照需求的功能点逐个说明该功能的展示细节、交互、判断逻辑、接口逻辑等细节。

如果是 C 端用户页面（App、小程序、H5），就以功能逻辑的具体页面从上到下、从左到右的顺序展示各个功能细节说明。

如果是中后台页面，则以各个细分的功能点梳理需求细节。

总之就是将复杂需求细分为多个子需求，分别陈述各个子需求功能的详细说明。

?举个例子：下面以某课程转介绍活动的C端页面和后台页面做示例。

页面元素（顺序：从上至下 从左到右）

下图为活动后台管理页面：

页面元素（顺序：从上至下 从左到右）

下图为活动数据页面说明：

注意：如果是多个功能需求应该多个目录展示，要注意目录的层级关系，提高文档的阅读体验。（前面提到的文档格式规范中的层级规范）

?举个例子：此处是截某个【活动需求】的目录层级展示。

非功能需求指本次需求相关的除了技术开发除外的其它需求，比如产品营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等等。

?举个例子： 假如现在要做一场转介绍活动，那么活动页面、相关的流程交互等等是需要开发的开发需求。除了开发之外。

• 活动前期的活动调研、用户调研、数据调研等等属于【前期调研需求】；
• 活动上线之前的运营宣传文案、宣传材料、触达策略等属于【活动前期推广需求】；
• 活动相关的奖品选品、采购等等属于【采购需求】；
• 采购时钱款审批等等属于【财务需求】；
• 如果是比较大型的活动需要有第三方的公证机构做公证，这种属于【法务/市场需求】；
• 活动上线后需要相关产品运营去给业务方培训，推广等等，属于【宣广/培训需求】；
• 活动上线和结束后的数据追踪、活动复盘等等，属于【数据需求&复盘需求】。

从活动计划开始，活动负责产品应规划好对应节点的排期，并且周知对应小伙伴关键时间节点和关键todo，最好是责任到人。不是非涉密的数据和方案，组内容最好做好同步，让大家清晰的知道自己需要在什么节点下完成什么事情。

需要展示相关埋点文档以及数据需求（偏C端的需求会需要）。

埋点文档一般公司会有标准的埋点规范，按照统一要求填写数据埋点表即可，但是强烈建议写完之后需要和对应的技术伙伴确认一下埋点要求是否合理（可以在PRD评审的时候一起过），另外在测试阶段一定要记得测埋点，以保证数据采集的准确性。

数据需求一般是在没有可视化数据看板的情况下，需要单独梳理出来你本次需求的数据要求，让技术同学单独帮你处理，数据需求需要清晰的说明自己的表头字段、字段定义、和要求更新的时间。

?举个例子：以某个转介绍活动数据需求为例子。

把正文提及到的项目管理文档附在此处，比如并且之前活动那个需求相关的数据需求、运营需求、采购需求等等相关的文档，都可以放到此处，并且@ 到相关责任人。

上线说明文档指针对相对复杂的需求上线之后，尤其是逻辑比较复杂，或者涉及到多个平台，或者多个端口使用的需求，应该以邮件或者群公告的形式通知相关干系人。

并且输出完善的需求上线【操作说明文档】，说明上线的功能点、操作说明、及影响范围，有必要的情况下需要录制操作视频，并且视频要搭配语音解说）并且以邮件附件的形式发送给相关干系人。

?举个例子：此处是截某个上线说明文档的目录展示：

此处是某个上线通知的邮件/群广告通知模版（仅供参考）

希望对今天的内容对你有用~

本文由 @产品陀螺 原创发布于人人都是产品经理，未经作者许可，禁止转载。

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

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。