在软件工程飞速发展今天，软件项目管理，与其称之为一项工程，倒更不如说是一门艺术。在这个过程中，不仅要根据软件项目的具体环境中巧妙整合软件技术，经济学和人际关系，更好考虑到高人员密集度，长时期跨度下可能出现的各种风险和问题。最近，根据对600多家公司的调查表明，35%的公司至少有一个失控的软件项目。一方面，顺序的，经典的流程驱动的瀑布模型使得人们在理解其风险和影响之前，过度地提出具有约束力的需求规范中的软件功能。另一方面，代码主导的开发过程，往往诱使企业过分注重功能复杂和代码实现，而忽略了需求，工期，质量，资源等因素间的平衡。工作时"用程序代替用户需求"，其结果必然如目前媒体"程序员生存状况"所言，以开发人员在时间的牺牲为代价来换取项目的结束。无数软件开发的残酷的现实告诉我们：没有规则的软件开发过程带来的只可能是无法预料的结果。如何改善我们的软件开发管理，其实有许多的原则和经验值得我们为之借鉴。

　一.平衡原则

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

　　这就要求我们在软件开发伊始，就建立细致长远的开发和管理计划，平衡各要素间的分配。没有计划，就无从知道什么时候控制和变更。制定一个详尽的计划，以详细到开发人员可以理解的程度为宜。计划能够告诉你什么时候应该做什么。由于没有计划或是计划太粗糙、不切实际，很多项目1/3甚至1/2的时间花在返工上面。因为计划中遗漏了某一项关键任务，或者因为计划太过简陋，就会出现在实际开发过程中，一旦遇到大的问题，急于解决的过程中就会使得原本设计好的需求，资源，工期与质量间的平衡被打破，随之带来的，无论是工期上的延长，还是质量上的纰漏，都可能导致项目最终宣告失败。

　　 二.高效原则

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

 　　在实际情况中，软件项目的人力资源分配大致符合Norden-Rayleigh曲线分布。①区域代表开始阶段，人力过剩；②区域表示开发的中后期，人手不足；③区域表示后来的补偿时间过晚，反而会出现Brooks定律的情况:“向一个已经拖延的项目追加新的开发人员，可能会使这个项目完成得更晚”。因为作为新加入的员工来说，相关培训、环境熟悉和人员之间的沟通通路的增加，迫使项目的工作效率急剧下跌。工作效率下降需要加班来进行弥补，但加班造成的疲劳会再次使工作效率降低。同时工作成本却不断的向上攀升。

　　基于高效性原则，需要对项目管理考虑以下几个方面：1.选择精英成员，虽然现实中开发人员不可能，也做不到像扎克伯格那样拥有天才般的速度和执行力，但总可以从现有人力资源中挑选出其中精英，对不同专长的人安排不同分工；2.目标要明确，范围要清楚，明确开发目标和功能的覆盖范围，并在实际操作过程中坚定地保持始终如一；3.沟通要及时、充分，沟通管理是对项目过程中产生的各种信息进行收集、存储、发布和最终处理，由沟通计划编制、信息发送、性能报告和阶段的结束构成。沟通，不仅包括项目组内部程序员和项目经理的沟通，还需要客户与项目组的沟。沟通的不足会导致效率的降低；4.要在激励成员上下工夫，通过评估我们可以激励人员，保证绩效。良好的绩效管理可以一目了然地反映项目成员的业绩，一切以数据