04-10-04 价值观冲突 - 学习笔记章节信息核心主题:价值观假设、描述性假设、价值观冲突、假设识别方法学习目标:学会识别隐藏的价值观假设,理解价值观冲突对决策的影响关键要点:价值观优先级、假设的识别、团队决策中的价值观冲突、技术与业务的平衡核心概念1. 什么是价值观假设?定义价值观假设(Value Assumptions):在论证中未明说的、关于什么更重要的隐含信念。关键特征:通常不明确说出来涉及优先级判断不同人可能有不同价值观影响结论的形成示例:结论:我们应该用最新的技术栈 隐含的价值观假设: - 创新性 稳定性 - 技术领先 成本控制 - 学习新技术 快速交付 如果你的价值观不同: - 稳定性 创新性 → 可能不同意这个结论价值观假设 vs 描述性假设┌──────────────────────────────────────────┐ │ 价值观假设 描述性假设 │ ├──────────────────────────────────────────┤ │ 关于应该 关于是什么 │ │ 涉及优先级 涉及事实 │ │ 价值判断 事实判断 │ │ 主观性强 相对客观 │ │ 难以验证 可以验证 │ │ │ │ 例子: │ │ 性能功能 用户量会增长 │ │ 创新稳定 团队能学会Kotlin │ │ 体验成本 重构不会引入bug │ └──────────────────────────────────────────┘Android场景示例:【场景:技术选型】 结论:应该用Flutter而不是原生Android 价值观假设: ✓ 跨平台 性能 ✓ 开发效率 用户体验 ✓ 统一代码 平台特性 描述性假设: ✓ Flutter性能足够好 ✓ 团队能快速学会Flutter ✓ Flutter生态成熟 ✓ 不需要太多原生功能 区别: - 价值观假设:主观判断,不同团队可能不同 - 描述性假设:客观判断,可以验证真假2. 常见的价值观冲突冲突1:创新 vs 稳定创新优先:观点:我们应该尝试新技术 价值观: - 技术领先很重要 - 学习新技术能提升团队 - 创新能带来竞争优势 决策倾向: - 愿意尝试新技术 - 接受一定风险 - 注重长期收益稳定优先:观点:我们应该用成熟技术 价值观: - 稳定性最重要 - 避免不必要的风险 - 保证项目按时交付 决策倾向: - 倾向成熟方案 - 规避风险 - 注重短期交付Android案例:【场景:是否采用Jetpack Compose】 创新派: 应该用Compose,这是未来趋势 → 价值观:创新 稳定 稳定派: 应该继续用XML,更稳定可靠 → 价值观:稳定 创新 平衡派: 新功能用Compose,旧功能保持XML → 价值观:平衡创新和稳定冲突2:性能 vs 开发效率性能优先:观点:应该手写代码,不用框架 价值观: - 性能是最重要的 - 用户体验不能妥协 - 宁可多花时间也要优化 决策倾向: - 手写优化代码 - 避免重型框架 - 注重每一个性能细节效率优先:观点:应该用框架,提高开发效率 价值观: - 开发效率更重要 - 快速迭代很关键 - 性能够用就行 决策倾向: - 使用成熟框架 - 接受一定性能损失 - 注重快速交付Android案例:【场景:图片加载方案】 性能派: 应该自己实现,Glide太重了 → 价值观:性能 开发效率 → 假设:性能差异很重要 效率派: 应该用Glide,稳定高效 → 价值观:开发效率 微小性能差异 → 假设:Glide性能足够好 数据驱动: 测试显示Glide性能差距5%,但能节省2周开发时间 → 基于数据做决策冲突3:用户体验 vs 技术债务用户体验优先:观点:先实现功能,代码质量可以后面优化 价值观: - 用户体验最重要 - 快速响应需求 - 市场机会稍纵即逝 决策倾向: - 快速开发新功能 - 可以容忍技术债务 - 重视用户反馈技术质量优先:观点:先重构代码,再开发新功能 价值观: - 代码质量很重要 - 技术债务要控制 - 长期维护很关键 决策倾向: - 先优化再开发 - 不容忍低质量代码 - 重视长期可维护性Android案例:【场景:产品要求紧急上线新功能】 产品视角: 下周必须上线,用户在等 → 价值观:用户需求 代码质量 → 假设:技术债务可以后面还 技术视角: 代码太乱,先重构再开发 → 价值观:代码质量 上线速度 → 假设:技术债务会影响后续开发 平衡方案: 用2天重构关键模块,再用3天开发新功能 → 平衡质量和速度冲突4:业务价值 vs 技术追求业务价值优先:观点:这个技术很好,但不符合业务需求 价值观: - 业务价值最重要 - 技术服务于业务 - 投入产出比要高 决策倾向: - 选择业务价值最大的方案 - 技术够用就行 - 重视ROI技术追求优先:观点:应该用最好的技术,追求技术卓越 价值观: - 技术追求很重要 - 技术领先是竞争力 - 技术人应该有追求 决策倾向: - 选择技术最优的方案 - 追求技术完美 - 重视技术积累Android案例:【场景:架构设计】 技术追求: 应该用Clean Architecture MVVM Dagger RxJava → 价值观:技术完美 快速交付 → 风险:过度设计,学习成本高 业务导向: 简单的MVP就够了,快速验证需求 → 价值观:快速验证 架构完美 → 风险:技术债务积累 合理平衡: 根据项目复杂度选择,简单项目用简单架构 → 价值观:适度设计3. 如何识别价值观假设?方法1:寻找价值观词汇常见价值观词汇:重要性词汇:- 应该/不应该 - 必须/不能 - 重要/次要 - 优先/其次 - 关键/无关紧要评价性词汇:- 好/坏 - 对/错 - 合理/不合理 - 优秀/糟糕 - 正确/错误程度词汇:- 更.../较... - 最.../最不... - 非常/一般 - 显著/微小Android场景示例:我们应该用Kotlin,因为它更优雅 → 应该更 → 价值判断 → 隐含假设:优雅性是重要的 性能优化很重要,必须优先做 → 重要必须优先 → 价值判断 → 隐含假设:性能 其他 这个方案不够好,需要重新设计 → 不够好 → 价值判断 → 隐含假设:当前方案未达到某个标准方法2:问为什么重要?追问技巧:观点:我们应该优化启动速度 ↓ 问:为什么启动速度重要? 答:因为影响用户体验 ↓ 问:为什么用户体验重要? 答:因为用户体验影响留存 ↓ 问:为什么留存比其他指标重要? 答:因为留存是长期增长的基础 ↓ 发现价值观:长期增长 短期增长Android场景:【场景:是否重构】 观点:应该重构这个模块 追问: 问:为什么要重构? 答:代码太乱了 问:为什么代码乱是个问题? 答:维护成本高 问:为什么维护成本高是问题? 答:影响后续开发效率 问:为什么开发效率比现在重构的成本更重要? 答:我们未来要开发很多新功能 价值观发现: → 长期开发效率 短期重构成本 → 可维护性 快速交付方法3:寻找价值观冲突冲突识别:当不同人对同一问题有不同观点时, 往往是价值观不同 【场景:技术选型争论】 A:应该用原生Android B:应该用Flutter 看似技术争论,实际是价值观冲突: A的价值观: - 性能 开发效率 - 用户体验 跨平台 - 稳定性 新技术 B的价值观: - 开发效率 微小性能差异 - 跨平台 平台特性 - 统一代码 多套代码 解决方法: 1. 明确双方的价值观 2. 讨论在当前项目中哪个更重要 3. 用数据验证假设方法4:反向推理从结论推价值观:结论 → 理由 → 价值观假设 示例: 结论:我们应该全面使用Kotlin ↓ 理由:Kotlin更简洁、更安全 ↓ 价值观假设: - 简洁性很重要 - 安全性很重要 - 代码质量 学习成本 - 长期收益 短期迁移成本 如果你的价值观不同: - 学习成本 简洁性 - 快速交付 长期收益 → 可能不同意这个结论4. 描述性假设定义描述性假设(Descriptive Assumptions):关于事实、关于是什么的未明说的假设。特点:可以验证真假关于客观事实支撑论证逻辑可能不成立识别方法方法1:寻找逻辑跳跃【示例】 结论:使用协程能提高性能 理由:协程比线程轻量 逻辑跳跃: 从轻量跳到提高性能 隐藏的描述性假设: ✓ 假设1:当前有性能问题 ✓ 假设2:性能问题是线程引起的 ✓ 假设3:轻量级就等于性能好 ✓ 假设4:没有其他副作用 验证: - 假设1:需要性能分析数据 - 假设2:需要定位瓶颈 - 假设3:需要benchmark测试 - 假设4:需要全面测试方法2:问如果…会怎样?结论:我们应该用MVVM架构 理由:MVVM更适合大型项目 假设识别: 问:如果该项目不是大型项目呢? → 假设1:该项目是大型项目 问:如果团队不熟悉MVVM呢? → 假设2:团队能快速学会MVVM 问:如果MVVM增加了复杂度呢? → 假设3:MVVM的收益大于复杂度成本 问:如果项目需要快速迭代呢? → 假设4:有足够时间搭建MVVM架构方法3:列举前提条件结论:使用Room数据库 理由:Room性能好,易用 需要成立的假设: 1. 项目需要本地数据库 2. 数据结构适合关系型数据库 3. 团队熟悉SQL或愿意学习 4. 不需要加密数据库 5. 数据量不会特别大 6. 不需要跨进程访问数据库 7. 最低支持API 16可接受 验证: - 逐一检查假设是否成立 - 不成立的假设可能导致方案不适用Android开发实战案例案例1:架构选择中的价值观冲突场景:团队讨论新项目的架构设计背景项目:电商App 团队:5人,1个高级,4个中级 时间:3个月MVP,6个月正式版 要求:快速迭代,稳定可靠忽视价值观差异的讨论【讨论记录】 高级开发A: 应该用Clean Architecture MVVM Dagger RxJava 中级开发B: 太复杂了,我们不会 高级开发A: 这是最佳实践,应该学 中级开发B: 学习时间太长,项目会延期 高级开发A: 技术人就应该追求技术 中级开发B: 但是产品要求快速交付 ...无休止的争论,无法达成共识 【问题分析】 双方都没有意识到: - 这是价值观冲突,不是技术争论 - 需要明确项目的优先级 - 需要找到平衡点识别价值观假设的讨论【改进的讨论】 Tech Lead(主持): 我们先明确一下,这个项目最重要的是什么? 【第一步:识别价值观】 高级开发A的价值观: ├─ 技术质量 交付速度 ├─ 长期可维护性 短期开发成本 ├─ 最佳实践 够用就好 └─ 团队成长 快速交付 中级开发B的价值观: ├─ 按时交付 技术完美 ├─ 团队能力匹配 最佳实践 ├─ 快速迭代 长期规划 └─ 业务价值 技术追求 【第二步:明确项目优先级】 Tech Lead: 以下看看项目的实际情况 项目约束: 1. 时间:3个月MVP必须上线 2. 团队:4个中级,学习成本要考虑 3. 业务:需求变化快,要快速迭代 4. 质量:不能频繁出bug,影响用户体验 项目价值观排序(团队投票): 1. 按时交付(优先级最高) 2. 稳定可靠(bug率低) 3. 快速迭代(响应需求变化) 4. 可维护性(长期考虑) 5. 技术先进性(相对次要) 【第三步:基于价值观选择方案】 方案A:Clean Architecture(高级开发A推荐) ├─ 优点:架构优秀,可维护性强 ├─ 缺点:学习成本高,开发速度慢 ├─ 匹配度:技术质量高,但与优先级不符 └─ 风险:可能延期,团队学习压力大 方案B:简单MVP架构(中级开发B推荐) ├─ 优点:简单易懂,快速开发 ├─ 缺点:技术债务,后期难维护 ├─ 匹配度:快速交付,但质量堪忧 └─ 风险:后期维护成本高 方案C:渐进式架构(Tech Lead建议) ├─ MVP阶段:简化的MVVM(不用Dagger,不用RxJava) ├─ 正式版:逐步引入Clean Architecture ├─ 优点:平衡速度和质量 └─ 风险:较低,可控 【第四步:评估假设】 方案C的假设: 1. 简化的MVVM团队能快速掌握 验证:[通过] 团队已有MVVM经验 2. 3个月够完成MVP 验证:[通过] 拆分功能,核心功能优先 3. MVP代码可以演进到Clean Architecture 验证:[通过] 遵循SOLID原则,预留扩展点 4. 后期有时间重构 验证:⚠️ 需要在规划中预留重构时间 【第五步:达成共识】 Tech Lead总结: 基于我们的优先级:按时交付 技术完美, 选择方案C: MVP阶段(0-3月): ├─ 简化的MVVM架构 ├─ 使用LiveData替代RxJava(团队熟悉) ├─ 手动依赖注入(避免Dagger学习成本) └─ 遵循SOLID原则(为后期重构做准备) 正式版阶段(3-6月): ├─ 逐步引入Dagger(如果需要) ├─ 引入Clean Architecture(如果项目变复杂) ├─ 重构技术债务 └─ 提升代码质量 这个方案: **正确做法** - 满足按时交付(优先级1) **正确做法** - 保证基本质量(优先级2) **正确做法** - 支持快速迭代(优先级3) **正确做法** - 预留演进空间(优先级4) **正确做法** - 团队能力匹配 高级开发A: 理解,虽然不是最完美的方案,但符合项目实际情况 → 接受了价值观排序 中级开发B: 好,这个方案我们能做 → 也有一定的技术追求 达成共识!关键点分析:【成功因素】 1. 识别了价值观冲突 - 不是技术争论,是价值观不同 2. 明确了项目优先级 - 基于实际约束排序价值观 3. 评估了描述性假设 - 验证团队能力、时间估算等 4. 找到了平衡方案 - 不是极端的任何一方 - 符合项目实际情况 5. 达成了团队共识 - 所有人理解并接受 【避免的问题】 **错误做法** - 盲目追求技术完美 **错误做法** - 完全忽视技术质量 **错误做法** - 不考虑团队能力 **错误做法** - 不考虑时间约束 **错误做法** - 价值观强加于人案例2:性能优化的优先级冲突场景:团队讨论性能优化计划背景现状: - 启动时间:3.5秒 - 内存占用:200MB - 包体积:80MB - 崩溃率:0.3% 资源: - 可用时间:4周 - 人力:2人 各方诉求: - 产品:希望优化启动速度(用户投诉多) - 技术:希望优化内存和包体积(技术指标) - 老板:希望降低崩溃率(影响口碑)没有识别价值观的讨论【争论】 产品经理: 应该优先优化启动速度,用户投诉最多 技术Leader: 应该优先优化内存,技术指标更重要 老板: 都重要,都要优化 产品经理: 时间有限,只能选一个 技术Leader: 那就优化技术指标,长远看更重要 产品经理: 但用户现在就在投诉 ...无法达成一致 【问题】 - 没有明确优先级标准 - 各自基于自己的价值观 - 缺乏数据支撑 - 没有评估投入产出比识别价值观和假设的讨论【改进的讨论】 Tech Lead: 我们先明确一下,如何判断优先级? 【第一步:识别各方价值观】 产品经理的价值观: ├─ 用户感知 技术指标 ├─ 解决投诉 长期优化 ├─ 用户满意度 技术完美 └─ 隐含假设:用户投诉会影响留存 技术Leader的价值观: ├─ 技术指标 用户感知 ├─ 长期优化 短期效果 ├─ 根本问题 表面问题 └─ 隐含假设:技术指标影响长期发展 老板的价值观: ├─ 业务价值 一切 ├─ 投入产出比 技术完美 ├─ 数据驱动 主观判断 └─ 隐含假设:业务增长最重要 【第二步:用数据评估影响】 Tech Lead: 以下用数据说话 ┌────────────────────────────────────────────┐ │ 优化项 │用户影响│技术价值│成本│周期│ROI│ ├────────────────────────────────────────────┤ │ 启动速度 │ ★★★★★│ ★★★ │ 中 │2周│★★★★│ │ │30%投诉 │行业标准│ │ │ │ │ │ │ │ │ │ │ │ 内存优化 │ ★★☆ │ ★★★★★│ 高 │3周│★★☆ │ │ │5%感知 │技术指标│ │ │ │ │ │ │ │ │ │ │ │ 包体积 │ ★★★ │ ★★★★ │ 中 │2周│★★★ │ │ │影响下载│技术指标│ │ │ │ │ │ │ │ │ │ │ │ 崩溃率 │ ★★★★ │ ★★★★★│ 低 │1周│★★★★★│ │ │影响口碑│质量指标│ │ │ │ └────────────────────────────────────────────┘ 【第三步:评估描述性假设】 启动速度优化: 假设1:启动慢是用户投诉的主因 验证:[通过] 30%的1星评价提到启动慢 假设2:优化后投诉会减少 验证:[通过] 竞品启动快,投诉少 假设3:2周能完成优化 验证:[通过] 已有技术方案,风险可控 假设4:不会引入新问题 验证:⚠️ 需要充分测试 内存优化: 假设1:内存高是个问题 验证:⚠️ 只有5%用户设备受影响 假设2:用户能感知到改善 验证:[未通过] 大部分用户不会注意 假设3:3周能完成 验证:[通过] 工作量评估合理 假设4:对业务有明显价值 验证:[未通过] 短期业务价值不明显 包体积优化: 假设1:包体积影响下载转化 验证:[通过] 数据显示每10MB影响5%转化 假设2:能优化到60MB以下 验证:[通过] 有优化空间 崩溃率优化: 假设1:0.3%崩溃率需要优化 验证:[通过] 行业标准是0.1% 假设2:1周能解决主要崩溃 验证:[通过] Top 3崩溃已定位 【第四步:基于价值观和数据决策】 决策框架: 1. 业务价值(老板的价值观) 2. 投入产出比 3. 用户影响 4. 技术价值 5. 实施难度 综合评分: ┌─────────────────────────────────┐ │ 优化项 │ 综合得分 │ 排序 │ ├─────────────────────────────────┤ │ 崩溃率 │ 95分 │ 1 │ │ 启动速度 │ 90分 │ 2 │ │ 包体积 │ 70分 │ 3 │ │ 内存优化 │ 60分 │ 4 │ └─────────────────────────────────┘ 【第五步:制定计划】 4周优化计划: Week 1: ├─ 崩溃率优化(最高优先级) ├─ 解决Top 3崩溃(覆盖80%崩溃) └─ 预期:崩溃率降到0.1%以下 Week 2-3: ├─ 启动速度优化(第二优先级) ├─ SDK懒加载 异步初始化 └─ 预期:启动时间降到2.5秒以下 Week 4: ├─ 包体积优化(第三优先级) ├─ 资源优化 代码优化 └─ 预期:包体积降到70MB以下 内存优化: └─ 暂缓(排期到下个迭代) 【第六步:达成共识】 老板: 好,优先做ROI最高的,崩溃率和启动速度 → 基于业务价值和数据 产品经理: 同意,先解决崩溃,再优化启动,都是用户痛点 → 理解了优先级 技术Leader: 理解,崩溃率确实应该优先,内存以后优化 → 接受了业务优先的价值观 团队达成共识!关键洞察:【价值观层面】 不同角色的价值观: 产品:用户感知 技术指标 技术:技术完美 短期效果 老板:业务价值 一切 统一的价值观: 数据驱动 主观判断 ROI 个人偏好 【假设层面】 关键假设: 1. 优化效果能达到预期 2. 不会引入新问题 3. 用户能感知到改善 4. 对业务有实际价值 验证方法: - 用数据验证影响 - 用测试验证风险 - 用ROI评估价值 【决策框架】 成功因素: **正确做法** - 明确了各方价值观 **正确做法** - 用数据而非主观判断 **正确做法** - 评估了所有假设 **正确做法** - 建立了统一的决策标准 **正确做法** - 找到了平衡点案例3:技术债务还是新功能?场景:产品要求开发新功能,技术团队想重构背景现状: - 代码质量:较差,技术债务多 - 业务压力:需要快速迭代 - 团队状态:疲于应付,想重构 冲突: - 产品:要求2周开发新功能 - 技术:要求3周先重构再开发价值观冲突的争论【对话】 产品经理: 必须2周上线新功能,竞品已经有了 → 价值观:市场竞争 技术质量 Tech Lead: 代码太乱,必须先重构,否则越来越难维护 → 价值观:技术质量 快速交付 产品经理: 重构用户看不到,没有业务价值 → 假设:用户不关心技术质量 Tech Lead: 不重构的话,以后开发会越来越慢 → 假设:技术债务会严重影响效率 产品经理: 以后再说,先把功能做出来 → 价值观:现在 以后 Tech Lead: 你们总是说以后,以后从来不来 → 情绪化,没有建设性 ...争论升级,关系紧张识别价值观,数据驱动的讨论【改进的对话】 Tech Lead: 我们先客观分析一下,用数据说话 【第一步:识别价值观差异】 产品的价值观: ├─ 市场竞争 技术质量 ├─ 功能上线 代码优化 ├─ 用户价值 技术追求 └─ 角色定位:业务导向 技术的价值观: ├─ 长期效率 短期交付 ├─ 技术质量 快速上线 ├─ 可维护性 功能堆砌 └─ 角色定位:技术导向 【第二步:用数据说话】 Tech Lead: 以下看看实际数据 当前技术债务影响: ┌────────────────────────────────┐ │ 指标 │ 数据 │ 趋势 │ ├────────────────────────────────┤ │ 开发效率 │-30% │ 持续下降│ │ Bug率 │50% │ 持续上升│ │ 改动影响范围 │平均3个模块│ 越来越大│ │ 新人上手时间 │5天 │ 越来越长│ │ 代码review时间│2小时/次│ 越来越长│ └────────────────────────────────┘ 近期开发周期对比: ├─ 3个月前:相似功能2周完成 ├─ 2个月前:相似功能2.5周完成 ├─ 1个月前:相似功能3周完成 └─ 预测:本次功能可能需要3.5周 → 数据证明:技术债务在拖慢开发速度 新功能开发评估: ┌────────────────────────────────────┐ │ 方案 │ 时间 │ 质量 │ 后续影响│ ├────────────────────────────────────┤ │ 不重构直接开发│ 2.5周│ 差 │ 债务20% │ │ 先重构再开发 │ 3.5周│ 好 │ 债务-30% │ │ 边重构边开发 │ 3周 │ 中 │ 债务-15% │ └────────────────────────────────────┘ 【第三步:评估假设】 产品的假设: 假设1:2周能完成 验证:[未通过] 基于历史数据,实际需要2.5周 假设2:技术债务影响不大 验证:[未通过] 数据显示效率已 假设3:不重构也能持续开发 验证:⚠️ 可以,但会越来越慢 技术的假设: 假设1:重构后开发会变快 验证:[通过] 消除债务后效率提升 假设2:不重构会越来越慢 验证:[通过] 趋势数据支持 假设3:用户不关心延期1周 验证:❓ 需要产品确认 【第四步:寻找平衡方案】 Tech Lead: 我提议一个折中方案 方案:边重构边开发(3周) Week 1:重构相关模块 ├─ 只重构本次功能相关的核心模块 ├─ 不做全面重构 ├─ 预期:消除15%技术债务 └─ 为新功能打好基础 Week 2-3:开发新功能 ├─ 基于重构后的代码开发 ├─ 新代码遵循规范 ├─ 预期:开发更顺畅 └─ 质量更高 总时间:3周 - 比不重构多3天 - 比全面重构少3.5天 - 质量提升明显 - 技术债务 后续计划: ├─ 每次开发新功能前,重构相关模块 ├─ 不做大规模重构 ├─ 渐进式改善代码质量 └─ 在业务和技术间平衡 【第五步:说服产品】 Tech Lead: 我知道你希望2周上线,但基于数据: 1. 实际需要2.5周,不是2周(历史数据) 2. 如果不重构,后续功能会更慢(趋势数据) 3. 我们的方案只多3天,但质量更好 4. 可以避免后续返工(bug率数据) 5. 长期看,效率会提升 风险:多3天 收益:质量提升效率改善债务减少 3天的投入,换来长期的效率提升,值得吗? 产品经理: 你说得有道理,数据很有说服力。 但是,能否2.5周完成?我去和老板争取。 Tech Lead: 我尽力,如果顺利可能2.5周,但3周更稳妥 产品经理: 好,我们就按3周规划,我去同步老板 达成共识! 【第六步:向上对齐】 产品经理向老板汇报: 新功能需要3周,原因: 1. 技术债务已影响效率(数据支撑) 2. 不处理会越来越慢(趋势支撑) 3. 这次边重构边开发,长期有利 4. 后续功能会更快 老板: 理解,3周可以接受。但要确保后续功能变快 产品经理: 收到,会跟踪效率指标成功因素分析:【关键点】 1. 识别价值观差异 ├─ 产品:业务优先 ├─ 技术:质量优先 └─ 老板:长期价值 2. 用数据说话 ├─ 不是主观判断 ├─ 用数据证明影响 └─ 用数据证明方案价值 3. 评估假设 ├─ 验证产品的假设(2周能完成) ├─ 验证技术的假设(重构有价值) └─ 用数据验证而非争论 4. 寻找平衡 ├─ 不是极端的任何一方 ├─ 边重构边开发 └─ 既交付功能,又改善质量 5. 建立信任 ├─ 技术用数据说服产品 ├─ 产品理解技术诉求 └─ 共同对老板负责 【避免的问题】 **错误做法** - 情绪化争论 **错误做法** - 强加价值观 **错误做法** - 主观判断 **错误做法** - 不考虑对方诉求 **错误做法** - 非黑即白的选择 【长期改进】 建立机制: 1. 定期技术债务盘点 2. 建立重构时间预算 3. 技术质量指标化 4. 业务和技术共同决策实用工具与检查清单工具1:价值观识别清单┌────────────────────────────────────────┐ │ 价值观识别清单 │ ├────────────────────────────────────────┤ │ □ 找到了价值观词汇(应该、重要、优先等)│ │ □ 识别了隐含的优先级排序 │ │ □ 发现了价值观冲突(不同人不同观点) │ │ □ 区分了价值观假设和描述性假设 │ │ │ │ 价值观假设(主观判断): │ │ - 关于什么更重要 │ │ - 涉及优先级选择 │ │ - 难以验证对错 │ │ 例:性能 开发效率 │ │ │ │ 描述性假设(客观判断): │ │ - 关于事实和现状 │ │ - 可以验证真假 │ │ - 支撑论证逻辑 │ │ 例:团队能学会Kotlin │ └────────────────────────────────────────┘工具2:价值观分析模板价值观分析模板 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【决策场景】 _____________________________________________ 【不同角色的价值观】 角色1:__________ 价值观排序: 1. __________ __________ 2. __________ __________ 3. __________ __________ 理由: 隐含假设: 角色2:__________ 价值观排序: 1. __________ __________ 2. __________ __________ 3. __________ __________ 理由: 隐含假设: 【价值观冲突点】 1. 2. 3. 【项目实际优先级】(基于约束和目标) 约束: - 时间: - 人力: - 质量: - 成本: 目标: - 业务目标: - 技术目标: - 用户目标: 优先级排序: 1. 2. 3. 4. 5. 【平衡方案】 基于优先级,我们的方案: 满足的价值观: □ □ □ 牺牲的价值观: □ (为什么可以牺牲?) □ (为什么可以牺牲?) 【达成共识】 □ 所有人理解优先级 □ 所有人接受方案 □ 建立了决策标准工具3:描述性假设检查清单描述性假设检查清单 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【结论】 _____________________________________________ 【理由】 1. 2. 3. 【假设识别】(从理由到结论的逻辑跳跃) 假设1:_______________________________________ ├─ 如果这个假设不成立,结论还成立吗? □是 □否 ├─ 如何验证这个假设? _____________________ ├─ 验证结果: □成立 □不成立 □不确定 └─ 如果不成立,如何调整方案? _____________ 假设2:_______________________________________ ├─ 如果这个假设不成立,结论还成立吗? □是 □否 ├─ 如何验证这个假设? _____________________ ├─ 验证结果: □成立 □不成立 □不确定 └─ 如果不成立,如何调整方案? _____________ 假设3:_______________________________________ ├─ 如果这个假设不成立,结论还成立吗? □是 □否 ├─ 如何验证这个假设? _____________________ ├─ 验证结果: □成立 □不成立 □不确定 └─ 如果不成立,如何调整方案? _____________ 【关键假设】(影响最大的假设) 1. 2. 3. 【验证计划】 假设1验证方法: 假设2验证方法: 假设3验证方法:工具4:价值观对话框架当团队有价值观冲突时,用这个框架引导讨论:价值观对话框架 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 【第一步:识别价值观】 以下先明确一下,大家各自看重什么? A的价值观: 从技术角度看______最重要,因为_______ B的价值观: 从技术角度看______最重要,因为_______ 【第二步:承认差异】 我理解你看重______,这确实很重要 我看重______,你觉得这个重要吗? 【第三步:寻找共同点】 我们有没有共同的目标? 有没有我们都认同的价值观? 共同目标: 共同价值观: 【第四步:明确项目优先级】 基于项目的实际情况,什么最重要? 项目约束: 项目目标: 优先级排序: 【第五步:基于优先级决策】 基于优先级,我们应该______ 方案: 理由: 满足的价值观: 牺牲的价值观: 【第六步:达成共识】 你能接受这个方案吗?为什么? 有什么顾虑?如何解决? 最终共识:小节总结核心要点回顾1. 价值观假设关于什么更重要的隐含信念影响决策的优先级不同人可能有不同价值观需要明确和对齐2. 常见价值观冲突创新 vs 稳定性能 vs 开发效率用户体验 vs 技术债务业务价值 vs 技术追求3. 识别方法寻找价值观词汇反复问为什么重要识别价值观冲突从结论反推价值观4. 描述性假设关于事实的未明说的假设可以验证真假寻找逻辑跳跃评估前提条件立即可应用的技巧技巧1:团队决策时先明确各方的价值观建立统一的优先级基于优先级而非个人偏好决策技巧2:技术方案评审时识别方案背后的价值观假设评估假设在项目中是否成立找到平衡不同价值观的方案技巧3:与产品沟通时理解产品的价值观(用户价值、业务价值)用数据验证假设寻找业务和技术的平衡点常见误区误区1:强加自己的价值观错误:“技术质量最重要,必须按我的来”正确:“基于项目优先级,我们应该…”误区2:忽视价值观差异错误:认为大家价值观一致正确:明确不同角色的价值观差异误区3:不验证假设错误:基于假设直接决策正确:识别关键假设,验证后决策误区4:非黑即白错误:要么全重构,要么不重构正确:寻找平衡方案,渐进式改进本章总结价值观冲突是分歧的暗线。表面上在争论方案底层是价值观优先级不同。识别出价值观假设才能真正理解对方为什么不同意。价值观 vs 描述性假设速查维度价值观假设描述性假设关注什么更重要世界是什么样的性质主观偏好客观事实验证无法验证对错可以验证真假关键词“应该”“更重要”“优先”“是”“会导致”“基于”示例“稳定性比创新重要”“这个SDK支持iOS 12”团队常见价值观冲突地图角色优先价值观典型话术开发技术质量、可维护性“代码质量不能妥协”产品用户价值、业务价值“用户等不了这么久”测试稳定性、覆盖率“必须充分回归测试”管理成本控制、交付速度“Q2必须上线”化解冲突三步法暴露差异——明确说出各自的价值观优先级建立共识——找到共同目标如都想要产品好基于场景决策——不同阶段不同优先级用项目阶段而非个人偏好决策实战心法争论方案前先对齐价值观——价值观不统一所有讨论都是鸡同鸭讲好方案不是消灭分歧而是管理分歧——找到各方都能接受的平衡点理解对方的价值观比反驳对方的论点更能推进共识。