8.4 设备报修系统交付复盘

8.4 设备报修系统交付复盘

本节摘要：华彩行政部委托的"办公设备报修台账"是一个教科书级的复盘样本：需求小到两周能交付，又全到足以把八章手艺各用一遍。本节按真实时间线重走全程——从口头需求到三张表，从一次翻车到一次返工，再到按第 7 章模板完成上线——你可以把它当作毕业后第一个独立项目的施工图纸。

导语里承诺过：读完这套教程，你能独立交付一套小型数据管理系统。空口无凭，这一节拿实际项目验收。项目本身平平无奇：华彩行政部门管着六十多台打印机、空调、碎纸机的维修事宜，此前靠一本纸质登记簿和微信群各记一半，每次对账都鸡飞狗跳。委托一句话就能说完："让报修有地方登记、有人认领、有据可查。"

第一步：把含混的需求翻译成边界

进场第一天照例不碰软件，先花一小时问出真正的边界。行政主管的原话很多，剥掉情绪后留下的有效诉求就三条：员工找得到入口提单、行政看得到待办清单、年底能统计每台设备的维修花费。至于"最好还能自动派短信提醒师傅"，经讨论砍掉了——他们没有预算买短信服务，而行政每天上午固定开两次台账点名待办，人工派单完全够用。

这番对话确定了两条边界：系统只做登记与流转的可视化，不做即时通讯；使用者为行政一人加全体员工（员工仅提单），并发规模个位数。对照第 1 章的能力清单，Access 稳稳胜任，立项。

第二步：建模，以及一次忍住没做的抽象

实体识别很顺：设备、报修单、处理人。第一版草案却长出了第四张表的苗头——行政主管提到"有些维修是外部供应商来的，要留对方电话"。新手会立刻建一张供应商表，我们停了一下：

供应商在本系统里只是报修单上的几个文字属性（名称、联系人、电话），没有独立流程挂在它身上；年度统计也从不按供应商汇总。按第 2 章 2.2 节的准则——属性不独立成表，除非它有自己的生命周期或被多方引用——决定先用三个短文本字段承载，并把这句话写进数据字典备查。三个月后若真出现"按供应商考核"的需求，再升级为表也不迟，数据迁移用生成表查询十分钟的事。克制过度设计，是小项目活下来并活得舒服的关键。

最终结构三张表：

关系与完整性照第 2 章 2.3 节办理：Ticket.DeviceID 对 Device 建一对多并启用参照完整性，杜绝"查无此机"的孤儿单。状态字段定为短文本、默认值"已登记"，并用查阅向导限定为五个取值。

待办清单是系统的灵魂查询，SQL 不过十来行：

-- 行政上午点名的"未关闭工单"清单
SELECT t.TicketID, d.Category, d.Location,
       t.FaultDesc, t.Status, t.RegisteredOn
FROM tblRepairTicket AS t
INNER JOIN tblDevice AS d ON t.DeviceID = d.DeviceID
WHERE t.Status <> "已解决" And t.Status <> "已评价"
ORDER BY t.RegisteredOn;
​

再配一个按科室筛选的参数查询（提示语写"输入位置关键词"）给年底盘点用。查询层到此为止——第 3 章教过的东西，够用了。

图：一张报修单的五种状态与回退通道

中场翻车：状态字段引发的连锁反应

第二周换了个跟头。为了报表里区分"内部师傅修的还是外委修的"，行政自作主张在状态栏里填了"处理中-外委""处理中-内修"两个新花样。当天待办清单查询就漏了单——WHERE 条件里没有这两个新词。事故本身两分钟修复（把例外值归位），但暴露的问题值得记住：自由文本充当枚举，迟早被用户的教育能力击穿。

加固动作有三层：状态字段改成带"限于列表"的查阅列，键入即拦；核心窗体的状态组合框锁死五个选项；每月例行跑一句 GROUP BY 状态字段的小查询，出现第五种取值立即可见。这场小翻车后来成了我给所有客户讲解参照完整性的现成教材——第 2 章讲道理，这里见到尸体。

交付配置：照抄第 7 章的模板

上线动作全是复习：拆分前后端（7.2）、后端加密加强密码、前端按岗位分发（7.1）；备份日历挂进行政的周五关机流程，压缩修复随周一开机顺手做（7.3）；版本号从 v1.0.0 起步，错误日志表同步建好（7.4）。培训走十五分钟路径，全员宣讲只讲一件事：微信扫码进表单页，填四格提交。一周后回访，登记簿光荣退休，群里再没人发过"打印机又坏了谁来看看"。

一个月后的回访：使用者的真实证词

复盘要有下半场——交付满月时回去听证明。行政台账给出了三组有意思的信号：其一，使用曲线比预想陡，第一个周日均只有四张单，第三周爬到十一张后稳住——员工养习惯需要两周，这个数字后来成为我给其他客户预估冷启动期的依据；其二，状态字段里"已解决"到"已评价"之间存在两天左右的滞留，说明评价动作缺提醒，补了一个主控台红色计数提示就消解了；其三，最有趣的一条——采购提出想在设备累计维修花费超过残值时自动亮灯建议报废。

第三个信号我们没有接。它真实、合理且技术上不难（一条聚合查询加条件格式），但会让系统第一次产生"建议类决策"，口径谁定、错了算谁的都要先说清。把它放进需求池标为待评估，是这个项目学到的最后一课：不是所有能做的事都该马上做，小系统的生命力恰恰来自每次都对范围说不的克制。

如果重来，我会改的三件事

复盘不是自我表扬，留三条具体的改进：

• 提单入口该更早想到浏览器表单：用 SharePoint 清单接收、定时收进 accdb（第 6 章的路子），比让员工开桌面文件门槛更低；
• 费用字段一开始就该设为货币型而非数字型：年底统计时格式混乱花了半小时清理，起因只是建表那天的随手；
• 处理记录应另立从表：目前备注挤在主表的长文本里，同一张单多轮维修的历史无法并列展示。将来业务变复杂，这是第一刀该拆的地方——你看，连"欠债清单"都符合第 2 章讲的规范化演进逻辑。

全书知识在此咬合

最后把八章对着这个项目逐一点卯：第 1 章判断立项，第 2 章给骨架（含忍住不过度抽象的定力），第 3 章让数据开口，第 4 章给出员工提单窗体与行政的驾驶舱，第 5 章用一行宏实现"提交后自动刷新清单"，第 6 章从旧 Excel 登记簿导入历史数据，第 7 章保它平安，本章则负责让它看清自己与世界。全部八件工具你都已经亲手摸过——下一个委托进来时，你缺的不再是知识，只是一次放手开工。