最近给项目添加一个错误日志上报的功能，由于使用的是第三方的服务，导致上报的错误信息都是Script error.。上写的很清楚，要处理这个问题只需要两步：添加“crossorigin="anonymous" 属性和添加跨域 HTTP

实际运行的时候script标签是服务端渲染时动态在上述APP变量处生成的，这个时候我们就需要对渲染的HTML模板APP处进行修改，可以直接使用Nuxt的钩子函数，在nuxt.config.js文件，导出的json中添加如下代码：

Nuxt更多hooks相关内容可以看。

还有一种情况就是类似于动态import，他生成script标签的时候是受babel来控制的。这时就需要修改webpack打包时候的配置了，好在Nuxt是支持修改配置的，再修改nuxt.config.js文件如下：

综上，需要在nuxt.config.js文件中添加如下代码：

1） 项目需求，干系人的要求与期望

2） 项目的商业需求、项目概述或产品需求

4） 任命项目经理并授权

8） 组织的、环境的和外部假设

10   论证项目业务方案，包括投资回报率

项目章程是正式批准一个项目的文档，或者是批准现行项目是否进入下一个阶段的文档。

项目章程应当有项目组织以外的项目发起人发布，若项目为本组织开发也可以由投资人发布。发布人其在组织内的级别应能批准项目，并有相应的为项目提供所需资金的权利。

项目章程为项目经理是有组织资源进行项目获得提供了授权。尽可能在项目早期确定和任命项目经理。

2）工作说明书（sow）

3）环境因素和组织因素

4） 项目管理信息系统（PMIS）

初步项目范围说明书内容：

1） 项目和范围的目标

2） 产品或服务的需求和特性

3） 项目的需求和可交付物

11）对项目工作的初步分解

12）初步的量级成功估算

13）项目配置管理的需求

1） 没有定义项目范围说明书，没有书面的范围界定文档，没有指定项目完成或阶段结束的标准；

2） 范围说明书中没有定义项目的目标，判断的标准要明确（要量化）；

3） 范围说明书没有经过相关按摩的确认和核实；

4） 没有惊喜变更的管理或管理不规范

2） 制定初步项目范围说明

2） 采用项目管理方法论、项目管理信息系统和装机判断等工具制度项目管理计划

3） 采用配置管理系统进行变更和版本控制

4） 采用风险核对表、头脑风暴、概率影响矩阵等工具，管理项目风险，根据项目需要重新配置项目资源

5） 可使用需求追溯矩阵等工具管理项目需求

1） 项目背景如项目名称、客户名称、项目商业目的等

2） 项目经理、项目经理的主管领导，项目领导小组（即项目管理团队）和项目实施小组人员

3） 项目的总体技术解决方案

4） 对于完成这些项目工程的工具和技术描述

5） 选择的项目的生命周期和相关的项目阶段

6） 项目的最终目标和阶段性目标

9） 变更流程和变更控制委员会

11）对于内容、范围和时间的关键管理评审，以便于确定悬留问题和未决决策

6） 活动清单：活动属性；资源日历

进度计划的工具和技术：

1） 关键路径法（CPM）

2） 计划评审技术（PERT）

7） 假设情景分析（模拟）

4） 资源要求（更新）

5） 活动属性（更新）

6） 项目日历（更新）

8） 项目管理计划（更新）

2）成立初步的项目团队

3）工作准备与信息收集

4）依据标准、模板、编写初步的概要的项目计划

5）编写范围管理、质量管理、进度、预算等分计划

6）把上述分计划纳入项目计划，然后对项目项目计划进行综合平衡、优化

7）项目经理负责组织编写项目计划

8）评审与批准项目计划

9）获得批准后的项目计划就成为了项目的基准计划

1） 项目管理计划残缺；附属计划没有与整体计划一致

2） 没有区分计划的层次性（高级计划、阶段计划、详细的计划）

3） 制定的计划不现实，估算没有依据（没经验、没历史数据参考），没得到相关干系（包括客户）参与或承诺；不够明细以指导后续的实施。

项目团队为执行项目管理计划应采取的行动：

1） 按计划标准执行项目获得

3） 配备、培训和管理项目团队成员

4） 获取、管理和使用资源，包括材料、工具、设备与设施

5） 执行已计划好的方法和标准监控

6） 建立和管理项目团队内外的沟通渠道

7） 定期发布项目状态报告（成本、进度、技术和质量进展及状态数据）为预测提供数基础

8） 变更流程：提出变更请求，实施批准的变更

9） 管理风险并实施风险应对活动

11）  收集和记录经验教训，并实施批准的过程改进计划

1） 项目各单项管理的局限性，没有整体观

2） 没有对发现的项目问题进行控制（各个目标的监督和控制）

3） 不同的监控方式没有在项目中使用（控制方式单一、无效）

4） 整体的变更的控制没有制度，即使制定了也不规范或没有遵循流程

整体管理过程复杂项目的生命周期管理、全局性管理和综合型管理

全生命周期管理意味着项目整体管理过程负责管理项目的启动阶段直到项目收尾阶段的整个项目生命周期

全局性管理意味着项目整体管理过程负责管理项目的整体包括项目管理工作、技术工作和商务工作等

综合性管理意味着项目整体管理过程负责管理项目的需求、范围、进度、成本、质量、人力资源、沟通、风险和采购

根据每个项目的实际情况，项目整体管理的重点随项目的不同而有所变化。项目整体管理知识域包括保证项目各要素相互协调以完成项目所需的各个过程。

1） 制定项目章程 输入：合同工作说明书（SOW）组织过程资产  输出：项目章程

1） 项目计划制定  输出：项目管理计划

3） 指导和管理项目执行

包括合同收尾和管理收尾。合同收尾就是按照合同约定，项目组合业主一项项的合规，检查是否完成合同所有的要求，是否可以把项目结束掉，也就是我们通常所讲的项目验收

管理收尾对于内部来说的，把做好的项目文档等归档，对外宣称项目已结束，转入维护期，把相关的产品说明书转到维护组，同时进行经验教训总结

1） 建立企业级的项目管理体系和工作规范、管理上不乱

3） 培训学习项目管理知识，提高管理能力

4） 做好经验总结和各项计划

5） 做好整体管理，项目过程

6） 加强变更管理与控制，建立变更流程体系

7） 要有项目启动可行性分析

整体计划，即确定、综合与协调所有子计划（项目计划缺少相关分计划）所需要的活动，并形成文件；

项目计划缺少评审和审批环节；

明确项目交付物，建立和执行项目的质量评审机制；

没有处理好外部、内部因素带来的风险，缺乏有效对应措施；

需求估计不准确，资源估算不足，项目发生变更时没有及时更新项目计划；

制定进度计划的方法不合理，没有预留一定的缓存时间；

项目管理计划应由项目组成员参与；

项目的组织形式，明确项目团队和职能部门之间的协作关系

3） 已批准的变更请求

2） 进度变更控制系统

3） 绩效测量（绩效衡量）

4） 项目管理软件；偏差分析

5） 甘特图 （假设条件分析模拟）

5） 活动清单（更新）

6） 活动属性（更新）

整理管理还有可能和配置管理一起考

1） 缺乏项目整体管理和权衡

2） 缺乏变更控制规程

3） 缺乏项目干系人沟通

5） 缺乏整体版本管理

6） 缺乏各种单元测试和集成测试

1） 制定配置管理计划

3） 建立配置管理系统

1） 针对当前系统建立基线

2） 梳理变更脉络，确定统一的最终需求和设计

3） 梳理配置项及历史版本

4） 对照最终需求和设计逐项分析现有配置及历史版本的符合情况

5） 根据分析结果有干系人确定整体变更计划并实施

6） 加强单元接口冲厕所与系统集成测试或联调

7） 加强整体版本管理

变更常见问题、后果及原因

1）对用户的要求未进行记录

2）对变更的请求未进行足够的分析，也没活动批准

3）在修改过程中没有注意进行版本管理

4）修改完成后未进行验证

5）修改的内容未和项目干系人进行沟通

1）缺乏变更的请求的记录可能会导致对产品变更无法追溯，并导致对工业产物的整体变化情况失去把握

2）缺乏变更请求的分析可能会导致后期的变更工作失误

3）在修改过程中不注意版本管理，一方面可能导致当变更失败时无法进行复原；另一方面，对于组织财富和经验的积累也是不利的

4）修改完成后不进行验证则难以确认变更是否正确实现

5）未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致处

 变更常见的原因：

1）产品范围（成果）定义的过失或者疏忽

2）项目范围（工作）定义的过失或者疏忽

4）应对风险的紧急计划或回避计划

5）项目执行过程与项目基准要求不一致带来的被动调整

变更管理的原则：建立项目基准、变更流程和变更控制委员会（也变更管理委员会）包括以下内容：

1）基准管理：基准是变更的依据，在项目实施过程中，基准计划确定并经过评审后（通常用户应参与部分评审工作），建立初始基准。此后每次变更通过评审后，都应重新确定基准。

2）建立变更控制流程。建立或选用符合项目需要的变更管理流程，所有变更都必须遵循这个控制流程进行控制。流程的作用在于将变更的原因、专业能力、资源运用方案、决策权、干系人的共识和信息流转等元素有效的综合起来，按可科学的顺序进行

3）明确组织分工。至少应明确变更相关的工作评估、评审和执行职能

4）完整体现变更的影响。变更的来源是多样的，既需要完成对客户可视的成功、交付期等变更的操作，还需要完成对客户不可视的项目内部工作的变更，如实施方的人员分工，管理工作和资源配置等

5）妥善保存变更产生的相关文档，确保其完整、及时、准确、清晰，适当的时候可以引用配置管理工具

1）提出与接受变更申请

 变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在评估前应以书面形式提出。

 变更的初审目的如下：

1.     对变更提出方施加影响，确认变更的必要性，确保变更时有价值的

2.     格式校验，完整性校验，确保评估所需信息准备充分。

3.     在干系人间就提出评估的变更信息达成共识

4.     变更初审的常见方式为变更申请文档审核流转

 变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供CCB决策。常见的方案内容包括技术评估和经济评估，前者评估需求如何转化为成果，后者评估价值和风险。

4）项目变更控制委员会审查

 审查过程，是项目所有者根据变更申请及评估方案，决定是否批准变更。评审过程常包括客户、相关领域的专业人士等。审查通常是文档会签形式，重大的变更审查可以包括正式会议形式。审查过程应注意分工，项目投资人虽有最终的决策权，但通常在专业技术上并非强项。所以应当在评审过程中将专业评审、经济评审分开，对涉及项目目标和交付成果的变更，客户意见应该放在核心位置

5）发错变更通知并开始实施评审通过，意味着项目基准调整，同事确保变更方案中的资源需求到位。项目基准的调整包括：项目目标的确认、最终成果、工作内容和资源、进度计划的调整。需要强调的是变更通知后，不只包括实施项目基准的调整，更要明确项目的交付日期、成果对应相关干系人的影响。如变更造成交付期的调整，应在变更确认时发布，而非交付前公布。

要监控的，处理调整过项目基准中所涉及的变更内容外，还应对项目的整体基准是否反映项目实施情况负责。通过监控行动，确保项目的整体实施工作是受控的，变更实施的过程监控。管理委员会监控边更明确的主要成果、进度里程碑等，可以委托监理单位承担监控职责。

7）变更效果的评估可以从以下方面进行

1）首要的评估依据，是项目基准

2）还需结合变更的初衷来看，变更所有达到的目的是否已达成。

3）评估变更方案中的技术论证、经济论证内容与实施过程的差距并推进

8）判断发生后变更的项目是否纳入正常轨道项目基准调整后，需要确认的是相应的资源配置和人员是否及时到位，更需要加关注。

之后对项目的整体监控应按新的项目基准进行。涉及变更的项目范围及进度，在变更后的紧邻监控中，应更多的关注，当确认新的项目标准已经生效则按正常项目实施流程进行。

1、 根据项目存在的问题，简要分析小赵在项目整体管理方面可能存在的问题

答：1）需求分析和项目计划的结果不够详细，不足以指导后续的工作。

2）缺乏项目管理经验，缺乏对项目整体的及时监控。

2、 简要叙述瀑布模型的优缺点；以及其他模型如何弥补瀑布模型的不足

答：1）优点：阶段次序划分清晰，各阶段的工作和人员职责明确，前后阶段协接紧密。

2）缺点：理想的线性开发模式，缺乏风险的控制（比如，从需求确认完成到最终系统呈现给客户，通常要经过一段时间，具有一定的风险）；无法解析不明确的状况。

3）原型模型可以解决需求不明确的问题；螺旋模型强调风险分析，适合复杂、风险高的项目。

3、 请简要说明项目进入验收阶段时，项目应该完成的主要文档

答: 需求文档、计划文档、设计文档、编码后经过测试的代码、测试用例、测试报告、项目监控文档（周报、例会纪要）、项目阶段报告等。

1、请简要分析造成项目目前状况的原因

答：1）项目经理没参加项目计划的制定，没形成项目总体计划

2）子计划之间缺乏沟通和协调，并没有经过评审，可能存在不一致的地方

   3）项目经理规定计划不允许变更时不合适的，缺少整体变更机制

   4）让小组长各自监控，作为项目经理不监控项目状况是不合适的

2、请简要叙述项目整体管理过程包括哪些内容

答：制定项目章程、编写初步范围说明书、制定项目管理计划、执行项目计划、监控项目计划、整体变更控制、项目收尾

3、未完成该项目，从项目整体管理的角度，说明项目经理和公司可采取哪些补救措施

答：  1）理清各个子项目的状态，并重新制定项目的总体管理计划。

2）按照计划，平衡资源，协调各个子项目的状态

3）加强子项目之间的沟通以及监控机制