copy from: https://www.zybuluo.com/TryLoveCatch/note/1809593
研发工程师的基本功
- 需求的交付能力；
- 系统的设计与架构能力；
- 行业对标与演化改进能力；
想要系统化的提升基本功，首先要全面的对我们所接触到的技术要素做分解，站在全局进行思考。
规划
- 为什么要做？
以客户为中心，从业务角度出发，业务最关心什么，我们不做会不会影响业务的核心指标 - 为什么现在做？
时间上 dead line - 为什么是我们做？
- 怎么做
拆解
一个规划应该主要分为：
- 背景
业务理解，内部现状、业务影响、外部变化、背景总结 - 目标
根据背景要能推出来目标，也可分短期和长期目标，或者业务目标和技术目标，或者定性目标和定量目标 - 方案
方案是要解决背景中遇到的问题 - 指标
如果衡量结果的好坏呢 - 规划
具体的方案拆解，子任务拆解，具体到人和时间，每一个子任务应该是里程碑 - 风险以及应对
技术风险、资源风险、质量风险等或者业务维度（抓重点解决核心问题）、技术维度（难度）、组织维度（资源不足）、流程维度
技术要素拆分法（BeafQPS）
组成
- 行业对标 Benchmark
- 效率 Efficiency
- 架构 Architecture
- 功能 Feature
- 质量 Quality
- 性能 Performance
- 安全 Security
分解
联系
设置技术维度指标上，发现各维度存在内在的关联关系：
- 成功的交付 = 行业对标是否充分 ？（（功能 + 质量 + 安全 + 性能）*（效率））^ 架构 ：0
- 行业对标：找国内甚至世界上最先进的公司进行对标，充分了解自身的优势和劣势，进行有效决策，否则盲目执行，无法有效评价我们工作的价值。
- 功能 + 质量 + 安全 + 性能 ：这个组合各维度缺一不可，否则将会出现：线上故障、安全漏洞、访问慢等伤害客户、伤害业务的问题
- 效率：特指研发效率，在业务和团队发展初期是非核心考虑的要素，可以粗放式发展。但是在业务和团队步入成熟期后，需要重点关注投入产出比，尤其是成本增速和业务增速的关系。
- 架构：好的架构是承载一切的基础，其优劣对以上 5 个维度是乘方的关系，有前瞻性的合理架构可以助力业务更快迭代、研发质量更好、系统更安全、性能更快、研发效率更高。
具体场景
| 分类 | 场景 | 作用 |
|---|---|---|
| 方案类 | 技术调研 | 1、多角度全面对标 2、统一优劣对比维度 3、比对后标准可度量 |
| 方案类 | 技术方案设计 | 1、提供启发式的思维框架 2、避免遗漏潜在的技术风险 3、提供进阶式的参考标准 |
| CheckList | 发布前 CheckList | 1、避免人为误操作导致线上问题 2、前置依赖任务检查 3、消除因经验不足造成的认知局限 |
| 复盘类 | CaseStudy | 1、清晰的表述发生了什么问题 2、有效的分析原因和过程 3、从技术角度来思考如何改进 |
研发交付标准
了解到了如何拆解技术基础维度，就涉及落地执行的问题。落地必定有交付物。根据交付物的标准，我们制定出高、中、低三条基线。
总体思路是：坚守底线、控制中线、拔高上线。
- 底线：守住基本交付要求（功能 + 质量 + 安全 + 性能 ），无硬伤、无疏漏；
- 中线：提质提效、从可用到好用、易用。架构设计上领先于业务发展。
- 上线：充分的行业对标，以全球领先的技术标准要求和实践。
WHWHORERE 工作法
- why：为什么做？现在有什么严重的问题亟待解决？
- what：我们要解决的是什么问题？这件事情我们要做成什么样子？理想的情况是什么？要有理想，要高标准。
- object: 要干到什么程度定什么样的目标？能定量的尽量定量，不能定量的先定性，逐步做到“定性 → 粗定量 → 细定量”。
- roadmap：里程碑如何设置？做事的计划是什么？优先级是什么？
- Evaluate：怎么评估做得好还是没做好？定义合理的指标比实现该指标更难。结果导向。
- resource：需要多少资源？需要什么类型资源？人力资源，激励支持，权利支持等等有的话都提出来。
WHWHORERE 对于研发线同学来说有些陌生，但是 2W1H 、PDCA 你一定听说过、甚至经常使用。
- 2W1H 由：Why、What、How 三问结构构成，其中 Why 说明背景和目的、What 来提出方法和解决方案、How 部分解决怎么“干”的问题，Why、What 类比 WHWHORERE 中的 why、what 是相同的。
- PDCA 由：Plan 计划、Do 实施、Check 检核、Action 改进计划， 四部分构成，用来保障“干”的效果。
- 对应到 WHWHORERE，Plan 可类比 object、Do 可类比 roadmap、Check 可类比 Evaluate 。 Action、resource 是各自方法论中独特的部分。
通过类比两种大家比较熟悉的方法论，大家对 WHWHORERE 的理解会不会变得更容易些？
工作价值判断二维表法
结合 BeafQPS 和 WHWHORERE 的要求，我们在接到一个任务、项目、进行复盘、CaseStudy、Review 时，就可以拉出一个表格，运用正交分解的方式，从每一个技术维度和工作要点进行自问自答。
如果每一个问题，都能够有思考、有答案，才说明在这件事情上，我们把基本功做到位了。反之，则需要继续完善和补充。
综合运用
Tips：行业对标贯穿于工作的全周期，包括：前期的调研、优劣比对，中期的验证、找差距，后期的效果复盘和总结。
表格中，给到大家一些范例式的思考点和问题，我们需要结合具体的应用场景（可参考：下文第五部分），进行不同的思考与提问，来解决具体的问题。
二维表法的核心在于：纵向不重不漏的分析每一个技术维度，横向对于问题的思考能够逐级深入展开，横纵交叉后能够完整、可信和系统性给出结论。
具体场景
| 分类 | 场景 | 作用 |
|---|---|---|
| 述职类 | 晋升述职 | 1、充分展现工作亮点 2、拆解能力模型为具体可评估的技术维度 3、结构化的组织汇报素材 |
| 复盘类 | 项目复盘 | 1、全面分析项目投入产出比 2、回溯实施后的结果是否符合设计时的目标 3、交付标准可横向对比 |
| 规划类 | 技术规划 | 1、清楚说明要解决问题的价值和评估手段 2、不重不漏的覆盖潜在的技术风险； 3、可分阶段落地的里程碑和资源评估； |
| 其他 | … |
团队文化
第一原则
Owner 意识：
认真负责是工作的底线。对交付结果负责，对自己负责的项目负责。
积极主动是“Owner 意识”更高一级的要求：对更多，更高，更大结果负责。
第二原则
时间观念：
工作有计划：计划越细致，交付越有保证。按时交付是可靠的保障。
事情分主次：按照四象限原则划分事情轻重缓急。
第三原则
以终为始：先确定目标，然后再行动。
既要埋头做事，又要抬头看天。
根据目标进行优化。
带着目标进行学习。
事情按照 PDAC(Plan Do Check Act)进行。
第四原则
闭环思维：
凡事有交代，件件有着落，事事有回音。（往往也可以用来回答靠谱的人具备什么特征）
即时反馈闭环：如果别人给我们分配了一个任务，不管完成的结果如何，一定要在规定的时间内给出明确的反馈。
沟通要有结论，通知要有反馈，To Do 要有验收。
定期主动进行阶段性的反馈。
第五原则
保持敬畏：
对组内规范，既定约定的敬畏。
让规范与约定与时俱进，也是另一种形式的敬畏。
对用户体验和线上服务的敬畏。
第六原则
事不过二：
所有评审和问题讨论，不超过 2 次。
同样问题不犯第二次。
第七原则
设计优先：
1.架构设计关于系统质量和团队效能。
- 写别人看得懂的设计
第八原则
P/PC 平衡：产量、产能平衡。重视蛋也重视鹅。
业务产出和技术优化并重。
贡献和持续学习并重。
第九原则
善于提问：
勤于提问。
懂得如何提问。
批判性思维。
第十原则
空杯心态：
经常自我检视和反省。
多角度，批判看待自己