工程师如何明白的做事情
Tw93 - 22/12/08
---
---
# 首先来套个娃 🪆
---
# 什么是工程师？
- 一个通过科学和技术知识解决问题的**专业人员**
- 掌握专业的知识和技能，并具备**创新能力和解决问题的能力**
大前提
- 第一我们不是码农
- 第二我们不是资源
- 第三我们是一个有专业技能的脑力工作者
---
## 什么叫明白的做事情？
- 事情本身被人们理解得很清楚、明确、没有疑惑、**不懵逼**
- 过程中对干活的内容、步骤、条件有清晰的认识，做起来一气呵成
---
## Talk is cheap，Show me the 实操
---
# 工程师如何明白的做事情
1. 理清楚
2. 讲明白
3. 做到位
当你理清楚了问题是什么？为什么出现？怎么做？做的过程会很有逻辑，而且还是自己想写的代码，你会发现真的很爽 😃
---
# 如何**理清楚**问题
---
## 简单归纳出这个问题是什么
1. 最原始的需求/问题是什么？
2. 为什么要解决这个问题？不解决会有什么影响？**不做效率最高 🙊**
3. 问题发生的根本原因是什么？
4. 这个定义对于其他人能否听得懂？
🌰：发现 XXX 无线端用户使用量明显低于 PC 端，排查是有多处用户外出必备功能有卡点，假如不解决会很影响用户的使用效率。
---
## 我常用拆问题的思维模型
1. MECE 分解法：相互独立，完全穷尽的分解出最小的问题 **分类**
2. 归因回溯法：通过不同地反推追问，从而找到深层的原因 **假设**
3. 5W2H：What、Who、Where、When、Why、How、How Much **角度**
---
# MECE 分解法
Mutually Exclusive 各部分之间**相互独立**，Collectively Exhaustive 所有部分**完全穷尽**。用于将一个大问题拆分成若干个互相排斥且集合完备的小问题，让你很清晰简单的解决。
- 二分法：找一个维度，分成 2 个部分，如中国/外国
- 过程法：事情发展的时间顺序，流程，程序，如 SOP
- 要素法：根据事物重要的几个要素进行划分，如夸人
- 公式法：简单数学公式，如 耗时 = 前端+传输+接口
- 矩阵法：将一个事物拆分成两维度变成 4 个象限，如重要紧急
---
# 归因回溯法
一种通过 **逐步排查和分析多个可能** 的原因，来寻找事件真正的原因的方法，从事件发生后的结果入手，逆序推断，最终找到真正的原因。
**🌰：一个视频客户端，播放稳定性数据突然发生了 30%的下降，如何用找到问题**
🤔：是不是系统的原因 -> 是不是网络的问题 -> 是不是手机品牌的原因 -> 是不是 App 版本问题
---
# 5W2H 法
- 🐝 What、Who、Where、When、Why、How、How Much
- 💡 在 **计划做一款产品** 的时候，用这个方法来明确需求痛点
- 🥸 用于自问自答的方式来 **发觉问题深层次的原因**
💡：这是什么产品->什么时候上线->在什么地方使用->为什么需要做它->主要用户是谁->怎么来实现->需要花费啥
🥸：1940 年代，杰弗逊纪念堂墙比周围其他有更多的裂纹，需要花大量资金来修补墙，开始认为是清洁剂的问题，解决办法是减少次数，换牌子？（墙脏->鸟粪->燕子->蜘蛛->飞虫->光大）
---
# 怎么判断问题理清楚了
- 还有没有懵逼的地方吗？
- 还有没有没有考虑到到的点？
- 你已经完全没有问题困恼了
- 无论别个怎么 argue，我基本上可以答得上来
---
# 想明白后，那怎么**讲到位**呢？
---
或者说 💡
如何让同事也很清楚这个事情
---
# 如何写一个很明白的文档
1. **组织结构有逻辑感**，标题和副标题、段落分组，脑图先行
2. **简单接地气的表达**，清晰易理解的描述，看得懂，讲逻辑
3. **很恰当的例子**，实际或者模拟的案例、Demo 的案例、流程图
如何判断写明白了：别人看着你的文档，也就可以开始写代码了 🤓
---
# 可以去查一下 RFC
Request for Comments，一种指导制定互联网标准的文档格式
1. 明确是谁来读，文章目的，并确定其适用的范围
2. 描述问题的背景和相关的已有解决方案
3. 对解决方案详细阐述，有清晰的逻辑推理和可实现的细节
4. 未解决的问题以及未来可能性的说明
---
# 写文档的反例思考
- **为了万无一失，是否需要对不同的人写不同的文档？**
- **是否为了显示我的牛逼，将简单逻辑写得很复杂？**
- **为了显示我很有“味道”，出现大量赋能、抓手、麻将大图**
- **由于 TL 催我交作业，想不出来只能编，其实我自己都觉得不靠谱**
---
# 写清楚了，讲就简单了吗 😖
---
# 我讲事情的时候很容易紧张？
1. 首先明确任何人讲东西都会紧张，只不过他熟练了而已
2. 你感觉到的普通紧张，其实别人看不出来
3. 假如你准备好了，你会很自信，让你没有那么紧张
---
# 讲明白事情常用模型 - STAR
- Situation：遇到的具体**情景**
- Task：需要解决的问题或**任务**
- Action：采取的**行动**和实施的过程
- Result：采取行动的**结果**
🌰：我们打算如何解决XXX的性能体验问题？
---
# 如何让合作方买账 - SCQA
- Situation：由大家都熟悉的**情景**事实引入
- Complication：实际情况往往和我们的要求有**冲突**
- Question：出现**问题**怎么办
- Answer：**回答**我们的解决方案是什么
🤦🏻♀️🌰：一句你可能记得住一辈子的广告语，“得了灰指甲，一个传染俩，问我怎么办，马上用亮甲”
---
# **没有**讲明白的情况 🥲
- **听的人自己在做自己的事情，甚至有一点想睡觉**
- **听的人没有任何和你讨论的点，一问就是好好好**
- **听的人一脑袋的问号？？不断 argue**
- **"我"高度太高了，你们听不懂是你们能力不够**
---
讲到位了
那就去做明白吧！
---
啊！我不会写代码😰
哈哈那就帮不到你了
---
不过有时做的过程中
发现有变化我该怎么办？
---
# 怎么证明自己做好了呢？
---
# 可能大部分同学想到的是数据 😭
---
但对于我们工程师而言
其实还有很多方式...
---
# Last but not least
---
# 如何将工程师本身做明白呢？
---
# 1️⃣ 有专业技能
---
# 2️⃣ 能讲明白事情
---
# 3️⃣ 会解决各种问题
---
# 4️⃣ 有完成事情的 PM 能力
---
# 5️⃣ 不断学习折腾有新点子
---
# 6️⃣ 懂做易于使用的产品
---
