吉宁博士观点
1．项目管理方法概述
对于软件开发过程，最关键的要素是可操控性。一个混乱的项目直接导致高费用、拖延的开发时段和低质的软件产品。当然这并不是我们想看到的结果。
依我看来，当一个项目结束时，我们需要的不仅仅是一堆软件，而要有更少的维护费用（意味着高质量）和训练有素的团队以及可继承的开发过程。继承意味着积累和连续性。这也是为什么那么多大的公司能够快速发行他们的新产品以幸免于市场的竞争。这就像著名科学家(newton译者注)讲的那样，“我之所以取得成功，是因为我站在巨人肩膀上的”。
在项目管理方法中，对于那些小型开发公司，完全依据CMM(CapabilityMaturityModelforSoftware软件能力成熟度模型)来管理软件项目是不值得的。因为这样的花费太大，以致于公司将失去它们的韧性。为了软件质量管理，软件开发无论如何应该遵守一定的基本规则。这将对于后期的产品质量很有帮助。
如果我让我用一句话来描述项目管理方法，我想说它是一个可管理，可操控的过程。我其实也就是说，无论在软件开发的那个阶段，质量和进度都应该是可控制的。
2．软件中开发的一些提示
于此我为软件开发列出一些提示。由于背景和习惯的不同，这些提示可能并非对任何人有效。但是如果这些提示能带给你某些深入的思考，我想它们是有价值的。
2．1软件预算
任何计划的制订（working-out）都是基于软件大小。一旦我们抓住了对项目的软件大小和构架的理解，我们就能初步安排人力数据和进度。这种安排不必精确。当软件开发过程推进，理解加深之后，无论如何，软件预算将变得越来越精确并且计划安排将。
在软件项目的初始阶段，我们应该实施第一次软件软件评估。在项目管理方法中，软件项目可以被分解成一些功能相对独立的功能模块(注意：这里的模块不同于那些在HLD阶段中被定义的模块)。其间，我们也能认识到哪个模块是最难以及哪个是最重要的。一旦我们有了这些数据，我们根本的人力数据和进度就离我们不远了。同时，我们可以保持我们的眼光在这些困难和重大模块之上，也就是那些投入较大的资源地方。
在项目管理方法中，在每一个软件开发阶段的结束，正如SRS和LLD，我们可以重新评估软件的规模并调整我们的项目计划。实际上这是一个项目计划的回顾过程。这种回顾的优点是更好地使用项目资源和发现存在的项目问题。仅仅通过这些持续的更新，项目计划真的能指引我们的开发行为。否则，随着项目的进行，这将变成一块没有使用的白纸。于是，你会感觉进度总是在你的掌控之下。当然，这是一种非常令人愉快的感觉。
2.2讨论和评审
软件开发是一个团队项目，所以我们认为团队精神是非常重要的，甚至它是关键项目成功的一个关键。一般由于市场竞争我们没有足够的剩余时间留给软件项目。因此，一个项目经理，在任何时候应该追踪正在做的事情。讨论和评审是通向目的非常好的路径。
好的项目必须有一个好的开发过程。在项目管理方法中，它是一个反映好的开发过程的文档。我们如何在有限时间内完成高质量的文档？我想有三方面的重大因素。第一，在你开始写之前，和相关的团队成员讨论是必要的。这种讨论不仅包括技术问题，而且还包括如文档风格等细节问题。一旦这些问题被团队解决了，接下来的文档工作只是小菜一碟。第二，在写文档的过程中，如果你发现新的问题，而你不能理解或者你认识先前的设计是错误的，请毫不犹豫地把这些问题拿出来和你的同事讨论。通过这种持续的讨论，我们可以会聚所有团队成员的智慧以保证在最终的文档中出现更少的错误。随着项目的进行，我们的理解也加深了。于是我们可能发现一些被忽略了的部分，这些将影响我们的设计。所以无论何时，只要我们有了新的发现，以获得高质量的文档，我想第三种因素──评审和更新已经结束的文档是很有必要的。
无庸置疑，在项目管理方法中，对于一个时段限制的项目，讨论和评审意味着你要花费大量的时间，并且在某些情形下这不易于安排，特别是在工作同时变故的情况下。关键的解决这人问题的在项目管理方法中，是把时间和人力精心划分。给个示例，如果我们下周有一些文档需要评审，那么理所当然应该在本周末完成安排。这种安排包括评审的参与者、时间、地点和持续时间等。只有通过这种仔细的安排，我们才能避免评审冲突。通常在正式评审之前，我们应该留出时间给项目组成员来预告判断评审的内容。在评审会议上，为节省时间，唯一目的是发现问题，而不是解决问题。深入的讨论应当被在评审会议之后举行。其间，我们应该采取措施来跟踪在评审会议上被发现的问题以避免缺失。
花费大量时间来讨论和评审是有价值的，因为许多人个错误会在讨论和评审中被暴露出来。在项目结束时，我们发现讨论和评审简直令人难以置信。另外，通过这种持续的交流与合作，我们对彼此的了解更多了些并且团队的效力也被加固了。
风险到处都有。在软件开发阶段，我们会遇到许多困难，并且我们应该真正尝试克服它们。另一方面，我们仍然需要预见我们未来可能发生的风险，并采取行动来减少这种潜在风险对项目的影响。这就是风险管理的概念。
对于一个软件项目，最严重的风险是人力资源问题。大多数项目被分割为由单独的工程师管理的功能模块，你能想象某一个工程师的突然离去对公司造成的影响吗？在软件项目的开始阶段，为避免灾难的接肿面至，人力后备计划应该被发起。
假如缺少工程师，我们如何处理人力后备计划？这在很多公司正在发生。尽管我们没有办法让一些工程师作为另一些的后备，让某些工程师部分掌控其它模块也是可能的。至少，他们一定能理解别的模块的基本原理。如果我们做到适当的管理，这种想法可以在讨论和评审的过程中实现。如果一个工程师被选为一个模块的后选人，他应该参与到所有关于这个模块的讨论和评审之中。也就是说，他与这个模块有关系。因此，当一个项目经理布置一个过程，他应当考虑这种关联。只要我们坚持这种项目管理方法，那个工程师或都更多的工程师将熟悉那个本来不属于他们掌管的模块。结果，即使这种风险变为实事，项目也可以更平稳地生还。
除出人力，还有很多其它的风险，比如实验设备，工具软件以及测试环境。所以这些风险应该被记录和追踪。其间，项目应该有一个计划来减少这种风险的影响。当一个风险过去之后，这个风险的记录应该被关闭。在每一个开发过程的结束，项目经理应该招开一次会议讨论哪个风险可能会在下一阶段发生。这就是说，“即使没有下雨，我们也应该准备好雨伞”。
在项目管理方法中，决定软件项目的成功的因素很多。毕竟，在一个公司有能力的人是最重要的资源。对于大多数公司来说，我想那种可操控，规范的软件过程也是一个基本条件。来自人才的联合和好的开发过程的功效将是令人难以置信的。
与其他重复性运行或操作的工作不同，项目管理具有一次性、独特性、目标的确定性、活动的整体性、组织的临时性和开放性、成果的不可挽回性等属性，因此，要确保项目的成功，获得让所有项目相关者满意的效果，项目经理除了需要清晰地把握项目流程外，更要具备优秀的信息管理、沟通管理、冲突管理、风险管理、质量管理和集成管理等能力。
清华大学项目经理培训课程精选战略管理、人力资源管理、财务管理和项目管理实战四个专题的核心课程，辅以模拟实战演练和案例研讨，项目经理不仅能切实提升项目管控的水平，更能站在企业战略的高度，将项目管理与企业发展联系起来，从而推动企业的高效运作。
