如果是前几年的我来回答“工程师最重要的价值是什么”，大概率会偏向实现能力。
代码写得快不快，架构搭得好不好，问题解得漂不漂亮，这些当然都很重要。直到后来接触越来越多复杂业务项目，我才逐渐发现，真实项目里很多最有价值的工程工作，其实并不总发生在代码最密集的地方。
它更多发生在更早、更抽象、也更容易被忽略的环节里。
工程价值不只是把功能做完
复杂业务项目最明显的一个特点，就是需求本身往往不是完整的。
业务方知道目标，但不一定知道系统边界；知道痛点，但不一定知道该怎么拆流程；知道想要什么结果，但不一定能准确表达过程约束。
这时候工程师如果只是等一个完整需求再开始实现，很多事情其实已经晚了。更现实的情况是，工程师本身就要参与结构梳理，要参与边界定义，要参与判断到底什么该做、什么先不做、什么阶段做。
这部分工作不一定最显眼，但非常关键。因为它决定了后面写的代码是不是在正确的问题上发力。
很多难点，根本不是代码难
我后来越来越有一个感受：复杂业务项目里，很多真正难的点都不是“技术实现本身太难”，而是下面这些东西很难：
- 需求表达不完整
- 多角色目标不一致
- 流程之间边界模糊
- 异常路径没人定义
- 数据口径没统一
- 页面承担职责过多
这些问题如果没理顺，工程师再努力实现，也很容易做出一个“功能都在，但整体不稳”的系统。
所以我现在会把“把问题讲清楚”看得和“把代码写出来”一样重要。因为后者很多时候是在执行，而前者才是在决定执行方向。
为什么我越来越重视取舍
复杂项目很少存在“全都要而且都能稳”的情况。时间有限、资源有限、平台有限、业务又想快，这意味着工程师一定会不断面临取舍。
以前我会更在意怎么把东西做得完整，现在我会更在意怎么把东西做得成立。
这两个词差别很大。“完整”容易走向堆功能；“成立”要求你判断什么是当前阶段真正不能丢的核心。
比如有些时候，实时体验不是最重要的，留痕和结果可信才是。有些时候，页面视觉不是最重要的，状态关系清楚才是。有些时候，不是先把模块做多，而是先把闭环做稳。
这种取舍判断，我现在会把它当成工程价值的一部分，而不只是项目管理的事情。
工程师其实在参与系统定义
这是我后来特别有感的一点。
很多人会默认“系统定义”是产品或业务的事，工程师只是负责落地。但在复杂项目里，这条线其实没那么清楚。
因为很多系统是不是成立，取决于技术边界怎么解释，状态怎么抽象，流程怎么组织，异常怎么兜底。这些都离不开工程视角。
也就是说，工程师并不只是参与实现，也在参与系统本身的定义。
结语
做复杂业务项目之后，我对工程价值的理解确实变了。
以前我更关注“能不能实现”，现在我更在意“是不是在解决真正的问题”；以前我更看重“写得出来”，现在我更看重“结构是不是成立”；以前我把工程工作理解成执行，现在我更愿意把它理解成判断、组织、翻译和落地。
代码依然重要，但对我来说，工程价值已经不只存在于代码里了。它更多存在于那些让一个复杂系统真正站得住的地方。