油气行业软件的研发原则：重设计、按需建，重迭代，接地气

最近两年做的一些软件比较复杂，如果不做好平台架构设计，可能会导致后期的扩展和维护问题。同时，很多平台的设计，其实是寻找一种构建软件的系统性、通用性工具，所以，需要在这方面做了调研和分析。

而近期软件平台和架构设计的文章，其实是这种研究过程的思考和记录，觉得有用，就分享出来，但并没有将软件平台抬到一个特别高的位置。

1、需求第一，清楚我们的软件为行业解决什么问题？

我们的行业之所以要使用软件，是因为软件其实是一种科技含量很高的工具，通过这个工具，一个是将业务局部场景的痛点问题解决，另一个是将各个场景实现联通和协同，从而实现整体的业务价值链。

所以，在软件设计和规划中，做什么不做什么、怎么实现、怎么连接信息流，这些就非常重要。所有的功能取舍、优先级、细化程度都是从大局出发进行总体设计的。所有这一切都和软件架构关联不大。

2、对于软件设计，平台是一个衍生品

在一切业务需求和功能设计都初步确定之后，我们才可以开始思考软件平台的问题。

软件研发中，一开始就做平台设计是不对的。平台开始仅仅是一个必要的技术规范和公共的技术框架，这些都是为了使得团队统一技术体系。渐渐的就会将一些通用性的功能进行统一的实现，比如数据获取、领域模型、通信、UI编排，等等；然后在研发的过程中不断实现多样化支撑和功能统一，不断重构和优化，最后形成了一个平台架构。

所以说，软件平台的架构基本不是设计出来的，而是与软件同步成长起来的。

软件架构是一种软件层面的技术均衡机制，是在保证软件功能的基础上，对于软件研发框架进行的一种不断的调整过程，它必须和软件研发是同步的，一些过早和过晚的机制，对于软件研发都是有害的。尤其是提前设计并构建一个过于庞大和繁重的架构，是软件研发和软件成长的大忌。

3、企业级架构设计为什么要提前做？

企业级的架构设计和软件架构有些不同，前者是企业运行很长一段时期且信息化基础具备的情况下的一种企业重构和优化，一个重点是将重复冗余的部分通过分层设计进行适度的合并和统一；另一个重点是通过平台设计打通和优化企业内部的信息流和业务流。企业软件架构和普通的软件架构相比，其业务整合是架构的设计核心，其面对的是已经形成的大量信息化基础设施（各类数据库、各类需求、各类软件），同时还要面对企业未来发展战略所面对的新的信息化基础设施建设（数据库和软件），因此必须提前规划和设计。

对于软件研发的层面，如果我们已经有了一系列软件，未来还要发展一系列软件，这时候存在一个各类软件整合问题，但架构设计非常必要的依然是“适度”，建立一个在未来1~3年内适度的软件平台架构，这是很重要的。

4、如何最低成本的研发软件？

不仅油气行业，所有的软件研发都是制造一种工具解决已经存在的行业问题或者潜在的发展问题。

所以，只要发现了基本的、明确的需求，首先要做一个基本的商业判断，明确商业价值所在，以及成本投入的对比。然后，就是在最短时间内拿出一个原型方案，这个最短时间，不是按月度统计，而是一周两周，甚至是一天两天，通过UI设计和样本数据，快速形成一个可实验的原型软件，从而以此作为媒介，一方面快速实现商业对接，一方面深度把握行业需求，在不断的需求反馈和发展明确的过程中，通过软件的敏捷迭代，一步步实现对于软件的发展和对于市场的覆盖。

如果有可能，一定要适度的避开科研项目立项流程的影响。

现有的科研项目流程，实际上是对优秀软件研发过程的一种严重制约，漫长的论证、申请、批复、启动，繁琐的各种阶段检查和各种考核，这一切对于软件的竞争力提升不但没有任何作用，而且完全打乱了敏捷和迭代的进度，打乱了与市场需求或者行业需求持续的迭代。同时，科研项目其实是将研发和市场的一定程度的分离，更是人为的将研发和应用分离（这是传统设备和产品的研发模式），中断了研发与市场之间的密切的迭代反馈过程。

软件是一个积累业务知识经验，形成数字化载体的使用工具的过程。只有将这个工具不断的优化并整合到业务运行的大流程中，软件才具有生命力。软件自身的特点，决定了它一定是一个 不断“精益求精”的过程，通过无数次迭代和升级逐步实现与业务环境的深度匹配，因此，将软件与需求结合，从最小的软件原型开始，不断反复的迭代优化，这是最低成本、高效率、高质量的软件研发方式。

5、结束语

引用 友“羊羊羊”的观点，“油气行业的软件研发，目前必须以关键核心业务系统（软件）为支点，重设计、按需建，重迭代，接地气”。此总结如下，的非常到位：

我个人认为，如果从一体化实施的角度来看的话，商业可行性更加重要。

现在能源行业百年未有大变局，新能源、减碳等公司未来业务方向尚在不断探索，是否有必要拿出如此海量资源投入平台研发，应该谨慎。

数字化还是应该以主营业务或专业技术占主导地位的关键核心业务系统（软件）为支点优先开展和落地；通用性技术为主导的平台应重设计，轻部署，按需建；信息类系统应适度引导业务结构改革，重迭代、轻功能；现阶段基础平台应着重提升对专业技术系统的支撑能力和欲望，业务模块需要什么就干什么，主动参与、承接和支撑专业技术系统的研发和运维，直接参与到产品和效益的创造中来。接地气，才能真正的有机会存活下来。

如上，大赞。