pd是什么意思 pd是什么意思( 二 )


原则二:时间观念相信大家都有时间观念 , 但是真正能执行到位的可能并没有那么多 。互联网是一个快速发展的行业 , RD的研发效率是一个公司硬实力的重要体现 。项目的按期交付是一项很重要的执行能力 , 在很大程度上决定着领导和同事对自己靠谱程度的评价 。大家可能会问:难度几乎相同的项目 , 为什么有的同学经常Delay , 而有的同学每次都能按时上线?一个很重要的原因 , 就是这些按时交付的同学往往具备如下两个特质:做事有计划 , 工作分主次 。

pd是什么意思 pd是什么意思

文章插图
工作安排要有计划性 。通常 , 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的架构体系 。如果我们能够带着问题与目标 , 再进行相关的资料搜集与学习 , 就会事半功倍 。这种学习模式的效果会比碎片化阅读好很多 。

秒懂生活扩展阅读