作为一名云计算的售前工程师，当客户给出需求之后，售前工程师应该如何做？ ...

作为云计算售前工程师，在客户提出需求后，需通过系统化的方法将客户需求转化为可落地的技术方案，同时创建信任并推动项目进展。以下是关键步骤和计谋：

---

一、需求深度剖析阶段

1. 需求澄清与细化

• 5W1H提问法：
  
  
  
  • Why：确认核心动机（如政策合规/性能瓶颈/资源优化）。
    "您提到要替换VMware，是出于信创要求还是现有架构扩展性题目？"
    
  • What：明白范围（哪些系统迁徙/新建）。
    "本次信创改造涉及哪些业务系统？优先级如何？"
    
  • How：了解技术束缚（兼容性/迁徙窗口/性能指标）。
    "数据库是否需要从Oracle迁徙到国产数据库？容忍多长停机时间？"
    
  
  
• 痛点分级：
  
  
  
  • 将客户需求分为Must Have（如信创合规）和Nice to Have（如未来混淆云支持），聚焦关键题目。
    
  
  

2. 技术风险评估

• 兼容性矩阵：
     客户现状信创要求风险点办理方案VMware假造机鲲鹏芯片指令集差异导致性能降落提供ARM架构POC测试CentOS系统麒麟OS应用依靠库不兼容容器化改造方案
  
• 隐藏需求挖掘：
  
  
  
  • 通过类比提问发现潜在需求：
    "其他高校迁徙时普遍关注数据加密，贵校是否有类似要求？"
    
  
  

---

二、方案计划阶段

1. 架构计划原则

• 信创适配三层模型：
  
  1. graph TD
  2.   A[基础设施层] -->|海光服务器+麒麟OS| B[信创云平台]
  3.   B -->|ZStack信创版| C[应用层]
  4.   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企服之家，中国第一个企服评测及商务社交产业平台。