文化案例库
维护部门：人力资源部
适用范围：星澜科技全体团队，案例来自产品研发中心
收录季度：0000 年第三季度
维护人：陈静
状态：本季已发布
一、使用说明
案例库收集已经发生、能够讲清前因后果的协作事例，供周会、新员工培训和晋升答辩引用。每条案例保留真实姓名和结果，引用时可以隐去客户名称。本季收录 3 条，下一次增补在 1 月第二周，由各小组负责人推荐，陈静核对事实后发布。
二、支付页面当日恢复
背景。8月16日 15:40，结算页在新版本发布后出现支付按钮无响应，半小时内客服收到 26 通投诉。版本已面向全部用户。
做法。张伟在 15:52 确认是按钮事件被重复绑定，16:10 提交回滚，16:28 完成发布。郑凯同步在状态页写明影响范围。赵磊把客服话术改成“已恢复，未支付的订单可以重新提交”，避免用户重复下单。韩雪在回滚后用 12 笔真实测试单验证了微信和支付宝两条通道。
结果。故障持续 48 分钟，未产生重复扣款。当日投诉在 19:00 前全部回访完毕。事后把“支付按钮发布前必须走一笔真实小额支付”写进发布检查，9 月的两次发布都执行了这一步。
可复用的做法
- 先恢复用户路径，再保留现场日志。回滚决定由值班负责人当场作出，不等待全员评审。
- 客服话术和用户可见状态与技术动作同时更新，避免用户按过期提示重复操作。
三、冻结日后的范围取舍
背景。9月2日版本已经冻结，销售同事希望把“发票备注可编辑”放进同一周发布。该需求涉及开票接口，测试尚未开始。
做法。赵磊在当天 17:00 的范围会上列出两个选择：推迟整个版本 5 天，或把发票备注放到下一周。李明选择后者。赵磊在会后 1 小时内写信给销售负责人，写明下一版本的发布时间是 9月12日，并给出临时做法：备注先由财务在开票系统手工补录，本周预计 14 张发票。
结果。9月6日版本按原计划发布。14 张发票全部在当天完成手工备注，没有客户投诉。发票备注功能在 9月12日上线，一次性通过验收。
可复用的做法
- 冻结日之后的新增需求，当场给出“改期”或“挪走”两个可执行选项，并写明对客户的临时办法。
- 答复外部同事时带上具体张数和日期，方便对方安排客户沟通。
四、新人首周的独立任务
背景。何敏 7月8日入职前端组，上一任带教曾把新人前两周安排成只看代码。何敏在面谈里表示希望第一周就提交一次合并。
做法。张伟给何敏的第一个任务是优惠券列表的空状态文案和一张缺省图，范围限制在一个页面，接口由张伟先准备好。每天 16:30 用 15 分钟看进度。何敏在 7月11日提交合并，郑凯做了代码评审并指出两处命名问题，何敏当天改完。
结果。何敏在入职第 4 个工作日完成第一次独立提交。第 4 周起，优惠券页面由何敏单独负责，张伟改为每周两次代码评审。试用期目标里的“独立负责一个页面”在第 6 周提前完成。
可复用的做法
- 第一周的任务小到可以在四天内合并，接口和设计事先准备好，新人只处理一层问题。
- 每天固定一个短反馈点，把评审意见留在同一次修改里，不积压到周末。
五、收录标准
- 事情已经结束，有日期、参与人和可核对的结果。
- 其他团队换一个场景后仍能照着做，而不是只适用于某一次故障。
- 推荐人把事实写全。陈静在发布前与当事人核对一次，核对记录留在人力资源部。