一、 计划原则

没有计划，你无从知道什么时候控制和变更。制定一个详尽的计划，以详细到开发人员可以理解的程度为宜。计划能够告诉你什么时候应该做什么。没有计划，你无从知道自己需要做什么。不少项目经理告诉组员需要做什么东西后扬长而去，丝毫没有一个相关任务（活动）之间的说明。由于没有计划或是计划太粗糙、不切实际，很多项目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倍。现实就是这么严酷。这很大范围内“归功于项目管理人员。是的，我们的确没有必要责备开发人员，因为我们对资源可用率的判断完全违反常识。 

八、变化原则

也许有人问过你，在项目管理中唯一不变的东西是什么？我可以告诉你，项目中唯一不变的就是“变化”。在项目中不考虑可能发生的变化是不可思议的。不过在面对项目可能发生变化而带来的项目风险时，我们的项目管理人员往往会怀有逃避的态度。经济学里大名鼎鼎的风险规避原则便是项目管理人员心理的有效描述。作为项目管理人员来说，应该及早预测可能出现的风险，做好风险储备。虽然风险储备不能解决所有的问题，但是“预防胜于治疗”。可惜的是我们绝大多数人没有这方面的意识，否则医院的生意未必如此红火，项目开发之途未必如此坎坷。 

九、作业标准原则

一个团队要完成项目的开发需要有一定的章法。很可惜，在国内目前仍然以“作坊式”为主，高举“我们符合国际CMM X规范（ISO某某规范）”的环境下，未必有多少项目团队注意到这一点。我们曾经惊叹印度的高中生都能编程序，而国内却非本科、硕士不收眼帘。究其原因，在于没有开发章法或是章法粗糙，犹如牛皮圣旨一般。一个好的代码模板和代码规范能够解决大多数人编写程序随心所欲的问题，很可惜，没有多少项目管理人员有此意识，也没有多少人愿意去做这项基础任务。业务软件开发需要高超的开发技巧吗？不需要，那是故弄玄虚的开发人员的伎俩。软件开发的美在于其简洁性和规范性，不在于奇技淫巧。因为缺乏作业标准，我们付出的代价是客户的抱怨和无休止的返工。此外，对于那些以形式主意蒙人的项目团队来说，如果你实质如同你口头所说那样，也许你就不会是今天的这副狼狈相。 

十、 复用和组织变革原则－解决项目问题的未来之路

如何解决日益突出的项目工期、成本、质量等问题，这是大多数项目管理者最为关心的问题。从实践来看加强复用的力度，建立项目复用体系和实施组织变革是效果较好的途径之一。复用能够提高项目的生产率，降低项目风险。通过复用，项目管理者能够快速的进入项目问题定义之中，减少项目开发人员的工作量，从而尽可能的解决项目在时间、资源方面的过载问题。另外一条途径是实施项目团队的组织变革（Moc），精简项目管理机构、重新定义工作职责，制定柔性的项目工作流程，改善项目开发人员的沟通状况，提高项目人员的开发效率，努力营造一个良好的项目开发环境。这样才能从根本上解决项目开发的种种棘手问题。 
结论：作为一个项目管理者来说，了解和运用上述原则是不够的，若要深入的掌握项目管理知识和技巧，还必须深入学习项目管理（建议参看PMI《PMBOK》）、管理心理学、质量管理学、组织变革、系统论等方面的知识，并在工作中不断的总结和实践。唯有如此，我们的项目管理人员看自己个人简历时方不会觉得脸红，才能在公司中树立自己的管理权威性，同样也才会有一个良好的职业经理生涯的开端。

 
能力的提高往往不是从成功的经验中来，而是从失败的教训中来。

在克莱斯勒汽车公司，一位项目经理把辞职信交给当时的CEO艾科卡·李，表示要对自己所领导项目的失败负责。艾科卡拒绝了，他知道这位项目经理还 
会在汽车行业继续工作，于是说：“我不希望这100万美元的学费替别的汽车公司交，把教训记下来，这是我们的财富。”这只是艾科卡带领克莱斯勒走出困境的一个小插曲，却令人回味。

许多项目经理不注意经验教训积累，即使在项目运作中碰得头破血流，也只是抱怨运气、环境或者团队配合不好，很少系统地分析总结，或者不知道怎样总结，以至于同样的问题不断出现。

可有可无的项目终结

项目总监王深刚进公司不久就接到一项任务，要求他尽快把项目成本估算的准确度抓一下。由于市场竞争激烈，公司不得不在没有足够信息和数据的情况下，短时间内做出标书。这使过去几个项目的进度大大延误，成本失控，公司管理层对各项目经理的信任大打折扣。

王深查看了公司的项目文件档案，按ISO9000管理来看还是比较规范的。他找来正处于项目收尾阶段的项目经理李明，请他写一个项目总结。要求项目组所有成员都参与总结，一周之后拿出一份完整的总结文件。李明的项目比预定工期晚了1个月，成本比预算多出10万元，但与大部分项目相比，这算是做得不错的了。

颇使王深意外的是，两天后一份两页纸的项目总结摆在他的办公桌上，除了项目背景的介绍，就是一些原则性的套话，“加强合作、及时跟踪”等等，没有触及任何实质性问题。毫无疑问，公司的项目经理们觉得“总结”可有可无、无足轻重，但是许多宝贵的经验就是这样白白地丢掉了。也许，静下心来好好总结一下，我们可以学到很多东西。

会议主题：抱怨

不得已，王深亲自召集李明的项目组开总结会。赵雁发牢骚说：“总结会不是已经开过了吗？我手上又接了一个电厂项目，马上要做详细设计了，这会能不能不开？”王深没有回答，把李明写的报告递给赵雁，问道：“这些体会，你都清楚吗？”赵雁扫了一眼，虽然有些不太明白，但还是不以为然地说：“这是项目经理的事，我们组员无所谓。况且，大部分项目根本就不写总结报告。想写也没有时间！”

“这就是大家没长进的原因！” 王深不客气地说，“超支10万元是怎样造成的？是选择分包商安装监控设备但又无法控制领料造成的！本想赚取材料差价，却没考虑潜在的风险。”王深接着说：“我听说以前公司发生过类似的事情，不幸在我们的项目上又发生了。要是总结就这样草草了事，下次还会有！”

大家逐渐意识到总结的必要性，联想起以往工作，纷纷发表意见。话匣子一打开，总结会变成了一个控诉会。

在项目总结会上，这是常有的事。项目组把所受的委屈，尤其是来自客户方面的，统统发泄出来。但结论往往没有什么建设性，大都是“不要相信分包商的承诺、对客户的无礼要求应拒绝”等没有指导意义的结论。

王深鼓励大家畅所欲言，他说：“总结的意义在于判别结果和我们预想的是否一致，以便调整我们今后做计划的方法，为以后的项目工作打基础。大家最好比较一下项目计划和实际执行的差距。”

李明不好意思地说：“我们的计划只更新过一次，大家基本不太用。” 赵雁插话道：“这是因为计划与实际太离谱，连我们自己都不相信它。”

王深并没有责怪，他说：“对于新的项目，我们的报价、人员安排、进度控制大都基于假设，这很正常。现在我们可以回过头来，逐一检查当初的假设与现实情况的差距。下次同类项目，就可以大大提高计划的准确率，尤其是在成本估算和报价策略上，也就能提高中标率了。” 在王深的提醒下，大家的思路逐渐清晰，原来带有发泄意味的各种意见也变得有些系统化了。赵雁觉得大家的建议在新接的项目中就用得上。

王深特别强调了风险识别意识。他说：“这次在消防审批上的时间比预计的要长很多，影响了回款，这应该加在风险列表中。” 李明补充道：“应该尽早更换电缆供货商，我们一直希望他们能补上进度，所以迟迟没有启动备选供货商。虽然最后还是换了，但是耽误了两周的工期。”

一份非常不错的总结报告出来了，超过了10页，特别精彩的是对风险防范中启动应急计划的体会以及工程量的估算部分。

成长的烦恼

笔者曾在一家外企工作，看到其完备的计划书、风险分析、文档模板，由衷地感叹总结工作的艰辛。许多项目经理不是意识不到总结的重要性，而是疑虑所付出的劳动太多，是不是值得？

一位著名作家在参加亚洲作家笔会之后曾有这样的感想：我们代表团成员的论文动辄就是综述、概述和趋势分析，而少有像日本学者所做的编年史、作家生平考证之类的基础数据积累。这或许是在中国文化某些领域我们的研究水平反而比海外落后很多的原因吧。

项目管理水平的提高，离不开项目总结这项基础工作。这是任何教科书都无法替你做的。如果我们没有诸葛孔明的前瞻智慧，那么项目总结上的亡羊补牢或许也能起到勤以补拙的效果。

我们往往只有在自己碰得头破血流后才真切体会到别人的忠告是多么正确。在经历了无数的成长的烦恼之后，我们才能体会“不听老人言，吃亏在眼前”这句老话的味道。

对于管理项目，你还想重蹈覆辙吗？

经常会遇到客户说，这个东西急着要，要什么什么时候赶出来，这个时候千万要拿得住，不能一味听客户的，要考虑到风险，首先考虑这个能不能做，做的话能不能完成，需不需要加班加点。如果做起来有难度，有没有替代方法，要真正了解客户想要的是什么东西，评估一个合理的时间，不能客户说多少时间就多少时间。如果情况比较急，也要考虑是不是加班就一定完的成，完成的质量又怎么样。同时不要想当然的认为只要加班就一定完的成，要做好一个项目固然免不了加班，不过要充分考虑到每个项目开发人员的情绪，适当的安排加班，如果今天需要加班，就要想到今天加班了明天就可能工作效率比较低，要权衡加班的得失和项目的进度，总之，就是加班要加的适当。

从头到尾一个人可以贯穿整个项目的不多，往往某个人这个项目做了一半，就被抽到另外一个项目中，新加入的人对整个项目又不是很了解，这就需要花时间去带，如果项目周期比较长，可能在前期先熟悉上手，后面就能帮上忙，如果是周期比较短的项目，必要性就不是很大了，与其花力气去带，不如把这个时间用到项目上。

看项目是不是能够赚钱，人力成本应该占了 90% 的比重，所以和客户沟通的需求人员，应该要知道控制项目的生命周期，什么算做项目上线，什么时候算做是后期维护阶段，我想都马虎不得的。如果对客户的需求把握不准，或者对上线的时间没有一个明确的概念，那么这个项目就无法很好的控制时间成本，如果平均下来，就很可能是一个亏本的试验品。在和客户接触的过程中，就要把握住一个原则，已经确定的上线一般来说不能改动，除非客户的需求增加，一方面要重新制定时间计划，一方面要向客户追加相应的费用，这才能保证项目的剩余价值。

协调好各方面的关系对一个项目的持续良好进行非常重要，一方面要不时把项目的进度人员困难等各方面的情况向领导反馈，通过交流可以得到一些有用的信息，同时领导了解了你的工作，你才能有一个坚强的后盾支持，做什么不至于没有方向感。一方面要处理和同事之间的关系，上班时间交流工作，下班时间交流感情，忙的时候让人加加班，项目不紧张的时候就让人休息休息，与人为善，与己为善，大家心情好了，做起事情来效率才高。