自己还是需要不停学习，下面的观点也是目前能想到的，还是需要不停补充，不停修正。有更好想法的同学欢迎留言,探讨。

技术的量化方法

很早的时候，在另外一家公司，嘲笑过公司 HR 经理给技术团队定 KPI，我当时想都没想，就反对了。说技术是没法量化的，现在想想，还是太片面了，即使没发 100% 定 KPI，至少可以定一部分吧。在现在的团队，我发现很多量化标准。

但是不要忘记一个问题（参考 Input／Output 模型的缺陷），哪些指标适合哪些人看。比如代码行数只适合一线 Team Leader 自己看，不要把这个标准公布出去，自己做为内参就行了，否则很容易出问题。

拥抱变化的价值

一个业务可能给一个 P9 来做，定时间、定目标。到了时间没有达到目标，可能 P9 就要换别的项目去做了，下面的 P8、P7、P6 可能不会动，换了老板以后，几十个人的团队，又要面临一个问题：证明自己。

所以 P8、P7 带头会拼命一段时间，下面 P6 也跟着跑。团队斗志可以恢复一下，效率确实可以提高。

但是人的兴奋劲都是有保质期的，过了大半年还是没起色，就疲惫了。如果业务起来了，团队肯定能兴奋；如果业务没起色，就换老板，让团队再进入「证明自己」的轮回中。

厂内的高层每年还要轮岗，还是高端的玩法。

对于基层的技术 leader 很容易犯的一个问题就是，我们正常定需求、估时、量化质量。时间是技术 leader 输入给一线开发人员的一个核心东西，然后到了时间，leader 来要 Output。到了时间没有产出，KPI 一出，就完事了。

这个模型操作起来非常简单，有效。但是很容易忽视一个问题，就是一线开发人员的状态。

有的同事孩子生病、自己结婚、老婆怀孕、学车、买房、失恋等等一系列的问题都会影响一个人的状态，如果工人父母病重，leader 还来继续要 Output，这是不道德的。早期社会上宣传「家人去世，还工作在一线」这种错误的价值观，现在已经不适合了。

所以一个重要的因素是，一线 Team Leader 不要忘记「同理心」。Input 不光是 Excel 表上的排期，还有一个理解别人的胸怀。

不同级别、不同背景的人都有自己的思考方法和出发点。同一个问题，都可能出现争论，所以千万不要下一个「死」观点，注意变通。

点、线、面问题。降维攻击问题。