沟通与协作习惯

技术 × 沟通 矩阵
┌─────────────────────────────────┐
│        技术强          技术弱     │
│  ┌──────────────┐  ┌──────────┐ │
│沟│ ★ 核心骨干     │  │ 团队粘合剂│ │
│通│ 能扛事能成事   │  │ 有影响力  │ │
│强├──────────────┤  ├──────────┤ │
│沟│ 技术独狼      │  │ 边缘角色  │ │
│通│ 能干活被埋没   │  │ 难协作    │ │
│弱└──────────────┘  └──────────┘ │
└─────────────────────────────────┘
→ 目标：右上角（技术强 + 沟通强）

✗ 纯技术说法（商业方听不懂）
「要改 3 层架构，涉及 20 个服务，还要改数据模型和缓存策略，
  中间有几个技术难点……」（5 分钟还没说到重点）

✓ 技术翻译（商业方秒懂）
「需要两周，上线后搜索速度能提升 3 倍，用户等待时间从 2 秒
  降到 0.5 秒。」（10 秒说清：要什么 + 得到什么）

汇报结构（30 秒版）
├── ① 结论：目前进度 70%，比计划提前 2 天
├── ② 结果：核心功能已联调通过
├── ③ 价值：下周三可提前交付给业务试用
├── ④ 风险：支付网关联调存在 1 天不确定性（已准备备选方案）

✗ 反例：「今天做了登录、改了订单模块、还看了两个 bug……」
   （流水账：没有结论、没有重点、没有风险）

拒绝公式 = 先说结论 + 诚实原因 + 替代方案 + 约定时间

示例（被加塞紧急需求时）：
├── ① 结论：「这个需求这周我排不了」
├── ② 原因：「手上有两个已承诺的上线任务（订单导出 + 退款修复）」
├── ③ 替代：「可以放到下周；或者如果需要这周，我需要先暂停其中一个」
├── ④ 约定：「你确认优先级后告诉我，我马上调整排期」
→ 效果：诚实 + 建设性 + 把决策权交还给对方

该拒绝的场景
├── ① 无休止的会议邀请（可以只参加有关的部分）
├── ② 不断加塞的「紧急需求」（打乱承诺排期）
├── ③ 责任边界外的活（没权力却要背责任）
├── ④ 会破坏交付承诺的额外任务
└── 不该拒绝：真正的紧急事故 / 高价值机会 / 合理协作

10 分钟冷却法则的应用
├── 场景：收到一条苛刻的代码审查意见
├── ✗ 立即回复：情绪上头 → 语气对抗 → 关系受损
├── ✓ 冷却：离开座位 10 分钟 → 冷静评估 →
│   发现 70% 意见合理 → 回复「谢谢，第 2 点确实是我疏忽，
│   已修复；第 5 点我用了不同方案，附上理由讨论」
└── 结果：问题解决 + 形象加分

评审双方习惯
├── 提交方：
│   ├── 提评审前自己先过一遍 diff
│   ├── PR 描述清楚（做了什么/为什么/怎么验证）
│   └── 及时回应评审意见（不过夜）
├── 审查方：
│   ├── 当天审完（拖慢评审 = 拖慢交付）
│   ├── 对事不对人（批评代码不批评作者）
│   └── 分严重度（P0 阻塞 / P1 应改 / P2 建议）
└── 共识：评审是质量机制不是攻击机制——双方都是为了让代码更好

跨团队协作三习惯
├── ① 接口先行：协作前先对齐接口契约（字段/错误/超时）
├── ② 文档同步：接口变更及时同步文档（防"代码改了文档没改"）
├── ③ 冲突升级：无法对齐时及时找共同负责人（不私下僵持）
└── 原则：协作中最贵的是「信息不同步」——主动同步是最高性价比习惯

好提问公式 = 背景 + 已尝试 + 具体问题 + 期望
├── ✗ 「这个报错了，帮我看看」（无背景、无上下文）
├── ✓ 「订单接口返回 500（背景），我试过本地复现和加日志，
│       定位到 OrderService:47 的 NPE（已尝试），
│       怀疑是 user 参数为 null（具体问题），
│       想确认这里的空值处理策略应该在哪一层（期望）」
→ 好提问让别人 30 秒能帮你；坏提问让别人 30 分钟猜你想问什么

求助三原则
├── ① 先自助 15 分钟（15 分钟法则：能自己解决的不浪费他人时间）
├── ② 带上下文提问（让对方快速进入你的问题）
├── ③ 事后感谢 + 沉淀（解决后把答案写进知识库，帮助下一个问同样问题的人）
└── 进阶：被问同样问题时——「上次这个问题的解答在知识库 XX 页」
    ——把「人肉问答」升级为「知识库问答」