从需求判断到技术债：把工程决策说清楚

工程项目的困难，经常不是不知道怎样实现，而是不知道应该先实现什么、为谁实现，以及愿意为速度付出什么代价。如果这些问题没有答案，代码写得再快，也可能只是在更快地累积返工。

本文由《接口、系统、管理与熵》《跑步与技术债》和两篇《汇报后的小思考》合并重写，去掉生活与工作经历，将讨论集中到可以复用的工程判断。

先证明问题值得解决

一项需求至少包含用户、场景、当前困难和希望出现的变化。只写“建设数据平台”或“提升效率”，还不能帮助决定资源如何投入。

可以把讨论整理成一页：当前情况有哪些事实，问题造成什么损失，可选方案是什么，每个方案需要什么成本，最后建议先验证哪一项假设。暂时没有数据的地方应明确标注，不能用精确的数字装饰不确定的判断。

最小成本不等于最少代码。一个看起来省事的临时方案，如果需要其他团队长期手工补偿，可能只是把成本转移了。

接口设计首先要确定概念。相同的“用户”“完成”“有效”在不同团队中可能代表不同对象或状态。字段名称一致，并不保证理解一致。

约定中除了输入输出，还应包含错误处理、权限、重试和版本变化。能独立修改的部分尽量分开；必须共同变化的部分，也不必为了追求形式上的解耦而制造大量适配层。

一个简单检查是：如果实现团队更换，另一个团队能否仅凭约定理解如何调用、怎样判断失败。如果不能，缺失的信息很可能还藏在口头沟通里。

技术债可以理解为为了当前交付而推迟的一部分工程工作，它会在未来的修改、排错和运行中产生额外成本。不是所有不完美代码都值得立刻重构，也不是所有临时方案都可以无限延期。

一条可讨论的债务记录，应说明当初省略了什么、为什么省略、现在造成什么影响，以及什么时候需要处理。例如，暂时共用一张表可以加快原型验证；当权限隔离和数据生命周期开始不同，继续共用的代价就可能明显增长。

优先处理频繁阻塞交付、放大事故影响或使系统难以验证的部分。单纯追求代码外观整齐，未必是当前最有价值的工作。

排期不能假设所有工作都连续进行。跨团队依赖、评审、发布与反馈都会占用时间。与其给所有任务乘一个固定系数，不如把已知依赖、未验证假设和可用容量逐项写出来。

同一时间承担太多任务，会增加切换和等待。可以限制同时进行的工作数量，把相似任务集中处理，并为紧急事项安排明确的入口。新增需求进入时，也应明确哪项原计划推迟，而不是假设团队可以无限吸收。

旧文用“熵”描述系统随着修改变得难以理解的现象。这个比喻可以提醒人关注维护成本，但软件复杂度并不直接遵循热力学熵的定量规律。

实际管理时，应观察可验证的现象：一个小修改影响多少模块，失败是否容易定位，回滚是否可行，新成员理解一项任务要多久。它们比抽象地判断系统“有序”或“混乱”更能指导行动。

保留做决定时的背景、备选方案、取舍理由和重新评估条件。日后条件变化，就能判断是原先推理错误，还是世界已经不同。

好的复盘不止追问谁做错了，也要追问当时能看到什么、为何那个选择显得合理、怎样让下一次更容易做对。团队应持续减少必须依赖个人记忆和临场救火的部分。