建设网站是不是必须要服务器,wordpress新建菜单,物流网站后台,网站成功案例大家好#xff0c;我是Z哥。我坦白#xff0c;这篇是早就写好的库存文章#xff0c;包括上周的那篇也是。原因是最近跳槽了#xff0c;到新公司忙得飞起#xff0c;都没时间写文章。还好我之前未雨绸缪准备了几篇提前写好的文章作为余量#xff5e;我尽量能保持不断更我是Z哥。我坦白这篇是早就写好的库存文章包括上周的那篇也是。原因是最近跳槽了到新公司忙得飞起都没时间写文章。还好我之前未雨绸缪准备了几篇提前写好的文章作为余量我尽量能保持不断更如果实在顶不住就周五的时候给大家请假哈。好了回到这次聊的正题。研发考核难是整个软件开发领域众所周知的问题甚至可以说是跨世纪的难题了上个世纪开始至今未被有效解决。近期我对这个问题有了一些新的思考在这里和大家分享交流一下。很多人觉得因为研发考核很难考所以索性就不考了。这个就有点因噎废食了。首先我们要搞清楚考核存在的意义是什么我的理解是为了达成团队的共同目标。为了更好的管理团队、驱动团队力往一处使。但是管理大师德鲁克又说过你如果无法度量它就无法管理它。德鲁克这句话既然能被各个时代的管理者所追捧存在了几十年自然有它的道理。所以不管我们是不是为了考核都得找到度量的方式方法。有些团队的确找到了不少度量指标但是大多偏向技术层面包括我们团队之前也是如此。这些指标一旦在具体实施之后往往发现效果甚至不如没有考核的时候。这个背后的原因也有很多文章提到过就是那些指标不适合考核。也有一些人经历了上面这个阶段后觉得研发的考核不好做不好量化。实则是因为找不到那种直击要害的关键指标。从这个问题的本质上来说大家之所以觉得研发考核难本质是由于研发工作的三个特点导致的。01 无法标准化这里的无法标准化并不只是难以度量而是说同样完成一个任务不同的人会有不同的做法最终的结果也可能会差别很大。比如同一个任务有的人做了 5 天有的人做了 10 天有的人喜欢花很多时间在前期的设计阶段有的人则会花更多时间在后期的自测上。但是你也不能说一定是谁的方式更好。02 工作透明度低实现同样一个功能如果有合理的代码封装可能只要 100 行代码。但是如果不花时间去构思封装那么可能是 500 行甚至是 1000 行。此时如果没有第三者进行 codereview 的话甚至可能会觉得写 1000 行代码的人产出更大。03 工作时间的碎片化不得不说大多数人的工作时间其实大部分时候很难完全由自己掌控一会有人找你问个事一会需要参加一个会一会又来个电话接一下。这些被动的意外之事都会使得做度量这件事变得困难甚至还会将原来的计划打乱导致某些考核指标出现失真。Z哥觉得研发考核指标怎么定这件事应该分为两个问题去看。能够度量的指标有哪些怎么考核这两个问题之间其实没有必然联系如果老想着一箭双雕一次解决两个问题就会陷入前面提到的困境中。我认为大部分的指标是用来作为帮助决策的信息源而用于考核的指标不一定要多要有业务价值。具体我来展开说说。/01 能够度量的指标有哪些/相信有不少指标已经马上在你的脑海中跳出来了代码行数工时bug 数……很多讲考核的文章都会对这些指标嗤之以鼻因为这些指标不适合用来考核这是针对流水线工作性质的考核产物。这点不否认。但是也不能否认这些简单的指标中也蕴含着有价值的信息。因此在我的理念里认为不应该主动放弃任何能被度量的指标。正如前面所说研发工作本身就具有无法标准化、工作透明度低、工作时间的碎片化的特点。我们好不容易找到一些指标能够帮助我们更清楚的认识我们的工作做得到底如何为什么不要呢不适合考核不等于我们可以忽略他们。这也是我认为要将这事分为「能够度量的指标有哪些」和「怎么考核」的原因。除了这些大家都知道的指标还有很多指标可以被度量。它们主要分为两个维度过程指标和结果指标。常见的过程指标有需求响应周期、发布前置时间、交付吞吐量、线上问题平均解决时长等结果指标有日均新增 bug 数日均 bug 库存数线上问题数量等。如果你所在的团队对工程效率比较重视相信还有不少指标可以被度量出来。这些指标有什么用呢我们需要每天观察他们的变化便于及时发现团队里正在发生的变化是否符合预期。比如最近并没有太多并行开发的版本为什么平均交付时间反而变长了是不是不够敏捷比如最近生产环境的 bug 数明显变多了是不是质量团队出了什么状况……/02 怎么考核/用上面列出的这些指标来考核吗自然不是。Z哥认为考核还是得从业务下手要想办法找到与技术有一定关系的业务指标比如DAU、用户平均停留时长等等。可能很多人第一眼会觉得说这些指标有很大比例是由业务决定的技术在其中起不了什么作用。其实并不然你想象一下。如果我们的拉新用户承接页的稳定性不好或者核心业务链路经常出错这对 DAU 和用户平均停留时长必然会造成不好的影响。所以业务指标真的与技术无关吗其实并不然。怎么落地为考核呢我的思路是建立在两个逻辑之上的业务指标的移动平均值在一段时间里是一条趋势向上或向下的曲线。平均范围越长曲线越平滑。技术在短期不能显著提高业务指标但可以降低业务指标。基于这两个逻辑在落地为考核的时候有两种方案。一种是长周期考核比如每半年或者每年一次的 OKR 考核。这种考核直接用指标在开始时和结束时的差值即可大多数的偶发性事件直接被平滑掉了。另一种是每个月都要进行的短期考核。这种考核建议使用环比变化作为依据。比如比上个月提升了就奖励降低了就惩罚这样从长期来看偶发性事件带来的影响也被平滑掉了。当然这里的奖励和惩罚不一定是物质形式的也可以是精神形式。可能有的人会觉得这样的考核如果在业务快速发展期不是躺赚吗是的没错只要技术能支撑快速发展的业务不拖业务的后腿我认为就应该奖励。至于是不是躺赚关键还是看选择的业务指标以及如何制定具体的奖惩尺度。今天就聊这么多吧。研发考核这事和研发工作一样没有「Sliver Bullet」我今天和大家聊的也只是我的一家之言欢迎大家一起探讨。本质上我们也是在讨论如何更好地向非技术人员展示我们技术人工作成果的好坏。好了总结一下。这篇呢Z哥和你分享了我对研发考核这件事的看法。首先我认为考核还是要考的不考核肯定不行。研发工作性质的三个特点导致考核指标很难定。无法标准化工作透明度低工作时间的碎片化所以我的建议是找指标管找指标考核管考核两件事分开看。我们要尽可能多的收集研发过程和衡量结果的指标它们不一定用来考核但可以用来及时发现团队中的潜在问题。关于考核指标还是建议使用业务相关的指标从中挑选有一定技术影响程度的。也分享了两种落地方案分别是长期用 OKR短期用环比来考核。希望对你有所启发。抛砖引玉欢迎在留言区分享你的观点。
