不确定性(范围不确定，目标模糊)

　　多样性(很难有通用方法和最佳实践可复制)

　　在修订中计划(渐进的计划)

　　丰富多彩的开发方法(条条大路通罗马)

　　额外的工作(方法，工具和技术)

　　没有纯粹的软件项目(不要忘记了目标)

　　积累和运用(技术积累和复用)

　　工具的制作和改造(方法，工具和技术)

　　聘用软件项目经理

　　JB:我曾经用了很多时间向非软件专业人员：客户、支撑机构、项目发起人、有时候甚至是项目经理讲解什么是软件项目：。几年前，我曾经帮助一位受过PMI 培训的项目经理，并且从事工厂地板安装项目多年的机械工程师，拯救一个挣扎在失败边缘的关键的软件项目。该项目已经提交并经常名列Media Metrix前50名，这位项目经理现在管理着那家工厂的大部分软件开发项目。其实，她最需要的只是对软件项目和其他项目之间的不同有所领会。此外，一些软件专业词汇和偶尔对任务、技术和工作成果进行理智的检查，就是帮助她走向成功的一切。软件项目是有一点独特之处，但是差别并不悬殊。上个月，一位刚被委任为他公司软件项目管理办公室的资深项目经理在NewGrange讨论列表中提问道：“如何学习软件项目?”。很长时间以来我给非软件专业人士解释软件项目，但直到现在我才记录下我的答案。我的回答从最初的4项增加到10项。因此，就有了下面的对非软件项目经理眼中软件项目的10大不同之处。

　　MW: 人们自愿花时间完成的记录他们实践经验的文档，往往是非常有价值的。注意，我强调的是“实践”。

　　JB: 软件是一种与众不同的东西。软件和其他种类项目的成果最大的区别是：它不是物理的。软件由想法、设计、指令和公式构成。创造软件的过程几乎都是感知活动。我们只能从代码文件中看到并衡量它(用一系列机器能够读懂的随机符号来代表相对真实的东西，这多惊奇啊)。他们通过另外一种方式代替着现实世界。但是，软件只有在看起来象某些真实的东西时才有价值，即使它仅仅只是一条在电脑屏幕上的彩色波浪线那样真实。软件的独特挑战之一就是维持思想存在与现实存在的联系。

　　MW: 是的，我们都愿意认为自己独有的特性是“与众不同”。事实上，在很多方面，它们确实与众不同的，否则它们就不会被称为“特性”。但是，对于项目经理来说，相对于其他类型的项目例如JIM提到的那些，软件项目真的那么与众不同吗?让我们更深入的探讨一番。

　　人们容易掉进的第一个陷阱就是他们没有区分技术的管理和项目进度的管理。其实，管理如何放置水泥板和在软件开发中如何在计算机屏幕上放置接口模块是有很大的不同。但是就项目范围、质量、时间、费用、风险等来说，这些不同对项目的管理有多大的影响呢?你可以看到两者，即使你可能无法看到两者后面隐藏的技术过程(从来有谁坐在那里看着水泥如何硬化呢?)。反过来说，即使确实存在差别，但是这些是同所使用技术的复杂性和工程所需的人员相关的。比如，当软件开发是 “最新的、技术先进的”时候，人们就认为构架已经建好了。但是，从这方面说，这不是独特的。

　　下面让我们对Jim的观点逐一探讨。

　　JB:1-通常，软件项目的成果不像其他项目那样可见或者容易理解。由于你不能像踢一捆砖头那处理一堆软件，你必须想方设法去确定软件的存在。在软件项目中最困难的工作通常是进度跟踪。有些大型软件项目的失败是由于初期工作比如设计不是按照预想的方式进行。比起软件设计，我们更清楚一个工厂的蓝图是否正确、完备和有用甚至时髦。一些所谓的脆弱项目的失败是因为它们没有一个仓库或者临时凑合的东西。软件项目的生产透明性需要我们拥有与建筑项目所没有的两样东西。第一，我们需要不可见的思维的替代品，然后，需要对替代品的状态进行监控。也就是说，使进行中的东西一致并可见。为每一个子项设定一个客户，并检查每块“砖”都满足操作标准(Donesss?)。增量提交和早期测试可以加强对项目进行过程中的模块和蓝图状态的可见性。

　　MW: 恩，第一部分都是关于技术而不是关于项目管理的。如果我们将软件项目同建筑项目进行比较，也是出于脑力工作的需要而不是劳动的需要。而且，人的管理需要使用特别的方法。但是，我要说，对于研发而言两者都是同样重要的。

　　JB: 2 – 与其它项目相比，软件项目的最终状态通常更具有不确定性。有时候我们对我们想要的东西最多有个朦胧的概念。有时候，我们的概念很清楚但是我们忘记告诉其它人(通常是隐含的需求)。在项目进行的过程中我们经常改变主意。因为软件是一个相对较新的领域，软件项目几乎总包含着新艺术—将软件应用于解决新的或扩充的难题。我们在创造的过程中学习我们要创造的东西。通过学习软件能做什么就可以提供一个的平台，来发掘软件的更多功用。有很多强有力的理由能够说明这一点。在项目进行的过程中，由于各种原因，软件项目的目标发生了变化。但与建好一半的墙相比，要意识到软件中的这些变化要困难一些。所以，软件项目应该采用渐进的方式来实现过程管理。渐进主义和沟通有助于项目包容在进行过程中发现的新价值和新挑战。它们也有助于凸显我们能够描述的隐含需求。而隐含需求可能会给项目带来巨大的冲击。除了渐进主义，测试也有助于发掘新功能、隐含需求和已有成果的变化。通常，在预定投zi和交付基线物的基础上开发和测试软件，以及基于我们所知道的情况考虑其他有限制的投zi都是有意义的。

　　MW: 我们还是在讨论技术的管理。确实，存在着一定的不确定因素，也可能是比建筑工程中能预料到的风险更大，虽然在建筑中工程保障要大得多。但是，同样的问题可以在电影制作中继续深入讨论。在拍摄某一幕并审核后就不得不返回进行调整。即使这样，除非在付费的观众面前播放，否则也不可能知道最后效果。

　　JB: 3 –在我们称之为“软件”和“软件开发”的项目中存在着很多的不确定性。设计一级方程式赛车同设计下一年的丰田佳美是有区别的，而丰田佳美和设计通用的新型燃料电池多用汽车平台也有区别。他们都与汽车设计有关，但是我们对他们的处理方式却十分不同。从某种意义上说，我们努力做到一致的设计软件，即使软件产品就像丰田佳美、赛车和平板车一样不同。系统处理了所有的差异问题，对于软件设计过程来说这些都不一样。考虑到这些差异性，我认为通用的软件方法论只能是一种幻想。我们应该做一些有意义的事情。跟踪工作，发布成果。你的软件项目可能和典型项目或者上一个项目有很大的区别。如果你的项目和典型的项目不一样，请相信你自己的项目。

　　软件产品：即使能够看到交付成果和固定的目标，软件产品通常差别很大而且是不可见的。部分是由于软件产品代表着很多不同的东西。因此，一个软件项目经理必须主动理解在他的项目中软件产品如何工作。

　　MW:我曾经参加过许多不同类型的建筑项目(还有软件项目)，我想在谈论到建筑项目时，我也能提出一样多的问题。特别你正在负责“新颖”的设计而不知道从何着手的时候。

　　JB: 4 从功能特性、代码到运行程序，整个产品链在吞吐量、可用性、可靠性甚至可变性本身都存在着很多差别。软件产品应不同的应用技术、不同的平台而不同，甚至同一个产品链如果部署方式不一样也是不同的。不同的产品差别很大，而且软件产品运行环境不同的时候也是不一样的。对于软件，我们无法保证我们能按照任何给定的速度从无到有创建出来，即使上周我们刚刚完成。软件项目可能还包括了对产品工具和方法的自愿的或被迫的更改，当你进行着这些动作的时候，也改变着软件产品。胡佛大坝曾经使用一种新颖的方法使水泥的硬化速度加速百分之一或更多。这种生产过程的改变在软件项目中经常出现(虽然有时候方向相反)。因此，调节项目向你要获得的成果前进包括了速度、返工河额外的动作。渐进式策略在这里有发挥作用了—在前进的过程中进行测量并察觉到事情的变化。作为一个项目经理，对软件项目进行重新计划不是一种形式而是一种需要。

　　MW: 相信我，在软件开发的生涯中，我经历了类似的无法保持前后一致的项目—当然，那时我们仅仅是用手工建立土坝和砖墙。

　　JB: 5 -生产代码在工作特征上与别的工作有很大的不同。通常，代码生产可以是：发明，研究，设计，创造，代码制造，集成中的任何一种或是其它什么。如果你的项目主要是修补工作，像解决Y2K问题，这时，“代码生产”是类产品，能够应用制造流程模型进行生产。如果你的项目主要是开发新系统，“代码生产”则更像是我们所谓的工业产品设计。即使你已经获得了大量的代码，制造模型仍然不能应用在设计中。在代码生产的过程中，设计和发明从某种意义上讲是可重复的。当然，这种可重复不是为编辑后的拷贝进行排版那种意义的重复，而是为报纸专栏撰写文章的那种意义上的重复。需要认识和处理你拥有各种代码产品，代码产品的种类也可能只有一些，也可能在你的项目生存周期中不断改变，当然也可能同时有几个种类。大部分方法学应用在某种特殊的生产流程，而且只在某段时间内适应实际情况。

　　MW: 事实上，这与药物产品的研究和开发非常相似。许多年以后，你才能知道，你已经获得了成功还是又一次走进了死胡同。

　　JB:6 - 软件生产的内涵远远复杂于生产软件。在整个产品过程中，前端(确定产品功能前)和后端(某些工作完成后)过程比编码过程更加易变，并且经常主导项目的时间表，风险和可变性。有些无具体产品输出的活动也能影响项目，比如组织变革，团队组建和技术采用。更糟的是，“完成”编码的意义并不相同。如同有些环境因素会影响到(或多或少)你，而其它的则不会，所以，编码完成包括了不同的后端工作。软件项目可能包含着生产软件的方法的改进，就像发明一种新的倾注混凝土的方法，来加速胡佛大坝的建造。经常，当我们更改软件的范围或影响时，用来测试和实施软件的方法也不得随之不改变-当这种方法不适应产品时。为成功开发软件产品，你必须管理项目中并非软件产品的部分。当重新计划软件项目时，连同对生产力的调整，全部任务或一大块任务会出现或消失。当非正式渠道的活动出现时，不要排斥它，尽量勾勒出它的特征。

　　MW：项目的基础构造会变得十分复杂，工作分解结构也会复杂而高度综合。目前有这样一种看法。软件构架师或工程师应该为他们的软件开发项目展开多少项工作分解结构。如果他们这样做了，是否会有帮助?

　　JB: 管理项目。管理软件项目意味着比管理其它变化较少领域的项目多一些的“控制管理”，少一些“支配管理”。软件项目管理就是一个持续的与客户、项目发起人、技术团队、供应商和支持组织谈判的过程。

　　MW: 软件项目的干系人确实需要大量的“操纵”，但是干系人们需要像高速公路和传输线那样被项目直线控制吗?让他们试着发现新的道路，铁轨或传输管来穿过你的邻居家吧。

　　JB:7 – 没有纯粹的软件项目。软件至少需要运行在硬件上，这样人们才能使用它。硬件必须是明确指定和配置的，有时也会是新研制的。人们使用软件改变了他们的世界-这才是要点。这适用于套装软件和嵌入式系统，在IT系统上就更加明显。如果你正在管理一个软件项目，你要么不得不管理项目的非软件部分，并且为整体系统的评估负责，要么你需要清楚的接口和传递到系统其它部分的东西。明确接口和传递是有点困难，因为软件产品很明显不是物理的。

　　MW: 这一点也确实同样适用于建筑项目。你必须有能够在上面盖房子的土地，必须确认这块土地在所有方面都符合要求，然后在这块土地上做好建造大楼的一切准备。同样的，你必须检查最后的工作，授权建设大楼，经常是最终还要卖掉它。

　　JB: 8 – 软件开发能力通常是有限的、共享的资源。而不像根据时间表来用一车车的水泥灌注工厂的地面。我们只能使用我们能够使用的资源。开发人员经常同时开发几个系统。我们总是正在考虑其它一些我们能利用这个系统做的事情并且软件产品总是超额订购的。大部分脑力工作者，多任务开发者会破坏生产力和士气并且无法跟踪。所以，分割工作，甚至让一个团队致力于一个单独的项目，就像加工车间。我们使用一个单独的产品或系统来叠加出一个大的产品或系统。软件是非常适合渐进主义的，因为它能经常增值。一个制造工厂可能在大部分没有修建完之前是没有用处的，而对于软件，如果你挑选出合适的10%，可能在整个软件在完成10%之后就有用处了。

　　MW: 对于不涉及软件的项目，其共性可以是“商业”或管理，但是对于软件项目来讲，很明显的共性是文化上的改变，例如态度。

　　JB: 9 –软件项目中使用的工具和方法都是可调的。所以，如果每五分钟重新构建软件会有助于代码生产，那么就调整你的环境来这样做。如果你依靠数据库中的数据，但是你不能很好的进入数据库，那就做一个拷贝。如果要把软件应用到10,000个点火系统中是缓慢而昂贵的，那么在你浪费大量的金钱和市场时间之前，调整你的方法做到相对正确。你可能希望得到烧制的样品芯片，当确实能得到时，你又面临一个计数问题-10,000是一个大数目-但是认识到功能是正确的，烧制还在继续。你可能想发明一种方法同时烧制10,000个芯片的方法。软件工具是比砖头或水泥更具有扩展性的。所以，关注什么受损，并且修复它。在软件工具和技巧中发明一种新的技术是即经常需要也经常失败的。只要是错误的路，迷人的新路和失败的老路同样都不应该走上去。我喜欢用每一个项目增量来迭代过程和方法 -“如何能在下一个项目中做到更好更快成本更低?”，然后在项目计划中跟踪过程或方法的改变。

　　MW: 看起来我们似乎回到管理技术而不是管理项目过程。

　　JB: 软件项目经理的工作。软件项目比非软件项目更像是一种“uber-project”。使用软件，我们没有大量的支撑能够帮助使其它种类的项目成功，像大部分人很了解一个工厂的样子，能计算砖头的数目。我们有大量的使用水泥生产和建筑的经验(确实有2,000到2,500年的历史，而软件只有不到60年)。综上所述，第10条特殊之处已经显而易见。

　　10- 软件项目经理是因为某种原因而被雇佣的。项目这种挑战不只需要行政管理者，它需要的是领导者和项目经理。你管理项目，同时支持那些必须应付变更目标，多重需求，多变的生产，有准备或无准备的变更，多任务，新方法等等的人。倒退回行政管理对项目(项目线)管理是有极大诱惑的。方法学说. . .那些坏的邪恶的客户，开发人员，卖主，激动的鬼说. . .项目群办公室需要. . .这很难，复杂，令人迷惑，不明确. . .这是你的工作。如果你不能描绘出(可能通过找到一个值得信任的顾问)，那么你的工作岗位描述是无用的。

　　MW: 我从未碰到过一个项目经理只为了某个原因而未被雇佣。我同样没有遇到一个十分成功却仍然不是领导或经理的项目经理，对于一个好的管理和推动者也是一样。事实上，项目经理承受大量的辱骂，但是现在，他们的部分角色是“教育”他们的负责人项目管理的艺术和科学。正因为如此，也教育他们项目群管理和项目组合管理。

　　JB: 这个建议也适用于软件工程发起人，软件项目经理的经理。在管理软件项目过程中，大部分忙碌而灵活的人要全力以赴。让他们去管理。不仅给他们支持，还要寄希望于他们，否则仅仅有他们的工作岗位描述是无用的。

　　MW: 事实上，这对所有领域的项目管理应用都有益处。