「お客様と未来を描く戦略＆技術伴走 — CM エンタープライズサービス TAM 支援 2つのユースケース」

https://events.classmethod.jp/study-club/connpass-402011/

文章中的“我”是指登台发言的人。

伴走支援不是加人手：少人数团队如何撑起大客户

人少，事情却不小

一个大型游戏项目的发布支援，核心团队只有两个人。另一个客户是组织复杂、产品线众多的大型零售企业，我们要同时处理成本、运用和治理三条线。按照传统的「人力外包」思路，这两个项目都像是人手不够；但实际做下来，人少并不是最大的问题，真正决定成败的是：团队有没有把力气放在正确的位置。

我在 Classmethod 做 Enterprise Service。加入公司之前，我在 SIer 和 AWS 做过客户支持，见过不少「派一个很懂系统的负责人驻场」的做法。这种做法的好处是响应快，坏处是很容易变成「客户多了一双手」，而不是「客户多了一种能力」。所以我想讲的「伴走支援」，不是加人手，而是和客户坐在同一条船上，帮它看清方向、保持动力，最后让它自己把船开到目的地。

先说我理解的三件事。AI 的部分我放到最后，因为它和这三件事都有关。

伴走支援的三张面孔：指南针、流程、催化剂

很多人对伴走支援的第一印象是「深度理解客户的系统，然后提前发现问题、主动支援」。这个定义没有错，但它还是太抽象。我更愿意用三个比喻来说明。

第一是指南针。客户这艘船的目的地其实已经定了，船员也很优秀，但船上需要一个能一起看方向的人。伴走支援不是替客户决定去哪，而是在客户要做取舍的时候，帮他把方向指清楚。

第二是流程。船要往前走，光有方向不够，还得让动力顺畅地传到该去的地方。放到组织里，就是让信息、决策和执行之间的「流」不堵住。这个工作很像汽车或船的机油和发动机保养：平时看不见，却决定了能不能持续跑。

第三是催化剂。客户本来就有自己的力量，伴走支援不是从外面灌一套东西进去，而是把客户原有的力量引出来，让它反应得更充分。

这三件事对应三种角色，但在实际项目里，常常是同一个小组在不同时刻切换。

团队怎么组：不是派人，是上船

基本的配置是担当营业加运用工程师，必要时再加入解决方案工程师。根据合同内容，有时是一个专属小组，有时是几个人并排坐在客户的船上，甚至和客户一起登船。

这里的关键不是「我们派了几个人」，而是「客户的船有没有因此跑得更稳」。一个专属小组如果只是等工单，人数再多也只是外包；反过来，一个两三个人的小组如果能在关键节点上判断、动手、负责，它就能撑起比人数大得多的局面。

下面两个客户，正好是两种不同的形状。

案例一：游戏公司的「时间轴」——重心随阶段移动

第一家是一家游戏企业。它要上线一个大型版本，时间点明确，安全要求高；上线之后还要做优化。客户自己的标准很高，希望最终能自己维护，但当下对发布会带来什么、团队能不能接住，心里没底。

我们配了两人的专属小组：一位营业，一位工程师。发布前，我们把客户的不安拆成具体的技术问题，一条条解决；发布当天，团队在现场值守；发布前后，监控不是「出了事再看」，而是每两小时看一次关键指标，发现异常就立刻开 ticket，转给后台支持团队。这套做法听起来很朴素，但它让「发布」从一个靠运气的时刻，变成了一个有观测、有回退、有升级路径的过程。

稳定之后，团队的重心开始移动：先保发布稳定，再做优化，然后做安全加固，最后把成本优化也接进来。这里有一个很重要的细节：目标不是一开始就写死、然后机械执行。客户最初想做的事很多，标准也高；真正走起来之后，我们在途中不断调整「中继点」——先把这个守住，再谈下一个。最初看见的目标还在，但路径被重新画过。

现在，客户遇到问题会先来找我们做「壁打ち」（碰撞想法），而不是等到合同里的工单流程。这种关系不是靠人数堆出来的。

案例二：大型零售的「空间轴」——把断掉的流程接起来

第二家是一家大型零售企业。产品线多，每个产品有不同负责人，组织复杂；工具也复杂，彼此割裂。一个问题常常是：有人发现了，但没有人把它整理成可以推进的议题，事情就停在那里。

客户那边有一位很懂 AWS 的资深负责人，他的目标是让团队最终能自走，而不是长期依赖外部。我们设计的支援有三个轴：成本、运用、治理。

为什么是三个？因为单做成本削减，效果再漂亮也是一次性的；要让削减持续发生，必须把运用支援和治理强化一起做，让流程自己转起来。成本是入口，但入口不是终点。

三根支柱的分工不是并列的。最上面是战略，下面是一线的运用工程师，但站位不同：战略的人要能下到现场，运用的人要能抬头看全局。成本这块，具体做法包括为计算资源设计 Compute Savings Plans 之类的承诺折扣，整理数据传输的折扣；同时做可视化，用每天取得的数据分析「这个量级有没有过度预留的风险、能不能买到更划算的承诺」，把数据变成采购的证据。运用工程师每天跑，发现偏差就反馈给战略；战略给出计划和预期效果，再回到现场验证。两边来回送球，而不是各做各的。

结果有两个数字：大约一个月，把此前积压的任务清理掉；成本削减的幅度超过了最初设定的目标。成本可视化后来还长成了日常的成本削减清单，治理上的难点也被整理进服务流程。

两种形状，三个共同点

两个案例的团队形状不同。游戏公司是时间轴上的支援：一个最小规模的专属小组，随着发布、稳定、优化、安全、成本的阶段，不断移动重心。零售企业是空间轴上的支援：多层的组织、多个产品线，需要更宽的覆盖，把不同层级的问题接起来。

但底层有三件事是共通的。

第一，提案要用客户自己的话讲。不是把我们准备好的菜单推过去，而是把客户已经说出口的焦虑，翻译成他能判断的方案。客户听到「这正是我在担心的事」，才会愿意往下走。

第二，站在中立的位置，给判断材料。客户需要的不是「我们觉得好」，而是「这是数据、这是取舍、这是风险」。伴走支援的价值，很大程度上在于帮客户把判断的依据摆到桌面上。

第三，战略和计划要能落到手。只有 PPT 的支援，在组织深处是推不动的；只有动手的支援，又会变成替客户干活。两者必须放在同一个团队里，而且要让两边互相看见。

伴走支援真正的难点

这种模式不是没有难点。

一个反复出现的问题是：离我们最近的客户团队理解得最快，但组织深处的那一层跟不上。越往下走，越容易遇到「你们说得对，但我们这里动不了」。这时候，单靠讲道理没用，只能拿一个具体的用例先做出效果，让效果自己去说服人。这也是为什么我更喜欢从「能看见结果的小切口」开始，而不是一上来就谈全公司的改革。

另一个问题是：当客户真的学会了，伴走团队的价值在哪里？我的看法是，价值不在「只有我们会做」，而在观察力、经验、采购力和最后交付的责任。客户可以学会工具和流程，但组织里总会有新的变化、新的取舍，需要有人一起判断。伴走支援的终点不是客户离不开我们，而是客户有能力自己走，同时愿意在关键路口继续找我们商量。

生成 AI 的位置：加速造武器，但最后交付的是人

最后回到 AI。这场分享真正的主角，其实是 AI 工具和人。AI 不是「多用几个工具」，而是嵌进伴走支援的框架里，放大指南针、流程、催化剂的效果。

我们的做法可以拆成一个循环：人先去收集新鲜度高的信息——客户现场的变化、组织的动向、技术的更新；然后让 AI 加速把这些信息变成「武器」，也就是分析、方案、可交付的材料；输出要快，但最后一步必须由人完成：把输出变成客户能听懂、能接受、能自己往下做的东西。客户接受了，信任就增加，新的机会就出现，然后再进入下一轮。

说得再直白一点：AI 可以帮你更快地造武器，但武器怎么递到客户手里、怎么让客户觉得这是他自己的事，仍然是人。速度是 AI 给的，分寸是人的。

终点是客户自己跑起来

回到最初的问题：少人数为什么能撑起大项目？

不是因为每个人都更强，而是因为团队把力气放在了正确的位置——方向、流程、催化，战略与执行不分开，重心随着客户的阶段移动。伴走支援的最终产品，不是一份报告，也不是一套工具，而是一个客户自己能跑起来的组织。

人少，反而逼着我们把这件事想清楚。