花500万买AI工具,不如先花5分钟看看你的组织架构图(漫画拆解版)

第19天

"不确定的时代，确定地成长。"

——ION lab 职场迭代实验室

一、一个被《哈佛商业评论》拒稿的定律，如何统治了软件工程57年

1967年，计算机科学家Melvin Conway在提交论文时，意外发现了一个规律："设计系统的组织，其产生的设计等同于组织之内的沟通结构。" 这就是后来被称为"康威定律"（Conway's Law）的原始表述。

颇具戏剧性的是，Conway最初将这一发现投稿至《哈佛商业评论》，却因"缺乏管理学价值"被拒稿。次年1968年，他将其改写为技术论文发表于《Datamation》杂志，标题为《How Do Committees Invent?》。这篇看似平淡的技术文章，却成为软件工程领域被引用最多的论文之一——其影响力远超同期发表的大部分研究，甚至被称为"软件架构的万有引力定律"。

康威定律的核心只有一句话，却有三个递进层次：

第一定律（组织决定架构）：软件系统的模块结构，必然复制组织的沟通结构

第二定律（沟通成本决定系统复杂度）：团队间沟通渠道按 n(n-1)/2 增长，系统复杂度随之指数上升

第三定律（组织边界=系统边界）：跨组织的系统接口，必然成为系统中最脆弱、最难维护的部分

《软件工程3.0》一书将这一1968年的定律置于大模型时代重新审视，指出一个被忽视的真相：LLM被寄予厚望，但软件复杂度问题能否被彻底解决，仍然值得深入探讨。因为复杂度不会消失，只会从代码迁移到架构，再迁移到组织。

---

二、医疗行业的三种"组织病"：康威定律正在惩罚谁？

🚑 病状一："硬件-软件-临床"三权分立，系统被迫"三国化"

某国产高端影像设备企业案例：CT/MRI硬件部、影像软件部、临床应用部分属三位VP。一款AI辅助诊断功能从立项到上市用了18个月：

硬件部坚持"我们的数据格式不能改"
软件部说"算法团队给的SDK不稳定"
临床部抱怨"你们做的界面医生根本不想用"

结果：系统架构被迫复制这种"三权分立"——硬件接口层、软件中间层、临床应用层各搞各的协议，最终形成一个"紧耦合的分布式单体"。医生点击一个按钮，后台要跨三个部门的三个系统，延迟高达8秒。

康威定律诊断：组织架构图就是系统架构图。三个VP的汇报线，直接变成了三个系统的"边界墙"。

🚑 病状二："合规部后置"——质量合规与研发割裂的代价

某IVD（体外诊断）企业案例：软件研发团队40人，质量合规（QA/RA）团队5人且向不同VP汇报。软件按敏捷每两周发版，合规团队按瀑布每三个月审一次。

结果：每次合规审查发现200+问题，研发团队被迫"救火式重构"。系统架构中，合规检查模块被硬塞进各个子系统，而非内建设计。最终CE认证延期11个月，错失欧洲市场窗口期。

康威定律诊断：合规团队与研发团队"跨组织"，其接口（审查流程）必然成为系统最脆弱的部分。当组织架构把QA/RA当作"守门员"而非"队友"，系统架构就会把合规当作"外挂补丁"而非"内建基因"。

🚑 病状三：大模型时代的"AI孤岛"——算法团队与业务团队的"组织墙"

某医疗AI企业案例：算法团队（博士扎堆）与产品交付团队（工程背景）分属CTO和COO。算法团队训练出肺结节检测模型（AUC 0.96），但：

产品团队说"模型太大，嵌入式设备跑不动"
算法团队说"那是你们工程化能力不行"
医院客户说"你们这界面和我们PACS系统对接不了"

结果：模型在实验室惊艳，在临床"水土不服"。组织架构的"算法-工程"边界，直接变成了系统架构的"云端-边缘"裂缝。

康威定律诊断：这与Apple Siri的困境如出一辙——AI团队与产品团队割裂，AI能力无法内化为产品体验。大模型时代，"AI部门"本身就是逆康威操作的反面教材。

---

三、三条药方：医疗行业如何"逆康威操作"

💊 药方一：按"业务域"重组团队，而非"职能墙"

某跨国影像设备企业的启示：其平台团队按"心血管工作流""肿瘤工作流""神经工作流"划分，每个"域团队"包含软件、硬件、临床、合规全角色，对端到端交付负责。

国内实践建议：

影像AI企业：设"胸部影像AI团队""病理AI团队"，而非"算法部""软件部"
IVD企业：设"化学发光平台团队""分子诊断团队"，内含QA/RA成员
每个团队控制在7±2人（邓巴数字），超过则按子域拆分

核心原则：组织架构图就是软件架构图的"初稿"。想拆微服务？先拆团队。

💊 药方二：把合规"内建"进团队，而非"外挂"

某国产医疗器械龙头的实践：其软件团队实行"合规前置"——每个Scrum团队配备1名QA/RA工程师（兼职），参与每日站会和Sprint评审。合规不再是"三个月审一次"，而是"每两周对齐一次"。

效果：CE/FDA认证周期缩短40%，系统架构中合规检查内建于各模块，而非后期补丁。

康威定律解读：当QA/RA与研发"同组织"，其接口（审查流程）就从"脆弱外部依赖"变成"稳定内部契约"。

💊 药方三：AI时代，消灭"AI部门"

某跨国医疗科技企业的转型：其解散独立"AI研究院"，算法工程师嵌入各产品线团队。肺结节AI团队直接向"胸部影像产品线"负责人汇报，而非CTO。

效果：模型从训练到临床部署周期从12个月缩短至3个月。

国内医疗AI企业建议：

算法工程师进病房：每周跟台2天，理解临床真实工作流
建立"人机协作"决策链：明确AI辅助诊断的"建议权"与医生的"否决权"边界
培养"医疗AI全栈工程师"：懂临床、会调参、能工程化——这才是大模型时代的"抗康威定律"人才

---

四、结语：组织设计是医疗软件最高杠杆的"合规决策"

《软件工程3.0》说："软件复杂度是软件工程的核心问题之一，如果不存在复杂度问题，软件工程似乎也将失去存在的意义。"

康威定律：复杂度只会转移，不会消失。

医疗行业的特殊性在于——组织架构不仅影响软件质量，更直接影响合规风险。当FDA/CE/NMPA审查你的设计历史文件（DHF）时，他们实际上在审查你的"组织沟通痕迹"。那些跨部门的邮件往来、会议纪要、变更审批，都是康威定律的"物证"。

下次开技术评审会前，先把组织架构图投影到屏幕上。那不是你团队的汇报关系，而是你未来产品的"基因图谱"——也是审查员将要解读的"设计意图证据"。

---

参考：《软件工程3.0：大模型驱动的研发新范式》朱少民、王干祥著

---

📎 关于 ION lab

ION 职场迭代实验室，由 Bati 主理。聚焦职场认知方法论的个人研究与实践分享，致力于在不确定的时代，帮助职场人建立确定的成长系统。

⚠️ 声明：本公众号所有内容均为个人观点，基于公开信息及个人经历独立创作和方法论总结，不代表任何现任或前任雇主立场，不构成任何形式的职业、投资或商业建议。

📮 交流：欢迎朋友私信交流，但请勿询问涉及保密义务的内容。