写给工程师的 10 条精进原则

原创 小万酱 随笔 JAVA 109阅读 18 天前 举报

原则一 Owner意识
主要表现
一是认真负责的态度
二是积极主动的精神
认真负责是工作的底线
首先,要对我们交付的结果负责
项目中每一个设计文档、每一行代码都需要认真完成,要对它的质量负责
如果设计文档逻辑混乱,代码没有注释,测试时发现一堆Bug,影响的不仅仅是RD的工程交付质量,还会对协同工作的RD、QA、PM等产生不好的影响
久而久之,团队的整体交付质量、工作效率也会逐步下降,甚至会导致团队成员之间产生不信任感
其次,我们要对开发的系统负责
系统的架构是否需要改进,接口文档是否完善
日志是否完整,数据库是否需要扩容,缓存空间够不够等等
积极主动是“Owner意识”更高一级的要求
RD每天要面对大量的工作,而且很多并不在计划内,这就需要具备一种积极主动的精神
积极主动地推动问题的解决,如果时间无法排开或者不知道如何解决,可以直接将问题反馈给能解决的同学
积极主动还可以表现在更多方面
很多同学会自发地梳理负责服务的现状,根据接口在性能方面暴露的问题提出改进意见并持续推动解决;
也有同学在跨团队沟通中主动承担起主R的角色,积极发现问题、暴露问题,推动合作团队的进度,保证项目顺利推进
我们在做好自己份内工作的同时,也应该积极主动地投入到“份外”的工作中去
原则二 时间观念
主要表现
做事有计划
工作分主次
工作安排要有计划性
凡事预则立,不预则废。
RD在设计评审之后就能预估出精确的开发时间,进而再合理地安排开发、联调、测试计划
如果是项目负责人,那么就会涉及协调FE、QA、PM等多个工种的同学共同完成工作
在计划制定过程中,要尽可能把每一项拆细一点(至少到pd粒度)
事实证明,粒度越细,计划就越精准,实际开发时间与计划之间的误差就会越小
务必要规定明确的可检查的产出,并在计划中设置一些关键的时间点进行核对
我们要做到计划粒度足够细,关键时间点要可检查
工作安排要分清楚主次
可以尝试使用“艾森豪威尔法则”(四象限法则),把工作按照重要、紧急程度分成四象限
优先做重要紧急的事情
重要不紧急的事情可以暂缓做,但是要持续推进
紧急不重要的事情可以酌情委托给最合适的人做
不重要不紧急的事情可以考虑不做
实际工作中,我们应当避免这种“本末倒置”的工作方式
原则三 以终为始
“以终为始”(Begin With The End In Mind),是史蒂芬·柯维在《高效能人士的七个习惯》中提到的一个习惯。它是以所有事物都经过两次创造的原则(第一次为心智上的创造,第二次为实际的创造)为基础的。
直观的表达就是:先想清楚目标,然后努力实现
解决特定的问题才是技术优化的最终目的,所以要根据问题设定目标,再进行优化
带着问题与目标,再进行相关的资料搜集与学习,就会事半功倍
原则四 闭环思维
一个人是否靠谱,就看他能否做到凡事有交代,件件有着落,事事有回音。这就是闭环思维的重要性
强调的是一种即时反馈闭环,如果别人给我们分配了一个任务,不管完成的结果如何,一定要在规定的时间内给出明确的反馈
真正的闭环,要求我们对工作中的事情都能够养成良好的思维习惯,沟通有结论,通知有反馈,To Do有验收
“闭环思维”还要求能够定期主动进行阶段性的反馈
原则五 保持敬畏
当我们进入到一个新的团队,请先暂时忘掉之前的习惯,要尽快学习团队既有的规范,并且让自己与团队保持一致
如果有事情拿不准,不妨多问问其他同事,不要凭自己的感觉做事情
让规范与约定与时俱进,也是另一种形式的敬畏
原则六 事不过二
所有的评审与问题讨论,不要超过两次
背景
很多RD都把时间花费在一些无休止的评审与问题讨论中,真正投入到实际开发中的时间反而很少
在实际工作场景中,我们经常会遇到一些不是很成熟的需求评审
这些需求文档,要么是背景与目标含糊不清,要么是产品方案描述不够细化,或者存在歧义
方案固然需要经过反复的讨论,但是如果迟迟不能达成一致,就会耗费很多RD与PM的宝贵时间
所有的评审最多两次
通过这种方式,倒逼利益相关方尽可能地做好需求与方案设计
评审会议组织前,尝试与所有相关人员达成一致,询问对方的意见,并进行有针对性的讨论,这样能够大大提升评审会议的效率和质量
如果在第一次评审中不通过,那么就只有一次机会进行复审
一旦两次不通过,就需要进行Casestudy
同样的错误不能犯第二次
每次故障之后,Casestudy都必须进行深刻的总结复盘,对故障原因进行5Why分析,给出明确可执行的To Do List
每次季度总结会,大家自我反省问题所在,在下个季度必须有所改善,不能再犯类似的错误
孔子云:“不迁怒,不贰过”,在错误中反思与成长,才能让我们成为更优秀的人
原则七 设计优先
Uncle Bob曾说过:“软件架构的目标,是为了让构建与维护系统的所需人力资源最小化。”
架构设计,并不仅仅关系到系统的质量,还关乎团队的效能问题
很多团队也有明文规定,开发周期在3pd以上的项目必须有设计文档,开发周期在5pd以上的项目必须有设计评审
无数事实证明,忽略了前期设计,往往会导致后续开发周期被大幅拉长,给项目带来了很大的Delay风险
最可怕的是,不当的设计会给项目带来巨大的后期维护成本,我们不得不腾出时间,专门进行项目的优化与重构
要求写别人看得懂的设计
设计的过程是一种智力上的创造,我们更希望它能成为个人与集体智慧的结晶
设计应该尽量使用比较合理的逻辑,进而把设计中的一些点组织起来
比如可以使用从抽象到具体,由总到分的结构来组织材料。
在设计过程中,要以需求为出发点,通过合理的抽象把问题简化,讲清楚各个模块之间的关系,再详细分述模块的实现细节
做完设计之后,可以发给比较资深的RD或者PM审阅一下,根据他们的反馈再进行完善
好的设计,一定是逻辑清晰易懂、细节落地可执行的
原则八 P/PC平衡
“P/PC平衡”原则,即产出与产能平衡原则
产出与产能必须平衡,才能达到真正的高效能
从系统的角度看
每一个系统都是通过持续不断地叠加功能,来实现其产出,而系统的产能是通过系统架构的可扩展性、稳定性等一系列特性来表征
为了达到产出与产能的平衡,需要在不断支持业务需求的过程中,持续进行技术架构层面的优化
如果一味地做业务需求,经过一定的时间,系统会越来越慢,最终影响业务的稳定性;反之,一个没有任何业务产出的系统,最终会消亡
从RD的角度看
RD通过做需求来给公司创造价值,实现自己的产出
RD的产能是指技术能力、软素质、身体健康状况,有这些资本后,我们才能进行持续的产出
在日常工作中,发现很多RD往往只重视产出,他们也在很努力地做项目,但是每一个项目所使用的方法,还是沿用自己先前一贯的思路
如果能在做项目的过程中,通过学习和总结持续提升自己的技术能力和软素质,并将其应用于项目实施交付中,相信一定会取得双赢的结果
原则九 善于提问
“善于提问”,首先要勤于提问
求知欲源于好奇心,是人类的一种本能
在工作中要养成勤于提问的好习惯,不懂就问,不要因为自己一时懒惰或者碍于情面,就放弃提问的机会
当遇到不同的观点时,也要礼貌地问出来
波克定理告诉我们,只有在争辩中,才可能诞生最好的主意和最好的决定
设计评审的目的,是让大家针对方案提出改进意见并达成一致,如果全程“打酱油”,那就失去了评审的意义
“善于提问”,还要懂得如何提问
批判性思维主张通过批判性思考达到理性思维,即对事物本质的认知和掌握
必须要学会使用批判性思维来进行分析,每个人的论据是否可靠,论证是否合理,是否有隐含的立场
原则十 空杯心态
保持“空杯心态”这一原则要求我们时刻进行自我检视与反省
在工作中,多去跟不同级别的同学聊一聊,或者做一个360度评估,这有助于我们更加客观地评价自己
在横向对比中,多向那些优秀的同学看齐,学习他人的优点
很多同学在设计评审或者代码Review过程中,针对别人提出的问题与建议,往往都采用一种对立的态度,错误地认为别人是在挑刺,是在针对自己
在某些方面,我们可能确实比其他人想得深入,但是这不代表在所有方面都能考虑周全
对于别人的建议,建议使用“善于提问”原则里提到的批判性思维仔细分析一下,虚心地吸取那些好的建议
保持空杯心态,可以让我们发现很多以前注意不到的新能力,我们要做的就是努力学习它,将它们转化为自己能力库的一部分
版权和编辑
本文内容来自公众号“美团技术团队”,本人整理仅作学习之用
编辑作者
昵称
小万酱
v:wanmen246

评论 ( 0 )
最新评论
暂无评论

赶紧努力消灭 0 回复