⚠️ 安全警告:本技能的示例可能涉及订单号、支付金额、截图、身份证、手机号等敏感数据。 实际使用时请勿粘贴真实生产数据、客户信息或财务凭证;测试前应脱敏/掩码处理。 本技能仅在 workspace/ 输出评估文件,不持久化、不外传、不跨会话复用。
干系人沟通
核心原则
同样一个Bug,跟不同人说完全不同的表述方式——说对方关心的,而不是你关心的。
三类沟通模式
模式1:跟开发说(技术视角)
沟通重点:
├─ 精确的复现步骤:每一步操作
├─ 日志/截图:错误信息、异常堆栈
├─ 根因推测:可能的原因
├─ 环境信息:浏览器、系统、配置
└─ 影响范围:哪些功能受影响
沟通格式:
[Bug标题] [严重程度]
复现步骤:
1. ...
2. ...
3. ...
错误日志:[日志内容]
截图:[截图描述]
推测原因:[原因分析]
影响范围:[影响描述]
模式2:跟PM说(业务视角)
沟通重点:
├─ 用户影响:哪些用户受影响
├─ 严重程度:业务影响多大
├─ 修复优先级:建议优先级
├─ 对其他功能的阻塞
└─ 预计修复时间
沟通格式:
[Bug标题]
影响:[用户范围]
严重程度:[业务影响]
优先级:[P0-P3]
阻塞:[是否阻塞其他功能]
预计修复:[时间估算]
模式3:跟老板说(决策视角)
沟通重点:
├─ 业务影响:对业务的影响
├─ 发布风险:是否影响发布
├─ 建议决策:建议怎么做
├─ 要什么资源:需要什么支持
└─ 时间节点:什么时候能解决
沟通格式:
[问题描述]
业务影响:[影响描述]
发布风险:[风险评估]
建议决策:[建议方案]
资源需求:[需要什么]
时间节点:[时间计划]
高危表达对比
| 场景 | 不要说 | 可以说 |
|---|---|---|
| Bug修复延迟 | "开发没时间" | "这个Bug涉及核心逻辑,需要更多时间确保质量" |
| 测试延期 | "测试做不完" | "为了保证质量,建议延长2天测试时间" |
| 质量问题 | "质量很差" "这个功能有风险" | "这个功能需要更多测试时间" |
| 资源不足 | "人不够" | "为了按时交付,建议增加1名测试人员" |
| 需求变更 | "需求又变了" | "这个变更会影响测试范围,建议重新评估时间" |
沟通场景模板
场景1:Bug评审会
参会角色:开发、测试、PM
沟通内容:
├─ 测试:Bug描述、复现步骤、影响范围
├─ 开发:根因分析、修复方案、修复时间
└─ PM:优先级评估、资源协调
场景2:发布评审会
参会角色:开发、测试、PM、运维
沟通内容:
├─ 测试:测试结果、质量评估、风险提示
├─ 开发:变更内容、技术风险
├─ PM:业务影响、发布决策
└─ 运维:部署方案、回滚方案
场景3:质量报告
报告对象:老板、PM
报告内容:
├─ 质量指标:缺陷密度、漏测率
├─ 质量趋势:改善/稳定/恶化
├─ 风险提示:高风险区域
└─ 改进建议:建议措施
应用场景
发现一个支付Bug,需要同步给不同角色 → 跟开发说:技术细节+复现步骤+日志截图(定位问题) → 跟PM说:影响用户数+严重程度+修复时间(评估影响) → 跟老板说:一句话结论+业务影响+风险等级(决策依据)
Bug评审会上开发说"这个没问题" → 沟通场景应对:用数据和截图说话,避免"我觉得",使用"数据显示"
自检清单
沟通完成后检查:
- 是否针对受众定制了信息?
- 是否包含了对方需要的决策信息?
- 是否避免了高危表达?
- 是否达成了沟通目标?
检查清单
- 受众角色是否识别?
- 沟通策略是否定制?
- 关键信息是否突出?
- 推动方案是否可行?
- 反馈机制是否建立?
评论
加载中…