相信大家都有时间观念，但是真正能执行到位的可能并没有那么多。互联网是一个快速发展的行业，RD 的研发效率是一个公司硬实力的重要体现。项目的按期交付是一项很重要的执行能力，在很大程度上决定着领导和同事对自己靠谱程度的评价。大家可能会问：难度几乎相同的项目，为什么有的同学经常Delay，而有的同学每次都能按时上线？一个很重要的原因，就是这些按时交付的同学往往具备如下两个特质：做事有计划，工作分主次。工作安排要有计划性。通常，RD 在设计评审之后就能预估出精确的开发时间，进而再合理地安排开发、联调、测试计划。如果是项目负责人，那么就会涉及协调 FE、QA、PM 等多个工种的同学共同完成工作。凡事预则立，不预则废。在计划制定过程中，要尽可能把每一项拆细一点（至少到 pd 粒度）。事实证明，粒度越细，计划就越精准，实际开发时间与计划之间的误差就会越小。此外，务必要规定明确的可检查的产出，并在计划中设置一些关键的时间点进行核对。无数血淋淋的事实告诉我们，很多项目延期都是因为在一些关键交付点上双方存在分歧造成的。例如后台 RD 的接口文档计划在周五提供，FE 认为是周五上午，而 RD 认为是周五下班前提交，无形中会给排期带来了 1pd 的误差。所以，我们要做到计划粒度足够细，关键时间点要可检查。工作安排要分清楚主次。我们每天要面对很多的事情，要学会分辨这些工作的主次。可以尝试使用“艾森豪威尔法则”（四象限法则），把工作按照重要、紧急程度分成四象限。优先做重要紧急的事情；重要不紧急的事情可以暂缓做，但是要持续推进；紧急不重要的事情可以酌情委托给最合适的人做；不重要不紧急的事情可以考虑不做。很多项目无法按期交付的原因，都是因为执行人分不清主次。比如在开发中需要使用到 ES，一些不熟悉 ES 的同学可能想系统性地学习一下这方面的知识，就会一头扎进 ES 的汪洋中。最后才发现，原本一天就能完成的工作被严重拖后。实际工作中，我们应当避免这种“本末倒置”的工作方式。在本例中，“系统性地学习 ES”是一件重要但不紧急的事情。要学会分辨出这些干扰的工作项，保证重要紧急的事情能够按时交付。
原则三：以终为始
“以终为始”（Begin With The End In Mind），是史蒂芬·柯维在《高效能人士的七个习惯》中提到的一个习惯。它是以所有事物都经过两次创造的原则（第一次为心智上的创造，第二次为实际的创造）为基础的。直观的表达就是：先想清楚目标，然后努力实现。在工作中，很多 RD 往往只是埋头走路，很少抬头看天。每次季度总结的时候，罗列了很多项目，付出很多努力。但是具体这些项目取得了哪些收益，对业务有哪些提升，却很难说出来。这就说明在工作中并没有遵守“以终为始”这一原则。此外，很多同学在做需求的过程中，对于目标与收益关注不够，系统上线之后，也没有持续地跟进使用效果。这一点在技术优化项目中体现的尤为明显。例如在一个接口性能优化的项目中，经过RD的努力优化，系统TP99缩短了60%，支持QPS提升了2倍。但是系统到底需要优化到什么程度呢？是不是缩短60%，提升2倍就能满足需求呢？在优化之前，很多同学常常忘记设置一个预设的目标（TP99小于多少，支持QPS大于多少）。我们必须清楚，优化一定是有原因的，比如预期某节假日流量会暴增或者某接口超时比例过高，如果不进行优化，系统可能会存在宕机风险。解决特定的问题才是技术优化的最终目的，所以要根据问题设定目标，再进行优化。“以终为始”，这一原则还可以作用于我们的学习中。很多同学看过很多技术文章，但是总是感觉自己依然一无所知。很重要的一个原因，就是没有带着目标去学习。在这个信息爆炸的时代，如果只是碎片化地接收各个公众号推送的文章，效果几乎可以忽略不计。在学习之前，我们一定要问自己，这次学习的目标是什么？是想把 Redis 的持久化原理搞清楚，还是把 Redis 的主从同步机制弄明白，亦或是想学习整个 Redis Cluster 的架构体系。如果我们能够带着问题与目标，再进行相关的资料搜集与学习，就会事半功倍。这种学习模式的效果会比碎片化阅读好很多。
原则四：闭环思维
你是否遇到过这样的场景：参加了一个设计（或需求）评审，大家兴致勃勃地提了很多合理的意见，等到再次评审的时候，却发现第一次提的很多问题都没有得到改进，很多讨论过的问题需要从头再开始讨论。这种情况就是一种典型的工作不闭环。之前看过一句话：一个人是否靠谱，就看他能否做到凡事有交代，件件有着落，事事有回音。这就是闭环思维的重要性。它强调的是一种即时反馈闭环，如果别人给我们分配了一个任务，不管完成的结果如何，一定要在规定的时间内给出明确的反馈。例如在跨部门的沟通会议中，虽然各方达成了一致，会议发起者已经将最终的记录周知大家。但是，到这一步其实并没有完成真正的闭环，在落地执行过程中很可能还存在一些潜在的问题。例如，会议纪要是否经各方仔细核对并确认过？会议中明确的 To Do 进展是什么？完成结果有没有 Check 的机制？如果这些没有做到的话，就会陷入“沟通-发现问题-再沟通-再发现问题”的恶性循环中。真正的闭环，要求我们对工作中的事情都能够养成良好的思维习惯，沟通要有结论，通知要有反馈，To Do 要有验收。“闭环思维”还要求能够定期主动进行阶段性的反馈。刚参加工作时，我接了一个工期为两个月的项目。整个项目需要独自完成，自己每天按照计划，有条不紊地进行开发。大概过了两周之后，Leader 询问项目进度，虽然我已经跟他说没问题。然而，Leader 告诉我，因为我每天对着电脑也不说话，让他心里很没底。这时，我才意识到一个很重要的问题，我跟 Leader 之间存在信息不对称。从那以后，我就时不时得跟他汇报一下进度，哪怕就只有简短的一句话，也可以明显感觉，他对我的信心增加了很多。特别是我做 Leader 之后，对这种闭环反馈的理解，就更加深刻了。从 Leader 的角度看，其实只是想知道项目是否在正常推进，是否遇到问题需要他协助解决。
原则五：保持敬畏
“君子之心，常怀敬畏”，保持敬畏之心能够让我们少犯错误。在工作中存在各种各样的规范，例如代码规范、设计规范、上线规范等等。我们必须明白，这些规范的制定一定是基于某些客观原因的，它们都是历史上无数 Case 积累而来的经验。团队里的每一个成员都应该学习并严格遵守，这一点对于新人尤其重要。当我们进入到一个新的团队，请先暂时忘掉之前的习惯，要尽快学习团队既有的规范，并且让自己与团队保持一致。以编码风格为例，很多同学往往习惯于自己之前的代码写作风格，在做新公司第一个项目时，也按照自己的习惯进行变量、包的命名等等。结果在代码 Review 过程中，被提了很多修改意见，不得不返工重写，得不偿失。如果能够保持敬畏之心，提前了解编码规范，这种问题完全可以避免。类似的问题，还包括对上线流程的不了解，对回滚操作不熟悉，对 SRE 线上变更过程不了解等等。除了这些显而易见的规范，还有一些约定俗成的规则。个人建议是：如果有事情拿不准，不妨多问问其他同事，不要凭自己的感觉做事情。保持敬畏之心并不意味着要“因循守旧”。在我们充分了解这些规范和约定之后，如果觉得存在不妥之处，可以跟全组同学讨论，是否采纳新的建议，然后及时去更新迭代。其实，让规范与约定与时俱进，也是另一种形式的敬畏。
原则六：事不过二
“事不过二”，是我们团队一贯坚持的原则，它可以解读为两层含义。一层含义是“所有的评审与问题讨论，不要超过两次”。之所以有这样的要求，是因为我们发现，很多 RD 都把时间花费在一些无休止的评审与问题讨论中，真正投入到实际开发中的时间反而很少。在实际工作场景中，我们经常会遇到一些不是很成熟的需求评审。这些需求文档，要么是背景与目标含糊不清，要么是产品方案描述不够细化，或者存在歧义。RD与PM被迫反复进行讨论，我曾经遇到过一个需求评审，进行了三次还被打回。同样的问题，在设计评审中也屡见不鲜。方案固然需要经过反复的讨论，但是如果迟迟不能达成一致，就会耗费很多RD与PM的宝贵时间，这就与提升研发效率的理念背道而驰。因此我们团队规定：所有的评审最多两次。通过这种方式，倒逼利益相关方尽可能地做好需求与方案设计。评审会议组织前，尝试与所有相关人员达成一致，询问对方的意见，并进行有针对性的讨论，这样能够大大提升评审会议的效率和质量。如果在第一次评审中不通过，那么就只有一次机会进行复审。一旦两次不通过，就需要进行 Case Study。“事不过二”原则的另一层含义，是“同样的错误不能犯第二次”。每次故障之后，Case Study 都必须进行深刻的总结复盘，对故障原因进行 5 Why 分析，给出明确可执行的 To Do List。每次季度总结会，大家自我反省问题所在，在下个季度必须有所改善，不能再犯类似的错误。孔子云：“不迁怒，不贰过”，在错误中反思与成长，才能让我们成为更优秀的人。
