一线经理日常管理的8个阶段及 38个任务 暂无简介

系统集成项目管理工程师-十大管理 暂无简介

软件行业业务流程全景图 暂无简介

职级能力示意图 暂无简介

工作总结/周报/月报模版 下载地址：隐藏内容，请前往内页查看详情

常规瀑布项目实施管理流程 暂无简介

如何进行目标管理及方法 暂无简介

迭代交付模式—Scrum 敏捷开发流程 在敏捷实践体系中，迭代交付模式是敏捷开发的核心要素。敏捷开发方法有很多，Scrum提供了迭代管理和持续改进的框架，如图1所示。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。Scrum敏捷开发流程步骤图1 Scrum敏捷开发流程Scrum是一个包括了一系列的实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。Scrum的最大特色是灵活和增量交付，要求团队之间有开放的沟通和协作。首先是由产品经理收集和整理需求，然后和开发团队确定开发列表，接着进入开发冲刺状态，后面就是日常开会、后期改善。在实际应用中，我们通常将其分为以下5个步骤。步骤1：创建用户需求列表一个产品的需求可能来自客户、团队或者产品经理的想法，这些需求的描述必须符合：作为，我希望，以完成__。这样的好处是让整个团队更容易理解需求，达成共识，图2 所示为一个实例。图2 用户需求列表（产品功能需求）步骤2：召开计划会议和制定开发计划（计划版）Scrum Master负责组织召开计划会议，产品经理和团队一起根据需求的重要性、开发量来确定开发优先级，做工作量预估，制定迭代开发计划（从需求列表中挑选出高优先级 Story（用户需求）作为本次迭代完成的目标。这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog（迭代代办事项））。开发团队一旦接受这些开发任务，就应该准时完成，不得修改交付标准。步骤3：执行迭代计划（任务板）首先，你需要确定每次Sprint（开发冲刺）的周期，短的周期可以更频繁地发布产品版本，因此可以从客户那里更迅速地收到反馈，修正错误。这个周期一般为1~4周。当然，你可以根据团队成熟程度或迭代任务确定一个合适的迭代周期，比如2周，这样可以让开发人员更投入地工作。所谓Sprint，就是在一定时间内全身心投入开发。这个阶段通常用看板来管理需求，每个卡片就是一个开发任务，工作完成后，可以将卡片移到下一个阶段，用看板管理需求。如图3 所示：你也可以使用专门的软件来管理看板，例如国外的Jira、国内的明道。图3 敏捷开发项目管理看板在冲刺中，每一天都会举行项目状况会议，被称为“每日站会”。会议在固定地点和每天的同一时间举行，对于迟到者团队常常会制定惩罚措施（例如罚款、做俯卧撑、在脖子上挂橡胶鸡玩具）。不论团队规模大小，会议被限制在15分钟。所有出席者都应站立，每个人都必须发言。会议的目标是讨论当前的任务的状态，一个推荐的汇报形式是：我昨天已经做了什么？我接下来准备做什么？现在遇到什么阻碍和问题？注意在会议中团队成员不必要针对每个问题进行探讨，只是作为一个重要信息的反馈通道，具体问题相关成员在会后私下当面沟通解决，这样更加高效，避免浪费问题无关成员的时间。步骤4：产品测试和演示因为每次的Sprint目标就是交付一个可以用的产品特性，所以测试工作非常重要。有不少方法可以减少测试周期，比如，你可以减少需求数量，或者让开发参与测试。当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成。这时，我们要进行演示会议，也称为评审会议。产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum团队的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）。步骤5：回顾会议和下一个Sprint计划每一个冲刺完成后，都会举行一次冲刺回顾会议。回顾会议也称为总结会议，会议的时间限制在4小时，以轮流发言方式进行，每个人都要发言，哪里做得好、哪里不好都可以提出，总结并讨论改进的地方，放入下一轮Sprint计划。Sprint冲刺会议冲刺（Sprint）计划是Scrum中的事件。Sprint计划的目的是定义在Sprint中可以交付什么，以及如何实现该工作。Sprint计划是由整个Scrum团队协作完成的。与体育界不同的是，Scrum鼓励总是全速前进，这样就可以在不断学习和改进的同时交付可用的软件。在Scrum中，Sprint冲刺是完成所有工作的固定时间段，即一个迭代周期。在采取行动之前，必须设置冲刺时间，需要确定时间间隔将是多长时间，冲刺目标以及开始的位置。冲刺计划会议通过设置议程和重点来开始冲刺。如果做得正确，它还将为团队创造动力，提供取得成功的环境。不良的冲刺计划可能会因设定不切实际的期望而使团队脱轨。为了确保冲刺的顺利进行，在冲洗计划中要包含若干会议为冲刺过程提供支持，如图4 所示。图4 冲刺计划包含会议运行一个伟大的Sprint计划事件需要一些纪律。产品负责人必须做好准备，结合之前Sprint评审的经验教训、涉众的反馈以及他们对产品的愿景，从而为Sprint做好准备。为了增加透明度，产品待办事项列表应该是最新的和细化的，以提供清晰的信息。Backlog细分在Scrum中是一个可选的事件，因为有些Backlog不需要它。然而，对于大多数团队来说，最好是在Sprint计划之前让团队一起检查和细化Backlog。输入Sprint计划的一个很好的起点是产品Backlog，因为它提供了一个“东西”的列表，这些“东西”可能是当前Sprint的一部分。团队还应该查看在增量中完成的现有工作，并查看容量。输出Sprint计划会议最重要的结果是团队可以描述Sprint的目标，以及他们将如何开始朝着这个目标工作。这在Sprint Backlog中是可见的。冲刺计划应该限制在每周冲刺不超过两小时。因此，例如，为期两周的Sprint计划会议将不会超过两个小时。这被称为“时间限制”，或者为团队完成一项任务设置最大时间量，在本例中是规划Sprint。Scrum Master（敏捷教练）负责确保会议的时间安排被理解。如果团队在时间框内完成之前感到高兴，那么事件就结束了。时间框是允许的最大时间，没有最小时间限制。在制定冲刺计划的过程中，很容易陷入“困境”，专注于哪个任务应该先做，谁应该做，以及需要多长时间。对于复杂的工作，您在开始时所知道的信息水平可能很低，而且大部分信息都是基于假设的。Scrum是一个经验主义的过程，这意味着你不能预先计划，而是在实践中学习。Sprint计划需要一定程度的评估。团队需要定义在Sprint中可以做什么，不可以做什么：估算工作量和团队能够承受的容量。良好的评估需要一个基于信任的环境，在这个环境中，信息可以自由提供，并且在过程中讨论假设。如果评估中使用负面的，对抗性的方式完成工作,那么很有可能估算的工作量将很大，会造成不必要的资源浪费。我们很容易陷入冲刺计划的细节，忘记冲刺计划的重点是为下一个冲刺建立一个“刚刚好”的计划。这个计划不应该成为团队背后的捣乱者，相反，它应该将团队的注意力集中在有价值的结果上，并为组织提供保护。Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样，Scrum采用了经验方法——承认需求无法完全理解或定义，因此关注如何使得开发团队快速响应不断出现的需求。Bocklog用户故事Sprint目标在高层次上描述了Sprint的目标，但是也可以在编写Backlog用户故事条目时体现。为了切身了解客户的需求，有些产品设计的市场和研发团队尝试运用基于客户情形，透过观察客户、叙说故事、编写剧本、再现客户情境和体验，从而沟通传达客户需求的剧本导引设计法，利用人类内心思考、言词表达的编故事、说故事的基本能力，将设计者及产品开发有关人员带入产品使用时的情境，透过这种情境故事，让设计者将与产品设计有关之信息自我内化吸收，转换对团队沟通。用户故事是从客户的角度描述工作的一种很好的方式，如图5 所示。用户描述将缺陷、问题和改进重新集中于客户所寻求的结果，而不是所观察到的问题。通过向用户故事中添加清晰的、可度量的结果，你可以此评估什么时候能完成。图5 用户故事示例项目里不同的参与者有不同的需求，产品经理想跟踪进度，开发人员想实现，产品经理想功能，产品老大有更高的视角，而用户想要一个可用的系统，在这些充满冲突的视角中，想要做出一个人人都支持、皆大欢喜的决定，并且持续保持平衡是很困难的事情。整个项目组就像一个四驱车，一个角色的强势就相当于一个轮子转得过快，这对产品都是损失，导致车子的方向偏移。我们通过大家一起建立产品全景图的方式，让项目组所有人包括用户站在高空俯视产品，这种同一空间多点对多点的共识就自然地完成了。我们通过这种一目了然、格式一致的故事地图，让项目组所有人都获得足够的信息，让项目有一个明朗的开发流程，如图6 所示。用户故事地图作为一种有效的需求工具，可以做到多角色、多视角。以合作沟通的方式来全面理解用户需求，涉及的主题包括怎么以故事地图的方式来讲用户需求，如何分解和优化需求。如果通过团队协同工作的方式来积极吸取经验教训，从中洞察用户的需求，开发真正有价值的、小而美的产品和服务。图6 用户故事地图示例用户故事地图是一个吸引用户参与设计他们所需产品的便捷手段。我们原型设计阶段的所有内容来源于用户故事地图，因为故事地图是用户全程参与的，所以在我们整个设计过程中都有用户的身影。与参与性设计对立的是经验性设计。在进行新产品设计时，经验性设计高度依赖前期的用户调研，包括用户访谈和用户观察，但是用户不会成为产品设计的真正参与者，后面的阶段基本是靠设计师经验，几乎没有用户身影。但参与性设计“用户故事地图”通过简洁明了、场景还原的方式让用户参与其中，每个用户故事都做到站在用户的角度，使大家快速知道用户想要什么，为什么要这个。用户故事易读、易懂，我们边聊故事的同时进行页面框架绘制，因此能激发用户的积极性，成为产品设计的参与者。同时，随着用户渐渐掌握如何口头表达故事来描绘他们的需求，项目组成员与用户间的关系变得更加亲密主动，这种良性的循环使所有人员都获益良多。思考：以往我们共识用户/产品需求的方式有两种，一种是文档，翻开一看，那些格式化的语言就变成了世界上最好的催眠曲。读尚且如此，写的人会怎么样？写文档的产品经理脑子里一定会回响一个问题：“这东西写了有人认真看么？”有文档看还是好的，还有些产品经理会直接拉上团队成员聊，撰写用户故事地图，就算交接需求了，这两种方式你认为哪种更加敏捷有效？这里的共识是点对点的，或者单点对多点的，信息传递也会带来信息内容的损耗，甚至错误的信息。

七种常见的敏捷开发方法介绍 在创建敏捷宣言时，有不少“轻量级”开发流程；此后出现了其他此类方法。它们现在统称为“敏捷”方法。★敏捷是一种思维方式和行为方式。★敏捷是一种心态，是一套价值观和原则。★敏捷是关于短周期、迭代和增量交付、快速失败、获得反馈、尽早向客户交付业务价值以及人员、协作和交互。★敏捷是一种思考透明度、检查和适应的方式。但是，敏捷不包含任何角色、事件或工件。这是一种心态。如Scrum就是敏捷方法下广泛使用的框架之一。它可以帮助你变得更加一个Agile，但也有更多的框架，敏捷运动，如看板，XP，水晶等如下：01Scrum这是一种非常流行的方法，它借用了足球scrum的名称并将其用作以下隐喻：每日站立会议，Scrum 的迭代很短。每次迭代都专注于交付由 Scrum 团队开发的工作软件，Sprint和产品有严格的优先级“积压”，并且分配了“产品所有者”角色来设置优先级。维护敏捷最佳实践的“ Scrum Master ”。02 极限编程（XP）XP是一套工程实践。开发人员必须超越他们的能力来实施这些实践。团队计划少量工作并在短时间内构建，称为 1-4 周迭代。XP 与其他迭代框架的主要区别在于 XP 侧重于需要达到极端水平的软件工程实践。例如，XP 将代码审查视为极端，并鼓励通过结对编程 100% 的时间进行同行审查。03 精益方法精益起源于 1970 年代的制造业。Mary 和 Tom Popendieck (2003) 在他们的《精益软件开发》一书中将精益原则应用于软件开发。精益专注于为客户提供价值并消除流程中的浪费04 看板看板：一种起源于精益制造的方法，由 David Anderson (2010) 进一步发展。看板基于工作流可视化，通常在物理板上，解决导致问题的问题，限制团队正在进行的工作并平衡对团队的需求。05 快速应用程序开发 (RAD)Rap不仅是一系列敏捷迭代方法的总称，也是 James Martin (1991) 所描述的一种方法。Rad 负责分析、设计、构建和测试阶段，并迭代开发原型和增加功能的版本。06 动态系统开发方法（DSDM）DSDM 是一种敏捷的软件开发方法。它是一种迭代和增量方法，主要基于快速应用程序开发（RAD）方法。然而，RAD 方法通常是非结构化的，并且 rad 团队之间没有共同的流程。因此，每个组织都建立了自己的方法和框架，标准也各不相同，因此很难招募到有经验的 rad 从业人员。为了解决这个问题，DSDM应运而生。该方法提供了一个四阶段的框架，包括：可行性和商业研究功能模型/原型迭代设计和构建迭代执行07 统一流程（UP）Up是一个迭代和增量框架，具有多种实现，包括 RUP、Open-UP 和 Agile-UP。一个高度可定制的框架，具有以架构为中心和以风险为中心的 rad 方法。UP的每个阶段被称为初始阶段、细化阶段、构建阶段和过渡阶段，每个阶段都有不同的侧重点。概括:敏捷开发是软件开发行业的热词之一。这是管理软件开发项目的一种不同方式。它不是特定的软件开发方法，而是基于敏捷宣言中表达的价值观和原则的一组方法和实践的总称。解决方案是通过自组织、跨职能团队之间的协作，使用适合其环境的适当实践来开发的。

风险判定及风险管理 一、风险显露度判定表项目风险管理20/80规律告诉我们，项目所有风险中对项目产生80%威胁的只是其中的20%的风险，因此我们要集中力量去规避这20%的最危险的风险。风险高中低跟显露度的关系（风险的显露度＝可能性 * 后果）二、风险管理策略规避：指改变项目计划，以排除风险或条件，或者保护项目目标，使其不受影响，或对受到威胁的一些目标放松要求。（例如：延长进度或减少范围等）缓解：设法把不利的风险事件的概率或后果降低到一个可接受的临界值。提前采取行动减少风险发生的概率或者减少其对项目所造成的影响，比在风险发生后亡羊补牢进行的补救要有效得多。转移：设法将风险的后果连同应对的责任以正当理由让他方承担；并非将其（风险）拔除。接受：已经决定不打算为处置某项风险而改变项目计划，无法找到任何其他应对良策的情况下，或者为应对风险而采取的对策所需要付出的代价太高（当该风险发生的概率很小时，往往采用“接受”这一措施）该策略可分为主动或被动方式：主动接受风险的方式就是建立应急储备，应对已知或潜在的未知威胁或机会。被动地接受风险则不要求采取任何行动，将其留给项目团队，待风险发生时视情况进行处理。三、风险管理过程目的：通过制订并跟踪风险管理计划对风险进行管理，降低风险对开发造成的冲击，提高开发的成功率。角色与职责：项目经理、资源线主管、研发PL进行全面的风险管理工作（开发人员参与项目风险的分析，评估和跟踪）项目启动时，参考《风险库》把风险登记在《项目周报的风险登记模块中》，并组织关键角色进行风险分析，估算可能性、后果显露度、风险等级等参数，并估计出风险所受影响和应关注的时间。项目经理组织团队成员一起确定每项风险的应对策略和阈值。一旦风险达到或超过阈值，便立即启动风险管理计划，从而减小风险对项目的影响，保证项目顺利进行。对于风险等级为高和中的风险，项目经理必须根据应对策略制定风险管理计划，识别所需任务。项目经理在制订计划时，要把风险管理计划中识别的相关任务加入到计划中。跟踪并监控风险：项目经理定期逐项评价风险及风险应对策略的有效性，并及时更新《项目周报的风险登记模块中》中的风险内容。项目经理及研发PL在跟踪风险过程中，发现新的风险且等级为高或者原来的中、低风险升级为高时，更新《项目周报的风险登记模块中》项目经理在每周发送项目周报时，对报告模块中的风险分析表中风险的跟踪情况进行检查更新，并向相关干系人通报。

弱矩阵、强矩阵、 和平衡矩阵的区别 一、弱矩阵、强矩阵、 和平衡矩阵的区别弱矩阵组织(weak matriⅸorganization)形式是矩阵型组织的一种形式，类似职能式组织形式的一个极端。在这种组织形式里，项目可能只有一个全职人员，即项目经理，项目成员不是直接从职能部门调派过来，而是利用他们在职能部门为项目提供服务。弱矩阵组织结构基本保留项目的职能组织结构的大部分主要特征，弱矩阵组织的应用但在组织系统中为更好地实施项目，建立相应明确的项目管理班子。项目班子由各职能部门属下的职能人员或职能组所组成，这样针对某一项目就有对项目总体负责的项目管理班子。然而，在弱矩阵组织结构中并未明确对项目目标负责的项目经理，即使有项目负责人，他的角色只不过是一个项目协调者或项目监督者，而不是一个管理者。弱矩阵组织保留了职能型组织的许多特点，项目经理的角色更像协调人员而非一个管理者。对于技术简单的项目适合采用弱矩阵型组织。主要是因为：技术简单的项目，各职能部门所承担的工作，其技术界面是明晰的或比较简单，跨部门的协调工作很少或很容易做。平衡矩阵组织(balancedmatrixorganization)平衡矩阵组织也称中矩阵组织：是向各部门借调过来的成员当中，指定一个人担任专案主持人(projectleader)的角色。一旦专案结束，专案主持人的头衔就随之消失。平衡矩阵中对各项目均任命项目经理，并且赋予他应有的职权与责任，项目经理以对部门及该部门中主要工作（或重要）人员的控制为主，由职能经理负责各个职能项目团队中一般人员的管理。平衡矩阵组织是对弱矩阵组织结构的改进，为强化对项目的管理，在项目管理班子内，从职能部门参与本项目活动的成员中任命一名项目经理。项目经理被赋予一定的权力，对项目整体与项目目标负责。强矩阵组织形式是矩阵组织形式的另一个极端。强矩阵组织形式类似于项目式组织形式，它们的区别在于项目部从公司中分离出来作为独立的单元。项目人员可根据需要全职或兼职地为项目服务。强矩阵组织结构具有项目的线性组织结构的主要特征。强矩阵组织结构在系统原有的职能组织结构的基础上，由系统的最高领导任命对项目全权负责的项目经理，项目经理直接向最高领导负责。二、矩阵的应用1、弱矩阵应用弱矩阵组织保留了职能型组织的许多特点，项目经理的角色更像协调人员而非一个管理者。对于技术简单的项目适合采用弱矩阵型组织。为什么呢？因为技术简单的项目，各职能部门所承担的工作，其技术界面是明晰的或比较简单，跨部门的协调工作很少或很容易做。2、平衡型矩阵应用对于有中等技术复杂程度而且周期较长的项目，适合采用平衡型矩阵组织。采用平衡型组织结构，需要精心建立管理程序和配备训练有素的协调人员才能取得好的效果。3、强矩阵应用在强矩阵组织中，具有项目型组织的许多特点：拥有专职的、具有较大权限的项目经理以及专职的项目管理人员。对于技术复杂而且时间相对紧迫的项目，适合采用强矩阵组织。三、矩阵总结可能是最微妙的组织关系了，分为弱矩阵，平衡矩阵，强矩阵。那么这个强、弱、平衡关系是如何界定的呢。就是项目经理与职能经理的权利的强弱关系决定；**项目经理 > 职能经理 = 强矩阵项目经理 = 职能经理 = 平衡矩阵项目经理 < 职能经理 = 弱矩阵权利：项目型>强矩阵>平衡矩阵>弱矩阵>职能型公司资源：职能型>矩阵型>项目型**

工作量及需求的评估管控 一、类比估算法：根据类似的项目工作量进行预估，再对估计值根据具体情况进行调整。二、参数估算法：公司可能缺乏这方面的数据支持，比如通过估计某个项目可能会有的代码行数，配备的成员技能，来进行估计。举个例子，某个项目的代码行估计可能会有10000行，一个一般技能的开发工程师一天可以完成的代码行为500行，那么开发需要的时间可能就是20人日。三、三点估算法：目的是为了尽量降低估算的不确定性。估算时对一个功能点分别估算最悲观的估算值、最乐观的估算值、最可能的估算值，最后确定的估算值=（最悲观的估算值+最乐观的估算值+4*最可能的估算值)/6四、delphi法也称专家调查法，由一组专家对项目进行估算。具体的步骤为：组织者发给每位专家一份软件系统的规格说明合一张记录估算值的表格，请专家估算。专家详细研究软件规格后，对该软件提出最乐观的估算值、最可能的估算值和最悲观的估算值。组织者对专家表格中的答复进行整理，使用三点估算计算每位专家的平均值。综合结束后，再组织专家无记名填表格，比较估算偏差，并查找原因。上述过程重复多次，最终可以获得一个多数专家共识的软件规模。五、团队估算法：类似与Delphi法，但是形式比较松散，参与评估的团队成员包括项目组的各个角色，大家一起对某一个功能点提出自己的估计值，如果比较接近则计算一个平均值作为估算值；如果差别比较大，则由每个人发表意见说明自己的评估理由，然后进行第二轮评估， 直到评估值比较接近。Other1.如何在需求不明确情况下进行工作量的评估？给量级的评估，由于需求不明确，所以估计不可能准确，误差很可能比较大。储备：储备要留足，需求越不明确储备越要多。先总后分：需求不明确也要有一个限度，项目的整体范围，整体框架还是要确定了才能接手项目的。接受计划改变的必然性，既然需求不明确，那么计划的改变可能性是非常大的，需要提前和相关各位沟通到位。2.如何在跨部门情况下进行工作量的评估？各个部门负责给出自己部分的工作量评估。 有专门的接口人负责协调资源，给出评估结果。信任，很多时候我们并不了解对方的工作和流程，所以信任很重要。信任的同时，尽可能多的了解对方的工作内容，积累经验，对未来的判断做准备。3.如何进行进度计划的安排？善用网络图，排好关键路径法和关键链法，时间提前量和滞后量。具体步骤：首先细分项目的每个功能点，针对功能点制定出我们需要进行的工作。 整理每项工作之间的逻辑关系，形成一个网络图。 评估每项工作的工作量。 安排每项工作对应的负责人。根据具体负责人以及工作量调整网络图。 安排储备工作时间。4.排出具体的进度计划需求变更如何处理？事前：丑话当先，变更流程还是要有的。变更流程可以分需求变更的规模，按大、中、小来区别对待，制定不同的流程。事中：执行过程中可能需要灵活应对了，对于需求的优先级和紧迫性需要有一个把握。不是不能变，但对流程还是要坚持的，否则乱了只能是自己。如果发布时间不能改变，需求又是一定要完成的，那我们就只能从其他方面来想办法了。这个可以参考六边形。事后：对人对事进行总结，未来对于类似的事情，相同的人，我们就需要更多的考虑需求变更的风险了。5.对于前期需求不明确的项目如何控制需求范围？前期需求的细节可以不清晰，但是整个项目的大范围需要确定。项目的整体设计最好不要迭代，或者说不要做迭代的打算，一开始就对整体设计做一个统一的规划。整体设计完成后，再对每个部分的功能分别来看。划分每个部分的系分功能点，各个功能点之间的优先级，是否需求已经明确，与其他功能点之间是否有关联等。对已经比较清晰的功能点，并且与其他功能点之间的关联不是非常紧密的，先进行开发、测试。同时细化未清晰的功能点。 对于需求变更的控制重点把控。这需要看项目经理的全局观，是否能对项目的整体设计，功能点间的关联关系有一个比较到位的把握项目成本的构成项目的成本结构从小到大进行逐级汇总，主要包括：活动成本、工作包成本、成本基准、项目总预算、合同总价。什么是应急储备和管理储备？应急储备是为应对项目实施时可能出现的估计误差、遗漏和不确定性而事先建立的储备。一般又分为预算储备和管理储备。其规模取决于项目的“新颖性”、不精确的时间和成本估计、技术问题、范围变动的大小及意料之外的问题。这种储备通常占项目总预算的1~10个百分点。项目经理可动用应急储备，但不能动用管理储备，因为管理储备不在项目成本基准之内，若需要动用管理储备，需要走变更流程进行审批。管理储备一般需要高层管理员进行管理和审批。不管是啥项目，项目在执行过程中都是会存在风险的。风险的分类，可以按照专业、内外、经营关系和已知程度进行分类。按专业分类：技术风险、组织风险、管理风险、财务风险。按内外分类：内部风险、外部风险。按与经营者的关系分类：经营风险、纯风险（自然风险)。按已知程度分类：已知的已知风险、已知的未知风险、已知的未知风险。① 已知已知风险：是已经识别并分析过的风险，不仅知道风险类别，还知道其发生慨率和后果，通常根据其风险敞口计入项目直接成本。参考项目风险库② 已知未知风险：属于已经识别出的风险，但不清楚其发生概率和后果，通常由应急储备来应对。③ 未知风险：又称未知未知风险，是从未遇到过、完全未知的风险，因此也称作突发风险，只有在实际发生后才能识别、分析的风险。未知风险通常无法预防，只能通过提高项目的韧性来减轻发生的后果通常由管理储备来应对。业务人员经常会说，在前期工作量也评估了，合同也签了，最后反而最终算利润的时候不赚钱反而赔钱。问题主要出在以下几个方面。商机阶段的需求一般颗粒度比较粗，研发负责人也仅仅只是进行的需求研发的工作量粗评，常规下有时因为没有叫对应的测试部门，没有把测试阶段的工作量评估出来。不能以商机阶段对接的需求，就所以然的认为这就是客户端最终需求。此时前期如果有意向进行签单，一定要拿到客户端详细需求。（如果客户提不出来，建议由产品经理进行现场需求调研落实清楚客户到底想要的功能）没有在签单之前进行有效的风险评估和技术评估，工作量粗评后，业务人员会拿工作量换算成研发成本，在✖️系数对外报价。本以为是可以hold住，但因为没有预留充分的应急储备和管理储备，又在实际项目执行过程中的各种风险无形中把“利润”消磨掉。有可能还会形成赔本的情况。项目执行过程中，也会因为项目并行执行会造成研发资源和测试资源的过度浪费。未完待续……

项目变更流程 交付类项目变更流程图