项目管理是指对项目进行组织、规划、指导和控制的过程，为了适应不断发展的社会和经济环境，在项目管理领域不断涌现新的理念。下面将介绍几个项目管理的新理念：

1. 敏捷项目管理（Agile Project Management）：敏捷项目管理是一种注重实施更灵活、迅速、高产出的项目管理方法。与传统的瀑布式项目管理相比，敏捷项目管理更加强调不断反馈和实时调整，以应对需求的不确定性。在敏捷项目管理中，项目团队可以根据实际情况进行快速决策，并以迭代、增量的方式逐步推进项目的开发。

2. 复杂项目管理（Complex Project Management）：传统项目管理主要针对线性、确定性的项目进行规划和控制，而复杂项目管理则针对那些由于环境的不确定性、项目的规模庞大、技术复杂性等因素而具有不同寻常难度的项目。复杂项目管理强调项目团队对于问题的分析、创新思维和适应性能力的培养，同时更加注重不同利益相关方之间的沟通和协作。

3. 经验主义项目管理（Empirical Project Management）：经验主义项目管理是一种基于经验的项目管理方法。它认为项目的发展过程中存在无可避免的不确定性和复杂性，无法通过简单的计划和执行来应对所有问题。因此，经验主义项目管理强调项目团队的经验总结和知识分享，在实践中不断学习和改进。同时，它也注重团队的灵活性和适应性，鼓励团队成员主动解决问题和创新。

通过引入这些新的项目管理理念，可以有效地提升项目的成功率和效率。敏捷项目管理的快速决策和灵活性使项目能够更好地适应需求变化，及时做出调整。复杂项目管理的重点在于团队的沟通和协作，避免潜在的冲突和风险。而经验主义项目管理则关注团队的学习和创新，通过经验总结和知识分享来提升项目的质量和效果。 总之，随着社会和经济的发展，项目管理领域的新理念在不断涌现，不断适应多变的环境和需求。敏捷、复杂、经验主义项目管理等方法的引入为项目管理提供了更多的选择和工具，可以帮助项目团队更好地应对挑战，实现项目的顺利实施。项目管理的新理念不仅能够提升项目的效能，还可以培养团队成员的思维和能力，从而推动项目管理的发展。

项目管理核心理念是什么？为什么？中小型软件开发项目管理
本处指的中小型软件开发项目是指：

参与开发的直接人员（即开发团队）数量在3~25人

开发时间在3个月~18个月的软件项目

代码行数5000~75000行

子程序数量300~3500个

1软件开发管理的任务

软件开发管理的真正任务是团队成员的智能充分而适宜地发挥，并有效地投注在创造软件的活动中也就是说：合理配置各种资源（管理人员工程师设备软件制度时间）确保软件开发的有效进行最起码需要避免个体智商120，所开发的软件象智商60的人开发的软件确保创造性智能活动保持创造性张力并取得创造性成果

2项目管理的根本焦点

项目管理的根本焦点集中在TQCS上，即：开发进度特性与品质成本顾客服务其中最核心的是开发进度特性与品质两个方面其它一切管理工作都必须围绕这些焦点进行

3中小项目软件开发的组织设计

有效的组织设计是进行项目开发的前提大部分软件开发项目都是中小软件项目，或者说都可以应用本处所说的项目管理原则，中小项目软件开发的组织设计主要是设计参与项目开发的各种角色及其权利责任和这些角色之间的关系

参与中小软件开发项目人员，按角色可以分为五种：

项目经理

项目经理也有时被称为产品经理品牌经理项目负责人项目总监 项目经理的职责是：

领导团队定义出一个成功的产品

引导团队对产品注入深切的期望和信念

带领团队将理想实现，变成可预见的产品诞生

原则1：在项目经理可以对团队有任何价值之前不应该有任何直接的控制权要权威不要霸权，充分授权是项目成功的必要条件

项目经理是软件开发的核心任务：他具备技术背景，拥有建构软件的技术领导能力，他有擅长沟通和倾听，是维系团队灵魂的关键人物

项目经理的具体工作是：负责制定开发日程配置资源与外界沟通项目经理必须担负着保证团队士气营造共同美好前景的责任，也必须在困难出现时通过坚强的信心和必要的资源调整来确保士气和进度

系统分析员

进行技术规划和开发设计

程序开发员

写程序抓错虫

品保人员

测试评估软件品质

原则2：品保人员与开发人员比例不低于1：2

文档编制与使用者培训

撰写文档，以便用文字的形式正确表达软件的功能和使用

原则3：软件文档的编写量要适中，一般要作到详细，但是文档量上不要超过这个标准：1行程序代码的文档数量不要超过1页

原则3：软件=团队，所以沟通和互动是成功的基础

图一：角色与沟通

详细划分应该包括：

项目主管

产品主管

构架者：负责在设计和实作层次整合软件概念

使用者接口设计者

使用者联络人

开发人员

品管/测试人员

开发工具制作者

版本建立管理者

风险管理者

使用者文件编修专门人员

讨论：注重开发程序与士气的关系

4软件开发的金三角

软件开发的核心是：特色（产品与其品质）资源（人和钱）和时间

图二：软件开发的金三角

原则4：金三角警惕

加派人手？小心但不禁止！

追加预算？可以但是别掉进无低洞！

增加特色？谨慎但不禁止！

推迟时间？可以但是千万小心！

5里程碑与检查点

里程碑（基线基点）则是一个软件配置项在生存周期内的某一特定时刻正式设计并固定的静正式批准的版本，不管媒体如何，它是阶段性目标（可以认为是一个中间产品）配置项是一个配置中的实体它满足一项最终使用功能，并能在给定的参考点上单独标识里程碑应该是团队阶段性工作完成的标志，对于任何一个里程碑都应该给于认真的检查审定和批准 一般里程碑应该少于两个月，多于三个星期，里程碑给团队带来成就感，提高士气通常必须含有的里程碑为：

里程碑1：调研 审定对象：调研报告

里程碑2：需求分析 审定对象：需求规格说明书结构设计报告

里程碑3：数据分析 审定对象：数据字典

里程碑4：概要设计 审定对象：概要设计报告

里程碑5：详细设计 审定对象：详细设计报告

里程碑6：编码 审定对象：各配置项编码测试报告产品文档

里程碑7：发布 审定对象：用户使用报告产品文档总结报告

原则5：对于每个错误列出的需求，将在下游开发中付出高达50~200倍的修正代价

原则5：里程碑必须设置并且设置时间不应是团队感到太长也不应感到太短，它必须有进行正式审定的衡量标准（零缺点里程碑）

原则6：除非任何一个人都到达了里程碑否则就没有达到，即：团队中最后到达的决定着团队的效率

在里程碑中间应该设置大量的检查点，这些检查点应该有可以审查的不管是何种媒体的资料检查点应该细分到一旦检查点出现问题不至于无法在时间上挽回，一般来说一周一个检查点是不长的任何人都应该有检查点 原则7：特殊的软件程序设计师可以作出一些无法想象的创举，掀起一波技术的飞跃，但是他绝不会出现在矢志如期推出产品的开发团队中如果这种没有检查点的人，他是最可以破坏产品的开发者

6成功的项目管理者与成功实施项目管理的项目

作一个成功的项目管理者：

不耻下问

给组员设定短期目标

建立长期计划

<建立评核制度

成功实施项目管理的项目组应该是：

进度刚好可以完成，适度紧张而可以完成

团队和组员士气高涨

成员富有思考乐于沟通

7有效率的工作会议

如果以下超过3个的回答是是的话，那么工作会议的质量就需要主管去考虑了，长期下去必将损害士气决策质量

是否有人没有发言？

是否出现了20%的人发言超过了80%的情况？

是否有这种情况：本次议定的题目，而在会中说下次再说吧？

是否发言需要主管点名？

会议没有引导者？ l 发言是对人而不是对事？

主管是威胁多于鼓励？

是否有人有话但没有说？

8需方委托得项目开发中的若干实际原则：

原则8：顾客的需求是工作的核心，任何所谓天才的设想必须征得顾客赞同

原则9：持续得改善比一次性改善更能提高顾客得满意度，更好得是对开发方好处更大，但是牢记顾客关心的需求绝不可推迟

原则10：能够成熟的技术莫要用不成熟的技术，叫的最响的不一定是最好的，不成熟的技术不要流给顾客，留在实验室或作BETA版吧

软件开发中的几个常见问题分析

如果你在软件开发中遇到了下列问题，那么以下的建议也许对你有帮助

团队成员为什么不善于思考？表现为不发表自己的简介不与他人进行建设性交流

软件管理在沟通体制上出现了问题，这些问题可能是以下问题的一个或多个：

成员认为没有人重视自己的想法

没有好处，也许给主管的想法不一致，主管是不能接受自己建议和批评的

成员认为应该主管告诉他一切

管理者从来都是只管发号命令

解决办法：

A.每一个成员的建议都是重要的

B.与主管不同的意见更值得重视和讨论

l) 主管告诉成员做什么，不要问怎么做除非成员向你询问，那么做下来一起讨论

2）为什么软件的进度老是落后或者功能上老是不能令人满意？

也许你会向软件开发者或系统设计者找原因基本上你可能是失望的实际上你第一个要看的品保人员：人数够不够？确实参与设计了？

朋友，你坚持看完了一篇好文章，希望你对每一件都能有耐心