做气象业务系统，先别急着开发！

今天讨论一点技术问题，同时也是气象业务系统开发的一点思考。你有没有遇到这样的问题：投资了一大笔钱，找公司开发了一个气象业务的软件系统，从需求对接到开发测试，时间精力投入也很多，可最终交付的系统却跟我们想要的相距甚远？开发流程上也没问题，开发投入上也没问题，那问题到底出在哪了呢？

目前气象局的业务系统或平台大多采用外包（多是工程性质的项目），一些气象公司中标后会派人驻场与需求单位进行对接，这时候就是甲乙方沟通系统软件要实现的功能、达到什么效果，然后公司根据功能需求进行原型设计，出效果图，再进行需求确认，搭建开发环境，进行代码编写、测试，交付甲方进行试运行，后期再提供运维服务，是不是这样的一个流程呢？气象局的需求方一般会由项目负责人、技术对接人、业务应用人员组成一个项目小组，乙方公司一般会由一个项目经理、产品经理、技术经理以及若干开发人员组成一个项目小组来完成这个软件系统的开发和交付。乍一看似乎没出现什么问题，而且大多是这样一个执行流程，为什么这样做出来的系统仍然会出现需求和成果不匹配的现象呢？我觉得问题是出在甲乙双方对气象业务的理解上出现偏差。虽然现在的气象公司越来越重视气象专业领域，招聘对象也转向气象专业的学生，但是没有在业务环境中的实践经验；气象局的需求单位往往对IT技术缺乏了解，只关注业务中要实现的软件功能，即使在开发前已经做了充分的需求沟通，双方在需求理解上仍旧不对等，因为甲乙双方并没有使用统一的沟通“语言”（需求描述的通用语言）。另外还有一点值的关注，那就是开发前需求并没有完全表述清楚，只是大概描述，随着开发进展需求不断增加或调整，乙方往往也没有理解透彻，只能最大限度的满足甲方的需求变化，这就带来开发量大增，最终只能在有限工期内优先实现基本功能，无法完成业务系统开发的主要目标。这其实是个恶性循环，交付的业务系统质量就可想而知了。看着这样的业务系统或平台，只能感叹，当初规划的宏伟蓝图，如今仍旧是一个梦！

其实解决这个问题的关键在人！这是一个什么样的人呢？那就是懂得气象业务驱动模型设计的人。这是我自创的一个技术名词，气象业务驱动模型MODD（Meteorological operations DrivenModel）灵感来源于BMD（Business ModelDriven）和DDD（Domain-DrivenDesign），是气象业务和IT技术结合的综合体。这样的知识架构，可以将气象业务进行量化分析并采用科学方法建立业务模型，将复杂的业务系统拆解为可管控的微型业务模块，再转换为IT的技术表述语言，从而完成按业务需求开发和部署的气象业务软件系统。关于MODD的讨论，我们明天接着说！五一小长假要开始了，祝愿大家度过一个快乐的劳动节！