04-09-04 陈述观点 - 学习笔记

04-09-04 陈述观点 - 学习笔记

章节信息

核心主题:STATE技巧、事实与观点分离、试探性表达、说服的艺术
学习目标:掌握STATE五步法,学会既坦诚又安全地表达观点
关键要点:Share facts(分享事实)、Tell story(说出想法)、Ask(征询观点)、Talk tentatively(试探表达)、Encourage testing(鼓励测试)

核心概念

1. 为什么陈述观点这么难?

常见困境

在关键对话中,我们经常面临一个两难选择:

说实话 vs 保持和谐

说得太直接 → 伤害关系,引发冲突 说得太委婉 → 对方不理解,问题不解决

传统误区:

误区1:认为这是个二选一的问题

• 要么直接说,不管后果
• 要么不说,维护关系
• 正确:可以既坦诚又安全地表达

误区2:认为"真诚"就是"直率"

• “我就是这个性格,有话直说”
• “我是为你好,所以实话实说”
• 正确:真诚不等于无礼,直率不等于冒犯

误区3:认为表达观点就是说服对方

• 目标是让对方接受我的看法
• 要用各种理由证明我是对的
• 正确:目标是把观点放入共享池,让对方理解

核心挑战

在Android开发中,常见的困难场景:

技术分歧:

你认为应该用MVVM,对方坚持用MVC → 如何表达观点而不显得攻击对方的技术能力?

代码审查:

你发现同事的代码有严重问题 → 如何指出问题而不让对方感到被批评?

向上反馈:

你觉得领导的技术决策有问题 → 如何表达不同意见而不显得不尊重?

2. STATE技巧:五步表达法

STATE是一个助记词,代表陈述观点的五个步骤:

S - Share facts 分享事实 T - Tell your story 说出想法 A - Ask for others' 征询观点 paths T - Talk tentatively 试探表达 E - Encourage testing 鼓励测试

Step 1: Share facts(分享事实)

定义:从客观事实开始,而非主观判断。

为什么要从事实开始?

原因1:事实最不容易引发防御

• 事实是客观的,难以争辩
• 判断是主观的,容易引发争论
• 从事实开始,建立共同基础

原因2:事实更有说服力

• 数据比空谈有力
• 具体比抽象清晰
• 可验证比模糊可信

原因3:事实帮助对方理解你的推理

• 让对方看到你的观察
• 让对方理解你的逻辑链条
• 让对方有机会指出你的盲区

什么是事实?什么是判断?

事实(Fact) 判断(Judgment) ──────────────────────────────────────── 可观察的 推断的 可测量的 评价性的 客观的 主观的 大家都会同意的 可能有争议的

实例对比:

场景:代码审查

判断先行:

"这段代码写得不好,性能有问题,需要重构。" → 对方可能的反应:"哪里不好了?我觉得挺好的啊!"

事实先行:

"这段代码在处理大列表时,每次滑动都会创建新的ViewHolder, 导致滑动时帧率掉到20fps。我在Profiler里看到每秒有200+个 对象被创建和销毁。" → 对方更容易接受,因为是可验证的观察

如何识别和分享事实?

检查清单:

□ 这是我亲眼看到的吗?(观察) □ 这是可以测量的吗?(数据) □ 别人能验证这个说法吗?(可验证) □ 这是描述而非评价吗?(中性)

常见的"假事实":

假装是事实的判断: **错误做法** - "大家都觉得这个方案不好" (什么是"不好"?谁是"大家"?) **错误做法** - "这个bug明显是你的问题" (什么是"明显"?"你的问题"是判断) **错误做法** - "这种写法很业余" ("业余"是评价,不是事实) 真正的事实表达: **正确做法** - "在上次会议上,Tom和Mary都提到了对这个方案的顾虑" **正确做法** - "这个bug出现在你上周提交的UserManager.java第127行" **正确做法** - "这段代码使用了嵌套的for循环,时间复杂度是O(n²)"

Step 2: Tell your story(说出想法)

定义:在事实的基础上,说出你的推理、判断和感受。

为什么要说出想法?

如果只说事实,不说想法:

• 对方不知道你的关注点
• 对方不理解事实为什么重要
• 对方无法理解你的推理过程

想法的三个层次:

层次1:推理(Reasoning)

• 基于事实的逻辑推导
• 因果关系分析
• 趋势预测

示例: "这段代码每次滑动都创建200+对象(事实), 我推测在老设备上会导致频繁GC,引发卡顿(推理)。"

层次2:判断(Judgment)

• 对情况的评价
• 重要性的认定
• 优先级的看法

示例: "从技术角度看这是个P0级别的性能问题(判断), 因为影响了核心的列表浏览体验,用户感知非常明显。"

层次3:感受(Feeling)

• 情绪状态
• 担心和顾虑
• 期望和需求

示例: "我有点担心这个问题如果不修复,上线后会有大量用户投诉, 影响应用市场评分。"

完整示例:

【事实】 "这段代码在RecyclerView滑动时,每次都调用new ViewHolder(), Profiler显示每秒创建200+对象。" 【推理】 "这会导致频繁的GC,特别是在Android 6.0以下的设备, GC暂停时间比较长,用户会感觉到明显的卡顿。" 【判断】 "从技术角度看这是个需要优先修复的性能问题。" 【感受】 "我有点担心如果现在不修复,上线后处理起来会更麻烦, 而且会影响大量用户的体验。"

注意:想法不是指责

错误的"想法":

"你这代码写得太烂了,连RecyclerView的复用都不会用, 你到底有没有好好学过Android开发?"

这不是表达想法,是人身攻击。

正确的"想法":

"我注意到这里没有使用ViewHolder复用。我想可能是因为 这个场景比较特殊,或者我理解有偏差。能解释一下这里的 设计考虑吗?"

Step 3: Ask for others’ paths(征询观点)

定义:表达完自己的观点后,真诚地询问对方的看法。

为什么要征询观点?

原因1:展现开放态度

• 让对方知道你愿意倾听
• 不是单向的说教
• 不是已经做了决定

原因2:获取对方的信息

• 你可能有盲区
• 对方可能有不同的信息
• 完整的信息池才能做好决策

原因3:让对方参与讨论

• 对方有被尊重的感觉
• 增加对方的commitment
• 共同决策的方案更容易执行

征询的两个层次:

层次1:征询事实

"你看到的情况是怎样的?" "你有没有不同的数据或观察?" "我可能遗漏了什么信息?"

层次2:征询想法

"你怎么看这个问题?" "你的判断是什么?" "你对这个方案有什么顾虑?"

真诚 vs 虚假的征询:

虚假征询(其实已经决定了):

"这个必须用MVVM,你觉得呢?" → 语气和措辞都暗示不容讨论 "你没意见吧?" → 暗示最好别有意见 "我已经和老板确认了,你还有什么想法吗?" → 暗示你的想法不重要

真诚征询(真心想听):

"这是我的想法,你怎么看?可能我有没考虑到的地方。" "你对这个方案有什么顾虑或建议吗?我很想听听。" "我想知道你的真实想法,也许你有更好的方案, 或者发现了我没注意到的问题。"

征询的黄金问题:

1. "你怎么看?" 2. "你的想法是什么?" 3. "我可能漏掉了什么?" 4. "你看到了什么我没看到的?" 5. "有没有我没考虑到的风险?" 6. "你有更好的方案吗?"

Step 4: Talk tentatively(试探性表达)

定义:用试探性的语气表达观点,而非绝对化的断言。

为什么要试探性表达?

原因1:避免触发防御机制

• 绝对化的表达让人想辩驳
• 试探性的表达让人想讨论
• 留有余地让对方更舒服

原因2:反映真实的不确定性

• 你的观点可能不完全正确
• 你可能有信息盲区
• 保持谦逊更接近事实

原因3:鼓励对话而非辩论

• 试探邀请探讨
• 断言引发争论
• 对话比辩论更有效

试探性表达的语言标记:

强度等级:

绝对断言(避免): "这肯定是XX" "必须这样做" "毫无疑问" "显而易见" ↓ 降低强度 ↓ 强烈观点(慎用): "从技术角度看这是XX" "我建议这样做" "我相信" "我确信" ↓ 降低强度 ↓ 试探性表达(推荐): "我觉得可能是XX" "也许我们可以考虑" "技术理解是" "在我看来" ↓ 降低强度 ↓ 开放性探讨(最安全): "不知道是不是XX" "我在想会不会是" "我想了解一下" "能不能讨论一下"

实例对比:

场景:技术方案讨论

绝对化表达:

"这个方案肯定有问题,必须换成MVVM架构, 这是业界最佳实践,没有讨论的余地。" 对方可能的反应: "谁说的?MVC也有很多优点,为什么一定要用MVVM?" → 引发争论

试探性表达:

"我在想,这个场景用MVVM架构可能会更合适一些。 我的理由是XXX。不过我可能理解不全面,你怎么看? 也许MVC在某些方面有我没考虑到的优势?" 对方可能的反应: "嗯,你说的有道理。MVVM确实有这些优点。不过我担心XXX。" → 进入讨论

注意:试探不是弱化

有人担心:试探性表达会显得不自信、没立场。

这是误解!

过度弱化(失去立场):

"我也不太确定,可能,也许,或许,大概,好像... 反正你决定就好,我都行..." → 这不是试探,是回避

有立场的试探:

"我比较倾向于用MVVM(有立场),原因是XXX(有依据)。 但我想听听你的想法,可能我有没考虑到的地方(开放)。" → 既有观点,又开放

试探性表达的黄金句式:

"技术理解是...,你怎么看?" "在我看来...,可能我理解有偏差?" "我倾向于认为...,但我想听听你的想法。" "我观察到...,不知道你是否有同样的感觉?" "也许我们可以考虑...,你觉得这个方向如何?" "我有个想法...,不知道是否可行?"

Step 5: Encourage testing(鼓励测试)

定义:主动邀请对方挑战你的观点,测试你的想法。

为什么要鼓励测试?

原因1:创造最安全的对话环境

• 明确表示欢迎不同意见
• 对方敢于说出真实想法
• 减少对方的心理压力

原因2:发现你的盲区

• 你的观点可能有漏洞
• 你的逻辑可能有跳跃
• 其他人能看到你看不到的

原因3:共同优化方案

• 两个人的智慧大于一个人
• 挑战让方案更完善
• 压力测试后的方案更可靠

鼓励测试的表达方式:

方式1:明确邀请不同意见

"如果你有不同看法,请一定告诉我。" "我很想知道你是否认同这个分析。" "如果你觉得哪里不对,请指出来。"

方式2:询问可能的问题

"你觉得这个方案有什么问题或风险?" "我的推理中有没有什么漏洞?" "你能想到什么我没考虑到的情况?"

方式3:邀请挑战你的假设

"我的判断是基于XXX的假设,这个假设合理吗?" "我可能对XXX的理解有偏差,你怎么看?" "也许我遗漏了什么重要信息?"

方式4:感谢不同意见

"感谢你指出这个问题,我确实没考虑到。" "这个角度很好,我之前没想到。" "你的顾虑很有道理,我们需要解决这个。"

实例:

"这是我的分析和建议。不过我可能有盲区, 所以我特别想听听: 1. 你觉得我的分析中有什么漏洞吗? 2. 有没有我忽略的重要因素? 3. 你能想到什么场景下这个方案会有问题? 4. 如果你不同意,请一定告诉我为什么, 我真的很想知道你的真实想法。 你的挑战对我们做出更好的决策非常重要。"

3. STATE完整流程示例

以下看一个完整的STATE技巧应用:

场景:你发现团队的代码规范没有被遵守,影响代码质量

传统做法(可能引发防御):

"大家的代码都不按规范写,太随意了,这样下去 项目迟早要出大问题。必须严格执行代码规范!"

STATE五步法:

【S - Share facts 分享事实】 "我最近review了20个PR,发现有15个PR没有遵循我们的 命名规范,比如变量名用拼音、方法名过长、缺少注释等。 我统计了一下,这些问题让review时间平均增加了30%, 从20分钟增加到了26分钟。" 【T - Tell your story 说出想法】 "技术理解是,可能是因为大家工作比较忙,或者对规范 不够熟悉,所以没有严格遵守。但我有点担心,如果长期 这样,代码质量会逐渐下降,后期维护会越来越困难。 特别是新人看代码时,不一致的风格会增加理解难度。" 【A - Ask for others' paths 征询观点】 "我想了解一下大家的看法: 1. 你们在写代码时是否觉得遵守规范比较困难? 2. 是规范本身有问题,还是其他什么原因? 3. 有没有什么困难或顾虑?" 【T - Talk tentatively 试探表达】 "我在想,也许我们可以考虑这样做: - 设置一些自动化的代码检查工具 - 做一次规范的复习和培训 - 调整一些不合理的规范条款 不过这只是我的初步想法,可能不全面。" 【E - Encourage testing 鼓励测试】 "我特别想听听大家的真实想法: - 你们觉得这个问题严重吗?也许我过于担心了? - 我提的方案是否可行?有没有更好的建议? - 有没有我没考虑到的困难? 如果你们觉得我的看法有问题,请一定告诉我, 项目中一起找到最合适的解决办法。"

对比效果:

• 基于事实而非指责
• 表达关注而非批评
• 征询意见而非命令
• 试探建议而非强制
• 欢迎挑战而非防御

Android开发实战案例

案例1:代码审查 - 指出内存泄漏问题

场景设定:

• 你在review同事Alice的代码
• 发现一个明显的内存泄漏:Activity持有了匿名内部类Handler
• Alice是团队新人,技术基础一般
• 这段代码如果上线会导致严重的内存问题
• 你需要指出问题,但不想伤害她的积极性

错误示范:直接判断,引发防御

你的评论:

这里有严重的内存泄漏问题!你这样写Handler会持有Activity引用, 导致Activity无法被GC回收。这是Android开发的基础知识, 建议你先把基础学扎实再写代码。这个PR不能merge, 必须改成静态内部类+WeakReference。

Alice的内心反应:

"他是在说我基础不好吗?我已经很努力了... 但是为什么其他地方也这样写没问题? 他是不是故意找茬?算了,我改就是了, 下次再也不想让他review了..."

后续影响:

• Alice感到被批评和羞辱
• 她可能会回避代码审查
• 她可能不理解为什么要改
• 团队学习氛围受损
• 你和Alice的关系受影响

正确示范:STATE五步法

你的评论:

Hi Alice, 感谢提交PR!我仔细看了代码,想和你讨论一个地方。 【S - Share facts 分享事实】 我注意到在UserActivity的第78-85行,使用了匿名内部类的 Handler来处理延迟消息: private Handler mHandler = new Handler() { @Override public void handleMessage(Message msg) { // 处理消息 } }; 这个Handler引用了外部类UserActivity的实例(这是匿名内部类 的特性)。如果用户快速切换页面,Activity被finish但Handler 还有延迟消息在队列中,Activity就无法被GC回收。 我用Android Studio的Profiler做了个测试,快速进出这个页面10次, 发现内存从100MB涨到了180MB,并且有10个UserActivity实例没有 被回收。 【T - Tell your story 说出想法】 技术理解是,这个写法在短时间内可能看不出问题,但如果用户 频繁操作,会导致内存累积,最终可能OOM崩溃。我有点担心这个 问题在生产环境中可能影响用户体验,特别是低端设备的用户。 我记得我刚开始写Android的时候也遇到过类似的问题(我当时 更懵,连问题都没发现),后来学到了一些避免内存泄漏的模式。 【A - Ask 征询观点】 想问一下: 1. 这里的Handler主要是处理什么场景?有没有必须用延迟消息的原因? 2. 你之前了解过Handler导致内存泄漏的问题吗? 【T - Talk tentatively 试探表达】 我在想,也许我们可以考虑几个方案: **方案1:静态内部类 + WeakReference**(最标准) ```java private static class SafeHandler extends Handler { private final WeakReference<UserActivity> mActivity; SafeHandler(UserActivity activity) { mActivity = new WeakReference<>(activity); } @Override public void handleMessage(Message msg) { UserActivity activity = mActivity.get(); if (activity != null) { // 处理消息 } } } private final SafeHandler mHandler = new SafeHandler(this);

方案2:在onDestroy中清理(简单但不完美)

@OverrideprotectedvoidonDestroy(){super.onDestroy();mHandler.removeCallbacksAndMessages(null);}

方案3:使用Lifecycle-aware组件(最现代)

// 使用lifecycleScope或者LifecycleObserver

方案1最安全,方案2简单但不彻底,方案3最优雅但需要引入依赖。
不过这只是我的想法,也许这个场景有我没考虑到的特殊性。

【E - Encourage testing 鼓励测试】
你觉得哪个方案更适合这个场景?或者你有更好的想法?
如果我的分析有什么不对的地方,请告诉我。

另外,如果你想深入了解内存泄漏的检测和避免,我可以分享一些
资料,或者我们可以找个时间一起讨论下,这个坑我之前也踩过很多次😄

**Alice可能的回复**:

"谢谢你的详细说明!我之前确实不太了解这个问题,
现在理解了为什么会内存泄漏。

这个Handler主要是用来延迟500ms更新UI,避免用户操作时
频繁刷新。看起来方案1最安全,我按照方案1改一下,
同时在onDestroy也清理一下消息队列。

如果有相关资料的话,我很想学习一下,避免以后再犯类似的错误。
感谢你的耐心解释!"

**后续影响**: - Alice理解了问题的本质 - 她学到了解决方案 - 她感到被尊重和帮助,而非批评 - 她愿意继续学习和改进 - 你建立了良师的形象 - 团队知识得到了传播 **成功要点**: - 用具体的代码和数据(事实)而非"严重问题"(判断) - 分享自己的经验,降低对方的羞耻感 - 询问背景,而非假设对方不懂 - 提供多个方案,而非单一命令 - 邀请讨论,而非单向教育 - 真诚愿意帮助,而非炫耀技术 ### 案例2:性能优化 - 建议重构低效代码 **场景设定**: - 产品反馈首页列表滑动卡顿 - 你发现是同事Bob写的数据处理逻辑效率太低 - Bob的代码使用了三层嵌套循环,时间复杂度O(n³) - Bob是senior工程师,比你资历深 - 你需要建议优化,但不想显得在教他写代码 #### 错误示范1:过于委婉,问题不清晰 **你的反馈**:

“Bob,你的代码看起来还不错,不过我在想,也许,
可能,在某些情况下,如果数据量比较大的话,
是不是可以稍微优化一下?不过也可能没必要,
你觉得呢?如果你觉得不用改,那就不用改吧…”

**Bob的反应**:

“哦,好的。”(完全不知道你在说什么)

**问题分析**: - 过度弱化,失去了问题的严重性 - 没有事实支撑,Bob不理解问题 - 没有明确建议,Bob不知道怎么做 - 最后问题没有被解决 #### 错误示范2:技术炫耀,引发反感 **你的反馈**:

“Bob,这段代码性能太差了,三层嵌套循环,
时间复杂度O(n³),这种代码在高级工程师的PR里
不应该出现。应该用HashMap优化到O(n),
这是算法基础知识。我帮你重写一下吧。”

**Bob的反应**:

“我写代码的时候你还不知道在哪呢,
这段代码跑了一年了也没见有人说卡顿,
你现在来挑刺?”

**问题分析**: - 贬低对方的技术能力 - 居高临下的态度 - 没有考虑对方的面子(特别是senior) - 引发防御和对抗 #### 正确示范:STATE五步法,尊重资深同事 **你的反馈**:

Hey Bob,想和你讨论一下首页列表的性能问题,有10分钟时间吗?

【S - Share facts 分享事实】
产品那边最近收到一些用户反馈,说首页列表滑动时偶尔会卡顿。
我用Profiler分析了一下,发现主要瓶颈在数据处理这一块:

• 测试数据:50个商品,每个商品有20个属性,10个标签
• 当前耗时:处理一次数据需要180ms
• 瓶颈代码:DataProcessor.java的filterAndSort方法
• 具体问题:三层嵌套循环,每次滑动都要重新计算

我看了代码,大概是这样的结构:

for(Productproduct:products){// O(n)for(Attributeattr:product.attrs){// O(m)for(Tagtag:product.tags){// O(k)// 匹配和计算}}}

在数据量小的时候(10-20个商品)看不出问题,但当商品数量
增加到50+时,处理时间就会明显增加,导致UI卡顿。

我在老设备(Android 7.0, 2GB内存)上测试,帧率会掉到35fps。

【T - Tell your story 说出想法】
我回想了一下这段代码的历史,应该是去年初版开发的时候,
商品类型比较少,这个处理逻辑是没问题的。但现在业务发展了,
商品数量和属性都大幅增加,原来的逻辑就有点吃力了。

我理解这不是代码质量的问题,而是业务规模变化带来的挑战。
我也遇到过类似的情况,一开始简单的实现,后来发现需要优化。

我有点担心随着业务继续增长,这个问题会越来越明显,
特别是大促期间商品数量激增的时候。

【A - Ask 征询观点】
我想先了解一下:

1. 这段逻辑当时设计的时候,有什么特殊的考虑吗?
   比如必须要三层循环的原因?
2. 你有没有观察到类似的性能问题?
3. 这段代码是否有其他地方也在调用?我怕改了影响其他功能。

【T - Talk tentatively 试探表达】
我初步想了几个优化思路,不知道是否可行:

思路1:预处理 + HashMap
把三层循环改成预处理,用HashMap存储映射关系:

// 预处理:O(n*m*k),但只做一次Map<String,Set<Product>>tagToProducts=buildIndex(products);// 查询:O(1)Set<Product>result=tagToProducts.get(targetTag);

优点:查询快,缺点:占用一些内存

思路2:数据库索引
把匹配逻辑下沉到数据库,利用索引加速
优点:最彻底,缺点:改动较大

思路3:分页加载
不一次性处理所有数据,按需处理
优点:改动小,缺点:治标不治本

我个人倾向于思路1,因为改动相对可控,效果也比较明显。
用HashMap的话,处理时间预计能从180ms降到10ms以内。

不过我可能对这段代码的上下文理解不够全面,所以这些只是
初步想法。

【E - Encourage testing 鼓励测试】
你对这几个思路有什么看法?或者你有更好的方案?
也许我的分析有什么遗漏的地方?

特别想听听:

1. 我的性能分析准确吗?会不会是我测试方式有问题?
2. 你觉得这个优化的优先级如何?是否值得现在做?
3. 有没有我没考虑到的技术约束或业务限制?

如果你觉得合适,我可以先实现一个demo,我们一起看看效果,
再决定是否要改。或者你有其他安排也完全OK,我跟你的节奏走。

**Bob可能的回复**:

"感谢你的详细分析!确实,这段代码是一年前写的,那时候
商品数据库只有十几个商品,完全没想到会增长这么快。

你的分析很准确,我之前也隐约感觉有点慢,但没有具体测试。
你提到的HashMap方案听起来不错,改动可控,效果也明显。

这样吧:

1. 你先做个demo,我们一起review一下
2. 确保兼容现有的业务逻辑(特别是XXX场景)
3. 充分测试后,我们一起上线

另外,其他几个页面可能也有类似的问题,如果这个方案
效果好,我们可以一起优化一下其他地方。

这个优先级确实挺高的,用户体验问题不能拖。
我这周会配合你完成这个优化,有问题随时找我。"

**后续影响**: - Bob理解了问题,没有感到被批评 - 你展现了专业性,也尊重了对方 - 问题得到了有效解决 - 你和Bob建立了更好的协作关系 - 为后续的代码优化建立了良好模式 **成功要点**: - 用数据和测试结果(事实)而非"代码不好"(判断) - 将问题归因于业务变化,而非个人能力 - 分享自己的类似经历,建立共鸣 - 详细询问背景,显示尊重 - 提供多个方案,分析优劣 - 真诚征询意见,而非单向建议 - 表示愿意配合和支持 ### 案例3:架构选型 - 技术分歧讨论 **场景设定**: - 新项目要选择架构模式:MVC vs MVVM - Tech Lead倾向于用团队熟悉的MVC - 你认为MVVM更适合这个项目 - 决策会议在下午,需要说服团队 - 这关系到未来一年的开发效率 #### 错误示范:技术至上,忽略团队现状 **你在会议上的发言**:

"我强烈建议用MVVM,理由如下:

1. MVVM是Google推荐的架构
2. 数据绑定降低代码量
3. ViewModel生命周期安全
4. Jetpack组件支持MVVM
5. 业界都在用MVVM

MVC已经过时了,还在用MVC的公司技术都比较落后。
项目中应该拥抱先进技术,不能因为团队不熟悉就不学。
学习成本是一次性的,长期收益是巨大的。"

**Tech Lead的反应**:

“你说的这些我都知道,但是你考虑过团队现状吗?
项目中5个Android开发,只有你和小李用过MVVM,
其他3个人学习成本怎么算?项目要求3个月上线,
你确定来得及?而且MVC也没你说的那么不堪。
我还是倾向于用MVC。”

**问题分析**: - 只强调技术优势,忽略团队现实 - 贬低现有技术,引发防御 - 没有数据支撑,只有原则 - 没有考虑对方的顾虑 - 容易变成技术ego之争 #### 正确示范:STATE五步法,兼顾技术与现实 **你在会议上的发言**:

感谢大家参加这次架构讨论会议。我做了一些准备工作,
想和大家分享一下我的分析,然后听听大家的想法。

【S - Share facts 分享事实】
首先,我梳理了一下这个项目的特点:

项目特点:

• 业务复杂度:20+个页面,大量的状态管理
• 数据流向:频繁的网络请求、本地缓存、UI更新
• 团队情况:5名开发,其中2人(我和小李)有MVVM经验
• 时间要求:3个月MVP,6个月完整版
• 长期规划:这个项目会持续维护至少2年

技术调研:
我对比了MVC和MVVM在类似项目中的数据:

• 代码量:MVVM比MVC少约20-30%(参考XXX项目)
• 测试覆盖率:MVVM的ViewModel更容易测试,覆盖率高15-20%
• Bug率:MVVM的数据绑定减少手动UI更新,crash率低约10%
• 学习曲线:有MVC基础的话,MVVM学习时间约1-2周

我还调研了5个竞品:其中4个用MVVM,1个用MVI。

【T - Tell your story 说出想法】
基于这些数据,我的想法是:

短期看:
MVC确实有优势,团队熟悉,可以快速开发,风险低。
这是非常合理的考虑,特别是在时间紧的情况下。

长期看:
MVVM可能更有优势:

1. 项目会维护2年+,20-30%的代码量减少意味着长期维护成本降低
2. 更容易写单元测试,长期质量更有保障
3. 如果未来要引入Compose,MVVM迁移成本更低

我的顾虑:
如果用MVC,我担心的是:

• 随着功能增加,Activity/Fragment会越来越臃肿
• UI逻辑和业务逻辑混在一起,维护困难
• 新人加入时,可能会觉得技术栈有点老

如果用MVVM,我担心的是:

• 前期学习成本,可能影响进度
• 团队的抵触情绪
• 我和小李可能要承担更多的指导工作

【A - Ask 征询观点】
在做建议之前,我想先了解大家的想法:

给Tech Lead:
你主要担心的是时间风险吗?还是有其他方面的考虑?
你觉得什么情况下MVVM会是合适的选择?

给没用过MVVM的同事:
你们对学习MVVM的态度如何?担心的主要是什么?
需要什么样的支持?

给用过MVVM的小李:
你之前用MVVM的体验如何?遇到过什么坑?

【T - Talk tentatively 试探表达】
综合考虑,我有一个折中的建议,不知道是否可行:

阶段1(Week 1-2):准备期

• 我和小李准备MVVM的培训材料和项目模板
• 做一个完整的示例模块(包括网络请求、数据绑定、测试)
• 周五下午做一次内部培训(3小时)

阶段2(Week 3-4):试点期

• 选择2个中等复杂度的模块用MVVM实现
• 其他模块先用MVC,保证进度
• 我和小李重点review MVVM部分,快速解决问题
• 根据试点情况,决定是否全面推广

阶段3(Month 2-3):根据试点调整

• 如果试点顺利,新模块用MVVM
• 如果问题很多,就继续用MVC
• 已有的MVC模块不强制重构,按需优化

这个方案的优点:

1. 风险可控:不是all-in,可以灵活调整
2. 有数据支撑:2个试点模块能给出真实的数据
3. 团队参与:大家都有机会学习和评估
4. 时间可控:不影响整体进度

可能的问题:

1. 同时存在两种架构,可能有些混乱
2. 我和小李的工作量会增加(review + 指导)
3. 如果最终选择MVC,前期的MVVM工作会浪费

【E - Encourage testing 鼓励测试】
这是我的建议,但我可能考虑不全面,所以特别想听听:

1. Tech Lead,你觉得这个折中方案是否能降低你担心的风险?
2. 大家觉得这个学习安排的时间是否合理?
3. 有没有我忽略的重要风险或问题?
4. 有没有更好的方案?

我完全理解最终可能选择MVC,如果大家觉得风险还是太大,
那我们就用MVC,我也完全支持。技术服务于业务,确保项目
成功是第一优先级。

大家怎么看?

**可能的讨论结果**: **Tech Lead**:

"你的分析很全面,特别是考虑了团队现状和时间限制。
我最担心的确实是进度风险,但你提的阶段性方案我觉得
可以尝试。

我的建议是:

1. 试点期必须严格控制时间,如果2周后数据不好,立即切回MVC
2. 你和小李要承诺能快速响应MVVM的问题
3. 每周五我们review一次进展和问题

如果大家没意见,我们就按这个方案试试。"

**没用过MVVM的同事**:

“我其实也想学MVVM,但之前没时间。如果有完整的培训和示例,
我觉得可以试试。就是担心自己学得慢,拖后腿。”

**小李**:

“我之前用MVVM的体验不错,确实能减少代码量。不过刚开始
有些概念需要理解,比如LiveData、ViewModel的生命周期。
如果大家愿意学,我很乐意帮忙。”

**最终决策**:

采用阶段性推进的MVVM方案,2周后根据试点情况决定下一步。

**后续影响**: - 技术方案得到认可 - 团队达成共识,而非强制推进 - 风险可控,有退路 - 团队学习机会,提升积极性 - 你展现了全面思考能力 **成功要点**: - 用数据支撑观点,而非空谈理念 - 同时陈述两种方案的优劣,客观公正 - 承认对方顾虑的合理性 - 提供渐进式方案,降低风险 - 征询每个人的意见,让大家参与 - 保持开放态度,不强推自己的观点 - 明确表示支持最终决策 --- ## 实用工具 ### 工具1:STATE技巧快速检查清单 **使用时机**:准备重要对话时,检查表达是否完整

□ S - Share facts(分享事实)
□ 有具体的观察和数据
□ 是客观事实,不是主观判断
□ 对方可以验证

□ T - Tell your story(说出想法)
□ 说明了推理过程
□ 表达了判断和感受
□ 解释了为什么重要

□ A - Ask for others’ paths(征询观点)
□ 真诚地询问对方看法
□ 开放式问题,不是封闭式
□ 给对方充分表达的机会

□ T - Talk tentatively(试探表达)
□ 用了试探性语言
□ 不是绝对化断言
□ 承认可能有盲区

□ E - Encourage testing(鼓励测试)
□ 明确欢迎不同意见
□ 询问可能的问题
□ 邀请挑战你的观点

### 工具2:事实 vs 判断识别表 **使用时机**:准备陈述时,检查表达是否基于事实

判断性表达(避免) 事实性表达(使用)
──────────────────────────────────────────
“代码质量很差” “代码的圈复杂度是35,超过建议的15”
“性能有问题” “页面加载时间是3.2秒,超过2秒的目标”
“他不认真” “他的5个PR中有4个没有写单元测试”
“这个方案不好” “这个方案需要增加2个依赖库,包体积增加2MB”
“大家都不满意” “在上次会议上,Tom和Alice都提出了顾虑”
“明显的bug” “在Android 8.0上打开这个页面会崩溃”
“很难维护” “这个类有2000行代码,15个public方法”

**快速判断法**:

□ 能用数字衡量吗?
□ 能用工具检测吗?
□ 其他人会得出相同结论吗?
□ 去掉形容词后,还能清晰表达吗?

如果都是YES,很可能是事实
如果有NO,可能是判断

### 工具3:试探性表达句式库 **高度试探(最安全,用于敏感话题)**:

“我在想,会不会是…”
“不知道是否…”
“也许我理解有偏差,但是…”
“我可能想多了,不过…”
“能不能帮我理解一下…”

**中度试探(平衡,日常使用)**:

“技术理解是…”
“在我看来…”
“我倾向于认为…”
“我的观察是…”
“我注意到…”

**低度试探(保留立场,但开放)**:

“从技术角度看…”
“我建议…”
“我相信…”
“根据实践经验…”
“从XXX角度看…”

**选择建议**: - 对上级:高度试探 - 对平级:中度试探 - 对下级:低度试探(但仍要开放) - 敏感话题:高度试探 - 技术话题:中度试探 - 紧急情况:低度试探(但仍要友善) ### 工具4:征询观点的黄金问题 **开放式征询(最好)**:

“你怎么看这个问题?”
“你的想法是什么?”
“你有什么建议?”
“你觉得还有什么需要考虑的?”
“你的顾虑是什么?”

**具体化征询(针对性强)**:

“这个方案在XXX场景下是否可行?”
“你觉得这个优先级合理吗?”
“你担心的主要风险是什么?”
“你对XX部分有什么看法?”

**挖掘深层想法**:

“能说说你为什么这样想吗?”
“你有不同的信息或观察吗?”
“你能帮我理解一下XXX吗?”
“是什么让你有这个顾虑?”

**避免的错误问法**:

错误做法- “你没意见吧?”(暗示别有意见)
错误做法- “这样可以吧?”(不是真心征询)
错误做法- “你能理解吗?”(暗示应该理解)
错误做法- “我说得清楚吗?”(把责任推给自己,但其实不想听反对)

### 工具5:Android开发场景话术模板 #### 模板1:代码审查反馈

【指出问题】
"Hi XXX,我review了代码,在第XX行发现了一个地方想讨论一下:

[具体的代码或行为描述 - 事实]

这可能导致[具体的影响 - 推理]。我有点担心[具体的场景 - 顾虑]。

想了解一下:

1. [询问背景或设计意图]
2. [询问是否有特殊考虑]

我在想是否可以考虑[具体建议],不过可能我理解不全面。
你怎么看?"

#### 模板2:性能问题反馈

【反馈性能问题】
"发现了一个性能问题,想和你讨论一下:

[问题现象 - 事实]:

• 触发场景:XXX
• 性能数据:XXX
• 用户影响:XXX

思路2:XXX(优点XXX,缺点XXX)

我倾向于思路X,不过想听听你的想法。
你觉得有没有其他更好的方案?"

#### 模板3:技术方案建议

【提出技术方案】
"关于XXX,我做了一些调研,想和大家分享一下:

[背景和目标 - 现状]:

• 当前情况:XXX
• 遇到的问题:XXX
• 期望达到:XXX

• 优点:XXX
• 缺点:XXX
• 风险:XXX

方案B:XXX

• 优点:XXX
• 缺点:XXX
• 风险:XXX

1. [征询问题1]
2. [征询问题2]

也许我的分析有遗漏,欢迎指出。"

--- ## 小节总结 ### 核心要点回顾 **1. STATE五步法**: - Share facts:用事实建立共同基础 - Tell your story:说明推理和感受 - Ask for others' paths:真诚征询观点 - Talk tentatively:试探性表达 - Encourage testing:欢迎挑战 **2. 事实与判断的区别**: - 事实:可观察、可测量、客观 - 判断:推断、评价、主观 - 先事实后判断 **3. 试探性表达的价值**: - 避免触发防御 - 反映真实的不确定性 - 鼓励对话而非辩论 **4. 征询观点的重要性**: - 展现开放态度 - 获取完整信息 - 让对方参与决策 ### 立即可应用的技巧 **技巧1:准备重要对话时,写下STATE**

S - 我观察到的事实是:
T - 我的推理和感受是:
A - 我想问对方的问题是:
T - 试探性表达的句式:
E - 我如何鼓励对方挑战:

**技巧2:说话前停顿3秒** - 检查:这是事实还是判断? - 转换:把判断改成事实+推理 - 调整:加上试探性语言 **技巧3:每次表达观点后,问一个问题** - "你怎么看?" - "你觉得呢?" - "我有没有遗漏什么?" ### 常见误区 **误区1:认为试探是弱化立场** - 错误:试探让我显得不自信 - 正确:试探是自信+谦逊的体现 **误区2:只说事实,不说想法** - 错误:只说事实,对方不知道重要性 - 正确:事实+想法,让对方理解你的推理 **误区3:征询变成虚伪** - 错误:假装征询,其实已经决定 - 正确:真心想听,愿意调整 **误区4:过度委婉,失去意义** - 错误:也许、可能、大概太多,问题不清晰 - 正确:清晰表达+开放态度 ## 本章总结 本篇聚焦关键对话中最核心的环节——如何表达自己的观点。通过 STATE 五步法(分享事实、说出想法、征询观点、试探表达、鼓励测试),提供了一套"既能清晰传达观点,又不会触发对方防御"的完整方法论。三个Android开发实战案例(代码审查、性能优化、架构选型)覆盖了从新人到senior、从技术问题到管理决策的不同难度场景,展示了同一种方法论在不同情境下的灵活应用。 **核心要点速查**: - S(Share facts): 先说可验证的事实,不说主观判断 - T(Tell your story): 说明推理过程,让对方理解你的思考路径 - A(Ask): 真诚征询对方观点,用开放式问题获取完整信息 - T(Talk tentatively): 用试探性语言,承认自己可能有盲区 - E(Encourage testing): 明确欢迎不同意见和挑战 **实战心法**: - 说话前停顿3秒: 这是事实还是判断? 能不能加一句"你怎么看?" - 陈述观点的秘诀: 用最坚定的事实做底气,用最开放的姿态邀请对话 **金句**: 好观点不需要被"推销",当事实足够清晰、态度足够开放时,对方自然会接受。