软件工程项目管理原则

一.平衡原则
在我们讨论软件项目为什么会失败时可以列出很多的原因，如 管理问题、技术问题、人员问题等，但是有一个根本的思想问题是 更容易忽视的，也是软件系统的用户、软件开发商、销售代理商更 不想正视的，那就是：需求、资源、工期、质量这四个要素之间的 平衡关系问题。结合实际，我们可以通俗地理解这四者之间彼此的联系，需求的增多，必然会带来资源消耗的增多和工期的延长；而用户的需求又与工期密切关联，用户不希望工程交付过晚；相对而言，追求更高的质量，需要我们投入更多的人力物力资源，甚至更长的工期；同样，一个高质量的产品，也不是盲目得赶工期，多投入就可以完成的。这就要求我们在实际中考虑平衡需求，资源，工期，质量并得到各方面均衡的一个更优解。在软件项目中我们不仅仅是关注项目的进度，质量，范围和成本四要素的平衡。还需要关注人员角色分工的平衡，冒险和保守的平衡，外部和内部的平衡，纪律和灵活性间的平衡等等。任何一个方面失去平衡，项目都可能处于危险中。

二.卓效原则
记得看过一篇facebook创始人扎克伯格回忆自己创业之初的故事，有一句话让我印象深刻，“真实决定人生高度的，是你做事的速度”。当初，心血来潮的扎克伯格从产生想法，到实现一款简单的应用--大头照对比评分应用FaceMash，仅用了6个小时。在短短的时间内，他独自一人完成了产品的设计，开发，上线....这在当时可能是一个小型企业两天的日常工作量。而他的对头，在哈弗就读的Winklevoss兄弟，总说扎克伯格抄袭了他们的创意，才有了后来的facebook，而事实呢？在Winklevoss兄弟在犹豫是否要投入做社交网站时，扎克伯格的facebook已经覆盖了29所学校，7.5万注册用户。促成他们以后差距的，正是二者执行力的差距。也只有像这样在短时间内完成高质量的任务才能称之为卓效。

三.优先原则
在软件工程中存在这样的PARETO定律：在实际中企业80%的问题可以用20%的投资解决，而20%的次要问题则需要花费80%的投资的。在软件项目中，如果出现了过多的需求，通常会导致项目超出预算和预定进度，更终导致软件项目的失败，此时需求的优先级可能比需求本身更为重要。仔细分析一下，这些项目要求分为需要的非需要的，因此我们建议是压缩非需要的部分或是暂时将其放在一边不必太重视。软件项目开发事实告诉我们，开发人员在非需要的项目要求上耗费了太多的精力，用户的需求变更的大部分出现在"更好有"这一部分，实际上用户并不看重这些需求（即使去除这些需求），而我们所做的，往往是舍本求末。
在实际情况中，软件开发负责人员往往会面临需求方提出的一系列繁复的需求，在实施过程中一定要将需求划分为不同的优先级，建立项目开发的需求优先级队列，对于一个管理良好的软件工程必不可少。反之，盲目追求对细枝末节的全覆盖，反而会很大拖慢工期进度，甚至影响产品质量。

四.分解原则
“分而治之”是计算机领域的一个重要思想，对于软件项目来讲，可以将大的项目划分成几个小项目来做，将周期长的项目化分成几个明确的阶段。在需求管理中首先要进行分类管理，将软件需求分出层次，不同层次需求的侧要点、描述方式和管理方式是不同的。对于管理层而言，提出的需求可能会更加偏向于全局性的目标需求，对于底层实现和分工并不关心；而中层需要将具体的操作，代码分配给不同部分，人员进行实现，同时需要考虑各部分之间的相互衔接。项目越大对项目组的管理人员、开发人员的要求越高，参与的人员越多，需要协调沟通的渠道越多，周期越长，开发人员也容易疲劳，将大项目拆分成几个小项目，可以降低对项目管理人员的要求，减少项目的管理风险，而且能够充分地将项目管理的权力下放，充分调动人员的积极性，目标会比较具体明确，易于取得阶段性的成果，使开发人员有成就感。

五.风险原则
某家知名软件公司曾总结出排行前几的为软件管理埋下风险的罪魁祸首，分别是：
1.人为缺陷；2.不切实际的时间表和预算；3.开发错误的功能和属性；4.开发错误的用户交互；5.画蛇添足；6.持续的需求更改.....
软件项目管理的过程中，唯一不变的就是"变化"。风险管理也是始终贯穿于软件项目管理之中的重要元素，在项目中不考虑可能发生的变化是不可思议的。不过在面对项目可能发生变化而带来的项目风险时，项目管理人员往往会怀有逃避的态度。经济学里大名鼎鼎的风险规避原则便是项目管理人员心理的有效描述。作为项目管理人员来说，应该及早预测可能出现的风险，做好风险储备。虽然风险储备不能解决所有的问题，但预防胜于治疗"。通过学习项目管理知识掌握风险识别、量化、对策研究、反应控制的工具和方法，掌握项目风险管理所必备的知识。通过加强对项目规划中风险管理计划的审核提高项目组的风险管理意识。