项目的本质

项目的本质

我们把重复的工作叫运营，非重复的工作叫项目，只要你从事项目工作，改来改去的事儿就已经注定了。

项目，也就是要明白客户想要什么，如果客户不知道自己想要什么的话吗，就要帮客户弄明白他们想要什么。

客户会用他们的认知表示出他们未知的事情，所以客户会多次提出要求来得到渐渐磨合到他们想要的样子。

我们可以要求用户不断的提出需求，听过不断的提问得到客户的业务痛点，围绕使用的环境，业务背景进行提问，项目是业务不是技术。

项目的三大特性

专业的定义是为创造独特的产品、服务或成果而进行的临时性工作成为项目。
项目在本质上是独特的、临时的和非重复性的工作，要求使用有限的资源，在有限的时间内，所以特定的人完成特定的目标而开展工作。

1. 明确了项目的结果是产品、服务或成果，对于这个结果强调其独特性；
2. 为了获得所需要的结果，需要开展相关工作，对于这些工作强调其临时性。独特性说明所创造的结果就跟以前或多或少不同的地方，即结果的不重复性，同样为创造独特性结果而开展的项目工作，这个过程不仅是临时的，而且也具有不重复性这种不重复性会给人们认识项目带来复杂性和不确定性，这就是项目风险的来源。

在这里，独特性、临时性和渐进明晰性是项目的最明显的三大特征，其中独特性和临时性是最基本的特征，其他特性都是在这个基础上延伸出来的。
关于独特性，我们解释几点：

1. 独特性意味着项目的不重复性，每个项目创造的结果都是独特的，当前的项目与以前的项目或多或少存在不一样的地方。即便是存在一些相似或重复的部分，但并不改变项目工作的独特性本质。
   如果是创造性很高的项目，将完全没有可以参考的经验，这就意味着有新的知识有待于认识，当然这必然会犯错误，因此这种项目必须是要循序渐进的。
2. 独特性是相对的，一个项目与以前的项目相比，或多或少存在某些相似性，如研发一款新手机，肯定与之前的手机就一定有很多部分是继承性的，并不需要把每个部分都重新开发一遍，如果各个项目完全是独特的，就不可能存在大多数时候适用于大多数项目的知识
3. 独特性提升了竞争力，但也增加了挑战性
   正是因为项目的独特性，才让项目的结果具备了某种竞争力，否则只需要重复生产以前开发的产品就够了。当然独特性也提升了项目工作的挑战性，项目工作的一个重要方面就是化解复杂性，使之更明确、更可控。

宏观到微观，微观到宏观

在企业中，我们通常将企业的日常管理工作分为三大类型，战略规划类、日常运营类和项目工作类。

所以战略更多地强调是对于长期目标定位的准确性，以及怎样实现这个目标的这个过程。
战略至少包含两个方面:
一是现状，即我们现在在哪儿打仗吧，我们得知道我们自己在哪儿、处于什么状态。
二是愿景，就是我们去哪儿。
从现状走到愿景的规划路径，就是所谓的战略规划。

运营实现企业的持续稳定，项目实现企业的持续发展

随着环境的改变，用新的流程代替旧的，这就是一个新的迭代

在项目管理中，战略管理在前，项目管理在后。
一句话，项目管理只负责解决在正确选择项目以后的实施问题。

项目里问题的解决方案

以后遇到问题一定要试着从三个方面来解决问题，也就是问题的所在环境、问题本身以及问题解决的主体，这三个维度就可以理解为一个分析问题的一个空间结构，不但把问题想全面了，而且还分得很清楚。

如果从这三个方面分析，会发现很容易找到多种解决问题的方案。

但我的建议是遇到问题以后，首先把所有的解决方案列出来。
然后再分析每一个方案的优缺点进行排序，最后再选择代价最小的方案去实施。

所以在遇到问题的时候我们要从多个角度进行思考，在不同种类的解决方案中找到最契合的解决方案，然后再加以解决应用。

项目的生命周期

项目是具有生命周期的，在这里，项目周期可以让我们更好的管理项目，在项目管理中，我们将这种阶段化管理、控制叫做项目生命周期管理。

在项目周期中，我们可以把每一个阶段化的任务叫做一个里程碑，每一个阶段处理一个或者多个重难点

在项目周期中，我们要做到如下内容：
第一、确定在各个阶段需要完成哪些工作；
第二、明确各个阶段的可交付成果何时产生，如何对他们进行验证和确认；
第三、确定各个阶段需要哪些人员参加；
第四、确定如何控制和验收各个阶段。

项目中有两种不同类型的生命周期：瀑布型、敏捷型。不同的生命周期有不同的风险处理方式，也适用于不同的项目。

瀑布型生命周期适用于以下情况：

一、充分了解要交付的产品；
二、要有坚实的行业实践基础；
三、整批一次性交付产品有利于每个人敏捷型。
生命周期是通过一系列重复的循环活动来完成项目。通常又有两种实现方式，一种是迭代，另一种是增量。迭代的本质是有模糊、逐渐变清晰的过程，增量方法是通过渐进、增加功能的方式来实现项目。需要特别说明的是，通常把迭代和增量统称为敏捷，除非个别专业人士一般不做区分。

敏捷型生命周期适用于以下情况：
一、需要应对快速变化的环境；
二、需求和范围难以事先确定；
三、能够通过较小的增量逐步实现产品敏捷越来越成为一种趋势，以应对快速变化的环境。
不同的生命周期有不同的风险处理方式，声音不同的项目

不同的生命周期有不同的风险处理方式，也适用于不同的项目

项目在甲乙两方上的区别

第一、站在甲方角度，项目过程就是逐渐移交主动权给乙方的过程。站在乙方角度，项目过程就是逐渐绑架客户上咱们贼船的过程。
第二、一个正规的程序可以保证项目稳定运行在正确的轨道上。不管采用哪一种生命周期模型，程序和文档都是必不可少的。警惕、敏捷成为少写甚至不写项目文档

客户的需求

项目是基于业务导向的,客户提的很多是自己期望解决的需求。而对于最基本的需求往往是不说的。所以一定要详细调研用户的背景，项目的使用环境，然后深入了解他们的业务过程，这样才能得到用户的真实需求。

投射效应的存在大大增加了获取项目需求的难度，为项目实施制造了很多的障碍。对项目管理是一个严峻的挑战。项目经理们一定要谨防投射摄影带来的负面影响。不要用自己的认知和喜好来定义项目的需求和目标。
国内的项目经理呢一般都有较好的技术背景。技术视角往往会成为某种局限，而且技术背景越深厚，越容易把自己的想法和思路强加给别人。因为他们对自己的经验，自己的能力很自信。关键是很多项目干系人的问题，他并不是技术层面的。一定不要试图仅从技术层面来讨论问题。

项目的目的，目标，手段

要将项目做正确，分清项目的目的和手段是十分重要的。分清项目的目的和手段是成功管理项目的前提

项目的管理思路：
一、要明确项目要什么，也就是目标。
二、确定要完成什么，也就是要采用什么手段。
三、制定需要做什么和怎么做的步骤？也就是实现目标的计划。
四、构建考核的指标，包括进度、成本、质量等等。组织好人员在过程中通过绩效考核来确保完成。

项目思考框架：
一、确定工作内容，也就是需求。
二、确定何时完成这些工作，也就是时间。
三、确定要花多大的代价来完成，也就是成本。
四、确定这些工作做到什么程度可以接受，也就是质量。
五、弄清楚使用哪些资源来完成工作，也就是资源管理。
六、如果没有足够的资源，哪些工作需要外包，也就是采购。
七、如何做好干系人之间的沟通协调？
八、哪些工作确定不了，也就是风险。
九、如何搞好各干系人之间的关系？
十、如何实现上述九个目标的最优？也就是整合。

项目目标还必须满足smart法则。
smart是五个英文单词的缩写，也就是specific,明确；measurable,可量化；attainable,可达成的；relevant,有相关性；time bounced,有明确时间期限的

想要的与需要的

区分需要的和想要的，这里有一个最佳实践，就是客户愿意付钱的就是真正需要的，否则就不是真正需要的。

在需求确认这件事上，你需要强势一点。你要用各种可能的办法逼迫干系人把需求考虑清楚，这个干系人不管他是客户还是老板，不要被他们的强势吓到了。我要提醒你，只要你是为了把项目做好，一般情况下，他们是会理解的。你需要突破的是心理这一关。总之，不管用什么办法，在项目开始之前，主要的干系人必须对项目的目标和需求达成一致。当然一定要注意一个原则，那就是对事要硬，对人要软。

我要特别提醒你，在需求分析和设计阶段，当整理完需求文档和设计文档以后，一定要请客户一起参与评估，以避免需求理解的不一致，导致工作范围不确定的问题。总之，要让客户对需求进行确认，尽量让客户签字认可。如果不能拿到签字，你要尽最大可能，让客户方的领导在正式场合当面确认。

这样做的好处有四个。
一、可以有效的控制需求。当客户再想增加需求时，总不至于那么理直气壮了。
二、如果客户真的要增加需求，你也可以因此而提出一些经济补偿。
三、如果需求变更，毕竟客户以前是认可的。现在再增加需求，那就不是我的能力范围了。这个时候你还可以请领导出面来解决问题。
四、有了客户确认的需求，项目组就可以放心的去完成项目了。这样也给了团队一个信心。

我们在和客户谈条件的时候要把被动变成主动！！！

项目的本质是面向人

要获得项目的成功，关键是获取干系人的期望和影响力。

问题是很多项目上的问题本身不是技术层面的，一定不要试图仅从技术层面讨论问题。我必须提醒你，项目是基于业务导向的，项目管理者也是业务层面的管理者，这是一个重要的项目化思维。

权利-利益方格：
对于权力大、利益高的干系人，要重点管理，尽可能使其成为项目的支持者，促进项目的成功。
对于权力大、利益低的干系人，要小心处理，尽量让他满意，因为他们是具有影响力的人，应该注重他们的地位，一定不要使他们成为项目的反对者
对于权力小利益大的干系人，遇到问题要随时告知，因为他们一般对项目非常感兴趣，能够提供有用的信息。
对于权力小利益小的干系人，要花费尽可能少的时间，我们应该充分利用自己的时间。

要学会分析形势，尝试站在对方的角度考虑问题，注意区分需要的，还是想要的。

在项目中与干系人打交道时，特别是与客户打交道时，必须要知道怎么对付小人物。上面的领导好说话，到下面就很难说了。小人物有两个身份，一个身份是小人，说明他职位比较低；一个身份是人物，说明他具备了某些执行的权力。你如果不把他们当回事儿，让他感觉你不尊敬他，他们就用小人的方式对你。如果你把他们当人物哄哄他，他们就会用人物的方式对你了。你一定要记住，不要小看那些职位不高，但貌似有点权力的人，这是一种典型的中国特色的干系人管理。所以说，除了要懂技术和管理以外，在中国做项目，你还要理解中国特色的文化。

项目的管理本质

项目管理本质上是一种基于战略方向的组织开拓创新的学问，其目的在于组织来源于各方的资源，在短时间内形成合力实现突破，显然选择合适的项目管理者是至关重要的。我常说把事儿做成，关键是干部。绝大部分组织都是由职能部门组成的，这可能会导致独立王国思维。也就是说，人们倾向于先考虑单个部门的要求、利益和目标。而不是优先考虑组织的整体利益。这种态度往往是有害的。因为对某个部门自由的方案未必对一个组织，一个项目或者对客户是最好的。

从人性角度，每个人都生活在自己的世界里，每个人都有自己更关心的事情。市场人员更多从市场分类和市场趋势的角度看问题，而工程师更可能从实用性和功能规格视角出发。换一句话说，本位思考是人类思维的天性，这就是人们常说的部门墙。

部门墙的存在导致在项目上一个常见的情况：计划部门强调进度要快，财务部门要求省钱。质量部门挥舞质量第一的大棒，市场部门高举客户至上的大旗。组织的考核体系很容易加深这种矛盾。因为各个部门都有自己的业绩指标。最后导致一个尴尬的结果。一考核每个部门的指标都完成了，但是项目搞死了。

在绝大多数国内企业里面，项目的团队成员都来自于职能部门，他们有自己的部门经理，而且工资奖金都是由部门经理来决定的。而项目经理是既不给别人发钱，也决定不了人家升迁，需要对项目负责，基本上是在有责无权的条件下实施项目的。这种有责无权的状况，使得项目经理们极为郁闷，可以说项目经理这个职位简直就是神一样的职位。

方面职能分工导致了屁股决定脑袋式的片段思考，经常伤害项目的整体绩效，而另一方面，项目管理者有无权的现实进一步增加了项目实施的难度。

和乙方负责人的计划审核

计划一旦制定出来，就应该送交相关人员签字确认。相关人员一旦签字，就表示他承诺他的贡献，同意完成的工作范围，接受其中的技术规范。但是签字并不等于保证，因为没有人拥有百分之百的预见能力，或者完全控制他们的时间，但是签字就是一种承诺。所以我们说，签字就意味着牵制。客户签字表示他同意项目的功能，职能经理签字表示他同意按照约定为项目提供资源。在项目计划审查会议上来签署计划，比通过邮件的方式来签署，效果要好很多。

最后，关于项目的计划有以下几点：
第一，计划是用来改的，正是因为计划没有变化快，才更需要做计划。
第二，领导不应该直接管人管事，而应该管计划。
第三，项目不应该被领导管，而应该被计划管着。
第四，员工不应该按照领导的指示做事，而应该按照计划的安排来做事。

WBS(工作分解结构)

1.WBS是实现项目工作显性化、解构化、形象化的重要工具

任何复杂工作的完成，从认识、管理和控制的角度而言，总是从技术和专业角度将其分解成较小的，更易于管理的组成部分，这就是复杂事物的实现逻辑。

创建WBS就是把项目的交付成果和项目工作分解成较小的、更易于管理的组成部分的这个过程。一方面，WBS可以把常用魔鬼的隐性工作显性化；另一方面，当工作用结构化的图形方式展示出来的时候，可以帮助人们建立对项目的整体认知，特别是对那些对项目了解不够的人。同时WBS可以界定项目的范围，揭示项目的细节，从而有助于安排项目的进度，制定预算和进行有效的沟通。

2.创建WBS就是对项目进行显性化、结构化、标准化

在同一个企业中，尽管所有的项目各不相同，但有许多项目在较高层次上是相似的，如果这些企业能够花点精力去编制涵盖这些同类型项目的标准WBS,这样的WBS就形成了企业的一种无形资产。根据项目的实际情况，对标准的WBS进行裁剪，就成了该类项目可以使用的WBS。在项目分解完成以后，为了使项目组成员更准确地理解项目所包含的各项工作的具体内容和要求，应该编制相应的详细工作说明文件。不仅如此，这些详细的工作说明文件也同样是组织开展后续类似项目工作的重要参考。

WBS及其详细的工作说明文件是组织的最重要的无形资产，新加入项目组的成员能够根据这些资料迅速上手。这种方式虽然一次工作量较大，但一旦形成以后，你就能够迅速界定项目的工作范围，进行可靠的进度安排和成本预算。这不仅提高了进度，也提高了项目的可靠性，降低了项目的风险。要提高项目的执行效率，必须提高项目的构建化程度，也就是标准化程度。创建WBS的过程就是对项目进行显化、结构化、标准化的过程。只有这样，才能够提高项目过程的可复制性。项目的标准化是组织提高项目管理能力的必由之路。

WBS好坏判定标准

第一个原则是百分之百原则。WBS涵盖了项目中的百分之百的工作，不能多也不能少，既不重复也无遗漏，而且每一个层级都符合这个原则。
第二个原则是信息透明原则。WBS最底层工作包，应该分解到信息透明的层次。所谓的信息透明指的是，可以估算工作包的工作量，以及完成工作包所需的时间、成本和验收标准。
第三个原则是八十小时原则。一般情况下，单个工作包应该在八十小时之内搞定，也就是说十个工作日。实践证明，超过两周工作会失控，这也是敏捷开发要求两周一个迭代的原因。如果一个工作超过两周的话，就应该再次分解。
第四个原则是独立责任原则。单个工作包应该可以分配给一个责任人，以避免推诿扯皮。
第五个原则是滚动式规划原则。当前的工作要详细分解，要在未来远期才完成的交付成果，当前可能无法分解，通常要等这些交付成果信息足够明确以后再来详细分解。
第六个原则是不同层次原则。不同的交付成果可以分解到不同的层次，某些交付成果只需要分解一层，而另外一些则需要分解到更多层。工作分解的越细，对工作的规划管理和控制就越有利。但是分解越细，也就意味着成本越高，过细的分解会造成不必要的浪费和效率低下。
第七个原则是一个上级原则。每个下一级组件有且只有一个上级。

WBS时间安排

我们要把类比估算和参数估算联合使用。
前期使用类比先启动项目。等到执行阶段再使用参数估算，让安排更准确。
事实上还有第三种估算，也就是基于风险的三点估算，这种方法考虑的最可能情况、最乐观情况和最悲观情况。
是基于风险的判断，往往也更有效。

项目计划图

现实中，项目进度计划一般可以采用三种形式来表达，也就是网络图、甘特图和里程碑图。
网络图比较详细，对于没有学习过关键路径法的人来说，这显然是比较复杂的，所以这种图适合项目经理和项目团队自己使用。
甘特图也称横道图，用横道表示活动，并标明活动的开始与结束日期，显示出活动的持续时间。甘特图相对比较易读，也比较直观，最常用于向管理层汇报项目的情况。
里程碑图与甘特图类似，但仅标出最主要最关键的工作节点，这个最适合向对项目情况不够了解的高层，或者是客户的领导汇报工作使用。

项目成本管理的核心在于花了多少钱对应着完成了多少工作量。

第一、将预算以实际完成工作量做比较，表达了项目的进度状况；而将实际成本与实际完成工作量作比较，表达了项目的成本花费状况。项目成本管理的核心在于花了多少钱对应着完成了多少工作量。
第二、很多公司的财务人员仅仅关注进多少钱、出多少钱，与工作进展并不关联，存在着严重的表外风险
第三、国内的项目参与者。大多不直接参与项目的成本管理，甚至连项目经理自己也常常不是项目成本管理的主体，不让具体做事的责任人管理成本，这是一个非常遗憾的事。