敏捷项目管理

拥抱变化、快速响应、平等协作、持续改进

-- PMI-ACP敏捷项目管理与创新之道

文/银联培训中心主管于兆鹏

随着首届世界互联网大会召开，“互联网变革”又一次撞击了人们的眼球。人类历史上曾经发生过许多次伟大的变革，但从来没有一场变革像“互联网变革”一样能触及全球70亿个个体。

不仅仅是互联网让我们在变！

随着中国经济的转型和新生代消费群体的崛起，中国乃至世界的社会经济模式正经历着：

----以生产为核心到以需求为核心的转变

----以商户为核心到以用户为核心的转变

----以产品功能为核心到产品体验和个性为核心的转变

中国正在进行着由卖方市场到买方市场的重大社会变革，中国经济也因此将由原来的粗放型经济形式转变为集约型经济形式，由原来的世界工厂转变为未来的创新基地。

在这样的时代背景下，变革参与者需要深谙互联网“开放、平等、协作、分享”的精髓，通过互联网、移动互联网等各种工具，使得传统企业的业务具备透明度更强、参与度更高、协作性更好、中间成本更低。一句话，正如彼得?德鲁克所指出的：“互联网消灭一切基于信息不对称的商业模式”。

在新的商业模式下，作为项目经理的我们需要关注：

----如何拥抱变化，抛弃传统模式封闭的弊端，以极限迭代引领客户需求和市场变化；

----如何简化流程，最大化客户收益，始终关注组织和客户的核心价值点；

----如何将客户拉进团队，让客户之声成为打造制胜产品的真正利器；

----如何最大化激发团队潜能和创新力量，摆脱传统管理模式带给人性的束缚和禁锢；

----如何将持续改进纳入到团队每天、每小时、每分钟的工作循环，使改进这一词汇不再成为原来项目经理的口头禅，而是每个团队成员心中的戴明环；

对于我们而言，尽情享受“这场变革”的同时，正确把握社会的发展方向，才能使之继续造福于全社会。

一、为什么需要敏捷

长期以来，受传统项目管理思维的影响，项目计划往往需要很完备才有能开工的理由。我们往往因为不清楚WBS（工作分解结构）应该分解到何种程度而苦恼，或在一开始就试图将项目的方方面面都考虑得很周全，这在项目真实场景中是不可能的。

许多项目报告，尤其是在项目早期阶段显得过于乐观。因为让一个项目经理接受他们的进度会落后于时间表是一件非常困难的事情。在项目分析阶段，想知道总共有多少分析量是不可能的。那这样问题就来了，你既然不知道总量，又如何知道现在的工作能按部就班完成呢？

长久以来，我们一直在接受着这样的教导：项目经理是负责人。他管理团队，指派任务并且承担整个项目成功的责任。所有这些压力和以及所有这些期望都指向同一个人，这个人也负责项目的沟通交流工作。有了这样的场景，我们怎么可能期望项目沟通交流是中立的? 老板如果要求每周多给出一份详细的状态报告，那么这不就是一种不信任吗? 在我十五年来的项目管理职业生涯中，不断看到这种机能失调和不信任。

个人职业生涯有十年是与软件行业有关。熟知软件模型发展历史的人知道，传统软件开发模型是在20世纪60年代形成的，在那个时候统治IT王国的是大型计算机。在那个时代所使用的技术并不欢迎变更。那时候编程的模式是过程化、自上而下的。如果需要变更，就需要重新编译并组装整个程序或系统。为了安全起见，每一次编译的成品都需要新的完全测试。这个模型为其特定的技术服务，人们往往企图像神一样尝试一次性把工作做好。

后来软件行业采纳了新的面向组件的技术，但是底层的开发过程仍旧经常使用相同的传统方法。相比之下，现代软件开发通常使用面向对象的技术。这些面向对象的系统是由更小的高度聚合、松散耦合的分

块和元素组装起来的。这就使得开发团队能够以更小的步骤和单元进行开发、测试和集成。敏捷开发和敏捷项目管理方法更早、更频繁地把变更带入，而且这些方法以小的、循序渐进的步骤来构建软件。

软件行业发展只是时代发展的一个缩影，中国经济三十年来的发展同样也在经历着从传统模式到敏捷模式的演变！

20世纪80年代-90年代，中国经济刚刚腾飞，整个社会经济还是以计划经济为主导，市场导向是以厂家或供给方为核心的。实际上国家经济发展战略是以“出口导向”战略代替“进口替代”战略，以出口“量”的扩张促进经济增长。这种发展模式下就决定了卖方不需要过多关注用户的需求变化，只需要能生产出能满足市场需求量的产品就可以了，因为整个市场是供大于求的。

20世纪90年代-21世纪初，国家经济发展策略开始实施由“量的扩张”转向“以质取胜”的出口战略，更好地利用外资和技术积极实施“走出去”，从而使出口贸易在国民经济中产生质的飞跃的阶段。在这个阶段，用户开始有产品“质量”意识，开始不仅仅关注产品的量的满足，而更关注产品的品质。整个市场开始求大于供，一个重要的用户权利：“选择权”开始回归到用户手中。

21世纪初-至今，国家发展策略注重以科技为主导，使本国经济能够自主进入世界经济并居主导地位的阶段。在这个阶段，用户对产品的期望已不再满足于“质量”的需求，而是更加注重“体验”，希望产品能包含更加个性化的元素。这样的需求导致必须保证产品的开发有足够的用户参与度。

从项目需求管理的角度来说，用户的参与可以有效降低需求的“二义性”（即用户对同一种需求有不同的理解），同时通过引入用户的参与可有效提升其满意度与项目的可视性。而敏捷非常强调用户的参与，经常要求干系人对项目成果进行确认，可消除需求二义性，并提升用户体验。

二、什么是敏捷

敏捷方法是一种能够容纳变更的产品开发框架。比如，通常对于复杂的产品开发工作，需求在项目开始的时候尤其是未知的或模糊的。所以，敏捷框架必须要有内在的机制使项目得以处理并减少这些不确定因素。

敏捷也意味着框架本身也是灵活的，并可以适应许多情况。因此许多人把敏捷方法描述成“经验性”(Empirical)的方法，因为项目本身必须适应其环境。

敏捷源于敏捷宣言（Agile Manifesto）。敏捷宣言是2001年在美国犹他州的Snowbird滑雪胜地召开的一次会议提出的结果。17个与会者定义了敏捷过程并签署了宣言，这些成为了今后人们对敏捷的衡量标准。敏捷宣言只有短短的四句话，却为所有敏捷实施者提供了一个共同的基础：

----个人和交互优先于过程和工具(Individuals and Interactions Over Processes and Tools)

----可工作的软件优先于完备的文档 (Working Software Over Comprehensive Documentation)

----顾客协作优先于合同协商(Customer Collaboration Over Contact Negotiation)

----响应变更优先于遵循计划(Responding to Change Over Following a Plan)

请注意每个句子的左边比右边更有价值。这并不意味着右边的没有价值，只是说左边的更有价值。因此每个敏捷项目团队必须找到团队的正确平衡点。

PMI-ACP全称Agile Certified Practitioner，是由美国项目管理协会（PMI）于2011年推出一门敏捷项目管理的认证。PMI-ACP涵盖了目前主流的敏捷方法论，包括Scrum、XP、Lean：----Scrum：Scrum是Ken Schwaber和Jeff Sutherland在20世纪90年代开发的，他们将其定义为一种敏捷项目管理框架而不是一个敏捷过程。Scrum源于精益制造(Lean Manufacturing)、迭代-增量式开发(反复与渐进式开发)和Smalltalk工程工具。Scrum提供了一套简单的规则：首先，Scrum中有三种角色：产品所有者(Product Owner)、Scrum队长(Scrum Master)以及团队(Team)；其次，使用两种不同的待

办事宜(Backlog)来对范围进行管理：产品待办事宜(Product Backlog)-捕获产品的范围和冲刺待办事宜(Sprint Backlog)-包含当前迭代的详细工作。冲刺(Sprint)是Scrum称呼迭代的同义词，每次冲刺为4周时间。整个Scrum团队每天碰面15分钟，以便让每个成员之间相互快速更新信息。

----XP：极限编程（Extreme Programming，XP）是Kent Beck、Ward Cunningham和Ron Jeffries 在20世纪90年代开发的一套动态编程实践。现在XP是高技术行业最常采用的敏捷方法。XP中最值得关注的实践是结对编程(Pair Programming)和测试驱动开发(Test-driven Development)。

----Lean：精益开发源于Bob Charette，它是精益制造在软件开发上的应用，它是由22个工具组成的工具箱，“消除浪费”就是精益开发中有名的工具。

三、敏捷工具与方法

敏捷有许多工具，像我们熟知的迭代-增量开发、测试驱动开发、持续集成、每日例会、自适应团队等等，虽然工具方法很多，但这些万变不离其宗，其本质思想都是不断拥抱环境变化，快速响应客户需求，以开放平等的精神进行团队协作，以及不断持续改进产品。下面我们介绍迭代-增量开发、每日例会、自适应团队这三个敏捷中最核心的工具和方法：

----迭代-增量开发：迭代-增量开发可以说是对传统项目管理的颠覆。它实施的是重复和半并行化的开发活动，而不是在整个项目中只对每个产品开发周期（需求、设计、开发）执行一次（这是传统的瀑布模式）。这意味着项目活动极为窄小而且相互之间极为接近，他们的顺序也可以变更。作为一个经验方法，迭代越短越好，这也是敏捷过程每个迭代只需要大约2-6周的原因。

这个工具中第二个方面是实际的增量。迭代带来项目的节奏，而增量说明了项目的实际进展。在敏捷中，进展以可工作的软件为衡量基准。敏捷项目管理有点像切蛋糕，项目必须切成块，我们在开始的时候不知道我们需要多少块，也不知道这个会是哪种蛋糕。我们会随着项目的进行，一块一块地弄明白。这样在一个迭代的末期，一个优先级排序比较高的需求中的一块，就完成了，这是迭代-增量开发的真正的亮点：在项目启动两周（一个迭代）之后，一项需求就被转化成了可工作的软件并且可以向顾客展示。而这种方法最大的有价值之处在于，我们为客户打开了一个项目早期的反馈环，客户可以在现在做出变更并且按照他们所期待的正确方向指引项目，而这是许多客户在传统项目管理模式中无法想象的。

迭代开发不仅仅有上述优点，它的优势还在于：在早期的迭代中就可以减少或消除高风险；根据以往的迭代效果，可以越来越精准地预测完成日期的趋势；团队士气通过不断的客户反馈而增加，生产率成倍提高等等。

迭代-增量开发对于习惯于传统项目管理模式的人或机构来说是一个巨大的改变。然而，这种改变是值得的，因为它几乎可以立即带来不可估量的效益。

----每日例会：简短的每日例会是敏捷项目的常见惯例。在每日例会中，每个团队成员只对三个问题提供答案：

自从上次会议以来你都做了什么?

到下次会议前你计划做什么?

你所面临的问题和阻碍是什么?

敏捷项目经理感兴趣的是可交付和切实可见的结果，这些通常来说就是每日例会最经常失败的点。因为我们都习惯于每周或每月的项目报告，所以我们会精心包装我们的成就以证明我们在项目中的存在和价值。但认真想起来，一个人在8小时的工作时间能输出多少切实可见的成果呢? 但每日的进展却让团队成员感受到成就感，因为这时每个团队成员的真实成就，而不是应付项目经理和老板的。

----自适应团队：如果你参与过一个敏捷的每日例会，你就不难注意到每日例会中会有一对开发人员一起解读某个故事（Story）中的需求，并对其负责。在整个每日例会中，你会发现没有任何自上而下的命令的情况下，工作得到了很好的分配。在下一次例会中，团队成员将彼此报告其进展情况，也就是说他们之间相互控制。我们非常熟悉的传统项目管理中的命令控制，在这里转变成为了一种团队组织的方法。那么是否意味着在敏捷项目中不需要经理了呢? 因为团队已经是自我管理的，所以它所需要的是一个

“领导者(Leader)”。请注意由于东西方文化的差异，领导者是不同于我们在中国本土环境下理解的“领导”。

担任“领导者”需要做的事情包括：推进迭代回顾；为项目的每个需求故事以及业务迭代制定优先级顺序；评估需求；沟通项目进展；为团队排除组织上和技术上的障碍等。

你可能会说，在过去，项目经理已经承担了这些责任。是的，但是“领导者”是将愿景注入项目团队中，而不是用命令和控制的方式保持团队注意力。他负责创造一个环境，让大家觉得每个人都在朝相同的目标努力工作。

四、敏捷发展趋势

我们在前面讲过，随着中国经济由卖方市场到买方市场的转变，由粗放型经济形式到集约型经济形式的转变，用户对产品或服务的需求不再满足于功能，而更注重体验与个性。再加上90后、00后等新生代消费群体的兴起，需求的定义进行了重塑，因为新生代消费群体是一个注重个性，注重张扬的群体，他们的需求将更加趋于定制化和参与感。

这就注定了项目，这一产生产品或服务的努力或过程的管理模式必须发生变化，以适应日新月异的市场环境，以及品味越来越多样化的客户群体。传统的自上而下式、命令控制型的模式已经不能适应这个时代的需求了；反之崇尚客户参与、拥抱变化、团队自适应的敏捷模式将大行其道。

可以预见的是，在不久的将来，敏捷项目管理将在中国迅速发展，并成为与传统项目管理并驾齐驱的两大管理模式。这两大管理模式将适用于不同的场景与领域，如传统项目管理在诸如制造业、工程业等重资产、环境相对稳定的行业中继续应用发展；而敏捷项目管理将在互联网、IT、研发等轻资产、环境多变的行业得到广泛应用。

因此关注今天的敏捷就是把握未来的先机！让我们一同走进敏捷，走进PMI-ACP！在感受这个时代脉搏的同时，也感受敏捷的无穷魅力吧！

项目管理知识点总结

《项目管理》知识点总结进度计划的编制方法： 1.工程网络计划分为：双代号网络计划、单代号网络计划、双代号时标网络计划，单代号搭接网络计划。 2.工作之间的逻辑关系包括工艺关系和组织关系。 3.单代号搭接网络图的几种逻辑关系：STS、FTF、STF、FTS. 4.国际上，工程网络计划有许多名称，如：CPM，PERT，CPA，MPM等 5.工程网络计划按持续时间的特点划分为：肯定型问题的网络计划，非肯定型问题的网络计划，随机网络计划 6.按工作和事件在网络图中的表示法划分为：事件网络和工作网络 7.按计划平面的个数划分为，单平面网络图，多平面网络图。 8.美国多使用双代号网络计划，欧州则较多使用单代号搭接网络计划。 9.总时差最小的工作就是关键工作。当计划工期等于计算工期时，总时差为零的工作就是关键工作。 10.当考虑压缩关键工作的持续时间时，必须考虑下列因素：①缩短时间不能影响质量和安全工作②有充足备用资源的工作③缩短时间所需增加费用相对较少的工作 11.总时差是在不影响总工期的前提下，本工作可以利用的机动时间。 12.自由时差是在不影响其紧后工作最早开始时间的前提下，本工作可以利用的机动时间。 13.本工作的紧后工作为关键工作时，该工作的自由时差等于总时差。项目进度控制方法： 1.建设工程项目进度控制的管理措施涉及管理的思想，管理的方法，手段，承发包模式，合同管理和风险管理等。 2.常见的影响工程进度的风险有：组织风险，管理风险，合同风险，资源风险，技术风险等。 3.重视信息技术在进度控制中的应用。虽然信息对进度控制而言只是一种管理手段，但它的应用①有利于提高进度信息处理的效率②有利于提高进度信息的透明度③有利于促进进度信息的交流④有利于项目各参与方的协同工作 4.建设工

专业技术人员时间管理与项目管理-88分

1.单选题【本题型共30道题】 1.项目管理计划包括各专项计划和有关说明的()(包括经过批准的更新计划)。 A．总体综合管理计划？ B．单独计划？ C．复杂计划？ D．附加计划 2.()是—种使用国家或民间统一的标准定额和工程量计算规则去制订项目资源计划的方法 A．统一定额法？ B．调查法？ C．规章制定法？ D．推断法 3.()是根据已完成的类似项目对未来项目费用进行估算的一种方法 A．类比估算法？ B．历史估算法？ C．评估估测法？

D．统一估算法 4.()是指项目开工以后到项目竣工验收之前任何一个时点所进行的评价，它又称为项目中间评价 A．项目跟踪评价？ B．项目过程评价？ C．项目收尾评价？ D．项目后评价 5.德尔菲法依据系统的程序，采用()发表意见的方式实现的 A．匿名？ B．实名？ C．集中？ D．无规定 6.下面不属于有效防止信息泛滥的方法的是（）： A．选择有价值的书籍？ B．阅读有用的报纸和刊物？ C．合理使用电子邮件？

D．浏览微博，博客等 7.工作说明书包括经营需要、()、战略计划等 A．产品范围说明书？ B．产品预算说明书？ C．指导性文件？ D．理论结果预计书 8.研究和发现哪些项目能够促进国民经济和社会发展，能够提高人民生话水平或者提升企业的竞争力等酌项目发现过程叫做() A．项目识别？ B．项目甄选？ C．项目准备？ D．项目考察 9.下面不属于混乱产生的原因的是（）： A．“筑巢”本性？ B．作为视觉提示物？

C．爱因斯坦情结？ D．混乱可以说明有创造性 10.制定年计划的原则（）： A．越远大越好？ B．怎么过的舒服怎么制定？ C．抓住重点、兼顾其他？ D．制定一个可以随便完成的目标 11.（）可谓事务优先排序法的“鼻祖” A．ABC时间管理法？ B．艾森豪威尔法则？ C．外包原则？ D．GTD 12.象限管理法就是用坐标的方式将时间分为()个象限 A．2？ B．3？

敏捷项目管理实战之进度管理

优化项目计划 敏捷开发的基本特征是迭代开发。而迭代开发的强调的是"小批量、频繁交付"。因此，每次迭代所要实现的需求相对较少。这使得迭代开发中的项目计划制定相对容易，制定项目计划时任务与任务间的逻辑关系也比较容易掌握。但是，由于迭代开发往往采用时间盒(Time-box)的方式进行，即要求每次迭代的时间是固定的(业界推荐的是 2~4 周)。而每次迭代所要实现的需求(Story)的个数及其难度都不尽相同。这就要求我们在某些情况下要尽可能地优化项目计划，以保证工期不会超出时间盒的范围。 优化项目计划的常见方法是尽可能地使各个任务并行。比如，有两个功能的开发任务，其中一个功能 A 依赖于另外一个功能 B。但这并不意味着我们必须将这两个功能的开发任务串行安排(即先开发 B 功能，再开发 A 功能)。此时，可以使用测试桩(Testing Stub)来模拟 B 功能的实现，这样使得 A 功能的开发和测试可以先独立于 B 功能的实现。因此这两个功能的开发可以并行。 计划安排时考虑避免重复劳作也是缩短工期的一个常见方法。在 Story 驱动的一个迭代开发过程中，从第二个迭代开始，往往存在多个 Story 的实现涉及同一个模块的代码修改。此时，计划可以安排多个人并行开发这几个 Story、但是转 Story 测试时，这几个 Story 可以合并成一个"大 Story"一起转测试。从而避免了多次测试同一个模块带来的浪费。 出于应对风险的需要在安排计划时留出所谓的缓冲时间有其合理性。但是，这个缓冲时间延长了任务的持续时间。而关键任务持续时间的延长则延长了整个迭代持续的时间。值得注意的帕金森定律(Parkinson's Law)所阐述的现象却给了我们在某些情况下要适当压缩任务尤其是关键任务的持续时间。帕金森定律告诉我们：只要还有可用的时间，一件工作消耗的时间就会不断地扩展，直到用完所有的可用的时间。也就是说，一件任务如果需要 3 天时间完成，而计划安排的持续时间是 5 天的话，这个任务会消耗 5 天甚至更多的时间才能完成。这种现象的方面给了我们一个启示：如果一件任务如果需要 3 天时间完成，而计划安排的持续时间是 2 天，那么这件任务真的可能在 2 天内完成，最多也可能是 4 天时间完成。这也比将该任务计划为 5 天完成节省时间。可见，过于宽松的机会反而可能拖慢了进度，而有一定紧迫感的计划所带来的适当压力可以激发人的动力和潜能反而可以加快进度。 对于迭代中的技术风险点要优先安排进行验证。比如，对于从未使用过的技术或者新技术，要优先安排原型的验证，避免中途才发现技术障碍。 进度信息的获取 由于团队开发中的每个团队成员的日常工作之间都存在或多或少的依赖关系：某个人的工作要以其他人的一件工作产出为输入，同时其工作的输出又是另一个人的某件工作的输入。 从团队自我管理的角度来说，进度信息是将团队成员的工作自主得衔接起来的重要因素。因此，敏捷开发团队中，进度不应该是只有项目经理才关心的事情，而是整个团队成员都应该关心的事情。但事实上，团队成员往往倾向于只关心自己手头上的工作。因此，项目经理需要引导和鼓励团队成员主动关注自己手头上的任务所依赖的任务的进度。 另一方面，进度是整个团队应该关心的事情，这就要求在团队内有一个统一的进度信息获取与发布的平台和途径。这个平台可以是一个管理软件，比如工作流软件。也可以是一个即时通讯软件。不管采用什么样的平台，项目经理应该引导和鼓励团队成员主动将各自的进度信息推送到这个平台，而不是每个人进度还要等其他人来询问。

项目管理知识点

项目的优先级排序则取决于风险、资金和与组织战略规划相关的其他考虑。 项目管理就是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。项目管理通过合理运用与整合47 个项目管理过程得以实现。可以根据其逻辑关系，把这47 个过程归类成五大过程组，即： 启动 规划 执行 监控 收尾 管理一个项目通常包括（但不限于）： 识别需求。 在规划和执行项目时，处理干系人的各种需要、关注和期望。 在干系人之间建立、维护和开展积极、有效和合作性的沟通。 为满足项目需求和创建项目可交付成果而管理干系人。 平衡相互竞争的项目制约因素，包括（但不限于）：

○范围 ○质量 ○进度 ○预算 ○资源 ○风险 建立一个新的通信卫星系统就是项目集的一个实例，其所辖项目包括卫星与地面站的设计、卫星与地面站的建造、系统整合，以及卫星发射。

1.4.2 项目组合管理 项目组合是指为了实现战略目标而组合在一起管理的项目、项目集、子项目组合和运营工作。项目组合中的项目或项目集不一定彼此依赖或直接相关。例如，以投资回报最大化为战略目标的某基础设施公司，可以把油气、供电、供水、道路、铁路和机场等项目混合成一个项目组合。在这些项目中，公司又可以把相互关联的项目作为项目集来管理。所有供电项目合成供电项目集，所有供水项目合成供水项目集。如此，供电项目集和供水项目集就是该基础设施公司企业级项目组合中的基本组成部分。 项目组合管理是指为了实现战略目标而对一个或多个项目组合进行的集中管理。项目组合管理重点关注：通过审查项目和项目集，来确定资源分配的优先顺序，并确保对项目组合的管理与组织战略协调一致 1.7.1 项目经理的责任与能力 总体来说，项目经理有责任满足以下需求：任务需求、团队需求和个人需求。项目管理是一门很重要的战略性学科，项目经理是战略与团队之间的联系纽带。项目对于组织的生存与发展至关重要。项目可以用改进业务流程的方式创造价值，对新产品和新服务的研发不可或缺，能使组织更容易应对环境、竞争和市场变化。因此，项目经理的角色在战略上越来越重要。但是，仅理解和使用那些被公认为良好做法的知识、工具和技术，还不足以实现有效的项目管理。要有效管理项目，除了应具备特定应用领域的技能和通用管理方面的能力以外，项目经理还需具备以下能力： 知识能力——项目经理对项目管理了解多少。 实践能力——项目经理能够应用所掌握的项目管理知识做什么、完成什么。 个人能力——项目经理在执行项目或相关活动时的行为方式。个人态度、主要性格特征

关于华为敏捷项目管理

关于华为敏捷项目管理 IPD –集成产品开发，华为花重金从IBM购买的一套产品集成开发流程，业界有一本书，P ACE讲的就是这一套IPD 流程，而IPD并不去讲你的开发要怎么做，IP D做的就是“投资决策、市场驱动”，更多的是决定做不做这个事情，做这个事情对于投资人员是不是受控的，所以在IP D里面会有DCP点（决策评审点），每个点上都会去考虑该不该做、值不值得去做，在引入这个东西以前，华为实际上是技术驱动的，并不是市场驱动的，就是说以前华为听说有个新技术，然后就开始做，做了很多这样的东西，但是后来都卖不出去，所以后来就引入了IPD，以市场驱动。在引入IP D后，是解决了做什么的问题，但是怎么做，还是按照自己的想法去做，后来就引入了CMM，引入CMM后对华为确实起了非常大的作用，其产品开发的质量确实是比起前提高了，所以在前几年，通过IPD+CMM 使得华为走向了一个非常成熟的过程。在这个基础之上，关于质量管理、项目管理华为提出一些自己的体系，比如从项目的开始到项目的结束，有项目review、度量分析、根因分析、缺陷预防等一系列活动，在项目管理方面有风险管理、问题跟踪管理等活动，同时还会有质量审计以及相关的推动等事情，通过这些项目管理和质量保证使得IP D和CMM很正常的运作下去，但是现在行业已经发生了一些变化，比如需求变化快等方面华为也碰到了一些问题，以前产品质量是可控的，大多数产品的发布周期也是稳定的，比如对客户承诺什么时间提交产品基本上是有保证的，另外项目在管理层的进展也是非常清晰化的，你在向某某领导汇报的时候只用告诉他比方项目到了SRS阶段了，基本上这个项目的老大就知道这个项目还有多少事情需要去做，比如告诉他到单元测试阶段了，他就知道快搞定了，这样确实使得这个进展能够口头化。其实，流程存在的价值，就是能够给我们的管理层提供进展的可视化，所以从目前来看，对于客户、员工、管理层这三个利益相关人来讲确 实达到了这样一个目的。 但是现在行业中，需求变化太快，不管我们怎么努力去做，发现还是不能满足客户的需要，不管需求搞得多么细，到交付产品给客户的事情，总是有这样那样的问题，这个时候就不得不去修改我们的软件，这是华为面临的一个挑战，如何 解决这个问题？ 软件开发中有三个要素：人、过程、技术和工具。对于一个软件项目成功来说，这三个要素都不可省，而在以前大家强调IPD和CMM，更多的是强调大家规范的把它运作起来，对于人、技术和工具基本上不提了，忽略了，所以后来就反馈出一个问题，就是很多项目，看起来那个过程做的那个漂亮，那个报告写得那个完美，但是交出去的产品那个烂，其实这三个因素是缺一不可的，你必须得均匀的发展，还有一个是人的方面，因为人是具备创造能力的，所以从华为的教训给我启发，过度的关注过程而忽视人、忽视技术和工具，我们就得要思考和反省了。 针对这些问题，华为也就提出了敏捷。华为在99年之前基本上都是土生土长游击队的做法，到了2001年的时候就引入了IPD和CMM，到2006 年的时候，就发现了瀑布模型的问题，如交付周期特别长，就是每做一个客户的需求，然后一分析，这样一走半年就过去了，所以就引入了RUP，最初的想法就是加速我们项目的交付周期，能够快速的给客户响应，但是敏捷实际上已经进入了一个低谷期，所以当时就引入了迭代，实施了一年之后也发现，RUP里面的东西实际上也是挺多的，所以后来就接触了XP、SCRUM这些方法，这样就从07年开始向敏捷这个方向在走。 有一个图在业界流传比较广泛，也叫洋葱图，共分三圈，也就是从三个不同层面描述了敏捷开发方面的一些最佳实践。XP为什么叫极限编程？如果你觉得这个软件开发的实践是一个好的实践，那么你就把它发挥到极致。比如，结对编程，一个在编，一个人在看，实际上看的人不会白看，其实起到了一个review的作用，既然review这个作用有效，那么为什么不把这个作用发挥到极致，所以就采用了结对编程将review这个作用发挥到极致。在敏捷中有一个8个字的原则：沟通、反馈、交流、勇气。它认为项目团队中的成员这个沟通是比较重要的，既然你非常重要，那么我也要把你发挥到极致，所以两个人一起在干活的时候就会不停的有交流与沟通，所以，结对编程是一个典型的把review、沟通交流发挥到极致的实践。另外，TDD也可以认为是那刚好够用的事情发挥到极致。我们以前传统的软件开发的做法是，先做好这个软件，然后去测，看看是不是实现了这样一个功能，但是我们总会发现这里面有很多代码其实是从来就没有用过的，只是在下代码的时候顺手就把它写了，在分析那些产品的时候发现有的产品这样的没用到的代码高达50%，而TDD的

项目管理知识体系中的九大知识领域

项目管理知识体系中的九大知识领域 九大知识领域，是项目管理知识体系的重要内容，涉及内容非常广泛，在这里将会把各个知识领域中的主要管理内容和关键点作一介绍，如需了解更为详细的内容，请参考PMBOK以及相关的专业论著。 1.4.1集成管理 集成管理是项目管理九大知识领域中的第一个领域，与其它八个知识领域相比，这个领域的内容比较特殊，它并没有提供具体的知识点和具体的操作方法，而是反复强调围绕项目的全局观，在项目内部各个部分之间、在项目内部与外部之间，对各种内容进行集成，使各个相关方面形成有机的整体，保持管理上的一致性。这个知识领域的内容对于项目经理们来说可能感觉比较空泛，但对于企业级项目管理体系建设来说，则是非常具有指导意义的。 下面是项目管理中几个常见的集成方面的问题： 1、将项目计划中各个管理领域的子计划综合而成整体的项目计划。例如在整体项目计划中，要包括范围管理计划、时间管理计划、成本管理计划、质量管理计划、人力资源计划、沟通计划、风险管理计划、采购计划等，将这些不同的管理计划有机的结合起来，使整体项目计划能够有效涵盖项目管理的各个领域的管理内容并保持一致. 2、将项目的各个过程有机的集成起来。在后面我们会提到项目的五大过程——启动、计划、执行、控制、收尾。这些过程在整个项目当中，在项目的各个阶段当中，都可以根据管理的需要灵活运用，但是各个过程之间的关系仍然要符合基本的关系要求，这五大过程之间的关系会在后面的章节中进行介绍。 3、项目管理与企业日常运营管理的集成。不论企业是以项目方式从事主营业务，还是利用项目从事改革、创新，都存在着项目与企业日常运营之间的关系。在项目过程中通常会占用企业资源，也会对企业的日常工作产生一定的影响，如何协调资源、配合工作，同时满足两方面的需要，这就是经常遇到的一种集成管理的要求。例如在创新活动中，项目会产出成果，可能形成面向内部用户或外部客户的产品，企业就要考虑围绕这些产品的销售、支持服务等一系列的企业运营中的问题，因此，企业往往在项目初期定义项目成果时，就要求考虑项目成果在以后的企业运营中的管理问题。 4、项目生命周期与产品生命周期的集成。企业管理的核心内容都是围绕产品的（包括服务型产品），企业一定会对产品的生命周期进行管理，在产品的整个生命周期当中，产品的每一次进步，都是以项目的方式来实现的，从市场调研、可行性分析、产品设计、产品生产、市场促销、产品改进等各个不同的阶段，都可以单独成为项目。这时的项目的生命周期包含在产品的生命周期当中，项目的成果成为产品发展的阶段成果。因此，在项目管理中，还要同时兼顾产品长远发展的需要。 5、项目范围与产品范围的集成。当一个产品由不同的部分组成时，每个部分都可以单独生产时，就一定存在着项目范围与产品范围集成的要求。例如在汽车装配厂，需要从许多不同的加工厂采购不同的零部件来进行装配，对于零部件加工厂来说，设计、改进零部件的创新项目，不能孤立的对待，而是要考虑该零部件与其它相关部分的配合关系，考虑对整车的影响。如果把整车涉及的全部零部件看作是产品范围，针对某个零部件的改进就是单个项目的项目范围，那么项目范围就应该与产品范围进行有效的集成。 6、不同部门的成果的集成。当一个项目涉及企业内外多个部门和单位时，特别是当项目在企业中处于职能式或弱矩阵式组织结构时，通常会出现各个部门分头完成自己所分管部分的任务，将各自的成果提交给项目，那么在项目中就必须将这些成果集成在一起，形成项目的整体成果。 7、项目中不同约束条件的集成。不同的利益干系人可能会对项目提出不同要求，各种各样的外部因素会对项目形成不同的约束条件，例如外部法规的强制性要求、企业内部的管理要求、不同领导和部门的限制性要求、内部资源自身的特殊要求、项目发起者对项目本身的相关要求等，为项目管理勾画出了项目的边界，这个边界就直接反映出各个方面的约束条件的集成结果。 还有许多其它方面的集成问题，这里不能一一列举。由此可以看出，项目并不是孤立存在的，它受到来自项目内部和外部的多方面的影响，要管理好项目，就必须有很强的全局观。因此，在企业级项目管理

项目管理部简介(部门介绍)

项目管理部部门介绍 XX公司项目管理部是公司新设项目的执行管理部门。主要制订项目计划和目标，开展项目立项、组织实施工作、管理、监督项目运作过程，确保项目的咨询、设计工作按合同要求组织实施，且需符合法律法规，符合质量、安全、环境、职业健康安全等内容。并负责质量、安全、环境方面的交底工作，并在项目进行过程中提供技术服务，最终达到按时按量顺利完成。所以项目管理部以开阔思路和视野，敏捷的思维习惯，务实的工作作风，全新的管理方法处理公司跨领域的复杂问题，并实现更高的运营效率。 XX项目管理部主要工作流程是：项目启动、项目计划、项目执行、项目控制、项目收尾共五个过程。根据各个阶段的特点和所面临的主要问题，进行系统分析，制定可行性的解决方案。归纳为四大工作内容和管理领域，即综合管理内容、施工管理、质量管理、风险管理，并分别对各领域的知识、技能、工具和技术作了全面的总结。 一、项目综合管理内容 1、组织工程项目论证； 2、组织项目建议书、可行性报告的编制； 3、工程技术、功能设计、工程监理、现场施工安全、变更控制、工程进度和工程质量管理、组织实施项目的巡检； 4、负责组织工程勘察设计，审查勘察设计方案、勘查报告和设计图纸的质量，并出具意见； 5、负责现场施工管理，审查施工组织设计、施工技术方案和施工进度计划等，并出具意见； 6、对工程项目工程竣工验收报送的有关资料进行审查，并会同有关部门对项目进行验收；

7、督促好各类工程建设项目档案管理。 8、洽谈并签订项目合同。 二、项目施工管理 1、负责项目施工计划的制定与落实，执行施工方案，协调项目现场施工的各项工作； 2、参与编制项目质量、环境、职业健康安全管理规定，严格按标准、合同施工； 3、参与制订项目进度计划，细化执行进度计划，确保项目施工工作按时完成。 三、项目质量管理 根据国家法律法规和企业的相关规定，制定并修改质量、环境、职业安全的规章制度，建立完善的质量、环境、职业健康安全管理体系。 四、项目风险管理 根据国家法律法规和企业的相关规定对项目风险从识别到分析乃至采取应对措施的一系列过程，主要包括项目风险识别、风险量化、制定风险对策三个方面。 项目管理部 二〇一四年三月七日

(完整word版)项目管理常见问题解决办法

当前项目管理中的问题非常复杂，问题的多样性可以用五彩缤纷来形容，可能是不一而足的。我们且对一些有针对性的具体问题及其建议的解决方案尝试汇总如下： 1、问题一：如何修订不合理的项目目标？ 问题描述：很多项目在签约的阶段就定义了不合理的目标，这往往是由于销售人员的过度承诺或给客户主动建立或被动接受过高的期望值。 建议的解决方案：要使项目成功实施，就必须在合同约定目标基础上对项目目标进行再次定义，项目经理需要运用必要的办法在项目管理生命周期内不断去寻求客户或用户可接受的最小或最优的目标边界。当然，项目经理一上任就想动项目或合同的边界，显然会容易引起客户的反感。比较好的策略是先在项目实施过程中做出必要的业绩，在与此同时和客户之间建立彼此的基本信任。在充分了解客户所在企业的核心需求后，适时拿出有理有据的方案一点一点地说服客户调整项目目标边界。 2、问题二：如何处理用户强烈坚持需要的需求？ 问题描述：用户有时很强烈表示需要一个功能，态度很坚决，应该如何应对？ 建议的解决方案：从项目所要实现的业务全局出发，考虑用户这个需求到底要解决的是什么问题，然后再和用户探讨真正解决问题的办法，这样用户不但可能收回自己的想法，还会建立对你分析能力的信任。这就是所谓的比用户多想一步，并站在更高的角度去解决当前存在的问题。除此之外，如果用户提出的需求非常到位，确实指出项目所交付的产品的严重不足，项目经理要高度重视，及时调用公司资源予以解决，切记关键性需求绝对不可以绕过或采取临时解决方案。针对用户潜在的或尚未发现的需求，需要提前拟定预案，而不是等这些潜在需求发生后再考虑客户化开发解决，这样就很有可能使项目产生不必要的延期和徒增用户对项目延期所产生的不满情绪。 3、问题三：如何处理来自用户的需求变更？ 问题描述：用户的需求往往随着项目的深入而有所变化，项目验收标准的不断更改，导致项目验收延期或成本超支等诸多不可控的情况发生。 建议的解决方案：在项目一开始就需要定义变更流程，一般是要求用户内部意见一致后再统一以正式项目文件的方式提交给项目经理做评估分析，项目经理综合考虑此需求的变更对实施成本和项目进度可能造成的影响。必要时寻求公司高层或变更控制委员会(CCB)反馈

浅谈敏捷项目管理在软件开发中的应用

浅谈敏捷项目管理在软件开发中的应用 摘要：本文先介绍了使用传统项目管理技术管理软件开发项目的方法，然后介绍了使用敏捷项目管理的初步实践，通过两者比较，提出了使用敏捷项目管理进行软件开发的方法。 一、使用传统项目管理技术管理软件开发项目的方法 按照《人月神话》的说法，软件开发是个焦油坑，书店里关于软件开发管理的书籍林良满目，各个软件开发组织也在尝试和应用不同的软件开发管理办法，希望寻找到“软件开发的银弹”。 在软件开发管理中，引入项目管理的办法，已经得到广大软件开发管理人员的一致认同，但对于具体实施何种项目管理办法，各个软件开发组织都有不同的答案，更多的迷茫，因为引入的项目管理办法不能从根本上解决软件开发项目面临的进度拖后、费用超支等问题，软件开发的银弹到底在哪里？ 以下是笔者对国内软件开发组织不同项目管理成熟度的归纳和总结，大概可以分如下几类;1)小作坊、混沌形的，这样的组织还处在接单求生存的阶段，管理者还根本没有项目的意识，以满足客户需求、定制开发和回款为第一要务；2）尝试按照项目管理的思路与方法管理软件开发项目，但发现推

行困难，不得要领，目前很多中小型的软件开发组织都处于这个阶段；3）大型的软件企业，已经通过CMM|ISO认证、有足够的资源做保障，实行规范的项目管理做法，如一些软件外包工厂。 本文主要讲述处于第二个层次的软件开发组织的项目管理问题。软件开发项目管理涉及非常多的内容，从软件开发本身的业务出发，有需求管理、变更控制、配置管理、测试管理、系统分析与设计等；从项目管理的知识领域角度，有范围管理、时间管理、沟通管理、人力资源管理等内容。 按照传统的经典项目管理方法，通过一定的项目管理模板与IT工具，总结多个项目的经验，笔者总结有如下经典步骤来完成项目管理的计划编制与进度控制过程： 计划编制的经典步骤： ①建立企业和项目资源库：这个是进行项目管理的基础工作。 ②设置项目日历、资源日历。 ③设置项目的主要里程碑点。 ④在WBS（工作包）下列出工作清单（Task，Activity）。工作分解结构（WBS）和作业是进行项目范围管理的途径。 ⑤对每个Task估计工期。 ⑥连接每个Task间的逻辑关系（SS，FS，FS，FF，延时）。

PMP 项目管理知识点

项目管理知识点 项目管理知识点1：PMI（project management institute)是指美国的项目管理协会，于1969年成立，现已是全球最大的项目管理组织。 PMP （Project Management Professional）指项目管理专业人员资格认证，其证书由美国项目管理协会（PMI）颁发及认证，得到全世界的普遍公认。 PMBOK（The project management body of knowledge)。是由PMI的成员开发的一套项目管理知识体系，国际标准化组织也以该体系为框架，制定了ISO10006关于项目管理的标准。 项目管理知识点2：什么是项目：项目是为创造独特的产品、服务或成果而进行的临时性工作。什么是管理：哲学定义：管理是集中人的脑力和体力达到预期目的的活动。常规定义：管理是指在一定组织中的管理者，运用一定的职能和手段来协调他人的劳动，使别人同自己一起高效率地实现组织既定目标的活动过程。 项目管理知识点3：项目管理5大过程组包括启动、规划、执行、监控、收尾，九大知识领域包括：整合、范围、时间、成本、质量、人力资源、沟通、风险、采购。 项目管理知识点4：整合管理的概念：项目管理的管理哲学，最本质的内容。实现项目各要素之间的相互协调，在相互矛盾、竞争的目标中寻找最佳平衡点。追求整体利益最大化。各要素之间存在结合部（界面，Interface），只要有结合部就需要整合。 项目管理知识点5：三个重要的项目文件：项目章程、项目范围说明书、项目管理计划。 项目管理知识点6：整合管理的实现过程：启动（制定项目章程）、规划（制定项目管理计划）、执行（指导与管理项目执行）、监控（监控项目工作、实施整体变更控制）、收尾（结束项目或阶段）。 项目管理知识点7：项目启动通常是由发起人、管理层和PMO来完成的。项目

项目管理全过程所有环节WORD

项目管理全过程各项模板 项目需求建议书（RFP） A. 项目信息 提供关于项目名称、客户名称、项目经理以及项目发起人姓名等方面的一般信息 项目名称：客户名称：项目经理：文件起草人：项目发起人：日期：B. 项目目标 项目授权书 A. 项目信息 提供项目名称、客户名称、项目经理以及项目发起人姓名等与项目相关的一般信息 项目名称：客户名称：项目经理：授权书起草人：项目发起人：日期：

项目计划文件 A. 项目信息 提供项目名称、客户名称、项目经理以及项目发起人姓名等与项目相关的一般信息 项目名称：客户名称：项目经理：文件起草人：项目发起人：日期：

□项目范围说明书 描述项目交付结果和工作范围的书面文件 □关键的成功因素 描述关于项目管理、项目团队建设、客户关系管理等方面关键的成功因素方面的书面文件，以便得到项目小组成员的理解、接受和达成共识 □工作分解结构（WBS） 是以项目的交付结果为导向而分解出的、表明项目具体工作任务的书面文件，它定义了整个项目的工作范围 □组织分解结构（OBS） 提供项目沟通与汇报渠道，角色与职责，以及授权等方面信息的组织机构方式 □成本/效益分析 提供关于项目成本与收益，项目的货币价值等方面的信息，以便团队进行财务方面的分析，并作出经济决策 □资源计划 描述执行项目需要资源方面信息的书面文件 □项目进度计划 提供用甘特图表示的项目进度计划，包括项目的开始日期、里程碑事件、活动之间的先后逻辑关系、活动历时、交付日期等信息 □风险管理计划

描述在项目执行过程中可能出现的所有风险事件，每个风险严重程度，以及应急措施的书面文件 □采购计划 描述为了完成项目任务，需要从项目组织以外获取的产品或服务的种类和数量的书面文件 □质量计划 提供确保产品或服务质量的责任人，工作程序与作业指导书，以及质量检验与控制的措施等书面信息□沟通计划 定义项目利益相关者对项目信息方面的需要，包括谁、在何时、以什么方式需要何种信息等 □配置管理计划 提供关于定义和控制项目变更管理，文件版本以及设计变更方面的管理方式 □项目成本估算 关于项目成本和预算的书面文件，内容包括项目的总体预算、成本估算以及额外需要的资源等等 项目需求文件 A. 项目信息 提供项目名称、客户名称、项目经理以及项目发起人姓名等与项目相关的一般信息 项目名称：客户名称： 项目经理：文件起草人： 项目发起人：日期： B. 项目背景

pmbok项目管理知识重点笔记

p m b o k项目管理知识重 点笔记 Company number：【0089WT-8898YT-W8CCB-BUUT-202108】

第一章项目管理框架部分 【本章知识重点】 ★项目及其特点； ★项目和运营的相同点与不同点。 ★项目管理及其几个过程； ★Program / project / subproject的区别与关系。 【电子笔记】 项目管理知识体系（PMBOK） PMBOK是美国项目管理学会（PMI）提出的一个涵盖面很广的项目管理知识体系，内容包括项目管理（Project Management）这一职业的知识总和。PMBOK不是教科书，它并没有详细地解释知识体系中的那些术语，它只提供了项目管理的一种正确思路和管理技能与知识。 PMBOK是以西方人的思维方式，尤其是美国人的思维方式来看待项目管理问题的，所以我们在学习过程中要习惯他们考虑问题的思路。PMI一直不遗余力地促使为项目经理放权，期望创造一个良好的环境给项目团队。PMI很重视历史资料和检验教训，PMBOK知识体系将这些信息作为数据库的一部分，供项目以及执行组织的其它项目使用。数据库是知识管理的基础。 项目管理是管理偶然性的职业。我们成为PM（Project Manager）通常都是偶然的。组织任命某人为PM，有时只是对其技术绩效的嘉奖。 什么是项目 项目(Project)的定义：为创造某项独特产品、服务或结果所做的一次性努力。

1.2.1一次性( Temporary ) 一次性是指每个项目都有确定的(Definite)开始和确定的结束。当项目目标达到时，项目也就结束了。如果项目目标明显无法完成时，一般来说项目会终止。一次性一般不适用于项目所产生的产品或服务。项目经常会产生比项目本身更久远的，事先想到或未曾料到的社会、经济和环境影响。 1.2.2独特( Unique ) 项目所进行的都是以前没有进行过的事情，因而是独特的。一项产品或服务尽管其所属的类别范围很大，依然会是独特的。例如办公楼已经建造了成千上万座，但其中每一座都是独特的：不同的业主、不同的设计、不同的地点、不同的承建人等等。 什么是项目管理( Project Management ) 项目管理：就是将各种知识、技能、工具和技术应用于项目之中，用来满足或超过项目干系人对项目的要求和期望。项目管理是通过诸如启动、规划、实施、控制、收尾5个过程进行的。 Program / project / subproject的区别与关系 大型项目( programs )：是以协同的方式获取单独管理所无法取得之效益的一组项目。许多计划还包括持续营运部分。 子项目( sub-programs )：项目常常被划分为若干个较易管理的组成部分，称为子项目。子项目又常常分包给外部的承包商或内部的其它职能单位。子项目一般被视为项目，并按项目进行管理。 第二章项目管理的环境 【本章知识重点】 ★项目生命周期及其特点； ★项目生命周期和产品生命周期的定义与区别； ★项目干系人的定义、冲突如何解决 ★组织结构（每种组织的优缺点、项目经理的权限与称呼）。

敏捷项目管理终审稿)

敏捷项目管理 公司内部档案编码：[OPPTR-OPPT28-OPPTL98-OPPNN08]

拥抱变化、快速响应、平等协作、持续改进 -- PMI-ACP敏捷项目管理与创新之道 文/银联培训中心主管于兆鹏 随着首届世界互联网大会召开，“互联网变革”又一次撞击了人们的眼球。人类历史上曾经发生过许多次伟大的变革，但从来没有一场变革像“互联网变革”一样能触及全球70亿个个体。 不仅仅是互联网让我们在变！ 随着中国经济的转型和新生代消费群体的崛起，中国乃至世界的社会经济模式正经历着： ----以生产为核心到以需求为核心的转变 ----以商户为核心到以用户为核心的转变 ----以产品功能为核心到产品体验和个性为核心的转变 中国正在进行着由卖方市场到买方市场的重大社会变革，中国经济也因此将由原来的粗放型经济形式转变为集约型经济形式，由原来的世界工厂转变为未来的创新基地。 在这样的时代背景下，变革参与者需要深谙互联网“开放、平等、协作、分享”的精髓，通过互联网、移动互联网等各种工具，使得传统企业的业务具备透明度更强、参与度更高、协作性更好、中间成本更低。一句话，正如彼得德鲁克所指出的：“互联网消灭一切基于信息不对称的商业模式”。 在新的商业模式下，作为项目经理的我们需要关注：

----如何拥抱变化，抛弃传统模式封闭的弊端，以极限迭代引领客户需求和市场变化； ----如何简化流程，最大化客户收益，始终关注组织和客户的核心价值点； ----如何将客户拉进团队，让客户之声成为打造制胜产品的真正利器； ----如何最大化激发团队潜能和创新力量，摆脱传统管理模式带给人性的束缚和禁锢； ----如何将持续改进纳入到团队每天、每小时、每分钟的工作循环，使改进这一词汇不再成为原来项目经理的口头禅，而是每个团队成员心中的戴明环； 对于我们而言，尽情享受“这场变革”的同时，正确把握社会的发展方向，才能使之继续造福于全社会。 ? 一、为什么需要敏捷 长期以来，受传统项目管理思维的影响，项目计划往往需要很完备才有能开工的理由。我们往往因为不清楚WBS（工作分解结构）应该分解到何种程度而苦恼，或在一开始就试图将项目的方方面面都考虑得很周全，这在项目真实场景中是不可能的。 许多项目报告，尤其是在项目早期阶段显得过于乐观。因为让一个项目经理接受他们的进度会落后于时间表是一件非常困难的事情。在项目分析阶段，想知道总共有多少分析量是不可能的。那这样问题就来了，你既然不知道总量，又如何知道现在的工作能按部就班完成呢

项目管理手册介绍

《项目管理手册》介绍（借用集群工程管理讲座） 一、编制背景 1、通过芳邻、锦上花趣园的有效积累、总结，对小户精装修项目管理形成标准化管理。 ①原创性（来源于实际需要，不是照办照抄） ②坚持由上而下的原则(体系建设必须从高处建立框架，再从小处落实细节) 2、花好园的系统推进和提升（系统性）——对项目建设的系统性认识 ①项目实施过程需要程序化、合理化，降低不均衡性，保持现场秩序； ②通过项目管理，将上千个、上万个工程活动导演成为一个有序的高效率的经济 的实施过程。 3、目前国内房地产项目工程管理的发展方向—— （1）、谁控制了工程资源，谁就要承担相应的责任； （2）、目前，房地产企业牢牢地把控着工程资源，所以工程管理的宏观控制必须由房地产企业自己完成，比如：工程实施控制计划、施工总平面布置等； （3）、近期房地产工程管理的方向将是房地产企业要做“传统观念中施工总承包的部分工作”。 4、公司产品标准化需要建立标准作业模式。 5、房地产商业化、市场化、专业化以后，传统的规范已经滞后于市场对产品提出的要 求。从客户导向出发要求对产品质量提出更高要求。

二、在项目工程管理中面临的重要问题 1、产品本身的特点——集群工程管理带来 2、“人”的因素——工程管理实际上是面临四个层次的人的问题 ①项目部内部的人员管理——相对地容易执行 ②公司相关部门的协调沟通——需要公司层面有效地达成共识 ③对供应商的管理。在人的管理上，实际上面临如何管理不属于企业的员工，这是目前 很多企业面临的共同课题。当工程细化分包成为趋势，项目管理面临的外包数量日益增加，对其工作能力、工作态度、工作绩效如何关注？——这在管理上最难的。 ④对操作工人的管理——建筑产品尚处于大量手工操作阶段，工人水平直接影响产品质 量，统一产品质量标准要求建立统一的操作模式。——制定《作业指导书》，但制定标准仅迈开第一步，执行、纠偏、优化，还有很多后续工作需要进行。 3、解决之道——建立统一的管理制度，把所有供应商纳入统一的标准之下进行管理。 ——计划、协调、“时间、空间分离”、狠抓工序管理 （1）细化合同 （2）根据项目工程规律，依靠标准化、规范化管理，达到统一认识、统一标准、统一行动步伐——标准动作重复作，是效率最高、成本最低、威慑力最大的—— 共振的力量——军队的步伐；——插入《施工配合要求》 （3）工程项目管理必须依靠自身形成完善的保证体系，并与承建商共同构成一套完整的体系，才能使项目管理得到有力的保障，从而维护自己的产品品质和品牌

工程项目管理公司的简介怎么写范文

工程项目管理公司的简介怎么写范文 导语：工程项目管理公司的简介范文怎么写，以下小编为大家介绍工程项目管理公司的简介怎么写范文文章，仅供参考! 工程项目管理公司的简介怎么写范文 姓名：xx 性别：男 婚姻状况：未婚 民族：汉族 户籍：广东-东莞 年龄： 26 现所在地：广东-深圳 身高： 170cm 希望地区：广东-深圳 希望岗位：经营/管理类-项目经理/主管 工业/工厂类-新产品导入工程师 工业/工厂类-项目工程师 寻求职位：项目经理、高级项目管理工程师 教育经历 20xx-09 ～ 20xx-06 哈尔滨理工大学测控技术与仪器本科 培训经历

20xx-02 ～ 20xx-04 TDK DFM(Design For Manufacture) 20xx-02 ～ 20xx-04 TDK FMEA(Failure Mode and Effect Analysis) 20xx-09 ～ 20xx-xx TDK DOE(Design Of Experiment) 工作经验至今2年xx月工作经验，曾在1家公司工作 **公司 (20xx-09 ～至今) 公司性质：外资企业 行业类别：电子、微电子技术、集成电路 担任职位：项目管理工程师 岗位类别：新产品导入工程师 工作描述： 试产期: 1.协助处理客户RFQ，提供工序流程及物料清单。 2.负责项目运作，制定整体规划并对项目进行分解。 3.协调项目成员，并对资源进行合理分配。 4.制定物料采购计划，确保项目所需资源能按时到位。 5.项目数据分析，缺陷分析，协助制定改善措施及效果跟踪。 6.项目进度管理，确保关键路径上的任务按时完成。 7.项目质量管理，可靠性评估，保质保量完成客户交付并顺利量产。 8.DFM管理，确保设计能降低成本，提高产能，提高良率，更快速导入MP。

敏捷项目管理

拥抱变化、快速响应、平等协作、持续改进 -- PMI-ACP敏捷项目管理与创新之道 文/银联培训中心主管于兆鹏 随着首届世界互联网大会召开，“互联网变革”又一次撞击了人们的眼球。人类历史上曾经发生过许多次伟大的变革，但从来没有一场变革像“互联网变革”一样能触及全球70亿个个体。 不仅仅是互联网让我们在变！ 随着中国经济的转型和新生代消费群体的崛起，中国乃至世界的社会经济模式正经历着： ----以生产为核心到以需求为核心的转变 ----以商户为核心到以用户为核心的转变 ----以产品功能为核心到产品体验和个性为核心的转变 中国正在进行着由卖方市场到买方市场的重大社会变革，中国经济也因此将由原来的粗放型经济形式转变为集约型经济形式，由原来的世界工厂转变为未来的创新基地。 在这样的时代背景下，变革参与者需要深谙互联网“开放、平等、协作、分享”的精髓，通过互联网、移动互联网等各种工具，使得传统企业的业务具备透明度更强、参与度更高、协作性更好、中间成本更低。一句话，正如彼得?德鲁克所指出的：“互联网消灭一切基于信息不对称的商业模式”。 在新的商业模式下，作为项目经理的我们需要关注： ----如何拥抱变化，抛弃传统模式封闭的弊端，以极限迭代引领客户需求和市场变化； ----如何简化流程，最大化客户收益，始终关注组织和客户的核心价值点； ----如何将客户拉进团队，让客户之声成为打造制胜产品的真正利器； ----如何最大化激发团队潜能和创新力量，摆脱传统管理模式带给人性的束缚和禁锢； ----如何将持续改进纳入到团队每天、每小时、每分钟的工作循环，使改进这一词汇不再成为原来项目经理的口头禅，而是每个团队成员心中的戴明环； 对于我们而言，尽情享受“这场变革”的同时，正确把握社会的发展方向，才能使之继续造福于全社会。 一、为什么需要敏捷 长期以来，受传统项目管理思维的影响，项目计划往往需要很完备才有能开工的理由。我们往往因为不清楚WBS（工作分解结构）应该分解到何种程度而苦恼，或在一开始就试图将项目的方方面面都考虑得很周全，这在项目真实场景中是不可能的。 许多项目报告，尤其是在项目早期阶段显得过于乐观。因为让一个项目经理接受他们的进度会落后于时间表是一件非常困难的事情。在项目分析阶段，想知道总共有多少分析量是不可能的。那这样问题就来了，你既然不知道总量，又如何知道现在的工作能按部就班完成呢？ 长久以来，我们一直在接受着这样的教导：项目经理是负责人。他管理团队，指派任务并且承担整个项目成功的责任。所有这些压力和以及所有这些期望都指向同一个人，这个人也负责项目的沟通交流工作。有了这样的场景，我们怎么可能期望项目沟通交流是中立的? 老板如果要求每周多给出一份详细的状态报告，那么这不就是一种不信任吗? 在我十五年来的项目管理职业生涯中，不断看到这种机能失调和不信任。 个人职业生涯有十年是与软件行业有关。熟知软件模型发展历史的人知道，传统软件开发模型是在20世纪60年代形成的，在那个时候统治IT王国的是大型计算机。在那个时代所使用的技术并不欢迎变更。那时候编程的模式是过程化、自上而下的。如果需要变更，就需要重新编译并组装整个程序或系统。为了安全起见，每一次编译的成品都需要新的完全测试。这个模型为其特定的技术服务，人们往往企图像神一样尝试一次性把工作做好。 后来软件行业采纳了新的面向组件的技术，但是底层的开发过程仍旧经常使用相同的传统方法。相比之下，现代软件开发通常使用面向对象的技术。这些面向对象的系统是由更小的高度聚合、松散耦合的分