Zen.Wu

参考《系统集成项目管理工程师教程》第二版P230、P235 项目招投标

招标文件要求中标人要提交履约保证金的，中标人应当按照文件的要求提交。履约保证金不得超过中标合同金额的**10%**。

招标人在招标文件中要求投标人提交投标保证金的，投标保证金不得超过招标项目估算价的**2%**。投标保证金有效期应当与投标有效期一致。

范围说明书内容包括：项目目标、产品范围描述、项目需求、项目边界、项目的可交付成果、项目的制约因素、假设条件。

项目范围说明书（project scope statement）详细描述了项目的可交付物和产生这些可交付物所必须做的项目工作。项目范围说明书在所有项目千系人之间建立了一个对项目范围的共识，描述了项目的主要目标，使团队能进行更详细的规划，指导团队在项目实施期间的工作，并为评估是否为客户需求进行变更或附加的工作是否在项目范围之内提供基线。

定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，明确所收集的需求哪些将包括在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或输出的边界。所以制定项目范围说明书工作用来对项目进行定义，该工作用来明确“项目需要做什么”。

《系统集成项目管理工程师》教材（第二版）P5

信息系统的特点

(1)目的性
定义一个系统、组成一个系统或者抽象出一个系统，都有明确的目标或者目的，目标性决定了系统的功能。

(2)可嵌套性
系统可以包括若干子系统，系统之间也能够耦合成一个更大的系统。

(3)稳定性
稳定性强的系统使得系统在受到外部作用的同时，内部结构和秩序仍然能够保持。

(4)开放性
系统的开放性是指系统的可访问性。这个特性决定了系统可以被外部环境识别，外部环境或者其他系统可以按照预定的方法，使用系统的功能或者影响系统的行为。

(5)脆弱性
这个特性与系统的稳定性相对应，即系统可能存在着丧失结构、功能、秩序的特性，这个特性往往是隐藏不易被外界感知的。

(6)健壮性
当系统面临干扰、输入错误、入侵等因素时，系统可能会出现非预期的状态而丧失原有功能，出现错误甚至表现出破坏功能。系统具有的能够抵御出现非预期状态的特性称为健壮性，也叫鲁棒性( robustness) 。

项目管理计划的主要用途有：▲▲▲

1)指导项目执行、监控和收尾；
2)为项目绩效考核和项目控制提供基准；
3)记录制订项目计划所依据的假设条件；
4)记录制订项目计划过程中的有关方案选择；
5)促进项目干系人之间的沟通；
6)规定管理层审查项目的时间、内容和方式。

需求管理计划内容如下：

1、如何规划、跟踪和报告各种需求活动。
2、配置管理活动，例如，如何启动产品变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限。
3、需求优先级排序过程。
4、产品测量指标及使用这些指标的理由。
5、用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构。
6、收集需求过程。

范围管理计划内容如下：

1、制定详细项目范围说明书。
2、根据详细项目范围说明书创建WBS。
3、维护和批准工作分解结构。
4、正式验收已完成的项目可交付成果。
5、处理对详细项目范围说明书或WBS的变更。

制定项目质量计划是识别和确定必要的作业过程、配置所需的人力和物力资源，以确保达到预期质量目标所进行的周密考虑和统筹安排的过程。

项目经理在编制项目质量计划时，希望通过相应的方法来明确质量标准及达到标准的一种最佳方法，可以运用编制质量计划的工具与技术中来进行选取合适的方法。制定项目质量计划一般采用效益/成本分析、基准比较、流程图、实验设计、质量成本分析等方法和技术。

（1）效益／成本分析：项目质量计划过程必须权衡考虑效益／成本的利弊。满足质量要求最主要的好处就是减少返工，这意味着提高生产率、降低成本和增加项目干系人的满意度。为满足质量要求所付出的主要成本是指用于开展项目质量管理活动的开支。质量管理原则的就是收益胜过成本。

（2）基准比较：基准比较是指将项目的实际做法或计划做法与其他项目的实践相比较，从而产生改进的思路并提出度量绩效的标准。其他项目既可以是实施组织内部的也可以是外部的，既可以来自同一应用领域也可以来自其他领域。

（3）流程图：流程图是指任何显示与某系统相关的各要素之间相互关系的示意图。流程图是流经一个系统的信息流、观点流或部件流的图形代表。在企业中，流程图主要用来说明某一过程。这种过程既可以是生产线上的工艺流程，也可以是完成一项任务必需的管理过程。流程图是揭示和掌握封闭系统远动状况的有效方式。作为诊断工具，它能够辅助决策制定，让管理者清楚地知道，问题可能出在什么地方，从而确定出可供选择的行动方案。

（4）实验设计：实验设计是一种统计方法，它帮助确定影响特定变量的因素。实验设计也能用于诸如成本与进度权衡的项目管理问题。例如，高级程序员的成本要比初级程序员高得多，但可以预期他们在较短时间内完成指派的工作。恰当地设计“实验”（高级程序员与初级程序员的不同组合计算项目成本与历时）往往可以从为数有限的方案中确定最优的解决方案。

（5）质量成本：指为了达到产品服务的质量要求所付出的全部努力的总成本，既包括为确保符合质量要求所做的全部工作（如质量培训、研究和调查等），也包括因不符合质量要求所引起的全部工作（如返工、废物、过度库存、担保费用等）。

（6）质量功能展开（Quality Function Deployment．QFD）：就是将项目的质量要求、客户意见转化成项目技术要求的专业方法。这种方法在工程领域得到广泛地应用，它从客户对项目交付结果的质量要求出发，先识别出客户在功能方面的要求，然后把功能要求与产品或服务的特性对应起来，根据功能要求与产品特性的关系矩阵，以及产品特性之间的相关关系矩阵，进一步确定出项目产品或服务的技术参数。

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

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

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

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

ITSS生命周期

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

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

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

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

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

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

ITSS组成要素

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

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

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

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

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

通常情况下是由具备匹配的知识、技能和经验的人员，合理运用资源，并通过规定流程向客户提供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等。过程略。