学习笔记 - 云架构工程师/顾问型销售从业指南【1】

第一章：一份来自云架构师的从业指南

首先声明，这不是一篇技术博文，而是一篇关于云架构师（顾问型销售）软实力的学习笔记，一共有5章，在此分享1-2章，最初来源于挨踢茶馆的一门课程，很有意思，有兴趣的同学可以深入关注一下。在IT互联网公司，技术是一门硬实力，但是现在更迭非常之快，人才上后浪推前浪，年轻人会一波接一波引领纯技术的浪潮。所以，长远来看一个人的发展，必须要学会结合技术背景来沟通事务，树立品牌，合作洽谈，提出方案，解决问题，为企业赢得更多的机遇和budge，才不会被淘汰，这也IT企业中上升的重要途径。
https://iteablue.com/course/cloud-architect-and-sales-tutorial/lessons

1.1 面向业务的增益课程

技术性+管理型的经验，主要讲以下几个范围：

1. 销售型云从业者的拿单素质
2. 云架构师（售前）从入门到放弃的避“坑”记录
3. 销售视角的签单前的场景进攻分析
4. 云架构师（售前、顾问型销售）最佳实践的作战经验
5. 出场率最高的经典方案通用分解及案例描述
6. 几个客户故事的分享
7. 技术人正在尝试转型至前线或业务线的经验分享

• 面向对象：
• 关于MSP行业和云架构师
  MSP是Managed Service Provider，管理服务提供商。云架构师的基本要求是：理解云计算的价值、设计与管理、部署与监控、指定云战略与治理好云。

随着云计算市场的迅猛发展，越来越多的企业进入到云MSP领域，云MSP也呈现出多样化和差异化特征，对于整个行业来说，云MSP的选择、云服务管理发展现状、特征及趋势等成为了重要研究课题，同时企业及用户也亟需专业性、权威性的纲领文件为行业的未来发展指明方向。详情可见：http://cloud.idcquan.com/yzx/178629.shtml

职业生涯及技术储备要求

• 基础技能储备：网络NP水平以上、系统CE水平以上、云计算（阿里、腾讯、亚马逊、华为、微软）三张助理认证工程师以上。
• 进阶技能储备：网络IE、系统CA、云计算三家厂商的专家认证以上、PMP（项目管理）、CISA/CISSP（信息安全领域）、ITILV4基础、DevOps基础、容器CKA
• 高阶技能储备：业务的高嗅觉、软技能的经验体现、更高合同金额的项目经验。

1.2 关于软技能

来看一个简单的JD，highlight部分为软实力要求。
要有很深的技术沉淀，以及面对客户有效沟通的技巧。软实力在某种程度上，比硬实力更重要。

1.3 云的第一件大事儿-不要忽略迁移的重要性

如何迁移？- 包括6个内容

如何迁移？ - 4个阶段

注意，很多用户对云迁移的认知比如“平滑、无缝、零停机”是很浅显的，要做到几乎不太可能。为什么？因为企业级的用户在完成任何一次迁移之后，必须拿出30分钟乃至半天的时间来做校验、流程控制、做安全性的可控。所以一定要给用户讲停机窗口的必要性。迁移验证的环节非常重要。

1.4 设计迁移方案前的准备工作

迁移工作开展前，主要的思考路线和准备工作

八个经典模型，先自问自答，再与客户讨论

（再看）

1.5 如何设计一个迁移方案

如何面对并设计制作迁移方案？避免两难境地的功力

• 来自工程师的灵魂拷问-十几连击：

1. 有没有停机维护窗口，具体是多久？
2. 服务器、网络、存储环境（操作系统、网络、存储）
3. 对称新建迁移还是异步分批迁移？
4. 服务器规模及详细资产清单
5. 业务逻辑拓扑图、基础架构拓扑图
6. 数据库环境及详细环境清单
7. 运维权限以及联系清单
8. 迁移安全要求
9. 迁移完工时间预期？
10. 域名备案以及DNS相关管理权限联系人
11. 应用相关方（第三方、用户、渠道供应商）确认耦合
12. 迁移后架构是否有重构诉求？架构解耦分层
13. 设备资源闲置优化分析上云诉求？
14. 备份及灾备要求（RTO/RPO）
15. 是否有售后服务需求，比如需要专人管理

1.6 如何判断哪类迁移项目不能接

苦茶老师讲了几个小故事，但概括起来就是：不在工作服务范围内的活儿不能接。业务人员要多和工程师沟通，去明确潜在的交付风险。
云架构师（偏售前）的价值及时影响客户做出有利于”我方“的决策。(要懂技术、懂风险，懂交付）
云架构师 <= 业务代表 <= 销售人员 <= 代表公司体系 <= 代表售前 <= 交付团队，项目经理，各个组织部门.

• 做好可视化需求分析：

1. 识别（ISV) 软件供应商
2. 以客户名义与WMS供应商取得联系：交流应用的底层框架、web应用的逻辑结构等
3. 确认数据中心网格结构情况：分析子网重叠和VPN（or专线）对接的可行性
4. 进一步确认数据落盘的控制预期：保存时长、频率、哪些为关键/非关键？
5. 确认用户上线时间表：预期内合理分解工期安排
6. 明确工作服务范围：规避项目是否有溢出服务清单需要我们关注或超出服务边界的工作项
7. 分析用户上云的适配性：给出合理的围绕成本、访问控制、业务适配性等反馈
8. 描述实施工作内容：主动描述该项目交付细节（含项目团队的责任担当）
9. 最终输出经过梳理的内容：会议纪要，并发送至领导，抄送相关同事侧确认

1.7 如何做迁移方案？案例样板分享

第一步 - 解读迁移方法论

第二步 - 介绍企业级解决方案

第三步 - 演示迁移示意架构匹配需求

第四步 - 介绍交付周期及服务配置

• 介绍收集的需求
• 介绍我测算的交付周期
• 介绍我们的Delivery Team

第五步 - 介绍企业实力 & 客户案例

休息肉时间。总之，做迁移项目，需要学会用框架、思维逻辑、方法论帮助自己去思考，去解决工作效率的问题。业务人员要多思考技术人员的痛点，技术人员也要多从业务角度思考。这样可以帮助你在组织里获得更棒的资源知识。

第二章：软技能之建立气质-如何快速建立识别需求气质

2.1 甲乙服务商平常如何获得商机？

MSP 服务商平常如何获得项目线索？

甲乙服务商平常如何获得商机？
企业营收业务主要来自以下几个方面：

• 百度投放/关键字/竞价排名
• 联盟社区会员，各类大会名单
• 外部/自由电话销售/渠道/团队

产出商机后，项目商机录入前常见的归类分析

A. 云资源类 （云服务器，带宽，侧重IaaS）
B. 运维服务类（传统外包2.0）
C. 云管平台类（工具销售类，侧重SaaS）
D. 迁移服务类（最重要的挑战）
E. 安全服务类（不是售卖产商的服务产品。而是完整的安全加固的解决方案）
F. 集成项目类（包含以上所有）
现在大部分MSP服务商收入结构分析
产出商机后，项目商机录入常见做法。把需求可视化，一定要运用好表格。

迁移方案“三部曲”

2.2 试着分析你所在公司的经营和竞争力模型

针对当前你了解公司的情况，回答以下几个问题。然后你就会清楚这个公司是否值得你继续发展下去。

1. 有核心（研发）产品（团队）吗？
2. 有自建技术（售后）服务（支撑）团队吗？
3. 我们的业务机会（商机）怎么获取？

2.3 气质的“伪装”之礼仪的“三板斧”

首先，过硬的项目交付的经验 - 这是前提。
其次，多以老板的心态看待项目，尤其要多关注失败的项目复盘 - 这是sense的直接输入。
最后，用项目经理的视角，全篇看待整个项目，并事无巨细的研究过程、把握细节- 这是最有价值的间接输入。

综上，不断学习前沿技术，用业务型思维与用户交流和张罗事就可。

2.4 顾问型销售工程师需求识别正确姿势

• 接到销售任务
• 现场/远程沟通需求准备方案
• 方案交叉互动，完善方案
• 现场交流方案，解读方案
• 二次方案答疑，确认方案
• 促成客户成功，达成合作

论模型工作方法的重要意义

什么适合公有云？

1. 适合公有云环境的工作负载通常对所有考量因素的要求都最低
2. 具有以下一个或多个特征的工作负载或组织适合使用公有云

• 业务中需要电子邮件、文件共享等独特的公有云服务
• 行业数据监管或合规要求较少
• 影响业务的数据监管有限
• 客户群具有全球性
• 有一套成熟的SaaS解决方案，用于处理工作负载
• 需要访问远程位置的工作负载
• 组织的IT基础设施投资有限
• IT资源量和本地化数据中心技能组合缩减
• 即使与私有数据中心断开连接，业务部门也不会受到影响
• 组织中的应用开发人员需要全球可用的通用用户界面

什么适合私有云？

1. 适合私有云环境的工作负载通常对所有考量因素都有着最高的要求，因此非常适合本地云或私有云
2. 具有以下一个或多个特征的工作负载或组织适合使用私有云

• 业务要求低延迟和本地数据
• 严格的公司数据监管或合规数据
• 对存储敏感数据的位置有监管要求
• 存在针对业务数据和IP控制的安全要求
• 国家或地区对数据限制或主权有相关规定，例如数据保护条例（GDPR）
• 应用倾向于规避服务级别故障风险
• 组织需要在多个地理位置投资私有数据中心
• 业务无法接受获取洞察的时遭受延迟和数据传输成本高昂的情况。
• 需要加速从本地化数据中心提取实时洞察
• 已在私有数据中心进行IT投资者和资源部署
• 现有本地开发团队负责的工作，负载无需具有全球规模
• 需要满足限制性的服务级别协议

项目跟进过程中的几个重要实用工具
（年轻的售前&顾问型销售，有火力有态度，但缺少一些实战经验，这时候靠一些工具，则能更快达到企业服务的气质）

• 商机胜率评估矩阵
• 项目个人工作日志
• 问题日志表
• 需求跟踪表：客户提出来的假设性的需求，对应到个人提出的要求。

2.5 错误示范之抓住“xu求”一顿输出

虚求：X（一般来自新部门）

• 技术极端自嗨
• 流程管理地震
• 组织频繁调整

嘘求：X

• 经验惯性作祟
• 要政绩非收益
• 空降高管思维

需求： √

• 一线场景赋能
• 以用户为中心
• 需求思维优先

2.6 主动建立“不败”之沟通模型

潜在的转化风险

沟通过程状态	失败沟通信号经验
“死人”脸并带有沉默	无表情，无感且对不上眼
手注意力不集中，反复解锁电话	频繁走神，不关注不时打断你并带有“调侃”语气
希望加快速度，告知时间有限	催促，隐含勿占用过多时间
主人沉默，助理or其他发言	非直接拒绝，客户关系的最后一层窗户纸

微场景处理

• 办公室环境很好啊，在我们为您汇报解决方案前，您能否先带我们简单参观下公司| 在开始前，您能否先介绍下您这边的情况，这个有利于我们高效的沟通。
• 逐条分析需求和解决方案，应适当主动提问，征询意见，并表达类似“我这样理解是否正确，xxx总”
• 心态保持平和，主动澄清对我们的“误解”以及我们的一些不足的地方。
• 处理破冰阶段，发资料，刷纯在感，主动争取约工程师或领导线下非正式见面交流，一探究竟。

潜在的转化机会

沟通过程状态	成功沟通信号经验
“死人”脸并带有沉默	“有感情有温度”的神态，呈“和谐、欣赏”的神态
手注意力不集中，反复解锁电话	专注，几乎不碰手机，呈“思考”状
不时打断你并带有“调侃”语气	不时点头做记录，礼貌地表示想做一些补充，呈“好奇、活跃”的会议气氛
希望加快速度，告知时间有限	言简意赅地说明，有议程在后面。但语气开放并想听下方，呈“好奇、答疑解惑”的状态
主人沉默，助理or其他发言	助理说明需求，领导不断地纠正或做进一步补充和解释，呈似“头脑风暴”的状态

2.7 责任共担模型价值的妙处

每个厂商都有自己的一套责任共担模型，实际上类似免责声明。这其实与SLA协议中的免责条款是一个作用，目的在于“教育”用户。

做技术服务的企业，精准表达自身价值图解：

2.8 初次印象的邮件收尾之重要性

重要的一步：需求收集踩的七七八八，接着要为第一次拜访留下一个更好的收尾印象

2.9 你会做云计算的预算表吗？

拜访结束了，预算表如何做？

主要问题	Value	Value	Value
300+的云服务产品如何搭配？	多云选择下，工作量指数上升？	国内国外付费方式的区别？	后付费产品如何设计预算表？
有遗漏需求风险？	“开门见价”	技术服务如何快速“度量”	官网报价还是二次折扣价格？

2.10 以下场景若是你当如何应对

场景一

场景二

请大家试着用我们前两章介绍的方法论来理解并作出解答。