|
全文总计10177字，需阅读25分钟，以下为正文： 
甘特图 如果您正在寻找一种可视化任务，并使团队在项目过程中保持正常状态的方法，则应使用甘特图。让我们进一步了解这个功能强大的工具，该工具可以帮助您保持项目的及时性和重点。 甘特图是项目中需要在设定的时间内完成的任务的直观视图。甘特图可用于计划各种规模的项目。它们将始终显示项目的开始和结束日期，甚至还可以帮助您查看在给定的一天中必须完成的工作。 良好的甘特图应能为您的项目提供有效的概述，包括： 1. 您需要完成哪些任务; 2. 任务需要完成的顺序; 3. 每个任务应花费多长时间; 4. 在项目期间完成了多长时间的任务。 甘特图可以通过多种方式创建。幸运的是，Minitab Workspace提供了两种不同类型的甘特图模板，标准的甘特图（如下所示）和任务甘特图，它们是该软件中90多种工具的一部分。
甘特图的制定步骤： 1）确定项目任务： 你应首先明确你的项目目标，然后以此为基础确定需要完成的任务。这些任务可能是大的里程碑，也可能是每个阶段的小步骤。例如，如果你的项目是筹备一个大型活动，那么任务可能包括“确定活动日期”、“确定活动地点”、“邀请嘉宾”、“制定活动日程”等。你可以使用便签、表格或者项目管理软件来记录这些任务。 2）确定任务顺序： 一旦确定了任务列表，你需要确定任务之间的依赖关系。有些任务可能需要等到另一些任务完成后才能开始，有些任务则可以并行进行。在上述活动筹备的例子中，“确定活动地点”需要在“邀请嘉宾”和“制定活动日程”之前完成，而“确定活动日期”则可以与其他任务并行进行。
3）估计每个任务所需的时间： 对于每个任务，尽可能准确地估计完成所需的时间。这可能需要你参考过往经验，或者询问有经验的人。这一步很关键，因为它将直接影响到你的项目时间表。注意，应预留一些缓冲时间以应对可能的延误。 4）创建甘特图： 有了以上的信息，你就可以开始创建甘特图了。在水平轴上表示时间，垂直轴上列出任务。每个任务在图表中对应一条水平线，线的长度和位置表示任务的开始时间、结束时间和持续时间。你可以使用各种工具创建甘特图，包括Microsoft Project、Excel，也有许多在线工具如Asana、Monday.com等。
5）更新和修改甘特图： 甘特图不是一次性完成后就不变的。在项目进行过程中，实际情况可能会有所变动，你需要定期更新甘特图以反映这些变动。如果一个任务比预期提前或延后完成，你需要相应地调整后续任务的时间表。此外，你也应该在甘特图上标记出已完成的任务，这既能使团队成员看到项目进度，又能帮助你跟踪项目状态。
燃尽图 在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。 很多产品在开发过程中通常情况下使用白板来制作，一边是项目进度、一边是人员分工的贴纸，每天上班或下班前会对人员分工贴纸或问题做一个记录和解决。
工作分解结构法WBS 工作分解结构法（即Work Breakdown Structure，简称WBS），跟我们学习的因数分解是一个原理，就是把一个项目按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。即：项目→任务→工作→活动。 WBS是工作的一个总结，而不是工作本身，工作是构成项目的许多活动的总合。 WBS就是一个可以帮你理清头绪，根据目标做好计划的工具。与其选择后期背锅，不如学会用WBS进行前期“拆雷”，尤其是对于这种没有成熟经验的项目，必须遵循WBS工作分解结构法对项目进行“拆解”。
一、WBS工作分解结构的定义 ①Work工作：可以产生有形结果的工作任务； ① 属于范围管理知识领域； ① 确定项目范围：明确和准确说明项目的范围； ① 100%原则：100%覆盖项目的可交付物，每一层分解的子任务也要100%覆盖它的父级任务范畴； ① 按产品的物理结构分解
HOQ质量屋 HOQ质量屋，用于确定顾客需求和相应产品或服务性能之间的关系。用像房屋一样的直观矩阵框架，输入信息，再通过分析评价得到输出信息。
质量屋的构造始于分析顾客需求，写在矩阵的行里。矩阵列中是产品或服务的重量特性。矩阵中心和边缘是这组信息的关系，指导新设计的决定。 作为结果，顾客需求被转化为产品或服务的技术规格，从而使得设计能够最大化顾客的满意度。 质量屋适用场： ● 当要分析顾客需求时； ● 当要将顾客的需求转化为组织可理解的语言时； ● 当需求冲突需要权衡时； ● 当你开始设计新的产品或服务时。 如何实施？ 1）成立一个跨职能小组，小组成员包括： 熟悉顾客的人员以及熟悉产品或服务的人员。 接下来的每步中，小组成员必须首先获得构建质量屋的信息。这些信息可以从与顾客的直接接触中获得，也可以从部门内的调查中得到（例如营销和工程部门），或者依靠小组成员的工作经验。 左墙内容：顾客需求——“什么”( Whats) 2）把顾客需求写在屋的左侧作为行标，尽可能用顾客自己的语言。 3）在行标与中心间加一列来表示重要度。通常用1～10表示，1表示最不重要，10表示极其重要。基于从顾客得到的信息对每个顾客需求赋予数值。 4)质量屋的右侧记录的是顾客对该公司及其竞争对手现有的、具可比性的产品或服务的评价。通常用1～5表示，并且用不同的符号表示自己和竞争对手的产品。 5)（可选项）增加额外的有关顾客需求的信息：顾客投诉、卖点、竞争的目标值、提高因 子和绝对权重。详细情况参阅“注意事项”。 顶楼内容：产品或服务特性——“怎么样”( Hows) 6）在顶楼写上产品或服务的特性作为列标。选择那些可直接影响顾客需求及可度量的特性，并且用组织的技术语言表达。 7）在顶楼再加一行，用符号来表示为了更好满足顾客需求，特性是否需要提高或降低。常用的符号是＋和－或者↑和↓。 8）（可选项）增加更多的有关产品或服务的信息：成本、处理投诉成本及技术难度。 房间内容：相互关系矩阵 9）在屋的房间里，用顾客需求（行）和产品或服务的特性（列）形成的矩阵表示他们之间的关系。用符号表示需求和特性间的关系是正还是负，以及程度的强弱。 屋顶内容：产品或服务特性——Hows的相互关系矩阵 10）在屋顶用矩阵代表产品或服务特性之间的相互关系。用符号表示这种关系是正还是负，以及程度的强弱。 地下室内容：目标度量 11）在地下室用一行表示产品或服务特性的度量单位。 12）还是在地下室，记录有关本公司或竞争对手现有的、具可比性的产品或服务绩效的数据。或者用1～5的相对刻度和不同的符号表示不同的公司，与顾客需求评定一样。 右墙内容：分析及设定目标 13）(可选项)对每个产品或服务的特性确定一个权重。质量屋中间的关系符号赋予一个数值刻度。通常用1，3，5或1，3，9分别表示弱、强、非常强。 从第一列开始，每个关系数值乘上顾客需求的重要度（或者绝对权重，如果用的话），整个列的结果相加，和就是那一列特性的权重。在紧接着的行中，对产品或服务的特性排序，权重得分最高的特性排第一，依此类推。 14）为每个产品或服务的特性确定目标值。结合质量屋的所有信息为新设计决定适当的目标。把目标值记录在地下室的一行中。
RACI图 这个图表最大的作用就是在项目进行的过程中，用于记录不同角色之间的责任，其中R代表负责执行的人，A代表批准的人、C代表可以完成项目的人员、I代表应该被通知的人，通常使用Excel、Visio/亿图来制作。
RACI 包含四方面的内容：
分清谁在项目中做什么是最基本的要求，明确的任务、明确的职责和截止日期，是项目管理的基础。 RACI 图表有助于定义哪些角色是负责人、咨询人和知情人。 随着项目开发复杂性的增加，创建一个清晰的图表，标明谁负责什么。 这有助于防止任何类型的项目失败，如，开发、设计、IT、人力资源或变更管理。 根据百度百科中的解释，RACI表的绘制步骤分为： 1）辨识整个流程、找出各项活动，将它们记录在RACI表的左侧； 2）辨识流程、活动中的所有角色，将它们记录在RACI表的上方； 3）完成RACI表的方格单元：辨识每一个流程、活动的角色（R、A、C、I）； 4）每一个流程最好只有一个“A”角色，这是RACI的一般原则：
5）解决交叠问题； 每个流程只能有一个“A”角色，以便明确流程的具体拥有者和责任。 如果不止一个“A”存在，那么就要对该流程进行再分解，然而再对“A”进行分配。 6）解决缺口问题； 如果某个流程找不到“A”角色，这时对流程或项目负全责的权威人士则应该在现有角色中（或者发现新人选）挑选、任命一人担任“A”。 更新RASCI表，对各个角色及其相关责任进行阐述。
矩阵组织图 矩阵型组织试图把纯职能型组织和产品开发型组织的优点结合起来。这种组织结构形式理论上适用于项目驱动型公司。 下图是一种典型的矩阵型组织结构。各个项目经理直接向副总裁和总经理负责。因为每个项目都象征着一个潜在的利润中心，因而项目经理的职权由总经理直接授予。项目经理对项目的成功负有全部责任。 相对应的是，各部门则有职能上的责任为项目提供最好的技术支持。每个职能单位都由一位部门经理来领导，他的主要职责是确保有一个统一的技术平台，所有的有效信息都能在项目之间进行交流。同时，部门经理还必须让部门员工及时了解业内最新的技术成果。
项目管理实际上是一条“整合”的职能链条，而矩阵式项目管理就是多条项目管理链条并行。 在项目型组织的整合中，工作通常指派给专门人员或“做自己的事”的单位。在矩阵型组织的并行中，信息共享可能是强制性的，而同一份工作可能需要好几个人来协作。在项目型组织里，决策权和指挥权属于项目负责人，而在矩阵型组织里权力属于团体。 矩阵型组织的建立有几个基本的原则：
矩阵法是试图通过让项目管理者和职能管理者共同承担责任而建立的一种协作机制。然而说起来容易做起来难。没有两种工作环境是完全一样的，而且没有两个公司有着一模一样的矩阵设计。 在建立一个成功的矩阵型结构之前必须先解决以下问题：
这些问题的解决取决于项目经理和职能经理之间的相互理解。因为他们在项目中都拥有一定的职权、职责和责任性，因而他们必须不断地协商。然而遗憾的是，项目集经理可能只考虑什么对自己的项目最有利（而不考虑任何其他方面），而部门经理则可能认为自己的部门比任何项目都重要。 为了完成工作，项目经理有时需要一定的组织地位和授权。一位公司的总经理认为，上图所示的组织图应该加以修改，把部门经理的图标放到职能责任箭头的顶端。通过这种方法，项目经理的地位看起来比部门的小伙伴们要高，但事实上他们的地位是平等的。想要实施这一方法的总经理们一定要小心，因为部门经理和项目经理可能并不认为权力是平等的。 在这种环境下，问题的解决通常是间断和分散的。项目经理充当了项目资源和技术控制的总代表。他必须与各方充分交流，确保每个独立的项目达到局部最优。 在许多情况下，如果部门经理可以主动地从项目的整体角度思考问题，他们就有能力让项目经理满意。然而经常是事与愿违。 等级制度森严的单位总有这样一种不可避免的倾向，每个人发现问题并寻求答案时，总是从本身单一的职能范围出发，无法超越这一界限。无论管理人员的能力高低，这种现象都会存在。它产生的原因是权力的下放和职能的分工。 项目环境和职能环境不可分离，二者必须协同作用。项目与职能单位的交界面是一切活动的焦点。 部门经理控制着内部资源（如人员）。这就产生了一个问题，因为尽管项目经理有权（通过部门经理）控制所有资源，包括成本资金和人力资源，但必须由部门经理配置项目所需人员。这样，部门经理和项目经理之间不可避免地就会产生冲突： 矩阵型组织管理帮助我们整合了传统组织结构的优点，这些优点消除了传统型组织结构的缺陷。“矩阵”这个词听起来有点可怕，因为它暗示着组织结构发生了巨大的变化，至少字面上管理人员是这样理解的。 然而事实上，仔细观察一下上图，我们还是能从中发现传统组织结构的影子。矩阵结构只是在传统结构的基础上简单地加了一些水平链条。这些水平链条随项目开始而出现，因项目结束而消失。传统的构架是固定不变的，新增的部分实际上是暂时的。 我们必须注意到，只要高层管理者恰当地制订计划和实施控制，就可以消除所有的缺点。这是唯一能进行这种控制的组织形式。但为了更好地控制局面，公司必须持续设立更多的管理职位，通常会超出实际需要，增加项目上的管理费用。但有一点可以肯定，矩阵结构最终会走向成熟，管理层所需要人数也会越来越少。
PERT（计划评审技术）图 PERT的英文全称为：Program Evaluation and Review Technique，中文的翻译是计划评审技术。 计划评审技术 (PERT)是一种项目管理规划工具，用于计算实际完成项目所需的时间。PERT图 (PERT chart)用于计划项目中的任务，使得更加容易的安排和协调团队成员。计划评审技术将项目中的整个活动分解为单个任务以达到分析的目的。 PERT chart:
它可以帮助项目经理分析项目中的各种任务,并估算所要完成项目中的每个活动下的每个任务所需要的时间。借助这一点，项目经理可以轻松估算或者计算完成整个项目活动所需要的最短时间。 这些信息还有助于对项目做出预算和确定完成项目所需的所有资源类型。 PERT遵循概率论的方法, 也就是说PERT 结合概率论和统计学，从三点估算中推导出平均活动的公式。PERT公式是贝塔分布方程式的一个近似值。 PERT估算公式为：
PERT公式中的参数依次为：O (Optimistic) 最乐观时间。M (Most Likely) 最可能时间。P (Pessimistic) 最悲观时间。 PERT的优点:
思维导图 这个应该就不用详细介绍了吧，在项目初期什么都没有定下来的时候，用思维导图将项目全状进行一个展示，不但方便修改，也能在后期迅速的生成对应的图表，这个应该在互联网等敏捷性开发项目中应用的较多，通常使用Xmin/Mindmanger来制作。
决策树分析图 项目风险应对时，你有没有经常在多个应对方案之间拿不定主意?又或者在多个应对方案中不知道重点在哪? 所谓的决策树分析，是在不确定因素的背景下，对可能出现的风险定量分析，用来作出有利决策的一个工具。通过在若干备选方案中对不同分支事件的产生的发展路径分析发生概率及产生的风险(包括威胁和机会)，计算每条路径净值，根据预期收益选出最优路径。 决策树分析的应用场景非常广泛，不经意中我们就已经用很多次决策树分析。例如买西瓜时我们可以根据纹理、根蒂及触感来挑好瓜;银行在审批贷款时根据借款人的信用情况判断是否能放款;新产品商业论证时面临多条发展方案时根据各方案的预期收益来决策。 PMBOK中关于决策树分析的计算方法的例子很详细。但肯定还有不少人跟我一样，看完那个例子并不知道如何下手决策树分析?来吧，我们探索一下决策树分析。 1、决策树的要素与结构 决策树分析的要素包括决策点(决策的出发点，可以有多个层级的决策点)、方案枝(决策的若干备选方案)、结点(每个方案枝在各种自然状态下的收益结果)、概率枝(每种自然状态对应的发生概率)及结果点组成。 由决策点出发，从左到右根据需要决策的问题、可供选择的各种方案、各种方案的自然状态展现出决策树图。
2、决策树绘制的前提与准备 首先要明确有哪些备选方案：决策树分析要解决的是可选方案太多的“痛苦”，因此要先弄明白“痛苦”有哪些。举个简单例子，某个以新增利润为目标的项目交付过程中，业务方发现了新的商机，发起了一项需求变更，让业务方“痛苦”的可选方案有： 1) 实施变更，但上线计划要推迟一个月，研发费用100万; 2) 当前版本保持现状，下个版本(2个月后)实现新需求方案，研发费用新增80万; 3) 当前版本实施临时方案，效果不能完全实现，下个版本(2个月后)再完成最终方案，研发费用新增120万。 实际情况可能更复杂，某个备选方案自身可能就是一个决策点，这种情况就需要把这个决策点看成一个整体，绘制多阶决策树。 其次要分析各项概率枝及预期收益：这是决策树的关键，直接影响着最终决策的准确性及有效性。 这里有两个重点： 1) 概率枝的考虑要尽可能全面; 2) 各个概率枝发生的概率和预期收益要尽可能准确，可以借助结合数据、趋势、环境及专家评估等工具手段。 继续前面变更的例子，三项变更实施方案，最主要的差异在于新商机方案投产时间对于收益等影响，通过对类似方案的运营情况及历史数据分析，方案3采用了临时方案的折中方案，可能会出现一定概率1200万的利润情况，方案1和2受投产时间影响，只可能会出现1000万和1500万利润情况。 于是，通过上面两步走，决策树分析树基本可完成绘制：
3、决策分析的结果与应对 根据上面绘制的决策树分析图，计算出预期收益和期望值，方案1的预期收益最高，自然就是最佳决策方案。 决策方案的确定并不意味着风险已经解决，只是在当前不确定因素前提下综合发生概率集影响作出的最佳决策，而针对其中的不确定因素还需进一步进行风险识别并记录到风险等级册，制定有效风险应对措施，增加正面预期收益的发生概率，降低负面收益的发生概率。
决策树分析还可以作为一种预测性分析的方法，通过分析当前和历史数据对未来的事件做出预测，提前“预演”未来事件，并根据发生概率有针对性地进行有效风险应对。 进行预测性分析的关键点有两个： 1)、对于决策结点进行有效分类， 2)、决策结点的发生概率分析。 决策结点的分类，通常需要遵循以下原则： 1)、结点包含的样本具有相同的属性; 2)、结点中的样本属性无法再细分; 3)、当前结点的已经是最终结点，无法继续划分; 再来个例子：项目组识别到某个需求依赖外部合作方配合排期的风险，经项目组分析，对可能的结点进行归纳，绘制出下面的决策树：
从上面的划分可以看出，不管是由谁去要求业务方去协调排期，都是同样的属性，都可以归类成同一类;风险解决的结点也不难理解，达到了我们风险应对的效果，无需再划分;上升到决策委员会则是风险解决的最终策略，无法再进一步划分。 4、决策结点发生概率分析 根据每个决策事件，进一步分析其发生概率，计算每个决策结果发生的最终概率，那我们就可以把更多的精力放到高概率决策结果的应对中去。根据上面每个决策结点的概率，易知最终调整我侧排期并跟相关方达成一致的概率最高，那我们就应将风险应对重点在这之前过程。
项目风险管理的核心是采取有效的风险应对措施，决策树分析法通过理性的数据分析为风险应对提供有效的决策依据，如果你经常拿犹豫不决，如果你经常不知道风险应对的重点在哪，试试上面的决策树分析法吧。
项目状态报告 项目的实施，实际上，就是通过阶段性的推进，产出一个个的交付物，最终实现项目的目标，也就是我们常说的“过程管得住、执行看得见、成果留得下”。 那，过程怎么管控呢？其中，很重要的一个机制，就是定期地、主动地向公司汇报项目的实施状态，通常是每周/每月/每季度/每个阶段节点，向公司领导、PMO汇报当前项目的进展情况。 既然是汇报，就要站在公司领导的角度上，分析领导想知道的信息： 项目进展是否顺利？项目到哪个阶段了？预算使用情况如何？下一步的工作计划是什么？之前的问题是否跟进了等等。末枝细节的内容，就免了，领导也不会关心。 因此，就有了《项目状态报告》，一个周期性、阶段性的总结报告，总结当前的工作进展、制定未来的工作计划。 通过《项目状态报告》这张工具表，定期（每周/月）向领导/PMO汇报项目的进展情况： ①当前周期项目总结：项目是否顺利？进度是否正常？ ②当前周期的工作回顾：当前这个周期都有哪些任务，是否都完成了？ ③未来工作计划：项目组下一步的工作计划是什么，要做哪些事？ ④预算与实际对比情况：截至当前，成本/费用/人力是否符合预期？ ⑤上一周期问题是否跟进：上一阶段遗留的问题是否解决了？ ⑥有何新风险：新识别了什么风险？出现了什么新问题？ ⑦是否需要帮助：是否需要公司的支持？ 如下示例：
《项目状态报告》包含了：项目基本情况、当前任务状态、本周期内主要活动、下一周期内的活动计划、财务状况、上期遗留问题、本期发现的风险和问题、需要的支持。 ①项目基本情况：含，项目名称、项目编号、制作人、审核人、项目经理、制作日期、当前项目状况、汇报周期几项内容； 你可能也发现了，除了项目的基本信息，此表，还新增了“当前项目状况和汇报周期”两项内容； 是的，由于是向上汇报，所以，在工具表的开头部分，新增了对项目当前状况的总结和汇报周期，直接告诉领导项目的整体情况，项目是按照计划进行呢，还是提前了，或者是落后了？项目是，每周汇报呢，还是每月汇报？领导一看，就能知道，项目是否顺利进行。 ②当前任务状态：描述下这个周期的关键任务、任务的状态、并对状态做一个简单描述，尤其是对状态异常的任务。这里的任务，要与《WBS表》相对应，也是对项目当前进展是否顺利的一个论证。 ③本周期内主要活动：对本周期的具体工作做一个总结回顾，描述这个周期内，项目组都做了什么事情、产出了哪些交付物。实际上，就是细分关键任务，描述具体的工作。 ④下一个周期内的活动计划：根据当前项目的实际情况，并对照《WBS表》和《进度计划表》，制定下一个周期的工作计划。 ⑤财务状况：截至当前周期，统计项目已产生的成本/费用/人力情况，并与项目的预算进行对比分析，建议使用图表形式展示。 ⑥上期遗留问题的处理：跟进上一个周期的遗留问题，本周期是否都解决了，怎么解决的，如果未解决，则说明原因，并填写到下一个周期的遗留问题上，待处理。 ⑦本期发现的风险和问题：发现了什么样的新问题或新风险，并简要描述解决方案。需要注意的是，新发现的风险项/问题，要同步至《项目风险管理表》中。 ⑧需要的支持：是否需要公司的支持，如果需要，则需要什么样的资源。如果需要，项目经理，就可以利用汇报的机会，向公司争取更多的资源。
在使用《项目状态报告》时，要注意如下要点： 要点①、报告每个周期制作一份，并且存档：报告也是项目质量管理的重要交付物，它记录了项目管理的过程，将是质量度量和复盘的重要依据，因此，保存这些过程文档，非常重要； 要点②、报告要有连贯性：每个周期的报告都是相互关联的，比如，这期的计划，就是下期的工作内容；这期的遗留问题，在下期需要跟进；每期报告的项目状态是持续渐进的，这一期期的报告，也就构成了项目的实施过程； 要点③、《状态报告》、《WBS表》、《进度计划表》相互验证：WBS是工作结构分解，进度计划是整体工作计划，而状态报告则阶段性总结了计划的实施情况。正常的计划实施，应该是按照进度计划持续推进的，如果，某阶段出现了严重的无法调整的偏差，则，应考虑变更进度计划； 要点④、《报告》的编写需要项目组内先达成共识：《报告》一般由项目经理填写，但，需要项目组内先达成共识，再向上汇报。 《项目状态报告》，不仅，解决了项目经理向上沟通的问题，还通过这一期期的阶段性总结，记录了项目的完整实施过程，为项目的复盘和公司财富的沉淀，提供了原始依据。这是，过程管理的重要管理工具。 文章来源：网络（如侵联删） |
|
|
来自： 昵称53000553 > 《待分类》
