字节阿里携程，开始拆部门墙了

本文来自微信公众号： 人人都是产品经理 ，作者：怪哥产品经理给程序员打绩效，程序员向运营汇报。这种在大厂听起来有些魔幻的场景，可能真的要出现了。据某自媒体爆料，携程上周召开全员大会，宣布开始推广一项名为“产研融合”的组织改革。

具体怎么改？原来分属不同部门的产品、运营、前端、后端、算法、测试等人员，全部按项目重新组队。一个团队里，每个工种可能只有1到2个人，由一名直接负责人（DRI）统一管理。项目负责人可以是产品经理，也可以是运营或者技术负责人。

团队内部，工程师能自己提需求、自己开发；产品和运营有了想法，也可以借助AI直接实现。甚至连汇报关系和绩效考核，都可能打破原来的职能边界。携程给出的思路相当激进：人人都是全栈，人人都是产品经理。

说实话，携程的这一步，迈的有点大。。。想想以前，一个产品需求从提出到上线，需要经历运营提需求、产品评审需求、写PRD画原型、设计、技术评估、研发排期、测试验收等一系列环节。遇上复杂需求，还得协调几个部门。

大家开完需求会、评审会、排期会，再开个进度同步会。各个部门都有自己的KPI和优先级，产品想尽快上线，技术担心架构和稳定性，运营着急上线验证和拿结果。出了问题，还容易互相扯皮。有时候，一个功能本身可能只需要两天开发，光沟通协调就耗掉一两个星期。

携程这次改革，显然是想解决这些问题。但真正让怪哥感兴趣的，是这次改革可能把传统的组织关系和协同一起打破了。一个产品经理能不能管理工程师？一个运营负责人有没有能力评价技术人员的工作质量？

过去习惯了按职能划分团队的大厂，恐怕要重新研究怎么做绩效考核了。而且，最近有类似动作的大厂，还真不少。今年10月底，据媒体报道，字节跳动旗下今日头条调整研发组织，将原本按职能划分的前端、客户端、服务端团队，改为按业务模块统一配置。

一个业务模块由同一位负责人管理三端研发，直接对技术交付结果负责。这相当于把原来分散在不同部门的研发人员，重新组织成能够独立交付的团队。联想走得更远。今年9月，联想与中国人民大学联合发布的《AI原生组织转型指南》披露，全栈工程师已经在联想中国区全部软件团队普及。

过去需要前端、后端、测试、运维等多个角色完成的工作，联想现在尝试通过“全栈工程师+5个智能体”的方式完成。一个人带着几个AI智能体，就能覆盖多个研发环节。如果说联想主要在改变岗位分工，那么阿里云已经开始研究整个研发组织怎么变了。

就在11月11日，阿里云开发者社区发布了CTO产研线最近三个月的AI Native实践。阿里云明确提到，允许团队在试验阶段跨越原有岗位边界，探索产品、研发、安全等角色的混合编组，以及人与Agent共同协作的新机制。

在其中一个安全产品项目中，阿里云把产品、研发、安全人员整合到同一个团队，每个需求由一名Owner从目标定义负责到结果验收。按照阿里云披露的试点数据，需求平均处理周期从50.9天缩短至13.8天。

这个数据还不能代表整个阿里，但至少已经有些说服力。其实吧，很多大厂早就在内部掀起多轮组织改革了。原因并不复杂。过去互联网公司强调专业分工，因为每个岗位都有很高的技术门槛。产品经理负责想清楚做什么，设计师负责审美和体验，程序员负责写代码，测试负责找Bug，运营负责把产品推向市场。

为了管理这么多人，就需要不同职能部门、不同层级的负责人，以及大量流程来协调工作。这套组织方式已经是国内互联网公司的标配，运行了十几年。但随着AI Coding、Agent等技术越来越成熟，很多事情开始发生变化。

产品经理可以借助AI直接开发功能原型，工程师也可以让AI帮助自己完成产品设计、前端开发和测试。运营人员甚至可以独立完成一些过去必须排期研发的工具需求。原本需要几个岗位配合完成的工作，越来越多地可以由一个人加上几个AI智能体完成。

问题来了。一个人都能完成好几个岗位的工作，企业还需要保留那么多职能边界、审批环节和管理层级吗？我觉得这个问题，恐怕会让不少大厂管理者感到压力。AI工具普及后，一线员工的效率提高了，但如果整个公司还沿用原来的工作流程，最终的交付速度未必能提高多少。

员工花半天用AI把功能做好，结果还要等三天评审、五天排期，再等领导开会拍板。这就有点尴尬了。当然，部门墙也不能随便拆。例如，让运营负责人管理研发团队，他可能很懂业务增长，却未必能准确判断代码质量、技术架构和系统稳定性。

让产品经理自己用AI开发功能，做个Demo也许很容易，但真要上线涉及支付、订单、用户隐私的系统，就没那么简单了。更麻烦的还有绩效和晋升。如果员工不再按照传统职能划分，谁来评价专业能力？

谁负责培养新人？多个项目组都需要的基础技术能力，又由谁长期维护？这些问题处理不好，原来的部门墙拆了，最后可能又建起一道道项目墙。甚至出现一个尴尬的结果：部门合并了，管理者没减少，会议反而更多了。

所以，我觉得携程这次改革能否成功，关键还是要看管理机制能不能跟着改变。如果只是把产品、运营、研发拉到同一个群里，再换个负责人，恐怕解决不了多少问题。对产品经理来说，这轮变化同样值得警惕。

当工程师也能提需求，运营也能借助AI开发功能，产品经理过去依赖的部分岗位优势，确实会受到冲击。特别是那些主要负责写需求文档、传递需求、协调排期的产品经理，未来的职业空间可能会越来越窄。

但真正理解用户、熟悉业务、能够做出产品判断，并且愿意对最终结果负责的人，价值反而可能更高。同样，工程师也需要更懂业务，运营人员需要具备更强的产品思维。大家都得学着突破原来的岗位边界。

我甚至觉得，这一轮AI组织改革，受到冲击最大的可能还有大厂的中间管理层。过去，一个几十人的团队，可能需要好几个职能负责人。每个部门都有自己的汇报关系、审批权限和绩效体系。如果未来一个小团队搭配几个AI智能体，就能独立完成从需求到交付的工作，那么管理岗位的数量、权责和存在价值，迟早也会被重新评估。

这件事估计比让员工学习AI Coding还难推动。讲真，让员工学会使用AI工具，可能只需要几天或者几个月；让管理者主动放弃已经习惯的权力和组织边界，恐怕没什么人愿意了。携程这次改革最后落地效果咋样不清楚，但方向肯定是对的。

搞不好某一天，各大互联网公司就开始规模化效仿了。AI都开始重构员工的工作方式了，大厂的组织架构，被迫升级是迟早的事。