项目管理过程五个阶段

IT项目管理－五大过程组

PMBOK将项目管理分为了启动，计划，执行，监控和收尾五个过程组。

一，启动过程组

启动过程组的核心要素是可行性分析，立项，初步范围说明，确定项目的目标和范围，委任项目经理

等。很多项目都是在项目启动的时候就注定了是否是一个死亡之旅，因此项目经理应该有在项目启动

前启动的意识。只有这样才能够胸有成竹。

项目经理-在项目启动前启动

未之于未有，始之于未然。风险管理贯穿项目始终这句话应该进一步扩展，聪明的项目经理应该在项

目还没有启动前就能够未雨绸缪。项目启动后的每一天往往都异常宝贵，有可能你并不清楚项目是否

最终能签单，但只要有7,8成的把握，我们就应该提前行动，去分析可能的风险，去降低和消灭不确

定性。

项目成功是客户满意-去分析你即将的客户，他们有哪些特点，他们注重产品的哪些特点，以前公司

是否和该客户有过合作？在合作的过程中是否出现过相关的问题？客户接口人的性格特征以及是否

好打交道。如果客户对产品的易用性很在意，则项目应该提前考虑界面和易用性相关规范制定。如果

客户对性能很重视，则应该提交考虑架构设计和以往架构的优化。如果与客户以前合作中经常出现范

围的变更和蔓延，则要注意后续加强需求管理和需求开发工作。

分析你是否有可能成为该项目的项目经理，分析高层领导对项目的重视程度，分析如果你能够成为项

目经理是否可以获取到高层领导的支持和足够的资源。真正到了项目经理任命的时候你往往并没有足

够的时间来思考这些问题，那你那个时候的接收往往就是被动和突然的。你可能连胜算几何都不清楚

就接受了项目。

分析你团队的现状，分析如果项目能够启动团队人力资源是否满足，是否关键岗位或角色还缺少资

源？如果存在这种情况，要及时物色和考虑企业内或企业外可用的资源，团队组建需要时间，新人融

入团队更需要时间。如果不提前考虑这些问题，及时项目启动后给你资源名额你往往也可能不能及时

的获取到你需要的资源。在企业内获取其它项目资源更是一种复杂的交际行为，更需要项目经理充分

发挥自己的人际交往能力，提前为项目启动后真正资源的获取进行铺垫。

关注下客户在招标相关采购文件中对产品的要求，企业原有的产品功能特性是否都可以满足，有没有

客户特别强调了但我们没有具备的核心功能？对于这些功能是否存在技术难点？如果有，则这些技术

问题应该提前预研，项目中最难估算的任务工作量就是这种事先没有经验积累的新技术任务，而这类

任务往往又处于进度计划中的关键路径，直接影响到项目周期的不确定性。

如果项目经理在真正项目启动前都能够很好的分析和思考这些问题，那被委任为项目经理的时候才可

能显得胸有成竹。没有不确定性因素的项目就不应该失败，项目经理的所有工作始终都在围绕着消除

项目的风险以达成项目的最终目标。成功只偏爱有准备的人，我们可以临危受命，但决不应该仓促上

阵。

IT项目管理-项目启动三要素

是否是项目立项审批通过就代表项目启动？真正的项目启动应该包含三个方面的重要内容，一是项目

或产品初步范围已经确定，二是项目的目标已经确定，三是已经选择了委任了项目经理。如果安装

PMBOK的说法，这几个方面的内容都应该在项目章程中得到体现。项目章程也可以简化到项目启动会

议既要，但关键点都在于项目经理确定，并给予了法定的正式权力。

1.项目经理的选择和委任

在高层领导支持，项目目标也明确的情况下如果项目还失败，项目经理应该负完全的责任。项目经理

也可以选择是否接受项目，但一旦接受了就应该对项目的成败负责。

选择项目经理无定法，仍然关注平衡。如果是已有项目团队，团队成员技能都很强，那项目经理重点

是团队建设和资源整合。如果团队技能弱，但责任心和态度积极，那项目经理必须是技能强，必须是

一个能够传授知识的好教练。关于项目经理知识和技能层次，原来有文章阐述过，在这里不再多谈。

两个关键点就是项目成员愿意和你一起把事情做成功，另外一个是你能够使项目成员有能力把事情做

成功。

高层管理或者说PMO如果愿意在项目经理选择上多花些时间，完全是对产品和项目负责任的态度。基

于强矩阵或项目型的组织中，高层管理要能够轻松，就是其下一层的项目经理能够真正管理其整个项

目团队，项目中99%的问题都能够由项目经理解决。在这种金字塔型的权力型结构中，取决定性因素

的不是塔尖，也不是塔底，而是中层。而项目经理正是这种结构中的中坚力量。

2.项目目标

不要简单的把项目目标理解为进度目标，项目目标必须要包含进度，成本和质量三方面的目标。否则

我们虽然按时完工的做出来的产品可能无法卖出去，或者预审超支。在这种情况下项目仍然是失败的。

项目目标是如何确定的？是根据项目可研和项目立项后确定的。确定项目目标是为了保证我们最终产

出的项目成果能够赢利，能够为企业或客户带来实际的价值。很多时候项目经理不会考虑为何要制定

这样的目标，只知道是高层制定的，项目按照目标做就可以了。如果你不知道为何做的话，是无法把

问题做好的，项目经理有必要去深究项目目标的来源。

项目目标最主要的来源仍然是商业目标驱动的，做项目目的仍然是为了为企业创造效益，为了赚钱。

真正理解了商业目标，你才可能在进度，质量，成本，范围发生冲突的时候如何去平衡。大家都知道

削减不同的边可以达到平衡，但关键点却在抉择究竟该削减哪条边。

3.项目范围

启动阶段的项目范围是一个初步的范围。但启动阶段对于整个产品的范围必须要清晰，产品范围是产

品应该具备的功能特性。而项目范围是项目管理和执行过程的所做的所有事情，比如风险应对，项目

内学习培训属于项目范围，但不属于产品范围。

我们谈有了初步范围后可以启动项目，绝对不是指产品范围。启动项目的时候，产品范围必须要清楚，

产品范围不清楚将导致成本，进度等无法受控，产品范围不清楚就启动项目往往是项目做完了还赔钱。

项目范围可以初步是说明WBS分解可以是一个粗粒度的，细粒度的任务级可以在项目计划阶段在做。

客户关注的是最终提供的产品的功能特性，而不是你内部项目如何去运作以研制出产品。这点我们可

以从SOW工作说明书中看到，甲方招标的采购文件包或SOW都是有详尽的产品范围描述的，因为这也

是项目重要的验收标准。

IT项目管理-启动-项目立项

最近在看漫索公司林锐博士的相关培训ppt,从最早推出的CMMI三级精简并行过程SPP,到现在的RDM

S产品，还是很多值得借鉴的地方。今天先看下项目立项管理:

1.立项管理的重要性

立项管理应该说是新产品研发管理的或者说IPD的一个重要内容。人在江湖，最怕的就是跟错人，站

错队；而对于企业最怕的就是战略性决策和方向选择的失误。项目管理中的项目计划是保证实现项目

的目标，而立项管理正是去确定项目的目标，现在竞争如此积累，立项决策是否正确直接导致整个企

业的成败。

项目计划是保证如何做成功的问题，而立项是要解决做什么的问题。你需要开发的产品，不管什么客

户需求出发VOC还是产品核心竞争力，唯一关注点就是效益和利润。这个问题展开就是前期需要投入

多少？能否盈利？什么时候能够盈利？能否持久的盈利？整个立项报告的内容都将围绕这些核心内

容展开。

2.构思->调查->可行性研究

这里把构思放在第一位太重要了，在《像外行一样思考，像专家一样实践》这本书已经提到过，我们

是无法去穷举我们想做的事情和所有做事情的方法的，唯一可以采用的就是先根据自己的经验构思或

假设，再去证明构思的正确性。

构思的目的就是提出假设，能够提出好的构思的往往是有丰富经验的人，他们有很好的前瞻性和敏锐

的市场洞察力。有了构思需要去证明构思可行，而最有力的证据就是数据，拿数据来说话。因此在可

研里面必须要先看到这样的步骤:

现状分析->数据收集方案->数据收集->数据分析和预测->财务成本效益分析

步骤都知道是这样，真正的难点却在于你要开发的新产品根本无法收集到足够多的数据资料来做可行

性研究。这个时候风险分析，产品核心竞争力分析，SWOT分析转移到了重要的地位。风险遇到，可

能后期所能够取得的市场和利润也越大，像史玉柱几亿资金豪赌网游取得的成功不是一般人可以玩

的。

3.可行性研究报告和立项建议书的重点

前面已经谈到过，最重要的就是要说明前期投入多大，能否盈利，能否持续盈利的问题。但要回答这

些问题自然又会从市场现状分析入手:

市场现状->产品定位->产品功能->核心竞争力

通过产品定位和功能特性分析才可能估计前期的投入，有了对市场和潜在客户的分析才可能预期产品

后期的销售确实以确定盈利情况。有了核心竞争力的认识才可能清楚面临的竞争＆风险，产品是否会

被对手快速模范而导致无法持久盈利。

这条脉络清楚后，再看如果你能够你能保证产品能够开发成功，在特定的成本和进度目标里面研发成

功，具体分析为:

你已经有的经验资本积累->产品技术方案->项目核心团队

4.危机和风险意识

低头思考的时候我是一个悲观主义者，抬头向前的时候我是一个乐观主义者。立项的时候一定要对风

险有充足的认识，真正立项完了则需要积极和乐观应当。对于风险主要来源于技术方面，市场方面，

政策环境方面，人员，竞争对手方面等等，这些都必须有详细的分析和应对。

SWOT分析是立项中最常用，非常有效的可行性分析。在这里我们更加强调去分析自己的弱势和潜在

的风险。前期风险考虑的越多，后期就对自己越有利和主动。

5.立项评审和项目筹备

前面已经谈到了立项的关键问题，立项评审也应该从项目关键问题展开。产品的定位，盈利预期，核

心竞争力，风险，财务指标等都是重要的评审内容。评审通过后进入项目筹备阶段，立项评审完毕后

就应该确定出项目章程所需要的项目目标，制定完项目章程后才谈得上开始项目计划。

IT项目管理-启动-团队组建

IT项目管理-启动-研发规程制定

规程在项目启动时候就开始制定最好。而且应该根据历史已有经验和企业实际情况进行制定。过程必

须要有效，任何一份文档都要起到该起的作用。

1.可行性报告内容可以省略，将可行性分析内容全部写入立项报告。

2.调研报告很重要，与客户的每一次调研和访谈都应该及时输出。

3.同样开发通用型软件，必须输出产品需求，作为产品架构设计重要输入。

4.用户需求最好条目化，用户需求要从用户角度来描述，重点在业务规则。

5.项目计划不仅仅是进度计划。

1.没有列出详细设计文档原因仍然在于体现源代码即设计的思路。

2.总体设计包括了对功能性需求和非功能性需求的考虑。在总体设计阶段要制定详细的界面规范，设

计规范和编码规范，项目约定。

3.测试重点在测试数据准备和测试分析，针对V模型要单独出功能性测试和集成系统测试的不同。

IT项目管理-启动-干系人分析

项目经理接受委任后，个人认为最重要的一件事情就是进行干系人分析。或者讲在启动前或被委任前

就应该进行干系人分析，很简单的道理，比如高层管理都对项目不支持，项目经理再有能力也无法使

项目实现目标。

干系人是对你项目的目标达成有影响的所有人，如果要关注项目开发出的产品所带来的长期效益，则

干系人应该是对项目所开发的产品的整个生命周期都有影响的所有人员。干系人的识别，干系人分析

都不是干系人管理的最终目标，最终目的都将落到项目经理如何利用分析的结果，通过自身所拥有的

资源，技能，沟通等去影响干系人的行为，以达成项目的目标。

1.项目的出资方和赞助人

对于赞助人始终关注的如何使自己的投资有最丰厚和深远的回报，同时又将风险控制到最低。跟个人

投资是一个道理，投多少钱不是问题，关键是如何保证投入有低风险，稳定和客观的回报。因此赞助

人不仅仅关注项目本身是否成功按目标完成，而是关心产品能否成功按计划推入市场和创造效益。

对于项目周期较长的时候，为了项目本身降低风险和满足干系人预期，项目迭代开发就显得更加重要。

迭代开发可以保证将项目分为多个迭代周期，每个迭代版本都是可用的而不是一个半成品，项目最终

交付成果会分为多个迭代版本交付，赞助人可以尽可能早的看到项目所创造的产品或成果。同时采用

迭代开发每个迭代版本都可以尽可能早的投入市场和进行市场推广，资金不用一次性的全部投入，可

以通过市场的反馈不断的纠正方向和需求。

2.项目高层领导

高层领导一般是期望项目取得成功的，但高层领导关注的是PPM(项目组合管理)，因此项目经理一定

要清楚在多项目，自己的项目在高层领导眼中的优先级和地位。明白了这点才能够分析在多项目资源

冲突的情况下，自己的项目如何去通过高层领导协调更多的资源。项目经理需要让高层领导更加了解

自己的项目，需要及时准备的定期反馈和汇报项目进展，当出现资源问题时候需要有说服力的证据和

数据，通过需要提前提出问题给高层领导进行协调预留时间。

项目没有出现问题，往往高层领导认为项目运转良好而不受重视，项目经理简单认为暴露了问题可能

会使高层领导怀疑自己的管理水平，而实际隐藏问题本身，这往往导致项目最终无法实现目标交付。

因此勇于暴露项目自身问题，积极汇报高层领导，请求协调和资源是项目执行中项目经理沟通的一个

重要方面。

3.项目产出物的最终用户

用户是重要的干系人，直接关系到项目成果能否创造最大效益。在项目启动和确定范围前期，充分的

用户需求调研是必不可少的，另外在项目执行过程中可以分多个迭代周期，每一个迭代周期都可以让

用户参与进来反馈意见，及时纠正各种偏差，避免前期的缺陷泄漏导致后期过大的纠正成本。项目目

标是否能够实现是项目经理必须重点关注的，但项目说输出的成果能否赚钱则显得更加的重要，要使

产品能创造价值则必须多考虑用户的需求和反馈意见。如果在项目执行过程中，发现了一个重要的用

户反馈需要变更项目范围，在这种情况下项目经理要勇于提出并找高层领导和赞助人协调资源，而不

是置之不理的仅仅为了完成项目启动制定的目标。

4.项目组成员

项目目标制定合理，高层领导也能够保证项目资源，这个时候项目成功取决于项目经理，但项目经理

必须清楚项目成功依靠的是整个项目团队的共同努力。对每个项目成员的性格特点和技能特长进行分

析是很重要的，但之前需要先搞清楚项目能够带给项目成员什么以及项目成员能够从项目中获取哪些

收益？知脉，财脉和人脉仍然是三个重要的方面，需要根据各个项目成员不同的需求在这三个方面进

行平衡。明白了这些才可能在后期的人力资源管理和角色岗位分工中给出较合理的安排。如果项目经

理不管钱，项目成员绩效考核也不在项目经理，在这种情况下项目经理是很难对整个项目进行管理的，

及时项目经理有很强的个人领导力和权威。

二，计划过程组

凡事预则立，不预则废。项目计划是项目经理的重要一项工作，后续的项目执行监控和复盘都需要以

项目计划做为基准进行。在一份完整的项目计划中，可以看到项目目标范围，假设约束，生命周期模

型选择，WBS，估算，进度计划，人员计划，质量目标，方法工具技术都是项目计划的重要内容。在

项目计划的制定过程中有一个重点就是项目四要素的平衡，而平衡则需要培训做项目计划时候的系统

思维能力。

培养做项目进度计划时的系统观

客户最关注什么

产品质量往往是基本，这是一个默认属性。但是做到哪个度仍然可以谈，所以首先要清楚用户对质量

要求的优先级，一般来言可能是可用->易用->性能->安全。这一般叫测试类型，另外就是测试的等级

表明测试要达到何种覆盖率或程度。这些都影响到项目周期。

除了默认质量要求，项目周期往往是客户最为关注的。这个往往并不是经过详细的估算，排完进度了

再确定下来的，而是项目一开始往往就由客户敲定，而项目范围往往也是在合同就会明确下来。所以

跟用户敲项目周期就显得很重要了，根据软件工程和经济学得出结论是：对于一个软件项目我们可以

考虑投入更多资源来缩短项目周期，但当项目周期缩短到一定度以后，投入再多的资源也没有用。因

此项目经理谈判的底线为在不考虑人力资源情况下项目能够达到的最短周期，如果这个最短周期还达

不到客户要求，必须缩减项目范围而不是牺牲产品质量。

项目计划重点就是通过调整各个要素，保证项目能够有8,9成以上的胜算，对于影响到项目成功的全

部列入风险和关键问题进行跟踪。项目经理在计划完成后一大半的时间都应该花费在消除不确定性

上。项目失败往往并不是进展过程出现太多异常，而是一开始项目经理就不清楚自己有几层把握，一

开始也没有分析清楚有哪些不确定性和关键要素。

项目周期敲定了再排进度

如果简单的认为项目周期确定了再排进度就只能是倒排进度，那说明还没有真正理解各要素的平衡和

进度安排的实际含义。项目经理往往根据项目周期倒排不切实际的进度计划，那导致项目进度延期就

是必然的事情了。

制定进度前最重要的仍然是根据人力资源情况和项目周期来综合考虑生命周期模型的选择，是瀑布还

是增量迭代，这个直接影响到WBS的分解。而WBS中我们又最关心工作包或任务的粒度问题，这个需

要和可用的人力资源配合起来，一个功能模块分解细后可以更多的人力资源参与进来，使更多的任务

能够并行，但无疑会增加前面接口设计和后期集成的工作量。当接口设计和集成工作所花费时间大于

开发任务并行所缩短的时间时候，这个时候就到了分解的最小粒度。在这个粗细粒度间就是可以通过

调配人力资源能够获取的最大进度压缩。

在IT项目中由于岗位角色划分，往往并不适合采用关键路径的方法来预计进度。进度安排关键在让

所有人都尽可能早的动起来，在这里可以考虑的思考方式是:

1.关注项目关键资源，关键资源必须优先安排来执行关键任务

2.通过组件细分和迭代，增加后期集成时间，但缩短前期关键路径等待时间

3.通过每日构造将测试也迭代起来

4.进度紧往往更不该跳过需求和总体设计评审而直接编码，后期返工往往是灾难性的

最有效的方法论和过程

在裁剪过程的时候，必须清楚的认识到哪些过程元素是保证项目成功的核心要素，哪些是可以省略的。

XP方法论对于任何一个功能的开发仍然是遵循小瀑布，而不是跳过程。一个设计思路可以在纸面设

计草图后就可以开始编码，后期再形成规范的文档，但决定不是说不经过设计就开始编码。需求，D

EMO原型，总体架构，数据库设计，评审，项目开发模式和规范都是重要的元素，都应该最有效的去

发挥作用。因此以下是可以考虑的关键点

原型必须和用户沟通确认，但需求阶段技术架构工作可以并行

2.需求和架构，数据库必须经过评审

3.架构或总体设计完成后必须进行培训，强调后续的开发模式和规范

4.架构开发不一定要全部完成才能开始后续工作，但事先要定义清楚接口

4.详设可以出纸面草图，面对面沟通后即可开始编码，后期再补规范文档

5.对于100%要做的不涉及业务规则功能可提前编码，如一些基础表的维护

IT项目计划思维导图

IT项目计划主要内容总结

项目目标:包含进度,成本,质量三个方面的目标.其中成本主要是人力资源的投入.而质量目标一般应

该是产品进入维护阶段后的缺陷泄露情况.项目进行过程需求,设计和开发各阶段相关工件需要达到

的质量要求.这三个要素是项目的主要目标,相关还可能存在其它目标.如你需要控制项目范围的变化

幅度,你需要在项目过程中人员技能水平提高了怎样一个水平,你对各过程定义的偏差限度等.整个项

目管理过程和阶段的活动都是围绕相关目标进行,在有限的资源情况下按时按质的完成项目.

假设和约束:假设和约束最大的区别就是一个是确定的,一个是不确定的.假设最重要的是要出一个依

据,这个依据对项目计划过程和项目目标的实现造成影响,但根据项目现在已知因素又无法确定这个

依据是否是一定成立的.而约束则是这个依据一定是成立的,项目必须遵循这个依据.所以假设的例子

有项目假设在进入设计开发阶段后编码人员能够到位,假设项目执行过程中范围偏差不会超过10%,假

设项目估算依据的历史估算数据是真实可信的.而约束我们考虑因素同样是从项目几个要素考虑,从

进度,资源和质量等.另外要考虑的就是技术约束,如项目所使用的开发工具,技术架构,必须遵循的技

术标准等.如项目必须使用**标准开发网页以满足不同浏览器浏览,项目资源约束在**人内,项目必须

在**日发布版本等.

项目验收标准:太重要了,这是项目收尾的一个重要依据,项目收尾时候的项目验收必须通过项目验收

标准进行,防止扯皮.项目的的产出是产品,服务和成果.对于每项都必须定义明确的验收准则和标准.

因此项目交付物必须是可以验证的,如果是一个不可验证的东西则不能称为项目的交付物.

角色和职责:这个一定要分清楚,职责和职务一般只有一个,但其可以承担多个角色的任务.角色和职

责间是一个多对多的关系.如评审员就是一个虚拟的角色,可能并没有一个专门这样的职务.但需求,

设计,开发或测试人员都可以担任评审员.

项目自定义过程:CMMI三级的一个重要概念,项目应该是依据组织级的标准过程来定义项目自己的过

程,组织级可以定义相关的裁剪标准,项目依据裁剪标准对保证过程进行裁剪得到自定义的项目过程.

由于多过程或输出控件的控制问题,一般CMMI并不推荐采用敏捷或迭代的方法论或生命周期模型,现

在有专门的AgileCMMI,是研究的一个重要话题.

里程碑和基线:里程碑就是对上阶段的工作进行总结和评审,确认阶段的交付物是否达到了要求和质

量标准,确认是否可以进入下一个阶段的工作.里程碑的总历时为零.在里程碑达到并评审通过后,可

以对里程碑的所有交付物进行基线,基线的对象是配置项,基线的目的是保证工作产品的一致性,基线

的工作产品做为下一个阶段活动和任务的自己输入和依据.

项目的方法,工具,技术和标准:这几个因素都是重要的项目要素,而对于敏捷方法论或敏捷项目管理

则更强调这些要素.项目在资源和进度等都能够满足项目需求情况下仍然失败很多时候的原因就是方

法,工具或技术的选择上面出现问题.

估算:项目允许的工作量偏差或规模的偏差一般在20-30%左右，而进度偏差一般要求更严格，因此对

于估算的准确度最好能够在80%以上，如果估算不准确将导致后续频繁的调整进度计划．项目管理或

计划是一个渐近的过程，因此估算最好能够做两次，在软件需求出来后再进行一次估算，估算较为准

确的设计开发工作量．由于功能点估算一直存在的估算项无法和最终的活动和任务对应起来,估算的

数据功能的EIF和ILF无法分解到事务功能上面的问题,因此个人认为功能点估算更适合做项目总规

模的一个估算．根据总规模/生产率得到一个较为可信的项目周期数据．专家法和三点法估算是我们

常用的估算方法，三点法可以通过PERT计算出一个最可能的估算值，同时得到一个项目周期的估算

范围数据．

进度计划:再来谈下顺序问题，首先是确定清楚范围，选择项目的生命周期模型，然后进行顶层WBS

分解，对分解后的WBS进行规模的估算，根据历史的生产率数据推算出相关的工作量数据．根据WBS

确定出相关的活动和任务，对活动进行排序和建立依赖关系，确定项目的角色责任矩阵和资源分配准

则并根据该准则对活动安排资源，绘制网络图确定关键资源和关键路径，排进度表并对资源进行平衡．

在对任务分配资源的时候，优先保证关键资源分配到关键任务上面，同时当关键资源承担多个任务的

时候一个普遍原则是：

设A1,B1是两个关键任务，A的后续依赖任务是A2,B1的后续依赖任务是B2，A1可以比B1早3天开

始，A2到结束关键路径长为L1，B2到结束关键路径长为L2.

A.当两个从后续任务开始算起的关键路径长差不多时，关键资源优先开始可以提前开始的任务。即优

先开始A1任务。

B.当L1比L2短3天以上时候，这个时候反而要优先开始B1任务，虽然这个时候开始要闲置关键资

源，这点很重要。

人员计划：最主要是就是分阶段的人员投入计划．对于软件开发项目一般在需求和总体设计阶段仅仅

需要投入20-30%的人员即可．因此人员计划最好是分阶段投入的计划．投入人员必须规定相关的技

能要求，规定了技能要求后需要对项目人员进行技能评估，如果项目成员的技能达不到要求，则还需

要制定相关的培训计划，并对培训效果进行跟踪，并将该项列入项目的风险跟踪和控制．

人员技能:一般要求开发人员至少应该有1-2年的工作经验,这应该是一个基本的要求.智商再高,基

础理论再好没有经过一段时间的实战相关知识是不可能转化为技能的.但过了1-2年这个阶段,工作

经验和技能就是非线性的关系了,并不是说你工作经验长你的技能水平就一定高,这跟个人和环境等

诸多因素相关.工作了5年或8年的可能技能水平一般,而工作了2年的可能技能就能够达到专家水

平.

风险计划：风险管理是项目管理的一个重要内容，风险管理的过程贯穿整个项目生命周期。风险管理

计划中首先要确定风险管理小组的成员和各自的职责，对于PDM项目，风险小组负责人为项目经理.

风险小组确认后就要确定风险管理过程中需要使用的相关的工具和方法。其中包括风险识别的方法，

风险分析的方法，风险监控的方法和风险应对的方法。这些方法和工具组织级都有明确的定义和指导

原则，对于存在多种方法时要根据项目实际情况选择。

对于项目的风险来源和分类，组织级都有明确的标准和定义，项目一般都可以直接采用，但需要注意

的是有可能需要项目实际情况对其进行裁剪。如项目本身不可能存在采购方面的风险时候，就需要将

其裁剪到，这样在后续的风险识别和分析中都不用再过多考虑。

项目计划中的风险应对策略不是针对某个特定风险的，所以这里的应对策略更多是通用的应对策略：

如开发原型，技能评估和培训，数据模拟等。当遇到实际的风险时候，如何去应对还要根据风险的实

际情况进行分析。

项目计划阶段就应该分析出项目在当前状况下的所有风险，并对风险进行优先级排序，当确认了是项

目的关键风险后，需要制定这些风险的减轻计划和应对措施，这些内容都需要体现到进度计划中，进

度计划必须包含这些内容才是一份完整的进度计划。

在当我们积累了足够多的历史数据后可以对风险进行组合分析和量化分析，对于风险量化分析可以采

用决策树和蒙特卡洛模拟等方法进行。具体的方法可以参考以下文档

质量计划:项目计划中要做的质量计划和QA要出的质量保证计划完全是不同的．QA的质量保证计划

关注点在过程和工件的一些审核上面，保证项目遵循计划和过程执行．项目计划中的质量计划更多倾

向去产品的质量和要达到产品质量需要采取的控制措施．质量目标中来源与用户对质量的要求，来源

于项目至少质量改进需求，来源于历史项目的相关经验，因此首先应该制定出相关的质量目标，然后

根据质量目标去估计项目的缺陷趋势和各阶段缺陷数，为了达到质量目标所需要投入的评审，测试和

Review等相关的工作量．对评审和测试的覆盖率的要求，有这些数据后就可以估算出项目的质量成

本COQ,COPQ和COGQ.

IT项目计划核心要素

1.产品范围可以是用户需求说明书，产品规范，合同SOW，项目建议书等。产品范围和项目范围差别

在此不再多说，根据产品范围和项目的目标来选择项目要选择的方法论。对于软件项目开发，

RUP,XP,MSF等都可以算得上成熟的软件项目开发和管理的方法论。在方法论选择中的一个重点才是

软件生命周期模型的选择，究竟选择瀑布，增量还是迭代要根据项目特点和目标来确定。

2.项目范围很重要，PMBOK里面谈的时候包括项目范围说明书，WBS和WBS字典三方面的内容，共同

组成项目范围基线。简单讲你在项目进行过程中做的任何为了达到项目目标的工作都属于项目范围。

你发现项目成员技能水平有问题，给项目成员进行了一项培训，那么这些培训工作就属于项目范围而

不属于产品范围。有了这个概念就清楚了项目范围中应该包括风险分析后的具体应对活动，包括培训

活动，包括为了达到质量进行的评审和检查等活动。这样才可能构成完整的项目范围。

3.风险分析很重要，风险管理活动贯彻整个项目计划过程，确定项目范围WBS,估算资源活动，排具

体的进度的任何步骤都可能会分析出新的风险，对于分析为关键风险的要制定减轻措施和计划，因此

这些计划活动应该加入到项目范围和WBS中。

4.项目目标中有个重点就是质量目标，这个是制定项目计划容易忽视的，有了质量目标你才清楚整个

项目需要投入多少培训，需要安排多少评审和检查。你对好质量成本和坏质量成本的预计。很多时候

我们制定出来的进度计划根本没有评审，培训，检查等相关任务，从源头来讲就是忽视了质量目标。

这些活动和任务都应该是质量目标驱动出来的，是属于项目范围重要组成。

5.在排进度计划中的一个重点就是项目的人员技能分析，资源评估，角色技能矩阵。资源不是无限的，

导致进度计划受到资源约束是常见的事情，因此进度计划中的关键路径往往只是一开始的一个参考，

在考虑了资源约束和平衡后整个进度都会出现大的调整。对于这点关键链是一种比较好的方法，但关

键链并没有能给出一种成熟的规则和算法，仅仅是给出的可行的操作指导。

6.项目计划必须获取项目成员的承诺，如果有必要还需要组织正式的评审。评审过程中还可能发现进

度安排不合理的地方，项目范围考虑疏漏的地方，这些都会再回答项目范围确定过程，完善WBS并调

整项目进度。只有获取了承诺才能确定项目计划基本上是可行的，得到了大家认同的。为后面具体任

务执行打下基础。

IT项目管理-计划-目标范围确定

有了初步的项目范围，并委任了项目经理后可以进入到项目计划阶段，做项目计划过程仍然是目标驱

动，树立系统观和关注各要素的平衡。因此首先需要确定项目的目标和项目的范围。

1.项目目标的来源和包含的内容

项目的目标不是无源之水，项目目标必须来源于组织的商业目标，而组织的商业目标就是在某个时间

期限中获取最大的效益和利润。因此，有了商业目标驱动，项目目标应该包含进度，质量，成本三方

面的目标，具体三方面的目标如何平衡即是通过组织期望获取价值和创造利益的过程是一个短期行为

还是一个长期行为。

进度，质量，成本三方面的目标都会有一个最低限的目标，当发生最低限目标都无法满足的情况最有

效的方式就是削减项目范围，如果范围也不能变动则必须提高项目团队的生产率。

项目目标根据商业目标确定，而项目目标确定后又驱动项目计划的具体制定过程，项目计划中关于进

度，人力，资源，成本，质量等目标的安排都应该围绕项目目标进行。

2.项目目标的确定过程

首先必须搞清楚用户真正的需求和组织的商业目标，然后根据商业目标确定项目四要素中关键要素和

约束(不能变动或变动范围很小的要素)。

对于其它可变要素间本来就会存在影响和相互制约，比如多投入项目成本可以获取到更好的产品质

量。因此需要对各可变要素进行多种组合分析，分析在哪种组合下对于企业在某个时间期获取到最大

收益是最有利的。

一个好的项目目标必须和企业商业目标一致，最终体现到项目创造的产品和服务能够为企业创造最大

的价值和收益(包括潜在的无形收益)。

3.项目的范围

项目范围和产品范围不同，产品范围关注的是产品各阶段产出物本身以及整个包括了项目完成后维护

的产品生命周期。而项目范围来源于产品范围，来源于产品需求和用户需求。通过对产品需求和用户

需求的分析，根据选择的产品生命周期模型制作相关的WBS分解结构，前期需求文档或SOW工作

说明书，加上WBS工作结构分解共同构成了项目的范围，也可以简单理解项目范围就是项目正式启

动后到项目结束所做的任何事情都应该体现到项目范围中。

在计划阶段我们会对风险进行识别和分析，针对关键风险会制定风险应对和减轻计划，这些减轻计划

会对应项目中相关活动和任务，这些也属于项目范围的重要组成。

为了使项目达到预期的质量目标可能会增加评审，测试，培训，代码Review等相关工作，这些工作

都是项目范围的重要组成部分。项目日程固定周期的会议，项目经理对项目的跟踪控制，项目计划的

制定过程等内容也属于项目的范围。

4.项目的范围定义的目的和要素

项目范围的定义是制定WBS工作分解结构，项目估算，进度安排。项目变更，跟踪控制，基线比较

的基础。项目计划阶段项目范围必须明确，项目管理过程只应该做该做的事情，因此范围既不能遗漏

也不能镀金。

项目范围必须是明确和可以验证的。因此WBS对应的分解工作包也必须有明确的可以验证的输出。

项目范围的要素或输入有产品规划，立项报告，SOW,用户需求，产品需求等，这些都可能是项目范

围重要输入。

IT项目计划中的假设约束，依赖和承诺

项目中的假设约束依赖和承诺是制定项目计划的时候要确定的内容。

项目假设是我们先说严格意义的和非严格意义的：严格意义是在当前时间点根据当前拥有的各种工具

无法确定的事物或事件，而且这些事件会对你的项目造成影响。你的项目是在假设条件成立的情况下

进行了。由于假设是不确定因素，所有项目的所有假设都是项目的风险，只是风险的严重程度不同而

已，对于关键的风险应该转化为项目的风险，在后续进行风险的分析和跟踪。比如项目现状是没有测

试人员，你可以假设项目在进入测试阶段的时候，能够招聘到两名技能符合要求的测试人员。同时可

以将该条假设转化为风险，即可能存在无法招聘到测试人员，而影响测试和整体进度的风险。

另外还想说的是非严格意思的假设，比如我们经常和别人讨论问题时候爱说假设你的说法是正确的，

这个应该说是一种非严格意思的假设，因为在当时这个点究竟他的说法是否正确是可以通过其它评估

方法或工具进行判断的，是一个确认的事情，而不是远期未确认的一个预测性的事情。所以说对于根

据自身或组织级的现有条件无法来评估的现在的某一个事物或事件。这也可以做为假设。在项目开始

时候，我们可能并没有一套很体系化的评估和测评工具能够来测评我们每个项目成员的技能是否达到

要求，所以可以做个假设，假设项目中的每个成员都达到了组织或项目要求的技能要求。

而约束，是指所有对你项目有制约性的内部或外部因素都可以做为约束。约束有技术方面的约束如系

统的开发必须采用分布式技术，约束也可能是非技术性的，如项目的资源或成本方面的约束。约束应

该是一个在项目过程中不会发生变化的客观因素，因此比如项目中有新员工技能不能满足要求这就不

应该做为项目的约束，因为这个约束是动态变化的，在项目的进行过程中由于新员工技能的提高，这

个约束可能就不会成立了。另外约束也可以转化为风险进行跟踪，如项目可能存在某项约束不能满足

的风险。

项目的依赖和承诺都分为项目内部的项目外部的。依赖和承诺密切不可分。下游工序依赖于上游工序

的产出物，而上游工序需要做出承诺在哪个时间点给下游工序交出工件。项目内部的依赖可以体现到

进度计划的甘特图上面，我们在对任务进行排序并分析了任务的依赖关系后就可以根据网络图得出项

目的关键工序以便安排项目资源。项目外部的依赖主要是项目中的某项任务需要外界提供相关的产出

作为支持，如开发阶段任务需要一个其它项目提供的公用组件。由于外部依赖没有体现到项目进度计

划中，而且外部依赖很多时候项目自身无法控制，所以外部依赖更应该通过专门的跟踪表进行跟踪，

要提前多做相关的沟通和确认工作。

项目内的承诺是项目进度跟踪的一个重要内容，项目经理下达给项目成员的任务，项目成员接受了项

目任务就默认的承诺能够在相关时间点完成该任务，项目经理就需要去跟踪和确认任务能否按时完

成。而项目对外部的承诺则可能很多，如项目承诺在某个时间点给其它项目一个公用的接口，项目承

诺在哪一天能够正式发布版本等。不管是项目对内或对外的承诺，最好都能够转化成Project具体的

任务，这样方面项目进行跟踪和控制。

IT项目计划-软件生命周期模型和选择

瀑布模型/改进的瀑布模型

虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软

件开发生命周期模型.瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段进行,

每一个阶段都可以定义明确的产出物和验证准则.瀑布模型在每一个阶段完成后都可以组织相关的评

审和验证,只有在评审通过后才能够进入到下一个阶段.

由于需要对每一个阶段进行验证,瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模

型每一个阶段都不应该重叠,而应该是在评审通过,相关的产出物都已经基线后才能够进入到下一个

阶段.

瀑布模型的优点仍然是可以保证整个软件产品较高的质量,保证缺陷能够提前的被发现和解决.采用

瀑布模型可以保证系统在整体上的充分把握,使系统具备良好的扩展性和可维护性.但对于前期需求

不明确,而又很难短时间明确清楚的项目则很难很好的利用瀑布模型.另外对于中小型的项目,需求设

计和开发人员往往在项目开始后就会全部投入到项目中,而不是分阶段投入,因此采用瀑布模型会导

致项目人力资源过多的闲置的情况,这也是必须要考虑的问题.

很多人往往会以进度约束而不选择瀑布模型,这往往是一个错误的观点.导致这种情况的一个关键因

素往往是概念需求阶段人力不足.因此在概念需求阶段人力能够得到充分保证的情况下,瀑布模型和

迭代模型在开发周期上并不会存在太大的差别.反而是很多项目对于迭代或敏捷模型用不好,为了赶

进度在前期需求不明确,没有经过一个总体的架构设计情况下就开始编码,后期出现大量的返工而严

重影响进度.

架构设计是软件开发中一个重要的关注点.因此在RUP中也提及到软件开发要以架构为核心.因此在

架构设计完成后系统会被分为相关的子系统和功能模块.每个功能模块间的接口都可以定义清楚.在

这种情况下,当模块B的详细设计做完成后往往就没有必要等到其它模块的详细设计都要完全作完才

开始编码,因此在架构设计完成后可以将系统分为多个模块并行开发,每个模块仍然遵循先设计和编

码测试的瀑布模型思路.这是瀑布模型的一种最重要的改进思路,也可以说这是一种增量开发的模型.

当一个新系统的开发存在多个完全不相关的独立需求的功能开发的时候,这个时候也可以选择将整个

开发过程按独立的需求来分为多个小瀑布进行操作.这种方式的最大问题就是没有一个完全总体的设

计,架构设计人员无法在洞悉了所有需求后从系统的可扩展性,复用等方面总体规划.

在项目管理中有一种压缩进度的方法叫赶工,因此瀑布模型的另外改进处就在适当的重叠各个阶段过

程,达到资源的有效利用.比如我们通过讨论,会议确定的实现方式就可以开始执导下一个阶段的工作

而不一定完全等到相关的交付物文档化出来.

螺旋模型

首先螺旋模型是遵从瀑布模型的.即需求->架构->设计->开发->测试的路线.螺旋模型最大的价值在

于整个开发过程是迭代和风险驱动的.通过将瀑布模型的多个阶段转化到多个迭代过程中,以减少项

目的风险.

螺旋模型的每一次迭代都包含了以下六个步骤

1.决定目标,替代方案和约束

2.识别和解决项目的风险

3.评估技术方案和替代解决方案

4.开发本次迭代的交付物和验证迭代产出的正确性.

5.计划下一次迭代

6.提交下一次迭代的步骤和方案.

螺旋模型实现了随着项目成本投入不断增加,风险逐渐减小.以帮我我们加强项目的管理和跟踪,在每

次迭代结束后都需要对产出物进行评估和验证,当发现无法继续进行下去时可以及早的终止项目.

螺旋模型复杂的地方在于尽责,专心和知识渊博的管理.因为对于每一次迭代我们要制定出清晰的目

标,分析出相关的关键风险和计划中可以验证和测试的交付物并不是一件容易的事情.

螺旋模型的每一次迭代只包含了瀑布模型的某一个或两个阶段.如第二次迭代重点是需求,第三次迭

代是总体设计和后续设计开发计划等.因此这是和RUP提倡的迭代模型是有区别的,RUP的每一次迭代

都会包含需求,设计,开发和测试等各个阶段的活动.RUP迭代的目的在于逐步求精而不是仅仅完成瀑

布模型某一阶段的工作.

增量和迭代模型

增量迭代是RUP统一过程常采用的软件开发生命周期模型.增量和迭代有区别但两者又经常一起使用.

所以这里要先解释下增量和迭代的概念.假设现在要开发A,B,C,D四个大的业务功能,每个功能都需

要开发两周的时间.则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B

功能,第二次增量完成C,D功能;而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,

D四个基本业务功能但不含复杂的业务逻辑,而第二个功能再逐渐细化补充完整相关的业务逻辑.在第

一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,

B,C,D四个的基础功能都已经完成.

RUP强调的每次迭代都包含了需求,设计和开发,测试等各个过程,而且每次迭代完成后都是一个可以

交付的原型.迭代不是并行,在每次迭代过程中仍然要遵循需求->设计->开发的瀑布过程.迭代周期的

长度跟项目的周期和规模有很大的关系.小型项目可以一周一次迭代,而对于大型项目则可以2-4周

一次迭代.如果项目没有一个很好的架构师,很难规划出每次迭代的内容和要到达的目标,验证相关的

交付和产出.因此迭代模型虽然能够很好的满足与用户的交付,需求的变化,但确是一个很难真正用好

的模型.

就对风险的消除上,增量和迭代模型都能够很好的控制前期的风险并解决.但迭代模型在这方面更有

优势.迭代模型更多的可以从总体方面去系统的思考问题,从最早就可以给出相对完善的框架或原型,

后期的每次迭代都是针对上次迭代的逐步精化.

业界比较标准的增量模型往往要求在软件需求规格说明书全部出来后后续的设计开发再进行增量.同

时每个增量也可以是独立发布的小版本.由于系统的总体设计往往对一个系统的架构和可扩展性有重

大的影响,因此我们推荐的增量最好是在架构设计完成后再开始进行增量,这样可以更好的保证系统

的健壮性和可扩展性.

原型法

原型一般都不是单独采用的一种生命周期模型,往往会结合瀑布和增量迭代等方法一起使用.对于螺

旋模型就可以理解为瀑布+迭代+原型+风险的一种生命周期模型.对于迭代开发来讲,每一个迭代周期

的产出都可以看做是下个阶段要精化的原型.而对于瀑布模型开发来讲,我们在需求阶段也可以进行

界面和操作建模,形成DEMO后和用户做进一部的需求沟通和确认.

当你的用户没有信息系统的使用经验,你的系统分析员也没有过多的需求分析和挖掘经验的时候,需

求分析和调研过程则更需要是一个启发式的过程.而原型则是这种很好的启发式方法,可以快速的挖

掘用户需求并达成需求理解上的一致.否则即使双方都签字认可的需求往往仍然不是客户真正想要的

东西.

原型可以分为抛弃型的和不抛弃型的.如果原型仅仅是需求阶段方面和用户沟通画的DEMO,则这种原

型一般都建议抛弃掉.而对于迭代开发来将,每次迭代的产出都是可以独立运行和包含基础功能的系

统,是后续细化的基础,这类原型一般都不建议抛弃,后期的设计开发也要基于该原型逐渐的进行完

善.

快速和敏捷开发

我们一般将快速和敏捷开发做为方法论,而很少将其做为一种软件开发生命周期模型.敏捷的目的是

减少繁重和不必要的工件的输出,提高效率.而不是要我们去挑阶段或过程,不是分析设计都还没有做

就去做开发.因此对于瀑布,增量迭代或原型我们都可以借鉴敏捷方法论中的一些好的实践,这些实践

都是对传统的生命周期模型很好的补充.对于敏捷方法论在此不再做过多的叙述.

关于选择生命周期模型的最后的总结

1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.

2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.

3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型

4.在需求不稳定情况下尽量采用增量迭代模型

5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布

6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型

7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.

8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.

9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则.

IT项目管理-计划-WBS

2004年版PMBOK指南对WBS的解释：WorkBreakdownStructure（WBS）工作分解结构：对应当由

项目团队执行以便实现项目目标，并创造必要的可交付成果工作，按可交付成果所做的层次分解。WBS

将项目的整个范围组织在一起并加以明确。每向下分解一个层次，就意味着项目工作的定义深入了一

步。WBS最终分解为工作细目。WBS的层次结构以可交付成果为对象，包括内部和外部可交付成果。

WBS和WBS字典是项目范围的核心，通过WBS分解真正使项目目标和范围和项目进度中具体的工作任

务有效的衔接起来。WBS分解的难点不在是否有WBS模板，不在于WBS分解的方法和层次，分解的粒

度等内容，更多的困难点在项目管理组要对整个项目目标范围相当熟悉，要对特定业务领域的业务运

作和管理相当熟悉。比如对于IT项目如果对软件项目管理方法论，软件过程改进，软件工程和生命

周期不熟悉，或者没有积累如果经验很难分解出有效的WBS。

分解WBS，确定活动任务，已经活动排序依赖这些都不是孤立和严格先后关系的过程。在这个过程中

不断的存在着反复和调整，调整重要目的仍然是保证制定出有效的进度计划，保证后期的质量和成本

控制有基准。WBS的最底层是工作包，工作包必须是严格的输出物并且可验证。对于小型项目个人认

为工作包可以直接作为任务下达。

WBS是项目范围的全集，但不要忽视了WBS字典，WBS字典是对WBS每个分解项要求的详细描述。简

单讲，项目进展过程中的任何产出物，任何活动都应该在WBS中有体现。项目执行中应该只做应该做

的事情，不能遗漏也不能镀金。WBS分解的越清晰，完善，说明项目管理组对整个项目全景的把握越

好，越心中有数。

对于软件项目，我们最终需要提交的是软件产品，因此WBS的核心应该是结合了软件开发生命周期模

型的产品分解结构(PBS)。PBS再结合项目管理过程，配置变更等支持过程共同构成工作分解结构。

因此WBS应该是包含了工程域，管理域和支持域的内容，其核心是产品分解结构，其它活动和任务都

是保证项目目标，保证产品能按质按时完成。

IT项目计划-估算杂谈

规模，工作量，资源和工期

软件项目的复杂性就在于这几个因素间基本都没有简单的线性关系可寻。在项目过程不成熟或积累的

历史数据不够的时候，慎用直接估算规模的方法，因此及时估算了规模也不清楚团队的实际生产率情

况，无法根据规模推出具体的工作量。在这种情况下一般可以直接估算工作量，在项目进度跟踪过程

中再收集产出物的规模数据以积累历史数据，方便后期建立相关的预测模型。

功能点和代码行是可采用的规模数据，但采用代码行时候往往无法区分不同的代码类型本身往往具有

不同的复杂度，对于逻辑层实现算法的代码和UI层实现简单完整性代码，虽然可能相同的代码行，

但其复杂度不同将直接导致工作量的不同。对于任意一个功能点的开发基本都会涉及到DB,逻辑层和

UI代码，因此可以给出一个综合的代码生产率数据，然后根据该数据到计算工作量。

当新项目的规模比历史项目规模大几倍的时候，往往工作量会成指数级增长，在这种情况下要谨慎采

用原来的线性比率关系。可以借鉴Cocomo模型来估算项目的工作量和项目工期。当预计出项目工作

量人月后，最好能够根据历史经验和模型来预测在不考虑人力资源限制情况下项目可以完成的最短周

期。虽然这个时候还没有考虑活动任务排序和资源约束，但基本可以得出一个经验数据。

WBS分解和估算的关系

项目在做详细估算的时候往往项目周期已经确定，因此为了可以满足进度WBS的分解粒度和进度的

安排就至关重要了。比如在开发阶段现在有四个人可以进行并行开发，这个时候WBS最好能细化出

四个可以并行的任务,当发现预排的进度无法满足要求的时候，需要再投入4个人，这个时候就需要

WBS进一步分解以满足8个人能够同时进入并行开发。当WBS分解导致后期集成工作量超过并行节

约的时间时候，基本就到了进度能够压缩的极限。所以WBS和估算没有完全的先后关系，分解后进

行估算，在估算过程中又在调整和分解WBS。

当项目人力资源很固定的时候，WBS分解更需要按现有人力资源情况进行考虑和分解，这个时候分

解的粒度最好和项目可用人力资源匹配。总体原则仍然是前紧后松，让项目人力资源在项目一开始就

能够完全动起来，而不是要漫长的等待前续工件和任务。

当考虑了人力资源仍然无法满足进度要求的时候，需要考虑我们采用的方法论，如是否可用增量迭代

的方法替换瀑布模型，如果可以则需要完全根据增量迭代思路重新分解WBS，对于采用不同生命周

期模型情况下WBS往往存在较大的差异。

当以上仍然无法满足进度要求的时候，我们可以考虑对过程进行裁剪，重点保证对产品质量又重大影

响的核心过程元素。当进行过程裁剪仍然无法满足的时候，你需要考虑的是人的因素，去寻找开发生

产率比一般人高5倍以上的开发高手，而不是在明知WBS无法细分的情况下继续往项目里面投人。

估算方法

在项目没有太多积累情况下，依赖专家去估算往往是最有效的方法。专家估算是一种没有纸面化的

Bottom-Up估算方法，因此专家法估算的准确度往往是比简单的类别估算准确度高的。采用三点法估

算的计划评审技术仍然是专家法的一种，这种方式的估算可以让我们更加清楚项目进度的一个范围

值。

功能点法是一种经过实践验证的方法，但应用成本很高，估算的工作量投入也较大。功能点法最终结

果是规模，仍然需要知道项目的生产率数据才能得出实际的工作量。另外功能点法估算的结果无法直

接和WBS分解的工作包和具体的任务对应起来，这是一个较难解决的问题。

Cocomo估算是一种关于软件成本估算的方法，但仅给出一个可行的模型，项目没有足够多的历史数

据根本无法确定出各调整因子和系数。但一旦项目建立起这种模型，则通过Cocomo模型得出的项目

工作量和项目周期具有更高的准确度。

观察历史项目中工作量和项目规模的数据，通过回归拟合可以得出生产率，工作量，生产率三者间的

参数模型，这个参数模型可以用来我们通过软件项目的规模来预测实际的工作量。

估算的科学和艺术

估算模型是科学，专家经验是艺术

估算过程是科学，灵活调整是艺术

参数模型是科学，个体影响是艺术

过程定义是科学，过程裁剪是艺术

IT项目管理-计划-进度计划的关注点

WBS确定后项目详细范围基本确定，在PMBOK的时间管理里面有详细的进度计划制定步骤。活动

定义->活动排序->估算资源->估算历时->制定进度表，同时也提及到了估算方法，关键路径，PERT

网络，关键链，资源平衡等重要内容。但在整个过程中有太多的假设，假设创建出来的是理想化的进

度表，而我们需要的是可行的进度表。

1.进度计划不要去追求理论最优，而应该考虑可行性和对目标的满足。

2.在活动定义和排序估算中都可能会发现WBS分解层次，粒度，遗漏等问题

中制定进度各步骤并没有严格的先后关系,IT项目强调关键点是WBS,估算有后即可制定进

度。

项目进度安排的首要目标:在满足质量和成本要求的情况下，满足项目预期的进度要求。因此从这个

目标出发需要优先考虑两个问题，一个就是软件生命周期和方法论的选择，一个就是团队组建，人员

的搭配和角色安排。而这两个问题都是基于一个目的，或者说是基于TOC约束理论的思路，不要在

项目执行过程中因为瓶颈存在使过多的人员闲置和等待，而是要达到人力资源最佳配置和最有效的利

用。

4.制定进度前往往就已经想好了开发方法论选择和人员角色搭配安排。

5.瓶颈造成资源利用不均和等待，进度安排中资源利用最大化是TOC一个重要体现。

6.在生产管理中一般在瓶颈资源前预留缓冲，而在关键链中是要考虑在路径汇聚点(最大风险处)前预

留缓冲。

7.小型敏捷团队，整个计划中如果出现前期资源不饱和和空闲是要命的事情。

瀑布，迭代还是敏捷开发？关键需要解决的还是最大化的降低后续工序资源的等待时间。对于中小型

短周期的项目一般适合采用迭代或敏捷的开发方法。但敏捷不是跳过程，敏捷或迭代最好是基于前期

整个开发模式和功能框架都已经确定后再进行，这里指的并行是多个需求功能点的并行，对有严格依

赖关系的，对同一个功能点的需求，设计，编码多道工序而言仍然是串行。

8.任何方法论都不会是跳过程，而是将大瀑布转换为小瀑布。

9.并行和敏捷后势必影响到总体规划和系统思考，务必重视带来的需求不清和架构风险。

网络图是进度中的一个重要工具，目的仍然是对发掘各活动任务的依赖关系并对活动进行排序。在软

件项目中为了加强迭代和并行，一个重点就是要将强制依赖转换为非强制依赖，要将对整个设计开发

过程的依赖转换为对接口的依赖。因此这里也可以看到架构设计和接口设计在整个软件开发中的重要

作用，比如其他功能模块都要依赖系统管理和工作流相关功能，如果要等这些功能全部开发完成再进

行后续开发则其他资源等待时间太长，常用的处理方式就是架构只需要定出系统管理和工作流调用相

关接口，后续开发工作全部可以提前介入和并行起来。多出的代价则是后续需要有一个产品和功能模

块的集成过程。

10.通过架构和接口设计，将对整个功能模块的依赖转换为对接口的依赖。

11.架构设计和产品集成是网络图中依赖关系需要分析的重要内容。其他活动依赖关系都是简单的基于

小瀑布的线性依赖关系。

12.迭代的思路仍然是架构为核心，架构接口定义不清不应该过早进入设计开发。

对活动和任务工时的估算又是一个重点内容，估算跟任务粒度，复杂度，任务依赖，责任人技能，开

发方法等多种因素相关。在没有多个版本的历史经验数据积累的情况下，很难真正实施参数估算或功

能点估算方法，估算更多的是依赖于项目组成员的经验。关键链法推荐两点估算法，将进度缓冲留到

末尾，但仍然是基于估算工时是可以完成的，而不是倒推出的不可能任务。在进度压缩中我们可以多

投入人力资源，但有一个压缩的极限值，在这个临界点后投入再多的资源也无法再压缩。

13.在没有太多历史数据积累情况下，最有效的估算就是依赖专家经验。

14.根据关键链思路，不要在对单个任务的估算上预留太多的缓冲或余地。

15.先确定活动或任务的责任人，再来估算工时以遍考虑个体生产率对工时的影响。

项目计划四要素基准的确定

IT项目计划-方法工具和技术

关于项目中方法，工具和技术的说明是一个很重要的内容．都是项目管理的重要元素．特举个项目中

的例子如下：

项目中的方法

1.项目采用了RUP的相关方法论，以用例分析为驱动，得出相关的软件需求说明书和用例模型；以架

构设计为核心，在软件需求基础上进行4+1视图的架构设计，得出相关的分析模型；具体的增量迭代

在需求和架构上不迭代，在后续的结队开发中进行迭代。

2.项目借鉴敏捷开发的部分方法论，在结队开发任务中强调设计开发人员的紧密协作和工件的Revie

w和单元测试。强调项目个体技能对项目重要性；强调整个团队价值观对项目成功的重要性。

3.项目借鉴MSF的相关方法论，对项目人员角色和职责进行了明确的划分，保证了角色和职责的明确；

在项目过程中采用每日构建流程，保证相关功能的持续集成和问题的及早暴露和发现。

项目采用的工具和技术

1.需求采用Ro出用例模型和业务对象模型，采用DotNet2003开发界面原型。采用Word出软件需

求说明书。

2.架构和设计采用Ro或XDE出分析模型和设计模型，采用PowerDesigner出数据库设计，采用Do

tNet2003出相关的原型。

3.编码采用DotNet2003完成前台编码。采用PL/SQLDeveloper或Toad完成后台数据库表和存储过

程编码。

4.测试采用Nunit进行单元测试，采用LoadRunner进行性能测试。

5.项目方面采用CQ进行需求变更和BUG的管理；采用CC进行项目数据的管理；采用Excel进行测试

用例的管理和追踪；采用RP进行需求追踪和需求状态的管理；采用***进行项目任务的管理；采用*

**进行度量数据的收集后分析；采用**系统管理相关的同行评审。

IT项目计划-人员岗位角色划分

职责和角色不清楚往往是造成软件项目团队管理混乱的一个重要原因，一个好的软件团队必须根据团

队规模的不同和项目本身的特点对项目成员的角色和岗位进行明确的划分，这样团队中的每个成员才

可能有清晰的责任和目标。

软件开发不管采用哪种生命周期模型和开发方法论，整个过程都会包含需求，设计，开发，测试，配

置管理等各项活动。而这些活动会对应到项目中的不同角色，项目中进行岗位划分后每个岗位成员可

以兼职多个角色。形成相关的角色岗位矩阵。

方案一:项目负责人总览全局。

对于小作坊的软件开发团队，可以由一个项目负责人总览全局。项目负责人承担从用户需求->软件需

求->总体设计的所有工作。同时还需要做到整个团队进度规划，质量保证，配置管理和沟通协调等相

关工作。所以小型项目团队对项目负责人的业务，技术和沟通管理等技能都要求较高，项目负责人是

项目中的总体方案确认者和架构师。项目负责人能力和技能往往决定了整个软件项目的成败。

我们这里指的小型团队并不是只一个人单打独斗的项目，所以项目负责人最好不要介入到模块设计和

编码活动中，而是应该把重点放在进度的控制和质量的保证上面。由于项目负责人一般有较强的技术

能力，所以项目负责人可以承担项目中要使用的一些新技术的研究，项目中一些疑难问题的解决等相

关工作。项目负责人还应该有计划的设计开发人员的代码进行Review，对发现的规范性，性能，复

用差等问题跟项目成员确认，并写入到项目开发规范中。

方案二:项目负责人和开发负责人分离

在这种方案下项目负责人和开发负责人在软件需求和架构上的工作是重叠的。这两个岗位的人员共同

来确认项目的总体方案和架构。项目负责人的重点在项目管理和与客户交流沟通上，只有确认清楚第

一手的用户需求，才能开发出用户满意度高的软件。对于很多小型项目往往是用户需求都没有搞清楚

就开工，项目成员完全凭借着自己的感觉在做系统，过程中又不注意与用户及时反馈和迭代，导致开

发出完全不能使用的系统；开发负责人的重点是对整个开发过程负责，包括对项目经理确认的进度目

标进行任务的进一步分解，安排后续的增量和迭代计划。方案二的重点是第一次解放项目经理，架构

的核心移动到了开发负责人，而项目经理仅仅是参与讨论和评审。而单独剥离出开发负责人后，可以

更好的对开发过程进行跟踪和协调，开发负责人重点放在项目内部，而避免过多去和外部干系人沟通

和协调。

方案三:测试的专职化

对于项目团队发展到5-10的时候，项目中的测试工作必须专职化的由测试人员来完成。一般测试人

员的配置比例为4-6个开发人员需要配置一名专职化的测试人员。测试人员站在第三方和模拟使用者

角度来进行系统的测试，可以更好的发现系统的BUG和相关问题，有效的保证系统的质量。

方案三中项目经理工作进一步清晰，项目经理不在承担软件需求和架构的相关工作。而重点放在项目

内外的沟通协调和整个项目进度计划的安排上。这个时候项目中的设计负责人对整个系统的总体设计

方案和架构负责，而且设计负责人也将不在参与具体的功能模块的设计和开发工作。设计负责人的重

点转化到的软件需求的开发和总体设计上面(如涉及到RUP中的用例建模，用例分析，架构设计，组

件接口复用)。

方案四:项目经理和需求角色分离

当项目团队的规模发展到12-20人的时候，项目团队基本上可以算做中小型的项目团队。这个时候项

目经理完全专职化做项目管理的工作。包括项目进度计划制定，项目跟踪监控，风险分析和控制，项

目度量分析和决策等相关内容。对于需求活动设置专门的需求工程师岗位来完成需求的开发。同时项

目中设置专门的架构设计人员，架构设计人员不再负责需求的开发工作，而重点在于系统总体设计方

案的确定，系统的4+1视图的分析，同时架构人员要考虑整个系统的集成方案的确定和具体功能单元

和模块的集成。

由于项目规模的扩大，项目的配置项更加复杂，项目也需要同时起开发，测试，集成和BugFix等多

个分支。因此需要设置专门的配置管理员来进行项目的配置管理。

对于项目同时需要开发新版本，又需要对已经发布的维护版本进行功能改进的时候，项目中要考虑设

置专门的维护人员。由维护人员来完成项目小功能的改进和BUG的修复。这样新版本设计开发人员可

以更专注的进行新功能的开发。

附RUP提供的20人团队的具体人员安排方案：

IT项目计划中质量目标的确定

一个软件项目除了进度目标外，另外一个最重要的目标就是质量目标，而质量目标并不是简单指版本

发布的时候测试问题全部解决，而更多关注的是你版本发布后的缺陷泄露情况，这个质量目标在项目

完成的时候无法马上得到数据和进行验证的。所以一般是通过间接控制的方式，即可以去估计我们期

望的缺陷和BUG的发现情况，当质量目标高的时候，就期望在评审和测试阶段近可能多的发现BUG，

自然泄露到版本发布后的缺陷就少。

由于一个项目版本的总缺陷数量应该是一定的，只是在交付后发现出来还是在交付前发现出来。如果

能够在交付前发现出来我们软件的质量就高。BUG缺陷密度，总缺陷数，交付后缺陷数，代码行这

些指标间有着相互影响和作用。在作一个项目版本的时候，应该对这些关系有比较明确的了解，具体

关系如下图(中间为交付前BUG比重)

你缺陷密度是10，但你期望交付后缺陷密度是0.8这显然是很难做到的，所以上表中的绿色底纹数据

是我们可以参考和借鉴的数据。

对于项目历史版本数据统计，缺陷密度一般在4-6之间，因此交付密度采用0.8或1都是可行的。对

于交付后的软件的缺陷数据，CMMI三级的企业一般在0.5-1.5个/千行代码，CMMI四级企业在0.5

个/千行代码。所以根据业界这个标准和组织级的建议，项目V4.0版本采用的交付后缺陷密度为0.8

个/千行。

在项目V2.6版本，项目就根据组织级的规程仔细进行了复盘，其中得出的需求规模是39用例，产

出的代码行是30068，实际的缺陷总数是319个，测试阶段的BUG数量为115个。因此可以得出的

总缺陷密度为8.17个/UC，而跟测试BUG相关的测试缺陷密度为3.8。因此在项目V4.0版本项目的

估算中也采用了这些数据，并取得了较好的效果，具体的对比和偏差如下：

如果项目某个版本用户提出特殊的质量要求，就需要对项目的质量目标进行调整，质量目标在确定后

将直接影响到估算的工作量分布，因此在制定项目计划的时候一定是先制定出项目的质量目标，然后

在根据质量目标去指导和约束估算过程。

质量目标预计出来的数据在项目执行和跟踪过程中也有用处，我们时刻要使用该数据去检查我整个项

目过程是否出现偏离，如当预计的需求缺陷是160个时候，如果需求阶段实际完成缺陷只有50个或

更少，这个时候就要进行分析是否是同行评审过程有问题，该发现的缺陷没有发现出来，是否需要重

新组织评审或增加预审时间，只有这样才能够真正保证上游缺陷不泄露到后续工作中。

需要注意的是项目质量目标的确认过程不仅仅是项目组成员自己确定，更多的是需要和QA和测试负

责人根据该版本的业务需求共同讨论和确定，QA可以根据其它项目情况或业界的一些标准给出有建

设性的意见，测试也可以根据项目前续版本的测试情况来确认项目是否可以达到制定的质量目标。

项目质量目标确认后，还要进一步的确认项目的质量策略，质量策略就是你为了达到这些质量目标而

需要采用的方法或手段。如质量目标要求高的时候，推算出评审需要发现100个缺陷，如果采用单人

复审或多人复审就根本做不到发现这么多缺陷，这个时候就要考虑哪些要采用审查的方式以及审查的

比例。

在项目质量目标确认后，在后续的项目执行过程中要时刻关注这些目标的执行情况，如评审是否充分，

测试是否发现了预计多的BUG，当出现较大偏差的时候要及时分析原因和采用相关的应对措施。

IT项目管理-计划阶段总结

当了一段时间IT项目经理，把一个软件开发项目的项目管理的实际过程写一下供大家讨论和参考。I

T项目管理跟其它工程项目管理最大的一个不同就是人的管理，项目成员不是简单的机器，人员的知

识技能，团队建设，项目沟通等内容往往是项目管理的一个很关键内容。这个方面可以参考《人有神

话》，《软件工艺》，《最后期限》书籍，我的Blog上也有相关的读书笔记可以参考。

首先我们用思维导图把计划阶段的相关活动归纳一下再进行具体的分析：

1．项目目标和范围

开始一个新项目或版本时候，首先是和用户一起确认需求，进行项目的范围规划。项目是范围，进度，

质量和资源四要素的平衡，用户对项目进度要求和优先级高的时候，我们往往要缩小项目范围，对用

户需求进行优先级排序，排除优先级低的需求。另外我们做项目范围规划的一个重要依据就是我们的

历史经验数据，对项目特征的清楚认识，项目范围规划初期需求你进行一个较宏观的估算，否则你很

难判断清楚或给用户承诺在现有资源情况下，你3个月时间里面是否可以完成20个或更多用户功能。

正规过程好像是先确认项目范围，然后根据WBS->进度计划确认实际的项目周期，但实际情况往往很

难如此，用户往往对进度的关注度大于对范围的关注度，一个项目半年或一年都看不到具体的产品出

来用户肯定是无法接受的，所以我们的软件项目一般也是按版本增量迭代进行开发。

另外这里需要强调下项目目标的确定，项目的目标不能简单理解为在某个时间点完成所有功能。项目

另外一个重要目标就是项目的质量目标，你完成的这个项目需要达到那个等级的质量标准，交出的产

品BUG泄漏率要控制在什么范围内等内容。项目的质量目标不会影响到我们的范围，但会影响到我们

后续评审，测试等时间的安排，直接影响到项目的进度。

PMBOK里已经明确提到项目范围定义的另一个重要目的就是项目的绩效测量和验收准则，你交付项目

的时候用户会根据用户需求说明书内容对项目进行验收，所有我们项目的范围的定义必须是明确，量

化，可验证和可测试的，这样才能够避免后期无谓的纠纷。

另外在概述阶段需要分析项目的假设和约束，假设和约束又分为技术方面和非技术方面，在这里我们

分析的所有假设都可能成为项目的风险。

2．项目进度的确定

项目的目标和范围确定后，需要开始确定项目的过程，项目整个过程中采用何种生命周期模型？项目

过程是否需要对组织级定义的标准过程进行裁剪等相关内容。项目过程定义是进行WBS分解前必须确

定的一个环节，你采用瀑布模型和增量迭代模型对WBS分解和进度计划安排显然是完全不同的。

项目过程确认清楚后开始进行项目的WBS分解，WBS分解一般是项目组的核心成员参加，但项目经理

应该是起主导和协调作用。WBS分解方法一般有基于过程和基于成功两种方式，但两种方式可以混合

使用，比如在高层分解的时候先分解出子系统和工作包，在底层的时候再按照需求，设计，编码和测

试各个过程进行分解。WBS的最底层工作单元需要是可以独立核实的产品，需要去下达计划和任务，

工作单元需要有明确的责任人，因此有时候在没有做仔细的估算时候我们很难让工作单元满足这些要

求，这样就难免在进行估算过程中还要对WBS进行优化和调整。

WBS分解完成后可以开始进行工作单元的估算，估算一般有专家法，三点法和功能点法估算，由于我

们的项目采用专家法估算，因此更需要项目核心成员和有经验的成员参加，估算一般会针对工作单元

的单位和复杂度进行估算，最后估算出项目的总规模，再除以项目的生产率后得到项目的工作量数据。

专家法估算一般会进行很多轮，直到所有指标都收敛（收敛标准是组织或项目事先确定清楚了，如偏

差<30%就算收敛）。对于一个软件项目而言，我们用专家法估算其实很难估算出具体的各个功能编码

的代码行数据和编码的具体工作量，所以这里是需要使用项目的历史经验数据，即你在做历史项目的

时候需求：设计：编码工作量的比例究竟是如何的？然后根据估算得到的需求阶段工作量数据去推算

出设计和开发的估算工作量。所以从这点上也可以看出为何软件项目度量和分析很重要，因为你做的

度量和分析数据都会做为你后续项目的重要依据。很多项目老说软件估算很不准，原因就在于你没有

你自己项目的历史经验数据的积累。

在估算数据出来后，可以使用Project工具安排整个项目的进度计划，在项目进度计划安排中的两个

重要内容就是关键人力资源的确定和关键路径的确定。在这两个因素确认清楚后要排出整个项目的进

度计划就很简单了。对于项目关键人力资源确定一般可以采用工作单元－>人员的责任矩阵进行分析，

对于关键路径一般直接用运筹学中的关键路径分析法确定ES，EF，LE和LF四个时间即可。

在项目进度计划基本排出来后就可以规划和确定项目的里程碑和基线了，项目的里程碑和基线是项目

重要的跟踪控制检查点，在里程碑项目还会做专门的里程碑报告，对项目的当前状态，项目的进度，

工作量，规模，缺陷等各项指标的偏离进行分析。

整个项目进度计划基本出来后需要和项目组的所有项目成员确认，获取项目的内部承诺，项目成员应

该对整个进度计划安排基本达成一致。项目计划还有需要支持计划需要制定，项目进度计划出来后整

个可以通知QA和配置管理员分别制定质量保证计划和配置管理计划，项目经理协助测试负责人制定

项目的系统测试计划。

3．项目计划的其它关键因素分析和确认

项目的方法，技术，工具和标准

这是项目计划中需要确定的一个重要内容，即项目过程需要使用哪些方法和技术，采用哪些工具，项

目各个阶段的输出应该满足哪些检查标准等。一个项目中除了使用到常用的开发工具外，还会使用到

需求管理，设计建模，配置管理，变更管理，IM沟通等诸多工具；使用到面对对象分析和设计，开

发语言，数据库，测试等多种技术，在这里都需要分析和定义清楚，这将成为后续技能评估和培训的

一个重要依据。

干系人分析：

所有对你项目有直接和间接影响的相关人员都是项目的干系人，在这里我们一般会按项目内部角色和

外部角色进行划分。在对所有的干系人分析清楚后，还应该通过责任矩阵来分析各个干系人说涉及到

的项目各阶段的相关活动。

项目成员技能和培训：

其实这是项目计划的一个重要内容，就是要对项目中的各个成员的技能进行评估，根据项目评估的结

果来制定项目的培训计划，并对培训的效果进行跟踪。在这里常用的方法和工具有《项目成员培训需

求收集表》，《项目成员技能评估表》，《项目成员技能沟通确认表》，《项目培训计划》

项目的关键依赖和承诺

项目的内部关键依赖和承诺一般会直接体现到项目进度计划中，但项目的外部依赖和承诺必须有专门

的地方进行记录和定期进行跟踪。因为当你外部关键依赖无法得到满足时候将直接影响到整个项目的

进度，打乱整个项目的步调。

项目风险分析

风险管理是项目管理的一个重要知识领域，也是CMMI评估的一个关键过程域。整个项目管理的过程

就是不断的去分析，跟踪和减轻项目风险的过程。我们在分析项目风险过程中可以借助风险库，风险

检查单，专家法，头脑风暴法等多种手段。一个风险主要包括了风险的概率，后果，影响范围，处理

期限等方面的内容；风险的应对措施主要有减轻，承担，缓解和转移等；风险分析一个重要内容就是

分析风险的根源，然后根据根源去制定专门的应对措施。风险管理贯穿整个项目管理过程，需要定期

的对风险进行跟踪和重新评估，对于转变成了问题的风险还需要事先制定相关的应急计划。

CMMI过程域-PP项目计划

SG1:建立估计计划：要建立和维护项目计划参数的估计数据

•SP1.1估计项目的范围

•SP1.2建立项目属性的估计

•SP1.3定义项目生命周期

•SP1.4确定工作量和成本的估计

项目范围的估计可以通过建立顶层WBS分解，WBS分解一般是面向产品结构，需要分解到工作包这个

层次。由于WBS面向产品结构，使我们容易遗忘在WBS分解中包括风险缓解，配置管理，集成，培训，

非开发管理等任务。我们仍然强调的是WBS加上工作包的描述是项目范围的一个全集。

规模是许多用于估计工作量、成本和进度的模型的主要输入。SP1.2提到的项目属性估计的重点就是

先要有任务或工作产品的规模和复杂度的估计，这个是后续工作量，成本和进度估算的基础。对应软

件产品衡量规模的单位常用的有功能点，代码行，需求页数，用例数，需求条目数等。

三级的IPM集成项目管理强调了项目的过程是从组织标准过程定义裁剪出来的，一个重点大的裁剪就

是选择项目生命周期模型。SP1.3定义项目生命周期在二级的时候还没有上升到组织级。

项目生命周期模型的定义是确定工作量和成本的基础，不同的生命周期工作量的分布往往是不同的，

而且我们的项目历史数据也是在一定的生命周期模型下得到的。在这里把生命周期模型放到SP1.3，

是否说明顶层WBS分解更多的是项目产品结构，和采用的生命周期模型关系不大?

工作量和成本的估计一般基于使用模型或历史数据分析规模、活动和其他计划参数的结果。不可预测

的工作量是更危险的，需要更多研究来开发合理的估计基础，并需要预留更多的管理工作。在软件工

程领域，已经开发许多参数化模型来辅助成本和进度。历史数据包括来自先前已执行项目的成本、工

作量和进度的数据，加上考虑不同规模和复杂度的调整数据。

再对SG1进行总结，大致遵循的一个步骤如下:

SOW和用户需求->顶层WBS分解->规模和复杂度估算->生命周期模型确定->估算参数确定->工作量和

成本

SG2:开发项目计划：要建立和维护项目计划，并作为管理项目的基础

•SP2.1建立预算和进度

•SP2.2标识项目风险

•SP2.3计划数据的管理

•SP2.4计划项目的资源

•SP2.5计划所需的知识和技能

•SP2.6计划项目相关人员的参与

•SP2.7建立项目计划

在这里我们要注意，CMMI里面的PP过程域和PMBOK里面的制定进度过程有些小的区别。SG1的重点

是项目范围管理里面内容，SG2重点是项目时间管理内容，有一个大的不同就是规模和工作量的估算

是在WBS一建立后就可以开始的工作，而不是要先进度活动定义和排序后再开始。

从SG2内容可以看到PP项目计划强调的内容仍然是一个项目综合计划的内容，SP2.2涉及到初步的

风险管理计划制定，SP2.3涉及到数据管理计划；SP2.4涉及到人力资源计划，SP2.5涉及到培训计

划等。到了IPM集成项目管理后更加强调了集成计划，会再增加入质量保证计划、配置管理计划，测

试计划等。

SP2.1+SP2.4基本就涵盖了PMBOK中时间管理过程组的所有内容。最终的目的仍然是要有一个进度表

出来，这个进度表考虑了活动间的依赖关系，每个活动的复杂度和持续时间，关键路径，资源的分配

和平衡等各个方面的内容。在这个过程中我们看到关于活动和任务的所有属性基本上都得到了确定了

完善，包括任务的依赖关系，开始和结束时间，分配的资源，输入，产出定义。

SP2.1还有个重要内容就是要确定项目的重要里程碑，里程碑的一个重点是来保证度量的准确性，另

外就是在里程碑点的时候我们要及时的检查计划和实际执行的偏差情况，当偏差超出了某一个范围的

时候就要考虑是否采取相应的纠正措施。

在三级有专门的RSKM风险管理过程域，三级的风险管理更加强调了组织级的风险管理流程和风险参

数的定义，组织级的历史风险库等内容。在二级PP里面的风险管理一般做到能够能够识别风险，优

先级排序和文档化排序，并没有对文档的分析方法，风险的应对和跟踪过多的进行要求。

注意SP2.4可能是在项目一开始的时候就确定的，也可能是我们更多强调的进度和质量要求，对于资

源的投入没有明确的要求。但是要注意的是能够排进度计划的时候资源和资源的分配都应该是基本确

定的了。在SP2.4的子实践中也强调了，项目的人员配置取决于为完成项目需求而将项目需求分解为

在WBS工作包内任务、角色、职责的分配。人员配置需求应该考虑每个已标识职位要求的知识和技能

(像在计划需要的知识和技能特有实践中定义的)。

在项目计划中要计划项目需要的知识和技能，评估当前项目成员是否具备这些技能，如果没有达到则

需要安排相应的培训进行学习或者避免使用一些新技术。这也是一个风险管理的过程。在二级这个工

作主要是在项目层面进行的，在项目是可重复的，到了三级后提升到组织层面，有专门的OT过程域

进行对应。

我们都知道干系人分析和管理是项目管理的一个重要内容，在项目计划阶段我们需要识别项目干系

人，分析项目各个阶段活动和干系人之间的关系，知道项目干系人对项目的影响以平衡干系人的期望。

对于SP2.6可行的一个方法是通过标识项目中人员和功能需要代表的类型来标识项目生命周期所有

阶段的项目相关人员，并描述他们的相关性和在特定项目活动的交互程度。用两维矩阵来描述，一个

轴是项目相关人员，另一个轴是项目活动，这是实现这种标识的方便的格式。

有了以上活动后，最终就是要形成一个整体的项目计划。项目计划的意思就是到了项目执行阶段后所

有的活动都是事先有所计划进行的，而不是太多的临时任务。为项目产生的计划确定了所有方面的工

作：项目生命周期考虑；技术和管理任务；预算和进度；里程碑；数据管理；风险标识；资源和技能

需求；项目相关人员的标识和交互。基础设施的描述包括项目人员、管理和支持组织的职责和授权关

系。

SG3:获得对计划的承诺：要建立和维护对项目计划的承诺

•SP3.1评审项目的附属计划

•SP3.2协调工作和资源

•SP3.3获得计划的承诺

对应SG3主要说明项目计划指定完成后，必须得到项目识别的所有干系人对计划的承诺。而要获取计

划承诺的一个重要方式就是对项目计划进行评审，包括项目的附属计划。当出现了相关干系人利益冲

突的时候，需要考虑平衡和对计划进行调整。

相关的通用实践和PP过程域的关系

GP2.2:制订活动的计划(做项目计划前要先有计划的计划)

GP2.3:提供资源(提供进行项目计划活动的资源，你制定项目计划需要哪些资源参与)

GP2.4:明确职责

GP2.5:培训员工(员工知道如何做计划，估算的方法和原理，风险识别方法等)

GP2.6:管理配置(计划活动的内容是受控的)

GP2.7:识别和争取相关干系人的参与(和SP2.6的区别?)

GP2.8:对活动进行监控(对计划活动进行监控)

三级对PP项目计划的一些要求

1.根据组织标准过程进行过程定义和裁剪，首先要先选择生命周期模型

2.在项目计划中要有风险管理计划，能定性分析风险，对关键风险有缓解措施的制定

3.项目的估算参数来源于组织级的基线数据，但是项目可以根据需要进行调整

4.项目计划是集成计划，要考虑和质量保证计划，配置管理计划，测试计划等配合和集成

5.项目计划有了组织提供的标准规程和模板形成的最佳实践，制定项目计划时候要遵循

四级对PP项目计划的一些要求

1.通过项目历史数据已经分析了项目自身哪些过程或子过程是稳定的。

2.根据业务和客户的目标在项目计划中要确定项目的哪些子过程要进行量化管理。

3.确定要量化管理的子过程采取的方法，工具和技术。

4.通过组织提供的PPM对项目的目标进行量化的预算，如工作量，周期和缺陷情况等。

5.对风险管理进行了量化，比如引入蒙特卡洛方法对风险分析进行了量化。

6.根据总的质量目标分析和定义了可量化的过程性能指标(目标值，控制上下限)

三，项目执行和控制

项目监控是为了保证项目目标的顺利完成，而监控的将基准和计划内容＆实际的项目执行数据进行比

较以分析差异和发现偏差，并及时的采取各种纠正措施。在项目监控上我提到的几个重点就是不仅仅

是监视还要通过解决问题的根源去控制，还有就事任务的粒度问题，监控的周期和频率等问题.

再谈项目跟踪和控制

项目跟踪控制的目的是保证项目目标的达成。项目周期是重要的项目目标，因此进度控制是重要的监

控内容，同时软件产品的质量，成本等也应该根据当初定义的目标进行监控。否则到了时间点，产品

完成了但质量和成本都达不到要求，仍然是失败。

有监控但项目仍然延期，或者说仍然达不到当初定义的质量和成本要求，原因何在？只跟踪不控制，

只发现问题不找寻根源和解决问题，只应急处理问题而不是提前观察各种征兆是监控中最常见的现

象。

进度跟踪中发现进度偏差的根源分析

1.任务本身的估算问题

任务本身的工作量估算是否合理？进度出现偏差首先要考虑的工作量的估算是否合理，是否考虑了工

作中存在的技术难点，是否考虑了项目成员自身的技能，是否考虑了其它应该考虑的风险。任务计划

下达给项目成员时候应该获取承诺，但很多时候获取承诺是无用的，是否可以承诺或者是否能完成承

诺跟项目成员的个人经验和技能有太大的关系。

当偏差出在估算上，而且后续项目都是采用的相同估算模式的情况，调整项目计划往往是必须的了。

对于短期型的项目，如果这个时候才发现是项目成员技能问题，而想通过培训来提高技能以取得立竿

见影的效果往往已经是不现实的。

如果项目任务中存在着技术攻关或技术难点需要解决，对于这种任务往往是很难估计工作量的，而且

一旦在技术问题上被卡住往往对项目进度产生致命的影响。唯一的方式就是把无法预测和不透明的东

西转换为透明，在项目开始之前就应该进行风险分析和应对，提前进行技术问题的预研，开发原型，

积累相关的知识和经验。

估算问题的根源又出在历史项目或版本对项目历史数据的采集和分析不够，准确的估算依赖于专家的

经验，但专家的经验同样是依赖于历史项目和历史数据。估算问题的根源还在于对项目成员技能和生

产率水平没有较清楚的认识，一个软件类任务的完成往往存在着巨大的个人生产率差异和进度差异。

2.任务本身的粒度问题

对于一个软件项目，出现1-2天的偏差很容易得到纠正。而如果出现1-2周的偏差则很难再进行纠正。

任务本身的粒度和工作量直接和偏差的大小相关。当任务本身的粒度太大的时候是不适宜进行跟踪

的，任务本身是否会偏差不在取决于跟踪者，而是执行者对于大粒度的任务是否有很好的细分和自我

控制能力。

任何一个任务，要么不出现偏差，要么出现成倍的偏差。一个任务的粒度如果是1个月，那这个任务

很有可能要2个月才能完成，如果我们的进度偏差最多允许一周，则需要把任务粒度细化到周，按周

进行跟踪。如果对于任务最多允许偏差1-2天，则需要把任务粒度细化到天，按天来进行跟踪。细粒

度的跟踪目的就是要消除不确定性因素和风险，尽可能早的发现任务中的问题，这样才有可能有时间

来解决问题和纠正偏差。

对于大粒度的项目任务，任务内部本身也存在跟踪但一般只能有项目成员自己进行。任务没有细分，

成员反馈的任何任务完成40%,70%等完成百分比都是不可靠和主观的数据。项目成员的自我监控能力

对进度是否偏差起到重要的影响，在这种情况下，任务是否能够按期完成对项目经理是不可控的，因

此项目经理必须对成员有充分的了解和信任。

3.项目经理对业务和技术领域的不熟悉

对于IT领域项目经理，对业务和技术领域的熟悉是必须具备的能力。有了这些能力才可能和项目组

一起得出比较好的WBS分解和任务工作量的估算，有了这些能力才可能实现细粒度任务的划分，并定

义清晰的出入口准则。

在项目的跟踪过程中往往体现的较多的是项目管理能力，但在项目控制过程中体现更多的则是业务和

技术能力。控制的目的是真正去发现问题的根源，去解决问题并纠正偏差。举个例子：项目经理给项

目成员安排了一个任务，要求本周完成，到了周末项目成员反馈无法完成需要延期2天，项目经理就

确认延期两天并调整后续任务。到了下周二，项目成员又反馈出现了新问题，有个细节没有考虑到还

需要延期三天，项目经理不得已又进行任务调整。这就是我们常看到的场景，整个任务和项目计划都

变得不可控制了，项目成员有责任，但项目经理同样有责任，项目经理在第一次出现偏差时候就应该

介入任务或问题本身，帮忙一次诊断和分析问题，挖掘问题延期根源，或者调整任务粒度，改进监控

方式，而这些都需要项目经理具备一定的业务和技术能力，具备相关的经验积累及时做出指导。

在第一次出现进度偏差的时候，你需要的就是及时介入问题，查找问题根源而不是简单的关注成员反

馈的下一个可能完成的时间点。只有这样才可能进度小偏差就立即查找根源并控制，而不是进度大偏

差的时候进行应急。

4.最后总结

项目总体进度允许偏差确定了项目任务粒度划分和任务跟踪频度。

很多进度问题是前期没有进行充足风险分析和提前应对。

估算很重要，一份不切实际的进度再怎么跟踪都只可能延期或低质量。

任务完成百分比不可靠，可靠方法是任务细分并定义严格的出入口准则。

第一次延期就应该介入问题，查找根源而不是乐观期待下一个可能完成点。

IT项目管理过程-跟踪

项目经理在项目中的一个重要工作是沟通和协调。PMBOK把项目管理主要分为了项目启动，计划，执

行，控制和结束五个阶段的工作。而我们这里谈项目跟踪和控制，主要就是涉及到项目的执行和控制

两个重要管理程序。项目结束也很重要，后续还会专门来将关于项目总结和复盘的相关内容。项目跟

踪和控制也是CMMI重要的一个过程域，其目的很简单就是要保证项目在现有资源的情况下按时的交

出合格的产品来。因此所有对这个目的有造成影响的要素都应该属于项目跟踪控制的范畴。对于跟踪

控制的类别则完全可以跟踪项目管理四要素来分，即项目范围，项目资源成本，项目的质量和项目进

度四个方面的内容。

项目跟踪的目的是发现项目的偏离和问题，而项目控制的目的则是纠正偏离和解决问题。所以两者密

不可分，跟踪是为控制服务，而只要对跟踪的内容控制了才能够真正达到效果。另外项目跟踪过程中

还有一个重要目的就是收集项目度量所需要的数据，你在跟踪过程中发现的非异常数据也要收集和记

录下来，为后续项目服务。

下面我们先来考虑项目的跟踪，这里面分别谈下跟踪的内容和跟踪的频度两个问题。除了从项目四要

素进行跟踪外，另外还需要跟踪的就是项目的风险和问题。如果一个项目有不成功的理由，那这些理

由都应该在项目启动时分析为项目的风险，所以说在一个项目中项目经理70%的时间都是在和项目的

风险做斗争，你管理和控制住风险项目就成功了一半。而这里的问题主要应该有两类，一类是我们跟

踪过程中发现的问题，另外就是在项目执行过程突发的事件和问题。

对于项目跟踪的频度一般分为日跟踪，周跟踪，阶段跟踪和里程碑点的跟踪几个方面。项目要跟踪的

内容和面都很广，所以有些内容不会每天都会跟踪而是放在检查点或里程碑点统一跟踪一次。而对于

一个项目小组来说我们的日跟踪或周跟踪最重要跟踪的内容就是任务完成情况，这是保证项目进度的

一个重要内容，如果出现较大的偏离话就需要及时的调整项目进度计划。对于具体各个阶段需要跟踪

的项目要素可以用下表来描述(绿色表示在该点需要进行跟踪)。

项目的跟踪过程有些需要借助于自动化的软件或系统来协助完成数据的收集和统计，如CQ可以直接

帮我们统计出相关的变更或BUG的数据并帮我们形成图表，对于项目进度的信息数据则可以通过Pro

ject和项目成员的反馈来完成。对于其它如问题，承诺等相关跟踪项目，最适宜的跟踪工具就是Ex

cel表格，组织级可以制订出相关的Excel的跟踪模板，项目经理直接根据模板进行数据的反馈即可。

IT项目管理过程-控制

项目控制就是根据项目跟踪发现的偏差和问题，制订相关的改进措施和解决方案并监督其执行，保证

项目按照正常轨道运行。我们谈风险控制喜欢说要分析出风险的根源，项目控制也一样需要分析出问

题和偏差的根源，而这一关键步骤则需要项目经理和整个项目组有完善的问题和偏差分析能力(涉及

CMMI的DAR过程域)。

由于任何一个问题或偏差的产生都往往不是一个因素确定的，所以这里不仅仅是分析的时候需要综合

考虑各个指标和因素，在我们制订方案和措施的时候也需要进行多因素决策。在这里我们举例说明下：

当我们发现某个项目成员完成的某个功能提交系统测试后BUG很多，对于这个问题可能原因就有1)

任务工作量安排太紧张，根本没有留够自测和单元测试时间2)项目成员个体生产率较低，但估算没

有考虑该情况。3)该功能业务逻辑本身较复杂4)发现BUG很多不是开发人员问题，而是需求没有写

清楚；而具体针对以上不同原因应该采取的解决措施是1)考虑我们的估算是否需要改进2)对低于评

价生产率新员工或成员要进行培训，并且对类似情况要进行风险分析3)架构和设计人员要介入，加

强沟通4)需求质量要通过培训或需求评审进一步提高；如果存在多方面的原因则就需要制订复合的

改进措施进行改进。

另外对于控制我们不能简单的理解成纠正偏离即可的一个简单过程，控制的一个重要任务是通过原因

分析为我们后续版本积累宝贵经验。比如你在周跟踪的时候发现进度出现延后，你的控制措施可能是

周末加班解决问题。但如果仅仅这样做的话则只治标而未治本，这样后续还会接二连三的出现进度延

后的问题。但当你分析出进度延后的根源是项目成员的某方面技能没有达到而立刻组织相关培训进行

改进的话，则后续就可以很好的避免类似问题的发生。

让我们来分析下常用的一些项目控制或纠正偏离方法：

1)需求不明确，用户老是改来改去，项目返工工作量大。

尽量是从我们开发模式上想办法，采用快速原型和用户确认需求，系统分析员尽量分析和挖掘用户深

层次需求；开发模式上采用敏捷或增量迭代的开发方法来适应编号；设计上都采用面向接口设计保留

系统的扩展性和健壮性。

2)进度出现明显延后

这里我们首先要谈的是，周跟踪是很重要的，在项目中我们以每周为单位对项目任务的进展进行跟踪，

这样可以很好的控制项目的延期时间，便于采取后续的补救措施；在项目进度出现偏离时候增加人手

往往是愚蠢的办法，最有效的方法就是缩减项目范围。次之的方法是项目成员加班，适当加班可以补

救进度偏差，但长久的加班确会丧失所有效果；另外方法就是提升整个项目的士气，项目进度延后时

候往往士气较涣散，大家的生产率也较低，工作责任心不强导致产出的工件质量不高，这种时候往往

更是需要通过团队活动来提升项目凝聚力的时候。另外一个关键就是项目经理应该审视自己的进度和

人员安排是否合理，资源是否充分利用，外科手术队伍里面不需要大家都拿手术刀，你的项目手术刀

是否交给了放心的人？

3)项目产出物的质量较差。

质量差有两个原因，一个是成员本身技能还存在问题，另一个原因就是态度问题。对于本身技能问题

应该尽快的组织项目的培训和交流，对于新员工要安排专门的辅导老师，尽快让技能欠缺者提升技能，

保证整个团队的战斗力。态度决定一切，项目中产出物的质量差往往更多是项目成员的态度问题，而

这个没有捷径，只要通过持续的项目团队建设，定期的项目成员沟通进行改善。

项目经理不可能面面俱到，三头六臂。项目经理一个重要目标就是建设一个有激情和责任感的团队，

大家都以项目为重，把软件系统真正的当做他们自己的产品，这样才能够生产出高质量的产品。

当发现缺陷泄露率较高的时候，一定要及时的采取措施，加强评审的力度和代码Review的力度，加

强这方面团队规程和纪律的建立，保证项目成员能够按照规程和规范去执行检查，而不仅仅是把评审

和Review做为一种应付手段。

IT项目管理中的挣值分析

神话:你知道挣值分析吗？

人月:知道，但不清楚如何在项目中去用，我们的项目都是每周进行跟踪的，任务一般也是按周下达

了，到了周末项目成员任务完成的如何，究竟是否延期，大概要延期几天都很清楚。

神话:进度偏差可以每周跟踪清楚，那你的项目的成本偏差是否也每周分析清楚呢？

人月:人员这个倒没有注意，有些人员是多个项目共享了，项目有时赶进度也会从其它项目调些人力

资源。

神话：成本和进度是项目管理的两个要素，都应该关心。

人月:我觉得我们现在周跟踪的方式不是特别适合应用挣值分析法。

神话:软件项目应该尽量采用增量迭代的生命周期模型，比如200个功能点可以分5次增量完成，每

次增量的完成点就适合我们进行挣值分析。

人月：那挣值分析具体有什么用处

神话：可以在某些阶段点让你很清楚的了解倒项目的健康状态，辅助你进行项目跟踪和控制。辅助你

进行项目的决策。同时挣值分析还是风险管理的一个重要武器，但你发现你项目的进度或成本偏差超

过某个阈值后，你就可以去触发你分析的风险，去采取相关的缓解和应对计划。

我们模拟一个项目的实际数据如下：

整个软件项目分5次增量完成，第一次增量预计完成6个功能点，而实际仅仅完成了5个功能点。第

一次整理预计投入6*10人天的工作量，但由于一个人被借调到其它项目实际只投入了5*10人天的工

作量。由于第一个增量实际仅仅完成了5/6的功能，所以第一个增量实际应该挣的值为60*(5/6)=50

人天。这里我们假设软件项目工作量即为具体的成本数据：

所以计算值如下：

计划值PV=60

实际值AC=50

挣值EV=60*(5/6)=50

成本绩效指数CPI=EV/AC=50/50=1

进度绩效指数SPI=EV/PV=50/60=0.83

挣值(EV)应该理解为完成的工作按道理应该获取的价值，而不是你实际付出的价值，一项工作项目成

员只完成了80%，你本月仍然付了2000薪水，但根据他工作的

实际完成情况可能你只应该付1600的薪水。

所以经过计算后可以得到如下曲线图：

通过该图我们可以很清晰的看到在每个增量点项目的运行情况。如在第三个增量的时候EV挣值点在

PV和AC两个值的下方，说明项目的进度延后，且成本也超支。项目采取相关的措施赶进度，到增量

点4后EV位于PV和AC两者之间，说明虽然成本仍然超支，但项目进度已经提前。

风险管理和控制-斯坦福上的赌博课

一场“赌博”在进行：如果猜对，游戏者可获60美元；如果猜错，什么都没有。“如果需要花费20

美元，有谁愿意买这个机会？”伯克-罗宾逊(BurkeRobinson)发问。台下，新台州律师事务所主任、

法学博士项先权举起了手。

这是美国时间7月14日下午14时，斯坦福大学里的一堂“风险管理与控制”课。讲台上的罗宾逊是

斯坦福大学管理科学与工程顾问教授、世界级决策专家，曾是咨询界泰斗StrategicDecisionsGroup董

事合伙人，在应用最尖端手段进行商业和投资决策方面拥有丰富经验。

台下坐着的，是远渡重洋来到这里求学的30多名中国学员。这些国内投资机构人士和刚刚完成原始

积累的民营企业家们，正在进修由浙江大学国际创新研究院与斯坦福大学合作组织的,以“从实业到

资本”为主题的2008美国风险投资高级课程。现在，他们的大脑正进入决策的第一阶段——选择。

此前，罗宾逊已用硬币说明可用“决策树”帮助实施“决策的结构化”。如对硬币朝面的不确定性，

大家都知道成功率为50%。而当硬币变成一枚落地时针头朝向可能存在倾向性的图钉时，谁还愿支付

20美元买这个投资机会？(量化风险分析，决策树，结构化决策，风险乐观型还是悲观型)

赌，还是不赌？在这个瞬息万变的世界，就充满不确定性的未来作出抉择，是企业家常要面对的残酷

“赌博”。但谁也没有想到，第一个掏出20美元放到罗宾逊手上的，是项先权，这位常年处理经济纠

纷案件的高级律师。

图钉针尖上的“赌博”

从“掷币”游戏到“图钉”游戏，需先阐明一些基本要义。如果玩硬币最大收益是60美元，那么根

据朝面各为50%的概率，参与者获得的收益平均值为30美元。但这只是一种统计学理论上的计算，

而在实际生活中，除非可以玩很多次，否则他要么得到60美元，要么一无所获。

“很多投资决策，都只是一次性的决定。”罗宾逊说，这正是游戏风险所在，也是决策的涵义。决策

是一种不可变更的资源分配：“是一种可控制的行为，但事件发展和结果却不可控制。”不过，“掷币”

游戏仍值得一赌，原因是：相比30美元的期望值，花费20美元成本，参与者仍可能获得“+10”美

元的回报。

但当投资机会由硬币变为杯子中摇动的图钉，事情就不一样了。这里出现的第一个分歧是：有些人认

为针头朝向概率仍各为50%；而有些人则认为某朝向概率更高一些。这是一场有关主观概率又叫“贝

叶斯概率”的实验。即不完全情报下，对部分未知状态用主观概率估计，然后用贝叶斯公式修正发生

概率，最后利用期望值和修正概率做最优决策。(TODO)

“对传统统计学，这是一记响亮耳光。”罗宾逊说，概率并不隐藏于图钉中，而是众多信息综合于人

脑反应，“对同一事不同人认为概率不同很正常，它是你拥有的所有信息的一个函数。”由此，人们可

能站成三列：第一列是对图钉朝向毫无概念的人，他们的结局与猜测硬币朝向一样，对错概率也各为

50%；第二列则是认为图钉朝向有所偏向、但不知偏向为何的人。

对他们来说，事情是否会不一样？

可以先来假设一个较强的偏向：针头朝上偏向80%，朝下20%。那么，参与者朝上的猜对概率80%

乘50%=40%；朝下猜对概率20%乘50%=10%，即猜对概率为50%(即40%+10%)。也就是说，图钉

有无倾向性不重要，因为对错概率仍为50%。不过，还有第三种情况，即参与者认为自己知道针头倾

向性是什么。这也正是项先权挺身而出“参赌”的初衷。

在罗宾逊问到“你认为针头朝上的倾向性是多少”时，项律师回答说：“80%。”台下哄堂大笑，但这

个回答却正好解释他为何冲得那么快——如果他认为自己知道针头有80%倾向性是朝向哪里，那么

60乘80%=48美元，这个机会的期望回报值就是：48-20(成本)=28美元。

根据这个主观概率，项的确有很多机会。“你愿出多少信息费”不过项先权没想到，在猜测罗宾逊摇

动后的图钉A前，还要面临这么多抉择。“现在，有一些看起来对你猜中结果具有价值的信息，”罗

宾逊问：“假设我视力和记忆力都很好，也不会说谎，你愿付多少钱买这一信息？”这是“信息费”。

投资人士都清楚，如果拥有额外信息，他们可能获得更高的正确概率。项律师马上说，愿支付“30

美元”。

他的计算公式如下：60(收益)-30(信息费)-20(成本)，仍可稳赚10美元。这个公式遭到学员们的强烈异

议。

“对决策者而言，上台后就已超越过去阶段，不应再惦记最初20美元的沉没成本。”大家说，有人因

此大叫：“他是个公务员，而不是做生意的企业家，工资拿回家就算赚到钱了！”

罗宾逊说，这的确是一个很典型的错误，很多人走到第二步，还会习惯性念叨第一步的付出。为说明

信息费究竟值多少钱，他问：“如果我现在给你钱，出多少你愿把赌的机会卖给我？出价从20美元一

路飙升，到“25美元”时，项律师忍不住了——“OK！”

这可以视为是他对投资机会风险调整后的估值。事情似乎到了这一步：如果获得信息，可赚60美元；

如果没有，那么将获25美元的收益可能性。如此一来，该案例中“信息费”价值即60-25=35美元。

不过，项律师很聪明。他提出，应讨价还价，不愿花35美元这一最高价去购买，原因是世上没有完

美的信息。比如，企业可能去做市场调研、各种研究预测，但事实上获得的都是不完美信息。所以，

当罗宾逊再问，他将摇动另一枚图钉B获得一些结果时，项先权说摇一次他只愿支付“6美元”。

最终，罗宾逊三次摇图钉B结果全朝上。统计学上，这三次摇动都有重要意义，但由于次数太少，参

与者仍须谨慎采纳，不能被误导。终于，可以猜图钉A的朝向了。项律师说，他一直认为图钉80%

倾向性是朝上，所以那个早就躺在那里等他的图钉朝向也应是“上”。不过，图钉

A开了律师一个玩

笑，它最终的姿态是“五体投地”。

这时，罗宾逊说，上述提问只是想知道学员想法，实际上律师出价不是最优决策，因为对他而言，如

果买到信息可稳获60美元；如果没有信息，其期望回报值48美元。所以事实上，该信息最高价不应

超过60-48=12美元。也就是说，项律师之后6元一次的出价仍偏高，因为6乘3=18美元，大于12

美元。(信息能够增加多少你成功的概率，这个概率折算过来应该是多少成本?)

“两岸咖啡”和“高盛”的组合

接下来出场的是浙江两岸食品连锁有限公司总裁兼总经理金梅央，她赢得了比赛，不过也面临一个新

抉择——是拿60美元走人，还是再投资40美元，得到一个掷骰子机会。

骰子规则是这样的：如果显示1，那么游戏者将血本全亏；若显示2、3、4，收益120美元，若显示

5或6，收益为240美元。这看起来是个好生意：根据概率，金梅央有1/2概率可获120美元，1/3概

率获240美元，1/6概率收益为零美元。也就是说，收益期望值为120乘1/2+240乘1/3+0乘1/6=140

美元。

不过，决定投资前，她还有其它选择，比如要不要找个合伙人？这意味着金的收益期望值降低，但风

险也同时降低。台下热闹非凡，最终加入战场的是红鼎创投董事长刘晓人，这是国内第一个以较规范

合伙制形式组建公司的民营创投者。

因为金梅央旗下的“两岸咖啡”近日刚获得高盛等约3000万美元的投资，该组合又被戏称为“两岸

咖啡+高盛”组合。双方讨价还价后的合伙方案是这样的：由“高盛”支付40美元，如果获收益，双

方按出资比例分成。

“现在，你们愿买保险么？”罗宾逊又抛出新抉择。购买保险费用是20美金，作用为：若骰子显示

1，那么组合还能获60美元。如果组合决定接受，此时收益期望值将变成240乘1/3+120乘1/2-40(成

本)+60乘1/6(保险赔付)-20(保险费)=90美元，收益虽有所降低，但风险也同时降低。

“你们是否愿再支付10美元进行分散投资？”不过，教授又紧接问。这意味着：组合可投两次骰子，

每次获收益为原收益一半。也就是说，他们有1/4机会获120美金、1/9机会获240美金，但零收益

的风险几率也变为1/36。如果两个建议都采纳，该组合陷入极端情况的可能性也将大大降低，投资进

入稳健状况。不过现场董事会发生了分歧，“两岸咖啡”犹豫不决，而“高盛”则坚持买入。

最终，“高盛”说服了“两岸咖啡”。结果也幸好如此，因为金、刘掷骰子的显数是“1”和“6”。就

是说，该组合获得收益30(“保险+分散投资”后0收益为30)+240乘1/2(分散投资)=150美元。

注：风险和收益始终都是并存的，要想得到高收益就必须承担更多的风险。而要降低风险就必须要损

失一定的收益，比如购买保险，分析投资，合伙人等。他人帮你承担了风险，同时也享受承担风险带

来的收益。

奖励好决策，而不是好结果

在座的中国企业家中，不少人也曾在清华EMBA等课堂上学习过管理决策，但浙江万鼎信息技术有

限公司董事长郑杰认为：“罗宾逊的案例教学更生动。”罗宾逊说：这不是赌博，而是一个能帮助决策

者理解如何做卓越决策的游戏，“企业应奖励那些优秀决策而非优秀的结果。”他强调说。

即使项先权输了游戏，教授仍号召大家给他掌声，原因是其在主观概率为80%情况下进入游戏，仍是

一个好决策：“结果产出前，要奖励好决策，只有这样才能鼓励做决策的人在合理范围内冒最大的风

险。”

这可能给中国企业家们敲了一个警钟，通常情况下他们往往更看重结果，然而结果常常是不可控的，

企业能控制的只是好决策。

“中国人向来忽略风险。”企业家们还说，这是一场浓缩了什么是“决策”、“不确定性”、“概率”、“结

果”、“沉没成本”、“合伙”、“保险”、“分散”、“风险”和“回报”的课程，形象说明了以合理性和平

衡性协调风险与回报的要义。“合伙、保险和分散都是降低风险的方式，虽然目前国内金融服务还未

提供第三方保险，但可以将其理解为‘对赌协议’等，”刘晓人说。

敏捷项目管理-迭代功能卡和停车场图

敏捷项目管理是以迭代和功能为推动力的。功能的推动性表现在它将计划和执行的主要重点从任务转

变为产品功能。这是与传统项目管理以任务为推动力的重要一个区别。我们将整个需求分解为细粒度

的多个功能点，只有每个功能点的开发和测试全部完成才对进度贡献和客户承诺有意义。这与挣值中

的0-100法则是相吻合的。

按需求和功能点进行WBS分解可能更难于管理，但是它跟开发人员的实际工作方式根据容易匹配，让

项目的工作和与客户承诺保持同步。对于用户来讲只有真正可以交付的最终功能才是有价值的，而每

一次迭代可以是一次交付，是对客户承诺和价值实现的具体体现。

迭代周期的长短是我项目周期和项目对进度偏差限制密切相关的。一般而言在项目周期的15%左右处

都应该设置相应的检查点或里程碑。以方便我们及早的发现进度的偏差和资源使用情况，并对迭代计

划进行适当的调整。同时里程碑点也可能是项目同步和整合的关键点，在里程碑点需要对各迭代功能

进行整合并向用户交付。

迭代计划和里程碑的安排必须考虑客户价值和风险两个要素。迭代的目的就是要在降低风险的情况下

尽量满足客户价值的实现。因此在迭代前期必须要考虑技术风险的减轻和应对方案，使风险明朗。同

时要真正的做好需求分析和用户调研，优先交付用户最关注的功能点。

对于迭代计划的安排，主要涉及到如下活动：

1.确定已知的风险对迭代计划的影响。

2.确定里程碑和迭代周期。

3.为每次迭代(或者里程碑)制定方案。

4.根据优先级，资源，风险和依赖将功能卡分配为每次迭代。

5.结合功能卡和停车场图总结该计划。

6.根据人力资源可用性和工作量估算计划初步的项目进度。

7.必要时调整完成的计划。

对于大型软件应用程序可能包含成千上万的功能，虽然开发团队需要制定详细的进度计划，但是客户

和项目经理等往往需要一种粗粒度的方式进行管理。而以功能为推动力的开发方法依靠的是粒度功能

等级，《功能驱动开发》一书的作者德卢卡推荐的是使用停车场图来规划和报告组件活动的进展。

停车场图可以清楚的看到每个模块或功能的具体功能点数，完成的进度情况，是否延期和完成期限等

重要信息。停车场图可以是迭代进度计划的进一步细化，由于简单直观而更容易使用到进度的跟踪和

管理中。

客户团队只需要一起制定迭代计划(迭代功能卡图)，而将每个迭代里面详细的进度计划(停车场图)

留给具体的开发团队。这种两级的规划方法将给开发团队更多的灵活性。即使是对于较小的项目，活

动和功能的两级法也可以协助团队思考某个产品。

用“看板图”实现敏捷项目的可视化

在敏捷项目里，挂在墙上的“人人可见的大图表”是一种普遍的实践，它被用来共享项目的状态并将

之可视化。精益系统里也有这样的设施。“看板”在日语里的大意是“卡片”或者“标志”的意思。

在精益生产系统里，看板方法是给每个标准生产单元或者每个生产批量附上一张卡片。只有当一个“进

行中”卡片所代表的工作完成后，才会有一张新卡片被“拉”进系统。

在本文中，我将探究当今敏捷项目中广泛使用的各种可视化方法，并提出用看板图（KanbanBoard）

来组织三种视角（时间、任务和团队），目的是使整个团队都能理解项目的当前状态，并以一种自发、

有动力且互相合作的方式来工作。最后，我将介绍“TRICHORD”这个软件工具，它用看板方法来实现

这三个视角的项目可视化。

敏捷项目中的可视化

XP有一种实践叫做“信息化的工作空间”，从中你可以对项目的进行状态一目了然[Beck05]。把故

事卡和任务卡挂到墙上是这项实践的一种简陋实现方式。挂在墙上的其他图表有时候也被称为“信息

辐射体”[Cockburn01]或者“人人可见的大图表”[Jeffries04]，它们在现今的敏捷项目空间设施

里已经是很常见了。下面，我将展示在日本的敏捷团队中发现的一些可视化的例子。

第一个例子是任务看板图（TaskKanbanBoard），它的名字来自TPS（ToyotaProductionSystem）

所用的“Just-In-Time”（JIT）生产方式[Poppendieck03,07]。

图1：任务看板图

看板是代表一项要完成的任务的标签。在TPS中，它被用来具体化Just-In-Time的“拉”生产控制。

在图1里，看板图显示了在本次迭代中要完成的所有任务的当前状态。任务用卡片（便笺纸）来代表，

状态则由板上分别标有“未做”、“正做”和“做完”的三个区域来代表。看板图帮助团队理解当前

做得如何，以及下一步要做什么，令团队能够自我指导。

图2是另一种类型的看板图，称为“特性看板图（FeatureKanbanBoard）”[Highsmith04]。

图2：特性看板图

表的横轴代表时间线，线上的竖直区域代表发布，在区域中的卡片各自代表一项该次发布中要实现的

特性。第一个例子常在开发团队中使用。跟第一个例子相比，特性看板图为产品路线图提供了一种更

高层次的概观，因此分享范围应该被扩大到整个大团队，包括客户、市场员工和管理层。

图3的“停车场图（ParkingLotChart）”被用来提供一种最高层次的对项目状态的摘要总结（注

意不要同另一种“停车场列表（ParkingLotList）”弄混，那是一种用来帮助捕获未解决的问题的

工具）。它是在《FeatureDrivenDevelopment》（FDD）[Palmer02]里首次提出来的，现在已在敏

捷项目中广泛使用。有时候也被称为“项目仪表板（ProjectDashboard）”。

图3：停车场图

图4所示的另一种可视化方式称为延烧图（BurndownChart）。

这种表在Scrum[Schwaber01]中首次提出，用来显示剩余的未完成工作（backlog），现在已经蔓延

到了大多数敏捷项目中[Cockburn04][Cohn05]。它抓住了项目的当前状态以及完成剩余工作的进展比

率。

图5所示的最后一种有意思的可视化方式叫做表情日历（Niko-nikoCalendar或SmileyCalendar），

一种日本人的创造，它显示了团队成员每日的心情。当天工作结束后，每个人都在离开团队空间之前

往自己的日历上画一个表情符号[Sakata06]。它从成员的精神健康和动力的角度来观察项目。

图5：表情日历

用看板图作为主要的信息辐射体

总而言之，以上提到的可视化工具：用卡片作为任务、故事、特性的象征（看板），并将它们依附在

时间线上（看板图）。这里存在不同的粒度。

计算看板（未完成任务）的数目，分时间段来跟踪它们，以显示出工作的完成趋势。这里也存在不同

的粒度。

总结最高层次上的项目状态。

除了表情日历之外，还有很多日历变种可以用来显示项目的状态或者计划。

注意在看板图、延烧图和停车场图三者之中，看板图的信息最详细。延烧图和停车场图可以用看板图

的每日变化信息来绘制。因此后面我将把看板图作为主要的信息辐射体，而用延烧图和停车场图来作

为辅助工具，形象地总结看板的变化趋势。

从三个视角来组织看板

仔细观察看板图，你会发现上面表达了三项主题——时间、任务和团队。下面我尝试从这三个视角来

组织看板。

1.时间

在敏捷项目里，项目时间首先被分解成若干“发布”，每个发布又被分解成若干“迭代”，每个迭代

又分解成若干“工作日”。

发布的时间长度一般为1到6个月，它是最粗粒度的时间单元。它是整个团队的一个同步点，因此团

队中的每个人都应该对此感兴趣。

迭代是第二级的时间单元，长度一般为1到4周。开发团队用它来作为主要的工作、跟踪和改进周期。

工作日是最细粒度的时间单元，团队每天在站立会议上聚集在一起交流项目的状态和问题。

2.任务(特性->故事->任务)

任务被分成三种粒度。我把最高层次的叫做“特性”，每个特性都被分解成若干“故事”，而每个故

事又被分解成若干最低层次的“任务”。

特性是对用户有用和有意义的一项功能。故事是特性的一个可测试的片断，以用户的语言来描述。任

务是故事中的一个工作单元，通常以开发者的语言来描述

3.团队

项目团队由为了共同目标而工作的人们组成。一般团队的成员有一个经理，若干客户、程序员、业务

分析员、用户、测试员，以及其它利益相关的人。整个团队都应该分享时间和任务信息来达成项目的

目标。

用看板图为团队将任务映射到时间

我乐于将看板图定义成一种团队中任务与时间之间的映射。请注意“时间”和“任务”都可以分解成

三个层次，分解的层次越高，应该牵扯到的管理层次就越高。所以，按照“发布—特性”、“迭代—

故事”和“工作日—任务”的组合来设立看板是合理的，虽然其它时间与任务的组合也并非不可行。

“特性看板”的长处在于向全团队提供项目的一个高度抽象的视角。可以搭配停车场图来显示出最高

层次的状态。

“故事看板”处在中间层次，向团队提供每次迭代的最广泛周密的信息，搭配迭代的延烧图会更有效。

“任务看板”的层次最低，它显示出每日变动的当前状态，搭配每日的延烧图会更有帮助。

图7：概观——三种视角以及用看板图将任务映射到时间

CMMI过程域-PMC项目监督控制

提供对项目进展情况的了解。当项目的性能与其计划严重偏离时，采取适当的纠正行动。在这里注意

跟踪的依据是项目计划，而且项目计划必须要文档化和基线。跟踪的内容不仅仅涉及到项目的四要素：

进度，成本，质量，需求范围等，同时还涉及到问题风险监控，承诺达成情况监控，干系人参与情况

监控，人力资源情况跟踪等。在计划过程中我们会定义为了保证项目目标，我们能够容忍的计划和实

际偏差的限度，当我们在跟踪过程中发现了偏差超出范围的时候我们就必须要采取各种纠正措施。纠

正措施可能涉及到计划的变更，自然就涉及到了配置和变更管理的相关内容。

SG1:对照计划监督项目：对照项目计划监督项目的实际性能和进展

•SP1.1监督项目计划的参数

•SP1.2监督承诺

•SP1.3监督风险进行

•SP1.4监督数据管理

•SP1.5监督项目相关人员的参与

•SP1.6执行进展评审

•SP1.7执行里程碑评审

文档化的项目计划是作为跟踪活动、交流状态以及采取纠正行动的基础。我们需要按照计划中记录的

内容来监督承诺。首先看SP1.1监督项目计划的参数，而这些参数正好就是我们针对WBS分解后定义

的各项活动和任务进行的估算。估算包括了规模，工作量，进度和周期，缺陷等各方面的内容，这些

内容都是需要进行监控的，因此我们就需要收集想执行过程中的实际数据，这个自然涉及到MA度量

这个过程域的内容。我们可以将我们度量的数据通过一些系统自动化的工具放入到过程度量数据库

中，一方面是为了监控目的，一方面是为项目的后续版本提供可行的估算参数。

再看后面几个SP特定实践，可以看到监督基本涵盖了项目在执行阶段的所有活动。监督承诺既包括

了对外部客户的承诺，也包括了内部上游客户对下游客户的承诺，这个监督的依据是在项目计划中定

义的依赖承诺表。监督风险进行，一方面是监督风险的概率和影响程度等重要的风险参数是否有变化，

好对风险优先级进行重新评估；一方面是监督我们制定的风险缓解措施的执行情况。我们在项目计划

中会定义数据管理计划，包括项目的日常输出和产品产出具体的存放位置和管理方式，相关的配置管

理计划等，这些也是需要监督的内容。

监督干系人的参与，一个重要监督点就是监督评审的情况，监督项目的周报月报等沟通既要相关干系

人的反馈情况。监督的目的是平衡各方干系人的利益，及时发现项目执行情况和干系人期望之间的偏

差。监督的频度可以是每天，每周和每月。另外一些重要的监督点就是在项目计划制定时候我们确定

的项目分为的几个阶段，各个阶段对应的里程碑。在里程碑点我们会输出里程碑报告，里程碑报告里

面应该包括对所有项目重要要素的监督数据。具体应该包括:

需求规模，进度，工作量，成本投入，缺陷，缺陷泄露和移除，生产率

•人力资源和人员技能情况

•项目成员对承诺的达成情况

•问题和风险情况

•干系人的参与和评审的执行情况

SG2:管理纠正行动直至解决：当项目的性能和结果与计划由重大偏离时，要管理纠正行动直至解决

•SP2.1分析问题

•SP2.2采取纠正行动

•SP2.3管理纠正行动

监督的目的是发现问题，而纠正行动的目的的分析和解决问题。发现问题的问题应该主要包括项目的

计划和项目的实际执行出现显著的偏差；另外就是我们在验证和确认过程中发现的问题，涉及到三级

的VER和VAL两个过程域。问题除了通过项目经理通过监督数据发现外，还可以通过评审，周报月报，

检查点和里程碑报告，平时的沟通，干系人的反馈等多种驱动来收集。

采取纠正行动前一定要对问题的根源进行分析，我们的纠正措施是造成问题根源的，这样才可能避免

类似的问题重复发生。另外在分析问题的时候要避免单向思维，要了解到项目各要素直接的相互作用

和影响。比如当我们发现了进度的问题后采取的纠正措施往往是进度满足了，但是我们的质量目标却

又出现了明显的问题。

对应项目进度出现严重的偏差，我们可能采取的纠正措施是缩小项目范围，增加资源，变更过程和计

划。对于项目质量发生重大偏差，我们要加强员工技能培训，评审和走查等各种活动。对应监督风险

中发现了新的优先级高的关键风险，我们需要及时的制定相应的风险缓解措施。当你发现发现的问题

已经很难通过平衡项目各要素来满足，则必须要对项目目标进行变更，通过新的项目目标重新修订计

划，否则我们后面的监控就会变得没有意义。

四五级对项目监控的要求

1.首先是监控要到子过程。项目->阶段->过程->子过程。测试是过程，单元测试是子过程。评审是过

程，需求的评审是子过程，对评审规模的监控是子过程。需求是阶段，软件需求是过程，软件需求中

的需求收集可以理解为子过程。

2.引入了统计和量化的方法对项目进行监控，比如控制图。四级监控的目的是发现特殊原因，保证过

程稳定和受控。五级的要求是通过监控和分析发现一般原因，收缩上下限范围。

3.在监控过程中增加了通过模型对项目目标的重新预测。

4.对风险的监控加强，包括对风险的概率，后果等各个风险参数的监控，对风险缓解措施效果的监控。

5.监控更加体现量化数据和统计学方法，以反应子过程是否受控。

6.更加强调了对发现问题后的问题分析和纠正的流程，方法和工具的使用。组织也该提供这些内容。

四，项目收尾

项目收尾的一个重点就是项目复盘和经验总结，通过复盘收集和分析项目执行数据，为下个版本积累

估算参数和经验数据。通过版本总结找寻经验教训，在后续项目中持续改进。

IT项目管理-项目复盘

项目计划方面(PP)

1.通过流总数来定义用例的复杂度很难准确，且发现很多时候用例本身也偏大，但又很难去拆分它为

几个子用例。（项目估算）

后期对小版本采用专家法，对大版本采用功能点法估算，并进行功能点估算培训。对于基于用例估算

的时候需要考虑到对于复杂用例必须要考虑拆分出扩展用例或子用例。另外基本流，扩展流的粒度和

编写原则要进一步细化，现在还存在就是一条流描述了多条业务规则，或者是本来可以一条流描述的

写软件需求的时候拆分为多条描述。

2.估算没有通知到测试人员参与（项目估算）

测试的工作量和软件产品本身的规模是相关的，我们知道首先需求的规模和测试用例的规模之间根据

历史经验数据可以得出一个换算比例关系。所以根据软件需求规模可以得出测试规模，根据测试规模

/测试生产率后可以得到测试的工作量。因此估算需要通知到测试人员，进行测试设计和测试执行工

作量估算。

3.估算的新模板很多参数和指标具体含义项目成员不熟悉（项目估算）

包括COPQ,COGQ，以及评审，返工，设计开发等工作量是如何估算出来的参与估算的项目成员并不

是特别清楚。很多流程和规则都固化到了Excel模板中，虽然估算的过程简单了，但是成员并没有真

正了解估算的流程和原理。

4.周例会没有和项目成员共同分析和确认风险以及风险参数

周例会需要共同分析本周发生的问题，这块BA做的好，设计开发很少提问题。周例会需要共同对已

有的风险进行跟踪，并识别新风险。项目需要组织专门的风险管理培训，项目管理很多时候就是对风

险的管理

5.不是所有的成员都参加了项目主计划的评审获取项目承诺

个别设计开发人员没有全部参加项目主计划内部评审，项目成员不清楚总体情况。这跟项目团队的异

地化开发协调也有一定关系，但是我们仍然强调所有成员都应该参加项目计划的评审，并进行承诺，

这样团队成员可以将自我项目任务和团队项目目标很好的匹配。

6.项目成员不清楚项目自定义过程和作用

项目自定义过程是IPM过程域的一个重要内容，需要对其作用了解清楚。过程裁剪的方法，原则，

裁剪和项目特征之间的关系等都需要有个大致的了解。不是简单的为了进度而裁剪掉过程，评审，集

成测试等重要过程裁剪掉了往往项目质量和进度更加无法保障。

7.项目在一些技术方案和实现方式选择上面没有形成规范做法

CMMI三级DAR过程域强调了项目的分析和决策，如何通过DAR来指导项目识别，分析，选择技

术方案需要考虑。

分解计划阶段没有包含风险计划分解结果

项目的风险管理过程从项目一启动就已经开始，在项目计划阶段应该包括了风险的识别，风险的分析，

风险的应对措施和计划等很多内容。对于最终采取的风险应对措施和计划应该有专门的WBS摘要计

划和具体的风险应对任务和活动。

项目跟踪和监控方面(PMC)

1.项目周报很难体现项目总体进度

项目周报的形式需要进行改善，项目的开发模式需要更加的体现增量和迭代开发。这样跟踪的时候可

以按照功能点或需求特征点进行跟踪，根据冒烟测试的情况来使项目进度真正可视。在这一块可以引

入停车场图更加直观的项目进度展现方式。

2.集成测试比预期进度延后3天左右

再次强调敏捷开发中持续集成和每日构建的概念，这个版本在这里吃亏较多，持续集成的一个重要作

用就是保证测试的迭代，提前发现结队任务问题，避免设计严重泄露。

3.问题分析和跟踪机制不完善

因为经常最多的就是听到这个问题解决了没有，在谁哪里，为什么这样解决，这种解决方式有问题等

词语，说明整个问题解决和跟踪机制还有待改进。组织有组织级别的资产库和经验库，项目也需要有

项目级的问题和经验收集管理库。

4.设计人员对开发输出的Review力度还要加强

在团队本身不稳定或团队成员新老交替的时候，应该多采用以师带徒的模式，这个时候师傅要加强代

码的Review工作，通过Review代码来尽早的发展开发质量问题，发现新员工技能存在的欠缺点，后

续好开展有针对性的培训。

5.项目经理不能每周准确跟踪到进度情况

还是说到设计这块，由于没有持续集成，每周功能点也没有集成到151上来，项目经理这块很难确切

跟踪到准确进度情况，所以这块建立在对设计完全信任上。

6.架构如何跟踪设计是否按照架构思路执行问题

如何保证设计和架构的一致性？这块架构要考虑下，后期如何加强控制。这也是我们IT项目管理中

强调概念完整性的一个重要内容，首先需求本身不能出现偏差，其次架构和总体设计和需求匹配，设

计的思路要能够严格贯彻执行。

7.任务承诺和执行的问题

PMS任务周四提出可以延后两天，周五提出需要延期的只能延后一天。但任务延期必须有明确的原

因。项目经理口头或邮件的非PMS任务请大家一定注意，你承诺了在某个时间点能够搞定的要确保

在时间点搞定。

验证和确认相关(VER&VAL)

1.测试人员的测试用例模板存在问题

测试一个重要环节是分支分析和测试数据的准备，这块还要考虑后续改进方法。

2.测试人员对业务的理解程度问题

这块对测试业务培训较少，测试对业务理解深度还要加强，测试有需求要尽早提出来，项目组这边会

多安排BA给测试进行培训

3.测试用例本身的质量问题

测试用例本身的质量涉及到两方面的内容，一个是测试用例的编写方法，一个是测试人员对业务的理

解程度。测试用例要能够全面覆盖到软件需求的内容，包括非功能性方面的软件需求。测试用例一定

要能够很好的体现流程，体现数据准备，体现数据在流程中处理完成后我们分析出的期望结果。测试

数据，输入，期望输出必不可少。

4.通过评审的效果和质量问题

对于需求和架构的同行评审效果较好，能够发现大部分问题。但对于设计和编码的同行评审后期进度

紧张，进行的不是特别好，评审的时间点也较后，很难提前发现设计和编码问题。同时我们看到在需

求和设计阶段，我们评审重点都在功能性需求上面，对于系统的易用性，可扩展性，性能等方面的非

功能性需求考虑较少。

项目管理中的复盘主要做哪些事情

1.收集和净化开发过程中各种度量数据。

收集包括工作量，规模，进度，范围，需求变更，代码行，缺陷泄漏，测试BUG分布，生产率，评审，

返工等各项数据。

注意的是这些数据的收集要分散到整个项目监控过程中去，最好数据收集细化到周跟踪中，要得到第

一手的数据项目中最好能够推广使用PSPStudio等相关工具，保证数据的真实性和准确性。

复盘一词应该来源于围棋，围棋一般下完棋后马上进行复盘，目的是双方都还可以清楚记得过程中得

每个步骤和细节，而对于软件项目生命周期长得时候，靠复盘再去回忆是不可能完全记得清楚得，因

此需要我们平时记录好这些度量数据，或者中间增加多个里程碑和检查点，及时得收集和分析数据。

2.总结项目经验教训

项目一个版本完成后，肯定既有做得好得地方也有做得不好得地方，项目本身要总结同时项目中得每

个成员都应该进行自我总结。总结得目的一个是形成相关得规范和标准，避免后续版本犯同样得错误，

另外一个就是形成相关得方法或模式。项目在进度紧张时候很难有足够得时间去分析和决策究竟选择

那种方法或解决方案，这块每个项目必须形成相关得模式，以后遇到类似得场景就知道如何去分析和

解决问题。

3.为后续版本估算提供足够得数据支持

一个项目中需求，设计，开发各阶段工作量比例究竟如何，项目得平均生产率大概在一个什么样得水

平，项目在估算中评审，测试究竟需要留多少得时间?这些经验数据都需要我们从前续版本得复盘中

来获取。刚开始做我们得估算很难做得准备，是因为我们没有历史经验数据可以参加，项目版本做多

了，多注意复盘收集和分析数据，完全可以使我们得估算做到很准确。

复盘得实际值并不一定不加分析完全用于下一个版本得估算，实际数据本身可能也存在问题和缺陷，

我们应该把这些噪音剔除掉，同时有些工作量分布比例跟我们得质量目标有密切得联系，如当我们得

质量目标高得时候，则评审和测试占的工作量比例可能会更高些。