KPI 督促每个人快速解决问题 不考虑问题的深度以及重复性和潜在的风险,怎么破才好

[YourLord]

所以说一个好的 TL 很重要，既要懂业务，又要懂技术，但是最重要的是要有足够的时间去做 code review。

这样的 TL，前两点做到不难。第三点的话，其实也不是个人能力的问题，看公司制度和 TL 的领导是个什么货色了。另外，kpi 本身是个大坑；用好 todo list 之类的工具足够了。

[stcasshern]

@YourLord 目前组长乃至部门，都不太 care 技术，表现是：只要领导认为可以做到，然后能讲出好故事 划出大饼，就会鼓动底下人去做；然而做的时候是否有更高效的解决方法，是否能给底下人带来学习成长，都会被忽视。请问下对此怎么看，或者说该如何建议建言。

[otakustay]

据说，改 OKR 会好（个屁）

[otakustay]

我认为最好的办法，就是高管和高 T 全部每年扣 8 个月薪水下来，3 年后项目没爆炸再返还

[Varobjs]

非技术领导才不管你技术是否有深度，有没有可扩展性，风险有多少。他们只管什么时候解决问题，怎么保证不出问题，最关键的保证以上的基础上，还不要用太长时间，这就是很多人眼中 K P I
至于完不成，加班啊。。。

[TtTtTtT]

这是一个倒逼的循环。
为了让当前干活更加快速，前置的工作会创造尽可能多的可能性（积极的），但是对于无法预知的未来，技术债是不可避免的（消极的）。在消极因子积聚到一定程度、导致 KPI 无法达成后，就会倒逼产生新的解决方案（中性的），进入新的循环。
从达成目标的角度而言，或者是站在商业模式的立场上，上面的循环反而是良性的，因为消极因此都最终被强行转化为中性的。
而你所说的深度、重复性和潜在的风险，绝大部分时候都会在新的解决方案中处理（但处理的结果不一定是积极的）。如果作为工人，一方面就快速迭代，这是 KPI 导向下工作的本分，另一方面对于快速迭代中产生的问题进行归纳，以迎接下一次的革新，这是晋升的机会。如果作为领导，需要有节奏的对自己负责的工程进行梳理，如果当前的状态仍旧可以快速迭代，那就定期整理问题，如果当前的状态已经寸步难行，那就根据整理的问题直接开新坑。

软件是有生命的，效率优先的情况下，快速的迭代甚至包括了快速的淘汰旧架构，快速的产生新方案。

[bengcaca]

在公司组织架构不动的情况下，人员流通比较少的情况下，改成啥都是扯淡。就跟人性格一样，公司的性格已经固化下来了。具体是 KPI 还是 OKR，目标其实并没有变化，而且执行人也还是那些人，都是换汤不换药。

[gzchen]

@otakustay
普通员工要不要一起扣？

[google54321]

OKR 还可以啊

[scnace]

@Varobjs YYSY 投资人和大老板确实更喜欢这种偏管理的高层，有技术深度的高层可能会比较好招人，但是偏管理的高层能确保业务推进（你忽悠我也没事，到 deadline 把东西摸出来就好了啊……

[otakustay]

@gzchen 谁为架构设计、稳定性、可维护性负责就扣谁的，我不认为一线的员工需要为此负责，也不认为一线的员工有能力为此负责

[index90]

KPI 和 OKR 其实都是目标管理工具，最直观的区别是，前者和工资挂钩，后者只是和你“谈谈人生谈谈理想”。
“KPI 督促每个人快速解决问题”
这是对的，帮助大家专注于目标
“不考虑问题的深度以及重复性和潜在的风险“
这锅不应该由 KPI 来背，KPI 只是工具，KPI 的内容是人定的
“怎么破才好”
制定 KPI 的时候和管理者谈谈，或者坚定按照 KPI 字面执行

[songco]

码农的 KPI 一直是个大难题

[chenliangngng]

KPI 是个好东西，你考核什么，你一定会得到什么；
但 KPI 又是个坏东西，凡是你不考核的东西，都会成为业绩黑洞。

[kyuuseiryuu]

错误的目标就会得到错误的结果。

[whusnoopy]

如果是一线搬砖的，不用考虑 KPI 或别的什么，只要能出活，给定输入能得到确定输出，就可以了
如果是小团队负责人，看更大的层面的需求，对你的团队跟对一线搬砖一样的话，给定输入拿出给定输出就行，内部是否优化复用性等看自己的操守，否则像大团队负责人看齐
如果是大团队负责人，那一定要平衡好手里的资源和产出关系，人是资源，机器是资源，可复用的产出能有效提升人效比，但一线的同事的成长，只能是看怎么考核小团队的目标，和一线负责人的能力

我的结论：老板们自有老板们的考虑，不用为老板们多操心，你以为老板傻啥都不懂，也许老板只是拿你当一个随时可替换的码农资源在使用，所以不要求你有多好的复用性，关心好自己的成长就好。如果你就是老板，那你想办法去拆解绩效考核方式