对话吴穹：软件开发的终局，是我们将迎来自己的“黑灯工厂”

三十年的软件工程江湖，像一条奔流不息的河。

有人淘金，有人摆渡，有人筑坝，而吴穹，是那个试图画出河流走向图的人。

1995 年，师从杨芙清院士和梅宏院士，吴穹正在北大参与“青鸟工程”，一个近乎理想主义的尝试——在中国建立一条真正的“软件工业生产线”。做学术研究时，他内心总有一个强烈的声音在催促：如何将这些抽象的理论“落地”？毕业前夕，他找到了当时在全球软件工程领域声名赫掣的 Rational 公司，毛遂自荐，最终竟促成了这家巨头在中国的第一个办事处。就这样，他几乎是以一己之力，将 Rational 及其方法论 RUP（Rational Unified Process）这本“圣经”引入了中国。

那是一个“引渡者”的黄金时代。UML 统一建模语言、RUP，这些来自海外的严谨范式，如同精确的图纸，被递到了一群最渴望规范与秩序的中国工程师手中。吴穹和他的同仁们，就像当年的普罗米修斯，将理性的火种带到东方。他亲手将 RUP 翻译成中文，免费提供给整个社区，无数 CTO 和 CIO 都曾感念，是 RUP 为他们野蛮生长的研发体系，注入了第一支标准化的疫苗。

故事本可以这样继续——一位成功的布道者，不断引进、翻译、推广着世界上最先进的理念。然而，河流的走向，远比地图复杂。

在美国 IBM 担任全球产品经理的三年，是他人生中的一次关键“离岸”。他负责的是一款名叫 ClearCase 的配置管理工具——用他后来的话说，那是“Git 的爷爷”。他深入到一个全球顶尖产品的肌理之中，从产品经理这个“Mini-CEO”的视角，体验着一套成熟的、源自西方的研发文化。他看到的不仅是技术和流程，更是土壤之下的文化根系。

2007 年，当他带着敏捷开发的浪潮再度回国，开始帮助华为、平安科技、招商银行等巨头导入新的管理实践时，他清晰地听到了“水土不服”的断裂声。

矛盾，如同水下的暗礁，开始浮现。

西方的敏捷，诞生于鼓励试错、崇尚自组织的土壤，而中国的企业文化，更像一部严整的交响乐，强调“偏管控型”的指挥体系，追求令行禁止的确定性。

“很多敏捷教练什么都不管，就强调“敏捷”是对的。” 吴穹回忆。但这种“拿来主义”的失效，让他猛然惊醒。他意识到，自己不能再做一个单纯的“引渡者”。照搬最佳实践，本质上是一种思想上的懒惰。真正的价值，在于回到第一性原理——“敏捷”究竟要解决什么问题？是沟通效率，是快速反馈，是价值流动。然后，再用这些原理，去重新设计一套真正适合中国这片土壤的“农具”。

这背后，是他坚守了近三十年的核心战场：软件，是充满不确定性的艺术；而工程，是冷冰冰的确定性。他的使命，就是在这两者之间，为这门艺术建立工程化的秩序，让高质量的交付变得可预测、可执行。

“这个能力，一直是我们国家很缺乏的”，他认为自己的价值，就是把这件事帮助更多的企业去落地。这是他从“理念的引进者”蜕变为“本土范式的开创者”的转折点。他不再满足于给出地图，而是要亲自勘探、绘制一幅属于中国人自己的软件工程地图。这幅地图，就是他后来参与创立的 Adapt 方法论。到了 2016 年，当他意识到仅靠顾问一人之力难以撬动上千人的组织时，他需要一个杠杆。于是，软件工程工具“知微”应运而生，将他的思想注入代码。

然而，就在这幅地图逐渐清晰之时，一场更大的风暴席卷而来。

AI，以一种近乎蛮横的姿态，冲进了软件工厂。比尔·盖茨那句“我们总是高估未来两年的变化，低估未来十年的变革”的箴言，正在被狂热的现实所验证。CEO 们在云端宣告要“All in”，要彻底颠覆；而一线的开发者，却在“AI 幻觉”和“上下文缺失”的泥潭中挣扎。

一个新的、更深刻的矛盾摆在了所有人面前。吴穹敏锐地捕捉到了其中的荒诞之处：AI 工具的宣传，出现了两个截然相反的化身。“如果这个东西对员工是摸魚神器，在老板那儿它就不会是提效神器。” 吴穹一语道破。生产力的变革，从未如此尖锐地触及生产关系的根基。工具就在那里，但员工为什么要用它为公司创造价值，而不是提前下班？

这不再是一个技术问题，而是一个直抵人心的管理问题、一个组织变革的系统工程。

当 AI 可以像员工一样“领取任务”，甚至可以被“管理”，当一个程序员不再是亲自耕种的农民，而是变成了拥有一个 AI 军团的“地主”，我们又该如何衡量他的价值？当软件的生产成本趋近于零，这张图景的终点，或许就是一座将灯光熄灭、人类仅负责少量关键决策的生产体系，让 AI 自主编码的“黑灯工厂”。

这条奔流了三十年的软件工程之河，正迎来一次史无前例的河道变迁，甚至可能是一场冲毁一切堤坝的洪水。在本场对话中，我们将与吴穹一同探讨：软件工程的旧范式将如何被颠覆？而我们，又该如何自处？

“必须有一套中国人自己的、本土的、接地气的方法论”

王启隆：吴博的职业生涯经历了从理念的引进者到一个本土范式的开创者的变化过程。有没有什么契机让您觉得单纯从海外引进可能不够了？有没有什么具体的项目或事件，让您顿悟到必须有一套中国人自己的、本土的、接地气的方法论，也就是本土范式？

吴穹：出国之前我服务国内企业，到美国这三年，算是深度参与到一个产品的整个研发过程中。因为那三年我是作为 ClearCase 的产品经理，我跟那边的客户、研发团队、销售团队等各种各样的团队打交道。产品经理其实是一个 Mini-CEO，相当于一个产品的全面负责人，所以我会跟很多人去打交道。

等到我 07 年回国的时候，一开始我们是把国外的像 Scrum这样的方法论拿回来落地。前几年我们也是抱着落地的想法，但过了一段时间就发现会水土不服。因为我这三段经历有两段在国内，一段在国外，所以我比较明确地看到两种文化、两种思路的不同。我们国内整体上还是一个偏管控型的文化，这没有对错，可能是文化不同。

比如你按这样的方式去管理华为，可能会成功；但用这个方式去管理 IBM 可能会不成功。用 IBM 的方式去管理华为，虽然华为学了一些 IBM 的东西，但也不代表它全盘照抄。实际上华为在落地 IPD 的时候，还是做了很多自己的管理变革和创新。

如果你去国外，没有那么多人会说我在用 IPD 管理。所以我觉得华为也经历了一个本土化的过程。我们的管理文化、实践、组织架构、管理方式，都跟西方公司有很大差别。当你把一个敏捷方法论落进来的时候，我们以前很多时候就是不管，就说这是对的。

王启隆：你自己去想解决方案。

吴穹：对。但是我们当时觉得这样不行，要把敏捷的核心思想和国内的本土实践相结合，给出一个很具体的指导，这样在国内才能更好地落地。大概是这么一个想法。

王启隆：我觉得是从单纯的去复制成功到去研究他的思路的一个过程。

吴穹：对，相对来讲是。就是所谓的马斯克现在比较推崇的第一性原理。敏捷也是有第一性原理的，但它的第一性原理可能被包装成了一个适合国外的实践，当别人在国外做这个敏捷实践时，就可以产生效果，因为它应用到了第一性原理。现在你把这个实践完全搬回国内，就会发现它不适用，因为它跟周围方方面面的东西不适配。所以你要回到敏捷的第一性原理，重新适配国内的情况，这样的一套实践在国内就更容易落地。

所以我们今年也出了一本新书叫《敏稳兼顾：数字化研发管理实战》，专门讲规模化敏捷怎么样在国内落地。我们有一个方法论框架叫 Adapt，也就是把我们这些年的思考做了一个总结。

“不会有通用 Agent，最终还是会分化成专用 Agent”

王启隆：时间延伸到现在，我们看到了 AI 带来的巨大变革。很多企业高管也对这个新变革感到非常兴奋。但一线的研发团队，包括正在看视频或读文章的读者，会觉得在实际应用中，AI 常常让人感觉到幻觉很多，令人困惑和挣扎。您作为常年连接国内外高层战略和一线实践的顾问，认为当前企业管理者在推动 AI 赋能研发这件事上，最容易陷入的认知误区是什么？

吴穹：应该是比尔·盖茨说的，我们总是高估未来两年的变化，低估未来十年的变革。所以我觉得现在我们就处于一个狂热期，目前有点过分高估 AI 在这两年能取得的变化。

我觉得现在最常见的误区就是太着急，过分乐观。All in 是没错的，方向上 AI 肯定会彻底改变软件工程的生产方式，五年、十年来看，这肯定是确定的。

但短期之内，它的困难在哪里？我们看到现在 AI 比较强的是什么？如果你做一件任务，大模型压缩的知识已经足够了。你让它在一个熟悉的领域，用它已经掌握的知识去做事，现在它的能力已经相对非常好了。

但软件开发不是这样。你让 AI 在广场上做任何事情，用的是公域知识。但实际上我们大多数的软件开发项目都有很多私域知识。它是一个独特的金融软件，或者就算它是一个电商系统，但由于前面的人已经写了五年、十年，虽然它在领域上是个电商，但你的实现方式其实也是私域知识。

所以，这个时候你让 AI 纯粹地去处理，你只是给它一堆代码。就算现在上下文越来越长，它可以把所有代码库、所有文档都读进去。但很多时候，我们之前做这些事情的决策过程都在大脑里，没有留存文档，或者留存的文档和代码对不上。私域知识的质量是不好的，这时候你让 AI 去处理这些信息，它可能就会遇到短板。

王启隆：是的，就是常说的上下文工程，上下文不足。给它的私域数据不足。有时候你只是给它一个提示词，但它需要的可能是一个客户的聊天记录，或者你整个工程的记录，才能把事情做好。

吴穹：对，所以你会发现几件事情。我自己从今年开始也在试用 Cursor，去一线体感，我要看看这个事情现在进展到什么程度。现在大家会发现，当然最近是日新月异，每天都在变，但至少到现在为止，代码补全是一个非常高效的场景。为什么呢？因为在代码补全的上下文下，你已经把要改什么、在哪改等上下文告诉它了。

“我要在这儿改”，这是一个非常重要的上下文。你敲几行字之后，你的意图也告诉了它。所以，它在这个非常精确的点上改东西的时候，效率就会高很多。所以大家会发现代码补全很高效。但如果你不是用代码补全，而是说“我想干一件事”，那你就得给它很多上下文。

对于一个老系统，很多时候问题不是技术债，而是缺乏历史信息或历史上下文。这时候你有两个选择，要不你就手写了，要不你就把历史信息补全，把那个债补上。但你补这个债的时候，会面临不确定性：补全了就真的能快吗？你不知道。或者说要补到什么程度？这个要试验。所以很多时候大家就会说，那算了，我接着手写吧。

当 AI 应用到我们私域时，不确定性会多很多。所以现在我们看到大多数团队给我们的数据，比如 10%、16%、20%，都在体感误差范围内。你说我快了，我一定会说我比以前快了，但你说有多大效果吗？不好说，大家觉得可能会有误差。

所以我觉得长期来讲，我相信 AI 一定会改变整个软件工程的工艺、工具、组织，这些全都会变。但短期之内大家不能太着急。我看到今年有一些组织，在一些 AI 编码的突破之后，从 CEO 开始就觉得要颠覆。那 CIO、CTO 只好说好，要颠覆。底下的同学就只好说，你们觉得要颠覆，那我就配合你们颠覆。

当然，这是每次技术浪潮都会有的。比如我们回头看面向对象、CMMI、Java，每次都是这样。这是一个我们叫技术成熟度曲线（Gartner Hype Cycle）的过程，好像也是一个不可避免的过程。但我们现在只能说，尽量让大家冷静一点。要积极拥抱，但在这个过程中，要意识到上下文的缺失是 AI 发挥作用的一个很重要的阻碍。所以我们现在看到 AI 表现比较好的都是纯绿地项目，比如新建一个网站，新建一个原型，都没有问题。

图源：2025 年人工智能技术成熟度曲线 | Gartner官网

王启隆：而对于已有旧项目的维护和修改……

吴穹：难度大很多。另外，现在大家都在谈 Agent。你回头想，任何一个工程生产线，都没有人卖通用的工程生产线。真正最后软件工程实现了，或者说更高度自动化了，它一定会有很多差异化的生产线。没有人说这是一个万用生产线，做任何机器——造车、造火车、造导弹——都可以用，因为这不 make sense，肯定是个浪费。

我明明要造车，为什么要用一个万用生产线？你一定会把它调制成一个造车的生产线，像特斯拉一样。里面有一定灵活度，可以造 A 类车，可以造 B 类车，但我不会用它来生产飞机，因为没有道理，不经济。

所以最后，我觉得 Agent 这个技术一定会越来越分化、越来越专业化。例如，未来会出现专攻特定行业的“金融 Agent”，或专攻特定任务的“测试 Agent”、“重构 Agent”。更进一步，我们甚至需要为这些 Agent 建立一套管理机制，比如如何注册、如何考核 KPI、如何调解它们之间的任务冲突。

不仅仅是 Agent 会专业化，我们使用的开发语言也会进一步专业化。从模式上讲，Vibe Coding 和 Spec Coding 都是一个抽象层次提升的过程。就像原来我们用汇编，后来用高级语言。下一步骤一定是自然语言编程，我可以用一个相对更灵活的自然语言，不需要关心那么多技术细节。

就像今天你写 C++，不会去看汇编代码。可能万分之一的场景，你可能会去看一下汇编代码，解决一个非常难的问题。但大多数时候你会忘记汇编那一层。所以可能五年、十年之后，也不排除三年之后，我们会说我用自然语言就可以了，不需要看生成的 JavaScript、Java，因为那一层JS、Java就成了新的汇编，我们不需要关心了。

实际上我们是面临一次抽象层次的提升，抽象到自然语言。但到这个级别你会发现，还是会出现新的东西，我们叫 DSL（领域特定语言）。因为没有道理一直用一个通用的自然语言。我一定会到某一个点发现，既然都在做 ERP，那为什么不发明一个专用于 ERP 的自然语言描述框架？所以从道理上讲，它一定会进入一个熵减的模式，我不需要用一个纯自然语言。

我会用一个更特定于这个领域的描述方式，配合特定领域的 Agent，来更精确、更准确地干好这件事。所以这一定会走向一个分化的过程：我们的描述会分化，我们的 Agent 也会分化，逐渐形成更专业化的生产线。我觉得这是大概率会发生的事情，只是这个过程大家要有耐心，不是一蹴而就的。在这个过程中如果过分着急，就会导致动作变形，会付出很多成本和时间。所以我觉得这是我们看到的误区，大家有点过分着急。

王启隆：我觉得吴博从逻辑上解释了为什么不会有通用 Agent，最终在实际生产中还是会分化成不同的专用 Agent。甚至于我们最基本的聊天机器人（Chatbot），它可能也不是纯自然语言，而是专门用于对话的、日常口语化的语言。这个观点很精彩。

“要把 Agent 当成员工去管理”

王启隆：您刚刚有提到您创立的爱捷软件（Agilean），在 AI 时代之前，它是如何发挥在软件工程上的作用的？AI 带来的变革之后，它又是如何调整自身定位的？面对现在国内那么多客户都想要智能化、AI 化转型，您和您的团队为他们解决的核心问题，和三五年前相比，发生了哪些根本变化？

吴穹：我们这一套 Adapt 的方法论，包括我们做的事情，可以总结为“人、事、流、数”四件事情。

“人”其实延伸到组织，就是用什么样的组织形态最合理。我们一直都说，生产力会推动生产关系的变革，但生产关系决定了生产力能否有效发挥。所以我们一直在做的事情就是理顺生产关系。原来很多是科层制的、职能化的组织。我们现在在帮助很多组织做敏捷转型，建立这些面向交付的敏捷团队。

我们最近举的一个例子，跟国家的军事改革很像，叫“兵种主建，战区主战”。因为现在大多数知识工作者都需要跨职能协作，单一职能是做不了事的。但我们很多管理会偏向于按职能管理，职能线管理是一个常见的管理结构。我们现在做的大多数事，就是在职能线上叠加交付型组织，也就是所谓的“战区”，用这样一套组织结构，让它交付得更快、更好。这块是我们这几年在做的事情，就是建立组织。

建立组织之后，第二步就是“事”。要让组织干活，就要明确它干什么。“事”可以认为是一个指令体系。最上层的组织收到客户的一个要求，然后我要把它拆解成几个指令发给不同的组织，有人要做交付，有人要做能力建设。

我希望有一个指令拆解的过程。这个指令拆解的过程就是我们说的“事”，我们把它叫任务体系。相当于我的组织体系建好后，要用任务体系把它落实。

有了任务体系之后，再下面就是“流”，有点像流程，或者我们现在更多地叫价值流。这件事分多少个状态？每个状态由谁负责？这就又回到了把事和人连起来，让事去找人。这个事到了这个阶段应该是谁负责，把这个工艺落实下来。有了“人、事、流”之后，我们就会产生很多“数”——有关人的数、有关事的数、有关流的数，我们可以更好地管理整个组织。这就是我们这么多年在干的事，即如何从这几个角度优化，让一个组织能够更高效地运作。

AI 来了之后，我最近看到一个截图，好像是阿里的 CTO 或 CIO 说的，他说要把 Agent 当人去管理。这也是我们一直以来的核心观点：我们未来认为组织会是所谓的 1+N 的组织，即由“1 位人类小队长”带领“N 个 AI 特工”协同工作。

因为马上大家要解决一个问题：今年大概是大家对 AI 最狂热的一年，明年怀疑就开始出来了。我们投了很多钱，也做了很多事，为什么没取得效果？因为让组织使用先进生产力这件事从来就不容易。有一个核心问题大家都在回避：员工为什么要用这个生产力？这个员工我真的用 AI 提升了 50%，那他是多干一倍的活呢？

还是把这个时间用于摸鱼？你怎么激励他把 AI 省下的时间真正用于做更多的事？这是一个生产关系问题，不是生产力问题。AI 有没有这个生产力是现在大家关心的问题。但实际上这个观察忘了一个点：就算它有这个能力，你的员工是会把这个能力给公司做贡献，还是用来早点下班？

你会注意到 AI 工具宣传中的一个悖论：它既被包装成给老板的“提效神器”，又被宣传为给员工的“摸鱼神器”。但这两者本质上是矛盾的，如果它对员工真是摸鱼神器，那在老板那儿就不可能是提效神器。

王启隆：经常有这样的广告。

吴穹：但这其实是矛盾的。如果这个东西对员工是摸鱼神器，在老板那儿它就不会是提效神器。如果对老板是提效神器，它就不会是摸鱼神器。所以现在大家只是在宣传上决定谁买单，你买单我就跟你说这个，他买单我就跟他说那个。但实际上……

王启隆：这个矛盾一直存在。

吴穹：这是一个非常深刻的变化：怎么让组织拥抱 AI？这件事情不容易，不是说你给了工具他就会用。

任何事情我们会有 1% 的尝鲜者、10% 的早期采纳者，他们愿意用 AI，但很多人属于那种“行吧、可以、还好了”的态度。所以让组织拥抱 AI 是一个系统工程，很不容易。

所以我们最近的一个想法是，未来要把 Agent 当成员工。当 Agent 成为员工之后，这个 1+N 里的“1”，任何一个人都是一个小队长或班长。那组织就要看这个班的效能。比如说未来一个人能带 5 个 Agent，那个人说他能带 50 个。公司觉得谁的效能更好？那肯定是带 50 个的效能更好。当然，这是建立在假设 Agent 的产量是一致的。

所以未来的考核体系、组织结构都会发生变化，来适应一个新的模式。原来我们是以人为工作中心的，未来可能是以 Agent 为工作中心。人的角色变成了带领 Agent 去工作。你的效能就不是你产出了多少，而是你带领了多少 Agent 产出了多少。这样的一套组织体系会更有利于发挥 AI 的价值。我们觉得未来整个方法论也会演进，这是一个非常重要的演进：我们怎么让组织在 AI 来临之后还能高效运作？这个地方会有非常多的创新需要做。

王启隆：您刚刚提到假设 Agent 的效能一致，这是基于什么样的假设？因为目前我们看到，AI 的表现依旧取决于我们给的上下文和提示词。可能有的人用 AI 比较厉害，他可以让一个 Agent 发挥出十个的效能。

吴穹：未来我们觉得整体的趋势是，短期之内最关键的不是让 AI 在一件通用任务上打 90 分，而是让它在一件简单的事情上打 99 分。在任务标准化、模型与提示词均被锁定的前提下，从统计上说，这些 Agent 的效能就相当于基本一致了。

为什么？因为通用的 90 分，总有 10% 的尾巴要人来收。这个收尾成本非常高，就像在软件工程的软件复用领域有一个原则：如果你复用时需要改 10% 的代码，成本基本上就跟重写差不多。

别觉得 AI 帮你干了 90% 你就赚了，修正那 10% 可能让你白忙一场。更别说只帮你干 50% 了，那很可能反而是生产力陷阱。

所以，下一步的重点就是让 AI 找到那些它能干到 99% 甚至 100% 的任务，让更多的小任务可以全自动完成。

那人做什么呢？就是进入“planning mode”：先把任务拆出来，确认每个小任务是对的，再分给其他的小 Agent 去做。然后，这些小 Agent 就可以日夜不停地把这些事做完。

这时候体现的就是你这个人的本事，因为你分任务分得好。人跟人的差距就出来了：

• 分得好的人，可以拆出很多小任务让 AI 自动执行，利用自己的睡觉时间，更高并发地完成事情。

• 如果分得不好，AI 做完了你还要改，最后你还是在干很多 review 的事情。

这就是为什么我们认为，未来更倾向于人类带领很多小 Agent 去工作。那时候，你的绩效，就是看你带的那些 Agent 干得好不好。

“AI 最重要的就是准确的数据，先把语言拉齐”

王启隆：我们再延伸聊一聊 AI 时代的 Agilean。您沉淀多年的 Adapt 方法论，其中一个核心理念是在谈效率和改进之前，先统一组织的管理信息架构，也就是把大家对需求、任务这些概念的理解先拉齐。在今天这个追求快的时代，为什么这种听起来有点慢的、先统一语言的工作反而变得更加重要了？

吴穹：因为现在大家都知道，AI 最重要的是数据，是准确的数据。我们现在在很多组织的大多数问题是，如果真正要做到智能化的软件开发，数据缺乏是非常严重的。

在很多组织里面，一个最基本的问题就是：到底什么是需求？什么是项目？我说的需求和你说的项目是不是一个东西？很多组织把任何一个需求都叫项目。在很多组织里，语言非常贫乏，所以什么都叫项目。然后就是 A 类项目、B 类项目、C 类项目，还有的组织叫“需求类项目”、“项目类需求”，各种奇奇怪怪的排列组合。

因为大家没有经过这个过程。我们在给别人做系统时，可能还做一点架构设计，做一点领域驱动设计（DDD）。但在我们自己的 IT 管理系统里，基本上大家都不做领域驱动设计。这样，你的概念就是混乱的，数据一定是混乱的，这时候 AI 就无从学习，无从智慧。所以反而要回到第一步：当你真正要开始重新构建一个线上化、数字化的研发管理系统时，反而需要把最基本的概念模型搞清楚。这就是我们说的管理信息架构。

王启隆：像 Adapt 框架，除了我们熟悉的研发角色，还扩展到 PMO、财务这样的角色。为什么一场成功的数字化转型，必须把这些看似外围的职能部门也深度卷入进来？他们能带来哪些研发部门自身不具备的关键价值？

吴穹：是这样，我们认为未来所有组织都会是科技型组织，这个趋势已经越来越明显。未来如果一个组织没有科技能力，很难想象它有竞争力。任何一个组织都是业务和科技的深度融合，科技能力都会成为每个组织必不可少的 DNA，同时也会成为一个巨大的成本中心。对组织来讲，科技的成本会成为一个非常大的部分。

这时候我们都会面临投资决策：我要做什么，不做什么？做了这个东西到底有什么收益？所以研发过程，就不仅仅是开发测试这个过程。从规划到立项，到中间不断调整投资决策，再到事后复盘，整个组织管理都要跟科技体系打通。我可以从 CFO 的视角看研发，可以从人力资源的角度看研发。这不仅仅是科技团队自己的管理问题，而是科技和周边的整个公司治理都需要打通。

这也是我们在 Adapt 里试图解决的问题。当然这个比较复杂，还在探索的路上。但我们觉得科技团队不能孤立地谈自己的管理问题，因为最后所有的管理都还是为整个公司治理服务的。

你只要把这条线打通，最后才能有效地管好开发团队。否则，开发团队也会受到公司其他部门的挑战和制约。

既不是定制开发，也不是盒装软件

王启隆：我们刚刚聊了 Adapt 方法论。顺着这个话题，聊一聊具体的工具。您有了 Adapt 这套管理思想之后，您的团队打造了“知微”这个工具平台。您曾将它比作一个科技组织的“财务系统”，那它具体是如何将您在 Adapt 方法论中的那些理念，比如分层的需求体系、多维的组织架构，变成一个管理者看得懂、用得上的数字化工具的？

吴穹：刚才我们聊了很多，已经充分体会到每个组织的差异性非常大。我们谈了组织结构，可以看到每个组织在每个阶段的组织结构都有它的道理。你很难说这就是最好的。每个组织在不同规模、不同阶段，都会采用不同的组织结构，所以我们认为组织是柔性的。

其实在大公司都待过的人知道，组织重组（re-org）是每年都会发生的。这并非是简单地否定过去、肯定现在，而是为了适应当前阶段的需要。今年的架构适用于今年的挑战，明年则可能需要另一套方案。

所以我们认为组织应该是柔性的。这种柔性也体现在企业的“管理信息架构”上，它往往是历史路径依赖的结果。比如，同一个概念，在这家公司叫“需求”，在那家叫“产品需求”，在另一家又可能叫“业务需求”。哪个最合理？其实没有定论，只要内部统一、沟通成本最低，它就是有效的。因此，每个公司的管理信息架构不仅各不相同，而且是动态变化的——今天加一层，明天减一层。流程和角色同样如此。

我们在咨询中发现，尽管管理原理相通，但具体到每个组织的“人、事、流、数”（人员、事务、流程、数据）时，却千差万别。这就导致了大多数标准化盒装软件无法满足企业的实际需要。客户买来软件后，往往会发现这里不匹配、那里不适用，最后只能削足适履，因为软件本身是固化的。

现在业界基本上就两种实践。一种是我找一帮人来定制开发，严格按照我的想法来做。这种实践，我们也看到它大概率的最后结果。因为厂商没有任何管理经验，你说什么我就干什么，你说的不对我也照着做，因为我也不知道对不对。所以很多这种定制开发型的管理系统，可能一开始用的时候大家就会觉得不好用，就不断乱改，改到三五年改不动了就推倒重来。这是一种情况。

另外一种就是买盒装软件。虽然不适合我的需求，但我对付着用。但这样很多时候落地效果也不好。