浅谈软件项目管理原则.doc

目 录

第一章 软件项目管理原则谈 2
第二章 怎样选择软件项目经理 6
第三章 做软件项目经理应该具备的一些品质 10
第四章 软件项目需求管理简述 15
第五章 软件项目的需求开发与管理 18
第六章 软件项目管理的成功七法则 24
第七章 做一个成功的软件项目经理 27
第八章 软件项目成功的要素 30
第九章 软件项目应该怎样顺利实施？ 33
第十章 浅谈软件项目的质量管理 36
第十一章 浅谈软件开发项目的实施控制与进度管理 37

第一章 软件项目管理原则谈

软件开发的残酷的现实告诉我们：没有规则的软件开发过程带来的只可能是无法预料的结果。我们中的大多数项目管理人员在其个人简历中纷纷写到："拥有多年的丰富的项目管理经验"，但在实际开发中，"丰富的"管理经验变成了软件开发人员可怕的梦魇。一次次的失败、一次次的返工，她所谓的项目管理经验只不过是再一次的游戏于"无间"（十八层地狱）。

一次，在与不少项目管理者的交流中，大家纷纷提到的软件变更带来的可怕影响。但是正如完整的法律体制不能制止犯罪，但没有完整的法律体制犯罪会更加猖獗一样，频繁的软件变更固然可怕，但是没有一个完整的项目管理对应机制，我们无法相像项目最终会是一个什么样子。此外还有一次，笔者在求职时，招聘公司的技术主管（40-50岁左右），向我吹嘘公司按CMM4的过程规则来进行软件的开发和管理。殊不知，我一问下面开发人员，她们在经历无数的加班后正在给已经完成的软件项目添加软件概要设计书，这让我大吃一惊。如此这样形式主义的公司，不呆也罢。

记得一个格言曾经说过"人类最愚蠢的行为在于忘记常识"。另外一句较为相仿的格言则是"不知道历史的人必然会重蹈覆。作为项目管理来说亦为同样的道理。

很可惜，我们中的大多数管理者口口声声"软件工程"，工作时"用程序代替用户需求"极具政客的嘴脸。其结果必然如目前媒体"程序员生存状况"所言，以开发人员在时间的牺牲为代价来换取项目的结束，这是再为普遍不过的现象，在此不再妄加评论。

如何改善我们的软件开发管理，一条便捷之道便是"尊重常识，尊重历史经验教训"。在软件项目管理中，有许多的原则和经验可以供我们借鉴。

一、 计划原则

没有计划，你无从知道什么时候控制和变更。制定一个详尽的计划，以详细到开发人员可以理解的程度为宜。计划能够告诉你什么时候应该做什么。没有计划，你无从知道自己需要做什么。不少项目经理告诉组员需要做什么东西后扬长而去，丝毫没有一个相关任务（活动）之间的说明。

由于没有计划或是计划太粗糙、不切实际，很多项目1/3甚至1/2的时间花在返工上面。因为计划中遗漏了某一项关键任务，项目就有可能宣告失败。试想一下，制定一个周密合理的计划需要耗费这么多的时间吗？需要付出项目失败的代价吗？还有很多项目管理人员常常错误认为"变化比计划快"，但实际的情况是，由于没有计划，你无法预测和估量变化给你的项目所带来影响，你所面临的将会是比面条还难以理清?混沌"状态。

此外，对于开发人员来说，"目标导向（Objective Oriented）"是充分调动其工作积极性的最佳方法，每一个任务阶段的成果能够将员工的工作效率维持在一个较高的水平。因为近期目标总是比远期目标来说更容易看到和达到。为此，制定一个计划吧，让它符合目标导向（通过各个具体任务计划促使项目总计划的达成）。

二、 Brooks原则

向一个已经滞后的项目添加人员，可能会使项目更加滞后。因为作为新加入的员工来说，相关培训、环境熟悉和人员之间的沟通通路的增加，迫使项目的工作效率急剧下跌。工作效率下降需要加班来进行弥补，但加班造成的疲劳会再次使工作效率降低。

同时工作成本却不断的向上攀升。不过就目前来说，项目管理人员丝毫不会理会这一点，"人多力量大"也许更能引人入胜。不少项目管理人员抱怨到时间的急迫性，须知很多项目内时间的急迫性来自于项目管理人员不假思索和不基于常理的邀功表现，没有充分考虑的开发人员能力的多样性所致。

为此，正规的企业不得不耗费大量的加班费用于加班人员的津贴，同时亦要承担违反《劳动法》的潜在法律危险。现在一种万不得已的做法是，假设项目开发人员之间的任务的关联性不是太大的情况下，采取两班倒或是三班倒的方法来保证时间的延续性和相关开发人员的工作高效性。

三、 验收标准原则

我们在进行某项任务，往往会为以何种结果为宜而感到困惑。不求质量的开发人员往往凭据经验草草了事，追求完美的开发人员则在该项任务上耗费太多的精力，但此番耗费未必针对该项任务，因而常常吃力不讨好。这是由于没有验收标准而导致的情景。因为没有验收标准，你无法知道你要进行的任务需要一个什么样的结果，需要达到什么样的质量标准。在很多情况下，你的活动会与期望结果背道而驰，而此时的你还在沉醉于自己的辛勤耕耘之中。作为项目经理来说，只有制定好每个任务的验收标准，才能够严格把好每一个质量关、同时了解项目的进度情况。

四、 默认无效原则

你的项目成员理解和赞成项目的范围、目标和你所制定的项目策略吗？不少项目管理人员认为"沉默意味着同意"。实际上我们或多或少都会陷入这样的一个思维误区。试想一下，你作为职员或项目开发人员时的沉默完全代表你赞成你的领导的意见吗？不见得，这就是答案。

这一点在项目沟通中极为重要，项目管理者切不可为沉默认为是同意，沉默在很大的程度上说明项目开发人员还尚未弄清楚项目的范围、任务和目标。为此项目管理者还需要同开发人员进行充分沟通，了解开发人员的想法。在对项目没有一个共同的一致的理解的前提下，一个团队是不可能成功的。

五、 80-20原则

80-20原则在软件开发和项目管理方面有许多"实例"。其一便是我们在20％的项目要求上耗费了80％的时间。仔细分析一下，这些项目要求分为必须的非必须的，因此我们建议是压缩非必须的部分或是暂时将其放在一边不必太重视。

软件项目开发事实告诉我们，开发人员在非必须的项目要求上耗费了太多的精力，用户的需求变更的大部分出现在"最好有"这一部分，实际上用户并不看重这些需求（即使去除这些需求），而我们所做的，往往是舍本求末。

80-20原则的另外一个实例是我们项目中的20％的人员担当了80％的项目任务（这样讲在实际实施中一点都不过分）。考虑到开发人员能力的多样性，聪明的项目管理人员决不会采取任务均分的愚蠢做法，因为就系统论的观点来看，互补结构比对等结构要更稳定一些。

此外作为项目管理人员来说，了解属下员工的能力特点，将其放在合适的位置上，会更有利于项目的顺利进行。

很多管理人员常常抱怨属下能力问题，究其实质，往往是这些项目管理人员未能发现开发人员潜能所在之处。她们看待问题往往以"经验"这样的思维定势来做决定。导致的结果如系统论所言：由于"抱怨"的作用和反作用循环，结果是大家都不欢而散

六、 帕金森原则

帕金森原则原是用于反映政府部门机构臃肿，效率低下的代名词。不过它在软件开发中一样适用。没有时限限制的话，工作可能无限延期。在软件开发中，如果没有严格的时间限制，开发人员往往比较懈怠。这是人的天性所决定的。千万不要指望奇迹的发生――"所有员工的思想觉悟异常崇高"。作为项目管理者而言，此时应充分考虑到员工的工作效率和项目变更带来的负面影响，制定合理的项目工期并鼓动开发人员尽快完成。

七、时间分配原则

在项目计划编制过程中，我们常常将资源可用率（人、设备）等设置为100％，殊不知你曾想过，由于开发人员需要休息、吃饭、开会等，根本不可能把所有的时间放在项目开发工作上，而且这还不考虑到开发人员的工作效率是否保持在一恒定水平上。所谓一天8小时工时制实际上是徒有虚名。

由于项目管理人员的"无知"，不少开发人员被迫拼命加班。结果依旧出现Brooks原则所出现问题。在实际开发中，开发员工的时间利用率能够达到80％就已经时很不错的了，我个人比较倾向于60％左右（黄金分割点）。一个常用的经验是如果项目人员不懂技术的话，项目时间可能是原计划（该计划没有考虑到资源可用率）的4/3－5/3。
如果项目人员不懂技术、管理人员不懂管理的话，这个数字可能是2倍到3倍。现实就是这么严酷。这很大范围内"归功于项目管理人员。是的，我们的确没有必要责备开发人员，因为我们对资源可用率的判断完全违反常识。

八、变化原则

也许有人问过你，在项目管理中唯一不变的东西是什么？我可以告诉你，项目中唯一不变的就是"变化"。在项目中不考虑可能发生的变化是不可思议的。

不过在面对项目可能发生变化而带来的项目风险时，我们的项目管理人员往往会怀有逃避的态度。经济学里大名鼎鼎的风险规避原则便是项目管理人员心理的有效描述。

作为项目管理人员来说，应该及早预测可能出现的风险，做好风险储备。虽然风险储备不能解决所有的问题，但预防胜于治疗"。可惜的是我们绝大多数人没有这方面的意识，否则医院的生意未必如此红火，项目开发之途未必如此坎坷。

第二章 怎样选择软件项目经理

软件项目管理是"以过程为核心、以度量为基础、以人为本"的，在此过程中需要充分地集成技术方法、工具、过程、资源（人力、资金、时间等）等要素，谁来领导这个集成工作呢？是项目经理。

项目经理是项目组的灵魂，是项目组中很重要的一个角色，无论是什么时代，都必须依靠人来实现管理，这就是"以人为本"。无论管理多么正规，过程是对形式的管理，而内容的管理必须依靠个人的能力。

项目经理，是大多数软件公司中最难选的人。为什么呢？有实践经验又有理论知识的项目经理少之又少，而且即使有身价也比较高，所以在软件公里面"勉强的项目经理比比皆是"，有一定的开发经验，程序写的很好，有一定资历，虽然没有受过正规训练，也可能没有做过管理人员，但是没有办法，公司缺人，只好选他做项目经理了。当然，也不排除不具备上面的条件就做的很好的。

99年我主管过1个成功的项目，该项目是为我们的一个老用户开发一块外围的采购模块，挂接在财务系统中。该项目组的成员都是刚参加工作的本科毕业生，他们是第一次用DELPHI开发应用软件，项目经理也是他们其中一个比较有管理思想的员工，在上学时是学生干部，比较有组织能力，我做为项目主管对项目组进行管理的指导，因为我也从未用DELPHI做过开发，可想而知，该项目的人员风险有多大！

项目的需求分析请了一位有经验的老员工来做，并由该员工做出概要设计，详细设计、实现与实施都是由项目组来做，他们竟然在规定的时间里按照需求完工了！在去现场实施之前我都以为不应该这么顺利，结果在他们实施完毕的几个月里面，用户用的很好，只有几个小的地方对界面进行了调整，没有进行软件的正确性维护！真是难以置信。

为什么呢？在事后进行总结时，大家得出得结论是：我们是严格按照公司的软件工程规范做的。并非有经验的员工才可以做项目经理！新手一样可以成功！

那么，究竟如何来选择一个项目经理呢？我们先看一下项目经理的来源。

（1）专职的项目经理，比如说在公司里有项目管理部，专门是项目经理的派出机构，项目经理经过专业的培训与认证。

（2）兼职的项目经理，来源于某一个技术部门，如开发部或事业部，同时可以兼任其他岗位。

对于专职的项目经理，如果项目组中的成员有兼职的情况，即同一个项目成员可能同时参与多个项目，这时就存在资源竞争的问题，需要项目组之间进行协调，由于组员与项目经理没有行政的隶属关系，因而项目的协调很成问题。

对于第二种方式，往往项目经理只会对他熟悉的作业内容、熟悉的人员进行管理，名义上是项目经理，实际是个局部经理。因此在选择设置公司的组织结构时，在选择项目经理时要充分考虑上述的两种情形。

选一个合格的项目经理

一个合格的项目经理，下面的要求是必须的：

公正无私

99年我主管过一个项目，该项目的项目经理在分配奖金时论资派辈，不按业绩，使得项目组中资历浅但是干活多的员工怨言很大，导致整个项目的积极性很差，最后不得不由我出面制定新的业绩评估办法。如果一个项目经理不能做到公正无私，他就难以服众，无法带好项目团队。

有良好的职业道德

2002年在我经手主管的一个项目中，由于项目经理蓄意隐瞒了项目的真实进展情况，对用户的承诺没有兑现，而导致用户不信任他，向公司提出了撤换项目经理的要求。

用户对于项目有知情权，给用户暴露出问题不一定是坏事，因为只要大家能够互相理解，才能保证项目的顺利进展。如果明知完不成进度，而故意隐瞒了真相，当然是要受到惩罚的。

具有管理的基本技能与知识

要做一个好的项目经理，他肯定要好好的学习一些关于项目管理的基础知识，进行项目管理的技能训练，既要有管理意识，还要有管理的基本技能，要"心有余且力也有余"。

具有很好的沟通与表达能力

项目经理要和方方面面的人员沟通，包括项目组内的人员、市场人员、用户、上级主管，也要和各个层次的人员打交道，为了项目的成功要通过沟通交流消除来自各方面的阻力。

譬如，一个系统集成的项目，在用户现场布线时，你可能要和用户的工程主管、电工、施工队等各种角色沟通，否则，可能因为很小的问题，你的系统就要失败。

有很强的分析问题解决问题的能力

项目经理要能够通过现象看到本质,通过细节发现大问题,发现问题后要果断采取措施,而不是延误时机。如果一个项目经理对问题比较麻木，不能防微杜渐，那么就谁都可以做项目经理了！

懂技术，不要求精通，但是要全面

这可能是争议比较大的一个原则，因为如果按此原则执行，那些拿到PMP证书的专职项目经理如何找工作？使用不懂技术的项目经理我也曾经尝试过，用过一个不懂开发的人来做项目经理，他主要对项目的进度负责，进行项目组内外的协调，但是为了弥补其不足，必须还要给他配一个助手专门负责技术。

对于大的项目这种方式是可以的，对于小的项目而言肯定不能这样做，否则就会出现资源浪费，项目经理的工作量不饱满。所以我的意见还是要使用懂技术的项目经理，这样他能清楚地知道组员在做什么、做的怎么样，能够发出正确的方向性指令，而不是瞎指挥，外行领导内行。

谦虚，不能不懂装懂

有的项目经理搞一言堂，听不进去大家的意见，而且不懂装懂。有一位软件公司的人力资源部经理向我诉说了他们公司由于软件项目经理选择不当而带来的烦恼。2001年他们公司聘用了一位项目经理，该项目经理被程序员们冠以"外行领导内行"的帽子，团队中绝大多数成员对他非议很多，他也听不进去别人的意见，从而使项目团队的效率很低，项目的质量很差，系统开始实施后，就陷入到大量的纠错改错的泥潭中。

平易近人，不要摆架子

如果你的项目经理不能做到这一点，你肯定会对这样的项目经理很反感的！你也不会去和他很好地沟通的，当然项目组的效率也不会很高的。以上是对项目经理的基本要求，如果他能够在此基础上还有其他更好的优点，当然应该选中他。

选了一个好的项目经理，如何用好他呢？

给项目经理充分授权

在软件企业里面，一般有2种类型的组织结构：

（1）事业部制：在事业部里面包含一个产品生命周期的所有职责：产品开发、产品客户化、项目实施、产品的售后服务、市场、渠道等
（2）功能部门制：即将市场、销售、产品开发、项目开发、实施服务、研发管理、测试的职能分散在不同的部门中，按功能划分部门。

无论是哪种组织结构，对于项目组而言一般都需要采用动态的项目组方式，即项目组的成员是由不同部门的人员抽调到一个项目组中来，当项目完成后，项目组的成员就再回到各自的部门中。

对于静态的部门它的职责是提供合适的人员，培养人员的专业技能，进行专业职能的标准化工作，各职能部门就象人才的蓄水池，而项目组简单来讲就是用人。在动态组织的项目组中很容易出现的问题是项目经理的权力不够或者项目经理的权威不够，所以一定要充分授权。

不要轻易撤换项目经理

2002年初，我接手了一个项目，该项目已经换了3任项目经理，导致该项目的工期一拖再拖，每换一次项目经理就要和用户协调一次，每换一次项目经理，用户就要将项目的需求重新讲一遍，用户何其无辜！

所以在项目执行过程中，不要换项目经理。但是，换项目经理的情况在企业里是比较常见的，有时候企业也确实是不得已而为之，如项目经理离职了或者生病了。

在项目初期要识别出这一风险，为了规避此风险在项目组内部可以实行AB角的方法，即有一个组员，他能够和项目经理一样熟悉项目的整体进展情况，一旦项目经理离开了，他随时可以补上。

如果必须换项目经理时，也要选择一个恰当的时机，比如说系统开发完了，进入了实施阶段，可以将项目经理换成善于做实施工作的项目经理，再比如说在需求调研完了，可以换项目经理。

牢记上面的原则，相信您的项目的成功概率会大大提高！

第三章 做软件项目经理应该具备的一些品质

许多人都以为项目经理总是与“理想与光荣”相伴的，其实作为一个有志于改进中国软件开发流程的项目经理来说，他们承担的更多的是“艰辛与痛苦”。

在这里，我通过我担任项目经理期间所遇到的种种现象，来总结项目经理所必需具备的素质，当这些素质您不具备的话，就需要花费多年的努力来培养他，如果无法培养成功，那么请您转换岗位，因为项目经理不适合您，您难以在这个方面获的成功。

一、执着

可以这么说，在中国如果不执着是做不成任何事情的，因为在软件开发流程中推行各种规范和管理制度的时候，你可能遇到各种各样的阻力和障碍，如果没有应付挫折的思想和准备，你是很难推行成功的。

要知道这样一个基本事实，项目管理成败的关键是：如果你不坚持，谁也不会坚持下去的。指望领导的扶持和群众的自觉是不可能的。只有坚定信念，努力打动别人，才能成功。

坚持到成功为止。只要决定上管理流程了，就不要后悔，唯有坚持，因为你拼命努力而实现了99%,你却不知，最后当你决定放弃的时候也许就是你要成功之时。要知道你准备放弃的时候可能正是对方也准备放弃之时，唯有坚持，你才能成功。

二、亲和力

亲和力是指你和团队相互依赖，相互信任能力的大小。亲和力是你领导团队走向成功的基础，如果一个团队的向心力不够，各自为政，那么失败就会在身边陪伴你。要团队的每个成员都信任你，你必须要做到关心下属，主动与下属沟通，为下属争取合法权利等。关心下属就是在日常工作中对下属的工作状况，发展方向进行指导，避免其走弯路；在生活中也对其身体状况进行关心，促进身体和心理健康的恢复。

多找下属沟通是消除误会的润滑剂，同时也是了解下属内心真实想法唯一捷径。做项目经理的人，在某些事情上的处理的确会与人不同，也难以令人理解。这个时候只有多与下属沟通，逐步达成共识，争取大家的理解和支持。记住，没有下属的理解和支持，你永远无法实现项目管理的规范化。这个环节很重要，我在这个方面曾经用时太少，走了许多弯路。

另外就是了解下属的真实想法，经常了解一下下属的真实想法有利于我们不断改进和调整流程，使生产流程更加符合本团队的实际。切记一点，做领导的一定要多尊重下属的想法，并且与之沟通，若一味等下属找自己，那么是一般下属与之水火不容要摊牌时，才会与你沟通，这样悔之晚矣。

为下属争取合法权利是项目经理的一项重要职责。敢负责任是项目经理基本素质，如果你不经常研究工作数据保障下属的合法权益时，你就很难让你的团队保持高效率。

曾经有一次，我们测试工程师的工作业绩突然下降了一半，我与之沟通后发现公司不讲效率只讲工作时间，他有一天特殊没上班，结果公司扣了一天的工资；但是他其实超额完成了月计划的120％。了解情况后，我与公司协调，顺利补回工资，生产效率就大幅上扬．

三、品德高尚

“一撇一捺是个人，世世代代学做人。”在这个世界上最难做的就是做个品德高尚的人。试想一个思想猥亵的人很难取得成功，即使靠钻营取得也只是暂时的，他不可能取得长久的成功。只有品德高尚的人才能感染周围的人，使团队具有向心力，从成功走向成功。

人有三种，一种是仗势欺人，一种是持才压人，最后一种是以德服人。

仗势欺人的人自持地位高而指三道四，自然是不可能团结人，更不可能获得成功；持才压人的人自持学识高而盛气凌人，或咄咄逼人。殊不知“闻到有先后，术业有专攻”，“尺有所长，寸有所短”，难以学到更高的知识，也就难以取得更大的成功。只有以德服人的人以自己的修养和品德感染人，勇于吃亏，乐于助人，以德报怨，只有这样才能使你对立面德人都不忍心伤害你，团结到一切可以团结到的人，拥有这样的环境，你怎么可能不成功。

勇于吃亏，首先要放下私心，如果一个人始终 围着自己转的人是不可能做到的。“人不为己，天诛地灭”是八十年代后出生的人心灵普遍反应；但是要记住人首先是社会中的人，如果脱离了社会，人恐怕已不会成其为人了。因此只有当你抛弃私心，主动为人，别人才会反过来支持你，帮助你。

乐于助人，是人类的一个良好品质，就象一首歌中所唱的“人字的结构就是相互支撑”。管理流程是不可能靠项目经理一个人维持的，必须要大家支持你。但是这却需要你多帮助别人，别人才会帮助你。不管团队成员发生什么事情，你要尽你所能去帮助他，这样团队才可能继续前进。

以德报怨，可能是人最难做到的。中国人就强调“人若犯我，我必犯人”，其实在这回中不会有真正的仇敌，大家明争暗斗的结果如果过20年后再去看的时候，保准一大半的人都会觉得不值得，许多人赌得就是一口气，将自己成功的希望给湮灭了。当你能用宽容喝善良对待你对立面的人的时候，还有什么东西能阻挡你成功？

“得道多助，失道寡助；多助之至，天下顺之，失道之至，亲戚叛之；以天下之所顺，攻亲戚之所叛；故君子有不战，战必胜矣。”

四、口才

良好的口才是项目经理打动项目成员的必备武器，当你拥有良好的口才将会使你无往不利。当年希特勒就是用他那天才般的口才征服了德国，使他的《我的奋斗》贯彻到每一个德国人的心中，从而成立了第三帝国。

要使自己的项目管理思想贯彻到每一个项目成员心中，就必须要做到以下的演讲原则：

1.根据项目成员的共同目标象他们制定演讲内容，只有让他们信服你才有意义；

2.调动听众的这种感官，诉之触觉、视觉、听觉，用黑板、姿势来辅助你的内容；

3.不断的总结效果，改进自己演讲宣传的接受度，如果效果不理想，尝试换一个方式来表达和描述；

4.让听众学以至用，只有他们积极反馈，才能更深入的听你的思想。

五、循序渐进

循序渐进，不急于求成是项目经理在项目管理中必需具备的品质，在中国CMM过程改进的热潮中，真正实现CMM管理的企业屈指可数，而以CMM改进过程实质性为企业带来质量提升和效益改进的公司更是寥落晨星。

为什么会出现这种情况？难道CMM真的不适应中国过情吗？不是，绝对不是。是这些企业的项目经理太心急，连CMM2还不知道怎么回事就直奔CMM3，他们忽视了事务发展的客观规律，凡事必须循序渐进。如果有一个企业在2年内通过了CMM4，我有十足的信心说，那是花钱买征；如果乐观一点，一个中小企业从CMM1走到CMM2大约要2年时间，大型企业只会更长，不会更短，因为他们需要在培训和沟通上付出更大的代价。

就以我所在公司来说，技术部原来只有10任，后来培训CVS版本管理到精通花费了1年，然后才上CVSTrac变更和过程管理，花费了3个多月，然后再实施Finabuild管理花费了3个月，最后改进CVSTrac成CVSProduce管理开发过程并统计花费了半年，其间成立了QA管理部门，并增加了项目专职管理人员，部门人数已经增加到16人，还在不断扩充中。我们的感觉管理越科学化、流程化，所需的分工就越细，人员也就越多。

同事培训和做通这些人的思想工作的成本就越大。开发管理软件的成本也会随之上升。当所有人都能接受流程管理并持续改进时，大约2年光阴也就过去了。

“循序渐进，循序渐进，再循序渐进。”这句巴斯德德经典名言同样适用于我们项目管理领域，他将逐步把我们带向成功。

六、持久求学

“书到用时方恨少，学至成时始知卑。”学无止境，我在生产实践中发现，整个项目管理过程改进就是“学习－培训－实施－发现问题－再学习”的循环过程，项目经理如果不学习将不能解决现实工作中出现的新问题，更不可能站在一个战略的角度来解决问题。

事实上，求学也不能没有目标，否则学到的知识太庞杂，而不能融会贯通，这样的知识对实际工作指导甚少，真正的知识是一个目标体系，严格按照流程来一步步的掌握我们所需要的知识。

最后，我总结一下中国项目经理所必需掌握的知识：

1.专业知识：数据结构、关系数据库、操作系统、软件工程、编译原理。（外国的项目经理可能不需要掌握）

2.管理知识：项目计划、项目配置管理、成本核算、风险预估、绩效考核。这是项目经理必须掌握的内容。

3.网络知识：服务器的架构、各种服务的配置。因为管理的大厦是基于软件的管理，没有一个服务管理的网络配合是不可以想象的。

4.“越过高峰，另一峰却又现”，这是中国项目经理在持续求学中会不停的挑战自我，向更高的山峰迈进。

七、敢负责任

一个人因为有责任才有生存的意义。一个人随着年龄的增长，责任感也会愈来愈重。成年时，法律也会赋予一些年少时没有的责任。同时地位逐渐提高，责任也会相对加重。

一个人惟有负责，才能产生做人的价值。所负责任愈大，价值就愈高。换句话说，有责任，生命才有意义。如果没有感受到自己该负的责任，即使年龄超过20岁，也不算是一个成年人。

因此，经理就是要负责任，如果不负责任就可以不要经理了！项目经理关系到一个项目的成败；对于公司他必须要承担及时汇报项目进度、成本核算和质量系数的责任，同时也必须保证项目组成员绩效考核，政策落实，预留人才储备等责任，是整个项目中责任最大的人，如果没有良好的心理素质和应对能力是无法担负责任的。

实际工作中项目经理主要要负责项目组的人员安排调度、工作分配、工作审核、工作跟踪、项目计划、项目汇报总结、成本核算、利润分配等职责。

八、以身作则

项目管理的一个重要工作就是定义各种规范和制定，但是这些规范和制度的执行除了靠项目经理的执着推行，口才宣传，力主培训、惩戒得当之外，关键还是在于项目经理的以身作则。如果项目经理自己都违反自己定义的条款的话，那么就别指望团队会自觉遵守这些规定。

作为一个管理者以身作则是最基本的素质，千万不要为自己违反规范和制度找各种借口，例如我我是公司只属考核，我因为某某更重要的事情而不得不违反。“只许周宫放火，不许百姓点灯”的话，是无法将规范和制度推入人心的。项目经理如果违反了规范，只有当众加重处罚，别无他法。

说个真实的事例。我从事项目经理工作之前经常迟到，结果不久全技术部人隔三岔五的迟到。我当项目经理后执行晨会制度，早上到公司头半个小时总结一下昨天工作，探讨一下今天的工作，但是因为习惯，有人总是迟到。而我开始从不迟到，有一点为了赶时间我长跑去买早餐以在晨会规定时间之前到公司，被许多团队成员看见。以后就再没人迟到，直至项目结束。

因此，鉴于规范制度的权威性主要还是靠项目经理自己，只有坚持以身作则，才能将自己优秀的管理思想贯穿下去，取得开发过程改进的成功。

九、要有威信

一个项目经理说话有没有人听，必须要靠威信，这种威信是靠自身的素质，而不是狐假虎威。靠高层领导的支持来强迫团队执行项目制度过程的话，是注定会失败的。因为团队成员不信任你，表面服从，实际消极怠工，就足以让流程实质瘫痪。

做事要有信用，说一不二，不能因为朋友关心就讲情面。公是公，私是私。平时可以稀稀拉拉，关键问题决不手软，不因为朋友关系妥协，这样才能树立威信，便于工作。

威信除了必要的威信之外，最主要的还是信用，项目经理在做事没有绝对把握的时候千万不要承诺，一旦承诺就无论如何一定要实现。否则，当实现不成功而丢失信用之后，再想让团队相信你，信任你就是非常困难的事情了。

十、善于总结

项目经理要善于总结，只有不断的总结才能不停的完善自己，成功的事情总结经验，失败的事情要总结教训，总结的过程就是不断改进的过程，这也是CMM规范所必需的素质。总结的过程要多吸取别人的意见，不要武断自己的结论。博人所长，综合起来才算趋于完美。

我就不一一描述了，只有寄希望于大家在做项目经理的时候不断的培养完善自己，让软件开发流程不断获得改进.

第四章 软件项目需求管理简述

一、 前言

在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能 ，优化性能，提高用户友好性的要求。

在软件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。

二、需求管理复杂性分析

软件需求是整个软件开发项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面：

1、需求的描述问题。

缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。在用户方进行的需求评审会完全是走形式，因为用户根本不去听他读那上百页的需求文档。不同层次的客户（用户）关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。

2、需求的完备程度问题。

需求如何做到没有遗漏？如何准确划定系统的范围？这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。

3、需求开发的工期问题。

在需求上花费了大量的时间，客户、软件公司是否能够忍受？为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已！他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。

4、需求的细致程度问题。

需求到底描述到多细，才算可以结束了？仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。但是，需求的周期越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家（客户、用户、需求分析人员、设计人员、测试人员）认为描述清楚了，就可以进入设计阶段了。

5、需求的变化问题。

在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。

需求变化的原因很多，如：

一开始没有识别全，需要增加需求；

业务发生了变化，需求必须变化；

需求错误；

需求不清楚。

需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办？管理它！使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的流程来控制需求的变化。

难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变（Project Scope Creep）问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。

三、需求管理策略

需求管理需要遵守以下策略：

1、需求一定要与投入有必然的联系。

需求一定要与投入有必然的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。但是，接受需求变更目前却是软件开发商不得不咽下的苦果。所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。

2、需求的变更要经过出资者的认可。

需求的变更引起投入的变化所以要通过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。

笔者曾经经历过一个项目，为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量“小的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。

3、小的需求变更也要经过正规的需求管理流程。

小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。

4、精确的需求与范围定义并不会阻止需求的变更。

并非对需求定义的越细，越能避免需求的渐变，这是2个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求写细了，它就不会变化了。注意沟通的技巧。

实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他们的目的可能是使软件做的更精致，于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。

基于上述的问题，必须对需求进行管理，使需求能够真正成为软件工程和管理的基线，使软件计划、活动和工作产品同软件需求保持一致，使需求可以复用。

第五章 软件项目的需求开发与管理

需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的