04-10-05 模糊语言 - 学习笔记
04-10-05 模糊语言 - 学习笔记
章节信息
核心主题:模糊词汇、歧义、定义不清、情感词汇、如何澄清概念
学习目标:学会识别模糊语言,掌握澄清概念的方法,避免误解
关键要点:模糊词识别、歧义处理、需求澄清、文档歧义消除
核心概念
1. 什么是模糊语言?
定义
模糊语言(Ambiguous Language):含义不明确、可能有多种理解的词汇或表达。
危害:
- 造成沟通误解
- 导致需求偏差
- 引发技术方案错误
- 浪费时间和资源
技术场景中的常见问题:
产品说:"优化一下性能" 开发理解: - 理解1:优化启动速度? - 理解2:优化内存占用? - 理解3:优化流畅度? - 理解4:优化网络请求? 结果:理解不一致,做错需求模糊语言的三种类型
类型1:歧义词(多义词)
同一个词,有多种含义 例:"优化" - 可能指性能优化 - 可能指代码优化 - 可能指用户体验优化 - 可能指视觉优化 例:"快" - 启动快? - 响应快? - 开发快? - 学习快?类型2:程度词(模糊程度)
没有明确标准的程度描述 例:"性能很好" - 多好算好? - 和什么比? - 好在哪里? 例:"代码有点乱" - 多乱算乱? - 用什么标准衡量? - 乱的后果是什么?类型3:情感词(主观评价)
带有主观色彩的评价 例:"这个方案很优雅" - 什么叫优雅? - 优雅的标准是什么? - 为什么重要? 例:"体验不好" - 哪里不好? - 不好到什么程度? - 如何衡量?2. 技术领域常见的模糊词汇
类别1:性能相关
模糊词:"优化性能" 问题: - 哪方面性能? - 优化到什么程度? - 如何衡量? 澄清: **错误做法** - "需要优化性能" **正确做法** - "需要将冷启动时间以内" **正确做法** - "需要将列表滑动帧率从40fps提升到55fps以上" **正确做法** - "需要将内存占用从200MB降低到150MB以下"模糊词:"快"/"慢" 问题: - 多快算快? - 和什么比? - 有具体指标吗? 澄清: **错误做法** - "启动太慢了" **正确做法** - "启动时间3.5秒,行业平均2秒,我们落后75%" **正确做法** - "用户操作到界面响应平均500ms,目标是200ms以内"模糊词:"卡顿" 问题: - 什么场景卡顿? - 卡顿的定义是什么? - 多卡算卡? 澄清: **错误做法** - "页面有点卡" **正确做法** - "列表滑动时,帧率经常掉到30fps以下,有明显掉帧" **正确做法** - "点击按钮后,界面冻结500ms才响应"类别2:质量相关
模糊词:"代码质量差" 问题: - 差在哪里? - 用什么标准衡量? - 有多差? 澄清: **错误做法** - "代码质量不行" **正确做法** - "单个类超过2000行,圈复杂度超过50" **正确做法** - "单元测试覆盖率只有15%" **正确做法** - "最近3个月bug率上升50%"模糊词:"不好维护" 问题: - 为什么不好维护? - 不好到什么程度? - 影响是什么? 澄清: **错误做法** - "这个模块不好维护" **正确做法** - "修改一个功能平均影响3个模块" **正确做法** - "新人理解这个模块平均需要3天" **正确做法** - "每次修改都需要回归测试所有功能"模糊词:"技术债务" 问题: - 具体是什么债务? - 有多严重? - 影响是什么? 澄清: **错误做法** - "技术债务很多" **正确做法** - "有12个TODO标记超过6个月未处理" **正确做法** - "4个核心类违反单一职责原则" **正确做法** - "没有单元测试,修改风险高"类别3:功能相关
模糊词:"优化" 问题: - 优化什么? - 优化到什么程度? - 如何验收? 澄清: **错误做法** - "优化一下登录流程" **正确做法** - "减少登录步骤从4步到2步" **正确做法** - "增加记住密码功能,下次自动登录" **正确做法** - "支持指纹/面部识别快速登录"模糊词:"改进"/"增强" 问题: - 改进什么? - 改进的目标是什么? - 如何衡量改进? 澄清: **错误做法** - "改进用户体验" **正确做法** - "将页面加载时间" **正确做法** - "增加加载进度提示" **正确做法** - "优化错误提示,让用户知道如何操作"模糊词:"支持" 问题: - 支持什么场景? - 支持到什么程度? - 有哪些限制? 澄清: **错误做法** - "需要支持大文件上传" **正确做法** - "支持上传最大100MB的文件" **正确做法** - "支持断点续传" **正确做法** - "支持后台上传" **正确做法** - "支持上传进度显示"类别4:程度相关
模糊词:"很多"/"大量"/"经常" 问题: - 具体多少? - 频率如何? - 有数据吗? 澄清: **错误做法** - "很多用户反馈卡顿" **正确做法** - "30%的用户(约3000人)反馈卡顿" **正确做法** - "应用市场1星评价中,40%提到卡顿" **错误做法** - "经常崩溃" **正确做法** - "崩溃率0.5%,每天约500次崩溃" **正确做法** - "最近7天崩溃率上升了50%"模糊词:"简单"/"复杂" 问题: - 简单的标准是什么? - 对谁简单? - 简单在哪里? 澄清: **错误做法** - "这个需求很简单" **正确做法** - "预计1天完成开发,0.5天测试" **正确做法** - "不涉及复杂逻辑,主要是UI调整" **正确做法** - "新人也能独立完成" **错误做法** - "这个技术很复杂" **正确做法** - "需要学习2周才能掌握基本用法" **正确做法** - "涉及5个子系统的交互" **正确做法** - "出问题后定位困难,平均需要4小时"模糊词:"重要"/"关键"/"核心" 问题: - 有多重要? - 为什么重要? - 不做会怎样? 澄清: **错误做法** - "这个功能很重要" **正确做法** - "这个功能是MVP必备,不做无法上线" **正确做法** - "预计能的用户留存" **正确做法** - "竞品都有这个功能,我们没有会失去竞争力"3. 模糊语言的危害
危害1:需求理解偏差
案例:图片上传功能
**错误做法** - 模糊的需求 产品经理:"需要支持图片上传" 开发理解1: - 支持单张图片上传 - 最大1MB - 只支持JPG 开发理解2: - 支持多张图片上传 - 最大10MB - 支持JPG/PNG 开发理解3: - 支持批量上传 - 不限大小 - 支持所有格式 结果: 做完后发现和产品要求不一致 需要返工,浪费时间 **正确做法** - 清晰的需求 产品经理:"需要支持图片上传功能" 明确说明: 1. 数量:一次最多上传9张 2. 大小:单张最大5MB 3. 格式:支持JPG、PNG、WebP 4. 来源:支持拍照和相册选择 5. 压缩:超过1MB自动压缩 6. 进度:显示上传进度 7. 失败:失败后可重传 开发理解:完全一致 结果:一次做对危害2:技术方案偏差
案例:性能优化
**错误做法** - 模糊的需求 老板:"App性能不行,优化一下" 技术A的理解: - 优化启动速度 - 花了2周优化启动 - 启动 老板反馈: "我说的是页面卡顿,不是启动速度!" 结果:做了无用功 **正确做法** - 清晰的沟通 老板:"App性能不行" 技术Leader问: 1. 具体哪方面性能? 2. 用户反馈是什么? 3. 有数据支撑吗? 4. 期望优化到什么程度? 老板澄清: "用户反馈页面滑动卡顿,应用市场 有很多1星评价提到这个问题。希望 能解决卡顿问题。" 技术方案: - 定位:列表滑动卡顿 - 目标:帧率从40fps提升到55fps+ - 方案:RecyclerView优化+图片加载优化 - 验收:用户反馈卡顿投诉 结果:方向正确,解决了实际问题危害3:验收标准不一致
案例:代码重构
**错误做法** - 模糊的目标 Tech Lead:"把登录模块重构一下" 开发理解: - 简单重构一下代码结构 - 花了3天 Tech Lead反馈: "我说的是全面重构,拆分模块, 增加单元测试,应用设计模式!" 开发心态: "为什么不早说清楚!" **正确做法** - 清晰的目标 Tech Lead:"需要重构登录模块" 明确目标: 1. 拆分:从一个类拆分成5个职责类 2. 测试:单元测试覆盖率达到70% 3. 设计:应用策略模式处理不同登录方式 4. 质量:圈复杂度降到10以下 5. 文档:补充核心类的文档 6. 时间:1周完成 验收标准: □ 5个类都不超过500行 □ 测试覆盖率≥70% □ 策略模式实现完成 □ 圈复杂度≤10 □ 核心类有注释 结果:目标清晰,验收标准明确4. 如何澄清模糊语言?
方法1:追问细节
追问框架:
听到模糊词时,立即追问: 1. 是什么? "你说的'优化'具体指什么?" 2. 为什么? "为什么这个很重要?" 3. 多少? "具体的指标是多少?" 4. 什么标准? "什么算'好',什么算'不好'?" 5. 如何衡量? "怎么验证是否达到目标?" 6. 有例子吗? "能举个具体的例子吗?"Android场景示例:
【场景:产品需求】 产品:"需要优化一下启动速度" **错误做法** - 不追问,直接开发 - 可能理解错误 - 浪费时间 **正确做法** - 追问澄清 开发问: 1. "现在启动多慢?(是什么)" 产品:"大概3秒多" 2. "用户反馈了吗?(为什么)" 产品:"对,30%的1星评价提到启动慢" 3. "期望优化到多少?(多少)" 产品:"2秒以内,和竞品一样" 4. "怎么算优化成功?(标准)" 产品:"启动时间≤2秒,用户投诉" 5. "有时间要求吗?(约束)" 产品:"下个版本,还有3周" 6. "优先级如何?(优先级)" 产品:"P0,必须做" 澄清后的需求: ┌────────────────────────────────┐ │ 需求:启动速度优化 │ ├────────────────────────────────┤ │ 当前:3.2秒 │ │ 目标:≤2.0秒 │ │ 原因:30%的1星评价提到启动慢 │ │ 验收:启动≤2秒,投诉 │ │ 时间:3周 │ │ 优先级:P0 │ └────────────────────────────────┘ 清晰明确,可以开始设计方案了!方法2:举例说明
使用例子澄清概念:
【场景:技术讨论】 A:"这个方案更优雅" **错误做法** - 直接接受 - 不知道"优雅"是什么意思 **正确做法** - 要求举例 B:"你说的'优雅'是指什么?能举个例子吗?" A澄清: "比如,现在的代码是这样: ```java if (type == 1) { // 100行代码 } else if (type == 2) { // 100行代码 } else if (type == 3) { // 100行代码 }我说的’优雅’方案是这样:
Strategystrategy=StrategyFactory.create(type);strategy.execute();优雅的意思是:
- 代码更简洁(从300行到5行)
- 扩展性更好(新增类型不改主逻辑)
- 符合开闭原则(对扩展开放,对修改关闭)"
B:“明白了,你说的’优雅’是指代码简洁
且扩展性好。这个我同意。”
通过例子,双方理解一致!
#### 方法3:量化指标 **将模糊词转化为可衡量的指标**:模糊词 → 量化指标
错误做法- “性能要好”
正确做法- “启动时间≤2秒,列表滑动帧率≥55fps”
错误做法- “代码要好”
正确做法- “圈复杂度≤15,单元测试覆盖率≥70%”
错误做法- “很多用户反馈”
正确做法- “300个用户反馈,占比30%”
错误做法- “经常崩溃”
正确做法- “崩溃率0.5%,每天500次崩溃”
错误做法- “不好维护”
正确做法- “修改平均影响3个模块,新人需要3天理解”
错误做法- “简单需求”
正确做法- “预计1天开发,0.5天测试,不涉及复杂逻辑”
#### 方法4:对比澄清 **通过对比明确含义**:【场景:性能要求】
产品:“性能要好”
开发:“和什么比?好到什么程度?”
产品澄清(通过对比):
"和竞品A对比:
- 竞品A启动时间:1.8秒
- 我们目标:≤2.0秒(接近竞品A)
和行业标准对比:
- 行业平均:2.0秒
- 我们目标:达到行业平均
和当前状况对比:
- 当前:3.2秒
- 目标:2.0秒()"
通过对比,目标清晰!
#### 方法5:负面清单 **明确什么不是**:【场景:架构设计】
A:“需要一个简单的架构”
B:“'简单’是指什么?”
A澄清(负面清单):
"简单是指:
✓ 不用复杂的依赖注入框架(不用Dagger)
✓ 不用响应式框架(不用RxJava)
✓ 不用Clean Architecture的多层抽象
✓ 团队能快速理解(新人2天能上手)
但要包括:
✓ 基本的MVVM分层
✓ ViewModel + LiveData
✓ Repository层
✓ 遵循SOLID原则"
B:“明白了,'简单’是指不过度设计,
但保持基本的架构”
通过负面清单,澄清了"简单"的含义!
--- ## 本章总结 模糊语言是技术沟通中最隐蔽也最常见的障碍。它不像逻辑谬误那样明显，却能让大量讨论沦为无效交流。 **五种澄清方法速查**： | 方法 | 一句话概括 | 适用场景 | |------|-----------|---------| | 定义法 | "你说的X是什么意思？" | 专业术语、抽象词 | | 对比法 | "和什么比？" | 比较级、程度词 | | 量化法 | "好到什么程度？" | 性能、质量描述 | | 场景法 | "什么时候用？" | 通用性描述 | | 负面清单 | "什么不是？" | 开放性描述 | **实战心法**： - 不要怕问"这是什么意思" —— 问出来比猜错好 - 不要怕被问"这是什么意思" —— 被追问说明对方认真听了 - 模糊不可怕，可怕的是大家以为自己理解了 - 一次讨论前先对齐关键词的定义，效率会大幅提升 记住：**模糊的语言产生模糊的讨论，清晰的语言产生清晰的决策**。技术人最该学会的技能之一，是"把话说清楚"。