注:
黑色为正常编辑
红色修改编辑
灰色文档已编写图未确定/待确定功能
按照时间顺序排序文档废弃
*红色星号为必填项
文档底色为黄色底色
一、范围
本规范适用于本公司所有产品的排期、文档、进度、交互、需求会、验收的全部过程,产品部门必须严格遵守。
二、产品排期
三、文档
注:文档更新需要及时的@相关人员
(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为修正版本号
- 项目初版本时,版本号可以为 0.1 或 0.1.0, 也可以为 1.0 或 1.0.0,如果你为人很低调,我想你会选择那个主版本号为 0 的方式;
- 当项目在进行了局部修改或 bug 修正时,主版本号和子版本号都不变,修正版本号加 1;
- 当项目在原有的基础上增加了部分功能时,主版本号不变,子版本号加 1,修正版本号复位为 0,因而可以被忽略掉;
- 当项目在进行了重大修改或局部修正累积较多,而导致项目整体发生全局变化时,主版本号加 1;
- 另外,编译版本号一般是编译器在编译过程中自动生成的,我们只定义其格式,并不进行人为控制。
- 编写人:自身名字全称编写
- 创建人是本人时直接编写后续文档
- 修改文档人发生变更时,需在下方添加编写人
- 不许使用别名
- 类型:针对于文档面向的应用端(app/web)
- 注明针对的具体端名称(以英文简写为准)
- 当出现app端与web端的功能交互时,分两个表格编写
- 主要变更内容:主要概述文档的修改内容
- 不允许出现表述不清,要做到见名知意
- 第一个创建内容蓝色标注,之后的修改黑色字
- 时间:更新创建文档的时间
- 时间不许写2022.02.09,写为2022.2.9
- 更新时间需要及时更新
1.模块目录
功能:模块的文档整理在开发完成之后把确认的文档放入模块中。
目的:方便、快捷的了解每个每个产品功能的时间、开发版本、文档编写人员、变更内容。
示例:
2.周开发目录
功能:在每周召开需求会之前必须编写完成文档的开发目录。
目的:方便、快捷的了解每个产品功能时间、开发版本、文档编写人员、变更内容。
示例:
(3)文档内容
- 文档编写放在最左侧,功能延续时,需要换行
- 功能单一性,保证一行只存在一个功能属性
- 展示页面需要把展示的所有属性列举(显示&显示规则)
- 排序每一个的排序前缀标明明确,用箭头划分优先级
- 报错给的错误码,标注明确
- 交互逻辑当出现标记时标注明确,当出现需要1,2,3,4.....说明时,严格遵循编号标记
- 原型图放在右侧,当出现标识时,注明标识定义
示例:
#显示&显示规则
返回按钮;
页面标题:教育经历;
提交审核;
#包含元素:
*所在地(通过三级联动选择省、市)
*院校名称(长度20个字,只能输入中文英文,不允许输入特殊字符)
*专业信息(长度20个字,只能输入中文英文,不允许输入特殊字符)
*入学年份(弹出时间窗口,选择时间) 【2022.2.10修改 ws】
*毕业年份(弹出时间窗口,选择时间,不可早于入学年份) 【2022.2.11 新增 rjq】
*学位(学士、硕士、博士)
*认证材料(提交图片格式 png/jpeg)
#排序规则&分页
动态排序:按照活跃度倒序——>创建人名称正序——>创建时间倒序 【2022.2.10修改 ws】
动态排序:按照活跃度倒序——>创建人名称倒序——>创建时间倒序 【2022.2.11 修改 rjq】
社团排序:按照发布时间倒序
分页一页展示15条数据
#报错文案
院校名称格式错误 院校名称格式错误
输入信息不完整 输入信息不完整
#交互逻辑
点击返回按钮,跳转至我的-简介
点击提交审核按钮,跳转至提交成功页
①修改提示 修改成功
1. 修改错误停留在本页面
2. 修改正确返回
②删除提示 删除成功
③返回按钮 返回个人主页
示例:
(4)流程图/xd图
- 流程架构图,逻辑清晰,说明准确
-
形成闭环
示例:
四、进度
- 严格控制产品编辑开发文档的时间进度
-
按时的把原型图给到ui设计
五、需求评审/需求会
(1)、需求评审
1、每周四进行下一周开发需求的需求评审会议。
2、会议发起人:产品经理
3、会议参与人:需求相关负责人、项目负责人、开发小组负责人。
4、会议内容:对照产品需求文档,讲解需求内容。会议参与人对需求做出合理性评估,开发可实现性评估。
5、会后:会议后产品经理对问题进行记录,修改,完善。
(2)需求会
1、周一进行开发需求的需求会。
2、会议发起人:产品经理。
3、会议参与人:参与本次需求开发的前端开发,后端开发,web开发,以及测试人员。
4、会议线上进行:将本次需要开发的需求完整的向开发和测试展示需求文档,原型图,以及讲述详细需求内容。
5、开会之前必须@到相关人员,确保全部人员进入会议。
(3)、验收
1、产品经理验收,在开发将本次功能提测时,产品经理同时去验收本次功能点的开发完成度,以及正确性。
2、发包之前,项目负责人对本次功能进行查验。
3、需要Android和ios端全部进行验收。
4、验收通过则进行发包,验收不通过则不允许发包。