产品文档规范

注:
黑色为正常编辑
红色修改编辑
灰色文档已编写图未确定/待确定功能
按照时间顺序排序 文档废弃
*红色星号为必填项
文档底色为黄色底色

一、范围

本规范适用于本公司所有产品的排期、文档、进度、交互、需求会、验收的全部过程，产品部门必须严格遵守。

二、产品排期

三、文档

注：文档更新需要及时的@相关人员

（1）、文档主目录

1.项目主目录不允许出现多级同项目出现
2.层级清晰
3.说明准确

示例：

潮星球 
  潮星球app
    潮星球v.1.0.0
      用户登录注册
      验证码登录
    潮星球v.1.0.1
      用户登录注册
      验证码登录
    潮星球v.1.0.2
  潮星球运营后台
    ....
  潮星球商家后台
    ....
  潮星球官网
    ....

（2）、编写目录清晰

---

• 版本号：以小写v开始，示例v.1.6.7 1为主版本号 6为子版本号 7为修正版本号

1. 项目初版本时，版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0，如果你为人很低调，我想你会选择那个主版本号为 0 的方式；
2. 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
3. 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0，因而可以被忽略掉；
4. 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1；
5. 另外，编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制。

• 编写人：自身名字全称编写

1. 创建人是本人时直接编写后续文档
2. 修改文档人发生变更时，需在下方添加编写人
3. 不许使用别名

• 类型：针对于文档面向的应用端（app/web）

1. 注明针对的具体端名称（以英文简写为准）
2. 当出现app端与web端的功能交互时，分两个表格编写

• 主要变更内容：主要概述文档的修改内容

1. 不允许出现表述不清，要做到见名知意
2. 第一个创建内容蓝色标注，之后的修改黑色字

• 时间：更新创建文档的时间

1. 时间不许写2022.02.09，写为2022.2.9
2. 更新时间需要及时更新

---

1.模块目录

功能：模块的文档整理在开发完成之后把确认的文档放入模块中。
目的：方便、快捷的了解每个每个产品功能的时间、开发版本、文档编写人员、变更内容。
示例：

微信截图_20220209133842.png

2.周开发目录

功能：在每周召开需求会之前必须编写完成文档的开发目录。
目的：方便、快捷的了解每个产品功能时间、开发版本、文档编写人员、变更内容。
示例：

image.png

（3）文档内容

---

• 1. 文档编写放在最左侧，功能延续时，需要换行
• 2. 功能单一性，保证一行只存在一个功能属性
• 3. 展示页面需要把展示的所有属性列举（显示&显示规则）
• 4. 排序每一个的排序前缀标明明确，用箭头划分优先级
• 5. 报错给的错误码，标注明确
• 6. 交互逻辑当出现标记时标注明确，当出现需要1,2,3,4.....说明时，严格遵循编号标记
• 7. 原型图放在右侧，当出现标识时，注明标识定义

---

示例：

#显示&显示规则
返回按钮；
页面标题：教育经历；
提交审核；
#包含元素：
   *所在地（通过三级联动选择省、市）
   *院校名称（长度20个字，只能输入中文英文，不允许输入特殊字符）
   *专业信息（长度20个字，只能输入中文英文，不允许输入特殊字符）
   *入学年份（弹出时间窗口，选择时间）    【2022.2.10修改 ws】
   *毕业年份（弹出时间窗口，选择时间，不可早于入学年份） 【2022.2.11 新增 rjq】
   *学位（学士、硕士、博士）
   *认证材料（提交图片格式 png/jpeg）

#排序规则&分页
动态排序：按照活跃度倒序——>创建人名称正序——>创建时间倒序   【2022.2.10修改 ws】
动态排序：按照活跃度倒序——>创建人名称倒序——>创建时间倒序    【2022.2.11 修改 rjq】
社团排序：按照发布时间倒序
分页一页展示15条数据

#报错文案
院校名称格式错误   院校名称格式错误
输入信息不完整       输入信息不完整

#交互逻辑
点击返回按钮，跳转至我的-简介
点击提交审核按钮，跳转至提交成功页
①修改提示 修改成功
  1.  修改错误停留在本页面
  2.  修改正确返回
②删除提示  删除成功
③返回按钮  返回个人主页

示例：

Image.png

（4）流程图/xd图

1. 流程架构图，逻辑清晰，说明准确

2. 形成闭环
   示例：

   
   20220127-155416.png

四、进度

1. 严格控制产品编辑开发文档的时间进度

2. 按时的把原型图给到ui设计

   
   微信截图_20220209133842.png

五、需求评审/需求会

(1)、需求评审

1、每周四进行下一周开发需求的需求评审会议。
2、会议发起人：产品经理
3、会议参与人：需求相关负责人、项目负责人、开发小组负责人。
4、会议内容：对照产品需求文档，讲解需求内容。会议参与人对需求做出合理性评估，开发可实现性评估。
5、会后：会议后产品经理对问题进行记录，修改，完善。

（2）需求会

1、周一进行开发需求的需求会。
2、会议发起人：产品经理。
3、会议参与人：参与本次需求开发的前端开发，后端开发，web开发，以及测试人员。
4、会议线上进行：将本次需要开发的需求完整的向开发和测试展示需求文档，原型图，以及讲述详细需求内容。
5、开会之前必须@到相关人员，确保全部人员进入会议。

（3）、验收

1、产品经理验收，在开发将本次功能提测时，产品经理同时去验收本次功能点的开发完成度，以及正确性。
2、发包之前，项目负责人对本次功能进行查验。
3、需要Android和ios端全部进行验收。
4、验收通过则进行发包，验收不通过则不允许发包。