“以终为始”（Begin With The End In Mind），是史蒂芬·柯维在《高效能人士的七个习惯》中提到的一个习惯。它是以所有事物都经过两次创造的原则（第一次为心智上的创造，第二次为实际的创造）为基础的。直观的表达就是：先想清楚目标，然后努力实现。在工作中，很多RD往往只是埋头走路，很少抬头看天。每次季度总结的时候，罗列了很多项目，付出很多努力。但是具体这些项目取得了哪些收益，对业务有哪些提升，却很难说出来。这就说明在工作中并没有遵守“以终为始”这一原则。此外，很多同学在做需求的过程中，对于目标与收益关注不够，系统上线之后，也没有持续地跟进使用效果。这一点在技术优化项目中体现的尤为明显。例如在一个接口性能优化的项目中，经过RD的努力优化，系统TP99缩短了60%，支持QPS提升了2倍。但是系统到底需要优化到什么程度呢？是不是缩短60%，提升2倍就能满足需求呢？在优化之前，很多同学常常忘记设置一个预设的目标（TP99小于多少，支持QPS大于多少）。我们必须清楚，优化一定是有原因的，比如预期某节假日流量会暴增或者某接口超时比例过高，如果不进行优化，系统可能会存在宕机风险。解决特定的问题才是技术优化的最终目的，所以要根据问题设定目标，再进行优化。“以终为始”，这一原则还可以作用于我们的学习中。很多同学看过很多技术文章，但是总是感觉自己依然一无所知。很重要的一个原因，就是没有带着目标去学习。在这个信息爆炸的时代，如果只是碎片化地接收各个公众号推送的文章，效果几乎可以忽略不计。在学习之前，我们一定要问自己，这次学习的目标是什么？是想把Redis的持久化原理搞清楚，还是把Redis的主从同步机制弄明白，亦或是想学习整个Redis Cluster的架构体系。如果我们能够带着问题与目标，再进行相关的资料搜集与学习，就会事半功倍。这种学习模式的效果会比碎片化阅读好很多。
“事不过二”，是我们团队一贯坚持的原则，它可以解读为两层含义。一层含义是“所有的评审与问题讨论，不要超过两次”。之所以有这样的要求，是因为我们发现，很多RD都把时间花费在一些无休止的评审与问题讨论中，真正投入到实际开发中的时间反而很少。在实际工作场景中，我们经常会遇到一些不是很成熟的需求评审。这些需求文档，要么是背景与目标含糊不清，要么是产品方案描述不够细化，或者存在歧义。RD与PM被迫反复进行讨论，我曾经遇到过一个需求评审，进行了三次还被打回。同样的问题，在设计评审中也屡见不鲜。方案固然需要经过反复的讨论，但是如果迟迟不能达成一致，就会耗费很多RD与PM的宝贵时间，这就与提升研发效率的理念背道而驰。因此我们团队规定：所有的评审最多两次。通过这种方式，倒逼利益相关方尽可能地做好需求与方案设计。评审会议组织前，尝试与所有相关人员达成一致，询问对方的意见，并进行有针对性的讨论，这样能够大大提升评审会议的效率和质量。如果在第一次评审中不通过，那么就只有一次机会进行复审。一旦两次不通过，就需要进行Casestudy。“事不过二”原则的另一层含义，是“同样的错误不能犯第二次”。每次故障之后，Casestudy都必须进行深刻的总结复盘，对故障原因进行5Why分析，给出明确可执行的To Do List。每次季度总结会，大家自我反省问题所在，在下个季度必须有所改善，不能再犯类似的错误。孔子云：“不迁怒，不贰过”，在错误中反思与成长，才能让我们成为更优秀的人。
