我把91大事件的细节重刷了一遍：预算被砍后，团队用一种“笨办法”顶住了
那天的邮件像一盆冷水：季度预算削减了20%，一些既定的roadmap被迫暂停。项目经理的脸色和 Slack 频道里飞速增长的问号，说明大家都在计划“怎么死得更体面”。我重新翻看那段时间的日志、会议纪要、和几位同事的回忆录（口述版），发现团队顶住压力并没有什么高深策略，反而是一套“笨办法”把脆弱拉回到可控——靠的是简单、可执行、常常带点手工味的动作。
发生了什么
- 背景：核心产品进入调整期，市场不确定性放大，公司要求把非关键预算全部压缩，且在三周内交出可行方案。
- 直接影响：外包合约缩短、部分自动化计划搁置、两位中层被暂缓招聘。
- 风险：交付节奏可能被打断，用户体验和留存面临下滑，团队士气低落。
所谓“笨办法”到底是什么 这里的“笨”不是无脑，而是用低技术门槛、低成本、立刻可执行的方法，换取时间与稳定性。关键做法包括：
1) 把时间还给做事的人
- 砍掉一切非必要会议，把每周例会缩成一次15分钟的同步；把会议室里的决策挪到单条线程的文档审批里，减少来回讨论的摩擦。
- 结果：工程师把每周可用的深度工作时间增加了约20%。
2) 先做最小可行替代品（MVP），把“完美”延期
- 原计划里的两个新功能被拆成最小可交付单元，先上线核心路径，周边交互用临时状态/占位替代。
- 结果：用户体验的提升没有断档，开发量显著下降。
3) 人肉 automation：把复杂自动化拆成简单的手工模板
- 原本要花数周做的自动化测试，改成编写标准化手工操作清单、并由QA在短期内人工执行。数据采集也用半自动脚本配合人工核对。
- 结果：短期能维持质量门槛，同时为未来自动化留下可复用的脚本与模板。
4) 跨职能轮岗，建立“技能库存”
- 把设计、产品和工程做了更多交叉培训，让每个人能承担一到两项临时替代任务（例如前端开发做简单的A/B、产品同学做基础的用户研究）。
- 结果：关键岗位的单点风险降低，团队协作更流畅。
5) 优先用现成工具和开源替代定制开发
- 原计划的内部中台模块，改用市场已有服务或成熟开源组件接入，节省开发成本和维护负担。
- 结果：上线时间显著缩短，运营成本下降。
6) 把决策回归到核心指标
- 每个迭代都必须明确对某个核心指标（留存/转化/收入）的直接影响，其他“感觉很重要”的任务统一往后排。
- 结果：资源聚焦，产出更有可量化价值。
7) 增强透明沟通，减少“信息真空”造成的恐慌
- 每日简报（2–3行），说明进展与阻塞；对外与关键客户预告变更，争取理解与时间。
- 结果：管理层和客户的信任度保持，避免了额外的压力与突发指令。
为什么这些办法有效
- 快速见效：预算紧缩需要立即响应，复杂的长周期改造来不及，“笨办法”都是短期内能落地的选项。
- 可逆性强：大多数手段是临时、可回滚的，不会造成长期债务。
- 留下可复用的产物：手工流程、模板和脚本都可以作为未来自动化的蓝本，不是纯粹的权宜之计。
代价与警告 这些办法并非长期战略。长期依赖手工流程会累积技术债、降低效率并可能磨损团队士气。关键是在渡过危机后，要把“临时方案”系统化、自动化或替换成更稳定的机制。清单式的手工操作要记录、版本化，为自动化做准备。
可直接复制的六步清单（行动指南） 1) 一周内清理日程：把所有会议按影响力分类，删掉或缩短低价值的。 2) 明确优先级：列出对核心指标有直接贡献的5项任务，把其余都延后。 3) 写出手工流程模板：把自动化任务拆成可执行的手册，标注谁来做、如何验证。 4) 暂用现成工具：评估并接入成熟第三方或开源方案，先换掉耗时的定制工作。 5) 建立快速反馈回路：每天一个简短同步，周末一页周报给管理层。 6) 记录并计划复盘：在稳定后30天内把临时方法归档，列出自动化优先级和投资计划。
结语 回头看，91大事件里的那些操作没有惊天动地的创新，正因为“笨”，所以可靠、便捷、能立刻用上。团队用这些手段换来了时间、保住了基本服务，并为后续的重构提供了清晰的优先级。面对不可预期的预算收缩，所谓聪明，往往就是能把复杂问题拆成简单可行的步骤，然后坚持把每一条都做好。
