项目管理的十个步骤解析.docx
《项目管理的十个步骤解析.docx》由会员分享，可在线阅读，更多相关《项目管理的十个步骤解析.docx（22页珍藏版）》请在冰豆网上搜索。
项目管理的十个步骤解析
项目管理的十个步骤解析
管理风险和问题是成功的项目管理的基础。
本章能够帮助您了解如何让您的项目团队识别风险和问题，分析它们，开发应对表以及实施这些应对表。
杰出的项目团队与一般的团队之间的区别在于：
一般的团队只为成功做计划，而杰出的团队却认识到了影响绩效的许多威胁。
近年来，项目管理领域越来越关注失败项目的影响，并将它引入项目风险管理的必备程序和工具。
如果您在项目的计划和实施过程中引入了风险和问题管理，那么项目成功的概率也大大增加了。
介绍这个重要的命题前，我们首先介绍风险和问题的定义。
一个风险事件指二个不连续发生的事件，被认为是导致某事物发生的原因以及相应的结果。
风险事件的发生是有概率的。
一个通常用于识别风险的标准是“可能发生，可能不发生。
”如果该风险事件发生了，就会导致风险结果。
所有这三个因素（风险、事件、结果）是界定一个风险不可或缺的。
相对于风险的离散、不确定性，问题却是确定的。
因此，与风险的估计和管理也有所不同。
如果某个事件百分之百发生，就肯定不是风险，而是必然的事情。
因此，如果您能确定它会发生，或它已经发生，这就是问题。
您还应该解决该问题对后续活动可能造成的影响。
举个关于风险的案例：
某一天的清晨，天气多云。
您查看了天气预报，说今天雷阵雨的概率是50％。
您将“雷阵雨”定义为事件，并估计了发生的概率以及相应的可能结果。
谨慎起见，您决定在您的日程计划中加人应急储备。
您带上了雨伞，以防风险事件的发生。
再看一个问题的案例。
假设您现在看到窗外的雨下得很大。
降雨不再是一个风险，而是一个您必须管理的确定事件。
因为是一个确定的时间，要求您接受现实并以积极地态度解决问题。
作为一个理智、谨慎的人，您不应该傻傻的认为没有下雨的可能性，或认为您能变成超人阻止下雨。
所以，带好您的雨衣，即时打开您的雨伞！
以团队为基础的项目管理的十个步骤
所有好的项目团队是用合作的方式进行风险识别、分析以及应对的。
打个比方说，这些项目都有‘‘雷达’’对即将出现的威胁进行监控。
该雷达能够使得项目团队预期威胁，把威胁因素进行优先次序排序，并采用合适的措施有效地回避或减轻风险事件。
能够预期项目风险并采取有效措施的团队很有可能获得成功。
步骤一：
准备
在召集团队成员参加风险管理会议之前实施这一步骤。
好的绩效取决于交叉职能部门的贡献。
因此，有必要用系统、整体的方式进行风险识别，而不是项目经理运用一对一的模式召开个人会议。
在任何一个团队召开会议之前要做大量的准备。
下面介绍四项工作。
．查阅基本问题。
您是否亲自参与过项目?
（许多项目没有以项目图的形式经过管理授权就启动了，也没有获得对于工作的要求。
）您是否有获得合适人员的途径?
（很多人并不参与早期的项目计划，因为他们的经验告诉他们任务有可能变更。
因此，他们并不愿意参与那些不能产生产品设计或导致产品启动的过程。
）您是否邀请了关键的供应商?
（根据我们的经验，我们最大的困难在于我们没有过早地邀请供应商参与L您是否有交叉部门的代表（常犯的一个错误是推迟了“下游职能部门的参与，如采购、测试、销售以及生产）。
有关产品的建议书价值如何?
（最快产生的拥护的概念对现有客户没有任何意义。
如果您正在进行一项根本性变革，或试图进入一个市场，那么您最好能让别人明白您的目标）。
成功如何定义和测量?
．识别利益相关者。
项目通常都有很多利益相关者。
常被忽视的利益关者包括：
产品服务以及支持、法律保证、支付、仓库费、分销途径广告、物流、安全、环境保护功能、保险等，有的时候还涉及重要的分包商。
各方对于风险的观点都不同，对于风险的容忍度也不同。
有的利益相关者并没有在早期考虑，而他们最终的结论却导致很多问题。
训练您自己从利益相关者的角度看待问题，您可能会获得很好的观点。
没有一个项目是同计划完全一致的。
您在启动项目时所不知的是，您将会在何时以及以何种方式偏离计划。
．研究以前的项目。
组织总是犯同样的错误。
他们的目标是避免犯重复的错误，这样他们项目团队就可以进行革新。
以前的项目都有一系列的关于常见错误和问题的知识，包括不确定或变化的需求、资源变更、角色或职责界定不清、对接的问题等。
上述几项是经常遇到的困难，您需要建立这样一种观点：
“这个项目是不同的”。
您也应该尝试识别影响组织其他能力的机会，以及建立新技术、战略和知识产权。
．沟通目的。
您要确保各参与方明白会议召开的目的，并提前发出您的通知书，以便为会议的召开留出足够多的时间。
会议结束得比计划的早会比较容易，而计划另外的时间去完成最后的风险——应对计划——相对比较难。
当您听到“我没有时间”，那么请记住：
一个早期的风险事件的负面影响可能会导致进度计划的落后和费用超支。
有必要了解学习型曲线：
如果人们刚接触风险管理过程，那么至少要计划一天进行学习。
对于大型复杂的项目，可能时间更长。
随着团队流畅地使用术语和工具，团队会变得更有效。
这些决定在面对面的环境中将会更加有效。
在当今快速的全球经济环境下，人们常常会面。
尽管我们见证过一些B2B项目的成功，但大部分的会议却是组织不佳。
从面对面的沟通直到您建立一个资深的项目团队，风险管理都是沟通与组织决策制定的一部分。
步骤二：
用共同的语言进行沟通
共同的语言是为好的沟通和行为建立了基础。
您应该审查并“操纵”团队来研究本章开始介绍的问题和风险，还有回避、缓和、转移以及自留风险——应对战略。
我们将在第七步做详细介绍。
首先进行风险识别，对团队提出以下问题：
“考虑我们的公司或其他的组织，什么使得项目执行效果不佳（甚至失败）?
”问题的答案与项目战略方面有关。
我们还须建立项目战略的模型。
此外，问题还能激发人们关于项目复杂程度的更深一层的考虑。
记录结果，并张贴起来，以便团队成员能够获得可能的观点。
这种识别活动仅需15分钟。
邀请高级管理者参与识别活动，因为这能使风险的识别“合法化”，能够帮助表明人们实施的不同事例，并为有效的风险打下基石。
目标是用于开发杠杆：
项目团队需要让高级管理者对有哪些可能的风险和问题留下印象。
其中有的风险和问题需要高层管理者的拥护，高层管理者也要通过指派优先权做出决策。
这种方法采用从上而下的观点看待失败。
它扩大了技术人员的视野。
大部分人，尤其是那些有着深厚技术背景的人，主要从狭隘的观点管理项目，且不关注零售系统的综合功能。
通过直接介绍成功与失败，您能让他们更多地关注战略问题，而不仅仅是细节问题。
好的领导者建立了有效的团队文化，风险管理是该文化的催化剂。
有效的团队文化有很多特点，包括开放的思维、忠诚、权威、调查与主张的平衡、激情及承诺的意愿。
荒谬的是，组织文化在许多美国组织中（如乐观的、保密的、欢庆的、竞争的以及合作）竞是风险的来源之一，因为很多人都带着（（／陕乐”的面具，而掩盖了他们的不满。
领导者要能够帮助团队成员克服他们的心理障碍。
他们不愿意制造问题，因为他们不愿意被贴上“不乐意成为团队成员”或“不主动”的标签。
一种对团队有帮助的文化能够起到确保人们关注成功而不是制造危机的行为。
最大危险是由于失职这种错误导致的，而不是委任的错误。
失职的案例如缺少或忽视必要的技术或职能投入，而委任的错误则是让一个相关的评估会议变成了问题解决会议。
案例研究分析、个人经验，以及经验研究回顾表明有大量可预测、可识别的“红旗”在通知我们项目的绩效很差。
您可能希望使用简单的诊断性工具，如图11—1所示，帮助识别与列举遇到问题的常见原因。
给每个“真”项目制定权重，如果总分大于25分，那么您可能要变更项目计划或组织计划，您可以使用这个工具评估您的项目会走人困境的可能性。
根据您的实际情况制定适合您的项目的选项以及权重，并进一步查找困难的根本原因。
步骤三：
指定团队“关注点”列表
第三步的目标很简单：
预测影响成功的危险因素，制作风险事件表和问题表。
通过识别困难，团队能够采取预防的措施，更有效、更快速地做出反应，甚至有可能将威胁转变成机会。
图11—2介绍了已经通过验证的风险识别技术。
这些工具能帮助个人或团队重新制定他们的概念模型，并避免可能的决策制定的盲点。
注意：
每一项技术都有一个共同的缺点，需要他们花费时间学习以及实施，并可能产生导致个人冲突的心理障碍。
有的技术很常见，有的则不是。
当团队界定了关注点，紧接着就应该将它们分割为风险和问题。
风险事件离散的，并满足“有可能发生，有可能不发生”的标准。
问题是一种说明，有时候很模糊，比如“已经发生”、‘‘正在发生’’以及‘‘肯定发生”。
有的人认为风险和问题的区别在于，是否是一个重要的点。
以下是一种常见的反应：
“首先，团队成员没有认识到分离风险和问题的必要性。
无论你给出了多少案例用于界定风险和问题（比如，一个没有打气的轮胎是一个困险，驾驶一个几乎没有汽油的车是一个问题），人们仍在区分风险和问题上有困难。
”但是，经验表明：
进行这种区分是很有帮助的。
要尽量具体地确认关注点，那么在接下来的步骤中您可以省去很多困难图11—3介绍的因果结构在了解和确认风险上起到一定的作用。
这个例子的结果或成果被称为“推迟产品启动”：
注意：
有两种可能的起因，通常出现在风险识别和头脑风暴法中，它们是风险事件，因为它们可以满足“它们可能发生，它们也可能不发生”的标准；“供应商延迟”的因素是深层的原因，也因此该分析变得更有趣。
“没有给供应商足够的订货至交货的时间”不是一个风险，而是一个问题，需要通过问题管理程序进行管理。
因此，没有提供足够多的订货至交货的时间，组织就为可能的推迟做好了准备。
现在，团队可以合作逐步进行工作，确保供应商能满足他的职责。
我们也可以做出类似的有关设计的意见：
如果供应商管理没有一个模式或完整的设计能力，那么它就不能尽早地对要求变更做出反应。
要使风险最小，团队需要察看整个供应链，预先制定能力，而不是责备供应商。
图形化技术能帮助模拟原因和结果。
此外，图形化技术能指出产品开发的零售系统属性，并强调成功的职责要由各个利益相关者共同承担。
一个经常要问到的问题是：
“什么时候停止因果分解?
’’答案是通过反向查找原因链直到某个个人对风险事件的发生有影响的点。
当团队确定它已经通过分析，对安全、停止、记录风险事件达到足够的层次。
一个离散的、具体的风险事件是，量化工作和评估程序的输入。
通常来讲，在项目的早期，您会发现问题远远比风险多。
这是因为团队对产品开发工作没有充分了解，而且自然语言也很模糊，因此很难开发具体的因果说明书：
但是，该程序的真正价值在于能让交叉职能团队成员用合适的语言传达他们的关注点给其他人。
关注点的构思——并详细地介绍它们——并不需要花费很长的时间，通常来讲少于一个小时。
一般隋况下，团队成员会没有耐心，不愿意花时间从事风险识别的全面理解。
但是，有必要经常提醒团队成员：
如果有一个风险没有识别，那么团队在该权变区的工作会以不断地浪费之前的时间、精力以及资金而告终。
现在，您有了一个团队识别了的关注点列表用于进一步分析。
您确认的风险和问题越具体，您进行分析和制定的应对计划会越好：
步骤四：
分类
第四步，团队根据风险列表和问题列表评估它们的资源：
随着团队分析工作的进行，风险和问题分离能够帮助团队成员明白他们对项目的成功要共同承担责任。
风险和问题属于团队责任，不能任意妄想。
列举风险和问题的过程能够帮助项目经理制定一个有效的包含招标的项目计划：
通常，团队仅通过在在工作分解结构和进度计划上增加一个任务来解决问题。
分类过程能帮助团队成员明白了解了什么，还有什么没有了解。
因此，团队成员可以深化分析，并制定行动计划。
我们认为以下几步对项目风险资源类很有用。
·技术风险资源。
这些资源与项目产品或生产程序的设计与运作有关。
·物流风险资源。
指常规或经济地变更、供应、采购、存货、维修以及支持有关的资源：
·计划风险资源。
指获得与应用计划和项目的资源，如技术专家、项目工具以及资本和项目费用预算。
·商业风险资源。
指变更假设与影响收入、费用、市场占有率、利润等有关的资源。
通过划分职能领域避免分类风险（如工程风险、生产风险以及营销风险），因为这种方式避免了相互之间的指责。
大部分的项目和产品绩效问题都是在交接时发生的。
有时候，深入分析决定“战略”和，‘运营”因素是有价值的。
运营风险指影响产品交付时间和开发费用的风险。
技术问题通常是营运方面的，而不是战略方面的。
大部分的技术问题通常需要给予充分的时间和资源来解决。
团队生产产品时要进行时间、功能和费用的平衡分析。
如果在技术开发阶段团队会耗费大部分的时间在营运风险上。
但是，不要忽视影响项目挑选或项目能力以便满足业务目标战略的问题，如利润或客户满意度。
团队应该定期地在客户价值的角度评估风险事件。
项目取消是对某些风险事件或问题的法律反馈。
步骤五：
分析风险
风险事件是离散的事件，需要满足“可能发生，可能不发生”的标准。
风险分析是一个团队评估一个风险事件概率和结果的过程。
当涉及风险时，影响这个词常常与结果这个词同义。
风险的公式是事件的概率X事件的结果：
事件的概率X事件的结果=风险发生
图11—4介绍了一种风险图（也称为概率—结果矩阵），介绍了根据总体风险概率和结果的6个风险事件：
一个“高”风险；四个“中等”风险；两个“低”风险。
量化过程能帮助团队深入了解哪个风险事件需要更多的关注，记住LordKelVin所说的话：
“当您要对您所说的话进行测量并将它们以数据的形式表达出来时，说明您了解一些事情；但是如果您不能以数据的形式表达出来，您它的了解则很少。
”团队能靠确定在步骤二的项目成功与失败的定义测量评估，评估风险结果能帮助项目团队评估重要的成功因素。
有些人可能会反对用大量的、可能的和细小的风险事件。
他们害怕这些工作会使他们感到无助，也浪费时间。
尽管这可能是真的，但要牢记：
您需要开发和判断对于项目的成功而言哪些是战略性的，哪些是细微的。
当您认为发生的概率很高时，我们希望您注意：
您可能将它认为是一个问题而不是一个风险，因此您可能会用问题管理技术而不是采用将在步骤七介绍的风险管理技术。
根据我们的经验：
项目的技术风险不多；更恰当地说，产品绩效问题是通过设计平衡解决的。
运营风险是那些影响时间开发和费用开发的风险。
图11-6是一个表格，用来评估在四个可能结果区域的项目营运风险，这四个区域是开发费用、目标产品成本、进度计划和产品性能。
对团队成员来说有一点很重要：
根据他们自己的商业环境确定结果影响，并将它们具体到每个项目和它的组织背景（比如，延迟两周对某些公司和项目来说没有影响，但对有的公司则是灾难性的）
根本上的变革需要更大的风险容忍度，渐进性的变革通常对风险的容忍度很小。
增加的产品有更多的已知和了解的项目以及更多的预测。
如，利益相关者对根本上的变革在进度计划或预算上的容忍度是50％，而对一个渐进性的变革则可能是10％。
图11-7列举了几个项目风险定量化技术，项目团队能用于更深层次地了解率和结果。
项目团队经常进行结构评审（也称为红色团队或预排），提高它们的风险分析。
团队邀请一位独立的评估人员确认评估、边界以及交界面的有效性，确认分类、风险的特征，确认负责人。
团队仍对项目绩效负有职责，但对于项目的状态能够获得一个更加客观的外部观点。
该评审能促使项目团队反思，开发优先权以及避免匆忙进行不成熟的收尾。
第21章介绍了决策树，通常与风险分析一同使用，作为会带来不确定结果的选择的理性方法。
最终且最关键的要点是尽量小心分析，避免进入麻痹状态!
人们通常会陷于细节当中，使用过于细小、主观的数据。
您应该关注团队是否陷于细节当中。
目标是对风险和问题达成一致。
步骤六：
区分风险和问题的优先次序
项目有上百个风险和问题，通常比任何一个团队能够管理或者应该管理的还要多。
接下来的步骤就是团队应该区分分类后的风险和问题的优先权。
有很多技术可以用来区分优先权。
权重可能是常见的技术。
有必要将确定利益相关者对风险的容忍度作为制定优先程序的一部分。
了解利益相关者对风险的容忍度很重要。
作为一个制定决策的过程，项目团队要对结果进行讨论，并制定“截止层”，以决定哪些风险项目能接受，哪些风险项目要尽量避免。
尽管在定量化和区分优先权之前决定利益相关者的风险容忍度更有意义，但是我们发现团队通常担任此重任，并制定分析报告。
接着，与利益相关者讨论数据。
在不同的背景下研究可能结果的范围时，利益相关者会直接参考相关数据，做出直接的判断，决定哪些他们可以接受，哪些他们不能接受，以下是一些关于评估个人或组织风险容忍度的问题。
●上限和下限分别是多少?
风险何时发生?
●我们能最后挣回损失吗?
我们控制的程度如何?
步骤七：
风险应对计划以及问题管理计划
风险应对计划是一个制定战略计划的过程，用于减少完成计划项目以及产品成果中的风险。
项目团队根据制定好的优先等级风险列表，着手制定最受关注的风险的应对计划。
经常乘坐飞机的人知道大部分的商业航空公司都有进度计划缓冲表，以保证飞机按时抵达。
我们都有过这种经历：
飞机比预定的时间晚起飞30分钟，但仍然按时抵达。
此外时间缓冲表还允许飞行员使用应对方案，如提高飞行速度按时抵达。
航空公司通过制定稳妥的、有时间预留的计划达到顾客期望，同时给与飞行员（类似于项目经理）足够的资源和权力来制定和运用应对计划。
在深入研究风险应对计划之前，我们还要介绍常见的风险消极接受方法，即忽视风险的结果或预测不实际的风险结果。
考虑以下评论。
人们倾向于首先从事项目中简单的工作，而忽视那些困难的。
一个好的领导则是首先关注困难的事情。
当项目团队“将困难扫到地毯下”时，他们就是消极的接受风险事件。
有效的项目经理会带领和鼓励参与人员开始，并持续地投入精力管理项目风险。
包括：
认识到组织文化经常允许个人处于舒适地带，这通常是一种职能缺陷。
舒适领域常常会产生心理偏差，减弱自我职责，为竞争和危机管理寻找借口。
有四种常见的风险战略需要团队给予关注。
注意那些能帮助您评估每种战略优点的问题。
．风险回避。
包括改变项目计划以减少特殊的风险事件或条件。
通过回避风险，B2B项目团队能减少引起差产品或坏绩效的一种来源。
回避还包括取消项目。
但是运用风险回避，组织会失去很多机会。
在运用风险回避时，您要问以下问题：
我们如何回避风险事件?
风险事件带来的灾难性后果如此的重要，以至于要终止项目。
．风险缓和。
指减少可接受风险的概率以及结果。
增强一个产品的可信度（如减少失败之间的平均时间）就是一个减少概率的例子，增强设计（制定一个额外的或支持系统）是一个减少冲击的例子。
在运用风险缓和时您可能会问以下问题：
我们如何减少风险事件发生的概率?
我们如何减少风险事件对项目成果造成的冲击？
．风险转移。
指将风险的责任转移给另一方。
如合资、分包以及采购保险和担保。
转移对团队而言通常是范围之外的概念，他们认为工作是一种技术开发和市场开发。
运用风险转移时会问：
其他企业能否更好地处理该风险?
我们应该如何承包该风险工作或风险事件？
．风险自留。
积极地接受是指制定一个紧急计划。
消极地接受则是当风险发生时将风险留给项目团队解决。
运用风险接受要问以下问题：
如果我们一定要接受该风险，我们可以运用哪些紧急战略?
第8章和第9章介绍了在估算时项目不应该增加额外任务的原因，以回避风险。
好的方法是准确地估计任务（第8章介绍的PERT技术是一个好的方法），接着制作一个“缓冲表”解决项目中发生的偏差。
步骤是：
．如果组织有一个历史项目的实际一预算对比的数据库，您就能估算实际—预算对比的平均偏差，并在您的估算中运用这些数据。
．您要综合风险事件的预测货币价值。
．您要采用您估计的关键路径标准差，乘以一个常量（见任何一个标准统计课本书中的z表），计算出置信程度。
．您能通过使用可利用的PDM软件，通过蒙特卡罗模型模拟项目，利用该结果来决定您需要的置信程度。
记住：
利益相关者的风险容忍度估计（步骤六）是指任何一个内部或外部利益相关者都有一个确定的层次。
一旦项目经理有一个好的风险分析，他就能根据风险容忍程度与利益相关者进行协商。
有能力的项目经理会考虑利益相关者的风险容忍度，并将它们加入项目基准线计划中。
如，有的利益相者能容忍产品性能降低，但不能接受产品时间交付推迟。
计划能确认和定化项目经理可利用的缓解时间。
缓解能被称为管理准备金，因为它包含计算了负面风险事件的预测值。
该项目准备金是属于项目经理的资源，用于承担负面风险的费用。
基准线绩效和管理准备金能保证风险的所有权以及结果的责任。
在遇到风险时，即使风险应对措施在最初应对时看上去并不可行，也应该指导团队运用应对措施。
您还会发现团队可能采用预先回避、缓和以及转移的战略。
如果项目团队决定接受该风险，它就会制定相应的应急计划。
剩下的风险则通过为该目的制定的时间缓冲表或接受更低的利润获得。
在您的企业中，可能没有相应的备选预算。
因此，如果您发现您自己处于一定要增加任务／工作且没有其他明显的方法的境地时，那么您必须要这么做。
所在的组织是一个鼓励好的项目风险管理的组织，那么您很幸运，您可以据以往记录的方法，计算一个明确的、可追查的风险准备金，然后加入项目进度计划或预算，制定项目针对风险的时间缓解表。
在步骤四中，我们介绍了将风险进行分类。
最大的类别一般是技术风险。
我们发现大部分的技术风险指产品功能没有很好发挥作用。
因此，技术风险实际上就是产品可信度问题。
下面介绍的一种常见的产品工程技术——失败模式效果分析（FMEA）——很有帮助。
FEMA包括识别产品功能以及这些功能的性能、根据功能挑选失败模式（如间歇式失败）、评估一个导致失败原因的概率以及对客户造成的影响、查找并纠正失败模式的能力。
FEMA是工程学校以及进修学校通用的一种方法，在互联网上也有很多相关资料，因此项目团队中的一些成员会比较熟悉FEMA。
本章介绍的过程是针对项目群和项目层次的风险的，FEMA则更适用于技术可信度分析。
理论上，团队应该评估每个列举出的风险，但实际操作中，团队只选择指定的风险，一个好的方法是运用般关注权重很高的风险事件。
因此项目中风险和问题列表上的“前10的风险常常能指导团队选择考虑30-50个风险项”。
事件，但仅就其中的10个计划采取应对措施。
在步骤二中介绍了有效的风险管理的基础——“建立共同的语言进行沟通”记住：
一个风险是一个离散的事件，有发生的概率以及造成的影响；而问题则是已经发生或很有可能发生的重要事件。
如果团队不能很好地区分和了解风险和问题，团队就有可能会走入困境。
因为一个问题是一个肯定发生的事情，团队关注的不是问题会发生与否，而是在最后如何解决问题。
项目问题管理是简单的。
团队首先对问题进行排序并进一步分类。
团队成员决定个人对问题的责任并制定问题结论的标准。
我们发现指派职责对调查和评论很有帮助，且常常由其他人决定问题的解决方法。
项目经理要鼓励团队成员不时地提出问题的解决方法，保持项目团队会议的效率，并在会议上做出问题现在已经解决或需要重新开始的决定。
经验告诉我们，作为团队项目团队常常要选择20-30个问题进行管理；其余的则留给个人。
步骤八：
将风险应对综合到项目战略中，并将项目基准承诺归档
好的项目经理会对一定目标的范围、时间和费用做出承诺：
项目团队有必要做出某些决策，如，利益相关者的优先权有哪些?
项目团队留给项目每个因素的缓冲是多少（时间、范围以及费用）?
团队是如何分配风险责任的?
项目经理就像飞行员，他们会在起飞之前对飞行计划进行归档：
此外，他们还会考虑风险事件，如影响到进度计划、旅客的舒适感、预算以及安全感。
如果条件
升级会员 