Initial commit
This commit is contained in:
214
01_设计/用户故事.md
Normal file
214
01_设计/用户故事.md
Normal file
@@ -0,0 +1,214 @@
|
||||
# 用户故事 (User Stories) - 绿邻回收项目
|
||||
|
||||
> 本文档旨在通过具体的用户故事,详细描述“绿邻回收”项目中不同角色的需求、行为和期望,从而指导产品设计与开发。
|
||||
|
||||
---
|
||||
|
||||
## 角色一:老百姓 (C端用户)
|
||||
|
||||
### 1.1. 核心诉求:方便、省心、价格透明地卖掉家里的废品
|
||||
|
||||
#### **用户画像:王大妈**
|
||||
- **身份**: 65岁退休居民,社区活跃分子。
|
||||
- **习惯**: 精打细算,会用微信基础功能(聊天、发朋友圈、支付),但对复杂App有畏惧心理。
|
||||
- **痛点**: 楼下收废品的小贩时间不固定,价格随口报,还总想压价
|
||||
|
||||
### 1.2. 用户故事
|
||||
|
||||
#### **故事1:查看回收价格**
|
||||
- **作为** 王大妈,
|
||||
- **我想要** 在出门前就能通过小程序看到今天纸壳子、塑料瓶卖多少钱一斤,
|
||||
- **以便于** 我决定今天是否值得跑一趟,并且心里有底,不怕被坑。
|
||||
|
||||
#### **故事2:找到最近的回收站**
|
||||
- **作为** 刚搬来小区的年轻人小张,
|
||||
- **我想要** 在小程序上用地图直接看到最近的回收站在哪,离我有多远,现在是否在营业,
|
||||
- **以便于** 我能快速方便地处理掉家里堆积的快递纸箱。
|
||||
|
||||
#### **故事3:极速卖品**
|
||||
- **作为** 王大妈,
|
||||
- **我想要** 到小站后,让站长扫一下我的手机二维码,他称重、确认后,钱就能马上到我的小程序账户里,并且能听到“收款成功,5块8”这样的语音提醒,
|
||||
- **以便于** 整个过程像在超市用付款码一样简单,不用我输密码、点确认,甚至不用掏手机看,听声音就知道交易成功了,非常安心。
|
||||
|
||||
#### **故事4:查看我的收入**
|
||||
- **作为** 王大妈,
|
||||
- **我想要** 在“我的”页面清楚地看到我的账户里还有多少钱,并且能翻看每一笔卖废品的记录,
|
||||
- **以便于** 我知道这个月靠卖废品攒了多少零花钱,感觉很有成就感。
|
||||
|
||||
---
|
||||
|
||||
## 角色二:小站管理员
|
||||
|
||||
### 2.1. 核心诉求:操作简单高效,不影响主业,账目清晰,交接方便
|
||||
|
||||
#### **用户画像:李老板**
|
||||
- **身份**: 45岁,社区便民超市店主,兼营回收小站。
|
||||
- **习惯**: 熟悉智能手机操作,对钱款非常敏感,追求效率。
|
||||
- **痛点**: 手工记账容易出错,废品堆在店里不知道什么时候能被拉走,跟司机交接时核对重量很麻烦。
|
||||
|
||||
### 2.2. 用户故事
|
||||
|
||||
#### **故事1:快速开始回收**
|
||||
- **作为** 李老板,
|
||||
- **我想要** 在小站端小程序首页最显眼的位置有一个“开始回收”的大按钮,
|
||||
- **以便于** 当有居民来卖废品时,我能一键进入回收
|
||||
流程。
|
||||
|
||||
#### **故事2:高效完成回收**
|
||||
- **作为** 李老板,
|
||||
- **我想要** 扫完居民的码后,直接在屏幕上点选“纸壳”、“塑料瓶”等大按钮,然后输入重量,系统能自动算出价格,
|
||||
- **以便于** 我可以快速完成一笔交易,减少顾客等待时间,尤其是在我超市生意忙的时候。
|
||||
|
||||
#### **故事3:查看今日战果**
|
||||
- **作为** 李老板,
|
||||
- **我想要** 在小程序首页看到今天收了多少单、各种废品有多重、总共收入了多少钱,
|
||||
- **以便于** 我能随时掌握回收业务的经营状况,做到心中有数。
|
||||
|
||||
#### **故事4:库存盘点与交接**
|
||||
- **作为** 李老板,
|
||||
- **我想要** 能在小程序里看到店里各种废品的库存重量,并且在库存快满时,能一键生成出库单并通知物流来收货,
|
||||
- **以便于** 我可以合理安排店铺空间,并与运输司机高效、准确地完成交接,避免扯皮。
|
||||
|
||||
---
|
||||
|
||||
## 角色三:下站运输员 (物流司机)
|
||||
|
||||
### 3.1. 核心诉求:路线清晰,任务明确,交接高效,权责分明
|
||||
|
||||
#### **用户画像:张师傅**
|
||||
- **身份**: 35岁,回收车队司机。
|
||||
- **习惯**: 每天需要跑多个点,时间观念强,不希望在交接流程上浪费时间。
|
||||
- **痛点**: 路线规划不合理导致绕路,手写单据字迹潦草易出错,跟小站站长核对重量时偶尔会发生争执。
|
||||
|
||||
### 3.2. 用户故事
|
||||
|
||||
#### **故事1:查看揽收任务**
|
||||
- **作为** 运输员张师傅,
|
||||
- **我想要** 在我的手机端(H5或小程序)看到今天所有需要去揽收的任务列表,并能一键开启导航,
|
||||
- **以便于** 我可以合理规划路线,节省运输时间。
|
||||
|
||||
#### **故事2:无纸化扫码交接**
|
||||
- **作为** 运输员张师傅,
|
||||
- **我想要** 到达小站后,直接扫描站长出示的出库二维码,手机上就能显示出待交接的品类和重量,
|
||||
- **以便于** 我可以快速核对,确认无误后双方点击确认即可完成交接,无需手写单据,高效且有据可查。
|
||||
|
||||
#### **故事3:更新任务状态**
|
||||
- **作为** 运输员张师傅,
|
||||
- **我想要** 在完成揽收、运输、入库等关键节点时,能在手机上方便地更新任务状态,
|
||||
- **以便于** 公司后台能实时了解我的工作进展,也方便了后续的流程协同。
|
||||
|
||||
---
|
||||
|
||||
## 角色四:大仓库管理员
|
||||
|
||||
### 4.1. 核心诉求:入库清晰,库存准确,出库便捷
|
||||
|
||||
#### **用户画像:赵主管**
|
||||
- **身份**: 50岁,城市大仓的仓库主管。
|
||||
- **习惯**: 工作严谨,对数据准确性要求高。
|
||||
- **痛点**: 司机运回来的货物品类和重量与预期不符,库存盘点耗时耗力,与下游打包站的销售记录对账困难。
|
||||
|
||||
### 4.2. 用户故事
|
||||
|
||||
#### **故事1:扫码确认入库**
|
||||
- **作为** 仓库主管赵主管,
|
||||
- **我想要** 在司机把废品运到大仓时,我能扫描他任务单上的二维码,系统就自动记录某某司机在什么时间、从哪些小站运来了多少斤什么废品,
|
||||
- **以便于** 我可以快速完成入库登记,保证数据的准确性,并自动更新仓库库存。
|
||||
|
||||
#### **故事2:实时库存监控**
|
||||
- **作为** 仓库主管赵主管,
|
||||
- **我想要** 在后台系统的大屏或电脑上,实时看到仓库里所有品类的库存量、存放位置和存放天数,
|
||||
- **以便于** 我可以合理规划仓储空间,并在某种废品库存达到一定数量时,及时安排出库销售。
|
||||
|
||||
#### **故事3:生成出库单**
|
||||
- **作为** 仓库主管赵主管,
|
||||
- **我想要** 当联系好下游的打包站后,能在系统里选择品类和重量,一键生成标准化的出库单,
|
||||
- **以便于** 我可以指导工人备货,并作为与打包站结算的凭证,让整个出库流程规范化。
|
||||
|
||||
---
|
||||
|
||||
## 角色五:区域经理
|
||||
|
||||
### 5.1. 核心诉求:全局掌控,数据驱动,精细运营
|
||||
|
||||
#### **用户画像:小陈**
|
||||
- **身份**: 28岁,公司运营经理,负责一个城市的业务。
|
||||
- **习惯**: 擅长使用各类办公软件,关注数据报表,希望通过数据发现问题、驱动决策。
|
||||
- **痛点**: 无法实时了解各小站的经营状况,调整价格需要层层通知效率低,缺乏有效的数据来评估业务健康度。
|
||||
|
||||
### 5.2. 用户故事
|
||||
|
||||
#### **故事1:查看运营数据大盘**
|
||||
- **作为** 区域经理小陈,
|
||||
- **我想要** 在管理后台的首页看到一个数据驾驶舱,实时展示今日交易额、活跃用户数、各小站回收量排名、各品类回收趋势图等核心KPI,
|
||||
- **以便于** 我能一目了然地掌握整个区域的业务动态,快速发现异常。
|
||||
|
||||
#### **故事2:动态调整回收价格**
|
||||
- **作为** 区域经理小陈,
|
||||
- **我想要** 当废品市场价格波动时,能在后台方便地调整某个或所有小站的某个品类的回收单价,并且能立即生效,
|
||||
- **以便于** 我可以灵活应对市场变化,保证公司的利润空间,同时保持对用户的吸引力。
|
||||
|
||||
#### **故事3:管理与拓展小站**
|
||||
- **作为** 区域经理小陈,
|
||||
- **我想要** 在后台看到所有小站的地理分布、状态和详细信息,并能处理新的小站入驻申请,
|
||||
- **以便于** 我可以进行精细化的小站运营管理,并为BD团队的拓展工作提供数据支持。
|
||||
|
||||
---
|
||||
|
||||
## 角色六:后台系统运维人员
|
||||
|
||||
### 6.1. 核心诉求:保障系统稳定、安全、高效运行
|
||||
|
||||
#### **用户画像:老周**
|
||||
- **身份**: 38岁,公司IT运维工程师。
|
||||
- **习惯**: 熟悉服务器运维、数据库管理、系统监控工具。
|
||||
- **痛点**: 系统出问题时缺乏实时告警,日志分散难以排查,版本更新缺乏回滚机制,安全漏洞修复不及时可能影响业务。
|
||||
|
||||
### 6.2. 用户故事
|
||||
|
||||
#### **故事1:实时监控与告警**
|
||||
- **作为** 系统运维人员老周,
|
||||
- **我想要** 在运维后台或监控平台上实时查看服务器、数据库、网络的运行状态,并在出现异常(如CPU过高、数据库连接数过多、接口响应超时)时收到短信/邮件/企业微信告警,
|
||||
- **以便于** 我能第一时间介入处理,减少系统宕机时间,保障业务连续性。
|
||||
|
||||
#### **故事2:集中化日志管理**
|
||||
- **作为** 系统运维人员老周,
|
||||
- **我想要** 所有服务端、数据库、应用日志能集中到一个可检索的平台(如ELK、Grafana Loki),并支持按时间、关键字、服务模块快速筛选,
|
||||
- **以便于** 我能高效定位问题根源,缩短故障排查时间。
|
||||
|
||||
#### **故事3:安全与权限管理**
|
||||
- **作为** 系统运维人员老周,
|
||||
- **我想要** 能定期查看和管理系统的访问权限、API密钥、数据库账号,并对异常登录行为进行告警,
|
||||
- **以便于** 我能防止未授权访问,保障数据和系统安全。
|
||||
|
||||
#### **故事4:版本更新与回滚**
|
||||
- **作为** 系统运维人员老周,
|
||||
- **我想要** 在发布新版本时,系统能自动备份当前版本,并在新版本出现严重问题时一键回滚,
|
||||
- **以便于** 我能快速恢复系统到稳定状态,减少对业务的影响。
|
||||
|
||||
#### **故事5:容量与性能规划**
|
||||
- **作为** 系统运维人员老周,
|
||||
- **我想要** 定期查看系统的资源使用趋势(CPU、内存、磁盘、带宽),并在接近阈值时收到扩容建议,
|
||||
- **以便于** 我能提前规划资源,避免因资源不足导致的性能下降或宕机。
|
||||
|
||||
### 6.3. 业务运维扩展故事
|
||||
|
||||
#### **故事6:添加和管理站点信息**
|
||||
- **作为** 系统运维人员老周,
|
||||
- **我想要** 在后台可以方便地添加新的回收小站信息,包括名称、地址、地理位置、负责人联系方式、营业时间等,
|
||||
- **以便于** 新站点能快速接入系统并开始运营,同时保持站点信息的准确性。
|
||||
|
||||
#### **故事7:定义产品分类和价格**
|
||||
- **作为** 系统运维人员老周,
|
||||
- **我想要** 在后台可以新增、修改、停用回收品类,并为不同区域或站点设置不同的回收价格,
|
||||
- **以便于** 系统能灵活应对市场价格波动和业务策略调整。
|
||||
|
||||
#### **故事8:设置物流损耗参数**
|
||||
- **作为** 系统运维人员老周,
|
||||
- **我想要** 在后台为不同品类设置合理的运输损耗比例(如纸壳运输损耗2%),
|
||||
- **以便于** 在结算时自动扣除损耗,保证财务数据的准确性和公平性。
|
||||
|
||||
#### **故事9:报警处理与上报**
|
||||
- **作为** 系统运维人员老周,
|
||||
- **我想要** 在收到系统或业务异常报警(如库存异常、交易异常、物流延误)时,可以在后台查看详情、处理并记录处理结果,同时支持一键上报给相关负责人,
|
||||
- **以便于** 异常问题能被快速响应和闭环处理,减少对业务的影响。
|
||||
Reference in New Issue
Block a user