【转载】研发工作方法论

规划

• 为什么要做？
  以客户为中心，从业务角度出发，业务最关心什么，我们不做会不会影响业务的核心指标
• 为什么现在做？
  时间上 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次。
  同样问题不犯第二次。
• 第七原则
  设计优先：
  架构设计关于系统质量和团队效能。
  写别人看得懂的设计
• 第八原则
  P/PC平衡：产量、产能平衡。重视蛋也重视鹅。
  业务产出和技术优化并重。
  贡献和持续学习并重。
• 第九原则
  善于提问：
  勤于提问。
  懂得如何提问。
  批判性思维。
• 第十原则
  空杯心态：
  经常自我检视和反省。
  多角度，批判看待自己

[侵必删]原文链接：https://www.zybuluo.com/TryLoveCatch/note/1809593