放弃加班赶工吧,其实得不偿失

  其实早在75年之前,大多数的行业就已经放弃了去加班赶进度。而数不清的行业经验和研究事实也已经证明了:如果要想完成工作,那么加班赶工其实是成本最高的做法。

  缘起

  在2004年,某家国际电子游戏公司员工的家人以Ea_spouse为名,在某个网站上发布一篇文章,并且讲述了其配偶因为高强度、长时间的加班,导致对自己的身体健康还有家庭生活造成了很不好的影响。一石激起了千层浪,有关于电子游戏开发行业人士生活质量的话题再次引发了大家的热烈关注和讨论。Ea_spouse就收到了上千个回复,而且此事也很快被主要媒体跟踪报导。而通过网络,有上千人参与道了这个自发的大规模讨论,讨论内容涉及到了强制加班、工作效率、怠惰、工会、诉讼和对很多公司的控诉等议题。

  我现在已经做了二十多年的软件项目开发与管理工作。而在过去的每一年,做过的每一个项目,都会让我更加的坚信:加班赶进度——“赶工”——是一种高成本、低产出且极具破坏性的工作方式。“工作持续时间越长,工作效率越低”已是常识了。然而随着时间的推移,我已注意到:由于过多额外加班导致工作效率下降的速度,要超过大多数软件行业管理者的认知。随着调查深入,我惊讶地发现我并不是第一个认识到这一点的人:近一个世纪以来,传统工业的工程师们对于我所观察到的问题早已达成共识。

  历史

  1908年,工业效率研究先驱 Ernst Abbe公布了他的研究结论,即每天的工作时间从九小时减少到八小时,其日产出量会增加。而他也不是第一个注意到这件事的人。早在1893年,William Mather在Salford钢铁公司(Salford Iron Works)就已经采纳了每天八小时的工作制。在1909年,Sidney J. Chapman发表了《工作实践》(Hours of Labour)。他在文中描述了每天的工作小时数与工人的生产力之间的变化。下文会对其结论进行详细阐述。亨利•福特在1926年大张旗鼓地采纳每周40小时工作制,至少已经进行了十二年的试验让他确信:将每日工作10小时调整为8小时,并把每周工作六天改为五天,实际上会增加总产出并降低生产成本。福特大肆宣扬缩短工作时间的社会效益,并强调增加消费时间对每个人都有好处。但其核心观点仍是:减少当班时间可以带来更多产出。

  我发现很多组织(如商业、大学、工业协会和军事单位等)进行的研究结果都持有同样的基本观点,即对于大多数人来说,“每天工作八小时、每周工作五天”是保证高产出和低身心消耗之间的最佳平衡点。在十九世纪的三十年代至五十年代,类似研究进行过上百次;到了六十年代,40小时工作制所带来的好处在美国企业界已被无可争辩地接受了。1962年,商业协会(Chamber of Commerce)甚至专门发行了一个小宣传手册,来称赞减少工作时间所带来的生产率提高。

  然而,不知何故,硅谷却把其抛在了脑后。Ea_spouse写到:

  “现在的强制工作时间是从早上九点到晚上十点,且每周工作七天,基于员工的良好表现,星期六的下班时间偶尔会提前到晚上六点半。平均算下来,这相当于每周工作85小时。”

  实际上,一周有六天是从早上九点工作到晚上十点,还有一天是从早上九点到晚上六点半,算下来是每周工作87.5小时(6×13+9.5=87.5)。可是在工作这么长时间以后,谁还会算得那么详细呢?

  在这一方面,电子艺界与其它高科技公司没什么不同。请希望提高员工生产力且同时让他们保持头脑清醒的人一起来看一下:管理者在工作时间、产出、效率以及生产成本这几个方面做出的假设,以及一个世纪的产业研究如何证明这些假设是完全错误的。

  管理者想要什么?

  当管理层将员工送上“死亡之旅”时,他们究竟想要得到什么呢?我们真的相信EA的CEO想看到员工撅着屁股在办公室里连续工作7×24小时吗?

  管理者想从雇员那里得到最大的产出,是用最少的成本投入生产出最好的产品。不到万不得已,他们不希望为了完成产品出钱雇佣额外的人力资源,从而增加成本。表面看来,要想达到这两个目的,“赶工”好象是最显而易见且合理的方法了。

  假设产出是利用计件方式来衡量的话,没读过上述研究报告的管理者可能会推断:假如一个人在八小时内生产16件产品,那么,他在九个小时内应该能生产出18件产品,在十个小时内可能生产20件。我们可以用下面这个简单的公式来表示这种观点:

  O = X/Y * t

  其中,O是总产出,X是基准时间Y(以小时为计量单位)内的产出,而t是实际的工作小时数。在这种假设前提下,增加时间t是提高产出O的最简方法。在个别情况下,这种假设是有效的,例如只在很短的一段时间里延长工作小时数以便能在最后期限时交付。但是,其它行业的长期试验和研究表明:加班冲刺的极限持续时间比大家想象的要短;而且当达到极限以后,这种冲剌也会陷入困境。

  小时生产率很重要

  对于如何看待“工人的产出”,更现实的方法是考虑小时生产率会随着工作时间的长短发生变化。这种变化有两种主要来源:在一天中最后几个小时里,产生在脑力和体力上的明显疲劳状况;随着已经延长了工作时间的工作日不断增加,脑力和体力的疲劳也不断积聚。

  下面的等式表达了这种更复杂一点儿的情况:

  O = P(t1 , t2 , t3 , … , tn )

  其中,O代表总产出,P( )表示小时生产率随时间(t1-tn)的变化。在这个等式中,P( )是一个函数,不是一个常量。P( )根据工人的不同而变化,因为某些人生产力要高于其他人。P( )也随时间变化,因为人不是机器,在第14个小时完成的工作并不完全等于在第1个小时完成的工作。另外,P( )也会随工人最近的状态而变化,例如,开夜车后的早上与睡了一个好觉后的早上,其工作效率也不可能是完全一样的。

  在1909年Sidney J. Chapman发表的《工作时间》一文中展示了下面这张示意图:

  其中,曲线P表示“固定数量的劳动力(根据每个工作日的小时数)产出边际价值的长期变化值”。OX轴表示一天内的工作时间,OY轴表示产出的价值。在OX轴的n点上,也就是说如果每天工作n个小时,其总产值是图形Onda的面积(详情请参见 http://www.worklessparty.org/timework/chapman.htm)。可以发现:曲线P的高度就代表了工人的工作效率(每天在给定的工作小时数下,每个单位时间的产出)。

  聪明的读者已经注意到在点b,工作更多小时不会创造更多的价值。而且在b点以后,每多工作一个小时,产出反而是负值。怎么会这样呢?

  Chapman的工作曲线图假设给定工作小时数的工作日会持续一定的时间。因此,它将每天的疲劳状况和长期的疲劳累计统一在一个模型之内体现。首先,小时产出率的下降反映了在接近一天工作结束时,疲劳效应对工作质量和数量上的影响。但是到后来,每天的疲劳是由累积疲劳复合组成的。也就是说,在头一天加班时间导致疲劳产生的生产力下降,会对此后工作日的小时生产率下降产生叠加效应。

  即便是在一天之内,当精疲力竭的雇员再也无法投入工作时,产出就会停滞不前。如果某个已经变得麻木的雇员犯了灾难性的错误,破坏了前面已经完成的工作和投入资本,那产出就会变成负数。

  就工厂而言,一个工人的生产率会随时间下降。某工人在一个班次开始,可能每小时生产10个工件,而在接近下班时,可能每小时只能生产6个,在这其间,有几个小时可能会达到峰值12个。再往后,其工作会变得更慢,而且会犯更多错误。这种减速和错误最终会使生产力成为零,即花了很长时间才生产一个工件,而到了最后一个总会有点毛病。流水线的管理者很久之前就发现:当达到这种疲劳程度时,会带来较大的失误,并导致更大的成本损失,如昂贵的机器受损,存货被毁,或者工人严重受伤等。

  作为脑力工作者,得到充分休息后,程序员会生产更多高质量的代码,而且bug也会比较少。在开始工作的第一个小时,程序员会逐渐进入状态,接下来的 几个小时是最佳状态。在此之后,我们会感到疲劳,小时生产率也就下降;我们会花很长时间才能修复一个简单的bug,或增加一个简单的特性。而这样的事情如果拿到前几个小时做,可能也就是几分钟的活儿。再恶劣一些的状况—似乎很多电子娱乐行业的公司大部分时间都在这种极端状况下工作—一个过度疲倦的IT技术人员可能会删除很有价值的文件,从而要花费额外的工作去恢复备份;他也可能在回家的路上遇到交通事故,结果在几个月内都无法上班。

  这就是第一课:在一个工作日中,生产率随时间h变化。在前四至六个小时里,生产效率最高。随着时间的流逝,生产率会降为0,甚至会变成负数。

  平衡点在哪里?

  如果在一个工作日内,生产率本来就会随时间下降,而且长时间工作会导致低生产率,那么我们如何找到一种方法来达到最大产出呢,平衡点又在哪里?

  不幸的是,希望量化脑力劳动者的产出是相当困难的。我也希望能给出一个简单的公式,只要代入几个数字,就可以计算得出每个人达到最大产出所需工作小时数。但是我不能,因为即使存在这样的公式,也不能就找到并代入哪些基本数据达成一致。常见软件度量方式,如代码行法或功能点法,要么只是简单收集数字,无法让人信服其价值,要么就是数据很难定义和收集。有用的度量数据,如造成bug数目和修复bug数目等,其可信度也不高,并有可能会被不公平地用于年度考评上,也可能被聪明的程序员利用来算计年终考评或绩效奖金。架构师的产出可以很容易地用某些数据(如模型或架构图的数量)来衡量,但同样很难用另外一些数据(如主观质量、观感,及模型复杂度)衡量。如果用发现的独特bug数来衡量测试人员的产出很容易,但用代码覆盖率来衡量就有点儿难了,假如用发现缺陷的总百分比来衡量就难上加难。

  总而言之,对于团队的产出,大多数公司好象陷入了一种“最小公分母式”的度量。要么用游戏出厂数量和销售量,要么就不用。虽然这些的确是大多数股东所在意的度量数据,但对于生产率的度量完全没用,尤其是每日或每小时的生产效率。

  ◆ 第二课:对于脑力劳动者,生产效率很难量化。

  所以,我们只好同其它行业中进行类比:以下内容来自Work Less Institute of Technology名为《IT行业中的精神物理学》的一篇文章,是对Ea_spouse的回复:

  “这是一个多世纪前,Dr. Ernst Abbe 对德国耶拿的蔡司光学工厂(Zeiss Optical Works)工作时间与产出的调察。Dr. Abbe是工厂的董事,他将工作时间从每日9小时减少到8小时,并详细记录了调整前后每个工人的每日产出,其结果与十九世纪的其他研究一致,即适当减少工作时间确实提高了总产出。”

  Tom Walker指出:

  “产出的增减与工作时间的长短不成正比”好象是每一代人的必修课。1848年英国议会通过10小时工作法案,结果每个人每天的总产出增加了。到十九世纪九十年代,雇主又广泛尝试8小时工作制,不断发现每个工人的总产出仍在提升。“科学管理理论”创始人泰勒 (Frederick W. Taylor)指出减少工作时间会显著增加个人产出。

  在上个世纪二十年代,亨利•福特对工作时间安排进行了多年试验,最终在1926年引入每周工作五天共计40小时,却付六天薪水的工作制度。福特为什么要这么做呢?因为他的试验表明,其工厂在五天内的产出要比六天的产出还多。而在工作制变迁的每一步上(1840s,1890s和1920s),总有些行业人士坚持认为:缩短工作时间会降低产出,使经济受损。

  ◆ 第三课:经过上一个世纪的研究表明,每周五天且每天8小时的工作时间,从长远看其产出将会最大。有什么理由让我们认为:我们这个行业可以不遵守这个规则呢?

  短期的产出又当如何?

  如果每周40小时工作制是收到最多产出的最佳工作时间安排方式,我们能否期待“短期内的延长工作时间”能够有短期的成效?简而言之,从几天到几个月,你通过延长工作时间能够得到多少额外的产出,取决于一个工作日工作多长时间。

  显然,如果在八小时工作制下一个工人每小时生产一个工件,他在十六小时工作制下生产的工件数会在八到十六个之间。这是隐藏在“赶工”背后不那么明显的本质。另外,工人生产率还依赖于其所处状态。

  与每周工作40小时相比,每周工作60小时会导致生产效率下降。刚开始时,这额外的20个小时会弥补生产效率的下降,使总产出增加。但研究表明,当改为每周工作60小时以后,建筑工人的生产率很快就会开始下降。这种下降很快可以感觉到,一周之内就会很明显,而且还将不断下滑。在两个月内,累积生产力的损失会下降到与每周工作40小时的产出同样的水平。同一篇报告引证的研究显示出:每天工作八小时的总产出会高于每天工作九小时总产出16%或者20%。

  所以,没错,“赶工”可在短期内提高产出。但在每周工作60小时的情况下,这个“短期”绝不能超过八个星期。因为从这一点开始,成本耗费会严重超过带来的收益。不仅会失去赶工带来的成果,还会使员工感到疲倦、易怒、情绪难于控制。当恢复为每周工作40小时后,还需要一段时间,他们的产出才能恢复到原来的水平。

  一周如果工作87.5小时会怎么样呢?虽然缺乏确凿的数据,但我估计效率在一个月内将跌至原来的50%,即使每周额外的47.5小时工作(两倍于”正常”工作时间)在最初阶段可能有相当高的产出。

  ◆ 第四课:每星期工作60小时的情况下,由于长时间工作所导致的生产率下降,会抵消几个月超时工作所带来的产出。

  睡眠因素

  在评估“赶工”是否有用时,还要考虑另一个因素:如果工人没有足够的睡眠,他们能保持高产多长时间?

  Gregory Belenky上校是Walter Reed 军队研究所神经精神科的主任。他曾为五角大楼研究如何使士兵在战斗条件下最大化其效率和警惕性。在其1997年的论文《持续作战中睡眠、剥夺睡眠与人体的表现》中,他指出:

  “实验室内研究表明,每连续保持清醒24小时,神智功能下降25%。被剥夺睡眠的个体虽然能够保持认知活动的准确性,但是反应速度明显下降。”

  在我们的研究中,来自第82空降兵团炮火指示中心的团队接受了模拟持续战斗状态的测试,共持续了36小时。在测试开始阶段,当我们要求向一所医院进行模拟开火时,团队还能查看方位图,评估目标状况,拒绝开火请求。到模拟测试后期,他们就无视目标性质毫不犹豫地开火了。

  在进行模拟演习的第15天,每晚睡四小时的炮兵连的成绩仅是每晚睡七小时的炮兵连的三分之一。

  ◆ 第五课:每连续工作24小时,认知能力会下降25%。连续开夜车的人会产生严重的累积影响。

  认知迟钝与错误率

  “赶工”引起生产率下降的重要因素之一就是产生错误数量的增加。尽管大多数错误很容易修复,但还是有一些错误会把从“赶工”中得到的收益消耗殆尽。“赶工”时间越长,相关人员遇到大麻烦的机会就越大。

  程序员、架构师和测试人员能够拿到薪水,不是由于他们拥有发达的肌肉或者什么超能力能把重物从一点移到另一点,而是因为他们的大脑。工作时间越长,或者缺乏充足的睡眠(好比每晚只睡1~2小时)会大大降低他们使用大脑的效率。

  Belenky上校指出:士兵即使每天仅少睡一个小时,后果是“减少了……保持清醒地进行高条理性脑力工作的能力。降低了个体和团队的效率”。

  知识工作者应该感到幸运他们不必担心发生“友军误伤”的问题。

  在《持续减少睡眠会产生严重恶劣后果》一文中提到:

  “宾夕法尼亚大学的研究人员发现:连续十四天内每天只睡4至6小时的研究对象在认知表现方面显示出明显不足,其水平相当于连续三天不睡觉的人。然而,这些研究对象却说自己只感觉有点儿困,并没有意识到他们的状况有多糟。”

  在2005年1月的《洛杉矶时报》上,Karen Kaplan有一篇名为《瞌睡的医学院实习生成为马路杀手》的文章:

  “研究表明,在21个小时内没有睡眠的司机,其状态相当于血液内酒精含量检测达到0.08的人,而0.08是美国对非营利性驾驶司机进行血液内酒精含量检测是否超标的法定界限。”

  令人感到讽刺的是,大多数软件公司会解雇一个工作时间喝酒的人,却能毫不犹豫地将今年最重要的项目交到由于缺少睡眠(相当于达到法定司机酒精含量超标标准)的人手里。事实上,是他们要求这些人在“违法醉酒状态”进行工作的,并以此作为雇员被继续雇佣的条件。

  带来的风险很现实—引发的错误真能导致灾难发生。在Dr. William Dement写的《睡眠的承诺》一书写道:

  “1989年3月24日的夜晚清冷宁静,空气如水晶般透明。埃克森石油公司的油轮离开了阿拉斯加的瓦尔迪兹市,驶向威廉王子海湾。在如此清澈的气候条件下,油轮按原计划放下了输油管道,却没有及时收回。巨大的油轮搁浅,数百万加仑的原油泄漏到海湾之中。……在最后的报告中,国家运输安全委员会 (NTSB)发现,缺少睡眠是事件的直接原因。……导致美国历史上最严重的漏油事件的直接责任人是船上的三副,他在事发前48小时内仅睡6个小时,睡眠严重不足。”

  Exxon Valdez 威廉王子海湾漏油事件

  罗杰斯调查委员会(Rogers Commission)在关于美国挑战者号航天飞机失事分析最终报告中说:在关键时刻的电话会议上,做出发射决策是有问题的。在“人为因素分析”章节提到睡眠缺乏“对此有重大影响”。

  如果由于缺乏睡眠可以导致战斗失利,危害病人,搁浅油轮,引爆太空飞船;仔细想想这会为价值一千五百万美金的游戏项目带来什么?

  ◆ 第六课:错误率会随连续工作时间而攀升,尤其是睡眠时间不足的情况下。最终,失败会找上门来,导致灾难发生。当时间紧且预算投入大时,你真能承担得起这个风险吗?

  这意味着什么?

  意味着生产率下降。在保持每周五天共约40小时工作时间的情况下,工人可以维持生产率。工作更长时间,生产率开始下降。在四天和两个月之间某个时间点上,从加班工作中得到的收益会被小时生产率下降所抵消。在某些极端情况下(当工人无法保证每晚至少7到8小时睡眠的状况下,一到两天之内),效率会直线下降。

  上面的研究内容很多都是来自于工业产业环境,可能有人会认为这些结论不适用那些更多地使用脑力的程序员、架构师和测试人员身上,因为他们与普通的体力劳动者不同。事实上,的确不同,Belenky上校明确表示:

  “与复杂的脑力活动相比,可以说,简单的心理活动、体力劳动和耐力基本不受缺乏睡眠的影响。”

  需要完成复杂任务的脑力劳动者受睡眠缺乏影响比体力劳动者更明显,生产率下降得更快。在知识工作者中,由于过度工作而导致的生产率损失会比普通士兵更早更快,因为我们的工作更受脑力疲乏的影响。

  Ea_spouse想告诉我们,她老公所在团队的工作效率远远低于最佳效率。在老板让他们进行每周87.5小时的超级“赶工”之前,每周工作60小时以上的状态就已持续几个月了。

  二十世纪,在大部分的时间、地点和行业中,让手下雇员这样工作的管理者就被认为是不能胜任其工作。这不只是因为他们威胁到了良好的雇佣关系,还由于他们的错误管理方式将公司的生产力和资产至于危险境地。

  一百多年的业界研究已经毋庸置疑地证明:员工因精疲力尽所产生的错误会推迟计划,损坏设备,增加成本,降低产品质量,最终威胁组织的生存。这是对项目的威胁,也是对其管理者、雇主、每个人,以及其自身的威胁。

  无论如何, 将“赶工”用作长期策略,在经济上是不可行的。延时工作不能增加产出,除非是短期行为。另外,“赶工”也不能使产品更快推出,只会导致产品延迟发布。“赶工”不能提高产品质量,只能使其更糟糕。“赶工”增加了引发重大错误的机会,比如交付会擦除客户硬盘数据的软件,或者删除代码树,或者把可乐洒到最近没有做过备份的服务器中,甚至引起火灾。的确是这样,在“赶工”最后那些睡眼惺忪的日子里,我曾亲眼目睹过前三个后果。第四个后果迟早会发生,大概只是时间上的问题。

  管理者决定赶工,是因为他们想告诉他们的老板“我已尽我所能”。他们赶工,是因为他们评估的是放在椅子上的“草人”而不是那些能开发游戏的“大脑”。他们赶工,是因为他们没有认真考虑要做的工作,或没有考虑做工作的是人。他们赶工,是因为只知道要表现出自己在尽力做好工作的重要性,而不是真正去把工作做好。他们赶工,是因为他们回想到当他们还是程序员、测试人员、“助理制片人”或“副制片人”时,他们也是被要求这样做的。

  但这不是唯一的方法。事实上,很多文献一次又一次地表明:加班赶工是最差的方式。这也是很多行业七十五年前就已放弃这种工作方式的根本原因。管理者、股东和员工都坚信:使用经过时间检验的——每天工作8小时、每周5天——管理实践,大家会因更快、更省地交付更好的产品而获益,而且不会损耗组织的人力资源和在公众中的声望。

  Evan Robinson19 岁进入游戏行业, 在TSR 做程序员。22岁,他已经作为独立程序员给EA 做电脑游戏。之后的二十几年里,他先后在该行业数家知名企业做过程序员、高级工程师、技术主管、工程主管、过程咨询顾问,以及技术专员。Evan 的出版物以及其早期的GDC 演讲确立了他的地位,被认为是业内最佳软件工程实践及最有价值软件开发管理人员之一。目前他住在温哥华。

时间: 2024-10-28 11:31:43

放弃加班赶工吧,其实得不偿失的相关文章

东芝半导体工厂假期将赶工,半导体需求回温?

全球第2大NAND型快闪存储器 (Flash Memory)厂商东芝 ( Toshiba )于近日宣布,因半导体需求回温,故旗下日本半导体工厂将于今年年末的元旦假期期间加班赶工.东芝表示,于去年元旦假期停工8天的姬路半导体工厂今年将不停工持续进行生产;大分工厂今年元旦假期期间的停工天数则将自去年的6天减半至3天. 东芝姬路半导体工厂主要生产马达/PC用电源控制芯片.大分工厂主要生产影像传感器及系统整合芯片 (System LSI). 东芝于10月31日将今年度(2012年4月-2013年3月)半

我从学习计算机到现在(2013年初补充版)

毕业快4年了,这个文章该改改了,我从学习计算机开始(2004)到现在应该还不到8年时间,也许对于很多人来说这个时间较短的了,但是这几年以来对于我来说算是对于人生的改变,从一个地方的小农村没见过电脑考入一个"很戳"的师范大学内部新办的一个软件学院,但是对于当时的我来说只要有大学读就不错了,我也没考虑太多,就决定去念了,当时对于电脑的概念是盲目的,没有任何概念,几乎可以说是一无所知,我还记得和同学一起参加入学考试的时候因为在电脑上面考试,我问他们怎么用电脑,同学叫我用鼠标对着正确答案点,我

如何防止腾讯抄袭?

其实我很早就想写这篇文章了,只是因为想法比较零碎,所以就一直没有成文,但是在这两天,就觉得自己思考得比较成熟了一些,所以就把我的这些想法整理下来,欢迎大家一起来和我进行讨论. 鄙视抄袭和山寨 首先,我必须先表达我的立场,我对抄袭的立场是持BS和痛恨的态度,尤其是对于那些C2C的网站,我非常痛恨这些国外有什么然后国内就山寨什么的做法,甚至那些连界面都不改,像素级的抄袭,就连CSS和img都是一样的,而更有甚者,连图片都链接到抄袭源的网站去了,就是连源代码都抄的行为,比如:腾讯抄新浪的代码,新浪抄t

超时工作不可行

最近在Quora 上看到了一个有趣的问题,What is the best way to communicate to a software development team that they need to work more hours to meet a launch date? 问题原文如下︰ My team has a launch date two months out that we need to hit. Over the past year I've been comfor

想成为优秀的程序员这些码德不能缺

我把这些看成是作为一个程序员的基本素质,多数是编码之外的事情: ●代码每天备份:(预防意外导致的任何损失) ●上传代码时写清楚log信息:(为维护这个模块的人着想,有可能是你自己) ●提供接口时不要把问题抛给使用接口的人,升级或者变更接口时不要删掉原来的接口:(为使用你接口的同事着想) ●变量命名要见名知意:(起码不能误导别人) ●在工程中新建一个doc文件夹将项目相关的文档放在该目录下,方便后面维护的人员理解项目和代码:(为维护这个模块的人着想,有可能是你自己) ●签署bug或者转办bug时写

个人ASP.NET程序性能优化心得(1):数据库篇

前言 相信园子里有不少程序员同学都是在做着xx管理系统这样的中小型项目,这种项目往往是一种工作量的代码,程序员同学就将青年耗费在这样的项目中,不断改变需求,不断地加班赶工,于是就开始怀疑这个行业,对developer充满厌恶,想学新东西,可是周围同事的水平都是差不多:想买书学平时加班根本没有自己的时间.这种状况相信大多数情况都在我们身边发生,我之前就是处于这种状态,使用的是asp.net语言,不过很难界定所做的项目是网站还是软件,因为它很复杂,开发周期和传统软件开发没有什么区别,但它确实是部署在

《全栈性能测试修炼宝典 JMeter实战》—第1章 1.2节软件测试痛处

1.2 软件测试痛处 就目前国内情况来看,大多数的测试人员并没有开发和运维的技术功底,选择测试这个行业仅仅是因为高薪和入门门槛低.近年来互联网和P2P的神话,快速抬高了测试平均工资,却没能快速提高这个行业的技术水平.在北上广深这些一线城市,从事测试特别是手工测试的从业者长期处在测试职业发展的初期阶段,容易被替代,薪资水平固定.职业生涯基本到尽头. 时常我们也能听到许多测试同学的抱怨: (1)地位低,不受重视: (2)待遇差,成就感低: (3)压力大,加班,提升难: (4)不稳定. 地位高低在任何

iOS社交app技术合伙人笔试题

理想状况当然是找到有管理能力且还在写代码的架构师了,然而如果有这样的人,他自己能发起项目了,你要拉上他还真难.满足一定条件就行了,别追求完美. 还有比这更完美的吗?请生产这样的机器人: 性格开朗(开朗≠外向),平易近人 表达能力好,易于沟通交流 有设计能力,有攻关能力 知识范围广,跨职能团队合作顺畅 在业界有一定视野或影响力,有好的人脉资源 有管理能力(经验≠能力),中后期能管好团队,顺利成长为管理者 没身体和家庭负担,能日夜加班赶工 在电脑上答题,发个email过去要求一小时内回复: 1.你想

如何做好团队非技术建设

这次谈谈的是如何做好http://www.aliyun.com/zixun/aggregation/7004.html">团队建设.这其实是个很大范畴的,但这次主要想谈下团队建设中的非技术因素,以及分析下在团队建设中,特别重要的成员的心理建设方面的问题. 首先,要纠正大家一个错误的认识,认为团队建设中,平常只要抓技术建设就行了,比如抓团队用什么架构,框架,具体的技术,抓培训,抓绩效就足够了,很多时候,我们可以思考一下,就建设技术方面团队就一定能取得成功么? 其实那是不一定的,因为一个好的团