社区运营三大忌——以知乎为例

在「私吐槽」专栏,我针对这次的419事件,只写了一句话:「我一直觉得,知乎没搞好,与张亮这样的投资人,有很大关系。」

在「思考IT」这个专栏,我打算写一些更加有营养价值的内容。

前天与一个朋友聊天,我还发表过一个观点:「知乎是国内运营得最好的几个社区之一」,但是,我那天没有提到的「但是」,我想写在下面:

一忌:渐渐被遗忘的初心

周源曾经回答过这个问题:知乎团队的初心是什么?

基于这个想法,我们的初心是:

  • 每个人都是某个领域的专家,知乎能帮助每个人去展现自己亮闪闪的一面
  • 知乎将成为一个由人们的知识、经验和见解组成的 P2P 网络
  • 知乎帮助拉近人与人之间的距离
  • 知乎将持续产生高质量、可沉淀的信息,并让有价值的信息和人都关联起来

而我在另一个问题里,提到过自己的担忧:可能导致知乎走向失败的最大风险是什么?

我想,如果知乎有可能失败,最大的原因,是:“对于何为优质回答的定义发生了变化。”

知乎的运营,一直都在追求优质的回答。这是大家有目共睹的。但是,何为优质呢?
1、大家都赞同?
2、运营的员工有偏爱?
3、名人?
4、能够激发更多的讨论?
5、具备足够的深度和长度?

这些都可能不是优质的判断依据,但是也有可能被用来判断是否优秀。

我担心的最大的问题,就是知乎运营团队,在何为优秀的判断上,默默的,不自觉的,有意无意的,向KPI低头,向热闹低头,向名人和大企业低头

最终,从一个一流的问答社区,变成为一个二流的,却标榜自己是一流的问答社区。

在大约2年以后的今天,我想:「自己的那些担忧,几乎都已经成为了现实」

二忌:以人治代替法制

在一个虚拟社区,谈论法制,是不是有点大题小做呢? 之前我写过一篇给知乎的公开信:《规则与例外——写给知乎的一封信》后来,这封信还在知乎引发了一些讨论:你对《规则与例外——写给知乎的一封信》一文有什么看法呢?

但是,我在文中提到的所有问题,知乎团队一!个!都!没!有!解!决!

依然是区别对待,依然是顾此失彼,依然是各种潜规则。

这次的张公子退出,终于引起了知乎团队的重视,但是:他们的反应只会让其他知乎用户心凉!

@葛巾 算得上是知乎大神了吧?结果,照样会有没有受到重视的感觉,悠悠的叹了一句:「原来要张公子怒了,你们才会担心啊……」

而我之前的愤怒呢?我很愤怒! – 禾厶口土木曹 – 知乎专栏

我在文章里喊到:@黄继新@周源 @顾惜朝 请回答我的问题!

他们没有一个理我。我还给他们都发了私信呢!

今天,周源说:对不起,来晚了

我自然要小声的问一句:「您的私信是开放的!您的私信阅读与回复率是多少?」

你们忙,大家都理解,但是你们如果不能一视同仁,就不会得到任何理解。被你重视的,会感到失望。被你们忽视的,会更加失望!

@路小佳 明确指出:“知乎并非因为张佳玮的不满才站出来,事实上,我们在乎每一个人”,这句话,看了很不舒服,此地无银。我想,这就是大家的心声了。

三忌:指手画脚的投资人

其实,前两忌,还算是「可治之症」,这第三忌,才是「不治之症」!

大约是两年前,我曾经一口气喷了一篇文章:《要创业,就别听VC的!

其中有一句话是这么说的:「创业团队不要为了VC的建议而动摇,VC只是出钱的人,甚至不能算是业内人士,他们的建议,未必是为了你事业的长远发展,也许也许只是为了他能够更快脱手。」

但是,在知乎我们经常会看到@张亮 的身影。他的身份是创新工场的投资总监,但是却常常以知乎负责人的身份出来发表各种言论。这次张公子发怒,他居然来了一篇:知乎的耻辱 – 逆旅 – 知乎专栏

在文中,以一种居高临下的口吻说到:「刚才我已经跟周源通电话了,也跟相关产品经理沟通了,没废话,知乎会尽快改进审核相关的产品体验。别的话不说了,开始改,必须改好。」

还说:「如果你对知乎的某个用户体验不满,请留言或给我私信,谢谢!我会督促他们,没有任何借口。」

这就是一个典型的不守本分的投资人的形象!

你只是投资人,不是客服,不是公关,不是CEO,不是产品经理,不是知乎团队里的任何一员!

你只是一个投资人!但是你的手伸得太长了!不但给周源打电话,而且直接跟相关的产品经理沟通。 不但在私下插手此事,而且在知乎团队给出官方回应之前,就写什么《知乎的耻辱》!

你管得太宽了!

你管得太细了!

你管得太多了!

言尽于此吧,张亮以前的那些指手画脚的事情,我也懒得再一一去翻了,反正他没少干!

以上就是我的最后一次劝告,下不为例!

This entry was posted in 知乎.

【知乎专栏】企业开源杂谈

这篇文章的缘起,是一个朋友的约稿。但是,这篇约稿,实在是太难写了。打了3个礼拜的腹稿,还是一肚子杂乱的思绪、感想以及不吐不快的槽!可是文章不能这样来写呀,必须得有点条理啊。我试着按照某种“介绍–总结–反思–分析–杂谈”的逻辑来写吧。

  • 介绍

我曾经供职的公司,我在其中负责“开发者关系管理(DRM)”的工作,而运营一个公益性质的开源社区,是这个“DRM”工作的其中一部分。简而言之,公司的目标很简单,办一个开源社区,在技术圈子里树立良好的形象,以便改善公司与外部开发者之间的关系。

  • 总结

基于这样的目标,我们的开源社区不会有太多的KPI压力,纯公益性质的网站,给公司带来的利益都是间接的(或者说难以衡量的)。在公司发展顺利的时候,老板不妨睁一只眼闭一只眼,随便我们去折腾。一旦公司的战略发生调整,业务出现转向,这种“锦上添花”的工作,对于老板而言就是可有可无的。

归根结底,公司与外部开发者保持良好的关系,究竟能够给公司带来多大的利益,是没法说明白的。直白一点讲,我们虽然在做的是开源技术社区,而实质却是在做公关类的工作。而针对外部开发者的公关,往往无足轻重。

所以,如果企业开源不能给企业带来切实的利益,那么这种事情就肯定会昙花一现。

  • 反思

出于对于开源事业的持续的热情,我也一直在反思,如何才能确保这个事情能够长久的做下去,也许有以下几点需要考虑:

  1. 企业开源,必须自顶向下,最高领导必须切实赞同。仅仅是“随便他们去玩玩吧”是不够的。而最高领导的切实赞同,又取决于一个企业是否真正意识到(并且相信)开源能够给企业带来好处。较之专利与基础研究,开源对于企业的价值,会以更加(复杂、交错、间接)的方式体现出来。由于涉及到不可控的外部交流,开源甚至是有利有弊的。这使得企业评估开源为企业带来的利益,更加困难。所以,在获得实际的回报之前,对于开源,是需要某种信仰的。
  2. 企业开源,必须持之以恒,个人玩开源,随时可以加入,随时可以退出。Free Software,不仅仅是软件自由,人也是自由的。但是,企业开源,绝对不能玩玩而已。高兴的时候办一个网站,没兴致了,就随手一关。这种事情,对于企业的形象和声誉,是有相当大损害的。
  3. 企业开源,必须在内部找到持久的动力。开源不仅仅是开放源代码,更重要的是由此引发的企业技术文化的演进,如何在企业内部传播并推进一种开放、活泼、自由、创新的文化,是必须在制度层面解决的大问题。
  • 分析

开源当然会为企业带来价值,这篇文章不去多谈那些虚幻的、文化层面的、企业形象层面的价值,谈点实际的内容。

  1. 操作系统开源,以Google的Android为例。由于Google的开源政策,Android在移动领域的占有率一直在持续上升,则将为Google移动领域的领导地位,奠定坚实的基础,由此带来的价值,简直是难以估量的。
  2. 平台类开源,以Firefox和Chrome为例,作为上网的入口,浏览器的市场占有率对于企业的利益,有着战略级别的影响,如果不以开源的方式来做,IE的地位几乎是不可撼动的。
  3. 语言开源,Google开源了Golang、爱立信开源了Erlang、Sun开源了Java,其中以Java占据了最为广阔的开发者市场,可以毫不客气的说,如果没有Java,Sun早就不存在了。而Sun公司围绕Java进行的一些开源项目的开发和推广,也是Sun公司能够持续扩大Java影响力的关键。
  4. 参与或赞助开源项目的开发,由于企业原本就会用到某个开源项目,比如Linux、比如OpenStack、比如Hadoop,比如MySQL。企业的内部员工,会参与到这些开源项目中去,共享全球开源协作的开发成果,同时也对这种重量级的项目施加符合自己利益的影响。
  5. 被迫开源,由于授权协议(License)的限制,企业在使用、修改、分发了某个开源项目时,必须遵守相应的开源协议,以避免不必要的利益损失和形象损失。

当然,企业参与开源的形式还有很多,以上5种,可以说是比较能够向CEO们讲得明白的价值。任何企业,如果不能找到参与开源带给自己的价值,他们的开源总归是无法长久的。

  • 杂谈

从我个人而言,我肯定相信开源能够给参与其中的每个人、每个企业都带来回报。但是要说服具体企业相信这些,依然是困难的。

从由易到难的步骤而论,我想建议大多数企业,考虑以下的路径:

  1. 依法开源:那些必须开源的,别再藏起来了
  2. 赞助开源与开源社区:找到对自己公司有价值的开源项目以及开源社区,哪怕仅仅出于公益,也赞助一些。
  3. 鼓励员工参与开源:从这个阶段开始,会收到“变化气质”的效果
  4. 自身产品、项目开源:这一步需要慎重选择
  5. 主导某些开源项目或开放标准,这个就是至高境界了。。。

【知乎专栏】产品经理最大的挑战是什么?

之前我写了两篇关于产品经理的文章,一直有朋友在下面留言,谈到产品经理背黑锅的问题。

是的,我知道很多时候,产品经理其实是在背黑锅,他们遇到了几乎不可抗拒的挑战:懂产品的老板!

但是,我缺乏一个好的例子(靶子),所以我直到今天,才幸运的找到了一个:你是第五只猴子吗?

这篇文章的作者是:金山网络的CEO,傅盛。而他提到的产品,是目前已经非常成功的“猎豹浏览器”。文章各位不妨自行去看,我接着往下说:

另外一篇有趣的文章,也是关于五只猴子的:“湿猴理论”:被科学的寓言

所以,果壳网的谣言粉碎机,早在两年以前,就已经粉碎了这个关于猴子的谣言。文章各位不妨自行去看,我再接着往下说:

我决定当场给大家编一个寓言:一个公司里有5个产品经理和一个老板,每次那个最不听老板话的产品经理,就会被痛骂,然后直至被赶出公司!不断的有新的产品经理加入这个公司,经过一轮又一轮的筛选,剩下的5个产品经理,都是那种最能够听话的产品经理……

大家觉得,这个寓言如何?

老板其实也不难当,平时忙没空多关注那么多细节,挑中一个细节狠狠的骂一顿。我听说,有一种帝王心术,叫做小题大做,或者叫做敲山震虎,或者叫做见微知著,或者叫做明察秋毫。总之,挑一件小事,狠狠的说,狠狠的批,狠狠的深挖思想根源,狠狠的斗私批修。于是,下面的人,就个个战战兢兢地意识到老大无法糊弄,甚至根本不听我辩解……

总结陈词:对于产品经理而言,最大的挑战是“在这样的老板手下,做出有价值,有意义,被用户认可的产品来。

题图:某个看起来像Boss的人物…

【知乎专栏】测试,这个专业还有价值吗?

一直想写一写我对于测试的看法,较为远的一个原因,是因为左耳朵耗子(陈皓)的一篇文章:《我们需要专职的QA吗?》,以及段念的一篇回应《对《我们需要专职QA吗?》的回应

一个比较有趣的现实是:因为陈皓的个人经历,他遇到了一些非常糟糕的QA,结果发现这些活还不如开发自己来干,进而推出“专职的QA是不需要的”。甚至,他将这个结论,推广到了整个行业。

而与陈皓正相反,在我的职业生涯中,遇到了一些非常优秀的测试/QA,这使得我坚信:优秀的测试人员/QA,是开发团队必不可少的一部分。

首先谈谈我对QA进阶(层次)的看法:

  1. 最弱的(否则无法入行):能够发现看起来不对的地方。
  2. 重现bug:能够确定,某某问题在某种特定的条件下,可以重现。
  3. 分析与诊断:能够向程序员提供建议,这个问题,可能是由于什么原因造成的。
  4. 举一反三:能够基于对系统的了解,发现某个bug,进而推论可能存在或需要检查的其他方面。
  5. 预防与预警:帮助整个团队,提升质量意识,降低bug产生的可能性。
  6. 为整个团队,注入追求质量的气质

这里所谈的层次,都是围绕质量而言的,各种测试的手段,工具,方法,架构,都是他们必须在日常研究的内容,而这些研究,是为了帮助他们自身、以及整个团队,在保证质量时,做得更快、更好。

在我们的团队开发实践中,我发现依照个人的性格、偏好以及相应的分工:

  • 有些人喜欢深入研究“效率提升、性能提升”方面的课题;
  • 有些人喜欢深入研究“架构优化,代码重构”方面的课题;
  • 有些人喜欢深入研究“各种极限情况下的系统漏洞”;
  • 有些人喜欢深入研究“用户体验相关的各种优化”。

在不同的领域,都需要深入的积累、探索与创新,并不是仅仅空喊一句:“人人都应该负责XXX”,就可以解决的。

本质上而言,我之所以反对陈皓的观点,是因为未来的趋势,并非越来越综合全面,恰恰是越来越分工协作;以前的程序员,从设计、架构、前端、后端、测试、发布、运维,都可以一人完成。但是,从程序员这个角色,已经分化出:产品经理、UI、UE、前端工程师、后端工程师、DBA、运维、测试等诸多角色。

不能因为跟某个工种合作不顺利,就收回来自己干,如果是这样,岂不是都要收回来?

所以,我的观点是:我们需要更加优秀、更加专业、更加有价值的测试,而非取消这个专业!

题图:不管什么颜色的猫,只要抓到老鼠,就是好猫。但是没有好猫,难道就让狗去抓老鼠?

【知乎专栏】聊聊我理想中的产品经理

不出意料的,昨天的那篇专栏文章,果然还是收到了一些批评。比如直接骂垃圾文章的,说我太过片面的,当然,有一句话我承认:昨天的那篇文章,的确没有什么营养,全是负能量,没有正能量啊!

所以,我决定修改自己的写作计划,来一篇有点正面的文章,聊聊我理想中的产品经理。或者说,作为一个开发人员,我希望能够与怎样的产品经理合作。

1. 见多识广,但是并不随波逐流

是的,我希望他能够了解非常多的其他产品,其他企业,甚至不相干的各种行业的其他产品,不但熟悉人家的功能,更加理解别人的产品背后的逻辑和意图。

但是,千万不要走过来对我说:我就要一个那个XXX的样子,只是颜色改一改。再换一个Logo。

2. 好奇心,理解力

一个优秀的产品经理,应该对各种事物都保持旺盛的好奇心。这个是怎么做到的?是怎么运转的?如何才能做成这个样子?

如果他对技术有各种各样的好奇心,技术人员通常都会很乐意给他做一些深入浅出的介绍。只要他的理解力足够,他能够越来越明白技术的很多运作原理。

他不需要自己去写代码,去调试程序,但是:越是理解技术以及技术背后的原理,将有助于他设计更加合理的产品。

更由于新技术的层出不穷,一些原本不可能的点子,现在也变得可能。如果不及时了解技术的进展,产品的思路要么过于天马行空,要么过于死板守旧。

3. 知其然,更知其所以然

产品经理,当然会有很多新鲜的想法,但是这些想法有没有价值,不能上来就对我说:“我也不清楚这个功能有啥作用,你先做出来,咱们看看效果。”

一个优秀的产品经理,不会像瞎猫抓死耗子,碰到了是福气,碰不到是运气。一个产品,上线以后,成也不知道是怎么成的,败也不知道是怎么败的。甚至连怎么算成,怎么算败,都搞不清楚。

4. 以其昭昭,使人昭昭

如果产品经理的脑子不好使,表达能力又弱,那就真的:“说起来全是泪”了。一个优秀的产品经理,必定是思路非常清晰的家伙。一个产品来龙去脉,功能架构,服务对象,潜在的逻辑全都很清楚。一旦问他问题,他也能够干净利落的描述出来。

如果有产品经理对我说:你照做就行了,不需要管为什么。我就会大声的骂回去:你自己知道为什么要做这个吗?你说得清楚吗?

实话实说:开发人员,也很有兴趣了解他为何要做这个功能。基于真实的理解,他会做得更好。

5. 节奏感,方向感,使命感

不要像没头苍蝇,不要东一榔头西一棒。做事情,有步骤,有计划,有目标,有原则……

不好意思,我在YY。如果真有这样的产品经理,我愿意降级降薪,加班加点的帮他干。因为,与这种靠谱的产品经理合作一起做产品,我的未来会很靠谱!

题图介绍:一头很酷的狼!

【知乎专栏】产品经理,为什么大家都在骂?

在我不算太长,但却相当丰富的职业生涯中,我与很多产品经理,有过合作。在早年的时候,他们甚至都还没有自己的名称,往往被称之为:“做策划”的、“写文档”的、“画原型图”的。

到后来,有几件大事导致产品经理这个岗位越来越热,一个是乔布斯作为产品经理的神级偶像,被推上神坛!另一个是类似《人人都是产品经理》、《结网》这样的书,将一条“光明大道”铺在了每个年轻人的面前。

比较凑巧的是,最近我的朋友路盛华在知乎上提了一个问题:懂技术和设计是一个优秀产品经理的必要条件吗?我的回答如下:

他们甚至应该懂得更多!

如果一个产品经理,不懂技术、不懂设计,却信心满满的开始“写他的产品文档”,我简直无法想象他能够策划出什么产品来。

足够懂技术,才能够清楚:他的产品将会如何被实现。
足够懂设计,才能够清楚:他的产品将会如何被呈现。

这些都不懂,他的产品就是一团模糊的东西,这样的产品经理,通常脑子里也是一团浆糊。

结果,令人惊讶的收到了一些反对意见。比如这条:

哦对了,这么说,那个《结网》的作者王坚,也不懂技术,那本书一定是忽悠人的。还有,我和很多产品总监级别的人求教过,我问他们,产品究竟需不需要懂技术,他们都只给了一致的答案,不必须要懂技术,一样可以做好产品,额,莫非他们的成功另有妙招?

《人人都是产品经理》我看过,《结网》我还没有看过,出于好奇,我还特地去找来看了一下。原文如下:

我不懂研发,确切地说,不会写c语言代码、不会写PHP……。虽然我不能使用这些技术,但我知道这些技术大概都能干什么、其明显的局限是什么。这对于一名产品经理而言,可以算是及格了,所以我可以成功应聘进入腾讯,并且领导过产品团队。

可见,懂研发技术不是成为产品经理的必要条件,不要因为不懂研发技术而放弃对这个职业的考虑。

看到了吧,这行的门槛还真不高!即使是这样不高的堪称及格线的门槛(知道这些技术大概都能干什么、其明显的局限是什么。)还有人会曲解为(不必须要懂)。

而且,更加惊人的是:很多产品总监级别的人都告诉他,不必须要懂技术。

这就是为什么:大家都在骂产品经理了!真的有很多、很多的产品经理认为:要当好产品经理,有好的点子就可以了!懂战略就可以!学会Copy to China就行了!细节就能够决定成败了!用户体验才是最重要的!

好吧,进入正文,谈谈我对产品经理段位的看法。

  1. 不入流的:我有一个Idea(注:此处是英文单词),你们能给我实现出来吗?
  2. 末流的:那个产品不错,我们抄一个吧(有一个产品经理叫许朝军,就说过:咱们那是虔诚的借鉴)
  3. 三流的:你看我这个滑动效果,是不是很棒!(一个看了太多Apple文案的果粉,会认为Apple最牛的地方,在于各种细节。)
  4. 二流的:我要这个、这个和那个,这些功能点很重要,我希望能够下周一这些功能可以上线(通常这些话他会在周五告诉我,而且需求描述还有自相矛盾的地方)
  5. 一流的:(抱歉,我没见过,编不出来)

好吧,说点正儿八经的话:成为一个优秀的产品经理,是非常困难的,需要非常广泛的知识面、非常强烈的好奇心以及非常强大的执行能力。但是,现在成为一个产品经理的门槛,实在太低了,简直比成为一个程序员的门槛还要低。

低门槛导致的鱼龙混杂,甚至劣币驱逐良币,才是产品经理被很多人乱骂的根本原因。

对于有志成为产品经理的朋友,我就送你一句话:如果想要不被骂,你要学习非常非常多的东西,还要非常非常努力,才有可能!

题图介绍:哈士奇团体照

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》