需求文档撰写与合格交付原则

　　文档的撰写与合格交付一直是困扰在许多产品经理心中的一个难题。为了解决这个难题，笔者收集了开发、测试、设计人员多方意见，总结出这一份文档交付原则。
　　众所周知，需求文档的撰写与交付是每位产品经理工作中必备的技能，而在笔者写下这套文档交付原则之前，笔者所在的产品团队正面临着需求文档混乱、格式不统一、不具备参考性等众多问题。
　　笔者在收集了多位开发、测试、设计人员的意见后，综合了一些较为优秀的PRD需求文档，最终写下了这篇文档交付原则。目前也已经成功投入使用，它不仅仅能告诉你如何写一份需求文档，也能告诉你文档在进入设计、开发流程前你需要做哪些准备工作，衷心的希望这篇原则能给读者们以启迪！
　　一、文档交付流程
　　文档从最开始的需求分析到真正以文本格式投入使用往往需要经历以下几个阶段即：需求分析原型设计文档撰写内部评审外部评审。
　　这也是当今主流互联网公司大多采用的流程，笔者在本文中会主要介绍：原型设计、文档撰写、内部评审三个方面。
　　二、原型设计
　　原型绘画是产品经理的基础技能，但现在许多产品经理都认为绘画原型没那么重要，所以草草了事。
　　但实际上，一份好的原型不仅能帮助设计和后端开发较好的理解你的意图，也能增进团队之间的和谐。在笔者的产品工作中，设计人员不止一次因为拿到一些不规范的原型设计向笔者抱怨。那么，一份让大家都满意的原型应该满足哪些要求呢？
　　笔者认为主要是以下四点：
　　可点击的页面跳转或页面流程图
　　清晰且与文档对应的框架结构
　　美观且较易于理解的设计草图
　　简单、规范、统一的必要文字说明
　　可点击的页面跳转或页面流程图：能够帮开发更好的理解功能流程，也更利于产品经理在内审时对自己做的功能进行介绍，而且这通过Axure的屏幕快照功能可以非常轻松的实现。
　　清晰且与文档对应的框架结构：要求PRD需求文档功能模块的名称要与原型文档里的名称对应。
　　美观且较易于理解的设计草图：要求产品经理绘画的原型要至少保证可用性即有原型且原型交互符合规范。笔者曾遇到过有产品经理在原型设计中将Web端交互放到了移动端，甚至直接给设计人员Web端原型，让设计人员做一份移动端设计稿的情况。
　　（移动端原型错误的交互设计）
　　此时的设计人员：到底你是产品，还是我是产品？？？
　　简单、规范、统一的必要文字说明：因为有些功能点描述在文本中表现可能不够清晰，所以直接在原型上给予标注，这部分要尽量克制。
　　三、文档撰写
　　1。我们为什么要写文档？
　　文档的撰写目的，笔者认为主要有以下四点：
　　帮助产品经理梳理思路、流程及细节，完善产品。
　　减少设计、开发、测试过程中反复沟通造成的时间浪费和进度延误。
　　增强用户意识及程序思维。
　　反向通过完整的PRD、原型对产品进行验收及质量评价。
　　以上的一、三、四点都比较好理解，主要是为了完善产品经理的产品思维、减少出错。而第二点可能有很多人会疑惑，做产品本来就需要我们反复的去跟开发、设计、测试进行沟通，为什么还要减少呢？
　　这主要是因为：产品经理与他们之间的许多沟通本来是可以不发生的。
　　例如：一个Butoon的字段，你在文档里没有描述清晰，那么开发就会过来找你问，如果没有问你直接照着他的想法做了。最后方向和你想的不一样，那就悲剧了，要接着沟通怎么改了。
　　所以，对于一个产品经理，最好的状态是当你完成了某个项目的V1。0版本时，你就应该立刻着手准备V1。1版本的迭代与更新了，而不是接着和团队的其他成员在V1。0版本上扯皮。
　　请务必记住：产品经理是带着团队跑，不是和团队一起跑。
　　2。优秀文档应具有哪些特性？
　　笔者认为，优秀的文档主要具有以下特性：
　　逻辑性：内容有层次，描述可递进，文档中的结论要有客观事实来说明。
　　敏捷性：文档的内容要尽可能精简，切勿长篇大论。
　　完整性：在保证文档内容精简的同时，也不能缺三少四，重要的模块不能丢。
　　可读性：尽量避免使用二义性的语句，这容易造成使用人员曲解你的想法。
　　规范性：每份文档尽量保证格式相同或类似，减少使用人员的适应成本。
　　一致性：在需求分析模块的划分和命名上与原型文档保持一致。
　　3。优秀文档应该包含哪些模块？
　　上文提到：一个好的需求文档应该做到完整性即包含所有的重要模块，不能缺三少四。
　　那么又有哪些模块是重要的呢？
　　笔者在仔细分析了团队正在做的产品业务后，总结了优秀文档所需要包含的23个重要模块，其中有11个模块是必备的。
　　笔者相信，这也同样适用于大部分其他产品的业务。
　　笔者简单解释一下，上图中各个模块应包含的内容和存在意义。
　　（1）版本修订记录（必备）：主要包含现有版本的版本号、主要更改内容、更改原因等，它在产品出现问题，追根溯源时可以起到巨大作用。同时，也便于使用人员梳理逻辑。
　　（2）产品目标（必备）：可以是功能或者产品上线后想要达到的效果。
　　（4）需求方及背景（必备）：简述需求产生背景以及原因，需求面向哪些人群？一定要有事实或者数据作为佐证，开发吐槽产品经理乱提需求也不是一天两天了。
　　（5）预估收益（必备）：最好能用数字量化产品或功能开发产生的收益，也就是ROI，对收益的正确评判也是产品经理的一项重要能力。这里举个例子，如优化公司内部系统某流程，预计耗时13人天，完成后预计可以为公司其他部门每年节省35人天。这样的描述，清晰且可信。
　　（6）风险描述：简要概述产品或功能开发过程中可能会遇到的内部风险和外部风险，例如：新项目迁移可能遇到未知问题，这就是内部风险。前端开发缺人，项目撞车，这就属于外部风险。
　　（7）目标用户（必备）：简要描述一下产品或功能上线后服务的人群，有群体特征的最好也写上。
　　（8）使用场景：简要描述一下产品或功能上线后使用的场景。
　　（9）参与人员（必备）：记录产品或功能从孵化到上线过程中负责的工作人员，这样的好处是某个环节一旦出了问题，可以快速的定位到相关的负责人，提高效率，特别是翻看历史记录的时候。
　　（10）项目周期：主要是方便使用人员进行时间规划，同时可用于进行项目管理，如果所在团队项目的时间管理已经足够好，那么这个模块可以不写。
　　（11）名词解释：对使用人员可能不了解的名词进行注释。
　　（12）功能流程（必备）：这是PRD需求文档里最重要的一个模块，所以在保持简洁的同时要做到尽可能的详细。
　　流程图的作用不必多说，逻辑清晰的流程图可以帮助使用者快速的理清业务逻辑，提高效率，减少出错。而在交互流程中，我建议产品经理可以直接用Axure生成的HTML网址进行表示，方便且快捷。
　　接下来是页面及弹窗，这部分对前端开发意义很大，能有效的避免漏掉某些重要页面。
　　最后便是功能及说明，这部分主要对产品的每个功能进行详尽的描述。
　　以Web端的一个页面举例，我们需要介绍这个页面的操作路径，页面上的操作形式，数据的来源，额外的说明等。
　　具体的示例，笔者在下面用图片展示：
　　（13）权限amp；amp；角色：简要描述一下使用这个产品或功能的不同特征人群的权限，举个例子，企业做一个自己的日报系统，老板和员工的使用权限肯定是不一样的。
　　（14）性能需求：简要描述一下产品对性能的要求，如QPS、请求访问时长等。
　　（15）营销amp；amp；运营需求：这部分主要是面向C端产品，写出方向性就可以，是与运营联动的一个模块。
　　（16）安全需求：不同产品或功能对于安全的要求往往不尽相同，例如支付功能的安全需求比大多其他功能都要高，这个模块建议写上产品或功能安全等级的高低，应该做好哪些预防。
　　（17）法务需求：主要是专利著作权、版权等可能遇到的法务风险，大多产品或功能不存在这个问题。
　　（18）异常情况（必备）：简要描述一下用户使用产品或功能时可能碰到的异常情况，例如突然断网等。
　　（19）测试要点（必备）：这部分非常重要，产品经理需要在这个模块介绍产品或功能在上线前有哪些重点功能是需要反复测试的，有哪些异常逻辑是需要注意的。因为测试人员在一些细节的把控上可能没有产品经理来的仔细，如果一些重要的点没能被测试到就直接Pass，在后续的开发中就可能会惹上大麻烦（回炉重造等），从而导致项目延期。
　　（20）数据埋点及统计需求：写清楚应该在产品中的哪些维度进行数据埋点，和与之对应的统计需求。
　　（21）上线前准备（必备）：分点叙述上线前需要完成那些事件，例如把Bug状态都变为已解决。
　　（22）上线后工作（必备）：大多数产品或功能不是上线就结束了，往往需要后续的跟进，例如进行回归测试，对用户进行意见调研、实际收益评估等。
　　（23）设计规范：针对有交互原则的团队。
　　（24）补充说明：其他不属于以上22个模块的解释描述。
　　四、需求评审
　　1。评审的主要流程
　　自评清单，自评通过再内审。
　　内审评价，内审通过再外审。
　　外审评价，外审通过进入开发。
　　2。如何做好内审？
　　内审是评审的第一步，如果没有卡好内审这门关卡，随意的让项目通过，会导致外审时项目出现诸多纰漏，浪费团队其他人员的时间，所以内审一定要足够谨慎。
　　针对内审，笔者总结了六条原则：
　　至少应有3人参与内审；
　　内审必须邀请项目管理者参与；
　　要提前给定好内审预计所需要的时间；
　　基础测试一旦没有通过，内审必须当即中断；
　　评审结束后，相关人员应该在幕后形成相关的结论；
　　每次内审需做内审会议纪要，纪要包括内审的结论和问题。
　　这六条原则应该都是比较通俗易懂的，但关于基础测试，笔者要额外解释一下：所谓基础测试其实就是需求或功能流程，如果在内审当中，因为产品经理个人的灵光乍现或者是他人异议发现原定流程中有一段已经完全行不通了，那此时的内审也就没有意义了。产品经理应立刻停止内审，回去重新思考并修改流程，但如果仅仅是某一个节点需要修改，影响较小，则可以继续进行。
　　3。评审需要符合那些标准？
　　合理性：成本、收益、用户、痛点、风险等评估要合理。
　　完整性：角色是否完整、状态是否完整、功能是否完整。
　　可行性：技术的可行性，是否触碰到已知边界。
　　一致性：保持相同的视觉风格、交互方式和情感传达。
　　逻辑性：流程是否清晰便于其他人理解。
　　准确性：字段、数据源、数据计算方式、异常状态等。
　　易用性：用户使用成本是否足够低，路径足够简洁。
　　复用性：是否考虑复用已有产品、框架、设计。
　　创新性：是否能够尽可能发挥创新的能力。
　　以上标准既适用于内审，也适用于外审。
　　总结
　　文档的撰写与合格交付一直是困扰在许多产品经理心中的一个难题。现在许多的人都建议直接用Axure来同时进行原型与PRD文档的制作，这种方式的确非常节省时间，但要注意这个时间只是节省了写文档的时间，在接下来的设计、开发、测试过程中，由于前期文档内容不够详尽，耗费的时间实际上是大幅度增加了。
　　在笔者写下这篇原则之前，所在团队也是采取Axure原型和文档一起做的模式，但实行起来效果并不好前端、测试、设计饱受这种不规范文档之苦。所以，依旧建议大家用文字表达。
　　这套原则因为是第一版，且笔者作为一个实习生还没有太多的产品工作经历，所以在部分模块细节上可能仍然有许多疏漏。特别的，可能因为从事的业务相关，这套原则不能完全的适用于其他团队产品的工作模式，不过笔者相信它依旧能给你们以启发。
　　至于这套原则的下一步，笔者目前所考虑的是协同文档，WIKI、石墨等等，如果大家有好的建议或者是看法，也欢迎在评论中提出，笔者都会认真聆听并虚心接受，谢谢！