领导力大挑战
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
该内容已经被标记书签!
标记书签错误,请重试!
作者 Ben Hughes 译者 乔梁 发布于 2008年1月12日
2004年,某国际电子游戏公司员工的家人某blog中的述苦,引发了一系列的媒体报道和在线讨论。Evan Robinson为IGDA(International Game Developers Association)写了一篇文章,阐述了“赶工”没能收到效果的六个原因:
- 在一个工作日中,生产效率随时间发生变化。在前四至六个小时里,生产效率最高。随着时间的流逝,生产力会降为0,甚至会变成负数;
- 对于脑力劳动者,生产效率很难量化;
- 经过上一个世纪的研究表明,每周五天且每天八小时的工作时间,从长远看其产出将会最大。有什么理由让我们认为:我们这个行业可以不遵守这个规则呢?
- 在每星期工作60小时的情况下,由于长时间工作而导致的生产效率下降抵消了几个月超时工作所带来的产出;
- 每连续工作24小时,会使认知能力下降25%。多个连续开夜车的人会产生严重的叠加后果;
- 错误率会随连续工作的时间而攀升,尤其是在占用睡眠时间的情况下。最终,失败会找上门来,灾难也就发生了。当时间紧且预算大时,你真能承担这个风险吗?
的确,对于“每天八小时、每周五天”的工作制,是有据可依的。实际上自从1926年:
当Henry Ford在1926年采纳每周40小时的工作制时,着实被国家制造业者协会(National Association of Manufacturers)批评了一番。但是,他的试验(已经进行了至少12年)使他确信“将每天工作时间从10小时消减到8小时,且每周工作六天消减为五天”这一举措提高了总产出,并降低了生产成本。Ford还热心地提到由于缩短劳动时间而增加了人们的消费时间,从而带来社会效益。但是其论点的核心仍就是“减少上班时间意味着更多的产出”。
那是什么因素让“赶工”最终对软件行业产生了如此大的影响呢?一般来说,项目计划是建立在某种有缺陷的假设基础之上的,即“要做的工作是定量的”,即被称为“劳动总量固定”的谬论。而敏捷方法论如Scrum就不做这个假设。尽管它无法最终消除迭代的赶工,但它把赶工的时间按百分比加在了迭代上。因为不适当的计划制定或者是因为根本没有计划,频繁学习未知的知识会占用项目70%的时间(参见"The Secret Sauce Of Software Development")。
那么,假如我们(管理者)知道这是不对的,为什么还总这么做呢?Evan Robinson的观点是:
管理者决定赶工是因为他们想告诉他们的老板“我做了我能做的事”。他们赶工是因为他们评估的是放在椅子上的“草人”而不是那些能开发游戏的“大脑”。他们赶工是因为他们没有认真考虑要做的工作,或没有考虑做工作的是人。他们赶工是因为他们只知道要表现出自己在尽力做好工作的重要性,而不是真正去做好工作。还有,他们赶工是因为他们回想到当他们还是程序员、测试人员、“助理制片人”或“副制片人”时,他们也是被要求这样做的。
Esther Derby却有不同的观点,即:我们错误地计划了可能出错的东西:
我们来仔细回顾一下理解问题的各阶段。我们收集需求、开发分析模型,然后设计软件解决方案,并制订计划去构建和部署这个解决方案。我们提出一系列有序的活动合理地引导我们最终走向目标。
然而,当我们却跳过了一个重要的步骤:没有坐下来思考一下哪里可能会出错。当不良后果发生以后,我们才知道这些计划和设计中的缺点。即,“撞了南墙”才发现自己的疏忽,钱也花没了,也推迟交付了,还在质量上打了折扣。
似乎引起赶工的因素完全是人。您用什么方法与赶工现象做斗争?仅仅是工程学中“人”的一面吗,抑或,它是根本不必要的呢?
查看英文原文:Why Crunch Mode Doesn't Work译者 乔梁 有十多年软件开发及项目管理经验,专注于提高软件企业提高交付能力。现任百度项目管理部高级架构师。
管理者决定赶工是因为他们想告诉他们的老板“我做了我能做的事”。
----------------
没想到国外也是这种情况,我还以为只有国企才会有这种想法
hehe,当然了,这些官僚主义的问题,只要是有组织,就一定会有吧,何况国外的公司啥的历史不比我们长多了么?
企业追求短期利益回报,片面的认为工程人员前期各项准备工作都是使得项目超期,成本增加的主要原因;有意缩短或跳过这些内容,而改由咨询人员主导项目进展;其直接后果是低估项目开发难度,需求未完全明确的情况下即开始编码工作,随项目的进行,各种问题相即发生,无法与初期计划吻合,“赶工”在所难免。
赶工的肯定会造成加班严重,加班严重必定影响员工士气,连夜赶工加班必定会造成员工怨气冲天,导致的结果是员工病倒,或者离职。这种隐形的危害其实对公司造成更大的危害。
这个道理很多人都明白,但并不是所有人都能明白。而且有些人可以讲道理,有些人就没法讲道理。就像我从前工作的某个公司,主管就说过这样的话:“累就累去呗,有啥啊,反正现在招人这么便宜”
问题国外加班的加班费超高(正常工作时间的两倍吧好像)。。。国内超低(10块一晚算不错了)
英国同事说,如果需要加班的话,是去跟老板谈加班工资的,一小时给多少钱才加班
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
论道WP第三篇专栏,以应用程序栏的使用为中心,包括了软键盘带来的问题、应用程序栏介绍、如何绑定应用程序栏的属性等几个方面的具体话题,为开发者顺利使用应用程序栏开发提供了具体指导。
在多线程并发编程中Synchronized一直是元老级角色,很多人都会称呼它为重量级锁,但是随着Java SE1.6对Synchronized进行了各种优化之后,有些情况下它并不那么重了,本文详细介绍了Java SE1.6中对于锁的性能优化,以及锁的存储结构及升级过程。
本次分享将首先介绍现代富文本编辑器的组成和实现,然后结合UEditor的开发过程,与参会者分享UEditor在设计和实现的过程中,所涉及到的核心功能的细节实现。
本次演讲视频录制于百度技术沙龙。
我们所开发的应用程序大多都需要提供一个图形用户界面(GUI)。关于GUI应用的架构设计,已经有了Form & Control、MVC,、MVP、 Passive View等多种模式。模式可以帮助我们建立优雅的架构,但前提是弄清楚模式的应用场景。弄清楚GUI应用面临的设计上的问题,有助于我们正确的挑选设计方案。
MongoDB是一种非常易用的NoSQL方案,Brian C. Dilley在这篇文章里介绍了MongoDB的优劣势,并介绍了MJORM项目。MJORM用于MongoDB,是一个没有注解的Java ORM库。
随着网络基础设施的逐步成熟,从RPC进化到Web Service,并在业界开始普遍推行SOA,再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
7 条回复
关注此讨论 回复