下午参加了技术的上半年review，技术团队上半年定了个指标叫“上线准时率”。

起因是去年（22年）技术对需求上线时间的预估没怎么准确过，稍微复杂点的需求基本要延期十天半个月上线。技术老大于是想23年一定要解决这个问题，干脆咱就定个“上线准时率”的指标，全体技术同学23年向这个指标对齐。

于是，上半年，我们的需求上线准时率果然提升了，而且提升了很多。但是，只有产品经理才知道这其中有多么的痛苦。首先，从产品prd评审阶段，产研就开始相互拉扯，技术同学要求产品把需求完善到“尽善尽美”后，才会开始评估工期，一旦有需求模糊的地方，对技术来说就是个潜在延期风险点，以前一天搞定的需求评审，硬是拉长到一周。其次，为了保险起见，需求开发所需时间尽量往多了评估，改个字段甚至要排个一天时间。最重要的，一旦排期定下来了，很难做需求插入，需求轮转周期变成两个月、三个月，以前的灵活性丧失了。

但在以前，需求评审时把技术路径想清楚了就准备开干了，按照最快完成的时间来做评估，重要紧急需求灵活插入，客户评价相当高。所以，为什么看似达标了的OKR考核，对业务伤害这么大？

其实，错误在一开始定指标的时候就发生了。“上线准时率”是个单一指标，应当需要关联指标相互制约起作用的，类似于新闻网站如果只定个点击率的指标，那运营同学肯定标题怎么夸张怎么来，一段时间内点击率会有提升，但长期来看对平台和业务伤害巨大。其次，管理上要考虑“人性”，人的本能就是对自己趋利避害的，不能要求大家是圣人，所以规则上一定要避免指望“自觉”。最后，大家可能好奇，发生这种事情技术老大不知道吗？匪夷所思的是，可能真不知道，因为技术老大已经脱离一线好多年，对目前这些技术栈也完全不了解。所以啊，难怪阿里要裁中层这些p8p9，我们这种千人左右的公司都如此，大厂应该更严重吧，好多人真的还停留在五年前，甚至十年前，sad。