麦肯锡最近做了一项调查，向300家企业提出了同一个问题：在应用了AI工具之后，公司的整体生产力提升了多少？
答案有些令人尴尬——平均只有5%到15%。
这个数字让人困惑。
如果你去问任何一位正在使用AI编程工具的开发者，他们都能给你讲出十几个亲身经历的故事：那些原本需要花费数天才能完成的任务，现在几分钟内就能搞定。个体层面的效率飞跃是真实存在的，但为什么一旦放大到整个组织的层面，这些提升就仿佛消失了呢？
问题出在从个人生产力到团队协作的那道鸿沟上。
新的瓶颈正在形成
当AI工具开始大规模进入软件开发流程，一些意想不到的瓶颈开始显现。
第一个瓶颈是工作分配。
AI对不同任务的效力差异巨大，有些任务它处理得极好，有些则表现平平。同时，团队成员对AI工具的熟练程度也参差不齐。这让工程经理很难准确判断该把什么任务分配给谁，以及应该为此预留多少时间。
第二个瓶颈是代码审查。
许多公司提供给AI的需求描述仍然是传统的用户故事，写得比较模糊。AI生成的代码不一定符合预期，但审查机制依然依赖人工。结果就是，自动化了代码生成环节，却制造了更多需要人工介入审查的工作量。
第三个瓶颈是技术债务。
卡内基梅隆大学最近的一份研究指出，AI生成的代码正在加速技术债务的积累。代码量上去了，随之而来的复杂度和维护成本也同步攀升。
这些瓶颈的核心是什么？
是我们还在用旧范式的工作方式，去承接新范式的生产力。
大多数企业的软件团队仍然是8到10人的规模，仍在跑着两周一次的敏捷冲刺，还在沿用几年前定义的角色和职责。这套体系是为人类开发者设计的。当AI加入后，这套体系反而成了一种限制。
重新设计工作流程
麦肯锡与一家国际银行合作进行了一项实验。他们没有简单地给团队配备AI工具，而是重新设计了整个敏捷工作流程。
改变从需求定义开始。
产品经理不再撰写长篇大论的需求文档，而是直接与AI一起迭代技术规格说明。他们会要求AI生成多个功能原型，并在安全性、可观测性等维度上明确验收标准。这样做的好处是，开发者拿到的需求更加清晰，后期的返工量得以大幅减少。
团队被按工作流重组。
一个小组专门处理小型的Bug修复，另一个则专注于绿地开发。这样划分是因为AI在这两类任务上的表现模式和效率完全不同，分开处理能够实现整体效率的最大化。
协作开销被压缩。
以前，产品经理需要等待数据科学家提供分析才能调整功能优先级。现在，他们可以直接利用AI观察实时用户反馈，并自行做出决策。
这些调整带来的直接结果是：代码合并量增加了51%，AI工具的使用频次提升了惊人的60倍。 更重要的是，这些效率提升直接对应并服务于银行的业务优先级。
角色正在重新定义
麦肯锡的调查发现，那些转型效果最好的公司有一个共同特征：他们重新定义了团队中的角色。
工程师的工作重心从“执行代码”转向“编排任务”。
他们需要思考的是：如何将复杂工作拆解成适合AI处理的模块？如何高效审查AI的产出？如何将不同的部分无缝组装起来？
产品经理开始直接利用代码进行原型构建，而非在文档上反复打磨。这个变化看似微小，却意味着产品定义的方式发生了根本性的改变。
前端、后端、QA这些传统的职责界限开始融合。
新的角色可以被称作“产品构建者”，他们需要具备全栈的理解能力，能够有效管理和编排AI代理，并对整个代码库的架构有清晰的全局认知。
团队规模也在缩小。
从需要“两个披萨”才能喂饱的8到10人团队，转变为只需“一个披萨”的3到5人小组。但这些小组的产出并没有相应减少，因为AI填补了人力资源的缺口。
麦肯锡与另一家科技公司的合作案例显示，在总人数不变的情况下，他们组建了更多的小型团队，而每个小组的产出保持甚至超过了原来大型团队的水平，且代码质量并未下降。
有意思的是，调查中70%的公司完全没有调整角色定义。
他们给团队配上了先进的AI工具，却期望团队依然按照过去的老方式工作。这就像是给马车装上了发动机，却仍然要求它像马车一样奔跑。
规模化的真正挑战
从一个团队的成功试点，扩展到几百个团队的全面铺开，这完全是两场不同的游戏。麦肯锡与一家科技公司的合作经历很能说明问题。
他们推出了覆盖产品开发全生命周期的AI工具套件。初期使用率确实上去了，但很快就掉了下来。员工要么根本不用，要么用得很糟糕。尽管不断增加用户，但对整体业务的影响微乎其微。
他们不得不重启整个项目。
重启的核心是什么？麦肯锡的总结是 “把很多小事做对”。
这包括：
重新设定期望。 对开发者来说，AI的到来意味着什么？对产品经理又意味着什么？每个角色的日常工作将如何具体改变？
提供更具实操性的培训。 不再是听讲座，而是“带着你的真实代码来”。有专门的教练在旁边指导，特别是在最初的几个冲刺周期，这是养成新工作习惯的关键时期。
建立新的测量体系。 你需要清楚地知道什么正在改变，什么在真正得到改善。
设置新的认证和激励机制。 这些看起来是管理上的“小事”，但对于驱动根本性的行为改变至关重要。
这些措施单独看都不起眼，但组合起来，才构成了能够推动规模化变革的真正力量。
测量什么，就会得到什么
麦肯锡的调查有一个意外发现：那些表现最差的企业，甚至不测量开发速度，只有10%在系统性地测量生产力。
这解释了很多问题。如果你不知道要走向何方，那么任何道路都可能带你偏离目标。
麦肯锡建议的测量体系分为三层：
输入层： 投入了多少钱购买工具，花费了多少时间进行培训和变革管理。
输出层： 大多数公司只关注AI工具的采用率和开发速度的提升。但麦肯锡认为还应该关注开发者的NPS（净推荐值）评分——他们是更享受工作了，还是更沮丧了？代码的安全性、质量、韧性也需要跟踪，例如高优先级Bug的平均解决时间。
经济结果层： 这是高管层最关心的。达到收入目标的时间缩短了多少？高质量功能带来的市场溢价是多少？客户数量增长了多少？每个交付小组的单位成本降低了多少？
这套体系的价值在于，它将AI工具的使用与最终的业务结果清晰地连接了起来。核心不是为了用AI而用AI，而是为了创造可测量的商业价值。
未来会是什么样
麦肯锡给出的未来愿景是：更短的冲刺周期，更小的团队规模，但团队数量更多。
这个模型基于一个假设：即使未来的AI智能体变得更聪明，人类开发者变得更熟练，这种基本结构仍然成立。人机协作的最优单元不是庞大的团队，而是那些小而灵活、能够快速响应的小组。
他们给企业的建议非常直接：现在就开始行动。
因为这是一场关于“人”的变革，需要时间去适应和磨合。等到AI工具完全成熟再动手，就为时已晚了。变革过程本身，就是最重要的学习环节。
另一个建议是：找到适合自己的协作模式，并设定大胆的目标。
不同类型的工程任务可能需要不同的人机协作模式。例如 “现代化遗留代码库” ，这类任务上下文需求高但输出明确，适合“智能体工厂”模式——人类提供初始规格和最终审查，中间过程尽量减少干预。
而对于 “新功能开发” ，可能更适合迭代循环模式，AI作为共创者提供多种设计选项，从而大大加快反馈和决策循环。
关键在于实验、测量和快速调整。
那些有望在AI时代保持领先的公司，并非因为他们的AI工具更先进，而是因为他们更早地意识到：工具只是变革的起点，真正的变革在于如何重新组织“人”与“工作”。
从10%到50%甚至更高的效率提升，横亘在中间的这道鸿沟，本质上是一场 “组织能力”的鸿沟。技术已经准备就绪，而我们，是否准备好面对这样的未来了？
关于如何构建适应未来的高效技术团队，云栈社区 的开发者们也在持续探讨与分享实践经验。
发表于 5 小时前
|
查看: 0|
回复: 0
