现实的项目中，真正能够理想化地将工期、成本和质量目标在启动前就能够定义清楚的项目，能够完全按照商业合同来规范启动的项目只是少数，更多的是我们可以称之为“泛项目”的项目，即不能预先将项目目标、范围等定义清晰、而只能大致明确其目的的项目。新产品研发（如抗埃博拉病毒药物的研制）常是“泛项目”，人们无法预知该项目将遇到何种技术难题、它们究竟需要多长时间才能攻克。

“泛项目”占了项目中的大多数，真正能够规范定义的项目只是少数。“泛项目”不像理想的项目那样引人注意，但其数量极多，稍不注意都将导致组织资源的浪费；严重时导致项目完全失败、组织损失惨重。

《送给加西亚的信》就讲述了一个送信的泛项目。1898年4月，美西（美国和西班牙）战争爆发，美国总统麦金莱急于与在古巴丛林中打游击战反抗西班牙统治的起义军首领加西亚取得联系，但是没有人知道加西亚将军的确切地点。美国陆军的年轻中尉安德鲁·罗文接受了该任务。

罗文没有问“加西亚在什么地方？”、“到哪里能找到加西亚？”，接到任务就立即出发，没有任何人跟随前往。直到他潜入古巴岛，古巴的起义军才给他派了几名当地的向导，九死一生，终于把信送给了加西亚将军。

整个项目过程既没有良好的开始，也没有可控过程，更谈不上目标标准（不限费用、质量，只强调时间紧急还没有明确的里程碑计划），当然风险完全不可控，甚至目的地在哪里都不知道。但这个项目无疑又是成功的！

一、泛项目之路

融睿智捷公司的项目经理李炯曾经面对一个产值规模以“亿元”作为度量标准的客户，为其定制开发的一套价格是以“十万元”作为计量单位的软件。第一次面对客户主管领导（职位是总工程师）的时候，该领导的要求：“由于机构多，人员多，场地大，需要在网上共享尽可能多的资料，以方便员工之间的交流和领导层及时掌握实际工作状态。因此，我们需要以各部门（大大小小20多个）整理的资料为基础，连接若干个外部独立软件的数据库，建一个集介绍、查询、统计、共享为一体的综合性内部网站。为配合3个月后国家××部门（主管领导）的视察，该项目必须抓紧完成。”随后李炯的手中多了一份3页的建站内容要求。（由于某些原因，案例隐去某些细节）于是，一种前所未有的挑战感在李炯心中油然而生。

接下来，制定解决方案、编制投标书等等，再加上一些不为外人知的人情运作，三周后顺利中标。合同中约定，该项目的开发期3个月，维护期1年。

在公司总经理的授意下，李炯成立了一个由技术部“牛人”牵头的5人项目组。“牛人”负责系统总体设计和系统“主要部分”的开发，2名程序员负责系统“次要部分”的开发，还有一名美术设计来负责页面的美工制作。做为项目经理，李炯负责项目的总体把控和协调。

“项目成功后，依托客户的影响力将大大提升我们公司在行业中的地位。”启动会上，总经理为大家打气。

接下来的过程，正如狂热项目的过程，各位一定都很熟悉。陷阱就在此时被“挖”好了。

首先，客户方的需求暗藏玄机。既要功能全、自动化程度高，又要赶在上级视察时充分表现；其中又面临时间紧、初期构思简单等问题。真可谓“时间短、任务重”。

其次，合作方涉及面广，作为系统构建的主要出发点，系统应能连接众多的外部孤立系统，并从中查询和共享数据。以何种方式保证技术公开的完整性和准确性是片空白（相关系统中包含由国外厂商开发，由国内代理商销售的系统）。

再次，“主要部分”、“次要部分”的评价标准模糊，而且也没有人负责划分和解释，这在某种程度上挫伤了几个团队成员的自尊心。

最后，作为项目经理的李炯怎样对项目进行把控和协调也没有明确的定义和授权。

李炯感觉到了问题的严重性，决定针对预见到的问题召集一次项目会议。会议如期召开，参加的成员有总经理、销售副总、团队成员，会议的议题是“在有限时间内的优先开发标准”。最初，会议目的是建立基于判别标准的团队共识，以在3个月时限情况下，能够确定各类内容的开发时间顺序。换言之，短时间内，先做什么、后做什么，给出衡量标准。

可是，会议进程大出李炯的预料。总经理的态度：“客户要什么样的系统，就给什么样的系统，技术的要求就是实现而已”，而且旧话重提“项目成功后，依托客户的影响力将大大提升我们公司在行业中的地位。”销售副总：“我已经争取了这单，你们就一定要做好。”“牛人”也开始表白：“选择我，没错的”。其他人“领导怎么说，就怎么做。”

李炯慌了，思考了2天，很痛苦的2天，可能已经预计到了失败。然后毅然决定：一是不过问项目技术细节，不表态；二是一切以领导视察为首要目标。

这里，客户的目标事实上是不确定的。

首先，一个能及时提供信息的平台是为了工作效率而设定的技术目标。

其次，“该平台应能够如实向国家机关领导反映企业领导层的先进性，从而能够……”可以说是政治目标。

再次，客户把本该属于他们的时间上制约给了融睿智捷公司。

也就是说，项目应该为客户进行整体规划。遗憾的是走上了泛项目之路。

在公司的规划会议中，乐观氛围弥漫，没有实质内容，只有李炯感受到了风险难以承受。问题只要还没有发生就不是问题，这也是国内很多项目的实际情况。

项目经理、牛人和团队其他成员的人员配备和任务安排也值得探讨，“主要部分”、“次要部分”的划分在项目组中引入了不必要的竞争。这算不算是一个危险信号？

会议中“拍脑袋”和“拍胸脯”的表现已很明显，大家憧憬成功，而没有人关心项目目标的具体化、可行性以及项目的过程控制。

通常，作为项目经理，尤其是新技术行业的项目经理，都会遇到“客户逼”、“上司压”、“牛人顶”的局面。这是任何技术手段都无法解决的矛盾。因此，在该条件下试图以技术手段来解决矛盾的一切方法恐怕都包含幼稚的成分。这些问题已远远超出纯技术工作的范围，划为公共关系学的范畴也许更合适。

二、忘记项目目标是技术型项目经理面前的一堵墙

一个人坐在热气球上飞行，突然发现自己迷路了。他降低高度，发现下面有个人。他把气球降的更低，大声向下面的人问路：“请问，你能告诉我我在哪儿吗？”

下面的人说：“当然，你在一个热气球上，距离地面30英尺高。”

“你一定是个搞技术的，”热气球里的人说。

“没错”这人回答道。“你怎么知道的？”

“很简单，”热气球里的人说，“所有你告诉我的东西在技术上都是正确的，但对我一点用处也没有。”

下面的人回复说，“你一定是个项目经理。”

“没错，”热气球里的人说，“你怎么知道的？”

“很简单，”下面的人说，“你经常找不到北，或者不知道该去哪，你希望别人能够帮助你。在遇到我之前，你也是这样，但现在是我犯了个错误。”

时刻铭记项目目标是项目管理很重要的一个思维，项目所有的活动都围绕这个展开，而且项目目标是以业务为导向而非以技术导向的。

可是，随着项目的逐步开展，尤其是复杂项目：人多、事多、周期长，很多项目经理会逐渐因为个人喜好而忘记了项目的大目标，比较典型的有：

技术出身的项目经理会沉迷于技术细节，大量时间花在学习新技术或者一头闷在解决技术难题上；

脾气火爆的项目经理会因为很多不值当的事情大发脾气，把团队搞得乌烟瘴气；

小心眼、爱面子的团队成员会因为某个某种技术观点不同而怀恨在心，搞拉帮结派，不团结。

所有这些，无论原因是自身不成熟，还是管理经验、管理能力不足，结果都一样，那就是项目出问题，甚至失败。

项目经理最重要的一项任务就是跟踪与控制，时刻把握项目方向，保证项目计划得以顺利执行，让偏差控制在可控风险范围内。但项目总是有太多意外因素，特别是周期长的项目，人们常用夜长梦多来形容风险会随时间的延长而出现，所以项目经理一定要时刻保持头脑清醒，对项目无益的事情不做，对项目产生风险的事情更不能做。

任何项目在开展过程中都会不断面对机会和诱惑，项目经理一定要能明确以业务为导向的项目目标，才能清晰地识别哪些是使项目成功的机会，哪些是会给项目带来风险的诱惑，才会少走弯路，早日成功。

人是需要不断被提醒的，这由人性决定。智慧的人能够不断的反省从而自我提醒，愚笨的人会被挫折、外界的警示不断提醒，这就形成了成功与失败的差异。

三、银弹迷信

技术人员通常会认为采用新技术、新工具会缩短项目工作的时间，这就是“银弹迷信”。

学以致用，就怕乱用。无论是产品、技术还是管理方法，都存在为了更先进、更科学而罔顾现实，盲目乱用的现象，结果先进和科学的技术、工具不仅未提高生产效率，却成了累赘，这样的情况到处都是，国内大量失败的信息化项目就是这类错误的典型。

很多项目经理在学习了一些新的技术后，总想立刻在项目中实践，而不去仔细分析这些技术在这个项目中是否需要，是否适合。技术日新月异，不断有新的理论被提出来，被翻译引进到国内。有些项目经理在一知半解，对这些技术还不是很熟悉的情况下，就敢向人吹嘘他所掌握技术的科学性、先进性，进而强制要求在项目中实践。这可能是甲方的项目经理，也可能是乙方的项目经理。因为技术选择错误导致项目失败的例子在国内过去有，现在也还有！不可准备不足，大范围引入全新技术。到项目时间过去一半了，才发现选择的技术不适用，那时候一切都晚了。

新技术、新工具需要技术人员花费很多的时间去熟悉和掌握，特别是在项目工期比较紧张的情况下，使用不熟悉的新技术反而更有可能导致工期的延误。掌握任何新东西都有学习曲线，项目的时间限制是项目经理必须时刻牢记的要素，把握不好就会给项目带来极大风险。

技术人员大都很热爱自己的技术，技术牛人更是如此。然而，这些人懂得专业技术性工作常常并不是他们对项目最大的优点，反而有可能是他们最大缺点。技术人员是实干家，只要在做他喜欢的工作，他就感到幸福。他对项目的兴趣不在于项目的商业成果，而在于项目过程的刺激、在于对项目成果技术先进性的追求。对项目基于业务的事实时常置若罔闻。

对于一个软件工程师来说，永远没有完美的项目。只要时间允许，他总能发现可以进一步修改的地方。实践表明，缺乏商业专家参与的项目所产生出来的东西一般是能力过剩的、不适用的、甚至是完全不能用的。

然而，无论是作为使用项目产品的客户（他们很可能不属于相关技术行家），还是商业专家，都很难对项目的需求进行准确定义。客户和商业专家尽管也可能会用一些数据来帮助他们将需求定义清楚，但更多的情况下是通过描述性的语言来进行需求说明的。这些具有二义性或多义性的需求描述会造成干系人对项目需求理解上的不一致。

涉及到具体的项目管理，《PMBOK®指南》的知识体系可谓博大，还有一些其他新的项目管理工具，不能说不先进，但是哪些知识、工具、方法适合本项目，需要项目经理根据实情，认真分析后进行筛选使用。

科学、先进、好用等修饰头衔都不是要选择的首要理由，需要、适用和有效才是王道。很多项目经理因为年轻，初生牛犊不怕虎，胆量大、勇气足，敢于在实践中引入新的工具、方法。敢于尝试不是坏事，但试验的风险一定要控制好。对于项目经理来说，所有的决策都要围绕项目目标进行。

项目经理的首要任务是保证项目成功，如果同时引入新技术、新工具，增加组员的知识技能，提升项目组工作效率，提高产品的质量和可靠性，只能算是锦上添花。不能为了锦上添花而导致项目失控甚至失败，捡了芝麻，丢了西瓜！

【作者：郭致星】

【来源：《做项目，就得这么干》（人民邮电出版社）】

备注：原创文章，未经允许不得转载，违者必究。