这周又找晋叔吹B了一番，发现晋叔在思维模型上又丰富了一圈，每次和晋叔聊天总能带来一个新的角度去思考，想到一些稀奇古怪的点来丰富原有的思维框架。

以前对于架构演进的想法总是以技术和系统能力角度去思考，如果系统存在性能问题，那我们就解决性能问题。如果系统稳定性存在问题，就在多角度解决稳定性问题，辅助以数据审计及隔离，容量规划。如果发展为平台化系统，就在业务扩展能力上进行抽象和扩展点声明，辅以框架与工具。如果研发流程上存在问题就优化合作方式，建立工具体系。

这些方式看起来是够被动也够局限的，晋叔对于其系统的演进往往来源于其对业务发展流程的理解及业界的发展趋势而得来，因为看得见多远的未来，也就看得见多少价值。

很多系统为什么做着做着就没了，根本原因在于其没有了价值，没有了价值的系统的终局往往是被融合或是被放弃。

一个系统的发展很大程度上来源于系统负责人对于其的规划，如果纯以技术角度做规划，也就两年，相信系统的稳定性或是性能也就已经达到一定的量级，之后的工作可能是为了找点活干，打散原有系统，变为微服务，微服务带来新的问题，又整合成了统一平台，周而复始。

系统的真正价值肯定不是简单来源于系统的几个9，更多的在于其商业价值。对于一个有核心业务的系统来说，两年才是一个业务从定性到爆发的初期，未来还有大把空间值得施展拳脚。如果只以技术角度做架构做系统，很大一部分时间只能围绕“降本增效”这四个字展开，做久了势必会腻。

如果要问是什么在驱动公司的发展？技术、业务、运营、人事肯定都有话说，说的也都正确，但不够全面。

维基百科对业务的解释是“企业运用科学方法和生产工艺，生产出可交付给用户使用的产品与服务，并以此为企业带来利益的行为”。

因此，只有互相沟通、了解，才能更好的分工合作。首先要了解业务的发展规律，其次要了解技术的发展规律，最后要了解彼此对对方的要求。

业务发展规律分为 4 个阶段：

起步阶段：要快速验证商业逻辑、商业 idea；

发展阶段：要快速开拓市场，需要资本的注入和大量推广；

成熟阶段：精细化运营，提高效率节约成本，还有风险控制；

衰退阶段：需要转型，需要创新，需要快速的退出。

技术的特征与发展规律也分为 4 点，即提前布局技术、及时反馈修正、系统看待问题和批量化操作，以防万一。

业务方和技术方需要彼此了解要求。而业务规律对技术的要求可以总结为四个词：销量、服务、管控、沉淀。也就是先以销量功能为主，然后做服务功能，接下来是管控功能，最后沉淀为基础业务服务。

当然，业务方与技术方彼此了解后，还远远不足以驱动公司发展，二者需要匹配与融合。

这个匹配是阶段性的匹配，以时间为轴。先有商业逻辑，然后有产品逻辑，最后才有程序逻辑。如果没有商业逻辑，或没有表达好，研发自然不知道如何下手。因此，要先确定一个阶段性业务目标，然后提前布局技术研发，最后快速反馈和改进产品。

融合也是阶段内的融合，先确定大方向，然后在阶段内进行细节的融合。技术与业务该如何去融合呢？方法很多，以下是已经实践过的四个方法。

互训，各部门互训，互相了解各部门工作流程和输入输出；

轮岗，去别的部门轮岗，执岗；

活动，鼓励业务方与技术人员多做一些非正式的沟通；

思想突破和自我要求，这是最重要的一点，是思考的提升和自律。

对于上述第 4 个方法中的思想突破，可以借助 5 个问题来引发不同的思想。

业务人员要懂技术吗？

研发与技术的区别是什么？

研发是职能部门吗？

业务和技术的矛盾能否彻底解决？

各部门多配合就好吗？

除了思想突破外，业务和技术都应该有一些自我要求。

业务方需要了解研发的基本流程，梳理并表达清楚自己的业务逻辑，懂得提需求和反馈，懂得如何借助技术，来提高市场的推广效果和运营管理。

而技术方需要了解业务，懂得业务的重要性，以服务为导向，强调技术价值的输出。此外，产品经理在研发部门要说业务的好，业务的难，在业务部门要说研发的好，研发苦。

综上，没有配套的市场推广和运营计划，产品基本没戏。没有技术支持的市场推广和运营管理，那是劳动力，不是生产力。所以，只有技术和业务的匹配与融合，公司才有大的发展，科技才能转化为生产力。

到底是什么在驱动公司的发展？

不同阶段不同做法，比如早期产品，中期市场，后期运营。

是投资人的要求，是竞争对手，是行业，是社会需求。