上周在余杭的产业园喝了一下午冷掉的美式。
对方HRD把刚印出来的组织架构图往桌上一摔。
三层变两层，审批节点从7个砍到2个，全员OKR跟到部门周会，折腾了14个月，跨部门项目的交付速度反而比转型前慢了18%。
他说现在每次开高管会，被问起敏捷组织转型的进度，都觉得脸上发烫——钱花了不少，工具买了一堆，培训请了三轮，怎么越转越慢？
被神化的“小队制”，从来不是砍层级那么简单
说实话，这不是我第一次碰到踩同样坑的企业。
过去几年大家聊敏捷组织转型，张口闭口都是Spotify的小队模型，仿佛只要把几百人的大部门拆成10个以内的小团队，给每个小队配个产品、技术、运营的全栈角色，就能像创业公司一样跑得快。
可真拆完了才发现不对。
就拿那家做消费电子的客户来说，他们把原来统一对接供应商的供应链团队，拆成了三个分支塞进不同的产品小队。结果同一个型号的Type-C接口，三个小队分别找供应商报了三次价，光比价花的时间就比之前整个供应链团队统一对接多了一倍。更离谱的是，三个小队为了抢同一家代工厂的产能，私下给了不同的交付周期，最后工厂那边排不过来，两个新品的上架时间硬生生晚了三周。
很多企业对敏捷的理解，还停留在“把大公司拆成小创业团队”的表层。从来没想过，把本来拧成一股绳的公共能力拆得七零八落之后，每个小队都要重复造轮子的隐形成本。我之前接触过一个做国货美妆的品牌，拆完小队之后，每个小队都自己找达人谈合作，同一个腰部美妆博主，三个小队分别报了三个不同的坑位价，算下来比原来品牌部统一谈的价格高了40%。多花的那些冤枉钱，比所谓的“快速决策省下来的时间成本”多了去了。
说白了，大家抄作业的时候，只看到了人家小队制的灵活，没看到人家背后有一整套成熟的公共能力支撑——所有拆出去的小队，不是断了线的风筝，是有统一的共享服务台托着的。
真正转得动的团队，都在偷偷补“连接的网”
我见过把敏捷做的比较顺的团队，反而是那些一开始没急着拆层级的。
比如杭州那家做新茶饮的品牌，他们启动敏捷组织转型的时候，第一步不是砍部门，也不是拆小队，而是把原来的供应链研发、视觉设计、用户研究、内容传播这些公共团队，全部改成了可随时调用的共享资源池。
什么意思？就是这些人不再固定属于某个部门，也不用坐班在某个固定的小队里。每个项目立项的时候，由项目负责人根据实际需求，从资源池里点对应的人，项目结束之后，参与的成员直接回到资源池，等着下一个项目匹配。
去年他们推一款带鲜桃果肉的气泡水，从立项到全国门店上架只用了27天，比之前同类型新品的上线周期快了整整一倍。不是因为砍了多少审批流程，而是从项目启动的第一天开始，项目组就把供应链的研发人员、门店运营的督导、内容部的达人对接人，全部拉进了同一个共享文档里。配方要调整甜度？直接在文档里@供应链研发的同事，不用走部门审批打申请。门店要做活动海报？直接@设计岗的同事，把需要的尺寸和风格写清楚就行。
没有什么魔法。
很多人以为敏捷是把原来的金字塔推倒搭积木，实际上是在金字塔的缝隙里，织一张能随时接住需求的弹性网络，让本来要爬三层楼传的话，现在走个横向通道就能递到对方手里。真正的敏捷弹性，从来不是无边界的混乱，是有规则托着的灵活。
反观那些一开始就急着拆团队的企业，给每个小队拉个飞书群就算完成了转型。群里三天两头@全体成员，跨部门的事还是要找各自的领导签字，走原来的审批流程。那不是敏捷，是换了个地方开无效会。
别把敏捷当解药，它本来就是个“折腾人的系统”
不过话说回来，那些跑的快的团队，背后的折腾真不是外人能看到的。
就说那家新茶饮的品牌，为了跑通资源池的调度机制，前半年光是开协调会，就把原来的“部门月度汇报”全部取消，改成每周一次的资源匹配会。谁有项目需求，谁上来报，资源池的负责人根据项目的用户价值、投入产出比排优先级。最开始的时候乱成一锅粥——有个做品牌周边的项目，因为优先级排得靠后，硬生生等了三周才排到设计资源，项目组的负责人在会上拍桌子，说这机制根本不灵活。后来他们干脆给每个资源池留了15%的机动预留额度，专门给那些临时冒出来的、有爆点的小项目留资源，才把这个矛盾理顺。
我之前跟那个团队的COO聊天，他说最开始转型的头三个月，团队里一半的老员工不适应。原来只要管好自己部门的一亩三分地，把领导布置的任务完成就行。现在要随时响应跨部门的项目需求，还要能对自己参与的项目结果负责，有两个做了五六年的老主管，因为适应不了这种弹性的工作节奏，主动提了离职。
阵痛是真的。
那些在公开分享里把敏捷组织转型说的像换个系统就能一键升级的人，多半没经历过连续三个月每周开三次协调会、把原来写了十几年的岗位说明书全部推翻重写的狼狈阶段。现在很多企业的敏捷转型，最后变成了HR部门的季度KPI——建了多少个小队，落地了多少个OKR，采购了多少个线上协作工具，数都能报得清清楚楚。可真的问一句，最近的项目交付周期比之前短了多少，一线门店对用户反馈的响应速度快了多少，就开始支支吾吾。
说到底，敏捷的核心从来不是流程上的花架子。决策权跟着离用户最近的人走，你敢把原来集中在总部高管手里的决策权，一点点下放到一线的产品、运营、甚至门店员工手里，让他们能根据用户的反馈快速调整动作，而不是层层打报告等审批，才能真的快起来。
上次跟那个摔架构图的HRD喝完咖啡，临走的时候他说，之前总觉得敏捷是学个模型、抄个流程就能成的事，现在才明白，那些看起来轻飘飘的“灵活”，背后全是没写在PPT里的、反复磨出来的协作规则。
风一吹就倒的架子，永远跑不赢变化。
