专业技术岗位晋级失败的感想

今天 (2026.06.24) 单位正式发文岗位聘任通知，也标志着持续一个月时间的专业技术岗位晋级工作尘埃落定。我从专技七级竞聘专技六级失败。

虽然在准备答辩 PPT 的时候，在答辩后得知七进六岗位有限的时候，我就预见到这样的结果，但实际到了这一步，还是会有不少遗憾，所以就有了这一篇文章。

本文记录我答辩的主要内容和我在答辩之后的一些感想。

答辩记录

时间线

• 6月2-4日，集中答辩
• 6月3日，七进六答辩
• 6月11-18日，结果公示，原地踏步，晋级失败
• 6月23日，正式发文岗位聘任通知

答辩内容

个人基本情况

2021年12月被聘任为专业技术七级岗位。

注：个人情况没有什么出彩的地方，没有气象局级别的人才称号、没参加团队、也没以第一作者发表论文，就不再介绍。

主要工作成果

以 PPT 截图形式展示主要工作成果内容，不再用文字描述。

未来计划

答辩内容存在的问题

主要工作内容部分介绍的 4 个成果存在主旨分散的严重问题，缺乏一个清晰的主线。 而且 4 个成果也有各种各样的问题：

• 成果 1 来自去年下半年开始的技术研发工作，缺乏足够的时间跨度
• 成果 2 核心工作来自专技七级之前，而且与其他几项工作缺乏足够的关联
• 成果 3 和成果 4 缺乏足够让人信服的成果落地展示，尤其成果 4 游离于核心工作任务之外

针对这些问题，我在最近一段时间也持续进行思考，也就最终形成了下面章节内容。

感想

无论我自认为我的工作怎么样，也无论 cmec-oper 室里各位同事认为我的工作怎么样，从最终结果来看，显然在 CEMC 中心层面上，我在过去近五年时间里取得的工作成果、对中心业务的贡献，都不符合专技六级岗位的要求。也就是，别说竞聘正高级职称，就连更高一级的专业技术岗位都不能胜任。所以，在我看来，过去近五年时间里，我的工作实则就是一个彻头彻尾的失败典型。

最近我一直在思考我为什么会走到今天这个地步，我自认为自己在绝大部分时间都对工作保持认真的态度，那我的工作时间都耗在哪些任务上了呢，这些任务都能否转化为在岗位晋级答辩中的工作成果呢？

存在问题

我认为我的工作在两个方面存在重大问题，导致这些工作很难在评审中得到有效利用。

第一个问题是工作涉猎太多，缺乏一条核心主线。

在业务系统建设工作方面，我参与了 GFS、MESO、TYM 等中心业务系统建设，参与了 MCV 实时系统建设，参与了中心对外产品服务系统建设，参与了省局 MESO 系统建设，也参与了支持 NMIC 实况分析团队搭建 GFS 系统的相关工作，在今年因特殊原因，也参与了区域化学天气系统 CW 1.0 的建设。

单单是列出我参与建设过的 ecFlow 系统，一页 PPT 就完全写不下。但是这些任务给我带来了什么呢？GFS 的科技成果中没有我；MESO 的科技成果中没有我；TYM 的科技成果，哦，新版 TYM 应该还没有科技成果；国省统筹团队中没有我，我倒是在数值预报国省统筹专项任务研发组中，不过这个组我自己都没想起来；MCV，哦，这个系统没建好也没正式业务化，成果也几乎不可能轮到我，就不提了。

我无法用上面的任何一项任务来说明我对 CEMC 业务系统做出的贡献，也就说明了从个人角度看上面任何一项任务都没有实质上的意义。也许这些工作都是 cemc-oper 室的职责，但职称岗位评审始终都是个人参加的，从来不是处室参加的。可以看到，工作量的多少完全没有任何用处，真正对中心有贡献的、真正体现专业技术岗位价值的并不是工作的数量，而是工作的质量。

俗话说贪多嚼不烂，同时维护太多的系统导致我对系统重构始终非常谨慎，也就是今年在自费购买 AI 编程套餐的加持下才开始进行一直以来想做的一项工作，从 MCV 实时运行系统开始开展统一运行框架领域的相关技术研发，并逐步应用到我负责维护的其他各项业务系统中。

我应该更清醒地认识到自己并没有能力也没有必要同时维护的这么多系统，必须要对过去五年甚至过去十年来积攒的工作任务进行一次彻底的剖析，分析出从这些任务中能产出什么样的可以被中心认可的工作成果，哪些任务能支撑这一工作成果的最终落地，而哪些任务属于应该果断抛弃的无效工作。

正值短临工程项目正在搭建短临 MESO 系统，鉴于当前我负责的 MESO 后处理系统已经过多年的连续更新验证其可维护性，我已经着手向部门申请后续不再参与 MESO 业务系统建设工作，推动部门考虑通过各类工程项目来解决 MESO 后处理系统的后续维护工作。 对于 GFS、TYM、产品服务等系统，如有后续工程项目支持，我也会适时申请退出系统建设维护工作。

第二个问题是工作态度不够强硬，对工作成果落地不够果断。

在软件开发方面，我也犯了和上面一样的问题，在多个领域开发了大量工具软件，却最终没有几项能应用到业务系统中。

参加工作以来，我在个人兴趣的驱使下开发了各种各样的工具软件，一些软件已经应用到业务系统中，一些软件曾经辅助过业务维护，还有更多软件尚未得到应用。

我早期开发的软件集中在运维方面。开发了对业务系统进行监控的一系列工具(nmp-scheduler)，涵盖数据采集存储、分析展示、微信报警等，已被当前的业务监控平台取代。面向 ecFlow 日志分析开发了一组工具库 (nwpc-workflow-log-tool)，因缺乏持续维护而无法有效使用。开发运行消息发送和分析工具 (nwpc-message-client)，除了消息发送工具还在使用外，其他部分也不再使用。开发了 slurm 作业查询工具 (slurm-client-go)，只有我个人使用。

随后，我开发了可以应用到业务系统中的一些工具库。开发了用于数据查找的工具库 (nwpc-data-client)，已应用到我负责维护的后处理系统中。开发天擎检索 Python 工具库 (nuwe-cmadaas-python)，只有我个人使用。开发了检索 NMC 台风数据库的工具库，应用到业务系统的台风报文检索任务中。

近期，我的开发重点转向数据分析工具库和工作流调度工具。开发了数据分析套件 cedarkit (cedarkit-plots)，期望能统一业务系统使用的数据处理和绘图 Python 脚本，但因为我个人缺乏推广的魄力，而尚未应用到业务系统中。开发工作流调度工具库 takler，也尚未应用到业务系统中。

我个人开发的绝大部分工具软件都已在 GitHub 上以 cemc-oper 组的名义开源发布，一共 60 多个项目。但从当前应用情况来看，大部分项目都是个人玩具类的垃圾项目，没有取得任何成效。

我开发的工具项目涉及系统运行、维护、数据检索、数据处理、数据可视化等众多领域，看似涉猎广泛，但这些项目严重分散了我的开发精力，每个项目都没有得到持续不断的维护和改进，导致绝大部分项目实际上根本就没法持续使用，就更别提推广了。

还有一些项目目标是对现有业务系统进行改造，但因为与其他部门或同事的已有成果有所重叠，我始终没有下定决心强行采用自己开发的方案替换业务系统现有方案，缺乏破釜沉舟的勇气，一直在瞻前顾后，导致投入大量时间开发的工具库成为一个毫无用处的摆设。比如数据分析工具套件就面临这样的情况，这一使用 Python 实现的工具核心目的之一是取代现有业务系统的 NCL 和 GrADS 绘图脚本，提供统一的绘图框架，但因为有其它部门一直在开发 Python 绘图脚本，虽然这些 Python 绘图脚本存在同样的可维护性问题，我也没有尝试在单位内部推行自己开发的工具。

我是时候该反思之前的顾虑是否还是一个必须思考的问题，我是否应该采取更强硬的工作态度，积极主动地推动自己开发成果的最终落地。

最近推进的短临 MESO 1KM 系统建设工作给了我很大的启示。既然要打破持续十年以上的系统建设维护工作定式，引入外协团队负责准业务级别的实时运行系统建设部署，那么我所要做一些对现有业务系统进行改造的工作又有什么不可行的呢。所以，我根本不用再顾虑与现有实践是否保持一致，只需要朝着自己认定的方向前行就对了。比如我在构建 MCV 实时系统运行流程时使用了全新的系统结构，后续我会将自己开发的工作流调度软件集成到 MCV 工作流项目中，将该工作流调度软件作为统一运行框架支持的一个后端，用来促进开发成果的实际落地。

解决方案

未来，我将围绕提高系统可维护性这唯一核心主线开展后续一切工作。

在业务系统建设工作方面，我将持续维护一个典型的业务系统，并专注于统一运行框架技术的研发工作。在这一个系统流程中测试研发的各项技术，无需考虑与现有运行流程的兼容问题。

在业务软件开发工作方面，我将继续开发工作流调度工具 takler，并开发那些能有效提高系统可维护性的软件工具，比如已经应用到后处理系统中的数据查找工具库 nwpc-data-client，比如正在开发的替代 slsubmit6 和 slcancel4 的超算作业提交工具 orvix。我会持续将这些工具原生集成到我维护的业务系统中。同时，我将进一步评估数据分析套件 cedarkit 的存在价值，以判断是否继续开发。

结语

最后我还是要持续思考三个问题，这也是去年半年工作总结后我就意识到但一直没想清楚的三个问题：

• 单位当前需要我扮演什么角色
• 我认为自己当前扮演了什么角色
• 我希望自己未来扮演什么角色

祝愿我们都有一个美好的未来。