这一周过得极其痛苦，几乎每天都加班到凌晨。除了加班本身带来的疲惫，还有如同西西弗斯巨石一般从测试、验收，乃至上线后都在持续涌现的问题 —— 反反复复地修改，却又同雨后春笋般出现。有时好不容易和 QA 达成一致，PM 却说最初的版本才是正确的，让人有一种望不到终点的绝望感。

这种情况已经不是第一次出现了，但这一次尤为严重。趁周末总结一下，希望以后能减少类似问题复发。

一、被压缩的开发周期 #

在部门对研发人力安排中，75% 的工时被分配用于开发工作，剩下的 25% 需要覆盖包括但不限于承接 OnCall、处理报警、排查问题、解决 BUG、配合测试、参加会议在内的所有事务。

原计划周一上线这个需求，剩余时间投入新任务开发。但现实情况是 —— 本周几乎全部时间都消耗在这个需求上。

• 周一、周二：和 QA 一起陪着 PM 上线前验收，反复修改问题直到深夜
• 周三：上午上线后，业务随机反馈问题导致回滚，深夜低峰期再次上线
• 周四、周五：不停处理延绵不绝的线上反馈

最终新需求开发被迫推迟两天，即便占用周末紧急赶工，提测质量也难以保证。

二、需求理解差异 #

写代码的时间都已经被严重压缩，抽出大段连续时间完整参与需求评审自然也是一种奢望。很多关键决策被延迟到编码阶段才对照 PRD 确认，必然与 PM 的原始预期出现偏差。

而 PRD 又往往写得过于概括和抽象，这就导致：

• RD 由于排期压力，选择最小成本的实现方案
• QA 依据不完整的文档设计用例
• PM 验收时发现与设想存在大量偏差

需求在三者间理解错位所带来的返工成本，往往会是前期节省时间的数倍。比如某个在 PRD 上仅有两句话描述的功能点，就让我们反复修改了三天。

三、历史债务 #

这是我接手过历史债务最严重的系统 —— 不合理的架构设计、随处可见的重复代码、极高程度的耦合模块，核心功能代码如同煮熟又风干的面条混在一起纠缠不清。

即使是简单的重构也可能会牵一发而动全身，排期紧急的情况只好选择风险最低的方案往上堆砌代码，这又进一步加剧了历史债务。

解法 #

几个原因叠加在一起，最终形成了排期紧张 - 开发仓促 - 问题暴露 - 反复修改 - 压缩排期导致更加紧张的恶性循环。

必须从某一个环节作出改变，才能跳出这个循环。比如，从仔细参与方案评审和实现细节对齐开始，短期可能会延缓一些效率，但长期是有益的。

总而言之，一味地追求短期效率，换取长期稳定性，终将付出更高的修正成本。