项目管理艺术 1.1

  1.1    利用历史

        项目管理作为一种概念,可以追溯到很久的历史。当回想起人类文明史上所取得的成就时，你会发现我们有几千年的项目经验可以学习。我们可以用一条虚线把今天的软件开发者和埃及金字塔的建造者或者罗马水渠的设计者们连接起来。在不同的时代里，项目经理扮演着类似的角色，那就是把技术应用到属于他们的时代的问题上。然而在今天，当许多人想尽办法来改善他们的web和软件开发项目的管理时，却很少从过去汲取经验和教训。对于知识的运用，应该把目光放得更远一些，而不是仅仅局限于现在。

        工程项目的历史告诉我们，大部分的项目都有着惊人的相似性。它们都有需求、设计和限定条件；它们的完成需要依靠交流、决策以及融合各种创造性和逻辑性的想法；它们通常包括时间表、预算和客户；最为重要的是，项目的中心任务就是把不同人的工作融合成为一个整体并且使其对客户产生价值。无论项目是建立在HTML、C++之上还是水泥和钢铁的基础上，它们都分享着一套不可否认的核心观念。

        我对于如何更好的领导web和软件开发产生了浓厚的兴趣。我研究了其它领域和产业来挖掘它们是如何解决工程项目中的核心问题，这样我就可以把一些类似的解决方案应用到自身的工作当中。我想知道像哈勃望远镜和波音777这样的项目是如何设计和构建的，我是否能够从它们复杂的规范和规划过程中学习到什么有用东西? 当建造纽约的克莱斯勒大厦和雅典的帕台农神庙的时候，这些项目的领导者在计划和评估它们的建筑时是否使用了和我的程序设计者们相同的思考方式?它们之间有趣的差别是什么，我们可以从这些差别中得到什么启示呢？

那些报纸的编辑者是如何组织和计划新闻的日产量的？在Web出版物出现以前的很长一段时间内，他们就在做关于多媒体方面（画面和文字）的工作了。那电影产业的特点又是如何呢？阿波罗13号？通过检视这些问题，我能够发现以一种新的方式来领导项目团队。

        然而，这些问题并没有明显的答案。如果仅仅因为这本书中的建议受到了这些资料的影响便认为你会进展的更快或者计划的更好，我无法给您这样的保证。但是我知道当我回到软件世界的时候，我使用的方法和工具看起来会很不一样。我发现了一些方法来改变它们，而这些是我以前从来都没想到过的。基本上，我实行了许多有价值的步骤和方法，而这些在大学的计算机课程中并没有学到，它们也没有在技术部门的会议上讨论过或者在行业杂志上发表过。

        关于我对过去相关工作的调查，其主要内容可以归纳为以下3点：

1.    项目管理和软件开发并不是什么神圣的艺术。任何现代的工程项目都只是在生产产品的漫长历史中提供了一种新的生产方式而已，虽然工艺和技巧可能会改变，但是那些使工程项目变得困难的核心挑战仍然存在。所有的事情，无论是编程语言还是开发方法，在某些方面是独一无二的而在其他方面则是衍生出来的。但是如果想尽可能多的应用过去的知识，我们就需要保证在与过去的事物做比较的时候保持一种开放的态度，不仅要审视它们独特的地方，同时也不能忽略其衍生的方面。

2.    通常如果你把你所做的事情看得越简单,那么你越能集中精神和注意力在你做的事情上。如果我们能够周期性的把工作维持在这种简单的视图上， 我们就可以和许多不同的做事方式相比较并找出其中有价值的方法来达成我们的目的。从历史和现代工业中可以找出更多的例子和教训来进行比较和对照，这与日语中的词shoshin(初心)所表达出的概念类似，它代表了初学者的观点（1），或者开放的观点，而这也是许多武术训练的基本原则。保持好奇和坦率是你成长的动力，而这是需要经过训练才能维持那种心态。为了能够保持学习的态度，我们需要避免陷入那种狭隘保守的状态。

3.    简单并不代表着容易。最好的田径运动员、作家、程序员和经理往往是那些在作着看起来简单其实却很复杂的事情的人。请记住简单并不意味着容易。例如，跑马拉松是一件简单的事情，你起跑后必须一直跑到26.2英里才停止。什么能更简单？实际情况是在承认困难的同时并不能否认它的简单。领导力和管理也是很困难的，但是它们的本质是很简单的，那就是用一些明确的方法来完成明确的目标。

我将会在许多章节中提及这些观念。因此，如果我做的一些参考超出了软件开发的范畴，我希望你能明白我这么做的原因。当我提出决策和安排计划是很简单的功能的时候，我假设你已经知道这些并不是容易的事情。

1.1.1. 从失败中汲取教训

       人类具有互相学习经验的本领，这在所有动物中几乎是独一无二的。但是同时值得注意的是，他们也会对此表现出明显的厌恶感。

       Douglas Adams

        在向项目的历史学习的时候存在一个简单的问题：为什么有人愿意经受那种本来可以避免的由错误和失望所带来的痛苦？如果从公共领域的观点来看古老和现代工程的历史，无论灵感来自于何处，我们都会因为做了一些明智的事情而受到奖赏，为什么鲜有公司奖励那些从过去的经验取得收获的人？当项目完成或者取消的时候（许多开发的项目都是如此终止的（2）），很少有人去研究究竟发生了什么事情。看起来大部分公司的经理并不会奖励那些探求这些知识的人，可能是害怕他们会找到的东西（害怕会承担责任）。或者是对于回顾那些痛苦和失败的经历不感兴趣，取而代之的是，他们会把时间花费新的事物上面。

        在Henry Petroski所写的To Engineer Is Human: The Role of Failure in Successful Design (Vintage Books, 1992)中，他阐述了在工程中许多的突破都是从失败中取得的。这种现象在某种程度上确实存在，因为失败常常更能引起我们的注意，它要求我们重新检查那些我们遗漏的设想，(当原型都已经被火烧掉了，我们很难还装作若无其事)。正如Karl Poppe（3）r所说的那样，只存在两种理论：错误的理论和不完全的理论。如果不是失败，我们总会自大的忘记我们对事物的理解总是不完全的。

        窍门就是尽可能多的从其他人的失败中吸取教训。我们应该利用他们的经验来调控未来。尽管从表面看来，不同项目的失败原因不尽相同，但是导致其失败的根源或者团队的行为是可以被转移（避免）的。即使是在我们自己的项目上，我们也需要避免养成逃避或者隐藏错误的习惯。反之，我们应该将其看成是学习的机会。是什么因素导致这些失败发生的？哪一个因素可以被降低或者被消除？根据Petroski的理论，如果我们有勇气来仔细的检查究竟发生了什么，那么从实际的失败中获得的知识是我们取得进步的强大动力。

        可能这就是波音公司，世界上最大飞机设计和制造公司之一，保留了一本关于设计和制造失败经验的黑皮书的原因（4）。自从公司成立以来，波音公司就一直保留着这份文档，它被用来帮助那些现在的设计者们能够从过去的经历中学到有用的东西。任何一家这样做的公司不仅是为了提高项目的成功率，而且也能帮助他们创造一个敢于面对讨论和面对失败的环境，而不是否认和隐藏它们。看起来软件开发者也应该保存一本属于自己的黑皮书。

translated by geng