技术项目走向失败的五条“捷径”

oschina
 oschina
发布于 2014年01月23日
收藏 151

技术项目的失败,屡见不鲜。不论你运营的是一个持续跟进一些项目的软件公司,还是一个需要顾问来为你提供系统集成的非技术公司,你都有可能遭遇这个 问题。进度延期、预算疯涨、直至最后完全失败,这在软件世界非常普遍。事实上,一个项目延期数年,超支数百万,已经不是新鲜事了。

例如,在2003年,我飞去洛杉矶出席微软为软件开发者举办的其中一个会议。活动中,微软发表了激动人心的消息:下一个版本的windows将会带 来一些革命性的新功能。回顾我的笔记,其中有一个新功能叫做WinFS。具体细节不讲,简单来说,WinFS建议将操作系统的文件系统功能(文件和文件夹 的位置信息)和数据库功能(个人对文件的描述信息)合而为一,放进一个又大又邪恶的“文件数据库混合体”。

这是一个挺有野心的动作。从技术上来说,WinFS约等于重新安排一个国家的交通系统,以适应会飞的汽车。是的,这样会使航空公司停业。同样,所有车库也要变宽来适应带翼的车子。但先别想太远,还是让这功能在一年或最多两年内面世再说吧。

三年过去了。一个叫Quentin Clark的微软经理在博客里说道,WinFS根本不能准时面世,并且它阻碍了微软推出其最新的操作系统。因此这个功能要延期,或者放到以后版本的数据库 上,这意味着没有了“将文件系统与数据库系统合而为一”这唯一的亮点。有鉴于此,你怎么知道你某个技术项目哪一天会注定成为另一个WinFS?这里我有五 步指引来确证一个软件的失败:

错误一:采用平庸的开发团队

软件设计是有难度的,而且不幸的是,很多自称程序员的人确实不能胜任软件设计。尽管这是项目失败的首要原因,你也不曾从官方的失败报告中得知。在所 有的行业,软件业,物流业,或者客服业,人们对同事的无能都太过宽容。你从来都不会听到有人说“我们团队没有足够的智慧来完成这件事”。为什么要这样伤人 的心呢?显而易见的,如果这队分得了任务的人员并不擅长这份工作,他们的工作会日复一日,日复一日……等等……但软件却没有做出来。你也不用太担心HR会 阻挠你招聘一班废物。在大多数的案例里,我向你保证,HR对此毫无建树。

错误二:按周来定目标

假设你想改造你的厨房。你请来的师傅已经搞过很多厨房,而且不作详细蓝图就能估算出这项工作的成本。但软件开发者是在制造前所未有的东西。如果前所 已有,他卖张拷贝的光盘给你就行了。因此,粗略的估计是不可能的。他们需要在写代码之前做好详尽的计划。无论你是客户还是开发经理,你的责任就是确保开发 人员带着详尽计划来开展工作。当你向开发人员询问计划时,他们大多数人可能只会给你一份把进度按周来划分的时间表。这看似非常合理,但其实不然。如果你让 软件团队提交一份大粒度的时间表(大是指需要两天以上的工作),那么你可以认定他们没有考虑到所有需要实现的细节,而这些细节将会积累,导致延期。

错误三:为截止时间而谈判

还有什么比按周划分软件项目更糟糕?就是要求团队承诺大大地提早完成工作。根据我的经验,大多数开发者都会乐观地接受你的暗示并参与讨价还价。然后你会得到一份友好的协定时间表,但却无法按时执行。

试想以下情况:海象妈妈会在怀孕15到16个月后,生出小海象。你可能会叫海象妈妈保证在15个月内做到,而她也说没问题。或者你说,“15个月? 疯了吧?我们要在8个月内生出”。当然,这样谈判是无法促进事成的,而且即使得到一份8个月的进度表,我还是告诉你一个小秘密:这是不可能实现的。你可以 取得一份11个月的时间表,但你还是要等15个月,因为小海象就是要15个月才能出产,有时甚至16个月。

错误四:均分任务

这里有一个破坏项目的好方法。列出人们需要做的所有工作,然后给重新均分给各人。如果Mary有太多的工作,就分一些给John。这听起来完全合 理,使得你不会被质疑。但我向你保证,时间一长肯定会出现问题。那是因为当一个开发者去替代另一个时,我们有理由假设效率降为十分之一。John将会花费 无数小时去搞清楚Mary其实已经熟悉的那部分代码。而且John改bug也不及Mary快,因为Mary才了解所有的陷阱在哪里。

错误五:工作到深夜

让我们假设有个项目要每周工作40小时,连续六个月才能完成。如果你让所有人每周工作60小时,那么持续四个月就能完全搞定。软件团队可能甚至会接 受这个挑战,因为这使他们看上去像英雄(那个海象队有多厉害?他们每个周末都来工作!)这能行的,是吧?再想想吧。有一部完整的文献论述了“加班不会使软 件更快产出”。Edward Yourdon,作为软件企业家和该文献的作者,称这种项目为“死亡行军”。

软件开发者花费大量的脑力劳动。即使是最好的程序员,也很少有能坚持几小时以上的高强度脑力劳动。另外,他们还需要休息一下大脑。这就是为什么你好像总能撞到他们在上网或玩游戏。

强迫他们投入更长时间坐在电脑前,并不会转化为更多的产出——即使会,那都将是劣质的产品。当软件开发者的大脑完全发烧,他们几乎做错多过做对,写 出无法使用的代码,或者引入大量的bug。而如果你真的禁止他们上网,玩多人游戏,强迫他们在正常的睡眠时间继续写代码,好吧,他们可能会开始离你而去。 死亡行军不是造成项目延期和预算爆炸的唯一条件,但绝对是充分条件。

如果以上是使你项目失败的方法汇总,那么怎样做到万无一失呢?首先,你要招聘一个巨星级人马。在Fog Creek,对于一个全职岗位,我们倾向于审核大约400个候选人。因为最优秀的开发者拥有十倍于“一般优秀”的创造力

其次,让开发者给出细粒度的时间预算。是的,让开发者去预估制作一个新应用需要花多长时间,是不容易的(文章1文章2)。这就是为什么他们要在每个项目之前作出可靠的蓝图。

一旦你有时间表在手,不要尝试提前截止日期。如果项目不能在你能谅解的时间内完成,解决方法不应是去交涉一个“好听的”时间表,而应该是争取更多资源,或者推迟上线,或者拿掉一些功能。

当项目正在进行时,你会多次被诱导而想重新分配工作。但你要谨慎地重分配。所换的新人需要花不少时间去驾驭原作者的代码。我觉得让人员在不同岗位上 轮换有助于消除不可替代性,但我是谨慎地安排这事,并且在时间表里加入额外的三周给新人以学习新代码,和额外的一周给旧人去教新人。

最后,鼓励你的员工按合理的工时,一周干40小时。我是说真的。除了偶尔为截止日期而冲刺,我们在Fog Creek都是一天8小时工作制。在技术的世界里,应该将一个大项目看成是一次马拉松,而非一次短跑。

注:Joel Spolsky是纽约市Fog Creek的联合创始人兼CEO,并且是热门博客“Joel on software”的主人。英文原文最后更新于 2007 年 11 月 1 日。

原文链接: Joel Spolsky   翻译: 伯乐在线 - unblock
译文链接: http://blog.jobbole.com/55447/

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:技术项目走向失败的五条“捷径”
加载中

最新评论(32

北_木
北_木
感觉很对
首席搬砖工程师
首席搬砖工程师
国内软件项目走向失败的捷径再加这两条:
1.外行指导内行。项目经理一丁点技术都不懂,而且他认为他不需要懂,他是做管理的,技术这些粗活是程序员的事情。
2.售前无节操答应客户变态需求和交付时间。
默默无蚊
默默无蚊
mark一下吧
cisiqo
cisiqo
中的不少吧~
JPer
JPer
国内,不加班的公司比较少,出加班费的公司更少。
闫锋
闫锋
在天朝,只有有关系,就不会失败
小桦
小桦
mark
高跟男爵
高跟男爵

引用来自“东京热”的评论

引用来自“大案要案命案在身”的评论

我一天7.5小时 实际安心干活3小时,而我依然感觉累 感觉空虚 感觉寂寞··

冷吗?看东京热吧。

太重口味了
Kevin19701
Kevin19701
这些,销售一定不会赞同。
东京热
东京热

引用来自“大案要案命案在身”的评论

我一天7.5小时 实际安心干活3小时,而我依然感觉累 感觉空虚 感觉寂寞··

冷吗?看东京热吧。
返回顶部
顶部