项目管理思考小记之一

         最近笔者面试了很多项目经理，都是有PMP认证(PMP指的是项目管理专业人士资格认证。它是由美国项目管理协会（Project Management Institute发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证考试)，但没有几个人把项目管理从理论到实践落地。实际上我们需要就是从书本到实践，从实践回到书本，每个知识领域都是这样。个人与团队才会有提升。另一个客户也是过于相信PMP认证，认为只要有PMP认证的项目管理就能够做好项目管理，其实不然。

项目管理铁三角

      有些项目经理夸张到项目管理铁三角都讲不清楚， 也叫三重约束， 我们再到回顾下：每个项目都要平衡由时间、成本和范围组成的“三角形” ，若要更改其中一项，就一定会影响另外至少一项。项目经理的工作是防止整个三角形失衡。

• 范围：基本在项目前期已经规划好，并且有为完成项目所需要的详细待办任务清单，在后续执行的过程中很少会去进行调整；
• 时间：完成范围内待办任务所需要的时间投入；
• 成本：完成范围内待办任务所需要的成本投入。
  所以在传统的项目管理中，范围在前期经过大量调研和规划进而最终确定的情况下，只能通过时间和成本的调整来完成既定的任务。即，如果要节省时间则需要加大成本，如果要节省成本则延长时间，对于范围本身因为前期的大量投入，很难说在范围上面做太大的调整。

在当前的时代背景下，软件领域快速发展、客户要求的不断提高、用户诉求的日新月异，我们很难以保证在自己先期投入大量成本的项目规划是准确无误的，因为对于变化我们很难以去预判，也难以去管控。我们更需要不断的尝试和总结来，即采用经验过程控制的方式来完成软件项目的管理，也就是敏捷项目管理三角的由来。

• 价值：将目标聚焦在客户和用户的视角，软件用来交付他们需要的价值，而非站在项目角度去完成对应的待办任务。
• 质量：软件行业发展至今，用户对软件的依赖越来越强，要求也越来越高。
• 约束：制约用户价值和软件质量的因素，由传统项目管理三角型中的范围、时间和成本构成。
  对于传统三角的范围不变，敏捷三角反其道而行之，在既有的约束条件下，我们会高质量的优先完成高价值的事情。虽然约束条件中的三角和传统项目管理的三角在字面上是一样，但本质的区别在于，敏捷三角的范围是可变的而传统三角则很难。
  约束点中的时间能够以敏捷项目管理中的迭代实践来进行计算，以周为单位将时间抽象成一个相对固定的基础单元；而成本最多在与人力投入，在敏捷实践中的全功能团队规模也很方便计算出整体的投入。在单位时间内的投入和产出相对稳定的情况下，可以合理的通过调整范围来灵活调配约束这个点，以满足三角形中的价值和质量要求。

        在敏捷意义上，有一个固定的时间表（在Scrum中我们通过时间限制的 Sprint和固定资源来实现这一点。因此，当事情根据计划不起作用时，需要减少范围。在敏捷中但是，我们确保即使我们必须在范围上妥协，我们仍然会在产品积压中提供最高优先级的项目，以最大化项目产生的价值。

     敏捷三角相较于传统三角，将范围从固定演进为可变以灵活适应市场的变化，将目标聚焦于客户价值而非既定任务以满足多元化的用户需求，加强质量的权重以提升终端用户的体验。价值驱动的项目管理方式在当前的软件时代背景下显然是由于计划驱动的管理方式的。

    我们再来看软件工匠的宣言，与敏捷思想相关，响应变化，增加价值。如果我们给客户交付的软件没有价值，还有什么意义？

不仅要让软件工作，更要精益求精。

不仅可以响应变化，更要稳步增加价值。

不仅要有个体与交互，更要形成专业人员的社区。

不仅要与客户合作，更要建立卓有成效的伙伴关系。

    实施敏捷需要团队中每个人能力都能独挡一面，如果人的能力跟不上，还是控制变化为主。

过程

     PMP项目管理实际上是瀑布过程，而当下我们的软件开发大都是迭代开发过程。一个优秀的IT项目经理需要这点儿上面有思考。因为PMP教材不会告诉你。传统项目管理与软件工程项目管理相结合。

传统项目管理通常采用的是瀑布式、部分迭代开发模式，要求在项目建设时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大，会影响到项目的交付质量。

敏捷项目管理作为新兴的项目管理模式，简化了传统项目管理的繁琐流程和文档。以 Scrum 为代表，欢迎需求变更，在客户需求不明确的时候，以在较短的周期内开发出可用的软件为目标，来帮助客户描述自己的需求。迭代过程中的需求变更会加入到项目继续迭代需求池，丰富项目的产品功能。

具体的敏捷方法在每个迭代周期中都存在立会制度，燃尽图、看板监控、计划发布等，这些和PMBOK中对项目生命周期的五个过程组启动、规划、执行、监控和收尾的定义没有冲突矛盾，实际上敏捷项目管理的这些措施可以看作是PMBOK项目生命期五个过程组执行的微缩版，区别在于敏捷项目管理的迭代周期，时间很短，在去执行过程中裁剪了很多规范正式的项目管理流程制度。这些问题作为IT项目经理需要融会贯通。

范围蔓延

    在实际工作中，范围蔓延往往出自相关方的良好愿望，如客户要求采用不断出现的新技术，或者项目团队希望讨好客户等。在项目中，随意增加哪怕是一小件工作，都会消耗项目资源，都可能给整个项目带来不小的干扰。任何未经批准的项目范围变更都是不允许的。这种情况叫做“镀金”，即客户没有要求而项目团队主动增加的范围。除了讨好客户的原因外，秀才艺、配置强迫症也是造成“镀金”的原因，就是一定要给客户做完美才行。任何动作都会消耗资源，可做可不做的事情就不要做。

    与“镀金”对应的另一种情况叫“爬行”，即由于客户增加或改需求，项目经理被动接受而造成的范围蔓延。客户可能认为让项目团队多做一些事情会增加项目的价值，但往往会降低项目的价值。

这其实也是一种范围蔓延了。别看其中所提及的版本听起来只是比你原计划的版本强一点点而已，但是这种范围蔓延会耗费大量的时间和资源。在项目只中，最狡猾、最不易发现的一种范围蔓延就是伪装成“改进方案”或“优化方案”的蔓延。

为减少这种隐秘的范围蔓延，项目经理和团队应当明确每一步计划所包含的范围。至于那些计划之外的部分，可以当作是需求变更，走整体变更流程。

(1) 透彻理解相关方的需求。需求变更往往就是在需求分析时所埋的坑。
(2) 对顼目的所有要求都要记录在案， 形成规范的顼目文档，让需求变更有据可查、有理可依。
(3) 严格按顶目管理方法编制范围计划 ，做到专业的顼目管理。
(4) 制订并遵守项目范围管理计划。
(5) 不接受口头或微信群的变更申请，变更要走 整体变更控制流程。
(6) 坚持规范的综合评审。相关方也许会因为必须接受综合评审，而放弃某个 拍脑袋的不合理要求。
(7) 强调完工时间和预算的重要性。如果要追加工作，就只有取消另外的工作

---

今天先到这儿，希望对技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管理,团队建设 有参考作用 , 您可能感兴趣的文章:
精益IT组织与分享式领导
领导人怎样带领好团队
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。