作为一名云计算的售前工程师，当客户给出需求之后，售前工程师应该如何做？
作为云计算售前工程师，在客户提出需求后，需通过系统化的方法将客户需求转化为可落地的技术方案，同时创建信任并推动项目进展。以下是关键步骤和计谋：一、需求深度剖析阶段
1. 需求澄清与细化
[*] 5W1H提问法：
[*] Why：确认核心动机（如政策合规/性能瓶颈/资源优化）。
"您提到要替换VMware，是出于信创要求还是现有架构扩展性题目？"
[*] What：明白范围（哪些系统迁徙/新建）。
"本次信创改造涉及哪些业务系统？优先级如何？"
[*] How：了解技术束缚（兼容性/迁徙窗口/性能指标）。
"数据库是否需要从Oracle迁徙到国产数据库？容忍多长停机时间？"
[*] 痛点分级：
[*] 将客户需求分为Must Have（如信创合规）和Nice to Have（如未来混淆云支持），聚焦关键题目。
2. 技术风险评估
[*] 兼容性矩阵：
客户现状信创要求风险点办理方案VMware假造机鲲鹏芯片指令集差异导致性能降落提供ARM架构POC测试CentOS系统麒麟OS应用依靠库不兼容容器化改造方案
[*] 隐藏需求挖掘：
[*] 通过类比提问发现潜在需求：
"其他高校迁徙时普遍关注数据加密，贵校是否有类似要求？"
二、方案计划阶段
1. 架构计划原则
[*] 信创适配三层模型：
graph TD
A[基础设施层] -->|海光服务器+麒麟OS| B[信创云平台]
B -->|ZStack信创版| C[应用层]
C -->|MySQL替代Oracle| D[业务系统]
[*] 差异化计划：
[*] 对比友商方案，突出自身上风：
"相比华三的集中式存储，我们的分布式存储（ZBS）可降低单点故障风险，这是XX大学的实测数据..."
2. 价值量化呈现
[*] ROI计算示例：
项目现有方案（VMware）ZStack方案3年TCO￥120万￥80万故障规复时间4小时15分钟
三、客户沟通计谋
1. 技术交换框架（STAR法则）
[*] Situation：复述客户现状
"您提到A校区数据中心近期发生过硬件故障..."
[*] Task：明白核心任务
"这次改造需要同时满足信创要求和业务连续性..."
[*] Action：方案演示
"我们发起分三阶段实行，这是架构图..."
[*] Result：案例佐证
"某理工院校同样场景下实现了零停机迁徙..."
2. 异议处理技巧
[*] LSCPA模型：
[*] Listen：倾听质疑
"您担心鲲鹏芯片性能不敷？"
[*] Share：共情回应
"确实有客户最初也有类似顾虑..."
[*] Clarify：技术解释
"这是SPEC CPU2017测试数据，海光7285相比Intel 6248性能差距仅8%..."
[*] Propose：办理方案
"我们可以安排测试环境验证您的关键应用..."
[*] Ask：确认继承度
"您觉得这个验证方案是否可行？"
四、后续推进动作
[*] 交付物清单：
[*] 1周内提供《信创适配评估报告》
[*] 2周内完成POC环境搭建
[*] 决定链渗透：
[*] 通过技术交换识别关键决定人（如信息科科长分管采购，副校长关注政策合规）
[*] 风险预控：
[*] 提前预备《迁徙回滚方案》消除客户顾虑
五、核心本领要求
[*] 技术深度：
[*] 掌握信创生态图谱（芯片/OS/中心件适配关系）
[*] 业务理解：
[*] 熟悉教育行业等保2.0、信创考核指标
[*] 软技能：
[*] 能用"电梯演讲"（30秒说清方案差异）
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]