KPI,该死的KPI!

打算写这篇文章的时候,我在网上搜索了一下,结果发现了一篇同名的文章《该死的KPI》,已经表达得非常透彻了。那么,我只能换一个角度,来讨论KPI的问题了。

一、以医生看病做一个类比

想当年,医学还不发达,医生只能“望闻问切”,然后就开方抓药。到了现在,医学检查越来越强大,我们到了医院,医生往往二话不说,就开始开一堆的化验单,让我们去做化验。不看到化验单上的数据,医生都不知道跟我说什么。等到看到了单子,医生一下子就神气起来了,白细胞比较高,你可能有一些bla…bla…,再看你的淋巴细胞偏少,所以bla…bla…,有了这么一组数据,医生就敢开药了。

这样的看病科学吗?看起来很科学啊!他们都是用科学仪器化验出结果的,所谓的数据偏高偏低,也是根据科学规律统计出来的,所以,他们那个当然是科学。

但是,对症下药呢?因人而异呢?根据医生丰富的临床经验,具体病例具体分析呢?这些东西,还有多少医生讲究呢?

其实,这篇文章不是在对现在的医生进行吐槽,一个本硕连读的临床医学毕业生,至少已经读了7年的医学专业了。等到他能够给我们看病时,已经将近10年过去了。而绝大多数的企业管理者,在管理领域积累的经验,所接受的专业训练,却少得可怜。当他们开始借助KPI为工具,来进行管理时,往往会做出很多想当然的决策。

就好比一个一窍不通的医生,只听说过白细胞一种指标,就敢给病人开药一样危险。

二、KPI为何成为很多企业都愿意采纳的管理工具?

1. 管理领域的研究,远远不如医学领域成熟,还有许许多多的奇谈怪论,偏方灵药,在市面上流传。没看到在机场反复循环播放的那些大师的演讲吗?那些都是流毒!

2. 管理者的能力,进入瓶颈期。管理非常复杂,非常困难。随着企业规模的逐渐扩大,随着企业业务的不断发展,管理者会发现自己忙不过来,看不过来,管不过来。间接管理、分级管理,势在必行。由于不可能深入的了解企业内的所有问题,只能了解一个大概,一个摘要。又由于仅仅依靠文字的描述,太容易被下面的人做手脚,所以必须依靠那些不容易篡改,容易被复杂的数据,来表达。因此,当你用KPI管理公司时,你获得了一种虚幻的,一切尽在掌握的满足感。

3. 企业总要建立某种奖惩的制度,如果没有KPI,那么更加有可能变成老板的一时兴起就滥施赏罚。更糟糕的甚至是那些最后奉迎拍马的人,获得了奖励。

三、为何KPI通常弊大于利?

1. 一组指标体系,永远无法反应企业运作的全貌。各位老板们排着自己的脑袋,或者外面来的管理顾问给出的“基于丰富经验的建议”,通常的不够靠谱。

2. 因为KPI会与一个人(或者一组人)的实际利益挂钩(当然,这是KPI施行的初始目标),所以,员工一定会选择趋利避害的“正确策略”!再与上一条原因配合,员工的努力追求,将会导致企业的“异常发展”。

3. 因为KPI的假设(企业内的所有人,一定有好有坏),所以通过一组数据,我们可以把好的与坏的,都识别出来。所以,每个人都有各自不同的好,与各自不同的坏,这个事实被忽略了。总体而言,在实施KPI之后,一定会有人,遭遇不公正的评判,士气下降,进而离开。虽然:末尾淘汰,也是一些老板想当然的目标。

四、游戏式管理与经验值

我曾经在一家施行游戏式管理的公司工作过。简单介绍两句:每个员工都有自己的经验值,每天上班能够增加经验值,完成某个项目,能够增加项目经验值,经验值达到某个级别,就自动的升职加薪。

怎么评价呢?这个管理体系,彻底错了!

从网络游戏,得到灵感,引入企业管理领域,最大的一个假设错误是,投入与产出搞反了。在网络游戏领域,玩家投入时间,投入精力,甚至投入自己的金钱,在游戏的世界里不断成长,获得经验值与等级提升。而在企业中,员工投入的时间与经历,换得经验值提升之后,能够得到收入的增长。

再直白一点:在网络游戏,用户投入的是真金白银,收入的是虚拟的数值;而在工作中,员工投入的是时间精力,收入的却是真金白银。

在网络游戏运营的领域,网游企业的目标是:诱使玩家投入越来越多的真金白银(这是最容易量化的东西),付出的却是虚拟的经验值与道具(所以这个生意极其赚钱)。

而在企业管理领域,公司的目标是:诱使玩家投入各种难以量化的工作量(这个太容易忽悠老板了),付出的却是真金白银的工资奖金(所以老板会花很多很多的冤枉钱)。

五、总结陈词

1. 数据是有价值的,但是数据的价值决不能被高估。

2. 各种数据都是衡量工作与业绩的参考,但决不能直接与员工的利益挂钩。

3. 管理永远是复杂的工作,决不要患上KPI依赖症,而不去了解一个企业的真实情况。

开会,该死的开会!

有谁是喜欢开会的呢?一个不愿意透露姓名的在政府机关工作的朋友曾经告诉我,他的工作就是:开会,或者准备开会。

其实,我了解一下具体情况之后才发现,政府机关由于常年开会,已经积累了丰富的经验,比咱们开得好多了。

作为一篇系列文章,按惯例,还是列一个痛恨排行榜吧!

  • 第一名:不遵守时间。不能按时开始,不能按时结束。绝大多数开会,都像是受刑,居然还有延长刑期的!
  • 第二名:跑题。在轻松融洽的氛围里,同事们愉快的交谈着,从一个话题,联想到另一个话题,再联想到新的话题,不时爆发出哈哈大笑。这他妈真的好笑吗?
  • 第三名:头脑风暴。“来,这个问题,咱们大家一起头脑风暴一下。”……“都说说,都说说,别沉默啊,小明,你先说两句。”……“今天这个头脑风暴,很有成果啊!咱们下周再开一次。”
  • 第四名:老板High了。一个非常成功的老板,当然会有辉煌的过去,当他向大家说起自己的奋斗历程的时候,你是听呢?还是听呢?还是面带微笑,若有所得的认真听呢?
  • 第五名:扯皮推诿。或者推卸责任,或者回避问题,或者东拉西扯,或者强调困难,或者指桑骂槐,或者颠倒是非,或者抵死不从,或者阳奉阴违。
  • 第六名:顺民。老板发言,下面一群人,默默的记录,认真的思考,不时点头,段位高的,还会恰当的补充两句。让一言堂变得不那么一言。
  • 第七名:茫然。会开完了,大家四散而去,开的什么内容?不记得了。
  • 第八名:衍生。“我们发现这个事情,还有很多没有讨论清楚,因此,我们还要在和XXX、XXX等部门,再开N个会。”

总结陈词:大多数开会,对工作没有益处,却有害处。但是,大多数公司里的人,都不会开会。

附带说一句:有人为会问《罗伯特议事法则》如何?我说,不用那么复杂,就三条,做得到就已经极好了:

  • 会议之前,先确认人员、主题与目标
  • 会议之中,严格控制时间与讨论范围
  • 会议之后,确保会议的成果变成有价值的工作目标

加班,该死的加班!

说实话,我原本没有写系列文章的打算的。

但是,今天我正好看到了两条条微博:

@玄了个澄的:在微信里看了@Fenng关于加班的言论,很想再听听@左耳朵耗子的评论(看热闹不嫌事大)
@左耳朵耗子:当然错了,不然大家怎么看我和大辉的热闹?! 文中提到了加班和效率,文中的观点是错的。我改天写一篇。
于是我又去看了Fenng的那篇微信文章。虽然文字有些散乱,不过大概的意思还是能看明白的,为了精简我的文章,就不再一一点评别人的言论了,进入正题。
1、加班绝不该是常态,如果有一个紧急的活,要怎么怎么快速的干完,或者有某个紧急的Bug,必须尽快修复,没话说,必须加班。但是,如果有一家公司,每一个人,每一天,都在加班,不是一个小时两个小时的加,而是11、12点下班为常态,那么这个公司一定不正常。
2、无论是资本主义国家还是社会主义国家,都存在劳动法,都会保障劳动者的基本权利。如果有老板跟你说:我们是创业公司,所以我们自然天天都要加班。那么,这种老板,就是在说:“白马非马,所以创业公司不是普通的需要遵守劳动法的公司。”
3、与Fenng的意见类似,我可以列出最厌恶的加班情况排行榜
    第一名:加班给老板看,而且,居然老板还在津津有味的看着。只要手下还在公司里呆着,老板就心满意足。这种没有任何产出的加班,还有些团队因此自诩为“创业氛围浓厚”,我就真的没法明白了。
    第二名:6点以后开会,老板的想法其实很实际。白天你们当然要实实在在的干活,晚上开点会,拖点时间也不算啥。正好可以把明天要干的活,先讨论清楚。这种思维的老板,我称之为鸡贼。
    第三名:将加班标榜为企业文化,以至于没人敢不加班。日本这种变态国家,将这一点发挥到淋漓尽致。即使不加班,都要在外面喝点酒再回家,否则没脸见老婆。
    第四名:效率低下导致加班,每天都有干不完的活,而且每天都只能加班加点的干活。其实那点活如果是安排得妥当,少出些纰漏,早就干完了。一将无能,累死三军。说的就是这种缺乏管理导致的加班。
    第五名:不切实际的进度计划,导致加班。或者是项目组成员的过度乐观估计,也可能是老板想要榨干员工的每一滴精血,总之,这种事情也挺常见的。
    第六名:正好兴致上来了,这个活不干完,我也睡不着觉。很多热爱编程的家伙,可能会体会过这种加班,甚至对这种加班还念念不忘,认为是难得的人生经历与宝贵的生活财富。
4、总的态度
前面的三种加班,我极度厌恶,这样的公司,我能逃就逃。第四种,是可以通过改进管理来解决的。第五种,这种事情成王败寇很难说对错的。第六种,如果是年轻人,倒不妨多体会几次,也是一种历练。
5、多说一句,关于加班费的问题,由于程序员的效率差别极大,如果加班都有加班费,老板就无法将必须的加班和为了领加班费而混加班区分出来,从这一点来说,我倒是同意不给加班费的做法。但是,相应,不给加班费却又要求员工“自愿加班”,那就有些…了。
btw:这个标题不错,也许可以继续写其他的一些《该死的XXX》

进度,该死的进度!

早在2005年,我在ITEye连载了一个系列文章,当时的标题起得很大气《定论——软件开发的方法论探讨》,在写完1~7之后,我突然偃旗息鼓,写下了最后一篇(完)。

有兴趣的朋友,不妨一读:定论——软件开发的方法论探讨(1)(2)(3)(4)(5)(6)(7)(完)

当年的这篇文章,也是有感而发,最大的困扰,来自于软件开发的进度,难以估算。按照传统的软件工程的做法,大多数的开发进度,都会不断延期,不仅仅是一个给定范围的开发任务,会出现估算偏差,更加糟糕的是:在一个不断延期的开发过程中,还会有新的功能需求,不断加入。

后来,软件大师们,发明了一个新的办法:既然不能指哪打哪,那就打哪指哪。既然不能在给定的时间内完成任务,那么就反过来画个圈,这个阶段咱们完成的任务,就是咱们的阶段目标。

在给这种“掩耳盗铃”开发模式,起了一个漂亮的名字之后,这种敏捷开发的方式,在全世界流行起来了!

但是,真正“精明”的老板,是不会上当的!在敏捷开发模式下,开发人员永远是无可指责的!所有的开发进度,开发人员拥有无可争辩的主导权:“每一个Story的开发工作量都已经被估算出来了,产品经理能够选择的,仅仅是在下个阶段先实现哪几个Story而已。”

老板们通常会说:“三个月内,我要看到这个上线,不要告诉我不可能!公司的信条是:没有借口!”

进度,有时候是一个刚性需求,比如说:双11促销配套网站,决不能在11月12日才上线!

另外还有一些原因,导致了老板的无法信任不再估算进度的敏捷开发方法。

1. 听说,程序员之间的开发效率,高手和低手之间,甚至可以相差100倍。你如何才能让老板相信,你已经竭尽全力了呢?(他已经发现,你一到6点就下班了)

2. 软件开发的过程,总是难以一帆风顺,老板就会深度怀疑,明明你们的开发是可以提前完成的(如果不出这个、那个的bug的话)。

3. 当然,过度乐观的程序员,给自己挖了深坑,也是可能出现的情况之一。

4. 很多老板有一种行之有效的方法:先给程序员们,定一个无法完成的进度,然后,程序员会出于内心的愧疚,而努力熬夜加班,最终:进度虽然也会拖延,但是却常常能令老板偷笑。

根本的原因在于,即使是经验丰富的开发者,面对复杂的项目,也难以准确的估算进度,更不要说对于软件开发一无所知的老板了。一方面,老板不知道这活需要干多久,另一方面,手下的开发者,又不能做出靠谱的估算。一个不甘被愚弄的老板,只剩下一个选择:督促开发,尽力赶工。(只有这帮家伙,真正干到精疲力竭,我才能够相信,他们没法更快了。)

正好今天在微博上看到两个段子,虽然都是在说产品经理的,但其实是在说软件开发进度的。

一位艺术青年去拜访大师在:“为什么我专心画一幅画,只消一周功夫,可卖掉它却要整整一年?”“请你倒过来试试。你花一年功夫画一幅画,兴许一周就能卖掉。”大师说。青年照办,第二个月就因为进度太慢被产品经理捅死了……(via @顾扯淡 )「段子」

天黑请闭眼,rd睁眼,rd开发,rd闭眼,qa测试,qa找rd的bug,qa闭眼,天亮了,pm死了

因为开发进度,大多数的公司内部,都存在各种紧张的关系和激烈的争吵。这几乎算是永恒的矛盾了。

 

回到我写的那篇文章,当年的《定论》之所以没有写完,当年我是这么说的:“要能够检验软件开发方法的优劣,必须基于对于软件开发本质的正确认识,这样才能量化两个因素:软件需求的复杂程度以及软件开发的实际工作量。”

但是,在当时,我并没有找到这样的方法,而现在,我猜测Trello也许是解开这一难题的关键一环。由于我们目前还在各种尝试的阶段,还难以提出太多明确的观点,简单随意的先抛出一些:

  • 软件开发的本质,是经验复用+智力探索,经验丰富与脑子好用,同等重要
  • 软件开发管理的主要目的,是减少团队配合中的各种浪费与等待时间,以达到开发效率最大化
  • 基于Trello的看板拖拽操作,有可能真正将开发过程中的实际工作情况,记录下来,而这是一切改进的前提
  • 进度估算,是一个伴随开发过程同时进行的行为,而不仅仅是开发工作的前置阶段。但是,不能因为估算困难,就放弃估算
  • 也许,我们能够找到一个更加直观与科学的办法,既让开发者感到舒适,又让老板感到满意

先告一段落,等回头想得更加清楚一些时,再继续这个话题。

技术选型:效率至上与实用至上

当我们面对一个架构方面的决策时,通常会处于某种两难的境地,选A还是选B,”市面上”同时存在各种丰富多彩的说法,单独看去,往往各自言之成理,如果仔细对比,又往往莫衷一是。

在我目前所就职的公司,前段时间我刚刚做了一个架构决策:原来的系统,开发人员采用PHP编写后台执行的进程脚本,处理各种需要高性能的业务;另外,他们又用CoffeeScript编写了一个Web控制台,以配置、管理和监控这个系统。这令我感觉相当的怪异,因此我决定,后台关键进程,重新用nodejs编写,而Web控制台,则重新用PHP编写。

这个决策背后的逻辑是:一个复杂的系统,越来越多的是由多语言混合编写而成的,而在实际的系统中,所谓的架构决策,就是在不同的部分,选择不同却适合的语言和技术。

这个结论,我一直相当心安理得。直到上周,我去参加了ThinkInLAMP组织的PHP2013开发者大会。在会上,我听到了来自台湾的梁枫先生的一场演讲《在WEB之外——PHP》,在演讲中,他反复在问一个问题:PHP真的只能写Web吗?而他的开发实践相当的有趣,他在用PHP编写工业自动化控制方面的应用,编写串口通信的代码,同样的功能,用PHP编写的时间是2周,而用C语言编写的时间是8个月,而且PHP的2周,是他一个人完成的。这样的演讲,令人印象非常深刻,也引发了我更多的思考。

会后,我找到了梁先生,提出了我的疑问,举的就是我在公司里,颠倒两种语言的架构决策。蔡先生的回答是:对啊,当初我只用了2周,但是后来我们还是又花了8个月呀。PHP,主要可以快速的拿出原型,真正的产品,还要C语言去开发一遍的呀。

经过这番讨论,我得到了一个新的富有启发的结论:在快速原型的阶段,就可以选择快速开发的语言,而在实用的阶段,就应该选择更加实用的语言。

这么肤浅的结论,真的值得大肆宣扬,再写一篇Blog吗?自然不是,因为我在后来的一周里,一直在脑子里反复思考这个问题,然后,突然想明白了一些:

在一些极端的领域,效率至上与实用至上,可以毫不相干,各自有所追求,前期追求效率的开发产品,由于成本极低,大多是可以随时抛弃的。而真正的困难在于想要兼得。常见的与架构相关的两种痛苦:一种是,刚开始为了追求快速开发,在技术选型上怎么快怎么来,结果系统越来越大,越来越复杂,等到想要考虑架构优化,想要重构的时候,却已经积重难返,改起架构来伤筋动骨。另一种是一开始想得太多,架构做得太复杂,杀鸡用牛刀的技术用得太多,往往还没有等到系统开发完成,就已经Game Over了。

还有一个现象,也很常见,我们常常能够见到各种技术方面的争论,各执一词的原因,往往是由于各自的立场不同:你说某某语言效率极高,他说等到复杂了这个语言就撑不住了。一些常常被人引用的例子是:某某知名网站,放弃了PHP技术、放弃了.NET技术,放弃了Ruby技术等等,对立阵营的同学们,就感到欢欣鼓舞:看吧,就知道你们那个语言,只能拿来开发玩具应用…

长长的引言部分结束,开始系统性的阐述我的观点:
1. 选择技术,往往不是选择某种单一的技术,而是选择一个技术栈;
2. 有些技术一开始的出发点就是追求开发效率,然后在后续的发展中,逐步开始追求实用;
3. 有些技术一开始的出发点就是追求实用性,然后在后续的发展中,逐步开始追求开发效率;
4. 想要兼得鱼和熊掌,的确困难,但是并非没有可能,我们可以找到一些优秀的、可选的技术集合(兜售私货的伏笔);
5. 对于技术选型的判断,需要考虑理论情况与实际情况;

效率考虑
技术复杂度(复用性):学习并掌握一组技术栈,需要了解多复杂的技术;相应的,当我们掌握了这门技术,他可以在多少地方复用?
技术友好度(优雅性):在开发的过程中,会不会有各种莫名其妙的陷阱,会不会让我纠缠于各种莫名其妙的细节?
实用考虑
业务复杂度(组织性):随着业务的复杂,我们的代码会不会最终无法驾驭?无法维护?无人能懂?
性能提升度(潜力):随着业务的增长,压力的提升,我们会不会最终被迫放弃现有的技术架构,重头开始?

也许,我们可以凭借这四个维度,做一个雷达图,以便更加准确的评价候选的技术,这里就先靠文字描述粗略的表达一下吧。

LAMP,当然是最为知名也最为成熟的技术栈,随着技术的发展,Nginix、Memcached、Redis、LVS等等技术,也非常自然的加入到这个体系之中,常常有人宣称:LAMP是全能的,而我在大多数时候,也相当同意这一点。如果将LAMP拆开来看,除了PHP,其他的几项技术,并非LAMP独有,如果我们单独来看PHP的话,他在开发效率方面相当优秀,但是略弱于Ruby&Rails;在实用方面,却略胜于Ruby&Rails,因此:PHP始终是一个不算坏的选择。

Ruby&Rails,是一个较新的技术栈(当然,我们可以说它仅仅替换了LAMP中的P),但是,Rails在快速开发领域的贡献是划时代的,具有开风气之先的意义。现在的Rails,也开始越来越大,越来越复杂,逐步的开始追求实用,这也造成了另一个有趣的现象:Ruby whitout Rails的兴起。甚至可以认为:Ruby社区一个非常显著的特点,就是强烈的追求开发效率,不太强烈的追求实用性。

nodejs,是目前最新的一个技术栈,他最大的一个优势,就是前后端只需要一种编程语言,使得原本就熟悉JavaScript的程序员,爆发了极大的向后端进军的热情。而另一方面,由于nodejs的异步响应的高效特性,使得其在实用性方面,有相当宽广的未来。但是,现在的nodejs,对于业务复杂度的支持,还远远不够。

Java是一门老牌的语言,说实话,我已经早就背叛了这个阵营,原因很简单,Java仅仅在组织复杂业务代码的能力上,有不小的优势;但是:这是以一开始就引入的架构复杂度为代价的。Java社区的众多框架,似乎也忘记了对开发效率的追求,一门心思为了展现更多的设计模式…(纯吐槽,请无视)

HTML5,也是相当火爆的热门领域,很大的一个原因,就在于:HTML5的知识,可以复用于Browser、Mobile、Tablet等原本差异极大的多个领域,因此在开发效率上,对程序员产生了极大的诱惑。只是在实用性方面,目前还有一些疑问。经常听人提到的HTML5&Native混合编程,我的直觉是:这样只会造成更多复杂的问题需要解决。

Golang、Erlang,本身就是根植于实用性(尤其是性能)追求的技术,在开发效率方面弱于其他技术,原本就是合理和正常的,对于某些预期肯定会非常复杂的系统,一开始就选择这样的技术,可以说是相当正确的选择。

Redis是一个好的技术,无论是自己一个人做个玩具小应用,还是在关键领域,承担核心性能组件。REST是一个好技术,无论是开发一个DEMO,还是用于整个SOA架构的核心,都非常合适。这样的技术,的确不多。

最后需要表达的一个观点是:以上这些点评,仅仅出于我对这些技术的了解(你看,我根本不懂Python/C#,所以也不敢点评什么)。 对我而言,在目前的阶段,nodejs是一个非常值得加大投入,深入学习的技术栈(私货在此)。

希望这篇文章,不致令各位朋友失望…