如何解决软件工程中的“复杂”问题

就“复杂”这个概念来讲，我认为其原因来自于多个方面，譬如我处理互联网金融平台的贷款审批系统的架构升级是一种历史债带来的复杂，缺少需求文档，缺少架构设计文档等，只能靠逆向和重构技巧；我处理OT（实时协同编辑）问题，其复杂是源于技术细节的复杂；构建confluence的替代品，完成数字化转型的核心产品的架构设计，源于业务场景洞察和架构迭代平衡之间的复杂。

在我15年的经历中，我认为最复杂的问题从来不是单纯的技术难题，而是多维度的系统性挑战。它通常混合了历史债务、技术深度、业务不确定性、团队协作和紧迫的时间窗口。比如，我处理过三种典型的复杂：清理历史债（如贷款审批系统）、攻克技术深水区（如实时协同编辑）、以及从0到1设计业务核心系统（如数字化转型产品）。而其中最具代表性的，我认为是构建Confluence替代品/数字化转型产品。

• S（情境）： 公司需要一款核心产品推动数字化转型，替代Confluence。复杂在于：1)业务模糊：没有现成的、清晰的需求文档，需要从海量的用户访谈和混乱的现有流程中定义产品核心价值；2)架构挑战：既要快速推出MVP验证市场，又必须为未来5年的扩展性打下基础；3)组织协同：需要让非技术背景的业务方理解并参与共创。

• T（任务）： 我的任务不是简单地“开发一个工具”，而是作为特性团队负责人，定义产品愿景、设计可演进的技术架构，并建立一套能让业务和技术持续协同的机制。

• A（行动）：

1. 解构复杂，定义核心：我没有一头扎进技术选型。而是先通过“海盗派方法学”等，与业务方一起梳理核心用户旅程，将模糊的“数字化协同”需求，收敛为“实时文档协同、知识图谱化、低代码业务插件”三个核心支柱。这解决了“业务目标复杂”。

2. 架构分层，应对不确定性：我设计了微前端架构（简历中提到）。这不是简单的技术炫技，而是战略决策：将系统拆分为独立可部署的“核心编辑器”、“知识图谱引擎”、“插件市场”。这样，在业务需求还不完全明确时，各个模块可以并行开发、独立试错和迭代。用架构的灵活性，化解了业务的不确定性。

3. 建立机制，而非单次解决：为了解决“业务人员参与”的复杂，我没有无止境地为他们做定制开发，而是创建了“宏插件”开发市场和机制。这是一种“赋能”思维，将一次性的复杂协作，变成了可持续、可扩展的生态。这解决了“组织协同复杂”。

4. 技术深水区的攻坚：对于“实时协同”这个技术深水区（您提到的OT算法），我没有要求团队一开始就造出完美轮子，而是先评估是自研、开源还是采购。在确认自研价值后，设立专项小组攻克，并确保其失败不影响主流程上线。这体现了对“技术复杂”的风险隔离能力。

• R（结果）： 最终，我们不仅成功交付了产品（支持500+人同时编辑，延迟<200ms），更重要的是，建立了一套从业务洞察到技术落地的可复用的“解题框架”。产品成为公司标准，沉淀的技术资产（微前端框架、插件机制）被复用于多个项目。这证明了我处理系统性复杂、并创造长期价值的能力。

所以，回顾这个问题，我认为‘最复杂的’不是某一个具体问题，而是如何在一堆互相冲突的约束条件（模糊的业务、厚重的历史、艰深的技术、有限的资源）中，找到那条通向成功的路径。

我的经验让我习惯于不急于解决表面问题，而是先定义问题的本质，然后用架构思维、机制设计和分而治之的策略，将‘不可控的复杂’转化为‘可控的模块’。这也正是我过去能在中兴、阿里、叮咚成功主导多个0到1或重大重构项目的核心方法。”