标签:
“我们很难测量软件工程生产力,”推特公司工程效率部的技术总监彼得.塞贝尔说,“但是我们肯定能破坏它。”
在一场脸谱网举办的大会上,塞贝尔这样说道。这场大会集结了1800名来自约400家不同公司的软件工程师,他们开发的应用软件可能会被数百万甚至数十亿人使用。它讲述了一个关于推特公司软件进化升级的故事:一个有许多不同程序语言的babel,像Ruby, Java, and Scala,因为需要各类工程师一起协作,所以很难完成,但最后(大体上)完成了。
“作为一个知道如何去升级软件的行业,我们也知道如何去升级企业,如何有效管理使数千人在一起工作。”
“但是我们还没有解决如何升级软件工程和人员组织之间的连接。而且可能我们甚至还没有意识到这个问题的重要性。”
“我们对这类工作的投入少得可怜,”他说道。
塞贝尔认为,软件工程师小组从实际开发产品的人员中抽取适当的人数,并交给他们协助工程师的任务,可以提高小组的工作效率。他说,“一个十个人的团队不需要特别安排人员负责提高工程效率。”他们自己就能知道自己需要什么。“一个一百人的工程师团队,分出两个人”为其他人提供更好的工具和其他支持,“他们这一百人的产出和101个工程师的产出一样多。”
他还建议,一个一千人的团队需要255名工程师来支持其他人的工作,他们这一千人的工作效率等同于1400名工程师。而一个由一万名工程师组成的团队(脸谱工程师团队的规模),则需要分出三分之一的工程师负责提高工程效率。
这些有效工作的工程师们能一点一点的去除影响生产力的问题,而在一家大公司里每一点提高都会产生叠加效应。例如,每天减少五分钟的整理时间能让工程师们多增加百分之一的实际工作时间。减少找工具的次数-即使每次事故仅造成一两分钟的工作中断-能极大提高生产力。塞贝尔解释说,工作的每一次中断会打破工程师顺畅的工作状态,而研究表明,工程师通常需要十五分钟重新进入状态。好的工具也十分重要,塞贝尔说,因为好的工具能带来工作乐趣。“给员工提供好的工具跟给他们提供好的事务一样:都能使工作更加愉悦。”
工程效率团队也能减少塞贝尔所谓的“技术债务”,这是在工作过程中为使工程师继续前进而没有以最佳方式解决的问题,尽管他们知道之后还是得想办法解决。
塞贝尔承认他还没有解决推特的技术债务问题。“我的梦想是有一支高级工程师团队,”他说,“他们能顺道解决一些编码问题,进行升级然后再回到他们的本职工作。如果团队里有这类能主动解决一些无暇处理的事情的人,会带来巨大的工程收获。”
标签:
原文地址:http://www.cnblogs.com/qk2015/p/4824633.html