历时三周将《IT项目经理成长手记》通读一遍，期间为了写博客对每个章节又进行了回顾式阅读，记忆更加深刻，有利于在实际的工作中借鉴应用。
1. 范围说明书
项目《范围说明书》的作用是详细记录项目可交付的成果，以及为提交这些可交付成果而必须开展的工作。有了《范围说明书》，项目团队才能展开更详细的计划，才能评估变更请求是否为额外工作。
WBS(Work Breakdown Structure)是《范围说明书》的最主要内容，WBS将项目的交付物自顶向下逐层分解成易于管理的若干元素，结构化地定义了项目的工作范围。WBS每细分一层都是对项目元素更细致的描述，细分的元素称为工作细目，其中最底层的工作细目叫工作包。
项目的目标不等于工作范围，工作范围是项目目标的实现途径。善于发现项目潜在需求，是确定工作范围的一个要点。一份清晰的工作范围说明书，是后续工作的依据；即使有不清楚的地方，也可以通过假设的方式先记录下来。
2. 计划过程
工作范围确定后，需要按照标准化流程制定详细的工作计划，这套标准化流程就是制定计划的“计划”。
- 根据WBS制定活动清单。
- 确定活动之间的依赖关系，绘制网络图。
- 根据网络图的依赖关系和工期要求，确定各个小组的资源配置。根据资源的情况进行调整和平衡，完成进度计划和资源计划。
- 根据资源和进度计划，制定项目的预算。
3. 资源配置
资源配置有两种方法：资源优先和工期优先。
- 如果资源有限，工期要求不严，则按照资源优先的原则，按照实际能力计算工期。
- 如果资源充足，或者工期要求严，则按照工期优先的原则，先设定工期，然后计算所需要的资源，想办法获取资源。 资源配置的过程，核心是协调工作量、资源和工期的关系：
- 工作量(Effort)，指完成一个活动需要投入的人工，一般以人时、人天、人月为单位，比如，某需求分析的工作需要100人天。
- 资源(Resource)，指完成一项活动投入的人力资源和其他资源。
- 工期(Duration)，完成一项活动需要的时长。
4. 项目预算
项目预算过程可以分为估算和预算两大部分。估算的目的是估计项目的总成本和误差范围，而预算则是将项目的总成本分配到各工作项中去。
估算内容包括人工成本、费用、设备、原材料、劳务和外包成本等。在IT项目中，人工成本占相当大的比例，需要根据人员的成本单价和投入工作量进行计算。
成本预算是在确定总体成本后的分解过程。分解主要是做两方面工作：
一是按工作包分摊成本，这样就可以对照检查每项工作的成本，出现偏差时可以确定是哪项工作出了问题；
二是按工期时段分摊成本，将预算成本分摊到工期的各个时段。这样做的好处是可以在任何时间检查偏差，并评价成本绩效，避免“只要不超过总预算成本就没问题”的误解。
5. 风险管理
项目的四大风险：
| 风险 | 应对策略 |
|---|---|
| 项目可能延期 | 加强进度管理 |
| 项目可能超支 | 加强成本管理 |
| 质量可能难以达标 | 提高交付质量 |
| 项目可能失控 | 加强变更管理 |
风险管理的过程简单，包括风险识别、风险分析、风险计划和风险监控几个步骤。
5.1 识别风险
- 技术风险 如果项目采用了复杂或高新技术，或采取了非常规方法，就有潜在问题。如果技术目标过高、技术标准发生变化等也可造成技术风险。
- 管理风险 比如进度和资源配置不合理；计划草率且质量差；项目管理的基本原则使用不当等就可能造成管理风险。
- 组织风险 常见的是组织内部对目标未达成一致；高层对项目不重视、资金不足或与其他项目有资源冲突等都是潜在的组织风险。
- 外部风险 比如法律法规变化；项目相关接口方的情况发生变化，这些事情往往是不可控制的。
5.2 风险分析
分析分三个维度，一是风险发生的可能性；二是发生之后对项目的影响，包括对项目的工作范围、时间、成本、质量几个方面的影响；三是当前到风险事项预期发生时段的时间距离。
因为“可能性”和“影响”都是定性的因素，为了规避口径不同，可以参考定性分析的表格。用五个等级划分可能性和影响的等级，并分别用系数、语言描述和数字概率进行说明。
5.3 风险计划
风险管理流程中规定，对于不同类型的风险，可以采用不同的对策。有的认了，有的避免，有的提前准备，这是制定风险计划的依据。 应对策略分为以下几类：
- 规避 通过变更项目计划消除风险或风险的触发条件，保护目标免受影响。这是一种事前的风险应对策略。例如，采用更熟悉的工作方法；澄清不明确的需求；增加资源和时间；减少项目工作范围；避免不熟悉的分包商等。规避策略可以从根本上避开风险，这样的事情不会再发生了。
- 转移 不消除风险，而是将项目风险的结果连同应对的权力转移给第三方。(第三方应该知道这是风险并有承受能力)。这也是一种事前的应对策略，例如，签订不同种类的合同，或签订补偿性合同。转移性策略可以确保这样的事情发生了也跟我没有关系。如果采用这种策略，可以签人月合同，延期不会造成我们的损失。
- 弱化 将风险事件的概率或影响降低到一个可以接受的程度。例如，选择更简单的流程；进行更多的实验；建造原型系统；增加备份设计；储备更多的资源应对意外等。弱化策略可以确保风险发生了也能应付，虽然有一定的影响但是可以接受。
- 接受 不改变项目计划(或没有合适的策略应付风险)，而考虑发生后如何应对。例如，制定应急计划或退却计划；甚至仅仅进行应急储备和监控，待发生时随机应变。接受的策略基本上就是发生了再说。
5.4 风险监控
风险监控有三个目的：
一是监视风险的状况，例如风险是已经发生、仍然存在还是已经消失；对已发生的风险启动应对计划。
二是检查风险的应对计划是否有效，监控机制是否在运行。
三是不断识别新的风险并制定对策，不断更新已识别风险的状态。一般随着时间的临近，风险的发生概率也会增大，风险的级别可能改变。
项目中常见的风险监控方法如下：
- 风险审计 专人检查监控机制，并定期做风险评审。除了周例会评审，到达里程碑后还要进行全面的风险识别和分析，并制定新的应对计划。
- 偏差分析 与基准计划比较，分析成本和时间上的偏差。例如，未能按期完工、超出预算等都是潜在的问题。
- 技术指标 原定技术指标和实际技术指标存在严重差异。例如，测试未达到性能要求，缺陷数量大大超过预期等。
6. 需求变更
IT项目中变更是常见的一个难题，但变更控制不是为了让变更变得困难，而是让变更变得有序，否者就会出现很多灾难性的后果。
变更控制流程有四个重要控制点：授权、审核、评估和确认，只有理解每个控制点的作用，在执行过程中作出正确的判断，才能避免什么都改客户还不满意的情况发生。
- 授权 变更流程中规定，必须明确授权客户方哪些人员有权提出变更申请，项目组哪些人员有权受理变更，并有双方人数要求。
- 审核 变更审核过程要求确定变更的优先级，并不是所有的变更都一定要修改，更不是所有变更都要立即修改，审核的目的就是按照规则确定哪些立刻改，哪些以后逐步优化。
- 评估 变更都是有代价的，应该评估一下变更对于时间、成本、质量等方面的影响，方便高层领导作出决策。
- 确定 评估结果一定要让客户知道，并确认是否接受代价进行修改。确认过程争取到了与客户协商的机会，如果客户接受变更的代价，即使今后不需要额外支付款项，也知道项目组有苦劳，项目组吃的是明亏。
项目过程中应该对变更控制的执行情况进行审计，发现违反规定的事件要严肃处理，这样就不会造成流程逐渐失效。
