@TryLoveCatch
2023-03-08T14:01:12.000000Z
字数 2964
阅读 1743
方法论
一个规划应该主要分为:
设置技术维度指标上,发现各维度存在内在的关联关系:
分类 | 场景 | 作用 |
---|---|---|
方案类 | 技术调研 | 1、多角度全面对标 2、统一优劣对比维度 3、比对后标准可度量 |
技术方案设计 | 1、提供启发式的思维框架 2、避免遗漏潜在的技术风险 3、提供进阶式的参考标准 |
|
CheckList | 发布前 CheckList | 1、避免人为误操作导致线上问题 2、前置依赖任务检查 3、消除因经验不足造成的认知局限 |
复盘类 | CaseStudy | 1、清晰的表述发生了什么问题 2、有效的分析原因和过程 3、从技术角度来思考如何改进 |
了解到了如何拆解技术基础维度,就涉及落地执行的问题。落地必定有交付物。根据交付物的标准,我们制定出高、中、低三条基线。
总体思路是:坚守底线、控制中线、拔高上线。
WHWHORERE 对于研发线同学来说有些陌生,但是 2W1H 、PDCA 你一定听说过、甚至经常使用。
通过类比两种大家比较熟悉的方法论,大家对WHWHORERE的理解会不会变得更容易些?
结合BeafQPS和WHWHORERE的要求,我们在接到一个任务、项目、进行复盘、CaseStudy、Review时,就可以拉出一个表格,运用正交分解的方式,从每一个技术维度和工作要点进行自问自答。
如果每一个问题,都能够有思考、有答案,才说明在这件事情上,我们把基本功做到位了。反之,则需要继续完善和补充。
Tips:行业对标贯穿于工作的全周期,包括:前期的调研、优劣比对,中期的验证、找差距,后期的效果复盘和总结。
表格中,给到大家一些范例式的思考点和问题,我们需要结合具体的应用场景(可参考:下文第五部分),进行不同的思考与提问,来解决具体的问题。
二维表法的核心在于:纵向不重不漏的分析每一个技术维度,横向对于问题的思考能够逐级深入展开,横纵交叉后能够完整、可信和系统性给出结论。
分类 | 场景 | 作用 |
---|---|---|
述职类 | 晋升述职 | 1、充分展现工作亮点 2、拆解能力模型为具体可评估的技术维度 3、结构化的组织汇报素材 |
复盘类 | 项目复盘 | 1、全面分析项目投入产出比 2、回溯实施后的结果是否符合设计时的目标 3、交付标准可横向对比 |
规划类 | 技术规划 | 1、清楚说明要解决问题的价值和评估手段 2、不重不漏的覆盖潜在的技术风险; 3、可分阶段落地的里程碑和资源评估; |
其他 | ... |
https://juejin.cn/post/7187713181769269285
5W2H是What、Who、Why、Where、When、How much、How首字母缩写之和,广泛用于企业技术管理、头脑风暴等。
Owner意识:
认真负责是工作的底线。对交付结果负责,对自己负责的项目负责。
积极主动是“Owner意识”更高一级的要求:对更多,更高,更大结果负责。
时间观念:
工作有计划:计划越细致,交付越有保证。按时交付是可靠的保障。
事情分主次:按照四象限原则划分事情轻重缓急。
以终为始:先确定目标,然后再行动。
既要埋头做事,又要抬头看天。
根据目标进行优化。
带着目标进行学习。
事情按照PDAC(Plan Do Check Act)进行。
第四原则
闭环思维:
凡事有交代,件件有着落,事事有回音。(往往也可以用来回答靠谱的人具备什么特征)
即时反馈闭环:如果别人给我们分配了一个任务,不管完成的结果如何,一定要在规定的时间内给出明确的反馈。
沟通要有结论,通知要有反馈,To Do要有验收。
定期主动进行阶段性的反馈。
第五原则
保持敬畏:
对组内规范,既定约定的敬畏。
让规范与约定与时俱进,也是另一种形式的敬畏。
对用户体验和线上服务的敬畏。
第六原则
事不过二:
所有评审和问题讨论,不超过2次。
同样问题不犯第二次。
设计优先:
1.架构设计关于系统质量和团队效能。
P/PC平衡:产量、产能平衡。重视蛋也重视鹅。
业务产出和技术优化并重。
贡献和持续学习并重。
善于提问:
勤于提问。
懂得如何提问。
批判性思维。
空杯心态:
经常自我检视和反省。
多角度,批判看待自己