距离上一篇文章有很久了，确实一直想保持这种节奏，但一直出现‘脱更’的情况实属无奈。除个人工作的调整之外更多是因为到处出差‘飞’的状态。

时间越久，越是发现技术和沟通的两把武器，技术在技术人员身上是没有问题的，但是在沟通上问题极大。虽然说‘自古套路得人心’，但初心总归是好的。
在国内，目前有非常的做云计算服务的公司，今年格外多。尤其是伴随华为云发力、AWS发力和各类公有云在基础架构上的‘白菜价’上，对‘迁移、上云服务、对持续运维服务’上有简单而又粗暴的需求。
因为信息敏感问题，最终用户以“用户”简称、自己的公司以“公司”简称。如果您是我文章中提到公司的管理者，且认为文章表达措辞不当，请及时联系我进行删除或者修改

邮件联系方式：[email protected]

此次交流，侧重与业务线的交流和沟通，这里不会分享技术原理。文章已通过内部团队脱敏审核，请大家放心阅读：）

分享形式将会使用‘对话形式’，最大化的还原我作为偏业务线（架构师）临场与客户沟通时候的心理变化以及应对策略

如何与不懂技术的强势甲方boss沟通并获得认可？

本次交流重点简述

  • > 一次救场的沟通记录（此次分享内容）
  • > 顾问式销售的三把‘武器’
  • > 服务产品的博弈

☆首先描述下背景（分享会首次使用对话的方式还原场景）

讲起来也挺有意思，当天个人行程是下午7点的飞机（飞往古城西安），因为需要出差四天，所以我当天的穿着是运动装（类似健身房里的那种穿法），远去一看不认识还以为是准备去打篮球，所以极其不适合见客户。
Sales提前安排了客户在公司的腾讯云办公室见面会谈，起初是我们的俩位同事过去接待的，因前期交流时就是正常的流程：聊需求、聊解决方案，很正常的交流过程。

Allen内心旁白：现在回想起来，确实任何时候不能光凭感觉去评估，还是做最全的心理准备和预期才行，否则就像这一次一样。
在交流半小时后，我们的sales上楼从会议室把我叫出来了，告知需要我临时过去‘解答一些技术问题什么什么的····’‘什么？！！我一身怎么见客户？’，没办法！搞不定了，要救场，必须上了，我快速脱掉帽子，整理了下头发，穿上外套就过去了。

☆会议室场景复原
客户四位面对会议室进口而坐，我们四人面对面坐着。进来就有种扑面而来的紧张感，似乎前面有些没聊好，第一时间能感觉到没关注用户的表达。

致命提问1—给我一个总的预算，然后每一项标注清楚

Allen内心旁白：很尖锐的话题，一上来就问了个问题！没前没尾的，同事信息有限的让我略有心慌不知所措，这里我用对话的方式还原场景给大家复盘下这个现场情况

进入实际场景：
C-BOSS=对方最大老板
Colleague=同事
Allen=我
Customer：对方其他人

Allen：抱歉，抱歉，各位领导。我今天出差，所以穿的很不正式。非常不好意思，失礼失礼，‘这个话题！抱歉，我们前面没参与，很多信息没有交互。能劳驾您再与我细致的再复述下‘痛点和需求’和‘大致预算’的数字。

Customer：是这样的，大概是这么需求‘我们想做个30-200W并发’的APP，依你们的专业经验，是否能帮我们评估下大概多少钱？

Allen：emmm…..您能再详细说下这个APP的业务类型吗？比如；社交、企业商户、电商等等

Customer：我们是一家做人力专业资源服务的公司，考虑做一个人力资源的服务APP

Allen：是类似Boss直聘、前程无忧、猎聘、拉勾网这类APP应用吗？

Customer：对的。

Allen：明白了，那您大概能告诉我，这个APP用户量级的规划吗？在哪一个阶梯中？比如；500W

Customer：你就当差不多50000W-1亿的用户体量吧，我们在前期差不多至少能达到3000W的注册量吧，并发能到30W-50W并发量的样子，你看看好勒。

Allen：好的，了解了。提一句体外话，您这边的软件开发商是公司自建的团队，还是使用的外包服务团队？

Customer：外包的，这个事情确实有点让人不开心，这个APP，我们开发时间花了将近两年，而且因为很多合同边界没有提前商定清楚，导致一直说有些额外的开发内容需要不断的补充费用，弄的确实不开心。所以我们这不是我们老板亲自也过来了嘛，也是能在一会后面的沟通中，我们能听一听你们对服务这个事情上的一些专业指导和经验。

C-Boss：我们其实是冲着腾讯云来的，但事先其实是不知道这边是服务商（代理商）。

Allen：嗯哈哈，腾讯云总部在漕河泾那边。我们是华东区较有代表性的腾讯云的服务商。存在的价值主要就是像今天一样‘坐下来跟您（用户）一起探讨交流，帮助用户理解腾讯、更好的使用腾讯云，同时我们能支撑您后端所有的运维管理工作，这一定程度上避免您需要花比较多的学习成本去学习，或者去招人解决腾讯云的各类技术运维话题、构建问题了’

Allen：其实您也是管理公司’菜米油盐’的领导，每一次项目上成本的上升和额外支出都是其实很敏感的，我们这里也是。每次提交未预见突发计划产生的成本，就特别敏感，特别是提headcount的事情，恩哈哈~~~

Allen：对了，聊到这里，在这个APP开发的过程当中，您这边是如何管理外包团队的，是专业的项目经理参与管理还是仅限在合同协议上？

Customer：我们Selina在负责，就是这位。（说罢，挥手示意了下左手边的美女）

Allen：噢噢噢，是偏管理上的协调，还是会盯到特别细节，比如：某一个技术细节这类的管理？

Selina：就是协调管理下，我不是技术，所以无法盯的这么细致。
Allen：好的，明白了，那也就是说，如果我现在想了解您这边的软件开发构建框架、技术选型等，这会估计无法聊的，是不？

Selina：对的。

Allen：那您这边能否帮我演示下您APP现在的样子，我看一下里面的业务模块啊什么的，同时您帮我讲讲，用户/管理员如何如何使用这个APP、您的后台管理端是什么样的、APP是如何产生业务收益的？等等

Selina：这样吧，我打开手机给你看下好了。
（‘我和其他两位同时一起观看了这个APP的演示和一些用户的使用过程分析，包括后台管理端存在一些数据分析的功能等等’）

Allen：好的，我大致能了解到您这边APP的业务逻辑和体现构造了。图片、文字的交互比较多（无非就是刷简历，找工作，彼此介绍工作，），所以您这边能帮我确认一个事情不，比如图片的访问是与应用服务器分离的吗？比如；我们图片和访问登录流量是分离的。

Selina：这个，我不知道诶，估计要找技术那边问了。

Customer：这是有什么讲究吗？

Allen：有的，采用传统物理基础架构构造，是通过一些功能的切分区分各种服务器的功能。比如图片的反馈全是直接通过web应用服务器反馈到用户端。即：‘web应用程序的带宽、IO性能是典型的瓶颈潜在对象’，一旦你的图片没有经过一些压缩等优化，对外的web服务器带宽可能被图片的大量返回和调用占满，从而影响用户的APP体验。

Allen：其次呢，我们这一次聊的背景本身是采用云计算的方式部署应用系统，故综合云的优势会将构建进行一定的架构优化，这是面向云计算的正确使用做法。所以在前面的这个问题上，我们会使用云上的对象存储去“剥离”这部分图片的返回的带宽流量，加上对象存储不存在单点故障，接近不存在IO瓶颈，并天然拥有无缝对接CDN的加速特点。这样用户将会打开更快的同时又不占用web应用服务器大量带宽。因为您大概能知道，云上带宽是最贵的。

Allen：讲究也不算，这其实是任何一家做云管理的服务商最基本的能力。因为您问了很多专业的参数测算值，出于严谨和对您负责，我们大胆的探讨假设的同时，需要的是谨慎的求证才行，我这里需要您比较多的关联信息来支持我的判断，所以您看看能不能再帮我详细一些。

Customer：这可能没法满足你，我们自身本来就不是专业的，所以过来找你们来聊也是这个目的。想听取你们专业的意见。所以你不要再问很技术的问题了，我们没法给到你，根据你们的专业意见，帮助我们来看下大概多少预算吧。

C-BOSS：你们这样，就告诉我根据你的实践，我们这个APP在腾讯云我们需要花多少钱，好吧。我们也没带软件商过来。帮我们把每一个资源对应的费用都现场拉出来，我们来一项一项来看。

Allen：emmmmm，明白了，现场我们就可以拉价格的，因为价格在官网都是公开的，我们这就边回顾最佳实践以及现在的情况给到一个基础架构资源的评估

Colleague：好的，我来拉给您现场看下（这个时候，我们边聊边解释我为什么要用这个资源，例如：为什么要用负载均衡、为什么要用waf应用防火墙、为什么要买八台而不买2台）

C-BOSS：我们也会需要过等保的，所以你们要结合这些一起来考虑。

Colleague：好的，明白
（随后我带着同事一起follow等保的要求产品需要，和一些最佳实践把云资源做出来，客户考虑后，觉得太贵了，暂时不考虑。）

致命提问2—你们告诉我这些产品是干嘛用的？

• 问题2）为什么使用负载均衡、为什么读写分离、为什么需要缓存服务器？

Allen内心旁白：这个看似很平常的问题，但实际非常要小心，其中陷进很多。我们都知道越是看似简单的问题越是能提现出甲方想观察你对基本的事情理解深度。又或者这位提问者是明白的，只是‘揣着明白装糊涂’看看你的专业度情况，这个过程中除了‘润物细无声’体现我们的专业能力的过程之外。更重要的技巧是你还要用最最最最通俗的语言翻译给这些领导。
（我们在边讲边介绍的过程 中，用户老板不时有打断并质问为什么？比如下面）

C-BOSS：这个负载均衡是干嘛用的，为什么我们要用呢？

Allen：这个是必须的，不只您这边，任何一家大企业部署生产业务都不能忽略这个产品。举个例子：这个房间是一个大门对吧。我们现在一个一个进来是没有问题的。但是如果有很多人同时一起并排进来怎么办呢？是不是就是会产生拥挤的情况。

Allen：那我们更进一步比喻，如果把我们现在的这个腾讯云会议室比喻成一个应用系统，把这个‘门’比喻成我们应用程序入口，也就是‘公网’。那是不是就会出现用户量很多，但是没有办法同时一起进来。因为门并排最多同时一起两个人进来。

Allen：那今天，您把这个问题交给我们，我们就用技术构建的维度解决这个问题。

Allen：传统的做法，是不是会告诉（建议）您，多放几个这样的腾讯云会议室嘛。这样不就解决了吗，这有什么难的？！！，您说认可这个说法吗？
C-BOSS：emmm，不难，就是这么弄的

Allen：那么第一个问题来了，谁来告诉进来的人，这两个房间都可以进呢？对，指示牌或指示人嘛。所以我们在提前设置一个指示牌或者人来指引，这两个房间都可以进去的，请根据自己洗好选择进去好了。第二个问题也来了，如果其中有一个房间里有一半凳子坏了，这个时候指示牌没有办法主动发现并解决这个问题。可能当人（指示牌）被动发现问题临时说，你们快去第二个房间吧。

C-BOSS：对，是这么个逻辑

Allen：emmm，这个指示牌或人用技术的思维去思考就是‘负载均衡’，这里凳子坏了就比喻为‘应用程序故障’，我这么讲您能明白不？
C-BOSS：能明白。

Allen：但是您提前放一个‘智能’的人，提前告诉他这里有10个腾讯云会议室可以用，您根据这个‘智能’的人，提前预设好的规则和策略，按照该规则去分配，同时你会议室想临时拿走或增加、或者会议室凳子坏了。这个智能的人都能发现和感知，我们把这个动作比喻为‘故障自动检测’的过程

C-BOSS：好的，这个我能明白是做什么的了，那什么读写分离是什么？这个技术必须要吗？

Colleague：是的，这个有利于缓解您的数据库读写压力。

C-BOSS：……嗯？

Allen：是这样，我同事解读的非常正确。我帮您解读下这个使用场景，不恰当的比喻啊，或许您就能明白这个是干嘛的了。还是前面的这个场景，会议室是应用程序，门是公网入口，凳子是实际的‘用户’进来要坐的（用得），我这个比喻能理解否？

C-BOSS：这个能理解

Allen：好的，我们更进一步，那请问在公司组织管理上，是不是会各种部门，部门内部是不是有各种工种的分类，这个您是专家，毕竟是做人力资源的企业。所以我们这个时候引入‘场景’的概念。回到会议室（会议室比喻成应用程序），是不是会有像我这样的用户‘反正就是每天（进来会议室）登上来查询下自己的简历被多少猎头看过、看看新闻’等等。

Customer：啊哈哈哈……

Allen：这种人很多的，我就属于这种，恩哈哈,,,不过话题说话来。这确实是一种场景。

C-BOSS：哈哈啊，是的

Allen：好，那是不是还存在一种这样的人，刚注册或者要频繁修改自己的简历信息的。

C-BOSS：是的

Allen：emm好的。那我们把这两种比喻成两种不同的‘场景’，对应到前面我所说‘凳子’，所以我会根据实际用户的真实使用场景的频度来提前安排‘凳子’的分配。比如天天查自己简历被多少人看过的客户，在您的用户群体中占比80%，那我是不是就需要为这些用户多准备一些资源（多准备一些凳子）让用户使用。

C-BOSS：是的，就是这个意思。

Allen：那我们这个时候，如果我们这个会议室中放置‘两种场景’的用户，是不是对这个地方的管理会增加难度和压力，即：又要顾着查询量又要帮着存储修改后的简历数据。如果按照现在这个会议室，我可能只能专心的听您说，不能同时兼着处理另外一位的疑问。所以我这边描述，您是否明白我想表达的意思？

C-BOSS：好的，似乎明白了，是不是相当于我将用户场景提前分类，然后把压力做一些合理区分。那这里有个疑问，两个场景只查询的数据和做修改的数据，是否能保持一致呢，否则不就有问题呢？

Allen：好问题，这个‘读写分离’的技术在诞生的那一刻就要解决这个问题，所以目前各大厂商这类技术（PAAS数据库产品）几乎完全接近没有延迟，两边的数据在同可用区几乎接近实时保持一致。

Customer：我们明白了，谢谢了。那再比如缓存呢？这个是解决什么问题？
C-BOSS：这个是不是就是比如啊；我们提前把一些可能涉及的查询数据提前算好，然后用户登录进来后，就可以提前拿到了，不需要进去数据库里面查询了。比如：我们的后台程序管理界面，每天一打开都会看到有多少登录量，类似这样的数据，就缓解了数据库的压力。

Colleague：没错的，就是缓解数据库压力的设计

Allen：您这描述看起来不像不专业的啊，这个解释很专业了，啊哈哈哈···我在您的基础上补充一下，这个缓存产品是在原有数据库读写分离的基础上，再次降低了数据库的读的压力。

Customer：恩哈哈哈……………..

Allen：您这个补充，着实是真的专业（我竖起大拇指了，比划了一下）
（随后还补充了一些WAF和主机防护的场景介绍，这里就不详细赘述了）

致命提问3—APP故障了，你们怎么赔偿？

第三个问题，也很突兀。这都是什么问题！！！但实际是我们在日常陌拜或者会议中经常出现的提问，合同关系是跟我们发生的。如果是钱付给我们，那腾讯云是否会拒绝向我赔偿，一定要通过你们来申请赔偿呢？
• 你们为我们APP运行兜底吗？比如故障，你们要积极解决之外，故障太久要赔偿的这种兜底。

很多新手在这种对话场景中，经常会出现一些不专业和不知如何应对的问题？且感受下我是如何应对的

Allen：您这边具体指什么故障？

Customer：所有的故障，既然委托给你们了，那就是所有的故障都包含了。
Allen：是啊，做云服务必须要积极面对和处理基础故障并承诺超出故障时间的赔偿金，但有些故障确实不是我们能左右的，比如；公有云自身物理机房断电故障导致业务瞬断、又或者恰好您的业务就在这个断电的机架中，导致宿主机迁移影响了业务5-10秒的时间，再比如运营商对外出口线路光缆被市政施工意外挖断了，还有台风啊等等。

C-BOSS：你们不是华东区最大的腾讯云服务商吗，我们跟你签合同，腾讯云的故障就应该你们承担，不然要我找谁赔偿？合同跟你们前的，找腾讯应该不认吧？

Allen：（我打开一个公有云责任共担模型），解释各个责任归属问题的同时，也具体的理清了一些不可抗力的故障：地震等自然灾害。另外再次强调了服务商在三个角色中的责任（用户、服务商、腾讯云），同时解释了基础设备硬件导致的故障腾讯云是根据公开承诺的协议文件进行赔偿的，这一点不会随着您跟服务商或者代理商签合同就会发生‘责任转移’，这一点您放心，另外这个赔偿（合同）协议腾讯云官网都是公开的。如果您还是担心，我们可以将这个协议文件以附件的形式依附在合同里，您看这么处理，是否认可？

C-BOSS：那这样说，我直接找腾讯云不就好了，干嘛非要跟你们前呢？
Allen：呃。。没错的，当然是可以直签，这个完全取决您的意愿，但提示您，现在这个云计算大热的背景下，为什么我们这样的服务商存在而且还活的很好，而且原厂也非常依赖我们。这侧面也印证了它并没有办法关注到所有用户的交付，每一个客户都有自己独到的场景需求，厂商不可能样一万数量级的客服人员，一万数量级的交付人员。况且腾讯云也好，阿里云也好，AWS也好，他们的客户量都是解决百万级的。

Allen：加上原厂的单个人力成本都高，那~您是做人力资源行业的也是大老板。您肯定能明白好资源要用在重要（高回报）的地方。举个例子；您这边前面经过一些测算，一年总共的云资源在20W左右。那假设我作为腾讯云sales，评估一对一服务20W的客户与服务一个200W的客户，很有可能成本是一样的。那请问我有什么动力来支持您呢？

C-BOSS：那我选阿里，选华为不就好了，华为云现在服务也挺好，就像你说的端到端的这种服务。

Allen：当然可以选，我们也做阿里云、华为云，甚至也做亚马逊和微软云。坦率的给您汇报一下吧，今年2019年人力成本的上升就是所有企业都在头疼的问题。我相信您也头疼！每家都其实是一样的。哪怕他现在确实给您做很一对一的服务，但随着它的业务量上去，它（厂商）一定会做一些取舍的。对吧，领导~

Customer：好的，我们明白了，那你们可以负责哪些故障呢？能承诺什么呢？

Allen：我们一直跟您聊运维管理服务，但是一直没有不知道您对这个有很多的不明确的地方，抱歉哈，这是我们的问题。我来给您详细解读下，我们到底做哪些事情，可以承诺什么？

Allen：所谓运维管理服务，其实不恰当的比喻为‘维稳部队’，那给您开发APP的团队呢呢，我们比喻为‘武器生产部门’，我们对这个武器的‘运行’负责，不对您的‘武器’生产质量负责。但是我们作为武器运行的‘维稳部队’，我们在日常行动中会使用这些‘武器’。那我们一定知道这个‘武器’运行的稳定与否，以及解决问题的实际效果如何，我这么表达您看是否合理？

C-BOSS：没问题，我能理解。

Allen：前面说的，我对‘武器’的正常使用负责，开发团队对武器的功能开发负责。所以这个武器功能也就是眼下我们谈到的APP应用，在运行时候，我们会帮助您管理他的运行状态（异常等）、容量等一系列需要关注的指标等问题。若业务量上去了，我们清晰的知道该如何正确迎接业务峰值压力。

Allen：对现有资源进行基础架构调整（或提前预留水平/垂直扩展的架构），优化APP在峰值突发运行时的访问和基础架构服务的健康性。但若是因为APP本身代码开发设计问题导致运行缓慢（异常），我们会尽可能快的协助您的开发团队找到问题原因，然后与您的开发商一起面对并克服该问题，但产生该问题的主因是代码质量的问题，我们无法提前干预，所以我们只能尽力帮助，无法承诺为此负责。

Allen：简而言之，你可以把我们比喻为家政服务中的保姆，我们无法承担房子结构不合理、塌陷、漏水的责任。我不知我这样描述，大家是否能理解这个。另外这是我们的服务清单，各位一起过目下。（sales将服务列表打印出来后，我们随着客户一起过了一次）

Customer：好的，我们看看，挺好挺好。。

C-BOSS：我们现在这个开发商啊，每一次调整功能就要收钱，特别不能理解，而且弄的特别不开心，我们双方。所以我们也是希望能更细致点，这样也好。

Allen：您到底是领导啊，很强。

Allen：我们也是一样，毕竟现在越来越多的强调‘专业的人做专业的事情’，确定成本能得到较好的控制下，让用户不要太担心责任边界不清晰导致的额外付费等等。不过坦率的说，在这点上对您自身公司的对接人综合能力要求较高，要懂很多。

C-BOSS：是的，小伙子你很专业

Allen：聊了这么一会，我确实能感觉到您之前受了不少伤害，我非常希望能帮助您这边扮演好这种‘链接器’职能的服务商，因为很多的日企都是这样找到我们的，并以这样的形式全部委托给我们。所以，感谢您给我们一次介绍自己的机会，也挺期待近期我们能依据今天的沟通，将商务、最终价格清单有更好的进展沟通。

Allen：MC（sales名字），你看我遗漏哪些还没有谈到的内容。

Sales：都探讨了，谢谢你。X总，P总，您看还需要我们做哪些补充？要是没了，我们今天就暂时先到这？

Customer：好的，暂时没有其他问题了，我们先这样。
（主动过去握手，再次抱歉我今天着装是这样子，非常期待下一次与您沟通）

回顾一下，问题提出

思考今天分享的这个案例前半部分中，我提到的三个问题。加入这个救场的人是你，你会如何考虑和应对的？如何提前保证内部团队的‘唱跳’搭配。

☆贵在坚持，请努力！
谢谢各位的阅读，又进步了一些，每天进步一点点，下一次

Allen人生格言：越努力，越幸运~~