研发工作方法论

copy from: https://www.zybuluo.com/TryLoveCatch/note/1809593

研发工程师的基本功

  1. 需求的交付能力;
  2. 系统的设计与架构能力;
  3. 行业对标与演化改进能力;

想要系统化的提升基本功,首先要全面的对我们所接触到的技术要素做分解,站在全局进行思考。

规划

  • 为什么要做?
    以客户为中心,从业务角度出发,业务最关心什么,我们不做会不会影响业务的核心指标
  • 为什么现在做?
    时间上 dead line
  • 为什么是我们做?
  • 怎么做
    拆解

一个规划应该主要分为:

  • 背景
    业务理解,内部现状、业务影响、外部变化、背景总结
  • 目标
    根据背景要能推出来目标,也可分短期和长期目标,或者业务目标和技术目标,或者定性目标和定量目标
  • 方案
    方案是要解决背景中遇到的问题
  • 指标
    如果衡量结果的好坏呢
  • 规划
    具体的方案拆解,子任务拆解,具体到人和时间,每一个子任务应该是里程碑
  • 风险以及应对
    技术风险、资源风险、质量风险等或者业务维度(抓重点解决核心问题)、技术维度(难度)、组织维度(资源不足)、流程维度

技术要素拆分法(BeafQPS)

组成

  1. 行业对标 Benchmark
  2. 效率 Efficiency
  3. 架构 Architecture
  4. 功能 Feature
  5. 质量 Quality
  6. 性能 Performance
  7. 安全 Security

分解

联系

设置技术维度指标上,发现各维度存在内在的关联关系:

  • 成功的交付 = 行业对标是否充分 ?((功能 + 质量 + 安全 + 性能)*(效率))^ 架构 :0
  • 行业对标:找国内甚至世界上最先进的公司进行对标,充分了解自身的优势和劣势,进行有效决策,否则盲目执行,无法有效评价我们工作的价值。
  • 功能 + 质量 + 安全 + 性能 :这个组合各维度缺一不可,否则将会出现:线上故障、安全漏洞、访问慢等伤害客户、伤害业务的问题
  • 效率:特指研发效率,在业务和团队发展初期是非核心考虑的要素,可以粗放式发展。但是在业务和团队步入成熟期后,需要重点关注投入产出比,尤其是成本增速和业务增速的关系。
  • 架构:好的架构是承载一切的基础,其优劣对以上 5 个维度是乘方的关系,有前瞻性的合理架构可以助力业务更快迭代、研发质量更好、系统更安全、性能更快、研发效率更高。

具体场景

分类 场景 作用
方案类 技术调研 1、多角度全面对标
2、统一优劣对比维度
3、比对后标准可度量
方案类 技术方案设计 1、提供启发式的思维框架
2、避免遗漏潜在的技术风险
3、提供进阶式的参考标准
CheckList 发布前 CheckList 1、避免人为误操作导致线上问题
2、前置依赖任务检查
3、消除因经验不足造成的认知局限
复盘类 CaseStudy 1、清晰的表述发生了什么问题
2、有效的分析原因和过程
3、从技术角度来思考如何改进

研发交付标准

了解到了如何拆解技术基础维度,就涉及落地执行的问题。落地必定有交付物。根据交付物的标准,我们制定出高、中、低三条基线。

总体思路是:坚守底线、控制中线、拔高上线。

  • 底线:守住基本交付要求(功能 + 质量 + 安全 + 性能 ),无硬伤、无疏漏;
  • 中线:提质提效、从可用到好用、易用。架构设计上领先于业务发展。
  • 上线:充分的行业对标,以全球领先的技术标准要求和实践。

WHWHORERE 工作法

  1. why:为什么做?现在有什么严重的问题亟待解决?
  2. what:我们要解决的是什么问题?这件事情我们要做成什么样子?理想的情况是什么?要有理想,要高标准。
  3. object: 要干到什么程度定什么样的目标?能定量的尽量定量,不能定量的先定性,逐步做到“定性 → 粗定量 → 细定量”。
  4. roadmap:里程碑如何设置?做事的计划是什么?优先级是什么?
  5. Evaluate:怎么评估做得好还是没做好?定义合理的指标比实现该指标更难。结果导向。
  6. 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.架构设计关于系统质量和团队效能。

  1. 写别人看得懂的设计

第八原则

P/PC 平衡:产量、产能平衡。重视蛋也重视鹅。

业务产出和技术优化并重。

贡献和持续学习并重。

第九原则

善于提问:

勤于提问。

懂得如何提问。

批判性思维。

第十原则

空杯心态:

经常自我检视和反省。

多角度,批判看待自己

Author: weibingo
Link: https://wbice.cn/article/研发工作方法论.html
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.