【转】一位架构师用服务打动客户的故事之三

转自：Allen在路上的51CTO博客

原文链接：http://blog.51cto.com/allen686/2072916

在开始正题前稍微给各位关注博客的伙伴说明下这段日子去干嘛了？

～～其实早在2017年8月我就开始了自身网络专家"修练"的日子。

修练什么呢？

答：CCIE

为什么要去做这个事儿？

答：其实就想给自己过去曾经给cisco做助教的经历一个交代

实战派为何需要这张paper？

答：第二个问题的补充哈，想认真的梳理下自己的知识结构

～～决定给自己列个百天计划，享受一下这个百天计划的压迫感！！！

～～起的越来早，睡的越来越晚

～～冲劲十足，从来不抱怨

～～现在想想也觉得那近6个月的日子真开心，除了知识得到了系统性的查漏补缺，更得到了心智上的"收获"。

好了，老铁们，不扎心了，，来讲讲今天这个客户的故事，上菜上菜！

在开始前讲一个背景，我们跟腾讯有深度的战略合作关系。

各位也清楚，市面上的公有云论IAAS的组成其实都一样。除了在一些特定行业特性上挂了自己的标签之外，其次就是自身能力转化成PAAS的产品能力！

总之，各有千秋，对于游走在各个产商中的我，也只不过是多了一个厂家的特色学习，IAAS组网、系统应用中间件构架的难度并非是难事。

本文没有解读太多技术细节，着重在“售前和销售在项目中的配合协作”上，所以不喜勿喷，(*^__^*) 嘻嘻……

时间回到2017年x月x日：

我们接收到腾讯云一个很牛X部门的通知，告知在上海漕河泾园区中有一个潜在客户（一家即将上市的公司）需要云计算资源和服务，授权我们前往拜访。

在接受到通知后，我们的渠道BD单独找到我，表达了希望我前去支持下这个项目。

随后呢，正赶上我们的云服务Team在上海出差，于是我邀请了云服务团队的Sunny（Leader）和其中一位资深的linux专家、以及上海Pre—sales Team的一位同事共同前去，一共4个人。 

PS：第一次拜访因为销售时间关系，没有办法参加，所以和客户约时间等事宜我个人全部代劳了。

第一次拜访材料的准备———第一波重点探讨，注意注意

因为没有前期的需求沟通，所以这个时候相对会比较"懵"，不知如何展开？我没想太多，直接拿了一份某同事整理的《通用型上云解决方案》的PPT准备起话术来。然后花了大概30分钟左右了解了下这个客户的情况（公司基础信息，包含但不仅限主营业务范围，人员结构，公司注册信息～～），结合这些信息判断了下客户可能会有哪些应用上云的诉求，并整理成材料。

材料部分截图：

拜访不只是相互认识，如果能在最短时间拿到客户需求又或者在很短时间能勾起客户"滔滔不绝"兴趣话题这个相当重要。

身为一个售前，假想下你初次拜访的场景～～

1.相互递个名片

2.公司介绍胶片走一遍

3.听客户把需求讲完后，客户告知发一些典型案例我们看看

4.差不多寒暄几句结束了

那根据我个人走了小十个单子的经历，这种情况基本你作为售前就是失败的。仔细听需求是没错的，但如果不想着办法让客户多讲点其他的东西，那售前当的就多少有点问题！！

例如;

 1.基于什么考虑要做这个上云事情?

 2.为什么会选择腾讯云，没选择阿里云、百度云、ucloud、金山云？

 3.物理机房在哪里？大概规模有多少？之前有出现过灾难故障吗？

 4.目前有多少业务系统？等等

为什么我个人主张这么去思考呢？我个人一直认为第一次的拜访一点不亚于破冰的概念，很多时候真的需要我们好好想想－技巧这两个字！我把脑子大概闪出几个关键点汇总如下：

1、让客户真正讲需求，这一点共知没问题

2、让客户讲讲公司的情况，我们除了因为有云计算需求过来拜访之外，我们也更希望深刻的认识和了解客户！！

PS：先朋友，再生意，自古以来的道理，当然预先已经铺垫好的项目就例外说了。别挺萌的一上来就谈项目怎么落地！这要是放在北京，不说别的，先是一顿大酒，喝好咱再谈生意！

3、带着专业的问题和预先准备好的（通用）方案过去客户那边，现场当面交流技术实现细节，以及方案的适用场景！别光顾着听，然后听完承诺回来给个方案，这种我就认为售前角色做的太低级。

PS：作为客户角度着想，这种情境如同：年轻的售前＝信息传递者、年长的售前＝老油条一个，没点真才实学。不敢直面现场交流，如果客户有很好的关系做信任基础，那就无碍。当然这是个人观念，不喜勿喷。

 4、 切勿以最高逼格直接上去梭哈！

PS：脱离实际，一味追求高大上的方案，客户再有钱也不傻！当然项目利润运作除外

 5、老生常谈了"我们来是过来解决问题的，不是来炫技的！"、"我们是来学习交朋友的，不是来吹牛皮的！"

PS：姿势和站位要对，论换位思考的重要性，明白先感情再生意的读者能体会到我想说什么。

 6、聊聊至少一年后的计划

PS：表明我们此次前来的目标是着眼于未来，眼前的问题并非难事儿。当然这不是让你"太务虚"，尺度自己把握好就行。

约到客户时间后，就到了拜访阶段了。

    我们提前十分钟到达楼下，再次碰了下今天拜访的主要目的和角色分配。随后我们到达客户会议室，相互递了各自的名片后，进入正题。

    按照我前面提到的几个关键点开始了今天的拜访。加上我们有腾讯的光环，客户滔滔不绝讲了非常多，方方面面几乎都涉及到了。加上前面预先准备的一版方案，客户更是表达了对我们做事的信心，也提到要做混合架构、安全、冗余备份的想法，刚好方案中也提到了实现细节。在很融洽的不到一小时的会议中，客户表示很期待我们下一次过来拜访（协议合同、优惠尺度、服务合同的商定）

本次混合云方案中PPT截图；（同事预先准备好的通用方案）

本文第二波重点场景解读：

举几个亲身经历的例子！

1、一次我代表甲方去跟新进的软件供应商谈运维话题的场景，对方什么准备也没有。絮絮叨叨没逻辑的讲了许久粗的"东西"，总之表达一个观念："运维没问题，我们有能力维护好"

 Allen解读：甲方无非其实就关注你能不能把他关心的方方面面讲清楚。风险可控的最重要的参考就是"过程"，过程即意味着细节。倘若都是泛泛而谈且没有逻辑和极强的细节阐述，那就会势必会造成冷场和尴尬，甚至客户的不信任。（当然，关系型项目引进和利益运作除外）

2、我去给一家在物联网领域研发技术能力很强的公司交流，云计算的便捷和挑战等内容时，对方甚至问到协议和数据报文的结构、数据流在各个中间件的走向与处理。再我在具体一点（Nginx灰度发布的实现原理、以及对业务可能造成的有损范围等）

Allen解读：遇到技术能力很强的沟通对象，你的技术功底相当重要。在这一次沟通中，我并没有回答上这样的问题，告知我下去后与我们的linux技术专家学习和交流下，不知道就是不知道的观念还是要积极去表达，不要装懂！！！大忌

3、还有一次一个非常典型的视频内容的客户，由于原先供应商的强势加上客户自身并不懂技术的原因，运维中产生的话题给内部造成了巨大的困扰。（每次APP的更新通过CDN推送到全球后，手机终端触发更新后都是秒下，导致更新失败），我作为技术顾问过去后得知这些问题多少是有些惊讶的，难道现在的ISV都介么"强势"嘛？，不过从IT人员组织结构来看，客户侧确实存在"缺失"。

Allen解读：如我之前几篇文章聊到的，开发对功能负责，运维对稳定负责。客户对这一点没有感知也能理解，避免术业有专攻。但作为售前如何把这个观点（故事）讲清楚，就是售前的本事了。所以售前不仅需要有技术，还要有讲故事的能力。最终用户的root cause是本地网络环境的DNS被劫持和CDN预热问题导致。

第二天中午，我便准备好了资源采购清单报价，补充调整了相关基础架构、安全方案。部分拓扑图如下：

和BD的沟通后，我梳理了一份邮件（包含报价、方案等SLA协议）发送给了客户侧，邮件内容如下；（已和谐）

PS：做云计算服务的公司，文化水平尤其是语句通顺和意思表达上很多时候都是通过邮件来传递过去的，所以中国语言文化博大精深，我个人也是深有感触的。

文章中有个上云总体流程，也算是我们Team的思想结晶，所以还是额外提一句。团队战队比个人作战始终会强很多，所以如果读者你是一位正在择业或大学毕业的学生的话，优先考虑选薪资待遇不如考虑选个好的Team文化的。。。当然，没有什么追求就想当个萝卜的，那就无视我这个观念。并不是这样不好，每个人追求不一样。只是笔者是个90后，自然血气方刚、更活力点，得罪得罪，不喜勿喷~~~~~

接下来，相当顺利的进入到了项目的第二阶段-深度调研，【怎么落地的问题？】，基本上进入到这个阶段就离正式签单不远了，而且八九能拿下项目。

PS：流水账经过不作赘述。

划重点啦，划重点啦，以下本文的重点：

            正如我前面的文章介绍的“售前策略”，这一次我是站在客户位置去和对应的开发商去谈上云细节。

            期间一共对接公司内部五个部门（财务、后勤、人事、业务、技术），外部则有三家应用供应商，可见这个沟通量很大，也对售前做事儿是很大的考验。不过好在我是轻车熟路，虽然一路波折，但还在结果是令人皆大欢喜的。

PS：读过我前面几篇文章的读者应该会知道，其实个人是非常喜欢分析和总结经历和问题的。当你一个人承接了这个项目，项目里面有这么多沟通对象以及三方的站位问题所带来的挑战。似乎都是一些值得回味和反思的“细节”

我总自我反省，技术+沟通是可以很好结合在一起，使售前工作进展顺利，让个人价值得到提升。

我一直在尝试学习MBI的方法论和做事路子，很多时候大厂的“套路”着实值得拍手叫好。

        他们经常从组织架构聊到业务架构，再到应用架构和网络架构～～～～～～～

        PS：自上而下一层层帮助客户理清思路

          再如，传统企业在互联网时代使用了一些互联网技术，在云端更好的处理这部分业务（用户数据），既而产生数据价值，达到提升公司整体运营、业务运行效率，解决数据之间的割裂。提高数据之间的扭转问题，这就是“新XX（零售）”，然后假以情境进行佐证。

             其实不得不说，大厂的思路很强之外，更强的在于他能告诉你“公司应该用什么姿势去承载这些需要互联网技术的业务”。通俗的去讲：给你做售前技术方案咨询时，免费帮你把公司运营的咨询也做了。非常值得我们学习，进一步转化成自身的能力。

回到项目中来，差不多两个礼拜后~~~~~~

    我和销售去了客户现场，给客户汇报了我们近期的工作“日志”和项目实施计划表（就是之前我分享材料），并进行了商务上的洽谈。对话也就不到一个小时，确实很顺利。剩下的就是等客户美滋滋的打款了！

（~~~这中间省略一些人物细节分析，天天分析人物关系，人容易分裂~~(*^__^*) 嘻嘻……）

因为项目的交付工作是由云服务Team带头完成，我作为PM+架构师中间偏问责和协调，所以这里就不详细赘述交付过程，只是列出一些交付期间产生的问题以及如何解决的？

1.      腾讯云CDB（for sql），软件商实施过程中无法执行license注册，导致软件部署工期延后

root cause分析：

架构是让DB和web服务分离，通过CLB起到负载冗余作用，但CDB属于一个单独的instance，独立于windows OS运行之外，注册失败是因为CDB无法主动与软件商的license center通信导致的。

How to solve the problem?：

取消CDB部署形式，DB使用CVM单独部署（与传统部署一致）

2.      云上VPN无法与动态IP对接

root cause分析：

腾讯云的VPN-GW在指定对端peer时，只能写IP地址（无法写域名等方式），恰好客户办公室均是动态IP。

How to solve the problem?：

通过云市场采购深信服云防火墙，部署在云VPC网络内（相当于硬件防火墙VPN对接形式）。通过调整VPC路由完成部署工作

今天先分享到这里，项目还有重要的第二部分的诉求，也是我彻底搞定对方boss的一个关键需求，且需求是摸出来的，并非放在台面上让你去“解”的，这里买个关子留着下回分享。

2018年会有很多心愿完成，我也在考虑是否要成为一位开发者，因为未来或将成为开发者的天下。

                                                                                         ———————来自一位在努力路上的网工

原作者联系方式

QQ:549675970

Wechat：

    Johnny_JunJun

QZONE:

    http://user.qzone.qq.com/549675970

E-mail：

          549675970@qq.com

          allen_junjun@hotmail.com