|
通常，RD在设计评审之后就能预估出精确的开发时间，进而再合理地安排开发、联调、测试计划。如果是项目负责人，那么就会涉及协调FE、QA、PM等多个工种的同学共同完成工作。凡事预则立，不预则废。在计划制定过程中，要尽可能把每一项拆细一点（至少到pd粒度）。事实证明，粒度越细，计划就越精准，实际开发时间与计划之间的误差就会越小。 此外，务必要规定明确的可检查的产出，并在计划中设置一些关键的时间点进行核对。无数血淋淋的事实告诉我们，很多项目延期都是因为在一些关键交付点上双方存在分歧造成的。例如：后台RD的接口文档计划在周五提供，FE认为是周五上午，而RD认为是周五下班前提交，无形中会给排期带来了1pd的误差。所以，我们要做到计划粒度足够细，关键时间点要可检查。 （2）工作安排要分清楚主次 我们每天要面对很多的事情，要学会分辨这些工作的主次。可以尝试使用“艾森豪威尔法则”（四象限法则），把工作按照重要、紧急程度分成四象限。 优先做重要紧急的事情；重要不紧急的事情可以暂缓做，但是要持续推进；紧急不重要的事情可以酌情委托给最合适的人做；不重要不紧急的事情可以考虑不做。 很多项目无法按期交付的原因，都是因为执行人分不清主次。比如：在开发中需要使用到ES，一些不熟悉ES的同学可能想系统性地学习一下这方面的知识，就会一头扎进ES的汪洋中。最后才发现，原本一天就能完成的工作被严重拖后。 实际工作中，我们应当避免这种“本末倒置”的工作方式。在本例中，“系统性地学习ES”是一件重要但不紧急的事情。要学会分辨出这些干扰的工作项，保证重要紧急的事情能够按时交付。 原则三：以终为始“以终为始”（Begin With The End In Mind），是史蒂芬·柯维在《高效能人士的七个习惯》中提到的一个习惯，它是以所有事物都经过两次创造的原则（第一次为心智上的创造，第二次为实际的创造）为基础的。直观的表达就是：先想清楚目标，然后努力实现。 在工作中，很多RD往往只是埋头走路，很少抬头看天。每次季度总结的时候，罗列了很多项目，付出很多努力。但是具体这些项目取得了哪些收益，对业务有哪些提升，却很难说出来。这就说明在工作中并没有遵守“以终为始”这一原则。 此外，很多同学在做需求的过程中，对于目标与收益关注不够，系统上线之后，也没有持续地跟进使用效果。这一点在技术优化项目中体现的尤为明显。 例如：在一个接口性能优化的项目中，经过RD的努力优化，系统TP99缩短了60%，支持QPS提升了2倍。但是系统到底需要优化到什么程度呢？是不是缩短60%，提升2倍就能满足需求呢？ 在优化之前，很多同学常常忘记设置一个预设的目标（TP99小于多少，支持QPS大于多少）。我们必须清楚，优化一定是有原因的，比如预期某节假日流量会暴增或者某接口超时比例过高，如果不进行优化，系统可能会存在宕机风险。解决特定的问题才是技术优化的最终目的，所以要根据问题设定目标，再进行优化。 “以终为始”，这一原则还可以作用于我们的学习中。很多同学看过很多技术文章，但是总是感觉自己依然一无所知。很重要的一个原因，就是没有带着目标去学习。 在这个信息爆炸的时代，如果只是碎片化地接收各个公众号推送的文章，效果几乎可以忽略不计。在学习之前，我们一定要问自己，这次学习的目标是什么？ 是想把Redis的持久化原理搞清楚，还是把Redis的主从同步机制弄明白，亦或是想学习整个Redis Cluster的架构体系。如果我们能够带着问题与目标，再进行相关的资料搜集与学习，就会事半功倍。这种学习模式的效果会比碎片化阅读好很多。 原则四：闭环思维你是否遇到过这样的场景：参加了一个设 计（或需求）评审，大家兴致勃勃地提了很多合理的意见，等到再次评审的时候，却发现第一次提的很多问题都没有得到改进，很多讨论过的问题需要从头再开始讨论。这种情况就是一种典型的工作不闭环。 之前看过一句话： 一个人是否靠谱，就看他能否做到凡事有交代，件件有着落，事事有回音。 （责任编辑：晨鸿） |
