明白做事的核心三要素
- 理清楚
- 讲明白
- 做到位
如何理清楚问题
- 最原始的需求/问题是什么？
- 为什么要解决这个问题？不解决会有什么影响，不做效率最高
- 问题发生的根本原因是什么？
- 这个定义对于其他人能否听的懂？
常用拆解问题的思维模型
- MECE分解法：
- 相对独立，完全穷尽的分解出最小的问题——分类
- 归因回溯法：
- 通过不同地反推追问，从而找到深层的原因——假设
- 5W2H：
- What、Who、Where、When、Why、How、How Much——角度
MECE分解法
Mutually Exclusive各部分之间Collectively Exhaustive所有部分。用于将一个大问题拆分成若干个互相排斥且集合完备的小问题，让你很清晰简单的解决。
- 二分法：找一个维度，分成2个部分，如中国外国
- 过程法：事情发展的时间顺序，流程，程序，如SOP
- 要素法：根据事物重要的几个要素进行划分，如夸人
- 公式法：简单数学公式，如 耗时=前端+传输+接口
- 矩阵法：将一个事物拆分成两维度变成4个象限，如重要紧急
归因回溯法
一种通过逐步排查和分析多个可能 的原因，来寻找事件真正的原因的方法，从事件发生后的结果入手，逆序推断，最终找到真正的原因。
eg: 一个视频客户端，播放稳定性数据突然发生了30%的下降，如何用找到问题
- 是不是系统的原因->是不是网络的问题->是不是手机品牌的原因->是不是App版本问题
5W2H法
- What、Who、Where、When、Why、How、How Much
- 在的时候，用这个方法来明确需求痛点
- 用于自问自答的方式来 发觉问题深层次的原因
eg:这是什么产品->什么时候上线->在什么地方使用->为什么需要做它->主要用户是谁->怎么来实现->需要花费啥
如何判断问题理清楚了
- 还有没有懵逼的地方吗？
- 还有没有没有考虑到到的点？
- 你已经完全没有问题困恼了
- 无论别个怎么argue，我基本上可以答得上来
如何讲明白问题
如何让其他人也很清楚这个事情
如何写一个很明白的文档
判断如何写明白了：别人看着你的文档，也就可以开始写代码了
- 组织结构有逻辑感，标题和副标题、段落分组，脑图先行
- 简单接地气的表达，清晰易理解的描述，看得懂，讲逻辑
- 很恰当的例子，实际或者模拟的案例、Demo的案例、流程图
可以去查一下RFC
Request for Comments，一种指导制定互联网标准的文档格式
- 明确是谁来读，文章目的，并确定其适用的范围
- 描述问题的背景和相关的已有解决方案
- 对解决方案详细阐述，有清晰的逻辑推理和可实现的细节
- 未解决的问题以及未来可能性的说明
写文档的反例思考
- 为了万无一失，是否需要对不同的人写不同的文档？
- 是否为了显示我的牛逼，将简单逻辑写得很复杂？
- 为了显示我很有“味道”，出现大量赋能、抓手、麻将大图
- 由于TL催我交作业，想不出来只能编，其实我自己都觉得不靠谱
讲明白事情常用模型- STAR
- Situation：遇到的具体情景
- Task：需要解决的问题或任务
- Action：采取的**行动和实施的过程
- Result：采取行动的结果
eg: 我们打算如何解决XXX的性能体验问题？
我讲事情的时候很容易紧张？
- 首先明确任何人讲东西都会紧张，只不过他熟练了而已
- 你感觉到的普通紧张，其实别人看不出来
- 假如你准备好了，你会很自信，让你没有那么紧张
eg: 如何让合作方买账- SCQA
- Situation：由大家都熟悉的情景事实引入
- Complication：实际情况往往和我们的要求有冲突
- Question：出现问题怎么办
- Answer：回答我们的解决方案是什么
一句你可能记得住一辈子的广告语，“得了灰指甲，一个传染俩，问我怎么办，马上用亮甲”
没有讲明白的情况
- 听的人自己在做自己的事情，甚至有一点想睡觉
- 听的人没有任何和你讨论的点，一问就是好好好
- **听的人一脑袋的问号？？不断argue
- 我”高度太高了，你们听不懂是你们能力不够
如何去明白的做
Last but not least
如何证明自己做好了呢？
- 制定验收标准，完成后进行验证
