软件项目管理笔记Software Project Management

本文将软件项目管理的主要笔记整理出来，主要用于自己的复习和回顾。

Chapter1. Project Management Introduction项目管理介绍

Project项目: A temporary endeavor undertaken to create a unique product, service, or result.

Three important factors:

1. Temporary临时性: has a definite beginning and definite end.

2. Uniqueness独一无二性: doing something that has not been done before.

3. Progressive Elaboration逐步完善: developing in steps

Project vs Operational Work运营

	Project	Operational Work
Character	unique, creative	routine, repeated
working environment	open, risk	close, stable
team	temporary, change	stable, durable
purpose	terminate	sustain

Project management项目管理: The application of knowledge, skills, tools, and techiniques to project activities to meet project requirements.

To increase efficiency

Project Mangaer Mission任务

Triple Constaint三角限制 - Time, Cost, Scope, (Quality)

项目经理的任务：在规定时间、规定花销下，在规定范围内完成项目，并有一定的质量。

Project Management Team’s skillset

PMBOK Guide

Project Environment项目环境: 项目经理如何规避项目阻力、风险，借一阵东风？

向上：focus activity以事为主

向下：focus people以人为主

项目经理的主要职责：communication交流，工作70%以上

四个从小到大的概念：

Subproject子项目: 把项目分成更细的部分，便于管理。

Progject: 系列的活动，为了创建唯一的产品、服务、活动成果。

Program: a group of projects具有相连关系的一组项目，能够获得单个项目管理以外的好处，比如针对同一个客户。

Portfolio项目集：也是a group of projects，又包含了一个公司的策略问题，而不是针对某个客户和营销领域。哪些项目投入多、哪些项目投入少，哪些项目不做。

低端市场：薄利多销。先打开市场，再做多做强。比如，只有将低价的项目做好了，高价项目才能带来收益。

Chapter2. Product Life Cycle & Orgranization产品生命周期和组织

organization ana PLC

几种类别的organization：

1. functional organization structure职能部门型的组织结构

   在CEO下，有各种职能型部门，每个部门都有经理和成员。当项目到来时，会选择不同部门的一些员工加入项目团队中。承担协调工作的人员就是职能经理。

   非常普遍，政府性的组织常见。好处：不会出乱子，经理说了算。比较容易积累专业技术能力，便于部门内部交流。缺点：项目团队的沟通效率低下。

2. weak matrix organization structure弱矩阵型组织结构

   当项目到来时，选择不同部门员工加入项目团队。成员之间沟通，不需要向职能经理传达。

   矩阵型：纵向为职能部门，横向为项目组成。

3. balance matrix organization structure平衡型的矩阵组织结构

   当项目到来时，选择不同部门员工加入项目团队。在其中选择一个成员作为项目经理。

4. strong matrix organization structure强矩阵型组织结构

   出现了一个团队，全部都是项目经理，独立于其他职能部门。当项目到来时，选择一个项目经理加入团队。

   在公司中，非常常见。好处：有专门的项目经理。又能兼顾效率，又能兼顾部门的管理。

5. projectized organization structure项目型组织结构

   没有职能部门，只有各种项目团队。项目团队是动态的，职能部门的成员相对静态。优点：只有一个领导，项目经理，与平衡型相比，结构更简单。好管理、好评价。做项目时，比较高效。缺点：动态，项目终结后，这个项目的所有资源都会遣散，回到整个公司的资源池中，所有人员在专业技术上的成长就不如职能部门的人员。容易忙忙碌碌，但个人积累缓慢。

6. composite organization structure混合型的组织结构

   既有矩阵型，也有项目型的结构。相对复杂。

冲突最多的结构：矩阵型。两条汇报线：职能部门和项目团队。最最多的结构：平衡型，因为两条线势均力敌。

resource availability人员资源的可管理性

product life cycle产品生命周期

从一开始产品有概念，到这个产品退出市场。

project life cycle项目生命周期

从项目开始，到项目结束

产品的生命周期，还包括维护、运营工作，因此生命周期更大。

案例：一个产品的生命周期

项目的成本和人员投入的变化曲线

意义：理解这个趋势，当我们做项目计划时，我们能更好地知道如何分配我们的资金和人力资源

随着项目的时间推进，风险和不确定性会越来越低，但变更的成本越来越大。

agile敏捷开发：iterative process交互型的过程。积累型的开发模式，一个迭代1-4周。每个迭代中都包含了软件开发的所有过程。每一个迭代结束，都是一个可运行的产品，向干系人展示。如果客户认可，就可以认为迭代完成。减少了不接受现阶段开发成果的风险。如果有变化，也会尽快地调整，不会发生最后推翻重来的风险。

scrum是敏捷开发的一种模式

sprint：一个敏捷的迭代是2-4周

product backlog：对于产品的一系列需求，来自客户

sprint backlog： 从product backlog中选择一些，可以被开发细化的需求，作为这个迭代周期的计划

计划完成后，进行具体的开发、测试，实现sprint backlog的功能

结束一个sprint后，进行sprint review/sprint retrospective演示

接着进行下一个sprint

waterfall瀑布模式 vs agile敏捷开发

瀑布：下一个活动的起始是上一个活动的结束。上一个活动没有结束，下一个活动就不会开始。一般是不太容易分段处理，如硬件开发，不容易修改，如果有差池，需要从头开始制作。

Chapter3. Project Management Processes& Interactions项目管理过程和相互作用

两种项目管理的过程 two categories:

Project Management Procersses面向项目的过程: 一切为了项目能够更高效地推进。

Product-oriented Procersses面向产品的过程: 明确地是为了开发产品。

都有五个过程组process group：初始过程、计划过程、执行过程、监控和控制过程、结束过程

facility decommissioning设备退役 / waste removal/Cleanup垃圾处理

Initialting初始：定义一个新项目或新项目过程，并为其获取资源，如项目经理、资金，最重要的是得到项目的授权——得到做项目的许可，有人愿意投资。

Planning Processes计划: 主要是确定项目的范围，定义项目的目标。另外还有花销、时间、质量的目标。根据目标，制定出一系列的行动方案，一系列的活动。制定计划、收集需求。

Executing Processes执行：实现项目目标。当出现计划的偏差时，要回到计划的过程组。

Monitoring & Controlling Processes监控: 跟踪、复盘、维持项目的过程和性能。当出现变更的需求时，如何进行调整。

Closing Processes结束:所有过程组中的活动正常地关闭，遣散所有的资源，做一点经验总结、项目回顾等。

项目组在一个阶段或项目中的相互交叉图

从始至终，监控的投入度没有太大差别，比较平缓地分布在生命周期之中

project boundaries项目边界：项目或项目阶段被授权完成的时间点。项目的交付使用和记录不属于项目的范围。

关闭项目非常重要，花销记录在公司的项目账户下，如果拖拉不能关闭，就会超支，无法完成任务。因此在计划过程组中就要把项目的范围制定好。

Chapter4. Project Intergration Management整体管理

每一个知识领域有很多不同的活动

五大过程组可以理解为整个项目的时间线

范围：按照知识领域，分为项目管理的不同方面

加上每一个时间点做什么活动，就成了一个列表矩阵

整体管理：包含所有方面的计划。不会细致到某一个方面，比如时间、成本。

4.1 develop project charter项目章程

初始化过程组的最重要输出：项目章程document。也可以称为是项目立项的主要输出。给项目经理授权，允许他做项目。

主要的内容：

项目的目的或理由，形成什么样的产品和服务。

可量化的项目目标和相关的成功标准。量化地进行说明，如几个月，多少资金，大致的方向。产品的目标和项目的目标。

高层级需求high-level project descrption和风险。风险不仅是产品的风险，还有项目的风险。

假设和约束，对项目是一个保护。

高层级的项目描述以及项目边界。

总体里程碑计划和预算。里程碑按照项目的时间线去写。

项目的干系人清单，包括资助者。

项目经理的责任以及权限范围。

输入：

1. 项目的内容描述SOW(statement of work)
2. 商业方案
3. 达成的共识
4. 事业环境因素
5. 组织的过程资产

工具和技术：

1. 专家判断（和头脑风暴是两种获取意见的方法）。并非面对面的会议，而是一对一的私下交流，背靠背的方式。（头脑风暴的优点：快速地收集；缺点：不够客观）专家判断比较客观，但返回结果比较慢。
2. 易化技术

4.2 Develop project management plan项目管理计划

整体管理：项目立项（项目章程），项目计划（子计划归总），项目实现，项目监管，项目结束

项目计划：The process of defining, preparing, and coordinating all subsidiary plans and integration them into a comprehensive project management plan.

comprehensive综合的

enterprise environmental factors事业环境因素：

政府或者是工业标准（目标：在一个大组织中，如何提供项目管理效率）

项目管理的知识体系

项目管理的信息系统

组织的结构、文化、管理的实践和工具

基础设施、个性管理

企业文化personnel administration

专家判断：

根据项目的需要，裁剪项目的流程

开发技术和管理细节

组织过程资产organization process asserts：

项目管理计划模板template

变更控制过程

先前项目的项目文档

all the subplan:

scope

schedule

cost

risk

commuincation

procurement采购

HR人力资源

milestons

process improvement

cost baseline

schedule baseline

quality baseline

scope baseline

resource calendar

risk list

input:

project charter

outputs from other processes

enterprise environmental factors

organizational process assets

output: project management plan

4.3 Direct and manage project work指导和管理项目

The process of leading and performing the work defined in th project management plan and implementing approved changes to achieve the project’s objectives.

两件最重要的事：指导项目实施、管理项目变更。

inputs:

project management plan

approved change requests

enterprise environmental factors

organizational process

enterprise environmental factors事业环境因素：

组织、公司或客户的文化或组织结构

基础设施

个性分析：知人善用

stakeholder对于风险的容忍度

outputs：

deliverables可交付物：特点是独特的specific、可验证的、有形的或无形的

work performance data：工作的绩效情况

change request变更的请求

project management plan update

project documents updates

project documents updates：

requirement documentation

project log

risk register风险登记册

stakeholder register相关者登记册

Main tools:

project management system项目管理系统: 包含自动化系统和文档、手动化系统、项目组织

project management information system: 自动化系统支持项目计划、监管和控制

configuration management system 配置管理系统：代码管理系统

change management system 变更管理系统

CCB变更控制委员会: change control board

4.5 Perform integrated change control变更管理

The process of reviewing all change requests; approving changes and managing changes to deliverables, organizational process assets, project documents, and the project management plan; and commuicating their disposition.

inputs：

project management plan

work performance reports

change requesets

enterprise environmental factors

organizational process assets

outputs:

approved change requests

change log

project management plan updates

project documents updates

baseline基准、底线

项目变更流程

start→get change request→PM&Team analyze impact项目经理和团队成员做分析

谁来决定是否变更？CCB：可以有很多不同角色的人来参与的。重大的变更必须由CCB来作决策，不重大的或紧急情况下可以由项目经理决定。

→communicate analyze result to change requestor

→CCB approve

→implement change requeset

→record change implementation status

→distribute new document

4.4 monitor and control project work监管和控制项目工作

要做的工作：时刻看着和baseline有什么差异

4.6 close project or phase关闭项目或阶段

Chapter5. Project Scope Management范围管理

5.1 project scope management项目范围管理

Includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.

计划：收集需求、定义范围、创建WBS

监管控制：理清范围、控制范围

产品范围vs项目范围

项目范围（广义）有时候也隐含包括了产品范围

产品的范围是目的，项目的范围是实现目的的过程

产品的范围变了，项目的范围一定变化；项目的范围变化，产品的范围不一定变化

项目范围管理

inputs:

project management plan项目管理计划

项目章程

事业环境因素

组织过程资产

output:

scope management plan

requirements management plan

备选方案分析alternatives analysis

项目范围管理：如何管理项目范围的流程性方法。不是所有组织都会使用，如果是比较大的组织，这个流程已经定下来，不会为一个新项目再建立新的流程。该流程其实也是一套过程资产。

5.2 Collect Requirement收集需求

inputs: 项目章程、项目管理计划、项目文档、商业分析、背景、和相关方达成的共识agreement、事业环境因素、组织过程资产

tools&techiques: 专家判断、数据收集（头脑风暴、面谈、焦点小组会focus group：针对某一个主题开会、调查问卷、benchmarking标杆对照）、数据分析（文档分析）

思维是连续的、流动的过程，但语言是割裂的。语言是割裂思维的工具。

Facilitated workshops：关注功能性利益相关者

JAD(joint application design): 软件设计

QFD(Quality function development): 质量管理工具

三步骤：1、确定什么是最关键的要素，2、找出支持这些要素的各种方法，3、在项目中创建与关键要素相关的价值

VOC: voice of the customers

客户最重视的是什么，在项目中就要完成。

customer needs vs. requirements

客户的需要是抽象的

需求是具体的，可实施的

Mind Mapping思维导图

affinity diagram亲和图（与头脑风暴相结合）

multicriteria decision analysis多决策分析

group decision making techniques 团体决策：1、unanimity全票通过2、大部分同意（大于50%，奇数人数），3、大部分同意（不需要大于50%），4、独裁dictatorship

需求跟踪矩阵requirement traceability matrix: 很有用，但是维护很麻烦

怎么收集需求？

需求也分为产品需求和项目需求。

产品有三方面的要求：1、技术需求（功能需求），2、性能需求，3、安全性的要求。

项目的需求：项目管理的需求、项目交付的需求

5.3 Define scope定义范围

详细的对于产品和过程的描述，其实就是将收集的需求形成一个文档。

inputs: 风险登记册

tools&techniques: 产品分析（价值分析：将最有用的东西呈现给客户）

价值分析：1、用最小的成本分析价值，2、定义价值，3、用最小的成本实现功能。

不同的客户群体，所需要的价值是不一样的。因此需要用最小的成本，实现最需要的价值。

Scope statement范围说明：对于范围的描述。包括产品范围和项目范围，该文档是定义范围的最重要输出

1、产品范围描述。逐步阐述项目章程和需求文档中描述的产品、服务或结果的特征。

2、可验收标准。在可交付成果被接受之前需要满足的一组条件。

3、可交付成果。执行所需服务的任何独特的、可验证的产品、结果或能力。

4、项目扩展。通常确定哪些内容被排除在项目之外。明确地说明项目范围之外的内容有助于管理项目干系人的期望。

5、约束。影响项目或过程执行的限制因素。

6、假设。在计划过程中被认为是真实的、真实的或确定的，而没有证据或证明的因素。

5.4 Create WBS工作分解结构

WBS: work breakdown structure工作分解结构

subdividing project deliverables and project work into smaller, more manageable components.

把工作范围分成更小的模块，更具体，更可执行的可管理工作包。

树状结构的组织结构方法，也可以写成列表的形式

ex1. 以项目阶段来划分

可能是一个长时间的项目，初始时可能不知道最终有什么的交付物，只知道现阶段的交付物，就细化当前阶段的交付物。

ex2. 以主要的可交付物来划分

按照项目的结构来分解

特点：对于项目组件的面向交付物deliverable-oriented的层级划分，组织和定义了整个项目的范围。

四条原则：

面向交付物原则：不要给后续的实施太多的限制条件。

100%原则：所有的交付物都要写在WBS中，不能遗漏任何一个。

80小时原则：合适的力度是80个小时的工作量，如果是一个人，一天8小时，工作10天。当然还需要看具体项目的大小，定义工作包的大小。

父子原则：可复用的组件只在WBS中写一次。一个父亲可以有两个孩子，一个孩子只属于一个父亲。

WBS主要是作为一个overview，全局的视图，也是一个好的checklist，但是用它做后续的工作比较困难，没有具体的信息，因此产生了WBS dictionary。对于每个work package，都有一个WBS dictionary，把这个WBS的工作描述得更清楚。

工作包的唯一标识“1.1”“1.2”的

WBS的最低层级：工作包work package

5.5 Validate scope范围核实

The process of formalizing acceptance of the completed project deliverable.

由客户发起，从接收的角度，来核实项目的范围。

由项目成员自己核验，称为质量保证quality assurance。

outputs:

可接收的交付物

变更的需求

工作表现的信息

项目相关文档的更新

tools&techniques:

inspection由上至下的、外部的、严格的正式检查或督查

5.6 Control Scope控制范围

基于scope的基线管理scope，既包括产品，也包括项目的范围

与变更控制流程的区别：CCB解决变更的提出，而此处是管理产生变更的源头。

细小的、未察觉的变更，需要我们发现察觉。

范围的蔓延：外部（客户的需求）或内部（项目组内部无知觉的变化）

Chapter6. Project Time Management时间管理

6.1 Schedule management活动日程管理

基于WBS

计划：定义活动、活动排序、建立活动持续时长、开发里程碑

监管控制：里程碑控制

6.2 Define Activities定义活动

inputs:

1. 项目管理计划：①schedule management plan ②scope baseline
2. 事业环境因素
3. 组织过程资产
4. WBS

decomposition分解

分解成一个人或者一个团队可以做的活动。

rolling wave planning渐进明细的计划

可以将WBS、活动定义得更加细化和准确。

工作包是一个名词，activity是动宾结构。

使用WBS定义活动：根据WBS最小的层次work package工作包，来定义活动。一个工作包可以对应一个或多个活动。

实现需求分析的需求文档。

主要的输出：activity list。汇总成一个活动列表

WBS的树状结构是一个全局的视图，活动汇总成列表更加容易查看和管理。id、名字、持续时间、描述、负责人、结果、复核。

一般以人/时为单位，有的大项目也会以人/天为单位。

活动属性activity attributes：

predecessor activity前导活动

successor activity后续活动

lag and leading滞后和提前

logic relationship和前导活动和后续活动的逻辑关系

resource requirement资源需求、人力需求、场地需求

人、机（机器）、料（物料）、法（方法）、环（环境）、测（测试的方法和资源）

6.3 sequence activities活动排序

PDM(precedence diagramming method)

活动是什么？活动和活动之间的逻辑关系怎么定义？

FS(finish-start)一个结束后，另一个才开始

SS(start-start)一个开始后，另一个也开始了

FF(finish-finish)一个结束后，另一个才可以结束

SF(start-finish)一个开始了，另一个才可以结束（不常见）

时差：滞后lag和提前leading

dependency依赖关系/逻辑关系

硬逻辑mandatory dependencies：来自于自然、事物、法律等的强制性的逻辑关系。

软逻辑discretionary dependencies：可以商量、有条件的逻辑关系，没有硬性要求。往往来自于最佳实践的经验。

外部逻辑external dependencis：来自于外部的限制，比如老板的要求。

内部逻辑internal dependencies：来自于内部的规则，比如先编码，再测试。

硬软逻辑和内外逻辑是两种不同的分类，不是互斥的。

microsoft的工具：用来做项目计划

excel表格+甘特图

里程碑milestone：0天，达成目标，不占用历时，作为一个标记

6.4 estimate activity durations建立活动历时

考虑资源、需要的时间

根据经验、WBS来评估

自上而下/自下而上的方法

估算方法：

analogous estimating(top down)类比估算法：根据历史的数据，项目规模。

parametric estimating参数估算法：依据工作效率历史数据，比第一种更准确。

three point estimates三点估算法：恒定生产率=（最高生产率optimistic+最低生产率pessimistic+4倍最可能生产率most likely）/6。标准差：（最好-最差）/6。

没有历史数据依赖时，很可能使用类比估算法，作一个粗略的估算。到了项目后期，数据积累较多时，可以采用参数估算法。

生产率：单位生产时间

持续时间 = 数量*生产率/可能的资源

练习：(30+120+4*60)/6=65

6.5 Develop schedule发展活动历时

schedule计划 vs. duration活动历时

活动历时是时间的多少（不考虑开始和结束日期），计划是从开始日期到结束日期的安排。

输入：

项目管理计划

项目文档：

lessons learned register经验总结列表

project team assignments项目分配的人员信息

resourse calendars资源谁可以用的排期

批准

tools & techniques：

项目活动的网络图

critical path method关键路径法

resource optimization资源优化

输出：

项目计划

milestones charts标注重要的交付结点、外部交互结点：最常用给老板汇报的时候

bar charts用一个bar来表示一个activity，用不同颜色标注进度；或划竖线表示今天；或用百分数来描述：最常用在团队交流，或比较关心详细信息的老板或leader。

project schedule network diagram项目计划网络图：常用在做项目计划时描述项目各个活动之间的逻辑关系。

microsoft project案例

左边是excel表格，右边是自动生成的bar

critical path method关键路径

关键路径：路径上的所有任务都是关键任务，不能delay，一旦delay，整个项目都会delay。相对的是不在关键路径上的，自由度较高的任务。

如何寻找关键路径？

ES：最早开始日期

EF：最早结束日期

DU：持续时间

ID：活动编号

LS：最晚开始日期

LF：最晚结束日期

TF：可以推迟多长时间开始，并不会影响schedule

EF=ES+DU-1

LS=LF-DU+1

ES=Max(EF) + 1

LF=Min(LS) - 1

TF=LS-ES=LF-EF

forward pass：从前往后梳理，计算ES、EF

backward pass：从后往前梳理，计算LF、LS

如果一条路径上的ES和LS、EF和LF相同，它就是关键路径。

一个项目可以有一条或多条关键路径，一条更好。

接下来可以更新活动清单

schedule compression
fast tracking快速跟进：把一些原本是串行的任务并行完成，不顾它们之间的关系。有一定风险，可能两个任务都搞砸了。需要更多的沟通。
crashing增加资源，简短任务历时，尤其是关键路径。要多花钱。

resource leveling
资源的平衡，可能在schedule时忽视了一个资源在一天之内的可用度。要使一个资源在每天的工作时间是比较平衡的。不仅是人，还有机器。做资源的平衡，一般是拉长计划。

Chapter7. Project cost management成本管理

成本的类型：
variable costs可变成本：与用量相关，比如物料。
fixed costs固定成本：不变的成本。
direct costs直接成本：为项目专门做的，直接分配的，比如团队成员的工资，出差费。
indirect costs间接成本：比如专业技术的培训，与项目没有直接关系。
两种分类方式。

7.1 estimate costs成本估算

人和物最终都要换算到货币化的资源（钱）。

输入：项目计划，文档，资源列表，事业环境因素，组织过程资产（包括人工资的价格）

方法技术：专家判断

类比估算

参数估算

三点估算

自底向上

7.2 determine budget决定成本

对估算的质量和精确度有不同的要求

在项目早期或比较难的项目，范围为±50%

在做预算计划时，范围为-10%到+25%

最后的估算，范围为-5%到+10%

成本基线baseline

cost budget的三部分内容：项目所有活动需要完成真正需要花的钱；项目可能有的一些风险的补救措施的钱；项目未知的风险是有可能的，未知风险的准备金

allocate budget

把钱分配到不同的时间里

成本预算的表达方式

budget chart表示每个月的分布

成本曲线

7.3 control cost控制预算（必考内容）

对项目做挣值分析earned value analysis：任务值多少钱。如果只知道在每个时间段内花了多少，不知道是否花销超过，要看挣到的价值，就是完成的任务量。这是做挣值分析的意义。

成本和进度监控以钱为单位

怎么定义任务的完成

完成50%就认为任务完成

EV - 挣到的价值

AC - 实际的花销

PV - 计划的花销

CV = EV-AC 挣值 - 实际花销，（>0表示钱花的效率高；<0表示花超了，效率低）

SV = EV-PV 挣值 - 计划花销，（>0表示超schedule完成工作量；<0表示没有按schedule完成工作量）

CPI = EV/AC 挣值/实际花销（>1 under budget；<1 over budget）

SPI = EV/PV 挣值/计划花销（>1 ahead of schedule；<1 delay）

案例1：

AC = $200K

EV = $100K

PV = $300K

CV = $100K-$200K = -$100K

SV = $100K-$300K = -$200K

CPI = $100K/$200K = 1/2

SPI = $100K/$300K = 1/3

BAC - 一开始给整个项目的定的成本

EAC = BAC/CPI 到今天为止，对项目的估算。已经花销了一部分钱，可能要花更多钱，实际花的钱可能比一开始的预算要多，实际花钱的效率，预估未来要花多少钱。

ETC = EAC - AC 到今天为止，到整个项目完工，要多少钱。

VAC = BAC - EAC 成本的偏差。

EAC的两种计算方法：

EAC = BAC/CPI，这是CPI不变的情况。

或CPI = 1

案例2：

SV = EV - PV = -100, SPI = EV/PV = 1/2

CV = EV - AC = -100, CPI = EV/AC = 1/2

BAC = 500

EAC = BAC/CPI = 500/0.5 = 1000（CPI不变）。或已经花了200完成100，然后500 - 100 = 400，完成400 = 200 + 400 = 600。

ETC = EAC - AC = 1000 - 200 = 800，或600 - 200 = 400。

案例3：

BAC = 6*1000 = 6000

PV = 3*1000 = 3000

AC = 1200+1000+750+500 = 3450

EV = 1000+1000+750+500 = 3250

CV = -200

SV = 250

CPI = 3250/3450=0.942

SPI = 3250/3000 = 1.08

EAC = BAC/CPI = 6000/(3250/3450) = 6369。或BAC - EV = 2750，2750 + 3450=6200。

ETC = EAC - AC = 2919, 或2750。

over budget = 369, ahead schedule

Chapter8. Project Quality Management项目质量管理

不仅是customer的质量，还有其他相关方。

三个活动：质量计划，根据计划管理项目质量，管控项目质量

（更多着眼点是产品和项目本身），（更多着眼于过程）

质量quality vs. grade等级

高的等级和好的质量不一样，低等不是问题，但是质量差是问题

什么是质量好：满足客户对功能和性能的要求。显性要求和隐性要求。

重要的点：

客户满意

预防措施＞检查措施：相对于检查要更重视预防

持续改进（基于PDCA循环）

管理的责任：70%在老板身上，30%在出错者身上

给客户最好的东西

分析最能给我们带来利润的质量提高点：关键质量展开，识别关键点

JIT零库存：没有库存，订了再立刻生产，没有囤积的成本

TQM：每个人都有管理质量的责任，不只是老板

戴明环：

PDCA - plan do check act

ISO9001：2015指导纲要

4.0对组织的要求

5.0对老板的要求

6.0对人的要求（招聘，满足组织研发生产的人）

定期发现问题，解决问题

三个部分

ISO9000的起源是工业迅猛发展的时期，后面又适用于各个行业，但又缺乏针对性。因此只能是一个基础的标准，只是及格。如果连它都达不到，证明研发和生产不可控。

Juran 质量之父

CMMI 比较繁重的标准

5个level

1超级英雄的阶段，依赖于超级英雄

5持续改进阶段，有自我价值需要实现

Lean精益的 SW development 7 principles：消除在生产和研发过程中的浪费

Agile敏捷开发：在质量管理中，把质量和变化前置，每次迭代都做review

8.1 Plan quality management计划质量管理

怎么做质量计划

input:

项目章程

项目管理计划：需求管理计划、风险管理计划、利益干系人管理计划、范围基线

项目文档：假设日志、需求文档、需求轨迹矩阵、风险登记册、相关方登记册

事业环境因素

组织过程资产（主要针对的就是过程，质量管理才“有法可依”）

tools & techniques

专家判断（经验总是重要的）：质量保证、质量控制、质量度量、质量提升、质量体系（比如ISO9000）

cost-benefit analysis收益分析：多条途径的衡量

benchmarking标杆对照：没谱的时候，参照同行业的相似的标杆前进，制定计划

cost of quality(CoQ)：质量是有成本的，对质量不能不投入，但也不能无限制的投入

1. 符合性（一致性）成本：

   预防性成本 - 将质量建造在产品里面，消除浪费（训练、文档过程、设备、一次性做好）

   检验成本 - 测试、检查

2. 不符合性（非一致性）成本

   内部的失效导致的损失 - 重复工作、重新拆解再重做

   外部的失败导致的损失（客户发现的，是最严重的一种成本） - 信任、保质期（替换产品和上门维修）、经济损失

符合性成本应该 < 不符合性成本

RoI Curve：投入产出比曲线。inflection point：在此之前，产出随着投入提升；在此之后，再提升投入，产出的提高不再明显了。

flowcharts流程图：找出潜在的质量问题

output:

质量管理计划应该包含的内容：

1. 该项目使用的质量标准
2. 项目的目标（范围、时间、成本、质量的目标）
3. 投入到质量管理的人员的角色和职责
4. 交付物、工作过程的review（比如计划里大流量、边界值的测试、异常情况的测试是否包含在交付物中）
5. 做什么样的质量管理和控制
6. 使用到什么样的质量工具
7. 项目中主要的过程，是否有裁剪

quality metrics质量量化指标（KPI），衡量质量的好坏：

1. 按时完成的任务的百分比
2. CPI
3. 失效的产品的比例（来自客户）
4. 检测部门每天发现的错误
5. 每个月服务器的总宕机时间
6. 每千行代码里的错误
7. 客户满意度的调查
8. 产品需求被测试的比例（测试覆盖率）：为什么不做百分之百的测试？测试案例太多了，根本没时间做百分之百的测试，而客户的满意度是有限的。只做积累型的测试，每一次的release测试一部分，也没有出现多少次问题。什么是质量的成本？就是始终有一个接受度作为衡量标准。

8.2 Manage quality管理质量

根据quality plan进行实施工作，比如quality in product

check list：

在整个产品的生命周期中，有不同的parse，每个parse有review，每次review都有很多人参加。有质量部门的人检查状态。

check list是一个很有用的工作，有多个条目，做完一个勾一个。

对红色非常敏锐，一般代表高风险

7QC tools（7大质量管理工具）

1. 鱼骨图cause and effect diagram(lshikawa diagram or fishbone diagram)

   出错的时候，找原因：人机料法环测

   多问几个why（一般上限5个），就能找到原因

2. 帕累托图pareto chart/diagram

   是一个直方图，将数据从大到小排序。

   思想指导：80%-20%原则（80%的问题都是20%的原因造成的）。

3. run chart - yearly failure rate年度失败率（重要的产品指标）

   趋势图：比如天气预测、PM2.5。

   有的时候是作为一个目标线，低于target都是符合要求的。

4. control chart控制图

   控制一个工厂生产的流程，对产品作某个指标的检查。正态分布的数值，有一个中间值。在上下限之内波动。

5. scatter diagrams散点图

   两个数据之间存在关联性，通过散点图看出两个数据的关系。比如正相关或负相关的曲线。

6. quality audits质量审计

   design for X

   问题解决的思想方法：

   定义问题、根本原因、生成可能的解决方案、找到最好的解决方案、应用该结局方案、衡量解决方案的效率。

tools & techniques:

statistical sampling统计抽样

8D报告：对问题问5个why，挖到根原因

是否有后续的行动计划？范围、计划的更新？

Chapter9. Project Resource Management项目资源管理

包括了人和物的资源管理

五个重要活动：计划资源管理、建立活动资源、获取资源、建设团队、管理团队、控制资源

识别你要做什么（什么人、设备、物料） - WBS

找到对的人 - 态度、能力、个性（在工作环境下的测试，有压力，和生活环境下可能不一样）

好好地使用你的团队 - RBS(资源分解结构)、OBS(组织分解结构)、RAM(责任分配矩阵)、RACI

RAM把WBS和OBS汇总成一个责任分配矩阵，工作包具体要分配给哪些人做

RACI管理一个任务的责权分配和期待，包括项目团队以外：responsible负责人（一个任务分给一个人负责），accountable管理者，consult顾问，inform被通知者

9.1 plan resource management计划资源管理

计划资源管理：定义怎么估算、获得、管理资源。有一定的计划成果时才能去做（需要WBS）

inputs:

项目章程、项目管理计划（质量管理计划、范围基线）、项目文档（项目日程、需求文档、风险登记册、利益干系人）、事业环境因素、组织过程资产

tools:

专家判断、数据准备、组织学说、会议

output:

资源计划、项目团队结构

资源计划包括但不限于：

识别所需要的资源

获取资源

责权（角色、权限、责任、能力）

项目团队结构

项目团队资源管理

训练

团队提升

资源控制

奖惩计划

9.2 estimate activity resources建立活动资源

放在时间管理，会比较现实（在前面讲过）

9.3 acquire resourse获取资源

获取团队成员、设备、物料、供应商和其他资源

input:

项目管理计划（资源管理计划、采购管理计划、花销的基线）、项目文档（项目日程、资源日历、资源需求、利益干系人登记册）

resource histogram资源直方图：一种是：在不同时期，对不同资源的描述；一种是在不同时间要完成多少工作任务

tools:

预分配pre-assignment：项目不需要项目经理来找，而是投标，比如需要资质认证的某方面的专家。好处：满足这个条件才能往下走，是一个资源；坏处：预分配的人比较难管。

谈判negotiation：获取需要的人和物，怎么在资源池中拿到想要的人和物。

招聘acquisition：怎么从外部招募？JD(job description)

虚拟团队virtual team：可以把对机器和物质的使用做到最大化。比如跨国团队。最大的缺点：沟通不方便，有时差；没有见过面，没有很好的归属感。改进方式：设计一个logo、slogen；建立联系列表（通讯录）；设计制服。

9.4 develop team发展团队

改善团队环境、增强团队交互

管理人的软技能

什么是team？一小群聚集在一起的人，全技能的组织；有一个共同目标；有一些方法让他们对自己做的事情负责。

工具和方法：

colocation把团队成员放在同一个物理地点。有比较好的沟通效率。

虚拟团队

沟通工具：视频、电话交流、邮箱、通讯工具

培训：线上/线下

什么叫做冲突？

对理念的不同理解+缺少对对方的认知+不愿意寻找共同的原则

冲突可能是有益的：风险和机遇并存，让不同观点爆发的契机

冲突是不可避免的。

冲突最好是由冲突各方一起来解决的。

为什么会产生冲突？

人的大脑像是一个计算机程序，一个程序是不会自动改变的，但是如果进行新的编程，新的程序需要个人的选择，有意愿的改变。

没有对错，只有不同

产生冲突的方面：

项目初期：优先级、资源；中期：管理过程、技术观点、个性；后期：项目进度

解决冲突的几种方式：

1. forcing强迫其中一方妥协，产生win-lose结果，解决问题但没有维护关系
2. withdrawing/avoiding回避，最不好的一种方式，没有解决问题
3. smoothing/accommodating强调共同点，维护了关系，也没有解决问题
4. collaborating协商，最好的解决问题的方式

influence影响力：以力服人，以才服人，以德服人

影响力是靠引发别人自身的需求来解决问题或寻得认同

认可recognition和奖励reward机制

马斯洛的需求层次说：人的需求从低到高分成五个层次，只有低层次的需求得到满足，才会追求高层次的需求。

生存需求→安全和保护需求→爱和被需要的需求→自尊→自我价值实现的需求

考虑团队的需求

四种人格personality：

1. 项目=结果，全局导向
2. 项目=和别人搞好关系的地方，团队关系导向
3. 项目=活动，细节导向，只关注细节的人，要提醒他们关注全局
4. 挑战者：项目=挑战别人的地方，问题导向，要关注自己而不是别人

六种人格：

harmonizer：热情、温暖的、敏感的

rebel叛逆：天马行空、活力的

workaholic：严谨的、有责任心的

promoter：灵活、有说服力、有个人魅力

dreamer：冷静、有想象力

persister：奉献的、善于观察的

9.5 manage team管理团队

维持团队高速运转、解决问题、提高表现的过程。

inputs:

tools: emotional intelligenceq情商管理

outputs:

Project manager power:

1. formal: 正式的授权的权力
2. penalty: 惩罚的权力
3. reward: 奖励的权力
4. expert: 专家权力
5. reference: 赞誉和名声

Tuckman ladder model塔克曼模型

团队的生命周期：

1. forming: 刚刚成立团队，一切都是新鲜的，感到好奇。项目经理要有指导力，要制定很多规则，回答很多疑问。
2. storming: 有冲突和争吵，团队变得不稳定。项目经理让团队成员讲话，多听多了解，有碰撞但要控制边界，要充满希望不要惊慌。
3. norming: 一切都比较规矩，形成一些规则。项目经理要创造更多社交机会来磨合提高。
4. performing: 在最高效率的状态下工作，比较成熟。项目经理要使成员保持动力，协调任务导向和团队导向的人，
5. adjourning: 完成任务，解散团队/有人退出，新人加入。要拿出结果，回顾，进行庆祝。

四种leader：

support type支持型：一起讨论，一起决定

coach type教练型：一起讨论，但我决定

authorization type授权型：你决定

instruction type指导型：我决定

对于一个职场新人，应该采用coach或instruction；对于一个职场老人，应该采用support或authorization

9.6 control resources资源控制

要监控实际和计划的资源的偏差（包括人和财务），并进行一些改进措施

Chapter10. Project Communication Management沟通管理

五个活动

适时地和正确地处理项目信息，生成、收集、分配、存储、检索、报废信息。

项目经理花了大量时间（70%-85%）在沟通。

沟通的活动的维度：

内部和外部

正式和非正式：往往是非正式的更重要，会上的决定一般是在会下商讨好了，才能通过。

vertical纵向和hierarchical横向：从上到下，从下到上，平级的沟通

official官宣和unofficial小道消息

written书面和oral口头

verbal语言和non-verbal非语言

10.1 Plan communications management计划沟通管理

沟通的动作，基于利益干系人想要的信息和需要的程度。

项目经理的第一沟通方：我们的客户、利益干系人、资源经理、团队成员。其他沟通方：其他的团队经理，其他的团队成员，其他的利益干系人。

沟通渠道的增长，随着人数的增长迅速增长：N(N-1)/2

信息发送者→信息接收者，中间有noise

发送者要发送清晰完整的信息，接受者保证信息接收是完整、正确的

沟通的目的：通知、动作需求、提问

语气不要过于强势，不要全部大写英文

选择一个正确的沟通媒介

选择一个正确的沟通时间

积极的倾听反馈、有效沟通

简洁的语言，不要废话

voice/tone声音和语调38%

gesture姿态55%

content内容7%

三种交流方法：

interactive communication有交互的，比如会议、电话、视频

push communication单向传达，比如通知、信件、邮件、传真

pull communication单向接收，比如网上学习

交流管理计划

10.2 Manage Communications管理沟通

根据计划实施一系列的沟通

有效的会议effective meeting

计划和准备会议：定义时间和参会者，清晰的讨论目标，创建一个议程

坚持计划：准时开始、准时结束

好的追踪：从参与者获得feedback

10.3 control communications控制交流

Chapter11. Project Stakeholder Management利益干系人管理

利益干系人是否满意：1、我提供了什么；2、他期待了什么

管理期待、降低期待

11.1 identify stakeholder识别相关方

会影响项目的人，都是项目相关方。他们对我们的项目有什么影响、有什么兴趣，都要记录下来，形成一个list，这是识别利益干系人的方式。

横坐标interest，纵坐标power

GroupA: 对项目没什么兴趣，也对项目没什么影响。可以花最少量的时间来管理。比如一些监控者。

GroupB: 对项目很有兴趣，但对项目没什么影响。比如其他项目的经理，可以花多一点时间，定期告知他项目的一些信息。

GroupC: 对项目没什么兴趣，但对项目有影响。比如公司CEO，不必时刻告知项目信息，但每次汇报都要使他们满意。否则可以随时砍掉项目。

GroupD: 对项目很有兴趣，对项目影响很大。比如投资方，或者客户，时刻告知项目状态，并且使他们对项目状态满意，要花比较多精力管理。

利益干系人登记册stakeholder register

识别的信息：名称、组织的地址、联系方式、项目角色

评估的信息：主要需求、预期、可能的产出

利益干系人的分类：内外部、级别的关系

11.2 plan stakeholder management 规划利益干系人管理

相关方的绑定状况的分析矩阵stakeholders engagement assessment matrix

c-current engagement现阶段的态度

d-desired engagement期望的态度

纵：干系人列表

横：干系人的状态（unaware一无所知，resistant反对，netural中立，supportive支持，leading领导）

干系人管理计划：

关键利益干系人的需求和当前的态度

变更干系人的范围和影响

识别干系人之间可能的冲突关系

当前项目阶段干系人的沟通需求

提供给干系人的信息，包括语言，格式，内容详细的程度

发布该信息的原因和预期的影响

时间和频度：更新项目信息，类似月报

管理干系人的期望和对项目的支持的程度

11.3 manage stakeholder engagement管理利益干系人

ground rules : 最低的，必须遵循的，有言在先的规则（比如会议中不能迟到早退）

包含的活动：

在合适的阶段把相关方引入进来

管理相关方的期望通过协商和交流

相关方有什么潜在风险（不确定性）

理清和解决问题

11.4 control stakeholder engagement 监控管理相关方

看performance和baseline有什么差异，根据这个差异，进行调整，比如更新计划。

资源、沟通和干系人在实际工作中应该是一起管理的。

Chapter12. Project Risk Management风险管理

风险管理：非常重要，决定项目的成败

风险：不确定性，一旦发生，对至少一个项目目标产生影响（范围、成本、人、质量）

目标：增加好的可能性，减少坏的可能性。（机遇和挑战）

概念：

uncertainty不确定性：影响到项目成功

risk averse风险厌恶者：不愿意承担风险

risk appetites风险爱好者：为了获取高利益，愿意为风险承担一定责任

risk tolerance对于风险可以接受的边界：有的风险可以接受，有的风险不可以接受

risk thresholds风险临界点：风险从低到高，刚开始可以接受，到某个临界点以后，就变得不能接受了

风险因子

1. 风险会发生的概率

2. 一旦发生会有什么影响产生

3. 风险发生的预期时间

4. 风险发生的频度

风险管理的主要活动：计划风险管理（可能在公司里本来有一套风险管理流程，按照流程就可以了）、识别风险（风险登记册）、定性的风险分析（按优先级排序的风险列表）、定量的分析风险（得到了一个风险的价值，不要求对所有风险都做）、规划风险的应对方法、实施风险应对方法、监控和管理风险

ISO9000对于风险管理的流程

12.1 plan risk management风险管理计划

可以对所有风险做一个量化的分析，也可以在流程里裁减掉定量分析的活动

风险的分类：在识别风险时非常有用（实现、销售、架构、开发等等）

可以从收益和损失方面分析，定义分析的分类（也有不属于收益和损失，比如人身安全方面的风险）

风险管理计划描述如何在项目中构建和执行风险管理：风险策略、方法论、角色和职责、预算、时间、风险种类、定义风险可能和营销、干系人对风险的容忍度、用什么方式来记录和跟踪风险、可能性和影响矩阵

对于不同级别的风险的可能性和影响定义

RBS(risk breakdown structure)风险分解结构

technical risk技术风险

management risk管理风险

commercial risk经济风险

external risk外部风险

12.2 identify risks识别风险

tools: 数据收集（头脑风暴、以前的经验总结checklists、访谈），数据分析

SWOT分析：把风险按照内外部、积极消极分成四个象限

积极的、内部的：长处Strength

消极的、内部的：短处Weakness

积极的、外部的：机遇Opportunity

消极的、外部的：挑战Threat

如何描述风险？

要理清的是什么是原因、什么是影响

两种风险说明的方法：

IF - THEN的方法（“如果分包商没有以所需的可靠性交付软件

等级，那么产品可能达不到性能规格”）

CONDITION - CONSEQUENCE的方法（更常用，比较清晰）

风险登记册risk register

对于风险的潜在应对措施

对组织过程资产的改进

12.3 perform qualitative risk analysis 对于风险的定性分析

probability-impact matrix可能性-影响矩阵

绿色格子：不太需要管理的（影响很大，但是可能性很小）

黄色格子：普通的风险

红色格子：高度警惕，保持重视

风险登记册

priority：填写层级的分数

remark：备注的信息

12.4 perform quantitative risk analysis定量分析

定量：转化成了钱

投资决定的分析：

EMV(expected monetary value) = probability可能性 × impact价值

12.5 plan risk responses应对风险

定义一些action，提高好的影响，降低不好的影响

风险应对的方式：

1. avoid the risks：发现存在风险时，修改项目计划直接消除风险
2. eliminate source of the risks：在源头改善风险，使它不会引入风险
3. transfer the risks：转移风险（花钱让承包方来承担风险）
4. mitigate缓和 the risks：降低风险发生的可能性
5. accept the risks：接受风险，采取一些预案措施，让损失更小一点

12.6 control risks控制和管理风险

实施风险应对计划的过程，跟踪已识别的风险，监控剩余风险，

识别新的风险，并评估整个项目的风险过程有效性。

风险仪表盘的案例

Chapter13. Project Procurement Management采购管理

三个活动：采购计划、实施采购、控制采购

计划采购：what、when、how

seller: 卖方，buyer: 买方

实施采购：获取信息、价目等信息，选择卖方

控制采购：管理合同

13.1 plan procurement management计划采购

tools:

make-or-buy analysis: 自制或者采购分析

关键的或包含潜在专利的，就适合自制；不符合项目战略的，就适合采购。

外包：租还是买？

采购的两种形式：公司集中采购、部门分散采购。

集中采购：优点是可以便宜一点，缺点是需要的周期很长。

分散采购：优点是需要周期短，缺点是价格高。

contract type合同分类

fixed-price contracts固定总价FP：范围也固定，风险较小，范围非常明确。

cost-reimbursable contracts成本报销：

1. CPPC: 成本+一定比例的费用，花得越多，报销越多。需要买方深度介入活动，对买方来说风险较高。
2. CPFF: 成本+固定费用，范围不明确。
3. CPIF: 成本+奖励费用，范围不明确。成本花得越少，奖励越多。鼓励节约成本。

time and material contracts时间物料合同T&M：单价确定，按照单价来定总价格。范围不明确，缺少项目管理技巧。

output:

采购如何与其他项目方面协调，如项目进度制定和控制过程

主要采购活动时间表

用于管理合同的采购指标

与采购相关的干系人角色和职责，包括执行组织拥有采购部门时项目团队的权力和约束

可能影响计划采购的限制和假设

支付的法定管辖权和支付所用的货币

决定是否使用独立核算的估计，以及是否需要将这些估计作为评价标准

风险管理问题，包括确定绩效担保或保险合同的要求，以减轻某些形式的项目风险

如果有预审合格的卖方就使用

评估的指标：技术能力和供货能力，产品的成本和生命周期的成本，提交的日期，相关经验，所需要采购的方案的描述，公司团队里面有没有能力很强的人，财务稳定，公司的管理能力

案例：CPIF，目标成本210000，目标小费25000，目标花费一共235000，如果有节省20%给卖方，80%给买方。实际上成本200000。问最后的小费和花费。

210000-200000=10000

10000×20%=2000

25000+2000=27000

最后花费：200000+27000=227000

13.2 conduct procurement management实施采购

得到卖方的反馈，选择采购方，实施合同。

1. weighting system权重系统
2. independent esimate独立评估，两方审核（定期去看生产研发的过程）或三方审核（委托第三方审核）
3. screening systems扫描系统，去把不符合最低要求的采购方筛选出去
4. past performance history了解历史的表现

协商的目标：获得一个公平合理的价格，与采购方发展友好关系

协商的内容：范围、日程、价格以及付款方式、职责、权力、适用的法律、技术和商业的管理方式、合同筹资

13.3 control procurement management监控采购

管理采购关系，监督合同履行情况，并酌情作出变更和纠正的过程