凌晨一点十七分。我手机屏幕亮了微信弹出来一条“魏老师我们系统又出问题了能不能帮忙看一下上次那个事之后我们一直在找你团队找不到……”发消息的是某连锁客户的 IT 负责人老周。他说的上次那个事是 14 个月前我带队给客户做的数字中台上线——上线当天跑得挺漂亮文档也交了培训也做了。14 个月过去了。客户业务量翻了一倍系统也跟着跑了一年多。现在凌晨一点出了问题他们打开后台准备排查发现——接手的工程师小李上个月已经离职了。仓库的 README 还写着三年前的部署命令跑一半报错。生产环境的账号密码存在前同事的私人备忘录里前同事手机换了号联系不上。决策档案上写着为什么这么选——但那条理由是某个会议上某位前 CTO 口头说的一句话没落进任何文档。老周翻遍客户的微信群、邮箱、文档库、SVN 历史——能找到的知情人要么早就离开项目要么根本不在客户现场。他最后只能回到微信上找到我。我心里咯噔一下——不是我不想帮是这套系统的代码我 14 个月前就交接给客户了工程师换了两拨关键决策没文档我今天再看代码我也要重新捋一遍。那一晚我花到凌晨四点帮他定位了一个很简单的内存泄漏问题——一个参数判断写反了。如果是当时的工程师在这个 bug 5 分钟就能定位。我用了 3 小时。我躺在床上翻来覆去想——系统上线那天我们做了一个看起来很漂亮的交付。但 14 个月后客户半夜出事找不到一个能 5 分钟解决问题的人。我们交付的是软件吗是。我们交付的是客户能用起来的能力吗不是。这件事儿值得我写一写。这一篇我想跟你聊聊长期陪客户过日子这件事。一次性交付不是终点——是陪客户过日子的起点。一、为什么交付完了就失联是定时炸弹我做过这么多年工程师、见过这么多项目之后回头看发现绝大多数交付完就失联的项目都有同样的剧本。剧本第一章交付那天一切都很完美。PPT 漂亮、PPT 上写的功能都跑通了、PPT 上写的 KPI 都达标了、客户在大会上讲了一段感谢的话、你的老板把你的名字写进了 OKR 总结——剧本第二章交付后 3-6 个月团队开始散。项目结了。工程师被调到下一个客户、做下一个项目。文档没人更新。代码没人 review。生产环境的运维账号没移交。客户业务在长代码在沉睡——3 个月没改过一行。剧本第三章交付后 12-18 个月定时炸弹响。客户的业务发生了变化、流量涨了三倍、出现了新的合规要求、某个依赖的第三方服务下线——任何一个变化都可能让系统出问题。客户半夜打电话找你——你团队的工程师已经换了两拨人。仓库的代码看着像别人写的。文档里写的是三年前的部署命令。生产环境的运维账号在某个前同事私人备忘录里前同事已经离职。客户当时拍板的决策理由在某个会议上口头讲过没落进任何文档。这时候你发现你交付的不是一套客户能用的系统是一颗客户在某个时间点一定会被引爆的定时炸弹。这不是我编的。我去查了一下行业里的真实事件——案例一某大型零售客户的电商系统2019 年由一家外包公司交付。2021 年客户要做双十一大促前的扩容改造找原班人马——3 个核心工程师全部离职文档全部过期账号密码失效。最后客户花了 8 周时间考古从 SVN 历史、聊天记录、邮件里拼凑出当时的决策才算把系统摸清。8 周。一个项目就这样被考古了 8 周。案例二某金融客户的理财系统2020 年交付。2022 年合规检查要求整改加密算法。原班工程师 2 人离职、1 人转岗、1 人创业。客户找到原外包公司原外包公司说这是新需求要重新立项。重新立项——意味着客户要重新付一遍钱、走一遍流程、等几个月。案例三某 SaaS 平台的内部管理系统2021 年交付。2023 年核心数据库服务器硬件老化要换机。客户运维发现原来的部署文档是 2020 年写的那时候用的是 Docker 18.x现在 Docker 都 25.x 了命令完全对不上。这三件事儿听起来扎心但它们每天都在发生。我敢说一句话——99% 的一次性交付项目交付后 18 个月内都会出现客户想找你团队却找不到的尴尬。这话听着绝对。但你听我讲完下面两个真相你会觉得我客气了。真相一交付完团队散了文档留不住任何决策的为什么。代码能留住做了什么但留不住为什么这么做。为什么这么选 PostgreSQL 不选 MySQL为什么这个接口用同步不用异步为什么这个参数默认是 5 不是 10这些为什么如果只在某次会议上口头讲过、没落进文档——半年后没人能答上来。新人接手只能猜。猜错了系统出事。真相二交付完账号密码和运维凭据不标准化移交下次出事没人能进系统。很多团队的运维账号是谁在现场就给谁开一个从来没想过半年后换人了这个账号怎么办。结果就是——生产环境账号在某个前同事私人备忘录里前同事离职手机换号新人进不去系统。出事那天的真实故事都是这两件事的变种。交付完了就失联——不是客户的问题是你交付模式的问题。你交付的是今天能跑起来的代码不是客户未来五年都能继续走下去的能力。这两件事儿从来不是一回事。我接客户这种电话接多了慢慢发现一件事——所有客户出事那天找过来的真实需求都可以剥成三件出事能找到人、能查到当时的决策、能基于现状继续演进而不用推倒重来。这三件事儿听着简单做起来难。为什么难因为这三件事儿都需要事前的工程纪律——不是你出事那天临时抱佛脚能解决的。你出事那天临时建一个找人的机制——来不及。你出事那天临时写一份 ADR 记录决策——来不及。你出事那天临时做一份接手手册——更来不及。这三件事儿都得在交付之前就准备好。出事那天能 5 分钟找到人——是因为你平时就把 SLA、oncall、应急流程做好了。出事那天能查到决策——是因为你平时就把 ADR、变更记录、决策档案做好了。出事那天新人能接手——是因为你平时就把 onboarding、交接清单、账号权限做好了。这三件事儿的共同点——都是事前功夫。事前功夫的特点是——没事的时候你觉得多此一举有事的时候你才知道救你命。这件事儿怎么落是下篇的重点。我们这一篇先把为什么讲透。二、剥客户的三个真需求——交付之后客户真正要的是什么我接客户深夜电话时从来不听他们说我们想要一个系统或者我们付了钱你们应该管到底。我听三件事——真需求一出事那天能找到人。“我们半夜系统挂了能不能有个人接电话”“我们想做个新功能找不到懂这套代码的人。”“我们的数据库要扩容谁能帮忙看看”这三个问题翻译过来都是同一句话——出事那天能找到一个懂这套系统的人。很多客户嘴上不说但心里一直在担心这个。他们不是想要你包一辈子他们想要出事那天能找到人。能 5 分钟响应 vs 24 小时响应差别巨大。能 5 分钟响应的人不是临时去找的——是你长期培养的。你平时不在客户现场、出事那天才派人过去等工程师赶到现场、黄花菜都凉了。真需求二能查到当时的决策原因。“为什么这个接口这么设计”“为什么当初选 PostgreSQL 不选 MySQL”“为什么这个参数默认是 5 不是 10”这三个问题翻译过来都是同一句话——能查到当时为什么这么决定。这不是为什么这么做是当时为什么这么选。这两个问题答案不一样。“为什么这么做”——看代码能知道。“当时为什么这么选”——看代码不知道得有决策记录。决策记录不是代码注释。决策记录是 ADRArchitecture Decision Record——一份单独的文件专门记录为什么这么选、当时考虑过哪些方案、为什么放弃这些方案。很多团队交付完没留 ADR。客户想改一个参数都怕改错了——因为不知道当初为什么这么设。真需求三能基于现状继续演进而不是推倒重来。“我们业务涨了三倍这套系统能不能继续撑”“我们要上新业务能不能基于这套系统改”“我们的合规要求变了能不能快速调整”这三个问题翻译过来都是同一句话——系统能跟着业务一起长。能跟着业务一起长的系统跟今天能跑的系统是两回事。能跟着业务一起长的系统——代码分层清晰、文档齐全、测试覆盖、模块边界明确新人能快速上手能基于现有能力迭代。今天能跑的系统——代码一团糊、文档不全、测试缺失、模块边界模糊新人只能考古式摸代码。这三个真需求翻译成一句人话客户买的不只是今天的系统是未来五年都能继续走下去的承诺。你能给客户的不是上线那天跑得漂亮是上线之后也能一直有人懂、能改、能撑。这件事儿不是某一个工程师靠谱就能解决的——是一套体系才能解决。你听过卖软件和卖服务这两个说法吧这两个说法都不够准确。更准确的说法是——“卖代码和卖能力”。卖代码——你交付的是字节、是功能、是 API。客户拿走这些字节之后爱怎么用怎么用跟你没关系。卖能力——你交付的是客户未来五年都能继续走下去的能力。客户拿走这些能力之后能不能用、好不好用跟你一直有关系。前者是一锤子买卖后者是长期陪跑。我每次给老板讲这个比喻的时候他们都会问一句“卖能力是不是成本更高”成本更高——但客户愿意付的钱也更多。卖代码的客户跟你谈价格。卖能力的客户跟你谈长期价值。这两种客户你愿意接哪种三、一次性交付像租房长期运维像买房我给客户讲长期运维的时候从不用长期合作“持续服务”客户成功这些商务黑话开场。我用的是一个生活化比喻——一次性交付像租房。长期运维像买房。租房是什么体验你付了房租住在房子里。房东给你配了基本家具——床、桌子、椅子。你住了一年两年灯泡坏了房东不一定会来修水管漏了房东可能让你自己掏钱修。租客跟房东之间是短期交易关系——你付钱我给你住租约到期就各走各的。买房是什么体验你付了首付、还了贷款住进了自己的房子。小区的物业会一直陪着你——电梯坏了物业协调维修、楼道灯不亮物业派人换、停车位纠纷物业来调解、节假日物业送温暖。业主跟物业之间是长期共生关系——你住多久物业陪多久。你会发现一个很微妙的事情——租客跟房东之间没有任何长期承诺。灯泡坏了你不修下次房东也不一定让你续约。搬家时房东不关心你下一站去哪。业主跟物业之间有日常关怀也有长期陪伴。灯泡坏了物业不管下个季度业委会就不续约了。搬不搬物业都关心你这户——因为你是长期的客户。这两个模式本质差别在于长期承诺是否存在。把这件事映射到我们做项目的场景——一次性交付 租房模式。项目交付那天是个时间点。时间点之前你是乙方时间点之后你变成前任乙方。客户的系统出事了你能帮就帮、不能帮也行——反正合约已经结束。长期运维 买房模式。项目交付那天是个起点。起点之后你是长期陪客户走下去的乙方。客户的系统出事了你得接——因为你跟客户签的不是一次性合同是长期居住合同。这两种模式对客户的价值差距巨大。租房模式——客户付了一次钱得到的是今天的系统。明天系统出事了找不到人下个月想改个功能找不到人半年后业务变了找不到人。买房模式——客户付了同样的钱甚至更少得到的是未来五年都能继续走下去的能力。明天出事能找到人下个月想改能找到人半年后业务变了还能继续改。对客户来说五年都能继续走下去比今天上线跑得漂亮值钱一百倍。为什么因为今天跑得漂亮是结果五年走下去是能力。结果是有限游戏能力是无限游戏。客户买的是能力不是结果。你只交付结果客户的系统在某个时间点一定会塌——因为没人能继续往上盖。你交付能力客户的系统能在未来五年里继续演化——因为有人一直在陪着往上盖。这两种交付模式我把它叫——交付软件和交付生活方式的差别。听起来很玄翻译成人话——你交付的是一套代码你做的是卖软件。你交付的是客户未来五年都能持续走下去的能力你做的是成为客户数字化生活的一部分。哪个值钱你愿意买哪个我之前给一个老板讲这个比喻他听完了沉默很久跟我说了一句话——“魏老师我做了 15 年软件从来没听人这么讲过。我之前一直以为我卖的是软件听你这么一说我才发现我卖的是客户未来 5 年的命。”我笑了。其实不是卖命——是陪客户过日子。你愿意做哪种乙方一次性交付的乙方——客户付你一次钱你给客户一套代码。从此客户的事跟你无关。长期陪客户的乙方——客户付你同样的钱你给客户未来五年都能继续走下去的能力。从此客户的事跟你一直有关。这两种乙方你愿意做哪种我敢说一句话——长期陪客户的乙方比一次性交付的乙方值钱一百倍。为什么因为一次性交付的乙方每做一单都要从零开始找客户、谈价格、做交付、收尾款。下一年还要重新找客户。长期陪客户的乙方做一单留下一个长期付费的客户、做两单留下两个、做三单留下三个——客户越来越多续约越来越多团队的资产越来越多。前者是猎人模式——每打一枪都要重新瞄准。后者是农夫模式——种下一棵果树每年都结果。这两种模式5 年后的差距你能算出来。猎人 5 年打 10 枪每枪 100 万 总收入 1000 万。农夫 5 年种 10 棵树每棵树每年结果 50 万 第 5 年总收入 2500 万且还在涨。你愿意做猎人还是农夫我见过太多做猎人转农夫的团队——他们转型的那 1-2 年最难但熬过去之后就是完全不同的收入曲线。农夫模式的护城河是客户信任——你陪客户越久客户越信任你客户越信任你越离不开你。猎人模式的护城河是价格优势——你价格越低客户越多客户越多你越累。这两种护城河的差距——前者是滚雪球后者是滚石头。四、一次性交付和长期陪客户的团队差距我见过的团队大致可以分成三种。第一种交付完就撤的团队。交付那天 PPT 漂亮、客户签字、尾款收回。然后工程师调走文档归档账号保留。这种团队做的事儿本质上是卖软件。客户半年后想改个东西找不到人。客户一年后系统扩容找不到人。客户两年后业务转型找不到人。客户每一次遇到想继续往前的时刻都得考古式从头来过。这种团队的结局——客户下次有项目不会再找你。你的口碑只在这一个客户身上有效传不出去。你团队的工程师一直在做一次性交付永远在交付新项目永远在从零开始没积累。人效上不去。第二种交付完有运维但没体系的团队。交付那天 PPT 漂亮、客户签字、尾款收回。然后团队留 1-2 个工程师做运维——客户有问题时救火没事时闲着。这种团队做的事儿本质上是卖软件 卖售后。客户有事能找到人——但这个人可能今天在处理另一个客户的事、明天在休假、后天换了岗。客户的体验是有事能找到人但响应不及时、解决问题不彻底。这种团队的结局——客户续约率比第一种高但工程师流失率高——因为天天救火没成长、工资涨幅低、有能力的工程师都走了。留下来的工程师越做越累、能力越来越窄、最后也走了。你团队的运维工程师是个消耗性岗位。口碑有但仅限于我们有事能找到人——不够深。第三种长期陪客户过日子、把运维做成不依赖任何一个人的体系的团队。交付那天 PPT 漂亮、客户签字、尾款收回。然后团队按体系长期陪客户——SLA 写明白 5 分钟响应、2 小时定位、4 小时修复。文档和决策记录留在客户能访问的地方——不是团队的私人备忘录。账号密码走权限管理——不依赖任何一个人的私人笔记本。人员变动有交接流程——交接人清楚接手人能从哪里继续。这种团队做的事儿本质上是成为客户数字化生活的一部分。客户有事第一时间找你——不是因为合同是因为找你最稳。客户想改个东西第一时间找你——不是因为价格是因为你能改对。客户业务变化第一时间找你——不是因为历史是因为你最懂我们的系统。这种团队的结局——客户续约率高——不是 60%、70%是 90%。客户口碑推荐多——客户愿意主动介绍给同行因为他知道找你最稳。团队能沉淀资产——客户的系统越做越深、资产越积越多新工程师来了能复用前人的工作。人效高——不需要每次交付都重新搭一遍工程师是在客户系统上做长期建设不是每次从零开始。这三种团队三年后的状态天差地别。第一种的三年后还在做一次性交付工程师来来去去团队规模上不去。第二种的三年后运维工程师累垮了剩下的工程师要么跑路要么躺平续约率开始下降。第三种的三年后客户越积越多、团队越做越稳、工程师越干越有积累形成正向循环。哪种团队你想做我说句扎心的话——大部分团队是第一种或第二种。他们不是不知道要长期陪客户——他们以为自己在长期陪。他们不知道的是长期陪客户这件事工程纪律要求比你以为的严格得多。长期陪客户不是留 1-2 个工程师救火——是用一套不依赖任何一个人的体系把客户长期陪好。我把这个不依赖任何一个人展开讲讲——不依赖某个特别靠谱的工程师——就算小张今天不在、出差、休假、生病、离职客户的响应不变。不依赖某个特别贴心的客户成功经理——就算小李今天不在、轮岗、调走客户的日常沟通不变。不依赖某个特别勤快的项目经理——就算小王今天不在、培训、休假、晋升客户的进度同步不变。体系化的团队是任何一个人离队都能继续运转的团队。非体系化的团队是任何核心离队都可能塌方的团队。我跟你讲一句扎心的话——90% 的团队是非体系化的团队。他们以为自己在陪客户其实是靠小张撑着的团队。小张在的 3 年客户满意、团队稳定、收入增长。小张走的第 1 年客户投诉、团队动荡、收入下滑。小张走的第 2 年客户流失、口碑崩盘、团队重组。3 年的努力被小张的离职清零了。你愿意做这种团队吗反正我不敢。这件事儿怎么落到工程上——是下篇的核心。五、长期陪客户的本质——不是卖软件是成为客户数字化生活的一部分很多老板把长期陪客户理解成多签几年合同——这是错的。合同签得再长团队散了、文档没了、账号失效了合同也救不了客户。合同是纸。纸救不了客户出事那天的事。真正能救客户的是一套不依赖任何一个人的体系。我给客户讲这套体系的时候用一个比喻——长期陪客户不是签一份长合同是请一个靠谱的物业。你买了一套房签的是购房合同。合同签完房子是你的。但你住进去以后你会发现——房子不会自己修电梯、不会自己通下水道、不会自己换灯泡、不会自己管停车。你需要一个靠谱的物业长期陪着。靠谱的物业长什么样1. 24 小时有人接电话——出事那天的第一道闸。半夜电梯困人你打电话物业有人接。物业不管能不能修至少有人接电话、有人安排人过去。长期陪客户的团队也是一样——出事那天有人接电话、有人能响应。不是事后诸葛亮是事先有 SLA、有 oncall 轮值、有应急流程。2. 小区的图纸资料随时能查到——决策记录的存档。你家要改个水管走向物业能调出你家的水电图纸。你家要装个空调外机物业能告诉你哪面墙能打孔、哪面墙不能动。长期陪客户的团队也是一样——客户想改个参数、想加个功能能查到当时的决策记录——为什么这么设计、为什么这么选、当时考虑过哪些方案。不是拍脑袋改——是按之前的决策脉络继续演化。3. 小区的门禁钥匙不绑定个人——账号权限的标准化。物业的钥匙在物业经理手里不在某个保安私人手里。保安换班钥匙还在——因为钥匙是公家的。长期陪客户的团队也是一样——生产环境账号在权限管理系统里不在某个工程师私人备忘录里。工程师离职账号注销、权限交接——新人来了能接手。4. 保安换班有交接本——人员变动的交接。物业保安 24 小时三班倒但每个班次都有交接本——上一班发生了什么、谁处理了、有什么遗留。长期陪客户的团队也是一样——工程师换岗、离职、新人接手都有交接流程。不是口口相传、不是找那个前同事问问是写在文档里的标准动作。5. 物业每月上门问有什么需要修的——持续改进的回访。靠谱的物业不只是等业主报修——他们会主动问最近有什么不顺手的地方、“有没有什么可以优化的地方”。长期陪客户的团队也是一样——不是等客户提需求才行动是定期回访、定期优化、定期把行业里新出现的好做法同步给客户。你看靠谱的物业做的事儿本质上是——用一套不依赖任何一个人的体系把小区的日常运维做好。不是某个保安特别靠谱——是物业的体系让任何一班保安都靠谱。你愿意找哪种物业找一个今天值班的小张特别靠谱但他明天就不在了的物业还是找一个不管今天值班的是谁体系都能保证响应的物业答案不言自明。把这件事映射到我们做项目——客户要的不是今天接电话的小李特别靠谱是不管今天接电话的是谁体系都能保证响应。这才是长期陪客户的本质——不是某个工程师特别靠谱是一套不依赖任何个人的体系把这件事长期做好。这件事儿听起来抽象落实到工程上是一整套具体的体系——运维体系——出事有 SLA、有 oncall、有应急流程。文档体系——决策有 ADR、变更记录在版本控制里、知识有索引。账号体系——生产账号在权限管理、不在私人备忘录、人员变动有交接。人员体系——换岗有交接流程、接手有手册、新人有 onboarding。四套体系 五道闸持续改进、变更管理、事件响应、问题管理、发布管理。这套体系怎么搭、怎么运转、怎么一步步落地——是下篇卷袖子干活的部分。这一篇先把为什么要长期陪客户的心智讲透。我跟你讲讲靠谱物业这个比喻在我心里的形成过程——2018 年我第一次搬进自己的房子签购房合同的时候很开心。住进去的第一周我就发现——电梯坏了没人修、楼道灯不亮没人换、停车位纠纷没人管。我去找物业物业经理跟我说“我们正在跟进。”我等了 3 天没人跟进。我又去找物业经理说“您这个事儿我们排在下周。”我又等了 1 周还是没人跟进。最后我自己掏钱请了个电工修了楼道灯、自己去找业委会反映了电梯问题、自己跟邻居协商了停车位。3 件本该物业做的事儿我自己做了。那一刻我突然理解了一件事——物业不是有就行是靠谱才行。乙方也不是有就行是靠谱才行。有物业的小区多了去了——大部分业主跟物业之间是互相不信任。靠谱的物业才是小区业主真正想要的——业主愿意续约、愿意推荐、愿意在物业群里帮忙说好话。靠谱的物业做的事儿本质上跟你长期陪客户做的事儿一模一样。都是用一套不依赖任何一个人的体系把日常运维做好。都是不管今天值班的是谁都能保证响应。都是在客户出事那天的 5 分钟内有人接、有人来、有人处理。这件事儿落到工程上是四套体系加五道闸的具体工程纪律。但这一切的为什么是为了把客户变成你长期的合作伙伴而不是一次性交易的对手。六、五种结局——一次性交付和长期运维的真实差距我见过太多项目看完三种团队再看五年后他们的结局差距大到你不敢信。第一种交付完就走的项目5 年后的结局——客户的系统在第 18 个月出了第一次大问题找不到原班人马。客户花了 8 周考古代码、3 个月才把系统重新摸清。这 5 个月里客户流失了一批——因为系统不稳定、新功能出不来。最终客户决定重做系统——找另一家外包公司从头搭。原外包公司——失去这个客户、失去这个客户的口碑推荐、未来 3 年也没接到这个客户介绍过来的新客户。第二种有售后没体系的客户5 年后的结局——客户的系统稳定运行了 3 年期间工程师小张救了 100 次火。第 4 年小张离职了——新接手的工程师小王发现所有隐性知识都在小张脑子里。小王用 6 个月时间考古——最后只恢复了 60% 的知识剩下 40% 跟着小张走了。这 6 个月里客户系统出了 3 次大问题——响应不及时客户投诉了两次。第 4 年底客户续约时砍价 40%——“反正你们的服务质量在下降”。第 5 年客户决定换供应商——因为续约价格和服务质量都不满意。第三种长期陪客户把运维做成体系的客户5 年后的结局——客户的系统稳定运行了 5 年期间体系自动响应了无数次问题。SLA 写明白、文档齐全、账号规范、人员变动有交接——任何新工程师接手都能在 2 周内上手。期间客户业务涨了 3 倍——系统跟着长没掉过链子。客户续约 5 次、每次主动加价——因为他们知道换供应商的成本比加价高。客户给原供应商介绍了 4 个同行——因为客户知道你靠谱、愿意主动帮你背书。原供应商团队越做越稳——客户资产越积越多工程师越干越有积累。这三种结局差距大到你可以量。第一种客户的 5 年总成本 重做系统的成本 5 个月业务中断的损失。第二种客户的 5 年总成本 6 个月考古的时间成本 3 次大问题的客诉损失 续约砍价的差额。第三种客户的 5 年续费 原价 × 5 4 个新客户的合同。你愿意做哪种我每次跟新人讲项目的时候都会问他们一句话——“你想做一次性交付的乙方还是想做客户数字化生活的合作方”前者挣的是一次性的钱。后者挣的是长期的钱、客户口碑的钱、团队积累的钱。后者值钱一百倍。我不是说前者不该做——有些项目天然就是一次性的做完就完事。但你交付完之后留下的资产——文档、决策记录、账号权限、人员交接、运维体系——这些东西才是你下一次还能接到项目的根本。不是价格低不是技术牛不是 PPT 漂亮。是客户出事那天能 5 分钟找到你。这件事儿只有体系能保证。七、写在最后讲到这里我想把这一篇收一收。你搬进新家第一件事是请朋友来开 party不是。你搬进新家的第一件事不是摆家具放照片也不是叫朋友来聚会——而是找到一个靠谱的物业把自己的长期居住交给他们。不是盼着出事是出事那天有人接电话、有人处理、有人能 5 分钟响应、有人能查到当时的决策、有人能在新人接手时无缝衔接。长期陪客户过日子这件事儿不是有个工程师靠谱就能解决。是有一套体系把这件事长期做下去。我把这篇的核心凝练成几句话你记一辈子——系统上线不是终点是陪客户过日子的起点。交付的不是今天的软件是客户未来五年都能继续走下去的能力。客户要的不是今天跑得漂亮是出事那天能找到人。一次性交付像租房长期运维像买房。靠谱的物业不是某个保安特别靠谱——是体系让任何一班保安都靠谱。长期陪客户不是留一两个人救火——是把这件事做成不依赖任何一个人的工程。很多人以为长期陪客户是签长合同“留人救火”“多签几年”——其实不是。长期陪客户是搭一套体系——运维体系、文档体系、账号体系、人员体系——让客户的事能长期、稳定、不依赖任何人地继续走下去。光知道要长期陪还不够。怎么搭运维体系怎么管文档怎么管账号怎么管团队人员变动怎么让响应有 SLA怎么让决策有记录怎么让新人 2 周能上手——是有章法的。下篇卷袖子干活——四套体系运维、文档、账号、人员加五道闸SLA / 决策记录 / 凭据管理 / 变更交接 / 持续改进把长期陪客户过日子做成不依赖任何一个人的工程。我给你讲 SLA 怎么定、文档怎么管、账号怎么标准化、交接怎么做、持续改进怎么落到日常动作里。读完这一篇你知道为什么要长期陪客户。读完下篇你会知道长期陪客户怎么做到不依赖任何一个人。我们下篇见。关于 ArchAIHarness这篇文章是「看懂 AI 与智能体」专栏的一部分由ArchAIHarness持续输出。ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产主张架构师定义秩序AI 在秩序中生长。人立法AI 执行体系审计。如果你也希望 AI 在明确的架构边界内协作而不是在混沌中碰运气欢迎到 GitHub 上看看我们在做什么组织主页github.com/ArchAIHarness — 了解完整理念与资产全景本专栏zhuanlan-ai-and-agents— 所有文章的源码与发布记录实践指南docs— 架构哲学、工程方法和落地指南开源工具agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools工程样例framework— DDD AI 协作的工程底座展示如何在开发中融合 AIEngineered by Architects · Empowered by AI · Audited by Discipline
系统上线不是终点，是起点——长期陪客户过日子比一次性交付值钱一百倍
凌晨一点十七分。我手机屏幕亮了微信弹出来一条“魏老师我们系统又出问题了能不能帮忙看一下上次那个事之后我们一直在找你团队找不到……”发消息的是某连锁客户的 IT 负责人老周。他说的上次那个事是 14 个月前我带队给客户做的数字中台上线——上线当天跑得挺漂亮文档也交了培训也做了。14 个月过去了。客户业务量翻了一倍系统也跟着跑了一年多。现在凌晨一点出了问题他们打开后台准备排查发现——接手的工程师小李上个月已经离职了。仓库的 README 还写着三年前的部署命令跑一半报错。生产环境的账号密码存在前同事的私人备忘录里前同事手机换了号联系不上。决策档案上写着为什么这么选——但那条理由是某个会议上某位前 CTO 口头说的一句话没落进任何文档。老周翻遍客户的微信群、邮箱、文档库、SVN 历史——能找到的知情人要么早就离开项目要么根本不在客户现场。他最后只能回到微信上找到我。我心里咯噔一下——不是我不想帮是这套系统的代码我 14 个月前就交接给客户了工程师换了两拨关键决策没文档我今天再看代码我也要重新捋一遍。那一晚我花到凌晨四点帮他定位了一个很简单的内存泄漏问题——一个参数判断写反了。如果是当时的工程师在这个 bug 5 分钟就能定位。我用了 3 小时。我躺在床上翻来覆去想——系统上线那天我们做了一个看起来很漂亮的交付。但 14 个月后客户半夜出事找不到一个能 5 分钟解决问题的人。我们交付的是软件吗是。我们交付的是客户能用起来的能力吗不是。这件事儿值得我写一写。这一篇我想跟你聊聊长期陪客户过日子这件事。一次性交付不是终点——是陪客户过日子的起点。一、为什么交付完了就失联是定时炸弹我做过这么多年工程师、见过这么多项目之后回头看发现绝大多数交付完就失联的项目都有同样的剧本。剧本第一章交付那天一切都很完美。PPT 漂亮、PPT 上写的功能都跑通了、PPT 上写的 KPI 都达标了、客户在大会上讲了一段感谢的话、你的老板把你的名字写进了 OKR 总结——剧本第二章交付后 3-6 个月团队开始散。项目结了。工程师被调到下一个客户、做下一个项目。文档没人更新。代码没人 review。生产环境的运维账号没移交。客户业务在长代码在沉睡——3 个月没改过一行。剧本第三章交付后 12-18 个月定时炸弹响。客户的业务发生了变化、流量涨了三倍、出现了新的合规要求、某个依赖的第三方服务下线——任何一个变化都可能让系统出问题。客户半夜打电话找你——你团队的工程师已经换了两拨人。仓库的代码看着像别人写的。文档里写的是三年前的部署命令。生产环境的运维账号在某个前同事私人备忘录里前同事已经离职。客户当时拍板的决策理由在某个会议上口头讲过没落进任何文档。这时候你发现你交付的不是一套客户能用的系统是一颗客户在某个时间点一定会被引爆的定时炸弹。这不是我编的。我去查了一下行业里的真实事件——案例一某大型零售客户的电商系统2019 年由一家外包公司交付。2021 年客户要做双十一大促前的扩容改造找原班人马——3 个核心工程师全部离职文档全部过期账号密码失效。最后客户花了 8 周时间考古从 SVN 历史、聊天记录、邮件里拼凑出当时的决策才算把系统摸清。8 周。一个项目就这样被考古了 8 周。案例二某金融客户的理财系统2020 年交付。2022 年合规检查要求整改加密算法。原班工程师 2 人离职、1 人转岗、1 人创业。客户找到原外包公司原外包公司说这是新需求要重新立项。重新立项——意味着客户要重新付一遍钱、走一遍流程、等几个月。案例三某 SaaS 平台的内部管理系统2021 年交付。2023 年核心数据库服务器硬件老化要换机。客户运维发现原来的部署文档是 2020 年写的那时候用的是 Docker 18.x现在 Docker 都 25.x 了命令完全对不上。这三件事儿听起来扎心但它们每天都在发生。我敢说一句话——99% 的一次性交付项目交付后 18 个月内都会出现客户想找你团队却找不到的尴尬。这话听着绝对。但你听我讲完下面两个真相你会觉得我客气了。真相一交付完团队散了文档留不住任何决策的为什么。代码能留住做了什么但留不住为什么这么做。为什么这么选 PostgreSQL 不选 MySQL为什么这个接口用同步不用异步为什么这个参数默认是 5 不是 10这些为什么如果只在某次会议上口头讲过、没落进文档——半年后没人能答上来。新人接手只能猜。猜错了系统出事。真相二交付完账号密码和运维凭据不标准化移交下次出事没人能进系统。很多团队的运维账号是谁在现场就给谁开一个从来没想过半年后换人了这个账号怎么办。结果就是——生产环境账号在某个前同事私人备忘录里前同事离职手机换号新人进不去系统。出事那天的真实故事都是这两件事的变种。交付完了就失联——不是客户的问题是你交付模式的问题。你交付的是今天能跑起来的代码不是客户未来五年都能继续走下去的能力。这两件事儿从来不是一回事。我接客户这种电话接多了慢慢发现一件事——所有客户出事那天找过来的真实需求都可以剥成三件出事能找到人、能查到当时的决策、能基于现状继续演进而不用推倒重来。这三件事儿听着简单做起来难。为什么难因为这三件事儿都需要事前的工程纪律——不是你出事那天临时抱佛脚能解决的。你出事那天临时建一个找人的机制——来不及。你出事那天临时写一份 ADR 记录决策——来不及。你出事那天临时做一份接手手册——更来不及。这三件事儿都得在交付之前就准备好。出事那天能 5 分钟找到人——是因为你平时就把 SLA、oncall、应急流程做好了。出事那天能查到决策——是因为你平时就把 ADR、变更记录、决策档案做好了。出事那天新人能接手——是因为你平时就把 onboarding、交接清单、账号权限做好了。这三件事儿的共同点——都是事前功夫。事前功夫的特点是——没事的时候你觉得多此一举有事的时候你才知道救你命。这件事儿怎么落是下篇的重点。我们这一篇先把为什么讲透。二、剥客户的三个真需求——交付之后客户真正要的是什么我接客户深夜电话时从来不听他们说我们想要一个系统或者我们付了钱你们应该管到底。我听三件事——真需求一出事那天能找到人。“我们半夜系统挂了能不能有个人接电话”“我们想做个新功能找不到懂这套代码的人。”“我们的数据库要扩容谁能帮忙看看”这三个问题翻译过来都是同一句话——出事那天能找到一个懂这套系统的人。很多客户嘴上不说但心里一直在担心这个。他们不是想要你包一辈子他们想要出事那天能找到人。能 5 分钟响应 vs 24 小时响应差别巨大。能 5 分钟响应的人不是临时去找的——是你长期培养的。你平时不在客户现场、出事那天才派人过去等工程师赶到现场、黄花菜都凉了。真需求二能查到当时的决策原因。“为什么这个接口这么设计”“为什么当初选 PostgreSQL 不选 MySQL”“为什么这个参数默认是 5 不是 10”这三个问题翻译过来都是同一句话——能查到当时为什么这么决定。这不是为什么这么做是当时为什么这么选。这两个问题答案不一样。“为什么这么做”——看代码能知道。“当时为什么这么选”——看代码不知道得有决策记录。决策记录不是代码注释。决策记录是 ADRArchitecture Decision Record——一份单独的文件专门记录为什么这么选、当时考虑过哪些方案、为什么放弃这些方案。很多团队交付完没留 ADR。客户想改一个参数都怕改错了——因为不知道当初为什么这么设。真需求三能基于现状继续演进而不是推倒重来。“我们业务涨了三倍这套系统能不能继续撑”“我们要上新业务能不能基于这套系统改”“我们的合规要求变了能不能快速调整”这三个问题翻译过来都是同一句话——系统能跟着业务一起长。能跟着业务一起长的系统跟今天能跑的系统是两回事。能跟着业务一起长的系统——代码分层清晰、文档齐全、测试覆盖、模块边界明确新人能快速上手能基于现有能力迭代。今天能跑的系统——代码一团糊、文档不全、测试缺失、模块边界模糊新人只能考古式摸代码。这三个真需求翻译成一句人话客户买的不只是今天的系统是未来五年都能继续走下去的承诺。你能给客户的不是上线那天跑得漂亮是上线之后也能一直有人懂、能改、能撑。这件事儿不是某一个工程师靠谱就能解决的——是一套体系才能解决。你听过卖软件和卖服务这两个说法吧这两个说法都不够准确。更准确的说法是——“卖代码和卖能力”。卖代码——你交付的是字节、是功能、是 API。客户拿走这些字节之后爱怎么用怎么用跟你没关系。卖能力——你交付的是客户未来五年都能继续走下去的能力。客户拿走这些能力之后能不能用、好不好用跟你一直有关系。前者是一锤子买卖后者是长期陪跑。我每次给老板讲这个比喻的时候他们都会问一句“卖能力是不是成本更高”成本更高——但客户愿意付的钱也更多。卖代码的客户跟你谈价格。卖能力的客户跟你谈长期价值。这两种客户你愿意接哪种三、一次性交付像租房长期运维像买房我给客户讲长期运维的时候从不用长期合作“持续服务”客户成功这些商务黑话开场。我用的是一个生活化比喻——一次性交付像租房。长期运维像买房。租房是什么体验你付了房租住在房子里。房东给你配了基本家具——床、桌子、椅子。你住了一年两年灯泡坏了房东不一定会来修水管漏了房东可能让你自己掏钱修。租客跟房东之间是短期交易关系——你付钱我给你住租约到期就各走各的。买房是什么体验你付了首付、还了贷款住进了自己的房子。小区的物业会一直陪着你——电梯坏了物业协调维修、楼道灯不亮物业派人换、停车位纠纷物业来调解、节假日物业送温暖。业主跟物业之间是长期共生关系——你住多久物业陪多久。你会发现一个很微妙的事情——租客跟房东之间没有任何长期承诺。灯泡坏了你不修下次房东也不一定让你续约。搬家时房东不关心你下一站去哪。业主跟物业之间有日常关怀也有长期陪伴。灯泡坏了物业不管下个季度业委会就不续约了。搬不搬物业都关心你这户——因为你是长期的客户。这两个模式本质差别在于长期承诺是否存在。把这件事映射到我们做项目的场景——一次性交付 租房模式。项目交付那天是个时间点。时间点之前你是乙方时间点之后你变成前任乙方。客户的系统出事了你能帮就帮、不能帮也行——反正合约已经结束。长期运维 买房模式。项目交付那天是个起点。起点之后你是长期陪客户走下去的乙方。客户的系统出事了你得接——因为你跟客户签的不是一次性合同是长期居住合同。这两种模式对客户的价值差距巨大。租房模式——客户付了一次钱得到的是今天的系统。明天系统出事了找不到人下个月想改个功能找不到人半年后业务变了找不到人。买房模式——客户付了同样的钱甚至更少得到的是未来五年都能继续走下去的能力。明天出事能找到人下个月想改能找到人半年后业务变了还能继续改。对客户来说五年都能继续走下去比今天上线跑得漂亮值钱一百倍。为什么因为今天跑得漂亮是结果五年走下去是能力。结果是有限游戏能力是无限游戏。客户买的是能力不是结果。你只交付结果客户的系统在某个时间点一定会塌——因为没人能继续往上盖。你交付能力客户的系统能在未来五年里继续演化——因为有人一直在陪着往上盖。这两种交付模式我把它叫——交付软件和交付生活方式的差别。听起来很玄翻译成人话——你交付的是一套代码你做的是卖软件。你交付的是客户未来五年都能持续走下去的能力你做的是成为客户数字化生活的一部分。哪个值钱你愿意买哪个我之前给一个老板讲这个比喻他听完了沉默很久跟我说了一句话——“魏老师我做了 15 年软件从来没听人这么讲过。我之前一直以为我卖的是软件听你这么一说我才发现我卖的是客户未来 5 年的命。”我笑了。其实不是卖命——是陪客户过日子。你愿意做哪种乙方一次性交付的乙方——客户付你一次钱你给客户一套代码。从此客户的事跟你无关。长期陪客户的乙方——客户付你同样的钱你给客户未来五年都能继续走下去的能力。从此客户的事跟你一直有关。这两种乙方你愿意做哪种我敢说一句话——长期陪客户的乙方比一次性交付的乙方值钱一百倍。为什么因为一次性交付的乙方每做一单都要从零开始找客户、谈价格、做交付、收尾款。下一年还要重新找客户。长期陪客户的乙方做一单留下一个长期付费的客户、做两单留下两个、做三单留下三个——客户越来越多续约越来越多团队的资产越来越多。前者是猎人模式——每打一枪都要重新瞄准。后者是农夫模式——种下一棵果树每年都结果。这两种模式5 年后的差距你能算出来。猎人 5 年打 10 枪每枪 100 万 总收入 1000 万。农夫 5 年种 10 棵树每棵树每年结果 50 万 第 5 年总收入 2500 万且还在涨。你愿意做猎人还是农夫我见过太多做猎人转农夫的团队——他们转型的那 1-2 年最难但熬过去之后就是完全不同的收入曲线。农夫模式的护城河是客户信任——你陪客户越久客户越信任你客户越信任你越离不开你。猎人模式的护城河是价格优势——你价格越低客户越多客户越多你越累。这两种护城河的差距——前者是滚雪球后者是滚石头。四、一次性交付和长期陪客户的团队差距我见过的团队大致可以分成三种。第一种交付完就撤的团队。交付那天 PPT 漂亮、客户签字、尾款收回。然后工程师调走文档归档账号保留。这种团队做的事儿本质上是卖软件。客户半年后想改个东西找不到人。客户一年后系统扩容找不到人。客户两年后业务转型找不到人。客户每一次遇到想继续往前的时刻都得考古式从头来过。这种团队的结局——客户下次有项目不会再找你。你的口碑只在这一个客户身上有效传不出去。你团队的工程师一直在做一次性交付永远在交付新项目永远在从零开始没积累。人效上不去。第二种交付完有运维但没体系的团队。交付那天 PPT 漂亮、客户签字、尾款收回。然后团队留 1-2 个工程师做运维——客户有问题时救火没事时闲着。这种团队做的事儿本质上是卖软件 卖售后。客户有事能找到人——但这个人可能今天在处理另一个客户的事、明天在休假、后天换了岗。客户的体验是有事能找到人但响应不及时、解决问题不彻底。这种团队的结局——客户续约率比第一种高但工程师流失率高——因为天天救火没成长、工资涨幅低、有能力的工程师都走了。留下来的工程师越做越累、能力越来越窄、最后也走了。你团队的运维工程师是个消耗性岗位。口碑有但仅限于我们有事能找到人——不够深。第三种长期陪客户过日子、把运维做成不依赖任何一个人的体系的团队。交付那天 PPT 漂亮、客户签字、尾款收回。然后团队按体系长期陪客户——SLA 写明白 5 分钟响应、2 小时定位、4 小时修复。文档和决策记录留在客户能访问的地方——不是团队的私人备忘录。账号密码走权限管理——不依赖任何一个人的私人笔记本。人员变动有交接流程——交接人清楚接手人能从哪里继续。这种团队做的事儿本质上是成为客户数字化生活的一部分。客户有事第一时间找你——不是因为合同是因为找你最稳。客户想改个东西第一时间找你——不是因为价格是因为你能改对。客户业务变化第一时间找你——不是因为历史是因为你最懂我们的系统。这种团队的结局——客户续约率高——不是 60%、70%是 90%。客户口碑推荐多——客户愿意主动介绍给同行因为他知道找你最稳。团队能沉淀资产——客户的系统越做越深、资产越积越多新工程师来了能复用前人的工作。人效高——不需要每次交付都重新搭一遍工程师是在客户系统上做长期建设不是每次从零开始。这三种团队三年后的状态天差地别。第一种的三年后还在做一次性交付工程师来来去去团队规模上不去。第二种的三年后运维工程师累垮了剩下的工程师要么跑路要么躺平续约率开始下降。第三种的三年后客户越积越多、团队越做越稳、工程师越干越有积累形成正向循环。哪种团队你想做我说句扎心的话——大部分团队是第一种或第二种。他们不是不知道要长期陪客户——他们以为自己在长期陪。他们不知道的是长期陪客户这件事工程纪律要求比你以为的严格得多。长期陪客户不是留 1-2 个工程师救火——是用一套不依赖任何一个人的体系把客户长期陪好。我把这个不依赖任何一个人展开讲讲——不依赖某个特别靠谱的工程师——就算小张今天不在、出差、休假、生病、离职客户的响应不变。不依赖某个特别贴心的客户成功经理——就算小李今天不在、轮岗、调走客户的日常沟通不变。不依赖某个特别勤快的项目经理——就算小王今天不在、培训、休假、晋升客户的进度同步不变。体系化的团队是任何一个人离队都能继续运转的团队。非体系化的团队是任何核心离队都可能塌方的团队。我跟你讲一句扎心的话——90% 的团队是非体系化的团队。他们以为自己在陪客户其实是靠小张撑着的团队。小张在的 3 年客户满意、团队稳定、收入增长。小张走的第 1 年客户投诉、团队动荡、收入下滑。小张走的第 2 年客户流失、口碑崩盘、团队重组。3 年的努力被小张的离职清零了。你愿意做这种团队吗反正我不敢。这件事儿怎么落到工程上——是下篇的核心。五、长期陪客户的本质——不是卖软件是成为客户数字化生活的一部分很多老板把长期陪客户理解成多签几年合同——这是错的。合同签得再长团队散了、文档没了、账号失效了合同也救不了客户。合同是纸。纸救不了客户出事那天的事。真正能救客户的是一套不依赖任何一个人的体系。我给客户讲这套体系的时候用一个比喻——长期陪客户不是签一份长合同是请一个靠谱的物业。你买了一套房签的是购房合同。合同签完房子是你的。但你住进去以后你会发现——房子不会自己修电梯、不会自己通下水道、不会自己换灯泡、不会自己管停车。你需要一个靠谱的物业长期陪着。靠谱的物业长什么样1. 24 小时有人接电话——出事那天的第一道闸。半夜电梯困人你打电话物业有人接。物业不管能不能修至少有人接电话、有人安排人过去。长期陪客户的团队也是一样——出事那天有人接电话、有人能响应。不是事后诸葛亮是事先有 SLA、有 oncall 轮值、有应急流程。2. 小区的图纸资料随时能查到——决策记录的存档。你家要改个水管走向物业能调出你家的水电图纸。你家要装个空调外机物业能告诉你哪面墙能打孔、哪面墙不能动。长期陪客户的团队也是一样——客户想改个参数、想加个功能能查到当时的决策记录——为什么这么设计、为什么这么选、当时考虑过哪些方案。不是拍脑袋改——是按之前的决策脉络继续演化。3. 小区的门禁钥匙不绑定个人——账号权限的标准化。物业的钥匙在物业经理手里不在某个保安私人手里。保安换班钥匙还在——因为钥匙是公家的。长期陪客户的团队也是一样——生产环境账号在权限管理系统里不在某个工程师私人备忘录里。工程师离职账号注销、权限交接——新人来了能接手。4. 保安换班有交接本——人员变动的交接。物业保安 24 小时三班倒但每个班次都有交接本——上一班发生了什么、谁处理了、有什么遗留。长期陪客户的团队也是一样——工程师换岗、离职、新人接手都有交接流程。不是口口相传、不是找那个前同事问问是写在文档里的标准动作。5. 物业每月上门问有什么需要修的——持续改进的回访。靠谱的物业不只是等业主报修——他们会主动问最近有什么不顺手的地方、“有没有什么可以优化的地方”。长期陪客户的团队也是一样——不是等客户提需求才行动是定期回访、定期优化、定期把行业里新出现的好做法同步给客户。你看靠谱的物业做的事儿本质上是——用一套不依赖任何一个人的体系把小区的日常运维做好。不是某个保安特别靠谱——是物业的体系让任何一班保安都靠谱。你愿意找哪种物业找一个今天值班的小张特别靠谱但他明天就不在了的物业还是找一个不管今天值班的是谁体系都能保证响应的物业答案不言自明。把这件事映射到我们做项目——客户要的不是今天接电话的小李特别靠谱是不管今天接电话的是谁体系都能保证响应。这才是长期陪客户的本质——不是某个工程师特别靠谱是一套不依赖任何个人的体系把这件事长期做好。这件事儿听起来抽象落实到工程上是一整套具体的体系——运维体系——出事有 SLA、有 oncall、有应急流程。文档体系——决策有 ADR、变更记录在版本控制里、知识有索引。账号体系——生产账号在权限管理、不在私人备忘录、人员变动有交接。人员体系——换岗有交接流程、接手有手册、新人有 onboarding。四套体系 五道闸持续改进、变更管理、事件响应、问题管理、发布管理。这套体系怎么搭、怎么运转、怎么一步步落地——是下篇卷袖子干活的部分。这一篇先把为什么要长期陪客户的心智讲透。我跟你讲讲靠谱物业这个比喻在我心里的形成过程——2018 年我第一次搬进自己的房子签购房合同的时候很开心。住进去的第一周我就发现——电梯坏了没人修、楼道灯不亮没人换、停车位纠纷没人管。我去找物业物业经理跟我说“我们正在跟进。”我等了 3 天没人跟进。我又去找物业经理说“您这个事儿我们排在下周。”我又等了 1 周还是没人跟进。最后我自己掏钱请了个电工修了楼道灯、自己去找业委会反映了电梯问题、自己跟邻居协商了停车位。3 件本该物业做的事儿我自己做了。那一刻我突然理解了一件事——物业不是有就行是靠谱才行。乙方也不是有就行是靠谱才行。有物业的小区多了去了——大部分业主跟物业之间是互相不信任。靠谱的物业才是小区业主真正想要的——业主愿意续约、愿意推荐、愿意在物业群里帮忙说好话。靠谱的物业做的事儿本质上跟你长期陪客户做的事儿一模一样。都是用一套不依赖任何一个人的体系把日常运维做好。都是不管今天值班的是谁都能保证响应。都是在客户出事那天的 5 分钟内有人接、有人来、有人处理。这件事儿落到工程上是四套体系加五道闸的具体工程纪律。但这一切的为什么是为了把客户变成你长期的合作伙伴而不是一次性交易的对手。六、五种结局——一次性交付和长期运维的真实差距我见过太多项目看完三种团队再看五年后他们的结局差距大到你不敢信。第一种交付完就走的项目5 年后的结局——客户的系统在第 18 个月出了第一次大问题找不到原班人马。客户花了 8 周考古代码、3 个月才把系统重新摸清。这 5 个月里客户流失了一批——因为系统不稳定、新功能出不来。最终客户决定重做系统——找另一家外包公司从头搭。原外包公司——失去这个客户、失去这个客户的口碑推荐、未来 3 年也没接到这个客户介绍过来的新客户。第二种有售后没体系的客户5 年后的结局——客户的系统稳定运行了 3 年期间工程师小张救了 100 次火。第 4 年小张离职了——新接手的工程师小王发现所有隐性知识都在小张脑子里。小王用 6 个月时间考古——最后只恢复了 60% 的知识剩下 40% 跟着小张走了。这 6 个月里客户系统出了 3 次大问题——响应不及时客户投诉了两次。第 4 年底客户续约时砍价 40%——“反正你们的服务质量在下降”。第 5 年客户决定换供应商——因为续约价格和服务质量都不满意。第三种长期陪客户把运维做成体系的客户5 年后的结局——客户的系统稳定运行了 5 年期间体系自动响应了无数次问题。SLA 写明白、文档齐全、账号规范、人员变动有交接——任何新工程师接手都能在 2 周内上手。期间客户业务涨了 3 倍——系统跟着长没掉过链子。客户续约 5 次、每次主动加价——因为他们知道换供应商的成本比加价高。客户给原供应商介绍了 4 个同行——因为客户知道你靠谱、愿意主动帮你背书。原供应商团队越做越稳——客户资产越积越多工程师越干越有积累。这三种结局差距大到你可以量。第一种客户的 5 年总成本 重做系统的成本 5 个月业务中断的损失。第二种客户的 5 年总成本 6 个月考古的时间成本 3 次大问题的客诉损失 续约砍价的差额。第三种客户的 5 年续费 原价 × 5 4 个新客户的合同。你愿意做哪种我每次跟新人讲项目的时候都会问他们一句话——“你想做一次性交付的乙方还是想做客户数字化生活的合作方”前者挣的是一次性的钱。后者挣的是长期的钱、客户口碑的钱、团队积累的钱。后者值钱一百倍。我不是说前者不该做——有些项目天然就是一次性的做完就完事。但你交付完之后留下的资产——文档、决策记录、账号权限、人员交接、运维体系——这些东西才是你下一次还能接到项目的根本。不是价格低不是技术牛不是 PPT 漂亮。是客户出事那天能 5 分钟找到你。这件事儿只有体系能保证。七、写在最后讲到这里我想把这一篇收一收。你搬进新家第一件事是请朋友来开 party不是。你搬进新家的第一件事不是摆家具放照片也不是叫朋友来聚会——而是找到一个靠谱的物业把自己的长期居住交给他们。不是盼着出事是出事那天有人接电话、有人处理、有人能 5 分钟响应、有人能查到当时的决策、有人能在新人接手时无缝衔接。长期陪客户过日子这件事儿不是有个工程师靠谱就能解决。是有一套体系把这件事长期做下去。我把这篇的核心凝练成几句话你记一辈子——系统上线不是终点是陪客户过日子的起点。交付的不是今天的软件是客户未来五年都能继续走下去的能力。客户要的不是今天跑得漂亮是出事那天能找到人。一次性交付像租房长期运维像买房。靠谱的物业不是某个保安特别靠谱——是体系让任何一班保安都靠谱。长期陪客户不是留一两个人救火——是把这件事做成不依赖任何一个人的工程。很多人以为长期陪客户是签长合同“留人救火”“多签几年”——其实不是。长期陪客户是搭一套体系——运维体系、文档体系、账号体系、人员体系——让客户的事能长期、稳定、不依赖任何人地继续走下去。光知道要长期陪还不够。怎么搭运维体系怎么管文档怎么管账号怎么管团队人员变动怎么让响应有 SLA怎么让决策有记录怎么让新人 2 周能上手——是有章法的。下篇卷袖子干活——四套体系运维、文档、账号、人员加五道闸SLA / 决策记录 / 凭据管理 / 变更交接 / 持续改进把长期陪客户过日子做成不依赖任何一个人的工程。我给你讲 SLA 怎么定、文档怎么管、账号怎么标准化、交接怎么做、持续改进怎么落到日常动作里。读完这一篇你知道为什么要长期陪客户。读完下篇你会知道长期陪客户怎么做到不依赖任何一个人。我们下篇见。关于 ArchAIHarness这篇文章是「看懂 AI 与智能体」专栏的一部分由ArchAIHarness持续输出。ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产主张架构师定义秩序AI 在秩序中生长。人立法AI 执行体系审计。如果你也希望 AI 在明确的架构边界内协作而不是在混沌中碰运气欢迎到 GitHub 上看看我们在做什么组织主页github.com/ArchAIHarness — 了解完整理念与资产全景本专栏zhuanlan-ai-and-agents— 所有文章的源码与发布记录实践指南docs— 架构哲学、工程方法和落地指南开源工具agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools工程样例framework— DDD AI 协作的工程底座展示如何在开发中融合 AIEngineered by Architects · Empowered by AI · Audited by Discipline
