项目的四种顶层设计.docx

项目的四种顶层设计.docx

《项目的四种顶层设计.docx》由会员分享，可在线阅读，更多相关《项目的四种顶层设计.docx（7页珍藏版）》请在冰豆网上搜索。

项目的四种顶层设计

项目的四种顶层设计

项目是一个系统，项目管理是一种计划、进度和掌握的系统方法，而项目经理则是应用项目管理方法驾驭这个系统的领导。

新出道的项目经理往往保留着原来的工作惯性，即特殊注意技术或业务细节，忽视项目的整体掌握;再或者是虽然意识到了需要“抓大放小”，通过学习项目管理，也明白了“管”与“干”的差别，但找不准项目管理整体掌握的关键。

本文介绍了项目管理四种关键的顶层设计，与您共享项目经理需要抓的“四个大”。

一、愿景设计

项目愿景，也是项目的总体目标，简洁地说，就是项目最终成果特性的定义，也就是项目完成之后应当具备的状态。

描述愿景时通常会说明项目所指向的结果，要达到的战略地位，要实现的目的，要取得的成果，要生产的产品，或预备供应的服务。

项目愿景是削减项目可能性的终极法则。

在项目早期，项目经理最重要的责任是就项目的愿景与干系人达成共识。

在项目诞生之初，项目的干系人对项目的期望可能是五花八门，几乎可以用那句经典的台词来说明这种状况“100个人心目中有100个哈姆雷特”来形容。

就像一个刚刚出生的婴儿，她（他）将来可能有很多种发展的可能，全家人都布满了期盼和期望。

项目早期我们一般是通过了解客户的大的业务需求，来设法搞清晰项目的愿景目标，留意客户在许多状况下自己并没有能力清楚描述项目的愿景和目标，这个需要项目经理通过分析客户的业务需求和项目定位来帮助客户明确项目的愿景目标。

在没有明确愿景目标之前，不要急着去收集所谓的具体需求，否则我们根本无从推断需求的合理性，到头来可能是白做功。

项目的可能性直接打算于项目的需求，我们做项目最憎恨的可能不是技术有难度和工作量大，需求不确定应当是我们恨中之恨。

我们如何推断需求的合理与否呢?

答案就是与干系人明确项目的目标，凡是与目标全都的就是合理的需求，凡是与目标不全都的就是不合理的需求。

例如，你今年最重要的目标是考研，但是家里给你说了一门亲事，对方各方面条件还不错（留意没法让你一夜暴富!

），那么在这种状况要我们做出选择，那结论就很明显了。

我们经常说，人生有目标，步伐就会特殊坚决，这句话对项目同样适用。

需要留意的是随着商业环境的变化，项目的目标有可能发生变化。

当项目进展到中间，发觉客户或领导提出的需求与原来的目标发生了较大的不全都，此时不是接受或拒绝需求，首先应当再次确认目标是否有转变。

项目的目标发生转变也是正常的，在项目管理中所谓机敏适应型开发方法，就是特地应对这种状况的。

但无论如何，当前都必需要有一个清楚的愿景目标。

项目愿景打算了项目的下一步行动。

大家先看下面这副图片，请回答图片中这位女生怎么了?

你的回答可能五花八门，最常见的答案诸如：

“感冒了!

”

“头疼”“没睡好”

“发愁”

“被别人打了!

”

……

我相信只要开动脑筋，大家总是可以想出各种各样的答案。

笔者也不知道这位女孩究竟怎么了?

我的接下来的问题是，假设你是她的朋友，假如你认为她是“感冒了!

”，该如何做?

“吃感冒药”、“多喝热水”。

但你假如认为她是“被人打了”，那么可能就说一起讨伐打人者，假如是年轻力壮的男友的话，甚至可能去替她报仇。

我们现在可以得出结论了，我们定义问题的方式，打算了我们解决问题的方式。

而项目愿景，就是我们的对项目的定义。

项目愿景会打算我们下一步行动的方向，詹姆斯.刘易斯在《项目计划、进度与掌握》一书中做了一个形象的比方，“没有愿景的项目，就是一只无头的小鸡，虽然可能会蹦跶一会，但是项目的开头已经打算了它凄惨的结局。

”

二、方案设计

确定了项目愿景，通过进一步挖掘和分析需求，我们需要给出一个总体的解决方案。

所谓解决方案，有的行业叫做总体或高层级设计，有的叫做架构设计，有的叫做服务方案。

所以解决方案实际就是技术或业务系统的高层次描述，该技术或业务系统的设计高度依靠于项目团队成员的专业学问。

解决方案从总体上描述了，项目的交付成果是什么样子（交付成果可能是服务方案或产品方案），项目通过解决方案满意客户的需求。

解决方案打算了项目的范围、进度和成本

学过项目管理的朋友都知道，项目管理中提到一个项目管理三角制约的概念，即由范围、进度、成本和质量组成的一个三角形，这四个要素相互制约，只有平衡协调的三角制约才是现实可行的项目，否则只有失败一种结局。

而要实现三角形的平衡，解决方案在其中扮演了至关重要的角色。

因为解决方案打算了项目的范围，而范围打算了项目的进度和成本。

需求和范围之间隔着一个解决方案，在解决方案未定的状况下，需求并不能直接打算项目的范围。

例如客户说口渴了，这是需求。

我们可以供应一瓶水，或一杯咖啡或一个西瓜来满意客户口渴的需求，但是客户说这些都不行，我想要来自南极的冰川水，还特殊强调必需是一万年以上的，否则不要。

一瓶水、一杯咖啡，再或者是万年冰川，这些是我们供应客户的解决方案，它直接满意了客户的需求。

但是我们发觉供应不同的解决方案，我们为完成这个解决方案所要开展的工作是完全不同的，这些要开展的工作在项目管理中称作“项目范围”，包括全部的技术和管理工作。

项目范围又打算了项目的进度和成本。

解决方案是项目成员发挥智慧的地方

好的解决方案可以缩短进度，例如有些公司要求在做新项目时，老技术的复用率不得少于80%，这样才能保证项目的工期和成本受控。

而对于技术不确定性高的项目，通常采用迭代增量的方式来做，不断地尝试最佳的解决方案。

解决方案及其相关模块或子系统是团队成员应用专业学问，发挥个人智慧的地方，是工作量投入最多的地方，这些在项目管理中我们统称为技术实现活动。

解决方案为项目管理建立了框架

项目要进入实施阶段前，必需搞清晰有多少工作要做，解决方案规定了项目的技术或业务工作的组成关系和数量，项目经理可以不懂详细的业务或技术，但必需能够从解决方案层级理解整个项目的业务和技术。

否则管理将无从谈起，因为管理要解决的基本问题就是分工和协作，没有解决方案，或者解决方案设计很差，则项目的分工就很难完成;没有一个整体解决方案，就不知道项目成果整合之后应当是个什么样子，那么协作也就无从谈起。

项目管理是为实现解决方案服务的，而不是反过来，那种以管理者的个人意志为导向的项目，肯定是一种操蛋项目。

三、组织设计

组织设计是为了保障项目的资源。

完成方案设计之后，项目需要的资源（种类和数量）基本上有底了，为了确保解决方案能够实现，必需确保能够获得项目所需的资源并有效地管理这些资源。

项目成功=资源x（完美的解决方案+完美的计划），所以没有资源等于一切是空。

确定项目组织结构

项目的组织结构打算了项目经理对项目资源的权力大小，权力大小打算了责任大小，在一个职能型和弱矩阵的组织中，项目经理也就是跑跑腿，传传话，基本上无法直接指挥团队成员，在这种状况下要把职能经理往前顶，不要和他们对着干，否则项目经理可能会死的很惨。

平衡矩阵和强矩阵虽然项目经理有些权力了，但是也不要得意忘形，项目的临时性打算了我们无法和团队成员建立长久的信任关系，这会影响权力的发挥。

项目经理通过合理的计划，大量的沟通来掌握项目，对职能经理要充分的敬重。

项目导向型组织，好像是全部项目经理梦寐以求的组织形式。

“最终可以老子一个人说了算”这是最充分的理由。

虽然少了甩锅扯皮的部门经理，但是项目经理的责任也是最大的，出了问题同样也没有了甩锅扯皮的机会。

在这种组织中，项目经理要提升自身技能，做好向上管理，处理好公司政治，否则也可能成为替罪羊。

建立指挥系统

依据项目的组织结构确定项目权力的安排，接下来就需要设计项目的指挥系统，也就是项目的组织分解结构。

虽然大部分小型项目采用扁平化的结构，但是只要人一多管理学的原理就开头明显的发挥作用，一般一个人直接指挥的人员数量不要超过7个，否则就可能出现指挥失灵的状况。

最古老，最有效的指挥体系就是金字塔，需要依据项目的状况对团队成员进行分类分层管理，确保“利出一孔”，最终实现“力出一孔”。

责任安排

指挥系统有效地将人员组织起来，这种组织确保分工之后人员之间的协作关系是明确的。

最终一步就是完成人员分工，可以通过责任安排矩阵达到责任到人的目的。

四、过程设计

为了完成一个项目，需要两类过程相互协作，即项目实现过程和项目管理过程。

所谓项目实现过程，也称作产品导向过程，是为了将产品“干”出来所完成一系列的业务或技术相关的活动，例如设计开发、产品调试、培训、技术支持、技术服务等。

所谓项目管理过程是为了保障实现项目目标所开展的一系列的管理活动，例如项目启动、项目规划、项目执行、项目监控收尾、项目范围、项目质量、项目进度、项目资源管理、项目沟通管理、项目风险管理等等。

项目管理过程和项目实现过程两种过程是相互重叠、相互作用的。

项目管理过程管理的对象主要就是项目实现过程的活动，例如需要完成哪些设计活动（范围），什么人完成什么工作（资源），什么时间根据什么顺序完成这些开发设计工作（进度），还有就是处理那些不利于完成这些工作的因素（风险）。

当然管理工作本身也应当被合理的计划和执行。

技术实现是项目基础，管理是项目的保证，管理最终是为产品或技术服务的。

分析项目的生命周期，总体把握项目的发展规律

项目生命周期指项目从启动到收尾所经历的一系列阶段，是项目实现过程的最高层级表现，在有的组织称作产品流程，或者一级流程。

项目生命周期是项目发展的一般规律。

假如把人的一生当作一个项目，通常划分成儿童、少年、青年、中年、老年等多个时期，这是人的生命的一般发展规律。

项目犹如人一样有出生（启动）和死亡（收尾），单个人的一生虽然不可重来，但是后来者无非以不同的方式在重复前人的过程，这说明虽然承认独特性，但规律性（周期性）也很明显，项目同样具有这样的特征和规律。

把人生分成多个阶段来谈论往往就简单说得清晰，简单把握，每个时期的任务不一样，例如儿童期只要吃、睡、玩和卖萌就行了，少年期主要任务是求学，青年期完成学业适应社会，中年要负责养家糊口……。

项目在分成多个阶段后，更加清晰地呈现其规律性，也更加简单把控项目的发展，增加项目成功的可能性。

通过划分阶段对工作根据时间进行分类，也简单搞清晰每个时期的主要矛盾是什么。

项目生命周期为项目管理供应了一个基本框架。

不论项目涉及的详细工作是什么，这个基本框架都适用。

例如建筑行业将项目划分成可行性研究、初步设计、具体设计、施工和移交。

软件开发项目分成需求分析、框架设计、具体设计、编程、测试、部署和移交等。

项目生命周期代表了从业者对本行业项目工作开展方式的理解，说明白如何实施项目的方法，也就是所谓项目管理方法论。

项目生命周期是项目管理与特定行业、企业、项目进行结合的有效抓手。

通过这个抓手将项目管理学问落地，项目生命周期为裁剪项目管理过程供应了框架和指南。

建立项目生命周期模型，确保项目成果交付

把项目切分成阶段之后，就需要关注阶段和阶段之间的关系，这些关系可以分为三种基本关系：

顺序关系、交叠关系和迭代关系。

无论是迭代还是交叠实际上都是在顺序的基础上进行的某种适应性调整。

这种不同的调整方式演化出了各种各样的生命周期模型。

典型的生命周期模型有：

预估型生命周期。

在生命周期的早期阶段确定项目范围、时间和成本。

对任何范围的变更都要进行认真管理。

预估型生命周期也称作瀑布型生命周期。

迭代型生命周期。

项目范围通常于项目生命周期的早期确定，但时间及成本估算将随着项目团队对产品理解的不断深入而定期修改。

增量型生命周期。

增量型生命周期是通过在预定的时间区间内渐进增加产品功能的一系列迭代来产出可交付成果。

只有在最终一次迭代之后，可交付成果具有了必要和足够的能力，才能被视为完整的。

适应型生命周期。

适应型生命周期属于机敏型、迭代型或增量型。

具体范围在迭代开头之前才得到定义和批准。

适应型生命周期也称作机敏或变更驱动型生命周期。

混合型生命周期。

混合型生命周期是预估型生命周期和适应型生命周期的组合。

充分了解或有确定需求的项目要素遵循预估型开发生命周期，而仍在发展中的要素遵循适应型开发生命周期。

裁剪项目过程以适应项目特点

因为项目的独特性，在实践中，组织、项目团队应选择恰当的项目管理过程、输入、工具、技术、输出和生命周期阶段以管理项目。

这一选择活动就是项目管理“裁剪”。

留意“裁剪”一词的含义比较丰富，含有削减、增加和调整的意思，不仅仅是削减。

那么问题来了，那么多过程、工具和文件，我怎么知道怎样裁剪才合适?

总的原则是一句正确的废话“实事求是、敏捷机动”。

更进一步是“三个有利于”的原则：

（1）是否有利于提高工作效率;

（2）是否有利于达成正确效果;

（3）是否有利于增加组织的商业价值。

所谓效率是指项目执行的成本效率和时间效率;所谓效果是指项目的可交付成果要满意需求和质量;所谓商业价值，即是否可以增加组织的有形和无形资产。

裁剪前可以用这三个原则进行分析，裁剪后可以用这个三个原则进行检验，发觉偏差持续改进。

【结束语】

项目是一个系统，作为系统管理员，项目经理要细心完成四种顶层设计。

依据《系统论》的结论：

（1）任何一个系统都是有目的性的，愿景设计，就是明确项目的目的和目标;

（2）系统的的结构功能性规律告知我们，任何一个系统都是元素根据一定的结构有机结合在一起的，并对外表现出特定的功能，系统的结构打算了系统的功能;

（3）人也是系统的一个组成部分，在项目这种系统中是最活跃的要素，往往打算着系统最终的归宿（成功或失败），因此需要依据技术系统的需要合理设计人员组织结构，保障项目顺当实施;

（4）系统的演化性和动态特性打算了，我们必需研究特定项目的演化规律，明确发展阶段，这样才能保证项目全生命周期的可控性。

文章来源：

微信公众号简洁项（ID：

EasyPMP），：

陈利海

项目是一个系统，项目管理是一种计划、进度和掌握的系统方法，而项目经理则是应用项目管理方法驾驭这个系统的领导。

新出道的项目经理往往保留着原来的工作惯性，即特殊注意技术或业务细节，忽视项目的整体掌握;再或者是虽然意识到了需要“抓大放小”，通过学习项目管理，也明白了“管”与“干”的差别，但找不准项目管理整体掌握的关键。

本文介绍了项目管理四种关键的顶层设计，与您共享项目经理需要抓的“四个大”。

一、愿景设计

项目愿景，也是项目的总体目标，简洁地说，就是项目最终成果特性的定义，也就是项目完成之后应当具备的状态。

描述愿景时通常会说明项目所指向的结果，要达到的战略地位，要实现的目的，要取得的成果，要生产的产品，或预备供应的服务。

项目愿景是削减项目可能性的终极法则。

在项目早期，项目经理最重要的责任是就项目的愿景与干系人达成共识。

在项目诞生之初，项目的干系人对项目的期望可能是五花八门，几乎可以用那句经典的台词来说明这种状况“100个人心目中有100个哈姆雷特”来形容。

就像一个刚刚出生的婴儿，她（他）将来可能有很多种发展的可能，全家人都布满了期盼和期望。

项目早期我们一般是通过了解客户的大的业务需求，来设法搞清晰项目的愿景目标，留意客户在许多状况下自己并没有能力清楚描述项目的愿景和目标，这个需要项目经理通过分析客户的业务需求和项目定位来帮助客户明确项目的愿景目标。

在没有明确愿景目标之前，不要急着去收集所谓的具体需求，否则我们根本无从推断需求的合理性，到头来可能是白做功。

项目的可能性直接打算于项目的需求，我们做项目最憎恨的可能不是技术有难度和工作量大，需求不确定应当是我们恨中之恨。

我们如何推断需求的合理与否呢?

答案就是与干系人明确项目的目标，凡是与目标全都的就是合理的需求，凡是与目标不全都的就是不合理的需求。

例如，你今年最重要的目标是考研，但是家里给你说了一门亲事，对方各方面条件还不错（留意没法让你一夜暴富!

），那么在这种状况要我们做出选择，那结论就很明显了。

我们经常说，人生有目标，步伐就会特殊坚决，这句话对项目同样适用。

需要留意的是随着商业环境的变化，项目的目标有可能发生变化。

当项目进展到中间，发觉客户或领导提出的需求与原来的目标发生了较大的不全都，此时不是接受或拒绝需求，首先应当再次确认目标是否有转变。

项目的目标发生转变也是正常的，在项目管理中所谓机敏适应型开发方法，就是特地应对这种状况的。

但无论如何，当前都必需要有一个清楚的愿景目标。

项目愿景打算了项目的下一步行动。

大家先看下面这副图片，请回答图片中这位女生怎么了?

你的回答可能五花八门，最常见的答案诸如：

“感冒了!

”

“头疼”“没睡好”

“发愁”

“被别人打了!

”

……

我相信只要开动脑筋，大家总是可以想出各种各样的答案。

笔者也不知道这位女孩究竟怎么了?

我的接下来的问题是，假设你是她的朋友，假如你认为她是“感冒了!

”，该如何做?

“吃感冒药”、“多喝热水”。

但你假如认为她是“被人打了”，那么可能就说一起讨伐打人者，假如是年轻力壮的男友的话，甚至可能去替她报仇。

我们现在可以得出结论了，我们定义问题的方式，打算了我们解决问题的方式。

而项目愿景，就是我们的对项目的定义。

项目愿景会打算我们下一步行动的方向，詹姆斯.刘易斯在《项目计划、进度与掌握》一书中做了一个形象的比方，“没有愿景的项目，就是一只无头的小鸡，虽然可能会蹦跶一会，但是项目的开头已经打算了它凄惨的结局。

”

二、方案设计

确定了项目愿景，通过进一步挖掘和分析需求，我们需要给出一个总体的解决方案。

所谓解决方案，有的行业叫做总体或高层级设计，有的叫做架构设计，有的叫做服务方案。

所以解决方案实际就是技术或业务系统的高层次描述，该技术或业务系统的设计高度依靠于项目团队成员的专业学问。

解决方案从总体上描述了，项目的交付成果是什么样子（交付成果可能是服务方案或产品方案），项目通过解决方案满意客户的需求。

解决方案打算了项目的范围、进度和成本

学过项目管理的朋友都知道，项目管理中提到一个项目管理三角制约的概念，即由范围、进度、成本和质量组成的一个三角形，这四个要素相互制约，只有平衡协调的三角制约才是现实可行的项目，否则只有失败一种结局。

而要实现三角形的平衡，解决方案在其中扮演了至关重要的角色。

因为解决方案打算了项目的范围，而范围打算了项目的进度和成本。

需求和范围之间隔着一个解决方案，在解决方案未定的状况下，需求并不能直接打算项目的范围。

例如客户说口渴了，这是需求。

我们可以供应一瓶水，或一杯咖啡或一个西瓜来满意客户口渴的需求，但是客户说这些都不行，我想要来自南极的冰川水，还特殊强调必需是一万年以上的，否则不要。

一瓶水、一杯咖啡，再或者是万年冰川，这些是我们供应客户的解决方案，它直接满意了客户的需求。

但是我们发觉供应不同的解决方案，我们为完成这个解决方案所要开展的工作是完全不同的，这些要开展的工作在项目管理中称作“项目范围”，包括全部的技术和管理工作。

项目范围又打算了项目的进度和成本。