工程师如何明白的做事情

Tw93 - 22/12/08

fit

首先来套个娃 🪆

什么是工程师？

  • 一个通过科学和技术知识解决问题的专业人员
  • 掌握专业的知识和技能，并具备创新能力和解决问题的能力


大前提

  • 第一我们不是码农
  • 第二我们不是资源
  • 第三我们是一个有专业技能的脑力工作者

什么叫明白的做事情？

  • 事情本身被人们理解得很清楚、明确、没有疑惑、不懵逼
  • 过程中对干活的内容、步骤、条件有清晰的认识，做起来一气呵成

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，一种指导制定互联网标准的文档格式 </br>

  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