关于未来工作方向的一些思考
本文是在中心成立一周年之际，在处室内部科级工作讨论会上的发言，介绍本年度前三季度工作及对未来工作方向的思考。
正文
个人
今年主要开展两方面的工作：
第一方面工作以产品制作流程为主线，包括信息化工程和部分开发工作，目前已开展的工作包括建立产品消息库，绘图算法封装，但进展比较缓慢。 最终目标是构建一个独立的产品制作系统，将目前基于本地文件使用 NCL 的绘图任务改为基于数据 API 接口使用 Python 实现绘图。 未来还需要开发模式要素库、模式产品库、绘图工具包等工作，需要科里和室里同事共同完成。
二是仿照 ecFlow 开发工作流调度工具，也是今年花费时间最多的工作。 ecFlow 是非常成熟的开源工具，也满足我们中心的业务需求。 但我还是觉得我们应该自己开发一些工具，尤其是流程调度这类业务系统中比较关键的工具。 程序员擅长重复造轮子，互联网大厂有许多面向 KPI 编程的开源项目，我们可以借鉴过来，构建中心自己的开源项目。
科
科里和室里发展的大方向在之前多次的讨论中已基本凝练为四个方向，即
- 数据平台
- 产品平台
- 运维平台
- 中试平台
某种程度上说想法和创意并不值钱，我们可以摸着欧洲中心过河，真正有价值的是能够落地的创意。
从我自己来说，我觉得自底向上比自顶向下更容易实现，所以我认为我们需要在总体目标的指导下开发一系列小工具，使用这些小工具，将这些小工具组成一个大的平台。 在工具开发和工具组织过程中，我们可以寻找一种合适的内部合作方式。 比如可以开发工具中的某个小组件，如果不想开发源代码，可以对工具进行测试，编写文档等等工作。 甚至如果愿意，可以将这些工具做成开源项目，向外输出我们的工作成果。 这也符合中心的发展战略，让更多的力量参与到数值预报业务系统建设中。
处室
对于处室的发展战略，我还有一条建议。 我们现在的业务运行系统是纵向布局的，即按模式系统区分，甚至有时对外仅说成一个数值预报业务系统。 这样会将系统科的工作淹没在模式研发工作中，我们也做了大量的工作，但没法体现在成果中。 我建议从纵向布局改为横向整合，我们独立于各个模式将业务系统的共性步骤进行整合，形成一个一个有关联的系统。 比如资料检索、资料同化、模式积分、产品制作、产品分发、数据归档等等，这样更容易体现我们的工作。 当然我的理解不一定正确，大家感兴趣可以找时间讨论讨论。
另外，对于中心正在推广的协同研发机制，我也想谈一下自己的想法。 就我观察目前中心有三种技术开发模式：
- 别人有现成的技术，我们买过来引进到中心
- 我们自己有想法点子，通过经费找人来将想法实现
- 我们自己有技术实现，想通过合作对技术进行包装从而最终落地部署
虽然只要最终的目标都是能在中心应用，但对成果和知识产权的认定还有很多地方尚未明确。 合作需要明确我们自己在其中扮演的角色，每个人都应该可以选择更适合自己的工作方式。
我个人更倾向于第3种模式，我们必须拥有自己的核心技术，才能在合作中占据主导地位。 这种核心技术一定是中心业务研发工作中确实需要的，可以持续长远发展的。当然哪些才是核心技术其实是随着发展阶段不同而不断变化的，所以这种选择具有押宝的成分。 即使是引进的技术，也要走引进消化吸收再创新的道路，避免重现当年国内引进汽车时“市场换技术”的失败策略。 我们一定培养各项技术的核心骨干，要培养中心自己的人才梯队。 过度依赖外部开发团队会因外部团队人事变动而让这项技术变得非常脆弱。 很少有核心技术是能通过看技术文档短期掌握的，都需要核心成员的传帮带。
后记
个人发展与单位发展难免会存在一定的冲突，尤其是有上级管理部门的单位，个人发展还会存在与全局统筹规划之间的冲突。 如何寻找个人、单位、大局之间的利益平衡点，是非常值得深入思考的事情。 不能简单地“服从组织安排,听从领导指挥”而放弃自我思考，要结合自身实际情况，在符合总体规划布局框架下，寻找适合自己的工作路线。 对于超过三十年的整个职业生涯来说，五年规划占六分之一，五年时间说短当然不合适，要说长也没有显得那么长。 说不定下个或下下个五年规划会带来全新的变化，所以我认为一定要选择哪些可长远持续发展的工作方向，不要被外部条件制约自己的职业规划。
2023.03 注：去年第四季度什么事情都没有做，本来想写一些对参考链接会议的感想，现在已经想不起来了，就不再补充了。
参考
CMA 微信公众号：《第二次全国气象信息化工作会议强调 着力推动信息化发展方式转型升级》
