变化原则
也许有人问过你，在项目管理中唯一不变的东西是什么？我可以告诉你，项目中唯一不变的就是“变化”。在项目中不考虑可能发生的变化是不可思议的。不过在面对项目可能发生变化而带来的项目风险时，我们的项目管理人员往往会怀有逃避的态度。经济学里大名鼎鼎的风险规避原则便是项目管理人员心理的有效描述。作为项目管理人员来说，应该及早预测可能出现的风险，做好风险储备。虽然风险储备不能解决所有的问题，但是“预防胜于治疗”。可惜的是我们绝大多数人没有这方面的意识，否则医院的生意未必如此红火，项目开发之途未必如此坎坷。
作业标准原则
一个团队要完成项目的开发需要有一定的章法。很可惜，在国内目前仍然以“作坊式”为主，高举“我们符合国际CMM X规范（ISO某某规范）”的环境下，未必有多少项目团队注意到这一点。我们曾经惊叹印度的高中生都能编程序，而国内却非本科、硕士不收眼帘。究其原因，在于没有开发章法或是章法粗糙，犹如牛皮圣旨一般。一个好的代码模板和代码规范能够解决大多数人编写程序随心所欲的问题，很可惜，没有多少项目管理人员有此意识，也没有多少人愿意去做这项基础任务。业务软件开发需要高超的开发技巧吗？不需要，那是故弄玄虚的开发人员的伎俩。软件开发的美在于其简洁性和规范性，不在于奇技淫巧。因为缺乏作业标准，我们付出的代价是客户的抱怨和无休止的返工。此外，对于那些以形式主意蒙人的项目团队来说，如果你实质如同你口头所说那样，也许你就不会是今天的这副狼狈相。
复用和组织变革原则－解决项目问题的未来之路
如何解决日益突出的项目工期、成本、质量等问题，这是大多数项目管理者最为关心的问题。从实践来看加强复用的力度，建立项目复用体系和实施组织变革是效果较好的途径之一。复用能够提高项目的生产率，降低项目风险。通过复用，项目管理者能够快速完成项目。
验收标准原则
我们在进行某项任务，往往会为以何种结果为宜而感到困惑。不求质量的开发人员往往凭据经验草草了事，追求完美的开发人员则在该项任务上耗费太多的精力，但此番耗费未必针对该项任务，因而常常吃力不讨好。这是由于没有验收标准而导致的情景。因为没有验收标准，你无法知道你要进行的任务需要一个什么样的结果，需要达到什么样的质量标准。在很多情况下，你的活动会与期望结果背道而驰，而此时的你还在沉醉于自己的辛勤耕耘之中。作为项目经理来说，只有制定好每个任务的验收标准，才能够严格把好每一个质量关、同时了解项目的进度情况。
默认无效原则
你的项目成员理解和赞成项目的范围、目标和你所制定的项目策略吗？不少项目管理人员认为“沉默意味着同意”。实际上我们或多或少都会陷入这样的一个思维误区。试想一下，你作为职员或项目开发人员时的沉默完全代表你赞成你的领导的意见吗？不见得，这就是答案。这一点在项目沟通中极为重要，项目管理者切不可为沉默认为是同意，沉默在很大的程度上说明项目开发人员还尚未弄清楚项目的范围、任务和目标。为此项目管理者还需要同开发人员进行充分沟通，了解开发人员的想法。在对项目没有一个共同的一致的理解的前提下，一个团队是不可能成功的。
80-20原则
80-20原则在软件开发和项目管理方面有许多“实例”。其一便是我们在20％的项目要求上耗费了80％的时间。仔细分析一下，这些项目要求分为必须的非必须的，因此我们建议是压缩非必须的部分或是暂时将其放在一边不必太重视。软件项目开发事实告诉我们，开发人员在非必须的项目要求上耗费了太多的精力，用户的需求变更的大部分出现在“最好有”这一部分，实际上用户并不看重这些需求（即使去除这些需求），而我们所做的，往往是舍本求末。
80-20原则的另外一个实例是我们项目中的20％的人员担当了80％的项目任务（这样讲在实际实施中一点都不过分）。考虑到开发人员能力的多样性，聪明的项目管理人员决不会采取任务均分的愚蠢做法，因为就系统论的观点来看，互补结构比对等结构要更稳定一些。此外作为项目管理人员来说，了解属下员工的能力特点，将其放在合适的位置上，会更有利于项目的顺利进行。很多管理人员常常抱怨属下能力问题，究其实质，往往是这些项目管理人员未能发现开发人员潜能所在之处。她们看待问题往往以“经验”这样的思维定势来做决定。导致的结果如系统论所言：由于“抱怨”的作用和反作用循环，结果是大家都不欢而散。
文章来源于领测软件测试网 https://www.ltesting.net/
