产品笔记（1）
这篇记录在项目中学到的产品知识。
需求属性
| 需求属性 | 属性说明 |
|---|---|
| 编号 | 需求的顺序号，唯一性标识 |
| 提交人(*) | 需求的录入PD，负责解释需求 |
| 提交时间 | 需求的录入时间，辅助信息 |
| 模块(*) | 根据产品的模块划分 |
| 名称(*) | 用简洁的短语描述需求 |
| 描述(*) | 需求描述：无歧义、完整性、一致性、可测试等 |
| 提出者 | 即需求的原始提出者，有疑惑时便于追溯 |
| 提出时间 | 原始需求的获得时间，辅助信息 |
| Bug编号 | 一些Bug视为需求，统一管理 |
| 分类 | 新增功能、功能改进、体验提升、Bug修复、内部需求等 |
| 层次 | 基础、扩展（期望需求）、增值（兴奋需求） |
| 重要性 | 重要程度，辅助确定商业价值 |
| 紧迫度 | 紧急程度，辅助确定商业价值 |
| 持续时间 | 持续时间，辅助确定商业价值 |
| 商业价值(*) | 商业优先级，不考虑实现难度，群体决策 |
| 开发量(*) | 需求的开发工作量，表征实现难度 |
| 性价比(*) | “商业价值/开发量”，用于决定先做哪个 |
| 状态(*) | 需求生命周期：待讨论、暂缓、拒绝、需求中、开发中、已发布 |
| 负责PD(*) | 状态进入“需求中”后确定 |
| 开发工程师 | 状态进入“开发中”后确定 |
| 项目名称 | 需求的发布项目 |
| 发布时间 | 需求的发布时间 |
| 备注 | 其它任何信息，如：1.被拒绝的理由 2.被暂缓的理由和重启条件 3.其它相关文档 …… |
需求文档
管理台—登录/个人中心需求文档
| 文档名称 | XX系统化 V1.0.0需求文档 |
|---|---|
| 所属产品 | |
| 迭代版本 | |
| 文档状态 | 编写中 |
| 人员职责 | |
| 原型地址 | |
| UI设计文档地址 | |
| 备注 |
| 需求概要 | |
|---|---|
| 部署方式 | 私有化部署 |
| 文档状态 | IN REVIEW / v0.1.0 |
| 产品负责人 | ginny |
| 产品版本 | v0.1.0 |
| 产品名称 | 我的产品 |
| 原型 link |
变更记录
| 时间 | 版本 | 变更人 | 变更说明 |
|---|---|---|---|
| 2023-1-1 | v0.1.0 | ginny | 初版需求文档 |
一、名词定义及方法论
| 名词 | 定义 | 备注 |
|---|---|---|
| 集群管理员 | 拥有平台最高权限，能够登录集群管理平台。目前有且仅有一位，后续支持增加管理员 | admin用户 |
二、功能性需求
| 一级功能 | 功能说明 | 优先级 | 备注 |
|---|---|---|---|
| 个人中心 | 支持查看个人信息 | 3 |
三、功能性需求详细说明
| 功能 | 详细说明 | 备注 |
|---|---|---|
| XX管理列表 | 列表字段包括：XXX |
四、性能需求
支持最大管理X台机器。允许支持X个用户的创建。
支持100人同时登录/注册平台。支持2000人同时处于登录状态。
五、产品边界与限制
六、附录
产品里程碑规划
| 时间 | 202X.3 | 202X.6 | 202X.12 |
|---|---|---|---|
| 商业化目标 | |||
| 产品目标 | 产品功能：输出XXX | 产品功能：完成mvp版本，配备XXX，功能包括：XXX | 产品质量： 稳定性达到70% |
| 研发目标 | 依赖环境搭建完成 |
竞品分析
一、调研背景
二、产品基本信息
1.产品定位/产品介绍/产品价值
2.面向用户/适用行业
3.产品优势
三、产品架构
四、功能分析
版本管理
版本管理是对软件开发过程中特定功能的集合或特定代码构建结果进行管理。版本管理是为满足不同需求，对同一产品或系统进行局部的改进和改型所产生的产品或系统系列的变更情况进行记录、跟踪、维护和控制的过程。
版本号定义
A.B.C.D
A—主板本号：当发生大的版本迭代、如架构重构、页面重构或有颠覆性功能上线时，主版本号+1。
B—次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。次版本号+1。
C—修订版本号：当每个次版本中规划出多个sprint时，每个sprint结束后，版本更为为修订版本更新，修订版本号+1.
D—日期版本号：当客户侧/内测时出现bug需要紧急修改，并且临时发版时，使用日期版本号。
版本迭代节奏
每个Q发布一个大版本，其中一个Q内再以两周为一个sprint周期进行迭代，每完成一个sprint，修订版本号+1
sprint内开发测试流程
每个Q最后一个sprint预留用于对本Q要上线功能的整体回归以及内部用户试用的内测阶段，并根据回归测试或内测时发现的bug进行修复，一般情况不进行功能开发。
git版本管理
master： 用于生产部署的版本，永远不会commit，只能由hotfix、release分支合并，并打tag
develop： 开发用的主分支
feature： 开发特性的分支，由develop分支创建，最终合并到develop
release： 当大版本中所有特性都完成开发后，由develop分支创建release分支，进行qa测试
hotfix： 线上出现bug时，从master生产一个bugfix版本，修复完成后，合并到master和develop分支并打tag
部署 & 环境
环境资源需求
| 环境 | 用途 | 配置 | 数量 | 开始时间 | 结束时间 | 拥有者 | 缺口 | 缺口成本 |
|---|---|---|---|---|---|---|---|---|
| 开发环境 | cpu:48核，内存512G，硬盘2T+8T | 1 | ||||||
| 测试环境 | ||||||||
| 运维开发 | 公共组件、存储服务 | 硬盘100T | ||||||
| 网络设备及配件 |
环境清单
| 环境类型 | 环境用途 | 环境负责人 | 环境配置 | 环境数量 |
|---|---|---|---|---|
| 开发环境 | 用于每个sprint功能开发 | 研发 | ||
| 测试环境 | 用于每个sprint功能测试 | QA | ||
| 内部稳定环境 | 作为内部正式使用的稳定环境 | PM | ||
| 外部PoC/Demo试用环境 | 面向外部客户前期交流时，用户试用环境 | PM | ||
| 客户私有环境 | 客户签订合同后部署的正式使用环境 | 客户联系人 |
问题级别
【阻塞级问题】：常规操作导致系统崩溃，数据丢失或异常、流程无法正常显示、继续和结束。一天内改完
【严重级别问题】：影响主要功能实现，出现非正常的结果或错误，主要或次要功能缺失不能满足需求设定。两天内改完
【一般问题】：影响次要功能实现和显示类bug，不影响系统使用，包括但不限于交互或显示与设计稿出现偏差，如文案提示、位置偏移等。尽量本周改完
【轻微问题】：即功能优化、实现逻辑的优化，交互和视觉层面优化的建议等。视紧急程度修改可作为优化项后续版本迭代。