加班与效率

关于加班

认为加班是公司的核心竞争力,或是超越对手的手段,是一种相当 Ridiculous 的想法。这说明管理者们已经想不到自己公司的核心价值了

是的,这些靠堆功能没有灵魂的产品的价值就只剩下比谁跑得快了。他们愚蠢和思维有限的大脑里已经区分不出来,“跑得快”和“跑得好”的差别了。产品的发展不是短跑,而是长跑,甚至更像是登山,登山比的不是快,而比的是策略,比的是意志,目的是登顶。并不是谁一开始爬得快谁就能最先登顶的,你往往被超越的时候都在后半程。对于一些危险的雪山来说,登顶的人通常都是要做好非常很充分的准备,并且在登山的过程中学会如何保留体力,学会如何步步为营的,从来不强行登顶。

  • 条件受限是好事,因为条件受限可以让你小材大用,让你没有办法再用蛮力来完成工作,让你必需去思考使用知识密集型的解决方案来更聪明的解决问题
  • 工作狂往往不得要领。他们花大把大把的时间去解决问题,他们以为能靠蛮力来弥补思维上的惰性,其结果就是折腾出一堆粗糙无用的解决方案

就像人肉手动的织布机一样,当面对大量订单的时候,一个简单粗暴的方法就是拼命地加人和拼命地工作来换取更大的生产力。只有你在人手不够或是人力成本太高的情况下,你才会去想是不是可以优化一下工具,制造一个更有效率更有生产力的工具。

在中国,劳动力的成本不高,而管理者们的智力和能力有限,所以,在这个环境下,尤其在KPI和数字的重压下,管理者们是非常非常容易想到需要靠加人或是加班来提高产能的。所以,他们放弃了知识密集型的创新,而采用了劳动密集型的简单粗暴的方式,长期下来,导致了自己再也不会思考,导致了只会使用人肉解决问题。

于是,当全自动化的织布机出现的时候,这种劳动密集型的公司分分钟就成为了历史。这样的例子太多太多了,看看历史就知道了。

当然,有时候,我们需要冲刺还是要适当偶尔加班的,但这绝对不应该是常态和长期的,不然,这必然是一种饮鸩止渴的行为。

另外,我还要多说几种情况:

1)如果你的员工就像在《软件公司的两种管理》中所说的,像Widget Factories那样,净是些X型的人的话,那么,你也只有使用加班和加人这种方式,就像长城和金字塔的建设过程一样,就像富士康一样,你的团队本质是不会思考只能用鞭子去抽他们的方式去管理。于是,你也只能用“狼性”来呼唤你的员工像那些低智商的野兽一样的行事。

2)有时候,我们需要去“卡位”,需要很快地去实现一个东西占领市场,这需要加班。就像Win95和Intel的奔腾芯片的浮点数问题一样。但是千万不要忘了,你在卡完位后,得马上把你产品的质量搞上去,不然,你一样会死得很难看。(Windows是有两个团队的,一个团队是用来占领市场的,另一个团队是安心搞发展的)注意:“卡位”从某种程度上来说应该是一种有价值的事,但我们依然要思考是否在用蛮力行事。

3)另外,有的人工作就是生活,生活就是工作,所以,对他来说,这不是一种工作,而是一种事业。我认可这样的精神和热情,但是,我还是想让这样的人反思一下自己,有没有用一种更为聪明的方式来从事自己的事业?而不是用蛮力。

无论上述的哪种情况,我们都可以看到,只要你进入了劳动密集型,靠人和靠加班来解决问题,并沉迷并深 陷其中不能自拔,那们,你终有一天会玩到尽头的。

关于效率

很多人不知道什么叫效率,他们以为效率就是:单位时间单位人数下干更多的活。这是错的!效率不是比谁干的活多,而是比谁干得活有更大的价值。效率的物理公式是:有用功/总功。换句话说,效率就是:单位时间和人数产生的价值。所以,提高效率,并不是加人,也不是干更多的活,而是,你这么多人干出来了多少有价值的东西。

有了公式,我们也就知道怎么来提高效率了。

1)增加有用功

  • 你得多问问你的需求方,为什么要加这个需求?干这个事到底有多大的价值?能让多少人受益?
  • 你得多问问你的需求方,能不能稍微简化一下需求,这样可以让我付出的努力更少一些?
  • 你得要多去思考一下,你是在干一个建筑队的活呢?还是在干一个装修队的活?
  • 你得要多去思考一下,业务上和用户的最大的痛点是什么?

关于增加有用功,再说两点:

  • 像乔布斯那样,告诉你的产品经理或是业务方,你现在提的10需求,我只能做3个,会是哪3个?为什么是这3个?有用功的来源不是拼命做需求,而是砍需求。
  • 关于创造价值,我们要干的不是像百度的竞价排名那样,把钱从别人口袋里搬运到自己的口袋里,而是要像英国工业革命或是硅谷那样,把价值真正的创造出来

2)降低总功

  • 你得多问问自己,你有多少时间是在干一些支持性而不是产出性的工作?
  • 你得多问问自己,有没有残酷无情地减少重复劳动的劳动密集型的工作?
  • 你得多问问自己,自己的管理者和员工的能力和素质有没有在降低你的团队执行的成本?

3)形成合力

有一个很不错的产品经理对我说,他看了南京那两个小女孩被饿死的消息,感到很震惊。与之有关联的每一方都说自己尽力,但是最终结果人还是饿死了,你几乎不敢相信这是真的。

但是,类比一下我们的项目,这种事似乎又发生在我们的公司当中,尤其是大公司中。每一个团队都说自己尽力了,结果项目就是没做好,底层团队说自己只干底层,已经尽力了,前端说自己只负责前端,也尽力了,后端说自己只管后端,不管前端和底层,运维说对于这样的设计和部署自己也尽力了,产品经理,运营都这样说,自己尽力了。你会发现,你几乎很难批评他们,因为他们的确如他们所说的那样,把他们自己的那块都做得很好了,而且的确做得很好了。但是,最终的结果却是:整个产品问题很多。

所以说,效率不是每个团队各自的效率,而是整个团队对整个产品负责的共同使命,这样才会现整体的效率。没有整体的效率,只有个体的效率,最终也等于没有效率

时间: 2024-10-25 15:16:09

加班与效率的相关文章

转载:关于加班和效率

转帖:http://coolshell.cn/articles/10217.html 微博上看到了这么一个贴子,就像以前在<腾讯,竞争力 和 用户体验>中批评过腾讯说自己的核心竞争力是员工加班一样,我顺着Winter的回复也批评了一下这个微博—— “靠加班超越对手?!劳动密集型么?我要是对手的话,我就来趁机挖人了,直接摁死你……//@寒冬winter: 当一个管理者的智慧无法衡量一支团队的产出的时候,他就会把“工时”当做最后的救命稻草,死死抱住——这是他唯一听得懂的东西了.” 然后,@玄了个澄

聊聊IT行业加班的问题

IT行业(包括互联网行业)是快速发展的行业,有时候一家公司同时可能要开发多个项目,并发进行,在公司开发人员相对固定的情况下,要想在指定的时间内完成项目谈何容易. 项目多.任务重.需求的不明确.技术难关的挑战.开发人员技能水平有高有低.各部门各职位之间的沟通时间成本等等这些因素均会造成项目很难在指定的时间内完成,公司为了项目早点完成.早点上线.早点投入市场,会让技术部门加加班赶赶进度. 一般来说,要加班的话,与项目相关的人员均需要加班,这其中最有可能加班的是开发人员(包括前端开发工程师.后端开发工

十. 加班等于团队建设?

摘要:在IT界,加班是不可避免的事情.但是,加班的方式和心态,将会影响加班的效率和加班的效果. 健生干货分享:第10篇 在移动互联网的日常工作中,不能不提的是加班. 总体来说,加班不应该过多.因为它不仅会损害员工的身体,更为IT业贡献了数不清的光棍. 因为加班,使IT从业人员的交际圈范围少,总是认识那么一丁点的妹纸:因为加班,使IT从业人员的身体素质不高,看起来不健康阳光:因为加班,使IT从业人员没法多参加社交活动,幸福感降低. 我看到过一种更忽悠的说法,说是经常加班,可增强团队的凝聚力,是团队

宝宝 : 天天加班, 有意义吗?

近几日,各大头条非 "宝宝"莫属,当然 宝宝 一词我是不喜欢叫的,感觉就是妹子卖萌用的.我从来不叫宝宝, 也不称呼自己:宝宝饿了(饿你妹啊), 宝宝很桑心... 本来我不想搭 宝强 的顺风车的,毕竟娱乐圈的东西,咱们it屌不懂.我这里也有很多顺嘴的段子,但我就不发出来了,毕竟UC.某讯.某浪的任何新闻,任何留言都是各种老王 老宋的段子.看多了也就觉得世人更喜欢调侃和娱乐而已! 但我也算一个傻根粉丝,毕竟:形象好.气质佳,让人看了笑哈哈!国内喜剧没了你真不行.所有人的损失!(其实我也占了

如何在python脚本开发做code review

在软件项目开发中,我们经常提到一个词"code review".code review中文翻译过来就是代码评审或复查,简而言之就是编码完成后由其他人通过阅读代码来检查代码的质量(可编译.可运行.可读.可维护.可复用),这些性质都比较抽象,但是一般都可以通过以下的检查点来实现: 检查代码的命名方式是否符合规范,代码的可读和可维护必须要求所有参与编码的同事使用的命名有统一的规范(注意每个人有自己的代码风格,但是要符合可读性的代码规范): 检查代码的注释,注释一般包括:1.类要有类用途和使用

[读后感]从Code Review 谈如何做技术

还有9个电,争取把这篇发出去,里面有太同共鸣,只不过之前没能写出来, 一是文笔有限,总结不够明确,本文至少总结出了我想总结的6个观点,看来总结能力还是要提高: 二是不确认这是对的,所以不敢贸然写出来,看来奔四的程序员都有这些共同的想法,并非我一人,还有许多人... 着实说,代码审查,以前想过,但没做过: 代码审查确实很不错,不懂开发的测试人员其实从某种角度是用于粗暴地替代代码审查, 结果可知,花在修复 Bug 上的时间要比编码时间多 N 倍, 我想我们以敏捷方式来对付它,逐层皮儿地扒着做,做完一

国内一些大型软件企业现状

过去,国内有一些大型系统集成的软件企业,早在10年前他们做的主要是商业智能,现在转向所谓高上大的大数据产业.一般研发中心都在北京等一线城市,在各个省市有自己的分公司或项目组.当然他们都通过了行业相关资质.如CMMI-5,ISO9000,但是实际上只是个表面工作,都可以用钱买的,只是为了资质.在各省市的项目组仍然是混乱的软件过程,从总公司拿一套系统的源代码过来,修修改改,就强行给客户上系统,客户不清楚细节,后面发现了许多BUGS,又开始疯狂改BUGS,最后变成项目到处扑火.这和软件危机差不多了.试

皓哥浅谈工程师文化

注:本文来自酷壳博主陈皓个人网站<什么是工程师文化?>,写得非常好,国内的确拥有工程师文化并落实到位的公司极度匮乏了! 四年前,我在QCon上演讲了一个<建一支强大的小团队>(整理后的PPT分享于这里)提到了工程师文化,今天,我想在这里再写一篇关于工程师文化的文章,一方面是因为我又有了一些想法和体会,另一方面,因为我也正走在创业的道路,毫无疑问,要建一个有浓重的工程师文化的团队或公司,所以有必要把自己的相关想法形有成白底黑字的“字据”,以供打自己的脸——“要是未来没有做到,这篇文章

从“黑掉Github”学Web安全开发

Egor Homakov(Twitter: @homakov 个人网站: EgorHomakov.com)是一个Web安全的布道士,他这两天把github给黑了,并给github报了5个安全方面的bug,他在他的这篇blog——<How I hacked Github again>(墙)说明了这5个安全bug以及他把github黑掉的思路.Egor的这篇文章讲得比较简单,很多地方一笔带过,所以,我在这里用我的语言给大家阐述一下黑掉Github的思路以及原文中所提到的那5个bug.希望这篇文章能