-
Notifications
You must be signed in to change notification settings - Fork 15
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
7 changed files
with
388 additions
and
885 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,95 +1,35 @@ | ||
01 此时此刻,一个项目正在走向失败 | ||
|
||
自计算机被广泛使用以来,编写出了数以万计的应收账款程 | ||
序(Accounts Receivable Program)。当你正在阅读这些文字时,可 | ||
能又有数十个或者更多的应收账款程序即将完成。然而,此时此 | ||
刻,一个项目正在走向失败! | ||
|
||
想象一下!一个没有真正技术创新的项目正在滑向失败的深 | ||
渊。应收账款程序不过是一个“重复发明的轮子”,经验老到的开 | ||
发人员面对这样的项目总能驾轻就熟。即便如此,有时在项目中 | ||
付出的努力却南辕北辙,最终将项目推向失败。假设其中一个走 | ||
向崩溃的项目结束,并邀请你前往会诊。(当然,这事儿永远不会 | ||
发生,我们这个行业自有一条金科玉律来阻止我们分析失败。) | ||
|
||
现在假设在所有参与者寻觅到各自的借口之前,你有机会分 | ||
析到底什么地方出现了差错:自然,你不会将项目遭遇覆顶之灾 | ||
归因于技术。就当前的技术发展来看,在技术上完全可以实现应收 | ||
账款系统。一定存在其他因素造成了失败。 | ||
|
||
在人件(peopleware)项目的第一个十年中,我们对开发项目 | ||
及其结果进行了调研。我们评估了项目的大小、成本、缺陷、加 | ||
速因素以及项目工期的成败。最终,我们统计了500多个项目的 | ||
历史,它们都来自开发一线的项目数据。 | ||
|
||
统计结果表明有15%的项目出现问题:项目取消、终止、延 | ||
迟或者交付的产品从未被使用。项目越大,出现问题的几率就越 | ||
高。对于持续时间达到25个工作年及以上的项目,足有25%的 | ||
项目最后宣告失败。在早期分析中,我们舍弃了这些失败项目的 | ||
数据,而对其他项目进行了分析。但自1979年以来,我们一直努 | ||
力联系项目上可以找到的人员,期望发现究竟是哪里出现了问题。 | ||
我们研究的绝大多数失败项目中,没有一个是因单纯的技术问题 | ||
导致失败的。 | ||
|
||
游戏的名称 | ||
|
||
“政治”( politics)是被访问者最常提及的失败原因。但这个词 | ||
经常被人们习惯性地含混使用。在“政治”这个词语下,包含着 | ||
诸多不相关联或松散关联的东西,如交流问题、人员安排问题、 | ||
与上级或客户关系不和、缺乏动力、高离职率等。人们经常用政 | ||
治来描述所有与人相关的工作,但语言学对这些内容提供了更为 | ||
准确的描述:它们构成了项目的社会学。真正的政治问题不过是 | ||
这些病态特征的冰山一角而已。 | ||
|
||
倘若你认为一个问题属于政治的范畴,你会宿命般地逆来顺 | ||
受。我们总是能直面技术的挑战,然而垣率地讲,我们又有几人 | ||
能自信地面对政治这个圈子呢?认识到问题真正的本质分属社会 | ||
学的范畴,而与政治无关,能帮助我们面对问题时更游刃有余。 | ||
项目及团队社会学或许超出了你的专业范畴,却没有超出你的能 | ||
力之外。 | ||
|
||
不管你怎么命名这些与人相关的问题,它们都比所有的设计、 | ||
实现及方法论问题更有可能在下一个项目中给你制造麻烦。事实 | ||
上,本书的基本论调都是基于这个想法: | ||
|
||
我们工作中的问题更多属于社会学范畴,而非技术范畴。 | ||
|
||
大多数管理者坦承:他们对人的担心更甚于对技术的担心。 | ||
但他们很少以此种方式去管理?他们的管理方式总是视技术为主 | ||
要关注点。他们总是越俎代庖,将大量时间耗费在本该由团队解 | ||
决的复杂而又有趣的难题上,就好像他们是自己完成工作,而非 | ||
进行管理。他们总是在寻求某种技术银弹(technical whizbang),以 | ||
期让工作实现自动化(参见第6章)。在他们的职责中,最重要的 | ||
与人相关的要素却被放到了最低优先级。 | ||
|
||
滋生这种现象的部分原因来自于管理者的提拔机制。对新晋 | ||
管理者的训练是如何完成一项工作,而不是如何管理它。很少有 | ||
公司会考察新晋管理者在工作中是否展示出相应的能力与良好的 | ||
心态来胜任管理工作。他们缺乏管理径验,也没有具体的实践。 | ||
那么,新晋管理者又是如何自我说服应该花更多的时间考虑问题 | ||
的技术因素而非人的因素的呢? | ||
|
||
高科技的幻觉 | ||
|
||
问题的症结或许在于高科技的幻觉:广为人知的理论认为凡 | ||
是接触新技术的人(我们谁不是呢?)就被想当然地看做属于高科 | ||
技领域。在鸡尾酒会上,当人们畅谈自己就职“计算机行业”、“电 | ||
讯行业”或者“在线电子交易行业”时,很容易沉溺于这种假象 | ||
中,认为他们自己就是高科技世界的一部分。在我们看来,他们 | ||
通常都不是。只有在上面那些领域从事基础研究、获得根本突破 | ||
的科研人员才是高科技工作者,其他人只是在运用他们的研究成 | ||
果。我们使用计算机和其他技术来开发我们的产品或者帮助组织 | ||
我们的事务。由于我们以团队、项目或者其他紧密协作工作小组 | ||
的形式来完成工作,我们大多数人是在从事人类交流的职业。我 | ||
们的成功源自于所有参与者良好的人与人之间的互动,我们的失 | ||
败则归因于这种互动的缺失。 | ||
|
||
我们习惯性地专注于工作中的技术问题,主因并非它们重 | ||
要,而是因为它们更简单。安装一块新的硬盘,比寻思为何 | ||
Horace显得忧郁而恐慌,Susan人职几个月就对公司不满要容易 | ||
得多。人与人之间的互动非常复杂,没有简单规律可循,但在工 | ||
作中它的确更为重要。 | ||
|
||
倘若你发现自己更加关注技术问题而非社会问题,那你就像 | ||
是一名杂耍演员,在一条雷黑的街道丢失了钥匙,却逡巡至邻近 | ||
的街道去寻找,并美其名日:“那里的灯光更明亮。” | ||
# 01 此时此刻,一个项目正在走向失败 | ||
|
||
自计算机被广泛使用以来,编写出了数以万计的应收账款程序(Accounts Receivable Program)。当你正在阅读这些文字时,可能又有数十个或者更多的应收账款程序即将完成。然而,此时此刻,一个项目正在走向失败! | ||
|
||
想象一下!一个没有真正技术创新的项目正在滑向失败的深渊。应收账款程序不过是一个“重复发明的轮子”,经验老到的开发人员面对这样的项目总能驾轻就熟。即便如此,有时在项目中付出的努力却南辕北辙,最终将项目推向失败。假设其中一个走向崩溃的项目结束,并邀请你前往会诊。(当然,这事儿永远不会发生,我们这个行业自有一条金科玉律来阻止我们分析失败。) | ||
|
||
现在假设在所有参与者寻觅到各自的借口之前,你有机会分析到底什么地方出现了差错:自然,你不会将项目遭遇覆顶之灾归因于技术。就当前的技术发展来看,在技术上完全可以实现应收账款系统。一定存在其他因素造成了失败。 | ||
|
||
在人件(peopleware)项目的第一个十年中,我们对开发项目及其结果进行了调研。我们评估了项目的大小、成本、缺陷、加速因素以及项目工期的成败。最终,我们统计了 500 多个项目的历史,它们都来自开发一线的项目数据。 | ||
|
||
统计结果表明有 15%的项目出现问题:项目取消、终止、延迟或者交付的产品从未被使用。项目越大,出现问题的几率就越高。对于持续时间达到 25 个工作年及以上的项目,足有 25%的项目最后宣告失败。在早期分析中,我们舍弃了这些失败项目的数据,而对其他项目进行了分析。但自 1979 年以来,我们一直努力联系项目上可以找到的人员,期望发现究竟是哪里出现了问题。我们研究的绝大多数失败项目中,没有一个是因单纯的技术问题导致失败的。 | ||
|
||
## 游戏的名称 | ||
|
||
“政治”( politics)是被访问者最常提及的失败原因。但这个词经常被人们习惯性地含混使用。在“政治”这个词语下,包含着诸多不相关联或松散关联的东西,如交流问题、人员安排问题、与上级或客户关系不和、缺乏动力、高离职率等。人们经常用政治来描述所有与人相关的工作,但语言学对这些内容提供了更为准确的描述:它们构成了项目的社会学。真正的政治问题不过是这些病态特征的冰山一角而已。 | ||
|
||
倘若你认为一个问题属于政治的范畴,你会宿命般地逆来顺受。我们总是能直面技术的挑战,然而垣率地讲,我们又有几人能自信地面对政治这个圈子呢?认识到问题真正的本质分属社会学的范畴,而与政治无关,能帮助我们面对问题时更游刃有余。项目及团队社会学或许超出了你的专业范畴,却没有超出你的能力之外。 | ||
|
||
不管你怎么命名这些与人相关的问题,它们都比所有的设计、实现及方法论问题更有可能在下一个项目中给你制造麻烦。事实上,本书的基本论调都是基于这个想法: | ||
|
||
我们工作中的问题更多属于社会学范畴,而非技术范畴。 | ||
|
||
大多数管理者坦承:他们对人的担心更甚于对技术的担心。 | ||
|
||
但他们很少以此种方式去管理?他们的管理方式总是视技术为主要关注点。他们总是越俎代庖,将大量时间耗费在本该由团队解决的复杂而又有趣的难题上,就好像他们是自己完成工作,而非进行管理。他们总是在寻求某种技术银弹(technical whizbang),以期让工作实现自动化(参见第 6 章)。在他们的职责中,最重要的与人相关的要素却被放到了最低优先级。 | ||
|
||
滋生这种现象的部分原因来自于管理者的提拔机制。对新晋管理者的训练是如何完成一项工作,而不是如何管理它。很少有公司会考察新晋管理者在工作中是否展示出相应的能力与良好的心态来胜任管理工作。他们缺乏管理径验,也没有具体的实践。那么,新晋管理者又是如何自我说服应该花更多的时间考虑问题的技术因素而非人的因素的呢? | ||
|
||
## 高科技的幻觉 | ||
|
||
问题的症结或许在于高科技的幻觉:广为人知的理论认为凡是接触新技术的人(我们谁不是呢?)就被想当然地看做属于高科技领域。在鸡尾酒会上,当人们畅谈自己就职“计算机行业”、“电讯行业”或者“在线电子交易行业”时,很容易沉溺于这种假象中,认为他们自己就是高科技世界的一部分。在我们看来,他们通常都不是。只有在上面那些领域从事基础研究、获得根本突破的科研人员才是高科技工作者,其他人只是在运用他们的研究成果。我们使用计算机和其他技术来开发我们的产品或者帮助组织我们的事务。由于我们以团队、项目或者其他紧密协作工作小组的形式来完成工作,我们大多数人是在从事人类交流的职业。我们的成功源自于所有参与者良好的人与人之间的互动,我们的失败则归因于这种互动的缺失。 | ||
|
||
我们习惯性地专注于工作中的技术问题,主因并非它们重要,而是因为它们更简单。安装一块新的硬盘,比寻思为何 Horace 显得忧郁而恐慌,Susan 人职几个月就对公司不满要容易得多。人与人之间的互动非常复杂,没有简单规律可循,但在工作中它的确更为重要。 | ||
|
||
倘若你发现自己更加关注技术问题而非社会问题,那你就像是一名杂耍演员,在一条雷黑的街道丢失了钥匙,却逡巡至邻近的街道去寻找,并美其名日:“那里的灯光更明亮。” |
Oops, something went wrong.