214 lines
12 KiB
Markdown
214 lines
12 KiB
Markdown
# 用户故事 (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：报警处理与上报**
|
||
- **作为** 系统运维人员老周，
|
||
- **我想要** 在收到系统或业务异常报警（如库存异常、交易异常、物流延误）时，可以在后台查看详情、处理并记录处理结果，同时支持一键上报给相关负责人，
|
||
- **以便于** 异常问题能被快速响应和闭环处理，减少对业务的影响。 |