几次述职之后

我保存着几份 2019 年至 2022 年的述职材料，当时会统计项目数量、代码规模、系统性能和故障发现率，也准备了不少架构图和趋势图，想尽量把一年做过的工作说明白。

几年以后再看，数字和项目名称已经不再重要。更值得保留的，是我在几次述职之间如何改变了对工作价值的理解。

最初想证明自己做得足够多

早期写述职，我最关心的是完整。负责过的项目不能漏，解决过的问题要全部写上，技术难点最好讲得足够深入。

这种思路并不奇怪。研发的很多工作不容易被直接看见。一个系统平稳运行，一次迁移没有影响业务，一项风险在上线前被处理，都不像新增功能那样有清楚的展示界面。如果自己不说，别人未必知道其中投入了什么。

所以我会列出处理过多少数据、优化了多少性能、接入了多少系统。数字能够说明规模，也让我觉得评价更加客观。

但数字多了，听的人可能只知道工作很复杂，却不知道做完以后有什么变化。

有一次准备晋升答辩，我花了很大篇幅说明监控系统的架构升级。存储怎样迁移，处理能力如何扩展，报警引擎如何改造，每一部分都有具体技术难点。

这些内容能说明技术难度，却没说清为什么要做。数据为什么丢失，业务为什么难以及时发现异常，旧系统哪里支撑不了新的使用方式，得把这些背景交代清楚，别人才能理解这次改造。

后来再写项目，我会尽量按照问题、选择和结果组织内容：当时遇到什么限制，有哪些可选方案，为什么承担某种成本，完成以后哪些指标或工作方式发生了变化。

如果平时只关注自己完成的技术任务，到述职时很难突然说清它与整体目标的关系。项目开始和推进时就得持续确认目标，最后才有结果可以说明，单改汇报的写法不够。

述职天然以个人为主语，但大部分项目都是多人协作的结果。

早期我容易把项目成果直接放进个人产出。后来负责的事情变多，才更清楚一个项目如期上线，可能同时依赖产品梳理需求、测试覆盖边界、上下游配合改造和团队成员完成各自部分。

个人价值并没有因此消失。它可能体现在提出关键方案、推动分歧解决、提前发现风险，或者在复杂情况下保持项目继续向前。但这些贡献需要放回协作关系中说明，不能把整个结果都归于自己。

同样，项目出了问题，也不能只用“协作方不给力”解释。负责人不一定要承担所有错误，却需要说明自己掌握了哪些信息、采取了什么行动，以及下一次可以改变什么。

我过去很容易详细说明不足，却较少直接确认自己的贡献。

做成一件事时，我会想到平台、团队和机会的帮助，没做好时则先检查自己是否不够主动、判断不够准确。这样做能找到改进的地方，也容易低估自己的贡献。

述职要求一个人暂时站到自己的工作之外，既不夸大，也不回避。哪些结果确实由自己的判断推动，哪些来自团队共同完成，哪些只是赶上了合适的条件，都应该分别说明。

准确评价自己的工作，不等于抢功。一个人如果长期说不清自己的作用，也很难判断下一阶段应该继续发挥什么、补足什么。

几次述职以后，我发现很多问题在写文档之前就已经存在了。如果目标一开始就不清楚，过程中没记下关键决定，完成后也没观察结果，到了年末只能靠项目清单和记忆拼一份总结。

更有效的做法，是在日常工作中保留少量记录：问题是什么，为什么这样做，结果如何，还有哪些没有解决。它既服务于汇报，也帮助自己避免重复犯错。

现在回看旧材料，我仍然能看到一些当时特有的表达：急于证明技术深度，习惯用工作量说明价值，也会把未来计划列得很满。它们并不成熟，却真实记录了那个阶段如何理解工作。