刘大双谈项目管理

个人简介 刘大双，PMP ，中国科学院研究生院客座教授，国家职业技能鉴定专家委员会项目管理专业委员会委员，曾任微软（中国）有限公司 Microsoft Project产品经理。刘先生有着多年的IT行业从业经历和丰富的项目管理的理论、实践经验，参与编写并出版了一些项目管理方面的书籍，如《软件开发的 过程与管理》，《Microsoft Office Project在项目管理中的应用》，《现代项目管理教程》，《Microsoft Project 2002与Server教程》等。

MPD大会是中国软件研发管理者自己的年会，是本土操作实践与海外研发经验分享的年会，主要面向以下软件开发管理人士：首席技术官（CTO）、研发总监、产品经理、开发主管、测试经理等与软件研发团队密切相关的领导成员。

   

1. 大家好，我现在是在亚太软件研发团队管理年会，坐在我旁边的是刘老师，首先请刘老师简单的介绍一下自己？

大家好，我大约是在90年加入IT行业，前后到现在将近20年的时间。先后服务于惠普、美国SAS软件研究所，以及微软。那么在过去的五年、六年的时间，其实我主要的精力致力于项目管理的方法，以及项目管理工具的一个推广，这是我大概的一个背景情况。

   

2. 谢谢刘老师，刘老师曾经在微软工作过，对微软的项目管理方法是非常了解。我们都知道微软有一套自己的方法，叫MSF（解决方案框架结构）。最近推出的VSTS 2010（Visual Studio Team System 2010）也引入了对敏捷Scrum这样一种支持，我想请刘老师谈一下你对微软的MSF和对敏捷的支持的这样的一种看法？

就像你刚才介绍的，微软其实是软件开发的管理方法，应该说还是比较成熟的，比较有名的大家知道叫MSF。随着现在软件开发形式的最新的一些进展，大家可能听说关于Scrum，这个敏捷开发，其实敏捷开发，通常大家认为比较适合比较小规模的一些软件产品的开发。从微软的本身在积累产品，微软的产品有的产品非常复杂，有的产品相对可能是比较简单。

但是对这几年的发展，大家看从VS本身，它的一个本质呢，虽然你可以定位它，这是一个开发工具了，但实际上这个开发工具本身结合了软件开发的这个方法论，以及技术管理的工具，比方说我们比较熟悉的像项目管理，微软的Microsoft Project这个软件，其实他把这些管理的方法，已经结合到VS体系中来了，尤其在VS里边，我们知道有VS的Team Foundation等等这些组件，其实他是结合了一个团队的开发模式，把整个微软的项目管理，尤其是软件开发的项目管理的方法结合进来，包括了你刚才提到的Scrum，这样一个理念，所以他结合了项目管理的理念，以及一个技术的实现，来整个提供一套完整的项目工作平台。

   

3. 我们都知道项目要取得成功，管理是很重要的，在这个行业我们天天都在谈项目管理，但是到底什么是项目管理，项目管理对IT项目管理来说包括哪些内容，它的难点和特点到底是什么？请刘老师谈一下。

这是个好问题。其实项目呢，大家每天都看得到，外面我们看到的工程，当然我们自己从事IT这个产业来讲，软件开发、系统实施其实都是项目。但是真正来讲，其实IT项目历史并不是很悠久，相对于我们外边的工程而言，大概只有几十年的历史；另外一个特点是这个产业本身是新的，表现在：这个技术突飞猛进，我们其实很难预见到明年或者后年会有什么技术的一个走向，所以这样使得这个产业本身，它的管理方法或者说我们叫这个产业的生产管理方法，显然就没有传统产业的管理方法的成熟。

那么在这方面，其实我们借用到了传统产业的管理方法，项目管理本身就是，其实我们看今天无论你叫做敏捷开发也好，或者是通常IT项目管理的方法，本质上相当大的程度上，还是借用传统领域的一个管理的方法。那么真正在IT项目管理，我觉得对我们一个挑战就是，刚才已经谈到了，这个产业的发展非常快，所以技术方面更新的速度也非常快；再一个，这个产业的从业人员都是智力密集型的这种人，而且将来的产品是非常依赖于具体的这些从业人员的，所以就给管理带来的挑战是，一个技术发展很快，传统的管理方法我们在借用，但是今天应该很难说有那个方法对于软件开发或者IT项目管理来讲，是一个放之四海而皆准的，其实它也是在一个成长的过程中；再一个管理的对象，尤其是参与的人，那么这个跟传统产业参与的人相比是有非常大的不同，这里也给管理带来了很大的变数，或者说是一个挑战，简单来说IT项目或者说软件开发的产品，每一个产品对每个人来讲，都像一个艺术品。所以从这个角度来言，艺术品大家可以知道，其实它的变数，那么它的依赖于具体的参与的人，甚至依赖于他的工作心情、工作态度，这个对于产品最终的产出都有非常大的影响，所以这就给管理带来了更大的挑战。

   

4. 对，事实上作为软件来说，它的复杂度以及可变的地方很多，所以在管理上是很困难的。根据现在Standish集团在08年的研究，只有32%的IT项目是成功的，也正是从这个数据上来说，也证明了刘老师刚才说的这个观点。像现在一个失败率居高不下，刘老师认为这个主要原因是什么？

我个人觉得，究其原因，基本上可以从两方面来看，第一个，就是需求的不确定性，由于IT项目，或者具体到产品开发，是一个创造性的工作。那么基本上来讲，对于很多人，尤其是对于需求方而言，他到底要做什么，我们都很难把它比较清楚的界定下来，这个也正是为什么今天有很多所谓IT项目管理，比方说敏捷开发等等，某种程度上应对这种特殊的一个情景，因为每个产品最终都是一种艺术品。所以具体来讲这个产品要开发什么，本身都比较难界定清楚，这就给我们带来一个挑战；第二个，有些时候对于一个产品开发，或者就客户而言，可能对IT项目的期望有一定的偏差，这样的话可能两个方面就导致将来这个项目的成功的机会相对比较低一些。当然还有一些其他的，比如说管理层的支持、资源的情况等等。但是我觉得比较主要的还是比如刚才我们谈到的两个方面，一个是需求，那到底做什么，第二个我们或者客户，或者我们这个团队对整个将来产品结果的期望，可能会有一定的偏差。

   

5. 项目的话，现在来说有的人是直接就失败了，还有一种虽然成功了，但是他没有能够按时的交付，就是对时间来说，我们怎么去规划它，在项目开发过程中，怎么去纠正这种时间的偏差？

没错，其实这个事也可能是IT项目管理的一个挑战的表现，今天非常多的项目，可以说一半以上的项目，可能都是延长了很多时间，甚至在投资上突破了很多。好歹这个项目还算是可以上线的一个项目，或者说一个产品。具体从时间而言，可能就要考虑到IT项目本身的一个特点，它的变数，这里依赖于技术的问题、人员的问题，以及受到很多外部其他情况的影响。这样从计划的角度，是不是能够从计划的角度多考虑一些所谓风险的因素在里边，比如说我们在计划上有很多方法来应对这种情景，比方我做一定的冗余，比方说备用方案、备用资源，以及事先可能做一些类似于POC的工作，做一些概念性的验证，如果有必要的话。这些都可能给计划一个稳健性，这可能是在时间管理上大概需要多花的一些精力。当然从计划本身的技术手段而言，关键路径法等等，我们可以考虑把一些我们认为相对有风险，或者变数比较大的工作，在整个计划，比方说甘特图也好，网络图也好，在这个方面做一定适当的分布，就是避免把风险比较大的工作都放在某一条，甚至是关键路径上去。

   

6. 刚才刘老师说到计划可以适当的考虑到这种情况，但是现在有很多有个现实，就是客户要求有这么一个Deadline，那这种情况下该怎么办？

这种情况呢，也说明了为什么我们IT的项目本身，相对而言失败的机会比较高，某种程度上我们面临的要求也是越来越，客户的期望对我们来讲也是越来越高，我们一个方面如果不能很好的管理客户的期望，将会直接导致将来项目实施的一个风险。

   

7. 比如说我们在做项目之前，应该还要和客户一个充分的交流？

没错，所以这部分也是专业性的一个体现，如果我作为客户而言，假设我是针对另外一类项目，我当然也会提对我最有利的一种要求。比方说以最少的钱、最短的时间做我所能想到最大的事情，这就是我个人也希望，我的乙方能够给我提供一些专业性的意见，双方合理的来设定这个目标，包括项目的范围、时间等等，这样也为项目将来的成功打下一个基础。

   

8. 刚才刘老师说到IT行业是一个智能密集型的，最关键的就是人。刚才我也问到项目时间的问题，事实上团队的工作效率，就直接会影响到项目的进度。但是这种效率，它不是机械，机械可以给我们一个稳定的数字，人就不行，那像这种情况之下，怎么去提高团队的效率？

说到底还是一个团队建设的问题，不过这个团队是个比较特殊的团队，特殊的表现在大家都是高智商的人群，所以对于这种团队，我们应该参照传统的团队建设的方法，这里不需要专门去提比较传统的这些方法。我想强调一个特点是，这种团队可能需要一个是技术的更新，由于今天技术开发工具、技术平台等等，更新的都非常快，我们希望这个团队是一种学习型的团队，能够跟踪这个技术发展，采用最合理的一个技术；再一个，我强调的是所谓这个团队的激励，怎么能够对这个团队人员，说到底对人员采用什么恰当的方式进行相应激励。再结合传统的通常讲的团队建设，形成大家协作的一种文化。在这种情况下可能才是一个有机会能够创建一个高效的一个团队。简单来说，要结合团队本身的特点来考虑。

   

9. 既使是最优秀的团队，可能在工作效率方面，他也无法完全保持恒定，总之可能在这个项目当中就会出现delay的这种情况。但是这个客户，对我们这个要求有很高，出现这种情况的时候，我们作为项目管理者怎么去和客户进行沟通？

这个问题，我的看法是这样，如果，这个项目已经严重的延迟，我觉得其实项目如果到一个严重的延迟这种情况，本身证明这个项目管理已经出了问题了，为什么这么讲呢？如果我作为甲方来讲，我能够接受的一种项目管理，你要尽早的告诉我，哪里已经出了问题，更好的是在那里可能出问题。在没有真的变的已经严重的成为现实的情况下，我们共同来讨论，用什么样的方法去应对，产生的原因可能是方面，有些是不可避免的，或者是双方都不能控制的因素，有一些可能是作为我甲方的，有一些可能是你作为乙方的。那么一个好的，至少是一个好的项目管理的标志，当这个问题没有真正发生，或者没有发生到真的那么严重的情况下，双方能够有很及时的沟通，要预先，其实这就是一种预警风险管理的表现，绝不能等到已经变成事实，甚至已经不可收拾的情况下，再考虑沟通，再考虑处理，其实很多情况下已经无力回天了，大家都已经没有办法了。

   

10. 那么做项目计划的时候，我们需要考虑那一些风险呢？

风险其实对于IT项目，其实我觉得不如更好的考虑一下，IT项目更着重的应该考虑哪些方面的风险，我觉得IT项目的风险，首先我们要考虑到技术风险，因为今天的技术方案，技术的发展方向，甚至你的开发手段等等，可能都是会有一些改变，这个本身也带来一定技术的风险。因为你不能所有的东西都去做一个验证，这个时间以及成本可能都不允许，这是一个技术方面的。

再一个管理方面，其实项目管理我们看了很多例子，很多团队本身都是很好的技术储备，很好的一个技术团队。但是，可能恰恰欠缺的是在管理方面，所以使的这个团队不能成为一个有效的，当然更不能成为一个高效的团队，这是管理的风险。

第三个，要考虑到组织、人员的方面的风险，这个对于IT项目来讲可能是相当的明显，这个例子也不少，很多项目有一些关键角色发生一些极端特殊的情况，甚至他可能离职，导致这个项目无法进展下去，我自己都碰到过这种情况。所以我到是觉得，首先从IT项目风险高发的地带来想办法，一个是技术风险、管理风险、组织层面的风险。那么这个风险呢，组织层面可能包括甲乙方的，人员的一些关键角色的一些变化。如果能够认可，哪些方面是IT项目风险的高发区，我们有可能在做计划的阶段，能够多花一些精力，选择一些恰当的备用的方案，以及在项目执行过程中，对这个风险进行实时的监督和监控，这样的话才能有效的来建立整体项目的一个风险。

   

11. 你刚才说你自己也碰到过人员变动，当时是怎么解决的？

那这种情况，惨的情况就是，你也只能认可这种现实，甚至某种情况，你要重建你的这个团队的一个关键角色，对于方案要寻找关键的来替代。更多的情况是在比较从容的场景下，对于关键的决策，严格来讲应该有一定技术的储备，比方说一些关键角色通常AB角的，针对一些比较大型的项目，在一些关键的岗位上，是要有相应的考虑。

   

12. 就像球队的主力球员和替补球员？

对，当然他可能不一定明确的表现出是一种替补，至少我会知道在一些关键岗位人员出现一些状况的时候，我在那里可以找到消防队，至少有人可以做一定工作的替代。

   

13. 当今IT项目管理来说，应该会有两种理论体系，一个是传统的项目管理，一种是敏捷的项目管理。刚才刘老师也提到敏捷的项目管理，更多的运用在小规模的项目，那传统的方式运用在大规模的项目。但是那些大规模项目运行中也有很多失败的，现在有一种思想，是想把敏捷和传统的方式结合起来，应该说是未来发展的趋势，那刘老师能不能根据你的一些经验和体会来谈一下，这两个方面的知识的理论体系？

传统的，我们通常认为项目管理方法，可能要看更加适用于哪种场景，如果从IT项目角度来讲，IT项目本身也可以划分成若干类，比方说，一类叫做产品开发，另外一类针对具体客户的定制实施。其实这两类项目，甚至还有咨询等等，其他的一些类。如果我们仅仅看产品开发和专门面向具体客户定制实施的，本身这两类项目还是有不同的地方。简单来讲，针对产品开发，可能我们还是有机会，与比较多的情况下去考虑采用瀑布的模型，因为我们可以有充分的机会去对产品进行规划，那么我知道第一个版本要实现什么功能，以及多长时间之后，我要推出第二个版本，再实现一些什么功能。这种情况下，可能还是相对而言，也许比较传统的瀑布模型，它的可用性还是比较高一些，可行性还是比较高一些。

但是针对第二种情形，针对客户的定制开发，可能要考虑利用传统的瀑布模型的机会可能相对比较小，因为这种情况下的需求，很难指望客户能够一次性，或者你能够拿出足够长的时间，把需求全部搞清楚。事实上不存在一个全部搞清楚，就算大家都认为全部搞清楚了，你将来做的时候还会发生一些双方意想不到的一些变化。所以我觉得两种方法，可能其实一，还是要判断我们所处的项目的具体的一个状况，我自己觉得，如果是有选择，假设我是做自己产品开发，我希望比较从容一点，我需求全都搞清楚了，因为前期有产品规划，可以采用；那另外一种情形，我到是觉得，今天在这种定制开发的场景，比较多的会引入这种叫敏捷开发，Scrum这种情形。我到觉得现在越来越多的可能因为客户越来越成熟，我们自己的积累，因为很多时候做项目也不完全都是从零开始，可能有一些所谓的半成品。那么在这种情况下，可能就会看到是两种，或者两种模型的混合模式，我觉得这大概是这样一种趋势，不过很难有这么足够的权威，站的足够的高来预测，怎么看将来会怎么发展，我觉得一切从实用出发。总的来讲，这个趋势是越来越多的采用结合的方式，原因就是客户越来越成熟。那么我们自己做项目，可能也越来越多有一定的半成品，这种情况下的项目要看，有可能采用两种模式的结合。

   

14. 好的，今天的采访就到此结束，谢谢刘老师。

好，谢谢。