在软件工程飞速发展，软件项目管理，与其称之为一项工程，倒更不如说是一门艺术。在这个过程中，不仅要根据软件项目的具体环境中巧妙整合软件技术，经济学和人际关系，更好考虑到高人员密集度，长时期跨度下可能出现的各种风险和问题。近，根据对600多家公司的调查表明，35%的公司至少有一个失控的软件项目。一方面，顺序的，经典的流程驱动的瀑布模型使得人们在理解其风险和影响之前，过度地提出具有约束力的需求规范中的软件功能。另一方面，代码主导的开发过程，往往诱使企业过分注重功能复杂和代码实现，而忽略了需求，工期，质量，资源等因素间的平衡。工作时"用程序代替用户需求"，其结果必然如目前媒体"程序员生存状况"所言，以开发人员在时间的牺牲为代价来换取项目的结束。无数软件开发的残酷的现实告诉我们：没有规则的软件开发过程带来的只可能是无法预料的结果。如何改善我们的软件开发管理，其实有许多的原则和经验值得我们为之借鉴。
　　一.平衡原则
　　在我们讨论软件项目为什么会失败时可以列出很多的原因，如 管理问题、技术问题、人员问题等，但是有一个根本的思想问题是 容易忽视的，也是软件系统的用户、软件开发商、销售代理商 不想正视的，那是：需求、资源、工期、质量这四个要素之间的 平衡关系问题。结合实际，我们可以通俗地理解这四者之间彼此的联系，需求的增多，必然会带来资源消耗的增多和工期的延长；而用户的需求又与工期密切关联，用户不希望工程交付过晚；相对而言，追求更高的质量，需要我们投入更多的人力物力资源，甚至更长的工期；同样，一个高质量的产品，也不是盲目得赶工期，多投入可以完成的。这要求我们在实际中考虑平衡需求，资源，工期，质量并得到各方面均衡的一个优解。在软件项目中我们不仅仅是关注项目的进度，质量，范围和成本四要素的平衡。还需要关注人员角色分工的平衡，冒险和保守的平衡，外部和内部的平衡，纪律和灵活性间的平衡等等。任何一个方面失去平衡，项目都可能处于危险中。
　　这要求我们在软件开发伊始，建立细致长远的开发和管理计划，平衡各要素间的分配。没有计划，无从知道什么时候控制和变更。制定一个详尽的计划，以详细到开发人员可以理解的程度为宜。计划能够告诉你什么时候应该做什么。由于没有计划或是计划太粗糙、不切实际，很多项目1/3甚至1/2的时间花在返工上面。因为计划中遗漏了某一项关键任务，或者因为计划太过简陋，会出现在实际开发过程中，一旦遇到大的问题，急于解决的过程中会使得原本设计好的需求，资源，工期与质量间的平衡被打破，随之带来的，无论是工期上的延长，还是质量上的纰漏，都可能导致项目终宣告失败。
　　二.高效原则
　　记得看过一篇facebook创始人扎克伯格回忆自己创业之初的故事，有一句话让我印象深刻，“真正决定人生高度的，是你做事的速度”。当初，心血来潮的扎克伯格从产生想法，到实现一款简单的应用--大头照对比评分应用FaceMash，仅用了6个小时。在短短的时间内，他独自一人完成了产品的设计，开发，上线....这在当时可能是一个小型企业两天的日常工作量。而他的对头，在哈弗读的Winklevoss兄弟，总说扎克伯格抄袭了他们的创意，才有了后来的facebook，而事实呢？在Winklevoss兄弟在犹豫是否要投入做社交网站时，扎克伯格的facebook已经覆盖了29所学校，7.5万注册用户。促成他们以后差距的，正是二者执行力的差距。也只有像这样在短时间内完成高质量的任务才能称之为高效。

　　在实际情况中，软件项目的人力资源分配大致符合Norden-Rayleigh曲线分布。①区域代表开始阶段，人力过剩；②区域表示开发的中后期，人手不足；③区域表示后来的补偿时间过晚，反而会出现Brooks定律的情况:“向一个已经拖延的项目追加新的开发人员，可能会使这个项目完成得更晚”。因为作为新加入的员工来说，相关培训、环境熟悉和人员之间的沟通通路的增加，迫使项目的工作效率急剧下跌。工作效率下降需要加班来进行弥补，但加班造成的疲劳会再次使工作效率降低。同时工作成本却不断的向上攀升。
　　基于高效性原则，需要对项目管理考虑以下几个方面：1.选择精英成员，虽然现实中开发人员不可能，也做不到像扎克伯格那样拥有天才般的速度和执行力，但总可以从现有人力资源中挑选出其中精英，对不同专长的人安排不同分工；2.目标要明确，范围要清楚，明确开发目标和功能的覆盖范围，并在实际操作过程中坚定地保持始终如一；3.沟通要及时、充分，沟通管理是对项目过程中产生的各种信息进行收集、存储、发布和终处理，由沟通计划编制、信息发送、性能报告和阶段的结束构成。沟通，不仅包括项目组内部程序员和项目经理的沟通，还需要客户与项目组的沟。沟通的不足会导致效率的降低；4.要在激励成员上下工夫，通过评估我们可以激励人员，保证绩效。良好的绩效管理可以一目了然地反映项目成员的业绩，一切以数据说话，更能体现公平。绩效考核分项目绩效和个人绩效两个部分，项目绩效从项目成本、利润、完成计划情况、项目质量、规范程度、文档水平、技术、产品化和共享度方面评价项目效果。
　　三.优先原则
　　在软件工程中存在这样的PARETO定律：在实际中企业80%的问题可以用20%的投资解决，而20%的次要问题则需要花费80%的投资的。在软件项目中，如果出现了过多的需求，通常会导致项目超出预算和预定进度，终导致软件项目的失败，此时需求的优先级可能比需求本身更为重要。仔细分析一下，这些项目要求分为必须的非必须的，因此我们建议是压缩非必须的部分或是暂时将其放在一边不必太重视。软件项目开发事实告诉我们，开发人员在非必须的项目要求上耗费了太多的精力，用户的需求变更的大部分出现在"好有"这一部分，实际上用户并不看重这些需求（即使去除这些需求），而我们所做的，往往是舍本求末。
　　在实际情况中，软件开发负责人员往往会面临需求方提出的一系列繁复的需求，在实施过程中一定要将需求划分为不同的优先级，建立项目开发的需求优先级队列，对于一个管理良好的软件工程必不可少。反之，盲目追求对细枝末节的全覆盖，反而会极大拖慢工期进度，甚至影响产品质量。
　　四.分解原则
　　“分而治之”是计算机领域的一个重要思想，对于软件项目来讲，可以将大的项目划分成几个小项目来做，将周期长的项目化分成几个明确的阶段。在需求管理中首先要进行分类管理，将软件需求分出层次，不同层次需求的侧重点、描述方式和管理方式是不同的。对于管理层而言，提出的需求可能会更加偏向于全局性的目标需求，对于底层实现和分工并不关心；而中层需要将具体的操作，代码分配给不同部分，人员进行实现，同时需要考虑各部分之间的相互衔接。项目越大对项目组的管理人员、开发人员的要求越高，参与的人员越多，需要协调沟通的渠道越多，周期越长，开发人员也容易疲劳，将大项目拆分成几个小项目，可以降低对项目管理人员的要求，减少项目的管理风险，而且能够充分地将项目管理的权力下放，充分调动人员的积极性，目标会比较具体明确，易于取得阶段性的成果，使开发人员有成感。
　　五.风险原则
　　某家知名软件公司曾总结出排行前几的为软件管理埋下风险的罪魁祸首，分别是：
　　1.人为缺陷；2.不切实际的时间表和预算；3.开发错误的功能和属性；4.开发错误的用户交互；5.画蛇添足；6.持续的需求更改.....
　　软件项目管理的过程中，不变的是"变化"。风险管理也是始终贯穿于软件项目管理之中的重要元素，在项目中不考虑可能发生的变化是不可思议的。不过在面对项目可能发生变化而带来的项目风险时，项目管理人员往往会怀有逃避的态度。经济学里大名鼎鼎的风险规避原则便是项目管理人员心理的有效描述。作为项目管理人员来说，应该及早预测可能出现的风险，做好风险储备。虽然风险储备不能解决所有的问题，但预防胜于治疗"。通过学习项目管理知识掌握风险识别、量化、对策研究、反应控制的工具和方法，掌握项目风险管理所必备的知识。通过加强对项目规划中风险管理计划的审核提高项目组的风险管理意识。
　　小结：
　　随着软件开发的深入、各种技术的不断创新以及软件产业的形成，人们越来越意识到软件过程管理的重要性，管理学的思想逐渐融入软件开发过程中，项目开发的管理日益受到重视。然而，实施切实有效的软件项目管理在实际操作中绝非易事，了解和运用上述原则是不够的，若要达成软件工程管理的终目标——保证软件项目能够按照预定的成本，进度，质量按期，顺利地交付用户使用，还必须深入学习项目管理、管理心理学、质量管理学、组织变革、系统论等方面的知识，并在工作中不断的总结和实践。