智慧社区SaaS服务平台PRD需求规格说明书V0.0.1

产品管理规范编号：产品管理规范版号：V1.0页码：共41页编制日期：审核：日期：批准：日期2022年8月目录产品管理规范 1一、前言 41.1目的 41.2范围 41.3职责 41.4内容 4二、产品战略规划 52.1产品路线 52.2产品策略 52.3产品计划 5三、产品需求阶段 63.1需求层级 63.2需求获取 63.3需求分析 83.4需求管理 93.5迭代规划 13四、产品设计阶段 144.1总体流程 144.2产品原型设计 154.3主流设计工具 184.4原型大纲 184.5界面原型及逻辑说明 194.6交互用例 204.7原型详细规范 204.8流程制作规范 214.9页面说明 22五、PRD文档撰写 245.1写PRD的目的 245.2PRD撰写的前提条件 245.3PRD内容 255.4产品向各方需求文档内容 37六、版本命名、验收规范、发版管理 376.1产品版本命名规则 376.2产品验收流程 396.3产品发版管理 41一、前言1.1目的实现以市场为导向的产品规划，有计划有组织地进行研究与产品开发活动。有效地调动营销部门以及生产部门的创造性思维，把市场与消费者的认识转换在新产品中，确保产品开发和企业产品战略的一致性，快速、合理应对市场需求，规避产品投资风险，并为企业获得最大限度的利润。1.2范围本制度适用于本公司产品开发、上线、管理全过程，对产品管理的流程做出规定，是公司管理产品规划工作的依据。1.3职责产品管理是企业在产品生命周期中对产品规划、设计、开发、运营和支持等环节进行管理的业务活动，包括需求管理、设计管理以及开发管理。1.4内容1.4.1产品战略规划产品战略包含：1产品路线2产品策略3产品计划1.4.2产品研发产品研发包含：1需求阶段2设计阶段3开发阶段4测试阶段5发布阶段（上线）1.4.3组织、主要人员及职责1.4.3.1组织结构1.4.3.2重要角色重要角色负责人：产品负责人、研发负责人、产品管理负责人、运营负责人。重要角色包括：产品经理、需求管理员、技术人员、运营人员。1.4.3.3其中对重要角色职责及相关要求定义如下：1)产品管理会产品管理会由产品中心、运营中心、产品研发中心总监以及参与在产品生命周期过程中的产品规划、用户研究、产品负责人、开发负责人、运营负责人等共同组成。主要职责：（1）制定运营计划，确定运营目标；（2）优化产品，制定运营策略；（3）监控产品质量，把控经营结果；（4）对产品进行全生命周期管理；（5）对产品需求的提出、终止和变更进行决策；（6）监督产品管理相关制度的执行。2)评审委员会由产品中心、产品规划、运营中心及产品研发的总监组成。主要职责：（1）对本中心项目进度和质量进行管理，保障经营结果达成；（2）对项目相关资源进行调配，以保证项目顺利开展；（3）对产品定义的方向性提出建议并评审；（4）对产品是否具备上线条件进行评审，并给出意见；（5）对产品运营结果进行评审，对产品和运营目标提出意见并给予帮助；（6）对产品是否退市进行评审。二、产品战略规划战略规划是产品管理中最重要工作之一，主要是制定公司产品（产品线）的长期发展规划和年度发展规划，具体的工作分为以下三个流程。2.1产品路线产品路线规划是属于公司业务中战略层面的制定工作之一，对于产品管理人员来说，每个大型项目需要对产品线进行产品（产品线）路线规划，确定产品（产品线）长期的发展规划和目标。2.2产品策略年度产品策略的制定是对产品路线规划每一年度的进一步细化的工作，确定公司年度的产品发展规划及相应的措施，是每一年度产品发展的总纲领文件。2.3产品计划年度产品计划是年度产品策略中详细产品管理工作的具体项目时间安排计划一览表，有利于更加明确年度需要确定的产品管理工作。以上的三个二级流程工作主要是解决公司业务发展和产品管理中的战略性层面的问题，确定公司整体的产品发展方向及年度的工作内容。具体产品战略规划步骤如下：1）产品管理部根据年度目标和战略，结合市场情况和各相关部门提供的相关资料进行分析，形成“产品规划讨论稿”。

2）产品管理部经理审核讨论稿。

3）产品管理部经理组织营销公司相关部门对“产品规划讨论稿”进行讨论修改，形成“产品规划书”。

4）产品管理部将“产品规划书”报产品委员会审批，若不通过，由产品部负责修改再报产品委员会审批。

5）产品委员会审批通过后下发各部门执行。三、产品需求阶段3.1需求层级3.1.1战略性需求为产品定基调，定方向的需求，引起战略性需求的因素可能有两大部分：一部分是由外部因素引起（如新技术趋势、市场变化、社会交流方式等出现的新机会）一部分是内部的技术、资源整合再利用，在原有业务方向之外的拓展3.1.2战术需求战术需求比战略需求低一层级，是战略的拆分也即是通常意义说的产品实现路线的每个阶段。3.1.3战役需求战役是对战术的再拆分，也就是每一个阶段性的具体实施。比如：合同电子签如何实现，登录方式如何处理。实际中短期需求也需要考虑到后期的可扩展性，否则做出来的东西后期改动成本会非常大。3.2需求获取1）概述：从概括性的项目背景说明、价值分析，深入到目标用户确认、业务现状、业务问题和期望效果的梳理。2）需求来源：战略规划、竞品分析、运营反馈、用户反馈、市场调研3.2.1内部客户简单说就是公司内部决策高层及各部门具体使用人员，对产品在使用中发现的问题，提出的优化改善运营策划方案。如运营使用频率最高，客服部与用户沟通频率最高，都能发现很多需求及问题。此部分需求，具体使用部门一般主要集中在对现有产品的优化迭代，在流程的优化、体验的优化，业务线的深化拓展。内部客户的需求收集整个流程：由内部用户填写需求功能收集表，按照一定周期提交产品经理，并进行沟通讨论，根据商业价值、技术可实现度、优先级、产品路线节奏规划等考虑点判断是否要做，及做的安排。短期内不做，或者有其它方法可解决的情况下，与需求提出方沟通其它解决方案（如：在项目的早期，以MVP方式做，则很多分析类的需求，在数据量较小，工作复杂程度较小的时候，是可以通过将相关数据埋点进行导出手动分析，则这个时候做大量的系统数据分析需求及实用性不大）。如果需求沟通之后确认要做，则将需求放入排期中，并将需求对接清楚，各方通过签字或其它方式进行确认。一般来说，如果不是非常紧急的需求及bug修复等，按照一周一次的提交频率进行，产品进展到一定的程度之后，大概率也是按照一定的固定频率进行更新。内部需求收集的整体流程如下：3.2.2外部客户外部客户的调研，这要看产品是针对的B端用户还是C端用户，B端用户的目标客户群较为清晰。B端用户要分决策购买人和使用者，最好的方式是同时满足两者的需求。这两者有不同点，比如决策者的依据是对企业好（其它目的不进行讨论），比如员工行为数据可视化、流程线上化。这样可以对员工进行监管，同时数据更为实时，后期商业决策更加有依据。实际在做的时候，需要深入业务中调研，也需要对流程进行优化，不能只是简单的将原有的流程完全搬到线上，或者简单的搞高大上的可视化显示，因为这样会增加实际操作人员的成本，并未能提高效率，缩减成本。一般B端业务，深入业务，对相关关系人进行足够的沟通，则需求将比较明显能够提炼出来。C端的用户，业务纵深一般没有B端的程度深，但目标用户的明确性，用户的需求会不这么明显，需求调研所花费的工作将会更多。总体来说，B、C都采用线上及线下的方式进行调研。线上调研一般是调研问卷的方式，以及参考行业相关资料，竞对资料，线下一般采用拜访（预设或不预设问题），邀请用户集中沟通，头脑风暴等方式。以下为外部需求收集的流程：3.3需求分析3.3.1概述产品经理针对获取的原始需求进行伪需求过滤，梳理得到真实需求并汇总进项目需求池，进行优先级判断和迭代规划等管理。其中优先级主要从核心需求难、基本需求、扩展需求三个维度进行判断；迭代规划则是权衡工期要求和开发资源，在当期版本中删减优先级低的需求，在后续版本中再开发。根据确认下来的当期需求，进行业务流程、功能架构、工作流状态定义的梳理工作——即进行框架层的需求设计。3.3.2注意事项《有效需求分析》中总结了这一现象：需求方往往提出“方案级需求”，需求分析则是要还原出“问题级需求”。过滤“伪需求”，得到“真实需求”。梳理出真实需求后，根据实际项目要求和资源限制，还需要从技术、业务、成本和收益、风险和策略等方面进行可行性分析。需求概要设计（包含业务流程图、功能架构图和工作流状态定义等）；需求清单；调研报告：邮件发送，同步双方；会议纪要：记录需求来源，重要等级3.3.3需求收集标准化文档产品需求收集表：以下为需求收集表的样式提出方需求名称需求描述需求类型紧急程度对接的产品经理对接时间--主要解决为什么做，做什么，怎么做这几个问题，特别是解决为什么及做什么的问题新增、改进判断排期得重要标准收到需求的时间3.4需求管理3.4.1需求池需求收集之后进入进入正式的需求池进行管理，每周一次从各方收集需求，并进行初步沟通之后，放进需求池。并根据需求本身的变动，调整需求池中的相关状态，标注相关的记录，批注。ID端口模块需求名称需求描述需求来源类型优先级提出时间提出人状态预计实现版本实际完成版本上线时间备注ID——需求的唯一ID号，需求身份标识，增加一个需求ID增加1。端口——需求所涉及的端口，前端如—安卓、iOS、小程序，后台—平台、供应商、商家，这是对需求做初步划分，如果涉及到多端，一般记为综合或拆分成多条子需求对应到各端口。模块——需求所涉及到的模块，例如会员管理、用户管理、商品管理等。需求名称——简单描述需求是做什么的需求描述——更详细描述需求的相关信息，例如需求提出的背景、需求要达成什么目的、需求的详细说明等。需求来源——记录需求的来源方，例如产品、市场、运营。类型——记录当前需求的类型，a、新功能；b、功能优化；c、bug修复。优先级——记录需求的优先级，a、一般用高中低；b、数字表达；c、需求的优先级是动态的，会随着战略、业务目标的变化而调整。提出时间——记录需求被提出的时间提出人——提出这个需求的人及联系方式，有助于在需求详细设计时追踪到原始需求。状态——需求当前的状态，根据不同的阶段，可以大致分为：a.记录——进入需求池（初始状态）；b.论证——需求开始评估论证；c.待设计——论证完成后有价值并决定近期开展后续工作；d,设计中——正在进行详细设计；e.设计完成——原型及UI已经设计完成；f.研发中——已正式安排研发周期；g.已上线——需求正式上线；h.已关闭——针对需求因各种原因提前终止其生命周期；i.预计版本——对需求计划上线的版本进行规划，产品部门规划的实现版本往往会超前正在研发版本g.实际完成版本——版本上线后，更新需求实现的实际版本号k.上线时间——记录版本实际上线的日期l.备注——各种情况的补充说明，例如需求关闭的原因，需求优先级变动原因，版本规划变动3.4.2需求优先级需求优先级的分析可以采用KANO模型、四象限法则、权重加权三种方式进行：3.4.2.1KANO模型以分析用户需求对用户满意的影响为基础，选择了两个维度：需求实现度、用户满意度。用这两个维度将需求区分，将需求分为5种，分别是：兴奋型需求——也称魅力型需求：随着满足用户期望程度的增加，用户满意度也会急剧上升，但一旦得到满足，即使表现并不完善，用户表现出的满意状况则也是非常高的。反之，即使在期望不满足时，用户也不会因而表现出明显的不满意。期望型需求——也称为意愿型需求：是指顾客的满意状况与需求的满足程度成比例关系的需求，此类需求得到满足或表现良好的话，客户满意度会显著增加，企业提供的产品和服务水平超出顾客期望越多，顾客的满意状况越好。比如说，支付方式，相对来说，是越多越好，这样用户会有更多选择，当没有一种支付或是其中一种没有资金的时候还有别的可供选择，能覆盖更多的用户。无差异需求——不论提供与否，对用户体验无影响，比如现在各平台都有的签到，打卡功能。基本型需求——也称为必备型需求、理所当然需求：是用户对企业提供的产品或服务因素的基本要求，比如现在互联网基本都有的客服功能。反向需求——又称逆向型需求：指引起强烈不满的导致低水平满意的需求，比如将产品流程设计的非常复杂，引起用户反感。针对不同类型的需求，采取不同的措施。3.4.2.2四象限法则四象限法则将需求分为：重要且紧急、重要不紧急、不重要但紧急、不重要也不紧急四类，两个选择维度是：紧急和重要。第一象限——包含一些紧急而重要的需求，这类需求具有时间的紧迫性和影响的重要性，无法回避也不能拖延，必须首先处理优先解决，比如支付功能出问题。第二象限——需求不具有时间上的紧迫性，但它具有重大的影响，需要ｗｂｓ方法分解任务、提前进行规划，按照计划逐步制性，比如数据埋点统计分析。第三象限——需求大多是些琐碎的杂事，没有时间的紧迫性，没有任何的重要性，这种需求的提出本身就存在一定问题，没有考虑清楚，可能是头脑发热，也可能是看着别人有就想做，与本身产品没有任何关联性，对这类需求可以放任不管，比如后台标题栏的颜色美观性第四象限——是那些紧急但不重要的需求，这些事情很紧急但并不重要，比如由于商品图片过大导致的加载慢（可以通过优化压缩上传图片解决）等，可以先采用替代方案执行3.4.2.3权重衡量对需求赋予一定的指标，进行量化分析，如工作量大小、对用户价值大小，对公司价值大小、紧迫程度、与核心流程相关性，可以将各指标赋予一定的权重（所有指标项权重相加为1，各指标项确定各自的程度数值，工作量按天计算时间越大，赋值越低）进行加权，得出综合值大的，则优先级高。如下图，需求2的综合得分为6.8》需求2的综合得分5.6，先做需求2：序号需求名称工作量（权重0.2）用户价值（0.3）公司价值（0.2）紧迫程度（0.2）核心流程相关性（0.1）综合分数1XXX367585.62XXX576976.83.5迭代规划3.5.1固定任务任务量固定，时间上可以进行调整，比如一个大的版本上线，新开的功能模块上线，即使采用MVP的方式，也会超出一般迭代的周期。这种方式一定是以保证业务、功能需求的完整性，系统性为主，不能完全按照时间来。否则的话，功能逻辑的完整性和链条就会缺失，上线之后会带来极坏的影响，如果功能不完整还不如不上线的好。3.5.2固定周期当产品进入稳定期之后，业务也较为稳定顺畅，则按照固定周期进行迭代，比如两周时间上新一个版本，则以时间为准，固定时间端，按照优先级并考虑工作量合理安排需求。3.5.3紧急需求在上一个版本发布之后，发现重大bug，需要紧急修复上线，这种肯定不能按照常规方式处理，直接将优先级提高，修复上线。3.5.4插入需求的处理紧急需求与插入需求有些类似，均是常规计划之外的。两者又有不同之处，紧急需求是不得不做的，不做将会带来严重影响的。插入式需求是计划已经排定，但又有新的需求进来，比如业务部门，上级领导等。这个时候从几个方面进行处理：1)根据需求规模，工作量大小，人力资源，是否能不动本次版本需求的基础上进行增加。如果可以则直接增加进去，如果不行，则将优先级低的需求进行删减。2)需求优先级不高，则沟通安排到之后的迭代四、产品设计阶段4.1总体流程4.1.1产品规划及评审与需求方对接需求，并经过评估，确定要做之后，即进行产品的规划。产品规划，将商业模式、盈利点、产品路线演化、主业务流程、核心功能模块确定之后，进行产规划的评审；评审通过之后进行低保真原型的绘制及PRD编写4.1.2产品设计及确认4.1.2.1概述产品经理依据需求概要设计（业务流程图+功能架构图+工作流状态定义）向需求方再次确认需求内容并阐述对应的解决方案。4.1.2.2注意事项信息在表述、理解过程中容易失真，需求review则是尽可能避免信息失真。受限于产品能力，或者需求复杂度高，需要输出系统级解决方案，“再确认”步骤必不可少。原型设计之后，进行评审，邀请评审的相关人员，中间可能会经历几次调整。具体邀请人这部分看具体公司，一般而言除产品及业务团队，研发介入越早越好，能够对部分功能的实现进行评估，产品在做原型设计的时候，也需要对相关功能进行调研，不能凭空想象。4.1.2.3输出内容完善低保真原型、完善PRD文档；修正业务流程图、功能架构图和工作流状态定义等需求概要内容。4.1.3视觉设计及评审原型设计评审通过，则移交资料给UI设计师并着手绘制高保真；UI设计师（如果有交互设计则相互配合，如果没有，产品也需要涉及交互设计）根据原型出设计图，UI设计师在产品原型评审阶段也需要介入。UI设计师设计完成之后进行评审，评审通过，则移交资料给研发团队。有些团队产品经理要承担项目的职责，则需要和研发人员共同制定开发进度计划。4.2产品原型设计4.2.1制定产品原型设计规范的目的及意义目的：产品原型的规范化，目的是清楚表达产品设计理念和功能交互及执行逻辑，提高产品、研发、UI及业务部门之间的沟通效率，避免信息不对称和信息传达的遗漏和缺失而导致的整个项目进度延期问题。1）让开发和设计团队提高设计开发质量及工作效率。2）统一设计规则，降低各方沟通成本。3）进行模块式的设计，降低开发成本和减少开发时间，加快产品迭代上线的速度。4)改善交互设计的水平，提升用户的使用体验。对于个人来说：规范性产品原型绘制能够提高个人的职业水平，标准，统一性，团队内部及协作单位的沟通成本也会降低，这能减少扯皮、反复沟通等问题，将更多时间放在产品的思考上，同时避免不必要的纠纷。4.2.2原型保真度比较4.2.2.1评价维度一般有五个维度来测量一个原型的真实（保真）程度。a、视觉精炼层次原型与最终产品看上去有多相似？一个低保真的原型也许就是一个手绘的草稿，而一个高保真原型就会是精确到像素，看上去和真实的产品没什么区别。b、功能的广度原型能够包含多少的功能？一个低保真的原型聚焦于那些最重要的任务，而高保真原型会有更细节的任务c、功能的深度每一个功能能够被多大程度地制作成原型？一个低保真的原型可以在页面和页面之间跳转，并在已有典型数据的情况下，告诉你大概的用户流程。一个高保真的原型可以让你输入数据，知道那些在进行不同的输入时影响到输出的区分。d、交互的丰富性原型中会有多少的交互？低保真原型也许会相当简单，在用户使用时没有任何的反馈信息。高保真原型将会考虑动画效果，表单验证，和所有用户与产品直接的细节交互。e、数据模型的丰富性你的原型中应用的数据有多丰富？低保真原型使用的是有限的，典型的数据设置，显示最常见的用例。高保真原型会包括边缘的情况，比如非常长的用户名（应该减少用户名的长度），无数据（提供默认人物头像），第一次使用（使用空白状态），或者极端大的数据量（使用翻页或者过滤）。产品原型设计根据还原度，也就是与最终成本的逼真度，分为低保真、中保真，高保真原型。4.2.2.2保真度

a、低保真原型表现软件的重点功能和基本交互过程，使用简易的线框进行处理，。好处是：制作成本低，速度快，修改也方便，在功能简单及团队沟通顺畅时可以使用b、

中度保真原型中度保真的产品添加了更多细节，对软件的交互进行了更细致的设计，比如照片处有对应内容照片，选项卡有具体内容，按钮颜色做了区分，有动效模拟。在大部分情况下，中度保真原型已经足够，既表现了软件的功能特性和交互过程，界面有一定的细节，而且使用者已经能完整体验到最终的产品，可以验证产品的可行性，确保了不会在后面的开发过程中发现重大失误。缺点是花费时间会多一些。c.

高保真原型几乎完全按照最终产品来制作的原型，细节丰富，包括了产品的所有功能以及详细的交互细节。制作高保真原型可以显著降低沟通成本，原型更精准和精美。但是，保真度越高就意味着需要花更多的时间和开发精力，而且一旦有修改也会更加耗费时间。d、各类保真度优劣总结低保真原型中保真原型高保真原型侧重点核心功能与产品框架具体功能流程及交互视觉呈现优点快速易修改适中的原型投入成本；较清晰的细节细节完善，沟通成本低缺点缺乏细节，沟通成本高仍缺乏一些细节，有一定的修改成本修改成本极高，容易分散精力4.3主流设计工具Axure：保密性更强，功能更强大，但是在线协作稍微差一点点。Xmind：绘制功能结构图（主要）；Visio：绘制用户使用流程、系统业务流程、功能架构等；Word：开发周期允许时撰写PRD；Excel：项目时间计划管理、项目会议纪要输出；4.4原型大纲一个完整项目的产品原型需要有“大纲”，包含内容如下：4.4.1产品的版本概况a、

版本记录：需明确记录原型的增删改内容及日期序号修订时间版本号修订内容类型（新增/修改）修订人备注12022.8.16V1.1.1登录注册修改XX增加第三方授权2b、功能点列表：列出该原型图的功能点，明确开发任务及优先级。对于分期开发，但原型已经出完的，标注不同功能开发的阶段，“1期”、“2期”等。模块功能子功能描述备注优先级首页筛选查找热门搜索1、系统设置的热门搜索词，可在后台进行设置4.4.2功能结构图a、使用xmind绘制，让开发人员了解整个功能框架、信息架构，利于估算开发时间。b、

功能结构图中使用的功能及页面名称要和“功能清单列表”保持一致，示例：4.5界面原型及逻辑说明4.5.1原型界面设计在绘制产品原型时，按思维导图的产品规划，先搭框架，制作主页面菜单，菜单支持多个级别，各页面的层级关系需要明确，但一般不要超过3级到4级，级数过多则意味着用户的使用层级深。设置母版，对于产品中的通用性功能、模块、建立统一的母版组建，为后期原型绘制提高便利性，如统一调用母版，统一修改母版。4.5.2逻辑交互说明包含数据逻辑和操作交互，主要是面向开发人员和UI设计人员阐述。描述要有利于功能逻辑的实现”，比如说，以下两种方式的准确性i.

点击账单结算按钮，跳转到账单支付页面。ii.

点击账单结算按钮，需要判断是否选中账单条目，所选中账单是否产生滞纳金a、如果没有选中账单，点击之后则当页弹窗提醒“您尚未选中待支付账单”，b、如果有选中账单，则跳转账单支付页面（对于不同情况下的点击效果，需要做多个按钮进行不同跳转，），可进一步说明不同跳转的切换效果，比如是左右滑动还是直接跳转等。对比以上两种方式，则第二种更明确，这也会减少沟通成本。4.5.3设计说明如果对设计有特殊要求的也需要做说明，比如支付的一般用明亮饱和的色调，专业性则一般采取蓝色，或者有设计可供参考的，配色等方面。4.6交互用例给主要交互控件设置交互用例，完善的交互能够帮助开发清晰的理解需求。4.7原型详细规范4.7.1页面层级树及每个页面命名的规则a、在页面层级树的第一个顶级菜单设置并填写【产品名称】，下面可以添加更多层级；b、版本号——采用子页面进行管理，页面名称命名：版本号+【版本编号】如版本号V1.1.1；c、修订记录——采用子页面进行管理，管理当前版本产品原型设计的修订记录——文章前部分已经做了说明；d、功能清单说明——采用子页面进行管理，使用表格说明本次产品原型中需求的主要内容和功能；e、正式原型部分：i、产品页面的层级，最高一般不超过4层；ii、产品模块，命名规则为“【序号】+【产品模块名称】”；iii、产品功能级页面，命名规则为“【序号】+【产品页面名称】”；命名规则与文章章节目录类似4.7.2母版制作与引用复用元件/组件，必须使用母版设计，然后再统一添加到页面上。在添加母版时，产品的背景，要求使用“位置锁定”，防止在原型绘制的过程中，背景变动频繁调整的情况；3.7.2.1页面母版的名称可自定义设置：“序号+自定义名称”；3.7.2.2全局性的母版和局部使用母版，需要在命名规则上做区分，3.7.2.3尽可能将众多页面都会使用到的标题（如小程序的头部）、元件（如日历）以及交互组件放置在母版中；4.7.3页面位置和尺寸规范4.7.3.1

PC默认尺寸为1280*960，APP/H5/小程序默认尺寸选择375HYPERLINK*6HYPERLINK67，并在之后的原型沿用；4.7.3.2APP的框架设计不区分Android与IOS，仅在交互用例的设计上进行区分；4.8流程制作规范“流程页面”设计并制作用户对本功能的使用流程，使用泳道流程图，一般而言是二维方式，横轴为角色，纵轴为流程进展，在流程旁边，给出必要的文字备注说明，对流程进行进一步的阐述。示例：4.9页面说明4.9.1交互设计及说明需按照产品原型规范要求，使产品原型上的所有功能板块能够准备模拟用户的操作情景，保证所有功能的动态面板交互、点击效果、页面跳转链接等交互效果准确并正确。并且为准确描述页面的交互效果需求。可在页面旁边增加“点击交互效果需求”的说明，来描述页面中每一个功能的操作交互需求。示例：4.9.2页面功能及逻辑的标注为了方便开发人员查看和理解，在产品原型中对功能的实现逻辑或使用的限制条件等进行说明。对页面的功能点进行编号，在对应编号进行说明备注范例：4.9.3页面流程图项目整体页面之间的交互流向逻辑，可以设置/生成一个工作流，可以点击进入之后，选择需要展示流向的页面，之后可以选择：4.9.3.1每个页面与页面整体交互的方式；4.9.3.2所有控件交互的流向两种方式进行自动生成。另一种页面流程交互流如下，这是按照业务流程进行分拆，按一个业务流程从头到尾，会走过哪些页面。下图即为示例，为订单相关的流程交互，从最开始的进入APP或网站首页》浏览商品》搜索》下单等，一直到最后支付成功，中间有异常流程也需要做说明。五、PRD文档撰写5.1写PRD的目的产品需求文档，即ProductRequirementDocumen，PRD的主要使用对象有：开发、测试、项目经理、设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；设计师可以通过PRD来设计交互细节。PRD文档是将产品项目由“概念化”阶段推进到“图纸化”，将需求落实到可开发的。PRD文档在产品项目中是一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。5.2PRD撰写的前提条件进行了需求收集与分析，构建了系统架构，绘制了功能结构图、信息结构图、产品结构图，2大流程图（业务、页面流程图）以及所有页面的原型稿、交互稿。完成这些部分之后，对以上部分进行有机的整合，撰写PRD文档。5.3PRD内容5.3.1文档编写记录记录文档创建，修改的情况，文档的编写状态，编写人，示例：日期名称版本状态签名2022.07.01建档1.04XX2022.08.01修改1.11XX备注：状态表示为：1.新建2.完成未审3.完成已审4.完成归档5.3.2文档修订记录记录每次修改的修改内容，更详细的进行记录每次修改的情况，对修改情况做概要性的描述，使查看人能够清晰的感知修订情况，示例：编号版本描述（包括：日期，变更图、表、段落号、标题或简单描述）修改类型A/M/D1v1.02备注：修改类型表示为：A.增加M.修改D.删除5.3.3目录根据PRD文档的章节自动生成生成，如果有变化进行更新整个目录的更新即可，示例：5.3.4概述a.背景介绍：简要说明产品/项目需求产生的背景，要达到的目的和需要实现的功能示例：通过建立招商加盟平台的商户管理系统，商户（招商公司）能够在商户后台直接发布项目、文章，进行自有项目的推广。商户（招商公司）能够在商户后台支付会员、广告宣传、站外文章发布等增值服务费用。可以接待来咨询访问的用户，并进行交谈，记录用户线索，形成用户档案。商户管理系统同时能为商户提供数据分析功能，对在该商家的访问、咨询、成交用户进行分析，对商户发布文章的宣传效果，广告投放效果进行综合分析，为商家的进一步业务开拓提供决策依据。b.涉及范围：描述本次需求，主要涉及到公司内部的哪些平台，并简要描述各平台应该做哪些事情示例：涉及范围描述XX招商加盟PC端增加企业管理系统的相关改造（广告投放、文章发布排名、咨询接口）c.阅读对象描述本文档的的阅读对象有哪些，一般包含：公司业务总负责人、各平级部门经理、产品经理、UI设计师、研发工程师、测试工程师等与本项目相关的所有人员。d.名词解释对项目或者行业的专业词汇的解释，对于较为独特的行业，或者专有名词的，复杂的系统，一定要进行名词解释。名词解释的目的：所有成员中达成认知的一致，防止一个事物多种命名的情况产生，提高信息的传递效率，消除歧义。名词解释普通用户所有使用XX平台内容搜索和咨询的外部用户商户在平台注册认证，发布招商项目，购买服务，进行项目推广的招商公司客服人员主要负责处理前端普通用户咨询服务的用户5.3.5结构图产品相关结构图一般包含3种：功能结构图、信息结构图、产品结构图a.功能结构图定义：

功能结构图就是以功能模块为类别，介绍模块下其各功能组成的图。作用：

产品设计时，辅助思路梳理，避免功能概念模糊、缺失。绘制功能结构时，尽量避免信息结构要素出现的可能性，形容一个功能点时建议多采用“动词+名词”的语言描述形式。示例：b.信息结构图定义：指脱离产品的实际页面，将产品的数据抽象出来，组合分类的图表。作用：帮助PM梳理复杂内容的信息组成，避免信息内容在展示过程中出现遗漏、混乱、重复；作为开发工程师建立数据库的参考依据；信息结构图的绘制通常晚于功能结构图，往往是在产品设计阶段的概念化过程中，在产品功能框架已确定、功能结构已完善好的情况下才对产品信息结构进行分析设计。示例：c.产品结构图定义：

产品结构图是综合展示产品信息和功能逻辑的图表

。可以理解为产品结构图是对产品原型的简化表达，产品结构图就是通过信息架构设计，将功能和信息以一种合理自然的逻辑，把功能结构图和信息结构图中的内容放入产品中的每一个页面的结果。示例：一般而言，直接采用产品结构图，对于概要描述，根据情况使用功能结构图，使用xmind制作产品功能结构图，并对产品功能进行简要描述。d.产品功能概要功能等级基本为三级+描述备注（模块、功能、子功能或者其它叫法），根据功能结构图而来，控制好级别，并进一步描述功能的内容和作用，对功能排列优先级，功能是否要进行分期开发，如果需要分期开发，则对应的开发周期需要注明，是否有另外的说明和备注，如果有则可以添加备注，尽量不要使用Excel中批注，很容易遗漏。示例：5.3.6核心业务流程对于本次需求中最核心的业务，采用泳道+文字描述的方式，对核心业务的阶段、步骤以及异常情况及判断进行描述。在画业务流程之前，要深入了解核心业务，与相关业务人员进行深入的沟通，确认。确定泳道（即任务），确定产品阶段，思考业务在各个阶段的形态，如果业务流程涉及多个部门的，需要共同进行沟通探讨，并可对部分流程进行优化。思考清楚后开始画业务流程图，在画的过程中也在头脑中进行梳理，尽可能的不遗漏任何的分支或异常情况。可以采用的思考方法：1)MECE——是MutuallyExclusiveCollectivelyExhaustive，中文意思是“相互独立，完全穷尽”。也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够藉此有效把握问题的核心，并解决问题的方法，也是找出异常流程的重要方法之一；2)5W1H分析——是对选定的事项、流程或操作，都要从原因（何因Why）、对象（何事What）、地点（何地Where）、时间（何时When）、人员（何人Who）、方法（何法How）等六个方面提出问题进行思考。可以寻找流程的改善方向，构思新的工作方法，以取代现行的工作流程方法；3)运用ECRS四原则——即取消、合并、重组和简化的原则，可以帮助人们找到更好的效能和更佳的工序方法）。业务流程图并不是一成不变的，在多次讨论会后中可能会有调整和变动。但每次调整或变动都需要进行明确，保证流程的清晰，不要存在核心流程的模糊死角。如果核心流程不清晰，则子流程以及后续很多工作都会导致极大的变动性，也会影响整体项目的进度，特别是在研发已经介入的情况，如果流程还存在不清晰的地方，开发工作也会反复。5.6.1核心业务流程跨职能的泳道图——泳道图中需将业务数据流所涉及的所有业务平台加入到泳道中，同时需区分正常流程和异常流程。示例：业务流程描述：用文字描述上述流程图中的所有流程，用以作为流程的补充说明，注意，流程中的每一步需以单独的数字序号进行描述。示例：优惠券发放、使用、核销流程（1）优惠活动创建优惠活动由平台设置。平台创建优惠活动，费用由平台、设备提供方、或其它方承担，具体承担方由运营进行设置之前与各方沟通确认，并在设置的之时进行确定。此处活动的设置，主要设置基本信息，如活动的优惠类型（满减、立减、折扣类型可适当减少，比如第一期只用满减），针对什么商品类别或是单个商品，针对区域店铺或者单个店铺。（2）优惠券发放从优惠活动中选择活动，设置优惠投放方案，如发放时间，有效期，针对门店，针对用户（新用户or老用户），自动发放还是用户手动领取设置投放方案后是否立即启用，如果启用，则在设置的投放时间向用户投放不支持正在投放的优惠券临时修改，只能停止作废，后台作废之后，用户端不管是否还在有效期内，均不能领取及使用正在使用的优惠券，优惠活动原始模板不能更改，如要改变，需单独创建。（3）领取使用如果是系统自动发放的优惠券，用户不需要单独进行领取，优惠券自动领取，在用户端优惠券中心可以看到如果需要用户领取的，用户可在领券中心进行领取用户在领取优惠券之后，升降柜的优惠券使用可让用户自己选择，双开门柜为拿货之后自动结算，则自动选择优惠券使用，以优惠最大的券为准。（4）核销结算用户使用优惠券购买商品之后，如果用户发生退款，则优惠券不退会，且不可再使用（即优惠券只能使用一次）如果订单中包含多个商品，均有使用优惠券，如果退款退货只退其中一部分，则优惠券也只退其中一部分，按比例进行摊薄进入清分结算的订单，有使用优惠券时，则在清分中按实际支付进行清分，并标注使用优惠券优惠券不进入清分，优惠券只进行费用承担，但使用该优惠券的订单结算完成后，该笔优惠券的费用承担状态为完成。备注：优惠券采用创建与发放分开的形式，创建为创建优惠活动，不配置具体的发送方案用户领取优惠券后，在购买商品时，进行金额的抵扣（用户级别不一，则抵扣金额和券的类别有差异）系统异常处理流程：主要描述跨系统、角色间的业务流转方面的异常处理逻辑。还有其它的一些通用异常处理：1)获取地理位置权限失败2)发送通知权限获取失败3)网络情况优惠券流程示例：1)优惠券发放错误，停止活动，则已发放的优惠券用户不能再使用，优惠券失效2)优惠券过期失效，不能再使用，并标记已过期失效，并给予提示3)退款订单中已使用的优惠券，不再恢复到可使用状态（即便未过期），直接作废4)其它5.3.7产品界面级功能及交互需求说明根据产品原型上的页面结构，构建功能需求说明树。示例：5.3.7.1功能一（界面）粘贴产品功能界面，并对产品功能界面的功能、交互进行描述，示例：菜单招商管理-》合同管理-》合同创建-基本信息功能创建合同用户场景当客户有意向签订时，创建合同，确认合同费用金额及履约条款优先级高前置条件已创建房源；已创建潜客后置条件-字段说明1.租客：从潜客列表中搜索2.租客联系人：选择租客后带出，可修改3.租客联系人电话：选择联系人后带出，可修改页面交互租客信息1.搜索租客时，输入关键字，远程搜索；选择租客后，填入客户联系人列表，可编辑；客户联系人选择后，填入联系电话，可编辑异常流程使用流程：以任务流方式，描述用户在完成该功能时的步骤、业务逻辑。示例（登录）：菜单：页面层级位置功能：模块作用用户场景：用户在什么时间、哪里，做什么事情要达到什么目的的描述优先级：决定HYPERLINK各模块接受系统资源的优先等级参数前置条件：发生这个用例的前提条件，满足条件才可以发生这个用例后置条件：发生这个用例之后的结果，会产生的影响字段说明：对列表记录字段进行解释说明页面交互：各页面间的交互，互动链接关系，以一个功能所涉及的相关页面为示例异常处理：描述业务发起过程中的异常处理流程。1.手机号做位数及类型限制，位数只能11位，只能是数字。2.密码由字母+数字构成，字母区分大小写，密码的组合方式为“大写字母or小写字母+数字”，如果用户输入字符与此规则不匹配，则进行提醒用户按规范输入3.如果用户未输入账号密码点击登录，手机账号：提示“手机账号未填写”；密码：提示“密码未填写”；账号与密码不匹配时，4.输入的账号未进行注册，提交检测在后台无记录，提示：用户账号不存在5.用户输入的账号与密码不匹配，则提示：用户名或密码输入错误5.3.8安全需求描述项目需要遵循的安全标准及需要进行安全验证等。验证包括手机短信、身份信息、银行信息，信用信息（芝麻信用）所有这些均有第三方接口进行验证，支付费用即可进行验证。5.3.9数据监测分析5.3.9.1数据监测采用数据埋点、数据采集等方法统计用户行为数据。第一种方式：自己开发——优点是保密性高，所有数据都在自己的平台中，但是很费时间，要想做的好，对技术也有一定要求第二种方式：使用第三方接口——比如友盟、神策、growio、百度等均提供接口，能快速的解决问题，另外growio，百度都有无埋点方式，就是不需要一个个数据点进行单独的埋点，而是监测所有有数据传输，操作行为的点，接入sdk之后，可以自主选择数据点进行分析。这种方式，不会存在遗漏，灵活度也非常高。5.3.9.2数据分析第一种方式也是完全自主开发，在早期的时候，数据量不大的时候，可以直接将数据导出进行Excel表的分析第二种方式是接入第三方接口，比如finebi、powerbi、DataFocus、tableau等，在选择第三方的时候要注意，是否满足企业要求（当下及后期），是否可以进行私有化部署，后期扩展的灵活性，是否简单易用。5.3.10系统日志需求对系统处理业务的操作记录或者逻辑记录在日志中，便于后期查找、追溯。5.3.1其它产品需求5.3.11.1性能需求明确产品的性能，知道产品性能上限，随着业务的发展，清楚改善节点。在早期考虑综合成本的情况并满足业务需求的情况下，可以对性能做一定的妥协。并发量：简单的可以说，同一秒的登录量，同时在线，订单并发量最高可以允许多少。比如客服系统，允许同时对话200，也就是允许同时存在200对话通道。图片加载：图片加载的时间，页面跳转切换的时间，在不同网速下，允许的时长（不同网络情况下，信号有强弱，可能根本4G、5G信号，或者用户的卡是3G）5.3.11.2兼容性、适配需求PC——兼容目前主流的浏览器，比如IE8、及Firefox3.5、safari、chrome等主流浏览器的主流版本，将相关版本进行罗列，同时考虑H5的跨设备适用性问题机型——通过各种渠道（talkingdata，友盟）查目前的主流机型，市场占比，根据公司情况，选择占比靠前的测试机型，或者采用第三方测试平台（testin，testbird）5.3.12相关文档A、原型地址B、消息通知模板用户消息通知序号模块具体功能消息接收人通知内容形式1登录注册注册用户【XX】已经注册成为平台的用户短信2留言回复平台回复留言用户【XX】您预约的留言反馈已得到回复，回复内容如下：XX，感谢您对我们的支持！消息通知C、其它商标，软著，域名、服务器、支付平台、消息接口、其它需要准备各类平台账号及及截止时间节点，部分事项可以并行，部分事项有严格的先后顺序，在进行计划安排时，需要作出区分，尽可能缩短时间，不要出现绝大部分人等一个人的情况出现。5.4产品向各方需求文档内容5.4.1给设计师文档思维导图、流程图、功能清单、原型图（含交互）。5.4.2给研发文档思维导图、功能清单、流程图、原型图、UI设计图、PRD文档、数据埋点文档5.4.3给运营文档思维导图、流程图、功能清单、PRD文档、产品使用说明书，上线资料准备清单（上线前需要准备的比如需要录入的商家信息）。六、版本命名、验收规范、发版管理6.1产品版本命名规则6.1.1版本命名规范软件版本号有四部分组成：第一部分为主版本号；第二部分为次版本号；第三部分为修订版本号；第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有五种，分别为base、alpha、beta

、RC

、

release。6.1.2版本号修改规则（1）主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化。此版本

号由项目经理决定是否修改。（2）次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部

的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。（3）修订版本号：一般是Bug

的修复或是一些小的变动或是一些功能的扩充，要经常发布

修订版，修复一个严重

Bug

即可发布一个修订版。此版本号由项目经理决定是否修改。（4）日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本

号。此版本号由开发人员决定是否修改。（5）希腊字母版本号：此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目经理决定是否修改。6.1.3版本阶段说明Base：此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。Alpha

：软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者

内部交流，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。测试

人员提交Bug经开发人员修改确认之后，发布到测试网址让测试人员测试，此时可将软件版本标注为alpha版。Beta

：该版本相对于Alpha

版已经有了很大的进步，消除了严重错误，但还需要经过多次

测试来进一步消除，此版本主要的修改对象是软件的UI。修改的的Bug

经测试人

员测试确认后可发布到外网上，此时可将软件版本标注为

beta版。RC

：该版本已经相当成熟了，基本上不存在导致错误的Bug，与即将发行的正式版本相差无几。Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是最终交付用户使用的一个版本。该版本有时也称标准版。6.1.4版本发布周期（1）非紧急情况：按照一般发包管理制度执行（2）紧急情况：如