几次述职之后

我保存着几份2019年至2022年的述职材料。

当时为了说明一年做过的工作，我会统计项目数量、代码规模、系统性能、故障发现率，也会准备架构图和趋势图。材料写得很满，几乎每一页都在证明自己做了事情。

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

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

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

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

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

但数字多了以后，另一个问题出现了：听的人知道工作很复杂，却不一定知道这些复杂工作最终改变了什么。

完成很多事情和产生明确结果并不是同一句话。

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

这些内容能够证明技术能力，却不能独立说明为什么值得做。只有回到最初的问题——数据为什么丢失，业务为什么难以及时发现异常，旧系统为什么无法继续支撑新的使用方式——方案的价值才变得完整。

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

这不是汇报技巧上的变化，而是工作视角的变化。如果平时只关注自己完成的技术任务，到述职时很难突然说清它与整体目标的关系。只有在项目开始和推进过程中就持续确认目标，最后才有可说明的结果。

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

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

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

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

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

做成一件事时，会想到平台、团队和机会的帮助；事情没有做好时，则首先检查自己是否不够主动、判断不够准确。这种习惯能带来行动上的改进，也可能让评价失去平衡。

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

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

几次述职以后，我逐渐意识到，真正困难的不是制作最后那份文档。

如果目标一开始就不清楚，项目过程中没有记录关键决定，完成后也没有观察结果，到了年末只能依靠项目清单和记忆拼出一份总结。这样的述职可能内容很多，却很难形成判断。

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

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

述职的形式没有那么重要。重要的是，一个人能否把做过的事情放回具体背景中，说明自己的作用，也承认结果受到哪些条件限制。