Zen.Wu

《系统集成项目管理工程师教程》的“10.2.2 制定项目质量计划所采用的主要方法、技术工具”节中指出：

制定项目质量管理计划一般采取效益／成本分析、基准比较、流程图、实验设计、质量成本分析等方法和技术。此外，还可以采用质量功能展开、过程决策程序图法等工具。

过程决策程序图法（PDPC）的主要思想是在制定计划时对实现既定目标的过程加以全面分析，估计到各种可能出现的障碍及结果，设想并制定相应的应变措施和应变计划，保持计划的灵活性；在计划执行过程中，当出现不利情况时，就采取原先设计的措施，随时修正方案，从而使计划仍能有条不紊地进行，以达到预定的目标；当出现了没有预计到的情况时随机应变，采取灵活的对策予以解决。

ITSS组成要素

IT服务由**人员(People)、流程(Process)、技术(Technology)和资源( Resource)**组成，简称PPTR。其中；

人员：指提供IT服务所需的人员及其知识、经验和技能要求；

流程：指提供IT服务时，合理利用必要的资源，将输入转化为输出的一组相互关联和结构化的活动：

技术：指交付满足质量要求的IT服务应使用的技术或应具备的技术能力；

资源：指提供IT服务所依存和产生的有形及无形资产。

通常情况下是由具备匹配的知识、技能和经验的人员，合理运用资源，并通过规定流程向客户提供IT服务。

ITSS生命周期

IT服务生命周期由规划设计(Pianning&Design)、部署实施（Implementing）、服务运营（Operation）、持续改进(Improvemenit)和监督管理（Supervision）5个阶段组成，简称PIOIS。

规划设计
从客户业务战略出发，以需求为中心，参照ITSS对IT服务进行全面系统的战略规划和设计，为IT服务的部署实施做好准备，以确保提供满足客户需求的IT服务。

部署实施
在规划设计基础上，依据ITSS建立管理体系、部署专用工具及服务解决方案。

服务运营
根据服务部署情况，依据ITSS，采用过程方法，全面管理基础设施、服务流程、人员和业务连续性，实现业务运营与IT服务运营融合。

持续改进
根据服务运营的实际情况，定期评审IT服务满足业务运营的情况，以及IT服务本身存在的缺陷，提出改进策略和方案，并对IT服务进行重新规划设计和部署实施，以提高IT服务质量。

监督管理
本阶段主要依据ITSS对IT服务服务质量进行评价，并列服务供方的服务过程、交付结果实施监督和绩效评估。

项目收尾包括：管理收尾、合同收尾。

管理收尾包括下面提到的按部就班的行动和活动：

（1）确认项目或者阶段已满足所有赞助者、客户，以及其他项目干系人需求的活动和行动。
（2）确认已满足项目阶段或者整个项目的完成标准，或者确认项目阶段或者整个项目的退出标准的行动和活动。
（3）当需要时，把项目产品或者服务传移到下一个阶段，或者移交到生产或运作的行动和活动。
（4）活动需要收集项目或者项目阶段记录、检查项目成功或者失败、收集教训、归档项目信息，以方便组织未来的项目管理．

项目收尾具体工作如：
①项目验收；②最终产品、服务或成果移交；③合同收尾；④总结经验教训，更新组织过程资产；⑤管理/行政收尾；⑥释放团队资源。

配置管理是为了系统的控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点配置的学科。

软件配置管理是一个支持性的软件生命周期过程，它有益于项目管理、开发和维护活动、各种保证活动、最终产品的客户和用户。

软件配置管理包括4个主要活动：配置识别、变更控制、状态报告和配置审计。

在配置管理系统中存放着配置项。IEEE对配置项的定义为“硬件、软件或者二者兼有的集合，为配置管理指定的，在配置管理过程中作为一个单独的实体对待”。

可作为配置项进行管理的内容有：

• 外部交付的软件产品和数据
• 指定的内部软件工作产品和数据
• 指定的用于创建或支持软件产品的支持工作
• 供方/供应商提供的软件和客户提供的设备/软件

其中典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经过评审和检查通过后进入软件配置管理。

1. 项目立项管理

项目立项管理包括机会研究、初步可行性研究、详细可行性研究、项目论证和项目评估。
项目论证一般分为机会研究、初步可行性研究和详细可行性研究三个阶段。

• 机会研究的内容为寻求投资机会，鉴别投资方向：
• 初步可行性研究阶段要研究项目是否有生命力，能否盈利；
• 详细可行性研究是要在多方案比较的基础上选择出最优方案：
• 项目论证是确定项目是否实施的前提。

2. 项目立项管理的内容

项目立项管理的内容包括需求分析、项目建议书、项目可行性研究报告。

项目可行性研究又包括初步可行性研究、详细可行性研究、项目论证和项目评估等过程。

信息系统项目的可行性研究就是从技术、经济、社会和人员等方面的条件和情况进行调查研究，对可能的技术方案进行论证，以最终确定整个项目是否可行。信息系统项目进行可行性研究包括很多方面的内容，可以归纳成以下几个方面：技术可行性分析、经济可行性分析、运行环境可行性分析以及其他方面的可行性分析等。

2.1. 需求分析

需求分析是指对要解决的问题进行详细的分析，弄清楚项目发起人及项目其他干系人的要求、待开发的信息系统要解决客户和用户的业务问题以及问题的来龙去脉。

2.2. 项目建议书

项目建议书（又称立项申请）是项目建设单位向上级主管部门提交项目申请时所必须的文件，是该项目建设筹建单位或项目法人，根据国民经济的发展、国家和地方中长期规划、产业政策、生产力布局、国内外市场、所在地的内外部条件、本单位的发展战略等等，提出的某一具体项目的建议文件，是对拟建项目提出的框架性的总体设想。

2.3. 项目可行性研究报告

项目可行性研究报告是通过对项目的主要内容和配套条件，如市场需求、资源供应、建设规模、工艺路线、设备选型、环境影响、资金筹措、盈利能力等，从技术、经济、工程等方面进行调查研究和分析比较，并对项目建成以后可能取得的财务、经济效益及社会影响进行预测，从而提出该项目是否值得投资和如何进行建设的咨询意见，为项目决策提供依据的一种综合性的分析方法。

2.4. 项目评估

项目评估指在项目可行性研究的基础上，由第三方（国家、银行或有关机构）根据国家颁布的政策、法规、方法、参数和条例等，从项目（或企业）、国民经济、社会角度出发，对拟建项目建设的必要性、建设条件、生产条件、产品市场需求、工程技术、经济效益和社会效益等进行评价、分析和论证，进而判断其是否可行的一个评估过程。项目评估是项目投资前期进行决策管理的重要环节，其目的是审查项目可行性研究的可靠性、真实性和客观性，为银行的贷款决策或行政主管部门的审批决策提供科学依据。

可行性研究报告只提供多方案比较依据，而项目评估报告通常是对多方案择优。因而，项目取舍的依据（决策依据）是项目评估报告。

配置标识 / 配置识别

配置标识( Configuration Identifcation)也称配置识别，包括为系统选择配置项并在技术文档中记录配置项的功能和物理特征。
配置识别是配置管理的基础性工作，是配置管理的前提。

配置标识是配置管理员的职能，基本步骤如下：

1. 识别需要受控的配置项
2. 为每个配置项指定唯一性的标识号
3. 定义每个配置项的重要特征
4. 确定每个配置项的所有者及其责任
5. 确定配置项进入配置管理的时间和条件
6. 建立和控制基线
7. 维护文档和组件的修订与产品版本之间的关系

企业信息化，参考集成第二版教程P57，合格的CRM系统至少需要包含以下几个比较基本的功能模块：

1. 自动化的销售；
2. 自动化的市场营销；
3. 自动化的客户服务。

客户关系（CRM）系统相关知识

概念：CRM系统是基于方法学、软件和因特网的已有组织的方式帮助企业管理客户关系的信息系统。
功能：有以客户为中心的数据库、有整合客户联系渠道的能力、销售、客户、营销三个业务自动化、有从大量数据中提取信息的能力。

整体变更控制流程

1. 提出和接受变更请求；
2. 对变更进行初审；
3. 变更方案论证；
4. CCB对变更进行审查、审批；
5. 发出变更通知并开始实施；
6. 变更实施的监控；
7. 变更效果的评估；
8. 判断发生变更后项目是否已纳入正常轨道；

其中(2)对变更的初审，变更初审的目的如下：
①对变更提出方施加影响，确认变更的必要性，确保变更是有价值的。
②格式校验，完整性较验，确保评估所需信息准备充分。
③在干系人间就提出供评估的变更信息达成共识。
④变更初审的常见方式为变更申请文档的审核流转。

实施定量风险分析是就已识别风险对项目整体目标的影响进行定量分析的过程。实施定量风险分析的对象是在定性风险分析过程中被认为对项目的竞争性需求存在潜在重大影响的风险。

实施定量风险分析过程就是对这些风险事件的影响进行分析。它可以为每个风险单独进行量化评级，或者可以评估所有风险对项目的总体影响。它也是在不确定情况下进行决策的一种量化方法。

定量风险分析的成果包括有：

(1)项目的概率分析
(2)实现成本和时间目标的概率
(3)风险登记单

错了很多次了

排列活动顺序过程-箭线图-四种依赖管理

(1) 强制性依赖关系

强制性依赖关系是法律或合同要求的或工作的内在性质决定的依赖关系。强制性依赖关系往往与客观限制有关。

项目管理团队在确定活动先后顺序的过程中，要明确哪些依赖关系属于强制性的。强制性依赖关系指工作性质所固有的依赖关系。它们往往涉及一些实际的限制。例如，在施工项目中，只有在基础完成之后，才能开始上部结构的施工：在电子项目中，必须先制作原型机，然后才能进行测试。强制性依赖关系又称硬逻辑关系。

(2) 选择性依赖关系

选择性依赖关系有时又称首选逻辑关系、优先逻辑关系或软逻辑关系。它通常是基于具体应用领域的最佳实践或者是基于项目的某些特殊性质而设定，即便还有其他顺序可以选用，但项目团队仍缺省按照此种特殊的顺序安排活动。

项目管理团队在确定活动先后顺序的过程中，要明确哪些依赖关系属于可斟酌处理的。可斟酌处理的依赖关系要有完整的文字记载，因为它们会造成总时差不确定、失去控制并限制今后进度安排方寨的选择。可斟酌处理的依赖关系有时叫做优先选用逻辑关系、优先逻辑关系或者软逻辑关系。可斟酌处理的依赖关系通常根据对具体应用领域内部最好做法，或者项目某些非寻常方面的了解而确定。项目的这些非寻常方面造成即使有其他顺序可以采纳，但也希望按照某种特殊的顺序安排。根据某些可斟酌处理的依赖关系，包括根据以前完成同类型工作的成功项目所取得的经验，选定计划活动顺序。

(3) 外部依赖关系

外部依赖关系是项目活动与非项目活动之间的依赖关系。这些 依赖关系往往不在项目团队的控制范围内。例如，软件项目的测试活动取决于外部硬件的到货；建筑项目的现场准备，可能要在政府的环境听证会之后才能开始。

项目管理团队在确定活动先后顺序的过程中，要明确哪些依赖关系属于外部依赖的。外部依赖关系指涉及项目活动和非项目活动之间关系的依赖关系。例如，软件项目测试活动的进度可能取决于来自外部的硬件是否到货；施工项目的场地平整，可能要在环境听证会之后才能动工。活动排序的这种依据可能要依靠以前性质类似的项目历史信息，或者合同和建议。

(4)内部依赖关系

内部依赖关系是项目活动之间的紧前关系，通常在项目团队的控制之中。

主流的网络存储技术主要有三种，分别是直接附加存储（Direct Attached Storage，DAS）、网络附加存储（Network Attached Storage，NAS）和存储区域网络（Storage Area Network，SAN）。

对象和类
对象是对客观事物的抽象，类是对对象的抽象。类是一种抽象的数据类型。它们的关系是，对象是类的实例，类是对象的模板。

抽象(Abstraction)
抽象是简化复杂的现实问题的途径。

封装
封装是隐藏对象的属性和实现细节，仅对外公开接口，控制在程序中属性的读取和修改的访问级别。

继承
可以使得子类具有父类的属性和方法或者重新定义、追加属性和方法等。

多态
同一操作作用于不同的对象，可以有不同的解释，产生不同的执行结果。

接口
描述对操作规范的说明，其只说明操作应该做什么，并没有定义操作如何做。

消息
消息体现对象间的交互，通过它向目标对象发送操作请求。

组件
组件表示软件系统可替代的、物理的组成部分，封装了模块功能的实现。

当项目的实际进度滞后于计划进度时，首先发现问题、分析问题根源并找到妥善的解决方法。

某大型项目原计划于6个月后交付，目前由于设备故障、人员流失和客户审核缓慢导致项目实际进展比计划延迟了 1个月。作为项目经理首先应该做的是（ ）。

A.对关键路径活动进行分析，评估是否可以进行赶工
B.重新设立进度基线，并对新的进度基线进行评审
C.记录进展缓慢的相关问题，并报告管理层
D.与客户沟通项目延期的可能性

根据《系统集成项目管理工程师教程》中“17.2.3信息系统安全管理体系”一节的所述内容，在GB／T20271-2006《信息安全技术信息系统通用安全技术要求》中将信息系统安全技术体系具体描述如下：

物理安全、运行安全、数据安全

灰度测试，在2020年下半年软考中项案例题，丢分了。整理一份知识点。
以下转载自：https://www.jianshu.com/p/5222073bc10d

灰度测试就是指如果软件要在不久的将来推出一个全新的功能，或者做一次比较重大的改版的话，要先进行一个小范围的尝试工作，然后再慢慢放量，直到这个全新的功能覆盖到所有的系统用户，也就是说在新功能上线的黑白之间有一个灰，所以这种方法也通常被称为灰度测试。类似于我们通常所说的内测。

注：核心内容是小范围、内测

模糊测试（Fuzzing），是一种通过向目标系统提供非预期的输入并监视异常结果来发现软件漏洞的方法。

在模糊测试中，用随机坏数据（也称做fuzz）攻击一个程序，然后等着观察哪里遭到了破坏。模糊测试的技巧在于它是不符合逻辑的。

自动模糊测试不去猜测哪个数据会导致破坏（就像人工测试员那样），而是将尽可能多的杂乱数据投入程序中。由这个测试验证过的失败模式通常对程序员来说是个彻底的震憾，因为任何按逻辑思考的人都不会想到这种失败。

模糊测试是一项简单的技术，但它却能揭示出程序中的重要bug。它能够验证出现实世界中的错误模式并在您的软件发货前对潜在的应当被堵塞的攻击渠道进行提示。

本题考查制定进度计划的技术和工具，参考《信息系统项目管理师教程》第三版教程P279。

1、进度网络图中可能有多条关键路径。在项目进展过程中，有的活动会提前完成，有的活动会推迟完成，有的活动会中途取消，新的活动可能会被中途加入，网络图在不断变化，关键路径也在不断变化之中。

2、正常情况下，关键活动的总浮动时间和自由浮动时间为零。

3、资源平衡(Resource Leveling)。为了在资源需求与资源供给之间取得平衡，根据资源制约对开始日期和结束日期进行调整的一种技术。如果共享资源或关键资源只在特定时间可用，数量有限，或被过度分配，如一个资源在同一时段内被分配至两个或多个活动，就需要进行资源平衡。也可以为保持资源使用量处于均衡水平而进行资源平衡。资源平衡往往导致关键路径改变，通常是延长。

注意资源平衡问题，20210222

• 资源平衡是一种进度网络分析技术，用于已经利用关键路线法分析过的进度模型之中。
• 资源平衡这种均匀使作资源的办法可能会改变原来的关键路线。
• 资源平衡的结果通常是使项目的预计持续时间比项目初步进度表长。将资源从非关键活动重新分配到关键活动的做法，是使项目自始至终尽可能接近原来为其设定的整体持续时间而经常采用的方式。
• 某些项目可能拥有数量有限但关键的项目资源，遇到时这种情况，资源可以从项目的结束日期开始反向安排，这种做法做按资源分配倒排进度法，但不一定能制定出最优项目进度表。

4、资源平滑(Resource Smoothing)。 对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术。相对于资源平衡而言，资源平滑不会改变项目关键路径，完工日期也不会延迟。也就是说，活动只在其自由浮动时间和总浮动时间内延迟。

系统集成合同管理的内容

系统集成合同管理是管理建设方和承建方的关系，保证承建方的实际工作满足合同要求的过程，其内容包括：

• 合同签订管理
• 合同履行管理
• 合同变更管理

不包括合同违约管理，合同违约是指信息系统项目合同当事人一方或双方不履行或不适当履行合同义务，应承担因此给对方造成的经济损失的赔偿责任。对合同违约的管理主要包括对建设单位违约的管理、对承建单位违约的管理、对其他类型违约的管理。

合同管理的作用

合同管理包括在处理合同关系时使用适当的项目管理过程，并把这些过程的结果综合到该项目的整合管理中。合同管理有如下3个主要作用。

1. 合同确定了信息系统实施和管理的主要目标，是合同双方在工程中各种经济活动的依据。
2. 合同规定了双方的经济关系，包括实施过程中的经济责任、利益和权利。
3. 合同是监理的基本依据，利用合同可以对工程进度、质量和成本实施管理和控制。

创建了.gitignore文件，在多个仓库中初始化和切换，发现过滤规则不生效，真是醉了。翻查百度，解决核心在于清除本地缓存，方法如下：

1
2
3
4

git rm -r --cached .
git add .
git commit -m 'update .gitignore'   //windows 使用的命令是  
git commit -m "update .gitignore"  //需要使用双引号

• 这是一篇 13年前 的博文，当时记录时间是在 2008-01-01 00:11:24 写下的，年轻真是可以无所畏惧的、任意妄为的，有删减。
• 仅仅做个纪念，括号为在 2021-01-26 20:10:30 加入的备注，***是人工过滤。

在2008年新一天，本着继续以自我为中心的理念（注：当时还是有点自知之明），刁着（YY）半支烟，翘着二郎腿，为过去的2007年做点忘却的纪念，为到来的2008年写下点宏伟目标。（注：假酒喝多有点上头~）

2007年，***就这样去了，不留一丝香味，追忆也只在一瞬，下一秒又是一个危险与机遇。（注：高端大气上档次的感觉）

流水式回顾下2007年：

上半年还是在南海桂城打滚着，NND有点陷入了井底，想跳也跳不出那井口，套住了差不多2年了，于是下半年回来顺德老家，为振兴顺德伟大web事业托起一陀飞翔，回来第二天找工作，极速互联，多猛的公司名字，让我一辈子都记得，特别是那叫孙小辉，让我第一次感到“老板”是这样，4个月光阴流失了，年末又跳到让我觉得稍微有点希望的技术型“ERP+出国留学+海归博士”的公司上，此乃后话……（注：后话是该公司还是个坑）

本文摘录2015年12月份学习总结，创建日期：2016-01-03 14:01:01，有修改。
以下正文：

在9月份领到了一项任务是关于《前端开发工程师的知识库指引》，想了又想，而在我们现在的设计团队，前端输出人员虽然技术水平是各有千秋，或者说术业有专攻的，但是在我看来，总是欠缺点什么。在网上搜索一堆文章和例子，特别喜欢这篇，《如何成为一个卓越的前端工程师》 http://jiongks.name/blog/how-to-become-a-great-front-end-engineer/ 这篇译文，翻译者是同行业的大牛。在《如何成为一个卓越的前端工程师》文章所说几点，值得我们深思学习。

• 别光解决问题，想想究竟发生是什么
• 学会预见未来的浏览器发展趋势
• 阅读规范文档
• 阅读别人的代码
• 与比你聪明的人一起工作
• “造轮子”
• 把你学到的东西都记录下来

而技能是可以学习的，但区分人才和顶尖人才的并不是他们的知识——而是他们思考问题的方式，我想这是我们最缺乏的。

本文摘录2018年12月份学习总结，创建日期：2019-04-15 17:09:30，有修改。
这是一个在2018年报考、学习PMP的总结，小小的在内网的分享。2021-01-21 22:11:20
以下正文：

12月也过去了，3个月PMBOK的项目管理学习也结束了，迎来一次持续4小时的考试，碰上考试期间不断咳嗽的老年病状，结果感觉是凉凉的，生无可恋了的。结果不美，虽然考试可以再来一次，但是过程还是没白费的，能完整地、系统地学习了一次项目管理知识体系的内容。

先介绍下学习和考试，有兴趣的同事看后可联系混个推荐PDU。

2017年6份学习总结，创建日期：2017-07-03 20:46:25，有删减；
文章是这文：https://mp.weixin.qq.com/s/wzxNbPiy0-JCTBShlKwoaQ，以下正文：

提高效率，提高效率，提高效率，终归事情太多，怎样做到高效的工作习惯，转载下文五个习惯，此文在我的微信收藏夹里，个别地方对照了自己的做法，学而时习之。

习惯一：异步沟通

沟通分两种，一种是同步沟通，另一种是异步沟通。

• 同步沟通，也叫即时沟通，我们平时在微信、QQ 上的对话，就属于即时沟通。即时沟通的优点是能够随时联系对方，即刻获取想要的结果，但缺点也很明显：沟通成本大，双方需要反复多次确认，才能继续。即时沟通对创作者来讲是大敌：硬生生将大块时间切成碎片，间歇性插入对话，转移注意力，打断心流。
• 异步沟通：简单地来讲就是尽量集中处理回复，争取将沟通效率最大化，给自己留下大块时间，专注于做更难更需要创意想象的事情。

2016年6月份学习总结，创建日期：2016-07-03 19:46:16，有删减；
以下正文：

这月陆陆续续看了刘同的《向着光亮那方》，“谁的青春不迷茫，迷茫背后是光亮”。记得当时看刘同的第一本书的时候，有一句话让我产生共鸣：谁的青春不迷茫，其实我们都一样，到第三本书，已经变成了谁的青春不迷茫、迷茫背后是光亮，伴随着书籍成长，从迷茫，到孤独，到有光亮，是不是能也找到点自己的影子，走向了光亮那方。

《向着光亮那方》是谁的青春不迷茫系列之三，青年作家刘同2016年的全新作品。关于人生中的转弯，告别，妥协，原则，裂痕……是青春的敌人，也是成长的代价。我们的青春都一样，孤独，迷茫，有光亮。愿你在自己存在的地方，成为一束光，照亮世界的一角。（百度百科介绍）

原文地址：http://blog.sina.com.cn/s/blog_6a656bb40102vhzf.html
作者：郭致星，百科介绍：http://baike.baidu.com/item/%E9%83%AD%E8%87%B4%E6%98%9F

• 在某市政政府集群调研，忙到天昏地暗，但还是抽空找了一个资深项目经理的一篇《如何做好项目的需求与业务调研》的文章，很有帮助，全文转载，供大家阅读，红字是划线内容，划线是附上我的读后感。(2017-03-03 22:59:04)
• 本文也是2017年3月内网学习总结；（2021-01-18 23:57:25）
• 这篇文章读了好几次，每次都获益良多，持续推荐。（2021-01-18 23:57:25）

2016年5月份学习总结，创建日期：2016-06-03 23:46:17，有删减；
回想当时，还真喜欢阅读刘同的作品，2021-01-18 20:58:55
以下正文：

这月一直在学习，现在只谈工作外的。大神名言，心情不好，多看书，看最想看的。偶尔翻到APP微信读书，第一本书《世界历史百科》读了几个晚上，没错我爱读历史书，一直不变的是读书的味道。

第二本书也就是今天推荐的，名字叫《你的孤独，虽败犹荣》，豆瓣链接，作者是刘同，百科链接，当初这书是很热，炒得厉害。我推荐这书，因被导读吸引了，作者在33岁的角度回顾33个篇章解读孤独，小清新加点小文艺还略带着点矫情的笔调。按作者的说话是这样的导读：

最近收到一份网络安全检查清单（如下，有删减），再加上部分的 IBM AppScan 里的安全漏洞，提取了出来，并完善内容做了说明，非原创仅方便在自己在日常工作中遇到时可查；
非原创，辅助说明内容持续更新；
可见：AppScan安全扫描工具 - IBM Security App Scan Standard

2011年12月份学习总结，创建日期：2012-01-03 22:21:31，有删减。

• 早年的一篇总结，记录对于前端标准的一些思考和萌芽工作；
• 对于当时的前端标准，始于2011年，在2013~2014进一步提升，编写和制定了一些硬性条件，但在2015年沉寂和消亡，在2016~2017年有SiteAzure产品后，重新做了点工作……
• 可由始至终还没做到位，原因很多，或者是项目性工作千化万变，在共性与个性中，难找平衡点，或者是核心人员不断流失，使得标准化过于空谈，或者是并没有重视质量保证和质量控制，使得初有成效的标准流于表面，没在项目中贯彻落实……

总之，那是10年前对前端标准的一些考量，个人记录。以下正文。

前言说的

设计中心标准化，为什么要做标准化？http://dtop.powereasy.net/pel/（注：已失效），这篇也算是标准化建设的2011总结和2012计划。

本文摘录2020年12月份学习总结，创建日期: 2020-12-16 21:05:05，有修改。

2020年下半年的软考高项考试，终于通过了！尽管这并没有什么卵用，一不入户积分、二不评职称、三不涨薪、四不加退休工资，可是：

富家不用买良田，书中自有千钟粟。
安居不用架高堂，书中自有黄金屋。
出门莫恨无人随，书中车马多如簇。
娶妻莫恨无良媒，书中自有颜如玉。
男儿欲遂平生志，五经勤向窗前读。

作为一篇总结日志，还是要记录下整一个学习过程，要从2010年开始说起了。

本文摘录2020年1月份学习总结，创建日期：2020-02-06 00:12:27，有修改。
从鱼骨项目管理的学习里，翻到一篇关于deadline的文章，有感，转载分享：《死线（Deadline）杀死团队拖延症》，鸡汤成分，占99%，慎思。

Deadline，大家都知道这个词表示“最后期限”的意思，为了强化最后期限的概念，也被翻译为“死线”。这个词源自美国的南北战争时期，用于军队的监狱里，表示监狱周围的死线，不可逾越的界线。到了二十世纪二十年代左右，deadline被媒体报纸作为行话术语推广开来，才有了如今被广为熟知的含义——最后期限。

每个团队都有一个长长的工作任务列表，在鱼骨系统创建任务记录待办工作：给每项工作一个负责人和截至日期，提升团队的整体效率和执行力。

1. Referrer

referrer是HTTP请求header的报文头，用于指明当前流量的来源参考页面。通过这个信息，我们可以知道访客是怎么来到当前页面的。这对于网站分析（Web Analytics）非常重要，可以用于分析不同渠道流量分布、用户搜索的关键词等。

但是，这个字段同时会造成用户敏感信息泄漏（如：带有敏感信息的重置密码URL，若被Web Analytics收集，则存在密码被重置的危险）。

2. Referrer-Policy

The Referrer-Policy HTTP header governs which referrer information, sent in the Refererheader, should be included with requests made.

通俗点就是Referrer的策略， Referrer 就是 referrer 属性可返回载入当前文档的文档的 URL。

转载：http://www.leadge.com/news_list/Details.aspx?id=81343
总结很全面，平平而谈中把众多的项目管理过程、方法都进行了讲述。

本人做项目经理工作多年，感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导，只有最合适的，没有什么叫对的，什么叫错的，项目经理最忌讳的就是完美主义倾向，尤其是做技术人员出身的，喜欢寻找标准答案，耽误了工作进度，也迷茫了自己。

1. hexo源码上存到git

1.1. 创建仓库、或创建分支

仓库用coding的，稍微比github快，于是建立了私人仓库等，配置ssh等。过程略。

内容安全策略，Content-Security-Policy，缩写 CSP，其核心思想十分简单：网站通过发送一个 CSP 头部，来告诉浏览器什么是被授权执行的与什么是需要被禁止的。其被誉为专门为解决XSS攻击而生的神器。

在SiteAzure的3.0版本配置文件web.config中，增加了这个防XSS的神器。

1
2
3
4
5

<add name="Content-Security-Policy" value="
script-src 'self' 'unsafe-inline' 'unsafe-eval' blob: *.map.baidu.com 
*.bdimg.com bdimg.share.baidu.com res.wx.qq.com pucha.kaipuyun.cn 
dcs.conac.cn webservice.coolwei.com www.gov.cn;
object-src 'self'"/>

下面详细介绍如何使用 CSP 防止 XSS 攻击。

自从考完高项后，博客的一堆笔记就这样放着了（信息系统项目管理师），但我想，博客还是想继续长期用用的，于是计划：

• 公司内网的学习笔记的转录
• Vue学习内容
• Linux学习内容
• 历史文章

目前博客是部署到 github+gitee+coding，双11入了腾讯CVM，同时兼顾学习Centos和Nginx，于是博客也部署到CVM，就成了 github+gitee+coding+CVM 的部署。

• hexo部署到 github+gitee+coding
• hexo部署到CVM
• hexo的图片使用又拍云的云储存和CDN（别问我为什么不是要腾讯OSS，我也不知道）
• 博客和图片都使用SSL

本文摘录2020年10月份学习总结，创建日期：2020-10-26 20:31:51，有修改。

一、案例分享

在一些PM群（PM创造营）定期会分享项目案例，以下的这条案例很常见、很通俗易懂，阅读后会有“原来是这样的，以后就按这样做了”，又或者 “也不过如此，无法改变”的感叹。

本人今年跳槽到外贸行业，新来这家公司的时候大领导谈的是PM，但是他分管几个地方，我现在在的地方有个小领导。最初和大领导谈的时候给绩效考核权，但是在实际中，各个工程师归小领导管，对PM的节点要求置之不理，甚至对项目要不要做都是看心情，同时小领导对项目管理认可但不重视。公司目前项目按照项目计划节点完成的很少，大部分项目都是延期状态，PM的职责更多的是明确项目的确切需求，进而降低产品开发过程中的变更，同时在项目各环节存在流程卡滞时，作为沟通员与其他部门进行沟通、督促流程签署。

以下群内大佬的回复

首先，分析案例，来进行问题梳理：

A. 新到一家公司任职PM
B. 不甘心被分公司小领导做上司，即心里不愿意被领导
C. 面试时候高级领导承诺了绩效考核权利，实际上没多大作用
D. 项目成员对项目价值不认可（做不做看心情）
E. 分公司小领导不重视项目管理
F. 项目延期
G. 需求不明确，导致变更繁多
H. 各部门环节沟通和信息传递不畅通

既然问的是在这种环境下如何进行项目管理，那么首先得这位PM得明确自己所处的环境是什么样的，明确外部环境因素，知道自己在这个公司当前实际上处于什么样的一个角色，毕竟按类型分有职能式、项目式、矩阵式多种类型的组织结构，不能一来就把自己当做项目式组织结构的项目经理。从以上描述可以看得出这位PM是把自己当做项目型组织的PM了，而实际这个组织是矩阵型组织，而且还是弱矩阵型组织，虽然也是顶着PM的title，实际上这个角色更倾向于一个项目协调人员或联络员，PM的权力影响力相对于职能经理都是很弱的，尤其是对于项目成员的绩效、薪酬、晋升这些关键方面几乎是没有什么重要影响力的，这是这种弱矩阵项目组织结构普遍的问题，也是很多国内公司的普遍现状。公司大环境是没法一朝一夕能改变的，所以问题归根结底还是PM如何在弱矩阵组织中做好项目管理。

先回到这位PM的具体问题，问题BC主要原因还是属于角色定位不对，解决办法首先要摆正自己在这个环境中的位置，先当好这个项目协调员，接受这是一个弱矩阵型项目组织的事实，接受地方小领导的领导，否则他随便一下子都能使你在协调项目过程中遭遇难以想象的阻力甚至项目失败。所以不要期待太多，在没有权限时要学会借用他人之权，只有名义上的绩效考核权，但这是一把双刃剑，现在在职能经理手里其实对你更有利，你不必因此背更多的考核压力。

问题D对项目做不做看心情终归于两方面：①是他们可能要接受双重领导，无所适从，毕竟绩效实际是职能经理在掌握，所以干脆只接受职能经理领导。②是是否真的了解项目的价值，这个项目到底有没有价值去做，这个你需要弄清楚之后再传递给项目组成员，也可能他们知道这个项目有价值，但是你缺乏影响力，这个就需要你提升自己的影响力了，初期可以通过先搞定产品经理和职能经理去达成，后面还是得靠自己的软实力硬实力去影响。

问题E：地方公司小领导不重视项目管理这个直接关系到资源的投入是否有保障，所以你需要使用软技能搞定他，具体操作还请结合社会主义特色（你懂的）根据实际操作，这又回到问题AB，要接受地方分公司领导的领导。

只要问题D和E搞定了，那自然项目延期也就能有很大的改观了，毕竟从这位PM的描述看延期产生的根源还是因为团队成员的不重视；

对于问题G需求的明确，这也是项目经理应该做的事情，产生原因①是可能项目章程没有明确目标和接收标准；②是可能项目成员没有理解需求或技能不足。如果是①那就把相关方拉拢重新开个会明确需求和执行要求；如果是②那就寻找资源针对成员进行技能培训。再建立需求跟踪矩阵进行跟踪，同时建立问题日志与经验教训册，避免同类问题重复发生。

对于问题H：各部门环节沟通和信息传递不畅通。流程卡壳先分析原因为啥会卡？是否与问题B和E相关？毕竟如果你在弱矩阵型组织中以项目型组织PM自居，那别人势必会对你设置一些障碍的。如果是因为流程本身确实有问题，那么可以在项目会上或者高层会议上提请针对当前项目进行流程优化方案，同时为自己争取更多的授权利于项目的开展，再通过后续逐步提升各方面的影响力，也就是PMP中所说的领导力，因为新入职而且暂时还没法去改变组织架构、流程制度，只能用软技能去达成目标，所有项目型组织都是由职能型和矩阵型组织成长起来的。

在当前环境下，你的PM之路就只有一个“借字诀”，在这个组织中所有资源都是借来的，不要对借来的资源有过高的期待，但是要凝聚这些资源，PM更多的意义在于沟通，可以说90%的时间都是用来沟通的，对项目成员适当的激励，借职能经理之手适当鞭策。

更重要的是要做好自己的心态建设，提升自己专业能力，从公司角度来说在意的是战略目标而非项目本身，做项目多的是你不知道的事，还须慢慢经历。

二、本月收藏的微信分享

• 拥有这个能力的项目经理，一开口就赢了 https://mp.weixin.qq.com/s/NJR0_CQ8Gj0wjCHAl1w4ew
• 项目经理必备的8种能力，最后一个90%的PM都认同！ https://mp.weixin.qq.com/s/lC9CwRMGcE9UPV8j4hctiA
• 【推荐】从《道德经》看项目经理修炼的7条法则，你做到了几条？https://mp.weixin.qq.com/s/cfOJLTa193V2B1P7dRgk3g

三、本月《高项》学习

10月份是最后一个月的学习了，“鼓足了劲头”，“我不入地狱，谁入地狱”，艰苦、享受的过程。这月把案例题、论文重新学习、复习、背诵。其余的事情已经无法分心，一张张“猝死”索命图。

2016年8月份学习总结，有删减，创建日期：2016-09-03 20:33:08

本月读书《书都不会读，你还想成功》

韩国的作者，倡导读书、读书、读书。这不是一个鸡汤书籍，类似小说的写法描述主人公从工作悬了、女友跑了、父亲的企业倒闭，想着老妈、小妹、房租，想着改变自己的人生，最后通过读书不断读书而逆袭的故事。

书在一开始就提出了“100天读33本”的目标，我们本身平时一听说“要读书”就会本能的觉得“我不是读书的料”“没时间读书”“我工作很忙的”，然后就是各种抗拒和拒绝，就算是咋们公司每月的学习总结，有哪几个是读书而自发后感的呢？哪几个是真正看书的人呢？豆瓣名人、作者、导师小川叔，也经常教导人多读书。《爱情公寓3》里的桥段宝强逆袭成功靠的是：多读书、多看报、少吃零食、多睡觉。（哈哈哈）

本文摘录2019年4月份学习总结，创建日期：2019-04-15 17:09:30，有修改。
吐槽文。

一、驻点实施的一些吐槽

（一）计划、找谁上门驻点实施

这里不谈项目需求应对的具体的人员这个情况(即开发对开发、设计对设计)。在公司的弱矩阵、平衡矩阵的项目组织结构下，会非常纠结，项目非一人能整合、绩效非一人能受控，这需要一个满满的项目计划、慢慢地渗透各组织、各部门、各层级的想法，正面、侧面，既要真实反馈项目情况、又或假设或积极或悲观对受影响的因素进行风险分析等。如上安排8人，能减少测试工程师、减少技术支持工程师吗？若有误判，就会造成了人员的错位、安排的失衡，说白就是成本两字。

并不是吹NB，这是需要不断演算的。俗称：夜观天象，掐指一算。

原文链接：https://blog.csdn.net/qq_36784628/article/details/80966826

js中三种定义变量的方式const， var， let的区别。

1. const定义的变量不可以修改，而且必须初始化

1
2
3
4
5

const b = 2; //正确
// const b; //错误，必须初始化
console.log('函数外const定义b：' + b); //有输出值
// b = 5; //修改变量值
// console.log('函数外修改const定义b：' + b); //无法输出，因为const定义的变量不可以修改

2. var定义的变量可以修改，如果不初始化会输出undefined，不会报错

1
2
3
4
5
6
7
8
9

var a = 1;
// var a; //不会报错
console.log('函数外var定义a：' + a); //可以输出a=1
function change(){
    a = 4; //改变变量值
    console.log('函数内var定义a：' + a); //可以输出a=4
}
change();
console.log('函数调用后var定义a为函数内部修改值：' + a); //可以输出a=4

3. let是块级作用域，函数内部使用let定义后，对函数外部无影响

1
2
3
4
5
6
7
8

let c = 3;
console.log('函数外let定义c：' + c); //输出c=3
function change(){
    let c = 6;
    console.log('函数内let定义c：' + c);//输出c=6
}
change();
console.log('函数调用后let定义c不受函数内部定义影响：' + c); //输出c=3