工程师如何明白的做事情

Tw93 - 22/12/08

--- ![fit](https://cdn.fliggy.com/upic/1h2HrE.png) --- # 首先来套个娃 🪆 --- # 什么是工程师? - 一个通过科学和技术知识解决问题的**专业人员** - 掌握专业的知识和技能,并具备**创新能力和解决问题的能力**

大前提

- 第一我们不是码农 - 第二我们不是资源 - 第三我们是一个有专业技能的脑力工作者 --- ## 什么叫明白的做事情? - 事情本身被人们理解得很清楚、明确、没有疑惑、**不懵逼** - 过程中对干活的内容、步骤、条件有清晰的认识,做起来一气呵成 --- ## 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️⃣ 懂做易于使用的产品 --- ![fit](https://cdn.fliggy.com/upic/l7VXSd.png)