以下文章来源于头哥侃码，作者王晔倞
这是写给我现公司「客户成功团队」的一封信。
为什么写？是不是心血来潮？不，你猜错了。熟悉我的朋友都知道，我是个直肠子，不仅喜欢说真话，而且不喜欢在别人背后说三道四，所以还是选择写出来比较痛快。写在最前
为了您能看得明白，我能说得清楚，所以在开始之前我还是先来做一个简短的介绍。
我现在投身的这家公司 —— 「深圳支流科技」，它是一家提供 API 处理和分析的开源基础软件公司，提供 API 网关、k8s ingress controller、Service Mesh 等微服务和实时流量处理的产品和解决方案。致力为全球企业管理并可视化 API 和微服务等关键业务流量，通过大数据和人工智能（AI）加速企业业务决策，驱动数字化转型。
大家比较熟悉的Apache APISIX 就是2019年由支流科技捐赠给 Apache 软件基金会，并在9个月之后成 顶级项目的。
怎么样？是不是有那么一瞬间感觉还挺酷的？不，请你醒一醒，别被一些表面现象蒙蔽双眼。在我的经历中，ToB 和 ToC 的逻辑是有本质区别的。在 ToC 领域，技术团队本身也是用户之一，我们开发的功能自己就在使用，我们清楚的知道用户需求，不仅用户的决策链较短，而且绝大多数的矛盾都是内部矛盾，但是 ToB 就完全不同了，我们不是最终的使用者，用户的需求经过层层传递就会失真，用户的反馈周期也很长。更重要的是，ToB 是一个复杂的决策链：工程师、研发经理、CTO、采购、商务、CEO等，都可能影响最终的成单。另外，销售也只是表面，能够和客户深入得交流，理解客户的本质需求才是 toB 企业能够赢得客户的关键。在这一年里，我发现我们公司的绝大部分同事似乎并不明白上面这些道理，不仅都没有做过 toB 的业务，而且还缺乏基本的企业服务意识。
我是去年4月入职的，因为战略的需要，所以我把大部分精力都用在了开源布道、社区运营上。
春节后，因为战略的调整，我们把 「企业版」和「开源商业化支持」两个团队合并为 「客户成功团队」。
这个团队要做的就是让客户通过使用我们的产品吃到甜头，并让他们期待继续、续费吃到新的甜头，并从售前、技术、支持、交付等全流程的角度提升对客户的服务质量、获客和转换能力。
从存在价值角度，客户成功团队工作内容的本质就是帮助公司在客户使用产品的全生命周期管理客户期望。
我临危受命，被推上了总负责人的位置。
一转眼，我加入客户成功团队已有两周的时间了。
“感觉如何？心情如何？下一步打算怎么走？累吗？”……不瞒大家，这是近几天被提及最多的问题，有些是我媳妇问的，有些是两位创始人问的，也有些是团队小伙伴问我的。
说实话，这两周的心情像过山车一样，高低起伏，五味俱全，有很多话憋在心里挺不是滋味。
有人说，写信是最好的交流感情、心得、见解、的绝佳手段，更是人与人之间感情寄托的最好摇篮。
有道理，静下心来，写一写，与大家说一说吧。
---------我是分割线，以下是邮件正文---------
大家好：
我是王晔倞，很高兴有机会能与大家一起并肩作战。近一个月以来，我一直想和大家聊下，但又不知道说什么，这周我利用了一些业余时间写下了这封邮件，想把内心深处的一些思考晒出来想与大家简单聊一聊、唠一唠。▌外部环境的剧烈变化虽然我们在 2021 年从 8 位同事增长到现在的接近 50 人，并且开源与商业化均在中国赢得了非常广泛的使用，但进入 2022 年之后，外部环境就开始进入一轮又一轮的变化。比如俄罗斯和乌克兰发生了热战，比如美国证券交易委员会(SEC) 根据《外国公司问责法》把 5 家中概股列入识别清单，再加上疫情反复的冲击，迫使我们把各种线下交流改为线上。说到这，或许你会觉得 “我们的业务又不受这些宏观环境的直接影响，管我们屁事？”
不，你这样想可就错了。
美国是不是对俄罗斯的制裁再升级了？不仅采取 “切断SWIFT、停止 IOE(IBM、Oracle、EMC) 的销售和支持”，而且还没收了一些企业的海外资产……设想一下，如果某一天美国用相同的手段砸向中国呢？那么我们这些靠美元基金投资活着的公司，下一步该何去何从？如果中国的公司不能再去美国上市，风险投资要怎么退出？什么？你说我在杞人忧天？这是小概率事件？中国有句古话，“做最坏的打算，往最好的方向努力”。如果中国的风险投资将进入寒冬，如果中国的基础软件、硬科技等需要资本长期支持的创业公司批量死亡，那该怎么办？不给你发工资，你拿什么来填饱肚子？我拿什么来给你买下午茶？还是现实一点比较好，您说呢？▌内部问题的若隐若现熟悉我的朋友都知道，我有两句话常挂在嘴边，第一句是 “主观决定方向，客观决定成败”，第二句是 “不想认命，就要拼命，但除了努力，我们别无选择”。这啥意思？很简单，少怨天怨地，不要回避，定好战略，确定目标，埋头干就行了。大家都知道，无论是商业软件还是基础软件，一款软件的开发不仅需要越来越多的人员加入，而且还需要不同岗位的人员相互配合才能够完成。我常说，如果把 “完成一款软件” 看成是 “打赢一场王者荣耀” 的话，那么每位小伙伴都应在对战中都找到自己的定位（比如近战、远程、恢复与法师等）。那么问题来了，如果你是客户成功团队的一员，那么请思考以下几个问题：
- 你的职责是什么？（什么归我管，什么不归我管）
- 你的核心战略是什么？（指哪打哪？打哪指哪？）
- 你对团队的价值是什么？（为什么团队需要你？）
- 你的客户是谁？（在工作流程中，谁在依赖你？你又依赖谁？）
- 我们的商业客户究竟在为什么付费？（节奏？技术？产品？）
……
总体来说，我当下看到的可以概括为 “目标与职责含糊不清、规则混乱、反馈缺乏、被动执行”，下一步我们应该 “改革” 的内容有以下几点。
第一、既不做外包，更不做项目，产品化是唯一出路
2019年，我曾在自己的公众号发布过一篇文章，其中有这样一段话。
……
如果撇开纯做 “劳工” 输出的外包公司，或者有后台背景的机构，除非产品化转型成功，那些做项目的，尤其是那些曾对客户信誓旦旦保障 “你说什么，我都能实现” 的软件公司，几乎全死了，而且死相还挺难看的。
为什么这么说呢？有句话说得好，能靠堆机器突破的瓶颈，通常都不是瓶颈，能用钱解决的问题，几乎都不是问题，但可悲的是没机器、没钱。在我已知的范围里，假如你不惜成本，基本没有招不到的人，也没有解决不了的技术问题，但这是伪命题，无论是互联网公司，还是软件公司，在技术上都是成本驱动，任何技术研发的投入必须对业务产生正向收益，反之，投入和收益一旦产生逆差，这场戏就很难唱的下去了。
……
这段话啥意思？说明了什么？在我看来，支流科技与国内大部分的基础软件公司差不多，基本都是从1-2个 Classic case 开始迈入商业化赛道的，所以刚开始的时候，无论项目的规模还是功能的复杂度都不大，所以依赖某几位高手（或创始人）就能够在客户适度满意的状态下成功完成项目，但随着时间的推移，企业承接的项目多了，人员多了，企业规模也扩大了。到这时候，任何一家企业的内外部环境都已经发生了很大的变化。从我们企业内部状况来看：
- 如果我们同时运作的商业项目数量增多，但依赖于 “一两个高手” 的项目模式没有改变。各项目都需要高手来保障，如果没有高手，项目就停滞不前（或者被客户直接终止），而且往往以非正常手段结束。
- 随着软件项目的深入展开或软件的升级换代，企业会发现有些模块的开发总是在重重复复地做，上一个版本做了，这个版本还要继续做，同时开展几个项目，都有类似的事情在重复做。但要直接使用之前的内容，又不行。
- 技术人员总是有很多理由不去写文档，如果不是一个人将一个模块从分析设计负责到代码，后一个环节的人总是得意于自我创新，并容易发生设计人员和开发人员的扯皮。
- 软件项目在前期开发时候是一路凯歌，到了快要交付的时候，却又难产，总是达不到要求，改改代码重新测试，没完没了。而技术人员又非常辛苦。甚至出现部分或大全部返工现象。
- 软件项目开始的时候，谁也不知道什么时候能完成，领导说三个月就三个月，半年就半年，实际上，没有按期完成的，延期3-5个月是常事，1-2年也是有的，甚至不得不换班子重开炉灶。
面对以上变化和问题，我们当然可以继续延续原有的驱动模式 —— “高手” 主导的项目模式，也就是给每一个项目配备高手，但问题是，如果没有那么多高手的话，所有的项目就会压在有限的几位 “高手” 身上。说白了，在这种模式下，企业实际上是将问题转移给相对低资源能力的高手去解决。当然，有限的 “高手” 也同样可以使用同样的手法进行问题转嫁，但这种解决办法由于将所有的问题转移到单个人身上，企业管理就研发方面的决策难以形成明确的方向和目标，在研发方面只有用人的战略。那么该如何留住高手？如何在符合企业价值观（薪资）与战略的前提下，找到高手，都是世界级难题。显然，以上并非根本性的解决方案。因为一旦高手动荡，企业业务发展就受限，而且这种方式面临的风险很大，过度的项目定制开发不但影响项目的交付进度和质量，再加上某些 “高手” 自以为是的要挟，也使经营成本居高不下，侵袭了企业本来就比较有限的利润。那么，出路只能是走向 “一对多服务 - 产品化”。也就是说，用 “一个团队 + 一个产品 + 多套解决方案” 的方案来服务多家客户，通过技术、配置化、产品化的手段，利用 “面向客户” 的思想来打造自己的产品，所以这才是我们客户成功的精髓，而不是 “技术攻坚 + 高手”。
第二、用户是谁？客户是谁？为什么花钱买你的 “货物”？
在几年前的一场技术分享中，知道创宇的CTO曾对 “谁是客户” 与 “谁是用户” 进行过一番概述，让我受益匪浅。
大致的意思是说，用户需求和客户需求还是有一点关系的 —— 用户是人，客户也是人，只有了解到详细的客户，才能明确地自己该做的需求。
那么用户是谁？无非是使用你产品的人，用户是人，同时用户也包含部门的负责人。
举个例子，以前开发 OA 系统时，用户说蓝色的好看，但过几天交付后，部门总监提需求说要改成红色的，可能你会纳闷他为什么要改这个颜色，后来才知道因为他是党委成员。也就是说，当我们设计产品时，我们会去调研 99% 使用产品的人，但是有小部分人只会使用你 1% 的功能页或者就只使用报表页，如果我们不去调研他们，到最后阻碍我们产品成功的人，很可能就是这 1% 的人。
在分析客户时，我们需要了解到他们的最高需求是 KPI。以前我做 ToB 业务时，从来不分析客户的 KPI，因而出现了挺多的问题。可能人家的 KPI 是一年事故率小于三次，但我们的事故率一年一次都没发生过，这时我们也要想方设法在报表和推送上体现出对方的 KPI。
除此之外，KPI 还有更深层的需求，这就靠人性洞察力和行业洞察力。
换句话来说，像我们现在只坐在办公室通过微信与客户聊聊天、发发邮件、打打电话，你是不可能挖掘到 1% 的需求的，更无法取得 1% 人的信任。
那么客户是谁？在解答之前，我先来说个搞笑的故事。
有一位朋友是产品经理，他经常跑到客户这里吹嘘说自己的产品能帮助企业节省 50% 的人力，但他所面临的客户都是国企以及拥有十几万、上百万员工的企业。对于国企和这些企业来说，节省 50% 的人力不是客户需求，他们本身可以不盈利，但必须政治正确，解决就业就是政治的一环。
这个故事说明了啥？
说白了，做产品的客户需求分析一定要分析到人，而且是你见得到的人，如果客户是你见不到的人，那么生意就不可能做。
说到这里，大家可以设想一下，如果报价超过百万，你会发现对方公司会跳出来一个采购委员会——由他们决定付不付钱、付多少钱。他们很可能来自不同部门，这会导致我们需要把采购委员会的人事部代表、法务部代表、信息化部代表、安全部代表所在的部门需求全分析一遍，并且现在有很多公司采购委员会都是一票否决制的，这导致了做 ToB 非常难。
好了，总结一下。
所谓客户，其实就是付钱的爷爷，也就是采购决策链所有参与的人、决策的人。他可能是一名司机，她也可能是老板大腿上的小秘书。
我们如何认识他们？如何取得他们的信任？如何在他们内心占据一个位置？如何在老板换小秘之前知道下一任是谁？
这些不仅是我们售前团队需要考虑的事情，更是我们这群技术男需要突破的界限。
什么？你说这些都是扯蛋，只要解决了 “痛点”，他们就会买单？
你真幼稚，也许运维总监的痛点就是找个人背锅，也许CTO的痛点就是解决无法找到这块的技术人员，也许CEO的痛点就是降低公司成本……然而这些痛点，恰恰是我们能够通过 解决方案与服务 帮他们解决的。
第三、缺乏目标感，找不到属于自己的位置，就知道 “低头拉磨”
几年前，我曾在一场技术演讲中分享过这样一张图。
当然，这里并没有贬低与诋毁的意思，我只是想让大家身临其境得脑补一下这头驴的内心感受。
很显然，没有一个人愿意当一头蒙着眼睛的驴子，但 “缺乏目标感，找不到属于自己的位置” 的现状却是当下很多人的状态。
为什么要做？做了有什么意义？下一阶段该怎么走？这个功能客户是否会满意？客户的核心痛点是啥？……不知道，不是你叫我做的吗？你问我干啥？
好了，大道理也叨叨了，调侃也调侃了，接下去我们该怎么做呢？
▌明确职责分工，严格落实责任
在我经历的企业中，有的在岗位职责方面会拆分得细一些，而有的即使有岗位职责也未必能够按照执行。
因为考虑到当下人员资源的投入情况，再加上许多小伙伴本身比较精干，所以我们会采取一个人负责几个岗位的方式。这样既能让大家主动发挥自己的能力，又尽可能的充分发挥自己的潜力，更多的为实现团队目标而努力。
为了解决这个问题，明确职责分工，严格落实责任，我会与大家一起输出 “客户成功团队 - 工作责任分配矩阵 - 2022”。
当然，在规模不是很大且人员也较少的当下，仅凭一张表是很难界定所有的职责与边界的，其关键是起到 “先梳理流程，再界定职责” 的作用。
至少，这样更容易让每个人牢记 “我为什么要存在？我在哪？我的价值是什么？”
▌转型敏捷，主要是文化与意识的改变
看到这个标题，相信有人会吐槽：“估计你又要宣扬 ‘敏捷是最后一根救命稻草’ 的理论了，我不认同。”
不，你猜错了，我是来讲故事的。
十年前，当时我去做一个项目，因为经验欠佳且多东西还不懂，再加上满脑子都是传统的瀑布式项目管理模式，所以当时我看到需求老是变来变去的，就火急火燎的跑去问项目经理：“为什么不能按照软件工程的这种套路来的，需求总是变不是浪费时间吗？我们应该把需求全部定好然后做设计，设计全部定好然后开发”。
他似乎很鄙视我，回头对我说：“你真天真，客户那边需求是我可以决定的？”
这次之后，他就经常带我去客户现场，并尝试让我与客户进行需求交流，于是我才慢慢发现你问客户需求是问不出来的，客户很多自己也说不出来，有时候需要你去帮他想和他一起想，也有很多你只有把它做出来了，给他看了，他才能进一步提出意见，慢慢地他才能找到他满意的真正的需求。
所以说，大部分客户的需求自己也不清楚，必须是他看了你给他做的东西才知道，这也是我们敏捷里面需求整改的一个大方向，需求是不确定的，特别是做软件，很少看到需求是完全确定的。
也就是说，敏捷，解决的不是速度的问题，而是灵活性与节奏感的问题。
我们需要利用敏捷化模式，加上专业领域的丰富经验，通过需求的小步快跑，不断的进行产品迭代，慢慢的向真正客户需求靠近，而不是演化成 “多条瀑布式布局，各有各的代码与标准”，这样不仅成本难以承受，而且时间一长，肯定资不抵债。
▌全力打造 “解决方案架构师“
有人说，只要是一坨能运行的代码，并且能为某个业务解决问题，那它就有商业价值。
对，理论上似乎很有道理，但却很难成为现实。
在当今的企业中，不是你跑通一个Hello World就万事大吉，大部分看似繁琐的代码，本质是为了解决软件系统的复杂度的问题，以更为健壮的业务代码，更灵活的响应个性化需求，最终给客户提供了更好的产品与服务。
什么分层啊，什么封装啊，什么接口化设计啊，我们有很多人把这些东西统称为 “架构”，而架构的核心是规划、设计和识别，而架构师，就是负责从这三个核心角度来解决特定领域问题的专项工作角色。
从某种角度来说，我们算ToB领域，与其说我们是卖产品的，还不如说我们是卖解决方案的。
为什么这么说？
因为解决方案是把各种产品、技术或理论方法，不断地进行优化组合及创新，从而满足用户的特定目标和需求，而解决方案架构师则要从繁杂纷乱的业务需求和问题现象中抽丝剥茧，提炼和设计解决方案，从而帮助客户把想法、问题、需求落地成一个可以执行、可实施的项目。
很显然，在很长一个阶段里并没有意识到这个岗位的重要性，所以无论是在知识积累还是经验传承上都没有更多的积累，但在我看来，这个岗位至关重要。
因为，在今年的计划中，“如何打造一个解决方案架构师团队” 将是我工作的重点之一，而且我会更看重在 心态、能力、方法 三个素养维度上加强和积累。
一是心态上，要具有永不言败的挑战心态、分秒必争的学习心态、虚怀若谷的开放心态。
二是技能上，要具有高度的抽象能力、高效的沟通能力、专精的业务能力、广泛的技术能力、接地的实施能力。
三是方法上，要具有战略思考的方法、设计思维的方法。解决方案架构师要具备有效的工作方法来进行能力转化输出。
写到这里，无论是想说的还是不想说的，不管是能说的还是不能说的，基本都叨叨得差不多了。
有人说，突围需要机遇，前进必临挑战。
有人说，人生之路不总是宽路、直路和上坡路，有时也要面临窄路、弯路，甚至是下坡路。
宽路、直路和上坡路好比机遇，窄路、弯路、下坡路好比挑战，他们是相伴相生的，正所谓 “困难与希望同在，机遇与挑战并存。”
毕竟短短的两周时间，我所看到的、遇到的、听到的都还停留在表层，但我相信 —— 虽然过程充满艰辛，但我们终将完成突破。
加油，伙伴们！
