04-09-06 技术分歧场景 - 学习笔记

04-09-06 技术分歧场景 - 学习笔记

章节信息

核心主题:技术分歧的本质、避免技术ego、寻找第三选择
学习目标:掌握处理技术分歧的方法,在保持技术追求的同时维护团队关系
关键要点:分歧背后的真实原因、数据驱动决策、第三选择思维、技术方案对话模板

核心概念

1. 技术分歧的本质

什么是技术分歧?

在Android开发中,常见的技术分歧场景:

架构选择: MVC vs MVVM vs MVI 语言选择: Java vs Kotlin 技术栈: RxJava vs Coroutines UI方案: XML vs Compose 图片库: Glide vs Coil vs Picasso 架构层级: 单体 vs 组件化 vs 模块化 数据库: SQLite vs Room vs Realm 网络库: Retrofit vs OkHttp vs Volley

技术分歧的三种常见误区

误区1:认为技术分歧是技术对错之争

**错误做法** - 错误认知: "MVVM就是比MVC好,这是事实!" "Kotlin已经是官方推荐,还用Java是落后!" 真相: 技术选择没有绝对的对错,只有在特定场景下的合适与否。 - MVVM在某些场景下更好,但不是所有场景 - Kotlin有很多优势,但Java在某些情况下也合理 - "最佳实践"往往是有上下文的

误区2:认为技术分歧是个人能力之争

**错误做法** - 错误认知: "你不同意我的方案,是因为你技术不行" "我比你资深,所以应该听我的" "你没用过这个技术,你不懂" 真相: 技术分歧往往不是能力问题,而是: - 掌握的信息不同 - 关注的优先级不同 - 过往的经验不同 - 对风险的容忍度不同

误区3:认为技术分歧只能有一个赢家

**错误做法** - 错误认知: "要么用你的方案,要么用我的方案" "必须有一个人说服另一个人" "只能二选一" 真相: 很多时候存在"第三选择": - 结合两种方案的优点 - 找到双方都能接受的折中方案 - 分阶段实施,逐步验证 - 根据场景选择不同方案

技术分歧背后的真实原因

表面上的技术争论,背后往往是这些因素:

因素1:优先级不同

场景:讨论是否要重构 开发A:"必须重构,代码太烂了!" → 真实优先级:代码质量、长期维护 开发B:"没时间重构,先保证功能上线!" → 真实优先级:交付进度、业务目标 冲突本质:不是技术之争,是优先级之争

因素2:风险偏好不同

场景:是否使用新技术 激进派:"用最新的Compose,能大幅提升效率!" → 风险偏好:愿意承担新技术的不确定性 保守派:"等Compose成熟了再说,现在太冒险!" → 风险偏好:倾向于稳定可靠的技术 冲突本质:不是能力之争,是风险偏好之争

因素3:视角不同

场景:包体积优化 前端工程师:"多引入一个库没关系,才500KB" → 视角:单个库的增量 架构师:"现在50个库,每个500KB,总共25MB!" → 视角:整体的累积效应 冲突本质:不是对错之争,是视角之争

因素4:过往经验不同

场景:是否使用某个第三方库 工程师A:"XXX库很好用,我在上个项目用过" → 经验:上个项目成功案例 工程师B:"XXX库有问题,我踩过坑" → 经验:某个项目失败案例 冲突本质:不是技术之争,是经验之争

2. 避免技术Ego

什么是技术Ego?

定义:把技术选择和个人身份、能力、地位绑定,把技术讨论变成个人较量。

技术Ego的表现:

□ 把"我的方案"和"我的能力"等同起来 "你反对我的方案,就是说我技术不行" □ 用技术高低来判断人的价值 "你连XXX都不会,你怎么有资格参与讨论?" □ 固守自己的观点,拒绝考虑其他可能 "我就是坚持用XXX,不接受其他方案" □ 把同意自己当作忠诚,不同意当作背叛 "你是支持我还是支持他?" □ 用权威和资历压制不同意见 "我做了10年Android,我说用XXX就用XXX" □ 赢得争论比解决问题更重要 "我一定要让他承认我是对的"

技术Ego的危害:

对个人: - 阻碍学习和成长 - 在团队中失去信任 - 错过更好的方案 对团队: - 制造对立和冲突 - 压制创新和讨论 - 影响决策质量 对项目: - 做出次优决策 - 技术债累积 - 项目成功率下降

如何克服技术Ego?

心态1:把"我的方案"和"我"分离

**错误做法** - 技术Ego思维: "这是我的方案,如果被否决,就是否定我" **正确做法** - 健康思维: "这是我基于当前信息提出的方案,如果有更好的方案, 我很愿意采纳。方案的好坏不代表我的价值。"

心态2:目标是解决问题,不是赢得争论

**错误做法** - 技术Ego思维: "我一定要让大家同意我的观点,证明我是对的" **正确做法** - 健康思维: "我的目标是找到最佳方案,不管是我的方案还是别人的方案, 只要能解决问题就好"

心态3:不同意见是帮助,不是攻击

**错误做法** - 技术Ego思维: "他反对我的方案,是在挑战我的权威" **正确做法** - 健康思维: "他提出不同意见,可能看到了我的盲区, 这是帮我完善方案的机会"

心态4:承认自己也会犯错

**错误做法** - 技术Ego思维: "实践经验和能力,不可能犯这种错误" **正确做法** - 健康思维: "我也会有盲区和错误,保持谦逊和开放"

实践技巧:

技巧1:用"我们"替代"我"

**错误做法** - "我的方案是XXX" **正确做法** - "我想到一个方案,我们一起讨论看看是否可行" **错误做法** - "从技术角度看应该XXX" **正确做法** - "我们是否可以考虑XXX"

技巧2:主动邀请挑战

"这是我的想法,但我可能有盲区, 请大家帮我看看有什么问题" "如果你发现我的方案有漏洞,请一定告诉我"

技巧3:公开承认自己不确定

"关于XXX部分,我不太确定,有人有经验吗?" "我对YYY不太了解,能否请ZZZ分享一下?"

技巧4:感谢不同意见

"感谢你指出这个问题,我确实没考虑到" "这个角度很好,我之前没想到"

3. 寻找第三选择

什么是第三选择?

定义:超越"你的方案"和"我的方案"的二元对立,创造一个融合双方优点、更优越的第三种方案。

第三选择的思维模式:

传统思维(二元对立): 方案A ←→ 必须二选一 ←→ 方案B 你 我 第三选择思维: 方案A ⤵ ⤷ 协同创造 → 方案C(更优) 方案B ⤴

如何寻找第三选择?

步骤1:理解双方的核心关注点

不要只看表面的技术方案,要理解背后的关注点:

示例:MVC vs MVVM之争 表面之争: 工程师A:"用MVC" 工程师B:"用MVVM" 理解: 工程师A的核心关注: - 团队熟悉MVC,学习成本低 - 时间紧,不想冒险 - 担心MVVM的坑 工程师B的核心关注: - MVVM长期维护成本低 - 代码质量和可测试性 - 团队技术成长 真正的目标: 既要降低短期风险,又要兼顾长期质量

步骤2:找到共同目标

提问: "虽然我们提出的方案不同,但我们是否在核心目标上 有共识?" 示例: "我们是否都认同: 1. 项目要按时上线(短期目标) 2. 代码要易于维护(长期目标) 3. 团队要能驾驭技术栈(能力匹配) 如果这三点我们都同意,那我们的分歧只是如何 实现这些目标,对吗?"

步骤3:跳出非此即彼的框架

**错误做法** - 二元思维: "要么用A,要么用B,没有第三种选择" **正确做法** - 第三选择思维: "如果我们不限于A和B,还有什么可能性?" 创造性提问: "有没有一种方式,既能实现A的优点,又能实现B的优点?" "能否分阶段?先做什么,后做什么?" "能否根据场景选择?哪些场景用A,哪些场景用B?" "能否创造一个新方案,比A和B都好?"

步骤4:共同创造方案

态度: - 不是"我说服你"或"你说服我" - 而是"我们一起创造新方案" 语言: - "我们能否结合两种思路?" - "如果我们这样做,能否解决双方的顾虑?" - "有没有一种方式,以下都满意?"

第三选择的常见模式

模式1:分阶段实施

场景:要不要全面重构? 方案A(激进派):立即全面重构 方案B(保守派):不重构,只修bug 第三选择: - Phase 1:重构最痛的核心模块(2周) - Phase 2:评估效果,决定是否继续 - Phase 3:根据效果逐步推进或调整 优势: - 降低风险(分阶段验证) - 兼顾进度(不是一次性全做) - 有数据支撑决策

模式2:并行试验

场景:选择图片加载库 方案A:Glide(成熟稳定) 方案B:Coil(新颖Kotlin友好) 第三选择: - 在两个不同的模块中分别试用 - 3周后对比性能、易用性、bug数 - 基于数据做最终决策 - 允许不同模块使用不同库(如果差异不大) 优势: - 用数据而非争论决策 - 两种方案都得到验证机会 - 团队都有参与感

模式3:分场景选择

场景:网络请求用RxJava还是Coroutines? 方案A:统一用RxJava 方案B:统一用Coroutines 第三选择: - 新代码用Coroutines(面向未来) - 老代码保持RxJava(降低风险) - 建立互操作层,确保兼容 - 逐步迁移,不强制一次性替换 优势: - 兼顾历史包袱和技术演进 - 降低迁移风险 - 给团队学习时间

模式4:混合方案

场景:用XML还是Compose? 方案A:全部用XML 方案B:全部用Compose 第三选择: - 基础组件用Compose(受益明显) - 复杂业务页面用XML(稳定可靠) - 通过AndroidView互操作 - 建立清晰的使用指南 优势: - 充分利用两种技术的优势 - 降低全面迁移的成本 - 渐进式技术升级

Android开发实战案例

案例1:架构选型争论 - MVC vs MVVM

场景设定:

• 新项目启动,需要选择架构模式
• Tech Lead Tom倾向MVC(团队熟悉,风险低)
• 你倾向MVVM(长期维护性好,可测试性强)
• 项目要求3个月上线
• 团队5人,其中2人(包括你)用过MVVM

错误示范1:技术至上,忽略现实约束

你在架构评审会上:

"我强烈建议用MVVM,理由很充分: 1. Google官方推荐的架构 2. Jetpack组件都是为MVVM设计的 3. ViewModel生命周期安全,避免内存泄漏 4. 数据绑定减少样板代码 5. 单元测试更容易写 6. 业界主流都在用MVVM MVC已经是上个时代的技术了,我们不应该因为 团队不熟悉就不学习。技术人员应该拥抱新技术, 而不是固步自封。学习成本是一次性的,但长期 收益是巨大的。 所以从技术角度看必须用MVVM,这是技术正确的选择。"

Tom的反应:

"你说的这些我都知道,但是你有没有考虑过现实情况? 1. 团队只有你和小李用过MVVM,其他3人都不会 2. 项目要求3个月上线,留给学习的时间很少 3. MVVM的学习曲线比MVC陡峭 4. 如果遇到坑,没有人能及时解决 5. MVC已经用了多年,团队很熟悉,风险可控 技术不是越新越好,适合团队的才是最好的。 我还是坚持用MVC,这是对项目负责。"

后续:

• 会议陷入僵局
• 双方都不肯让步
• 最终Tom用职位权威拍板用MVC
• 你心里不服气,觉得技术上被保守派压制
• 团队氛围受影响
• 问题没解决,关系受损,团队产生分裂

错误示范2:过度妥协,放弃技术追求

你在会议上:

"嗯...我理解团队的顾虑,确实MVVM学习成本 比较高,时间也比较紧张。那就用MVC吧, 我没意见。"

问题分析:

• 过快放弃,没有充分讨论
• Tom不理解MVVM的价值
• 团队失去了技术成长的机会
• 你自己也可能长期regret这个决定

正确示范:第三选择思维

你在会议上:

"Tom,感谢你的坦诚。我理解你的顾虑,这些都是 非常现实和重要的问题。在讨论方案之前,我想先 确认一下我们的共同目标,看看我们是否在基本点上 有共识。可以吗?" Tom:"好的,你说。" 【寻找共同目标】 你:"我理解我们的共同目标是: 1. 项目要在3个月内按时上线,这是第一优先级 2. 代码质量要有保障,避免上线后大量bug 3. 长期来看,代码要易于维护和扩展 4. 技术选择要匹配团队能力,风险可控 这些是否是我们都认同的?" Tom:"是的,我都认同。" 【理解双方的核心关注点】 你:"很好。那我们的分歧主要在于如何实现这些目标。 让我先理解一下你的核心顾虑: 你担心的主要是: 1. 学习成本:团队大部分人不会MVVM,学习需要时间 2. 时间风险:3个月的deadline很紧,学习可能影响进度 3. 技术风险:MVVM可能有坑,团队没经验解决不了 我理解对吗?还有其他顾虑吗?" Tom:"对,主要就是这三点。特别是时间风险, 老板对这个项目很重视,不能延期。" 【陈述自己的关注点】 你:"我理解了。我来说说我为什么倾向MVVM: 1. 长期维护:这个项目会持续维护至少2年,MVVM 的维护成本比MVC低约20-30%(基于我上个项目的经验) 2. 代码质量:MVVM的结构清晰,新人接手更容易 3. 可测试性:ViewModel的单元测试很容易写,能提高质量 4. 技术成长:这是团队学习现代Android开发的好机会 但是,我完全理解你的顾虑。我不想为了技术而技术, 如果确实风险太大,我也接受用MVC。" 【提出第三选择】 你:"不过,我在想,有没有一种方式,既能降低你担心的 风险,又能获得MVVM的长期收益? 我想到一个渐进式的方案,不知道是否可行: **阶段1:准备期(Week 1-2)** - 我和小李准备MVVM培训材料和项目模板 - 搭建好基础框架(网络层、数据层、ViewModel基类) - 做一个完整的示例模块,包括文档和最佳实践 - 周五下午做3小时的内部培训 **阶段2:试点期(Week 3-6,1个月)** - 选择2个中等复杂度的模块用MVVM实现 (比如:用户信息模块、商品列表模块) - 其他模块先用MVC,保证进度 - 我和小李重点review MVVM部分,快速解决问题 - 每周五review一次,评估效果和问题 **阶段3:评估期(Week 7,1周)** - 评估试点模块的数据: - 开发效率:是否比MVC慢?慢多少? - 代码质量:bug数、代码行数、复杂度 - 团队反馈:大家学习难度如何?遇到什么问题? - 基于数据做决策: - 如果效果好,后续新模块用MVVM - 如果问题多,后续改回MVC - 已有的MVVM模块保留(不影响功能) **阶段4:执行期(Week 8-12,剩余时间)** - 根据评估结果执行 - 已有的MVC模块不强制重构,稳定最重要 **这个方案的优点**: 1. 风险可控:只是部分试点,可以随时调整 2. 有数据支撑:1个月后有真实数据,不是空谈 3. 兼顾进度:不是all-in,MVC作为保险 4. 团队参与:大家都有学习和评估的机会 5. 给我们一个验证机会,不是主观判断 **可能的问题**: 1. 代码库会同时有MVC和MVVM,可能有些混乱 2. 我和小李的工作量会增加(培训、review、答疑) 3. 如果最终选择MVC,前期MVVM的工作有些浪费 但我觉得这些成本是可接受的,特别是能用数据 验证决策,比争论要更客观。 Tom,你怎么看这个方案?它是否能降低你担心的风险?" Tom:"(思考)...你这个方案考虑得很全面。 我主要的顾虑是时间风险,但你这个方案确实风险可控, 第一个月就能看到效果,如果不行可以及时调整, 不会影响整体进度。 我有几个具体问题: 1. 你说的示例模块和培训,能保证在第1周完成吗? 2. 试点的两个模块,会不会选到特别复杂的? 我担心试点选的太简单,不能代表真实情况。 3. 如果MVVM效果不好,改回MVC的成本有多大?" 【继续讨论细节】 你:"这些问题很好!让我一一回答: 1. 示例模块和培训时间: - 我和小李可以加班完成,第1周应该没问题 - 如果实在来不及,可以延长到Week 2的周三, 这样周五还能培训,不影响后面的schedule 2. 试点模块的选择: - 用户信息模块:中等复杂,有网络请求、本地缓存、UI更新 - 商品列表模块:中等复杂,有分页、筛选、图片加载 - 这两个模块的复杂度能代表大部分业务场景 - 我们可以一起review选择,确保有代表性 3. 改回MVC的成本: - 如果效果不好,MVVM模块可以保持不变, 不需要改回MVC(功能已经实现了) - 后续新模块用MVC就行 - 所以成本主要是前期的学习时间,但这个时间 不管结果如何,都有团队成长的价值 你觉得这样可以吗?还有其他concerns吗?" Tom:"我觉得可以试试。不过我有一个要求: 如果第一个月试点后,数据显示效率明显低于MVC, 或者团队反馈学习困难很大,我们要立即切回MVC, 不能为了技术而影响项目交付。你能承诺吗?" 你:"完全没问题!我承诺: 1. 如果试点数据不好,立即切回MVC,没有任何异议 2. 我和小李会全力支持,确保试点顺利 3. 每周五的review我会准备详细的数据和分析 实际上,我也想用数据验证MVVM是否真的如我预期的好。 如果事实证明在我们的场景下MVVM不合适,我也会调整 认知。技术服务于业务,确保项目成功是第一优先级。" Tom:"好!那我们就按这个方案执行。我会和大家 宣布这个决策,强调这是团队共同决定的方案, 不是我强制,也不是你强推。" 你:"太好了!感谢你愿意给我们这个验证的机会。 我会后整理详细的执行计划,明天发给你review。" 【会后团队宣布】 Tom:"大家好,关于架构选型,我和XXX经过详细讨论, 达成了一个渐进式的方案...(说明方案) 这个方案的好处是: - 风险可控,不是all-in - 有数据驱动,不是主观争论 - 给大家学习MVVM的机会,但不强制 - 如果效果不好,我们能及时调整 这不是我强制的,也不是XXX强推的,是我们共同创造的方案。 大家有什么问题或建议吗?" 团队:"(积极讨论,提出具体问题和建议)"

后续影响:

• 双方的关注点都得到了重视
• 创造了一个第三选择,比单一方案更好
• 用数据而非争论来决策
• 团队有参与感,不是被动接受
• Tom和你建立了更深的信任和respect
• 团队学习了现代Android开发
• 一个月后,数据显示MVVM效果很好,继续推进
• 项目按时上线,代码质量也很好

成功要点:

• 先寻找共同目标,建立共识基础
• 理解对方的核心顾虑(时间风险、学习成本)
• 陈述自己的关注点,但不强推
• 提出第三选择:渐进式方案,降低风险
• 用数据驱动决策,而非主观争论
• 真诚承诺:如果效果不好,立即调整
• 强调共同创造,而非个人胜利

案例2:技术栈选择 - Kotlin vs Java

场景设定:

• 项目启动2年,一直用Java
• 你提议新代码用Kotlin,逐步迁移
• Senior工程师Bob反对,认为现在不是时候
• 团队6人,3人想学Kotlin,3人prefer Java
• 需要达成团队共识

完整对话:从分歧到共识

【第一步:一对一了解Bob的真实顾虑】 你单独约Bob喝咖啡: 你:"Bob,想和你聊聊Kotlin的事情。我知道你不太 赞成现在引入Kotlin,能说说你的concerns吗? 我想真正理解你的考虑。" Bob:"我不是反对Kotlin本身,Kotlin确实有很多优点。 我主要有三个顾虑: 1. 时间成本:团队学习Kotlin需要时间,现在项目 pressure比较大,我担心影响进度 2. 维护成本:项目已经有10万行Java代码了,引入 Kotlin后代码库会有两种语言,维护起来更复杂 3. 招聘成本:以后招人是招会Kotlin的,还是会Java的? 会不会限制招聘范围?" 你:"这些顾虑很合理!我之前确实没太考虑招聘的问题。 能再问一下,除了这三点,你还有其他担心吗? 比如对Kotlin技术本身的担心?" Bob:"技术上我倒不太担心,Google都官方支持了, 肯定没问题。主要就是这三点成本问题。" 你:"明白了。那我也想问一下,如果这三个成本问题 能够解决或降低,你对引入Kotlin会是什么态度?" Bob:"如果成本可控,我觉得可以考虑。毕竟Kotlin 确实有很多优点,比如null safety、扩展函数这些。 我不是守旧,只是希望稳妥一点。" 你:"理解了,谢谢你的坦诚!我会想想有没有办法 降低你担心的成本。" 【第二步:团队会议讨论】 你在团队会议上: "关于是否引入Kotlin,我和Bob以及其他几位同事 都聊过了,我想先总结一下大家的观点: 【支持引入Kotlin的理由】: - Null safety,减少空指针crash - 简洁语法,减少样板代码 - Coroutines比RxJava更简洁 - Google官方推荐,长期趋势 - 团队技术成长的机会 【反对或担心的理由】: - 学习时间成本 - 代码库混合Java和Kotlin的维护成本 - 招聘时对技术栈的要求更高 - 当前项目进度压力大 我觉得双方的观点都很有道理。支持方关注的是 长期收益和技术进步,反对方关注的是短期成本和 现实约束。这不是对错之争,而是优先级和节奏的问题。 【寻找共同目标】 我想先问大家:我们是否在这些基本点上有共识? 1. Kotlin作为技术本身是有价值的(长期看) 2. 但引入新技术要考虑成本和时机 3. 我们的首要目标是确保项目稳定和进度 大家认同吗?" 团队:"认同。" 【提出第三选择】 你:"很好。那我们的问题就变成了:如何在控制成本 的前提下,逐步引入Kotlin,既获得长期收益,又不影响 短期交付? 我想到一个方案,叫'三步走策略': **Step 1:自愿学习(Month 1-2)** - 不强制要求,自愿学习 - 公司提供Kotlin课程和学习资料 - 每两周一次内部分享会,学习者分享经验 - 建立Kotlin最佳实践文档 **Step 2:新代码尝试(Month 3-6)** - 学过Kotlin且有兴趣的同学,可以在新代码中用Kotlin - 但不强制,prefer Java的同学可以继续用Java - 核心原则:团队review通过即可,不限制语言 - 建立Java-Kotlin互操作规范 **Step 3:评估和推广(Month 6+)** - 6个月后评估: - Kotlin代码的质量(bug率、可读性) - 团队的学习曲线和接受度 - 维护成本的实际情况 - 基于数据决定下一步: - 如果效果好,鼓励更多使用Kotlin - 如果问题多,保持现状或调整策略 - 不强制迁移老代码,自然演进 **针对Bob的三个顾虑的回应**: 1. 时间成本: - 自愿学习,不影响工作时间(利用业余时间) - 不强制,不给不想学的人压力 - 学习资源公司提供,降低个人成本 2. 维护成本: - Java和Kotlin可以很好地互操作 - 建立清晰的互操作规范 - 不强制迁移老代码,新老共存 - 6个月后评估实际维护成本 3. 招聘成本: - 不强制要求候选人会Kotlin - Java开发可以快速学习Kotlin(1-2周) - 实际上,会Kotlin是加分项,不影响招聘 Bob,你觉得这个方案是否能降低你担心的成本?" Bob:"我觉得这个方案比较合理。特别是不强制, 这样不会给团队太大压力。而且6个月后有数据评估, 不是盲目推进。我可以接受。" 你:"太好了!其他同学呢?有什么意见或建议吗?" 小李:"我很想学Kotlin,但我担心学了之后在项目中 用不上,会不会白学了?" 你:"不会的!即使6个月后评估决定不大规模推广, 你学到的Kotlin知识也是有价值的,对个人成长有帮助。 而且在新代码中,你完全可以用Kotlin,只要团队 review通过就行。" 小王:"我对Kotlin没什么兴趣,我就想继续用Java, 会不会以后被边缘化?" 你:"完全不会!这个方案就是要尊重每个人的选择。 你可以继续用Java,不会因此受到任何不利影响。 项目中评价代码质量,不是评价语言选择。" Bob:"对,我支持这个。不能因为语言选择搞派系。" 你:"没错!我们的目标是写好代码,解决问题, 不是搞语言之争。 那我们就这样定了: - 从下个月开始执行'三步走策略' - 我负责整理学习资源和最佳实践文档 - Bob,你能不能帮我一起制定Java-Kotlin互操作规范? 你对Java很熟,这个规范需要你的expertise - 6个月后,我们一起review数据,共同决定下一步 大家还有问题吗?" 团队:"没有了,我们同意这个方案。"

后续影响(6个月后):

• 3名同学学习了Kotlin,在新代码中使用
• Kotlin代码的bug率比Java低15%
• 代码行数减少约20%
• 3名prefer Java的同学继续用Java,没有压力
• 团队review时对两种语言都很友好
• Bob看到数据后,也开始学习Kotlin
• 招聘时,Kotlin成为加分项,吸引了更优秀的候选人
• 团队技术氛围更开放,愿意尝试新技术

成功要点:

• 一对一了解核心顾虑,不在公开场合争论
• 寻找共同目标,建立共识基础
• 提出"三步走"第三选择,兼顾多方诉求
• 自愿而非强制,尊重个人选择
• 用数据评估,而非主观判断
• 邀请反对者参与方案制定(Bob制定互操作规范)
• 长期看,技术演进和团队和谐双赢

案例3:重构时机讨论 - 现在 vs 以后

场景设定:

• 某个核心模块代码质量差,技术债严重
• 你认为应该立即重构
• 项目经理说现在没时间,要先做新需求
• 团队被夹在中间,不知道听谁的
• 需要达成共识,否则项目会一直拖延

完整对话:用数据和第三选择达成共识

【背景调研(你的准备工作)】 你花了2天时间做了详细的调研: 1. 技术债的量化数据: - 这个模块有3000行代码,圈复杂度平均35(正常应该<15) - 最近3个月,这个模块的bug占了全部bug的40% - 修复一个bug平均需要4小时(其他模块平均1小时) - 代码review时,新人理解这个模块平均需要3天 2. 重构的成本估算: - 完全重构需要3周(1人全职) - 渐进式重构需要分4次,每次2天 3. 不重构的成本估算: - 每月花在这个模块的bug修复时间:约32小时 - 新需求在这个模块上的开发效率:比正常慢50% - 未来6个月的机会成本:约96小时(4人周) 【第一步:和项目经理的一对一沟通】 你:"Linda,想和你聊聊XXX模块重构的事情。 我知道你说现在没时间,我想理解一下你的concerns。" Linda:"主要是时间压力。老板要求这个季度要上线 5个新功能,时间本来就很紧,如果现在重构, 新功能肯定会delay。" 你:"我理解。能问一下,如果新功能delay, 会有什么后果?" Linda:"老板会不满意,可能影响团队的OKR评分, 也会影响业务目标。所以我不能承担这个风险。" 你:"明白了。那我想分享一下我调研的数据, 然后我们一起看看有没有两全的办法。可以吗?" Linda:"好的,你说。" 你:"我做了一个详细的分析(展示数据): 【当前状况】 - 这个模块的bug占全部bug的40% - 修一个bug平均要4小时,是其他模块的4倍 - 新需求在这个模块上的开发速度慢50% - 最近3个月,我们在这个模块上花了96小时修bug 【重构成本】 - 完全重构:3周(120小时) - 渐进式重构:分4次,每次2天(64小时total) 【不重构的成本】 - 未来6个月预计还要花96小时修bug - 新功能开发效率低50%,额外多花约40小时 - Total:136小时 【关键洞察】 如果用渐进式重构(64小时),在6个月内就能回本, 而且之后每个月都能节省时间。 更重要的是,新功能如果要在这个模块上开发, 现在重构可能反而更快,因为开发效率能。 我想问:这个季度的5个新功能,有几个需要改动 这个模块?" Linda:"查看...(查看需求列表)5个需求中, 有3个需要改这个模块。" 你:"如果有3个需求要改这个模块,那么: - 不重构,开发这3个需求预计要60小时 - 先重构(渐进式,16小时),再开发,预计要16+30=46小时 实际上,先重构反而能节省14小时,而且质量更好, bug更少,还不会产生更多的技术债。 Linda,基于这些数据,你觉得是否值得重构?" Linda:"如果真的是这样,那重构确实有道理。 但我有两个concerns: 1. 你的估算准确吗?会不会实际超时? 2. 重构期间出了问题,谁负责?" 你:"这两个concerns非常重要!让我回应一下: 1. 估算的准确性: - 我是基于类似模块的重构经验估算的 - 为了保险,我可以加20%的buffer - 渐进式重构的好处是,如果第一次就发现超时, 可以立即停止,已完成的部分也有价值 2. 责任问题: - 我承诺:如果重构超时或出问题,我个人加班补回来, 不影响新功能的交付时间 - 我会每天同步进度,有问题立即报告 - 重构期间会保留旧代码,可以随时回滚 这样你是否能接受风险?" Linda:"你能做出这样的承诺,我觉得可以试试。 不过我希望用最稳妥的方式,你说的渐进式重构, 具体怎么做?" 【提出第三选择:渐进式重构】 你:"渐进式重构的方案是这样的: **Iteration 1(Week 1,2天)** - 重构数据层,提取接口,解耦依赖 - 影响范围:只有数据层内部 - 风险:低,单元测试覆盖 - 收益:后续需求1需要改数据层,这个重构后能快50% **Iteration 2(Week 3,2天)** - 重构业务逻辑层,拆分大方法 - 影响范围:逻辑层内部 - 风险:低,有完整回归测试 - 收益:后续需求2、3都要改逻辑层,这个重构后更清晰 **Iteration 3(Week 5,2天)** - 重构UI层,提取ViewMode - 影响范围:UI层内部 - 风险:中,需要UI测试验证 - 收益:UI层代码更简洁,新需求4能受益 **Iteration 4(Week 7,2天)** - 整体优化和文档更新 - 影响范围:整个模块 - 风险:低,之前都验证过了 - 收益:代码质量全面提升,新人容易理解 **关键点**: - 每个Iteration独立,有价值,可以随时停止 - 每次重构后立即回归测试,确保功能正常 - 重构和新需求穿插进行,互不影响 - 每次重构都让后续的开发更快 Linda,这个方案是否让你放心?" Linda:"你考虑得很细。我觉得可以。不过我还有 最后一个要求:每次重构后,我要看回归测试报告, 确认没有引入新问题。如果有问题,立即回滚。" 你:"完全没问题!我会每次重构后提交测试报告给你。 另外,我建议我们把这个方案也和团队分享, 让大家知道我们不是为了技术而技术,而是基于 数据和business价值做决策。这样团队也能学到 如何权衡技术债和业务需求。" Linda:"好主意!那我们就这样定了。" 【第二步:团队会议分享】 你在团队会议上: "大家好,关于XXX模块重构的事情,我和Linda讨论后, 达成了一个方案,想和大家分享。 首先,我们都认同: - 这个模块的技术债确实很严重 - 但项目进度也很重要,不能因为重构delay新功能 所以我们的challenge是:如何在不影响业务的前提下, 逐步偿还技术债? 我做了一个详细的数据分析(展示数据和方案)... 最终我们决定采用'渐进式重构'方案,分4次进行, 每次2天,总共8天。这样的好处是: - 不影响新功能开发 - 每次重构都有独立价值 - 风险可控,可以随时停止 - 反而能加快后续新功能的开发 我想强调的是:这不是我强推重构,也不是Linda强推需求, 而是我们基于数据,找到的一个兼顾技术和业务的方案。 我希望通过这个案例,让大家学到: - 技术债要量化,用数据说话 - 技术决策要考虑business impact - 遇到分歧时,找第三选择,而非二选一 大家有什么问题吗?" 团队成员A:"我可以参与重构吗?我也想学习重构的方法。" 你:"太好了!我正好需要人一起review重构代码, 项目中可以pair programming,你能学到很多。" 团队成员B:"重构后,我们会更新文档吗?我希望新人 能更容易理解这个模块。" 你:"必须的!Iteration 4专门包含文档更新, 项目中会把设计思路、关键决策都文档化。" Linda:"我补充一下,这个重构方案是经过详细评估的, 不是拍脑袋。我希望大家以后遇到类似的技术债, 也能这样: 1. 量化问题和成本 2. 评估重构的投入产出比 3. 设计低风险的执行方案 4. 基于数据做决策 这样我们就能在技术和业务之间找到平衡。"

后续影响(2个月后):

• 4次渐进式重构全部完成,实际用了9天(比预估多1天)
• 重构后,新功能开发效率确实提升了约45%
• Bug率下降了60%,从每月8个降到每月3个
• 新人理解这个模块的时间从3天降到半天
• 团队学到了渐进式重构的方法
• 你和Linda建立了相互信任,之后的技术决策都很顺利
• 老板看到数据后,称赞团队在技术和业务之间找到了平衡

成功要点:

• 用数据量化技术债和重构收益
• 理解对方的压力和优先级(业务deadline)
• 提出渐进式重构的第三选择
• 承诺责任,降低对方风险
• 让技术决策和业务价值对齐
• 团队学习,建立技术债评估的文化

实用工具

工具1:技术分歧讨论检查清单

使用时机:准备技术分歧讨论时

□ 准备阶段 □ 我量化了问题和影响(数据) □ 我评估了不同方案的成本和收益 □ 我了解了对方的核心顾虑 □ 我准备了第三选择方案 □ 我的心态是解决问题,不是赢得争论 □ 讨论阶段 □ 先寻找共同目标 □ 理解双方的核心关注点 □ 用数据而非主观判断 □ 提出第三选择,邀请共同创造 □ 避免技术ego,保持开放 □ 征询意见,给对方参与感 □ 决策阶段 □ 基于数据和共同目标决策 □ 明确下一步行动和责任人 □ 设定评估节点和调整机制 □ 强调共同决策,而非个人胜利 □ 执行阶段 □ 兑现承诺 □ 定期同步进展 □ 及时处理问题 □ 用数据评估效果

工具2:技术方案对比模板

使用时机:需要对比多个技术方案时

## 技术方案对比:【问题描述】 **背景**: - 当前问题:___________ - 业务目标:___________ - 技术约束:___________ **备选方案**: ┌──────────────────────────────────────────────┐ │ 对比维度 │ 方案A │ 方案B │ 方案C │ ├──────────────────────────────────────────────┤ │ 开发成本 │ ___ 人天 │ ___ 人天 │ ___ 人天 │ │ 学习成本 │ ★★★ │ ★★★ │ ★★★ │ │ 维护成本 │ ★★★ │ ★★★ │ ★★★ │ │ 性能表现 │ ___ms │ ___ms │ ___ms │ │ 包体积影响 │ +___KB │ +___KB │ +___KB │ │ 稳定性 │ ★★★ │ ★★★ │ ★★★ │ │ 团队熟悉度 │ ★★★ │ ★★★ │ ★★★ │ │ 技术风险 │ 低/中/高 │ 低/中/高 │ 低/中/高 │ │ 长期收益 │ ★★★ │ ★★★ │ ★★★ │ └──────────────────────────────────────────────┘ **推荐方案**:【方案X】 **推荐理由**(按重要性排序): 1. ___________ 2. ___________ 3. ___________ **权衡说明**: - 放弃方案Y的原因:___________ - 放弃方案Z的原因:___________ **风险和应对**: - 风险1:___________ → 应对:___________ - 风险2:___________ → 应对:___________ **执行计划**: - Phase 1:___________ - Phase 2:___________ - Phase 3:___________ **评估标准**: - 指标1:___________ - 指标2:___________ - 评估时间:___________

工具3:第三选择思维提示卡

使用时机:陷入二选一困境时

当你面临A vs B的困境时,问自己: □ "我们的共同目标是什么?" (寻找背后的真正目的) □ "A和B各自的核心优势是什么?" (提取精华) □ "能否结合A和B的优点?" (融合创新) □ "能否分阶段?先做什么,后做什么?" (时间维度) □ "能否分场景?哪些场景用A,哪些场景用B?" (空间维度) □ "能否并行试验?让数据说话?" (实验验证) □ "能否创造一个完全不同的方案C?" (跳出框架) 第三选择的特征: ✓ 比A和B都更能实现共同目标 ✓ 降低双方担心的风险 ✓ 双方都感到被尊重 ✓ 创造而非妥协

工具4:技术债量化评估表

使用时机:讨论是否要偿还技术债

## 技术债评估:【模块名称】 **技术债的表现**: □ 代码复杂度:圈复杂度 ___ (正常<15) □ 代码行数:___ 行(单文件>500行为过多) □ Bug率:最近3个月 ___ 个bug (占比 ___%) □ 修复成本:平均 ___ 小时/bug (正常<2小时) □ 开发效率:比正常慢 ___% □ 新人理解成本:___ 天(正常<1天) □ 代码重复率:___% (正常<10%) **量化影响**: - 最近3个月花在这个模块的时间:___ 人时 - 未来6个月预计花费:___ 人时 - 对团队士气的影响:___ (1-10分) **重构成本估算**: - 完全重构:___ 人时 - 渐进式重构:___ 人时(分 ___ 次) - 最小优化:___ 人时 **投资回报率**: - 重构成本:___ 人时 - 6个月节省:___ 人时 - ROI:___% - 回本周期:___ 月 **建议**: □ 立即重构(ROI>50%) □ 渐进式重构(ROI 20-50%) □ 暂缓重构(ROI<20%) □ 重写(技术债太严重) **执行方案**: ___________

工具5:技术讨论的黄金句式

避免技术Ego的表达方式:

【提出观点时】 **错误做法** - "必须用XXX" **正确做法** - "我倾向于XXX,因为YYY,大家怎么看?" **错误做法** - "这是最佳实践" **正确做法** - "在类似场景下,XXX是常见做法,我们的场景是否适用?" 【回应不同意见时】 **错误做法** - "你不懂XXX" **正确做法** - "能否解释一下你的考虑?可能我理解不全面" **错误做法** - "这个方案明显不对" **正确做法** - "我有些顾虑,主要是XXX,你怎么看?" 【承认不确定时】 **正确做法** - "关于XXX部分,我不太确定,有人有经验吗?" **正确做法** - "我可能对YYY的理解有偏差,能否帮我澄清一下?" 【邀请挑战时】 **正确做法** - "这是我的想法,但我可能有盲区,请帮我看看有什么问题" **正确做法** - "如果你发现我的方案有漏洞,请一定告诉我" 【达成共识时】 **正确做法** - "感谢大家的讨论,我们共同创造了这个方案" **正确做法** - "这个方案融合了大家的智慧,比我最初的想法更好"

小节总结

核心要点回顾

1. 技术分歧的本质:

• 不是对错之争,是优先级、风险偏好、视角、经验的差异
• 表面是技术,背后是人的需求和顾虑

2. 避免技术Ego:

• 把"我的方案"和"我"分离
• 目标是解决问题,不是赢得争论
• 不同意见是帮助,不是攻击

3. 寻找第三选择:

• 超越二元对立,共同创造更优方案
• 理解双方核心关注点,找到共同目标
• 用数据驱动决策,而非主观争论

4. 常见的第三选择模式:

• 分阶段实施
• 并行试验
• 分场景选择
• 混合方案

立即可应用的技巧

技巧1:准备技术讨论时,量化数据

- 问题的量化指标 - 不同方案的成本收益对比 - 风险评估和应对措施

技巧2:讨论中先寻找共同目标

"虽然我们方案不同,但我们是否在XXX目标上有共识?"

技巧3:提出第三选择时的句式

"有没有一种方式,既能实现A的优点,又能实现B的优点?" "能否分阶段?先XXX,再根据数据决定YYY?"

技巧4:避免技术Ego的自我提醒

- "我的目标是解决问题,不是证明自己对" - "不同意见是帮实践中发现盲区的机会" - "方案被否决不等于我被否定"

常见误区

误区1:技术分歧必须有一个赢家

• 错误:要么你的,要么我的
• 正确:寻找第三选择,共同创造

误区2:技术先进就应该用

• 错误:最新的技术就是最好的
• 正确:适合场景和团队的才是最好的

误区3:资历深就应该听他的

• 错误:用权威压制讨论
• 正确:用数据和逻辑说服

误区4:为了和谐放弃技术追求

• 错误:过度妥协,不表达真实想法
• 正确:坚持技术追求,但用合适的方式

本章总结

技术分歧不是战场,而是共同探索最优解的机会。

技术讨论中最常见的陷阱是把"方案被否定"等同于"我被否定",从而产生防御和对抗。真正的高手能把分歧变成集体智慧:通过数据说话、寻找第三选择、用小实验代替大争论。技术分歧的最终目的不是"谁赢",而是"什么方案最好"。

核心要点速查:

第三选择思维公式:

A方案优点 + B方案优点 → 能否兼得? ↓ 能否分阶段实现?能否混合使用? ↓ 能否用小实验低成本验证?

实战心法:

• 讨论技术方案时,把"我推荐XXX"改成"在YYY场景下,XXX的优势是ZZZ"——加场景限定,减少对抗
• 自我提醒:方案被否决不等于我被否定,目标是解决问题不是证明自己

技术的本质是解决问题,不是证明正确。把ego留在门外,把好奇心带进会议室。