本文介绍了管理一个软件产品与管理一部电影作品的若干对比，然后讨论了从成功项目中获得的四种软件管理方法。

使用传统的工程管理原则管理软件项目是很难取得成功的。把软件管理的挑战与制作一部动作大片进行比较，我们会发现很多有趣的观点。两者的管理问题都集中在在受经济因素制约的环境下进行复杂的集成知识产权的开发。本文介绍了管理一个软件产品与管理一部电影作品的一些对比，然后详细介绍了从成功项目中获得的软件管理的四种方法。主要的推荐做法是使用指导性的领导方式，而不是传统理念上的事无巨细的计划-轨迹领导方式。

在我的职业生涯中，我有机会观察并评估了上百个软件项目，它们广泛覆盖了各种工业和应用。一个显著的成败决定因素是在项目从初始到被用户接受的过程中所采用的项目管理方式。

根据我的经验，如果软件项目管理者使用更像是管理一部电影作品的方式，而不是管理一个工程产品的方式，那么他们似乎更容易成功。“胡说！”有人可能反对。“软件项目需要更多严格的工程管理，而不是更少！”在你发表你的言论，向权威发出挑战以前，请考虑以下观察资料：

大多数软件权威不需要物理定律或者物质属性来制约他们的问题及其解决方案。他们只是受到人类想象力、经济因素的制约，以及当他们获得一些可执行程序时，他们受到运行平台性能的制约。一些嵌入式软件的开发者显然是例外者。
在一个软件项目中，你几乎可以在任何时间改变任何东西：计划、人、预算里程碑、需求、设计、测试等等。需求——可能是我们的工业中被严重误用的词——很少能描述出真正需要的任何事情。一切几乎都是可以协商的。
软件产品的评估和衡量没有原子单元。经济性能（在服务行业中更为典型，评价为性价比）被证明是好的成功的度量手段。质量的大多数方面都是很主观的，比如可维护性、可靠性以及可用性。

这些观察结果对电影制片人同样适用，他们是有规律地创作独特的、复杂的、只受视角和人类创造性制约的知识产权作品。我假设电影作品的经济性能与软件项目的经济性能是相似的：从2000年起，只有三分之一作品的发行带有时间或经济上的可预言性。1我知道这些观察在使用工程理念来制造飞机、桥梁、心脏移植管、核反应堆、摩天大楼以及卫星的项目管理者看来是不入流的（除非这些工程项目包括重要的软件内容或是空前的，的系统）。

好的，有人可能会说，软件只是一个未成熟的工程分支，在我的职业生涯中，大约每五年软件项目的底层技术要翻新一次。这些翻新包括语言、结构模式、应用、用户界面、计算平台、网络、环境、过程以及工具。这种快速持续的进化将要放慢了吗？目前还看不出这种迹象。人类想象力和市场作用仍是非常强大的。

像电影工业，我们需要有资格的建筑师（导演）、分析家（编剧、设计师）、软件工程师（产品工作人员、编辑、特技制造者、演员替身）以及项目管理者（制片人）。还是和电影工业一样，我们必须使软件成为可执行形式（弄到胶片上）来切实进行进度和质量的评估。在我们发现什么可用什么不可用的过程中会产生大量的碎片和重复工作，然后我们把很多人的贡献集成为一个紧密集成的知识产权作品。

我所认识到的是，软件管理应被更精确地描述为软件经济的一个分支，而不是软件工程。软件管理者每天的决定（正如电影制作人每天的决定），主要是由价值判断、成本权衡、人为因素、宏观经济趋势、技术趋势、市场强度以及时机控制的。软件项目很少注重于精确的数学、物质属性、物理定律或是其他已经建立的成熟的工程原则。

我希望这一对软件-电影的对比刺激了你的神经，使你想继续读下去。如果想了解更详细的对比请参考 Paul Graham 的论文。2下文着重介绍的是一些从软件项目中获得的断言，这些项目包括了我在25年多的时间里在软件项目管理领域跟从、领导、实践、指导的少数成功软件项目和大量不成功软件项目。

迭代的方法

造成软件集中型项目的低成功率的原因之一是传统的项目管理方法不鼓励进行指导和调整以缓解以下问题的不确定性：

问题域（用户究竟想要或者需要什么）
解决域（何种结构和技术的组合是适用的）
计划域（成本和时间制约、团队组成和生产力、涉众交流、递增结果序列等等）

我们需要一种更为动态和具有适应性的方法来思考软件进程和质量管理的问题，这种方法应当适应成功项目的模式。当今的现代软件管理方法3-5 通常被称为迭代 开发方法。在现今充满不确定性的软件应用程序、产品和服务开发的雷区中，迭代方法指导了软件项目，而不是遵循一个精确的、长期的计划。按时间和预算计划成功发布软件产品需要一种发现、生产、评估和指导性领导方式的进步的混合。“指导”一词意味着积极的管理参与，经常的过程矫正以产生更好的结果。所有涉众应该通力合作，集中实现不断前进的目标。

作为一个被广泛接受的现代迭代开发过程，IBM Rational Unified Process，6 为一个更为平衡的发展提供了一个框架，这一发展是鼓励对不确定性和风险进行管理的。它的生命周期包括四个阶段，每个阶段都有可演示的结果：

1.起始：远景和商业案例的定义和原型设计
2.细化：对架构基线进行集成、论证和评估
3.构建：对有用的增量进行开发、论证和评估
4.产品化：可用性评估、终产品以及发行

阶段的名称表现了项目的状态，而不是从需求到设计到编码到测试到发行的基于顺序性活动的项目进展。

我们把这一迭代管理方式称为基于结果的，而不是基于活动的。在软件世界中，真正的结果是可执行程序。其他的任何东西（需求文档、用例模型、设计模型、测试用例、计划、过程、文档、检查）都是次要的，而且只是实现目标——一个可执行的软件程序——的手段的一部分。回想你做程序员的日子：当你在建立一个模型、画流程图草图、推理一个状态机的逻辑或是写源代码的时候，你知道你只是在思考和集成一个抽象方案。只有当你编译、链接和执行时方案才变得切实可行。项目管理者应该有同样的感觉。当你评估一个计划、模型、文档或一些其他不可执行的表现物的美好和出色之处时，你只是在推测项目质量和进度。电影制作人对剧本、情节串连板、背景设置以及服装设计的感觉也是如此。他们着力于影片的每一个镜头，使得电影成为可以判断总体集成效果的实体。

精确度与准确度

在一个成功的软件项目中，每一个开发阶段都加深了对发展计划、规格说明和完整解决方案的理解，因为每一个阶段都延伸了可执行序列和团队对竞争目标的认识。在生命周期中的任意一点，次要工件的精确性应与这种理解相平衡，在详细程度上保持一致，相互之间保持一定程度的可追踪性。

精确度与准确度之间的区别（在软件管理的上下文中）并不是它们看起来那样小。软件管理充满灰色的区域、情景依赖性以及不明确的折衷。对的软件管理者来说，理解精确性与准确性之间的区别是一种基本技能，因为他们必须准确地对投资、风险以及变化带来的影响进行预测。未被证实的精确度——在需求或是计划内的——实际上是造成阻碍成功的潜在而微妙的因素。大多数时候，早期的精确性是不诚实的，造成了有比实际上更多的进展和更高的质量的假象。不幸的是，很多项目发起者和涉众要求这种早期精确性和详细性，因为这给了他们对已经取得的进展的（虚假的）安慰。

我在软件工业中所见的常见的失败模式之一是开发有五位数精度的规格说明，而涉众其实对问题、方案或者计划只有一位数精度的理解。延长建立一个精确的需求理解或详细的计划的时间实际上耽误了对架构上更重要的问题的理解。你曾经做过、修改过、痛苦地回顾过多少厚度吓人的需求文档或是详细的管理计划呢？而几个月后当项目取得了有实际意义的可演示的进展，加快了涉众对实际的权衡的理解时，你又要全部重新检查这些文档和计划了。这种普遍现象在我们的行业里被称为刨光废物。