|
先问问自己：为什么要定KPI？ 定KPI无非是一个核心目标，那就是通过“奖勤罚懒”来引导员工，使得他们努力工作——当然企业没有罚款权，因此一般会变通为“定一个较低的基本工资，其它算到奖金上；然后只有A级卓越奖、B级优秀奖、C级合格奖和D级无奖”。说白了还是一回事，朝三暮四的把戏而已。 然后呢，怎么识别勤快/懒惰的员工呢？ 很简单，计件。A一天装配了10个轮胎，B只装了8个，C只有6个，D装了3个还歪了一个…… 那么，如果单件工资是X的话，给A的报酬就应该是10X，B是8X，C 6X，D 2X。 很遗憾。这个看起来天经地义一般的解决方案是傻子才会搞的——如果你发现手下有个管理者这样管生产线工人，嘉奖他；但如果他这样管技术类工种，请尽快撤他的职。 这是因为，技术类工作，产出是独一无二的。压根不能像流水线工人那样评估。 甚至于，技术类工作，产生的“量”和“质”往往是背道而驰的。 当你只顾考察他的量时，你只能得到一堆垃圾——而且技术类成果会有很多很多的衍生效应，比如会造成其它同事工作对接困难、比如会导致本来普通计算机10%CPU占用就能搞定的工作你得掏大钱砸几十上百台电脑进去搞一个集群…… 但在你眼里，后者玩的那可是集群！高科技！而前者嘛……一个512M内存的破机顶盒级电脑有什么好玩的！ 很遗憾。前者那才是真正的高科技。那叫算法优化。 后者嘛，那叫一将无能，累死千军。 这并不是笑话。我就遇到过这样的神人。他把一个大型交易系统的数据库查询复杂度“优化”到了O(N^3)级别——但实际上给真正懂行的技术人员，这个复杂度就应该做到O(N)！ 当然，你可能看不懂大O标记法。简单说就是：一个原本打算支持2000万用户的系统，如果给靠谱人设计，那么搞个服务器水平扩展架构然后按需增加机器即可，至多几百台服务器就能搞定（线性增长嘛）；但一旦搞成O(N^3)，这个系统就会随着用户数增长指数级增长——于是，100个用户，这个系统几秒钟就能完成盘点；500用户，这个系统盘点一次要半小时；当用户达到1000人时，这个系统盘点一次就要六个小时……依此类推，当用户数真的达到两千万时，公司就需要组织一支军队，把全世界已经生产出来的电脑全部抢过来、再奴役三星台积电等半导体厂让它们啥都别干先专心造八十年芯片再说…… 什么？这样能不能满足要求？没那事，你得给别人找点事做，不让就显得你无能了。折腾他们八十年，你死之后哪管洪水滔天。 可想而知，这会对公司造成多大的损失——但看KPI，谁能比他更忙、做的事情更多吗？！ 作为对比，那个把事情做对的人，实际做了什么？ 答案是什么都没做。除了数据库表设计从一开始就没搞那么复杂、使得将来围绕着数据库开发时，大家都不用做太多事之外。 换句话说，这种情况下，一个技术人员的价值，恰恰体现在他没有做那些多余的错事上。 从头追查这件事，就会发现，优秀开发人员和滥竽充数者的价值差异，运气非常好的时候，也只会在两年之后才让你发现——当后者问题爆发时，就会知道他吹的天花乱坠的玩意儿……不过是驴粪蛋外面光。 但是，如果真到两年后问题爆发时你才知道他是草包……砸进去的几千万甚至上亿开发费用已经打了水漂。 身为股东，你可能只剩两个选择。一是家大业大扔点没啥，二是破产自杀。 不想扔也不想自杀？那就难办了…… 不过也不是没办法。古人已经有解决方案了： 齐宣王使人吹竽，必三百人。南郭处士请为王吹竽，宣王说之，廪食以数百人。宣王死，湣王立，好一一听之，处士逃。 没错。这就是办法。别让人吃大锅饭，一个个考察。从小项目开始识人、提拔，找到合适人再慢慢组织团队搞中大型项目。 你可能会说：但是现在我已经有一个五百人的团队了啊…… 这就是软件工程的重要性了：真正会做工程的，一定是把一个大项目拆成一堆中型项目、中型项目再拆成小项目、小项目拆成函数来做的——合格的技术专家眼里就不存在大项目，只有基本函数库构成的小项目、一堆小项目构成的小项目以及小项目构成的一堆小项目构成的小项目…… 换句话说，考察你的中上层项目经理，看他们有没有本事把一个大项目三言两语说清楚、分成简单清晰、各自独立的几个模块——没这能耐？请他吃铁板炒鱿鱼吧。 类似的，考察你的每个程序员，看他们能不能清晰简洁的实现自己的任务、能不能把自己的任务实现的边界清晰、便于复用——然后，这些边界清晰的一个个小项目，你还考察不了他们的完成速度、效率、可靠程度吗？别整来整去，最该吃鱿鱼的是你自己吧？！ 软件开发就要用软件开发的方式管理。软件工程不会？没有金刚钻，谁给你的勇气揽这瓷器活。 综上，KPI只是你关于软件流程管理、开发人员能力评估等专业知识的外在体现——事实上，这KPI还就是当年引进的、国外软件企业的先进管理理念。 但这玩意儿想玩转，要么你是管理和技术两手一起抓，两手都要硬；要么呢，公司内部两条线，一条技术线，一条管理线。 技术线里面的负责人叫项目经理，他必须是一个软件工程高手，具体技术可以不精，但总体性的把握能力必须有。他负责识人、把工程师带好，确保项目保质保量按时完成。 管理线里面的负责人是业务经理，他掌管资源调配等工作。软件团队立项，要告诉他大概需要多少人多久时间开发、需要的软硬件投资额等信息；他来判断这个项目有没有前景、能不能挣到钱，决定要不要上、最高可以投资多少钱做研发。 将来，软件团队要对按时保质保量完成开发任务负责，业务经理则对项目能否赚钱负责——更复杂的模型里面还要有市场部/客户部/客户代表、产品经理等角色：市场部/客户代表提出需求，软件部决定能不能做、需要多少人月；产品经理确保人机界面设计合理……但最终，要不要上马项目、可以给多少开发经费，这还是要业务经理拍板。 注意各自负责的范围以及职责。尤其注意合作流程非常关键——如果你让客户经理/产品经理直接干预了开发过程，那么造成的延误该谁负责？ 现实是，绝大多数产品经理、客户经理、项目经理是不合格的——而他们的不合格，是因为业务经理乃至更高层领导不合格。 因为他们的不合格，很容易出现：
你看，问题的关键压根不是什么“如何定KPI”，而是你，你的同事，你们这一干人，究竟懂不懂开发？懂不懂管理？ 如果懂，那么你怎么搞怎么对——无论是散养、KPI还是OKR，你总是能保质保量按时完成任务、且团队成员还轻松惬意按时上下班。 但如果不懂，你搞什么都是和尚念经。 再说一遍：问题的核心是经理的能力，不是外在的具体表现。能力到了，怎么玩怎么对；能力不到，越是东施效颦，死的越难看。 |
|
|
