标签：
项目管理课堂笔记
1、项目的定义
项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的活动。
2、项目与日常运作的区别
项目是一次性的，日常运作是重复进行的，
项目是以目标为导向的，日常运作是通过效率和有效性体现的，
项目是通过项目经理及其团队工作完成的，而日常运作是职能式的线性管理；
项目存在大量的变更管理，而日常运作则基本保持连贯性的。
3、项目的特征
有明确的目标性
明确的时限性
资源成本的约束性
项目的不确定性
唯一性(一次性)
4、项目管理的定义
使项目能够按照预定的成本、进度、质量顺利完成并让所有干系人得到满意，而对成本、人员、进度、质量、风险等进行分析和管理的活动。
5、项目管理框架
（1）五大标准化过程组
启动阶段
项目的可行性分析、立项、招投标、合同签署。
计划阶段
范围定义、进度安排、资源计划、成本估计、质量保证计划、风险计划、实施计划等。
实施及控制阶段
项目实施、进度控制、费用控制、质量控制、变更控制等。
结束阶段
范围确认、质量验收、费用结算与审计、项目资料验收、项目交接与清算、项目审计与评估、项目总结等。
（2）十大知识领域
项目整合管理
项目范围管理
项目时间管理
项目成本管理
项目质量管理
项目人力资源管理
项目沟通管理
项目风险管理
项目采购管理
项目干系人管理
（3）四十七个过程
1、初始项目分析
（1）项目类型 ：合同项目、内部项目
（2）初始化项目分析
项目可行性分析
根据市场、技术、人员等各资源分析项目的可行性，对分析结果进行认证讨论。
?项目范围分析
确定项目的功能模块、边界范围等。
?项目干系人分析
分析确定项目相关人员，包括：项目发起人、项目开发人员、测试人员、维护人员、客户等。
2、生存期模型
（1）瀑布模型
瀑布模型（Waterfall Model） 是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。
（2）原型模型
原型模型即样品模型，先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。
原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应。
（3）增量模型
增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。
3、项目立项
（1）项目经理的角色
项目组织的领导者
项目组织的管理者
项目组织的决策者
项目组织的分析者
项目组织的计划者
项目组织的控制者
项目组织的组织者
项目组织的评价者
项目组织的协调者
（2）项目经理的责任
项目计划
组织实施
项目控制
（3）项目立项的相关文档
相关文档：项目章程、立项申请报告、立项评审报告
通常由公司PMO(项目管理办公室)组织立项会，对项目的调研、范围、项目经理等进行确定授权，评审，最后要有评审报告。
1、范围计划
（1）什么是项目范围管理
项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。它包括用以保证项目能按要求的范围完成所涉及的所有过程，包括：确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实等。
（2）WBS
工作分解结构（Work Breakdown Structure，简称WBS）就是把一个项目按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。
即：项目→任务→工作→日常活动
工作分解结构以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。
WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。
（3）什么是工作包
WBS的最低层次的项目可交付成果称为工作包(Work Package)，具有以下特点：
工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule)，即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化
（4）任务分解原则
将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成；
每个任务原则上要求分解到不能再细分为止；
日常活动要对应到人、时间和资金投入
在我们日常管理项目时，要学会分解任务，只有将任务分解得足够细，足够明了，才能统筹全局，安排人力和财力资源，把握项目的进度。
2、进度计划
（1）什么是进度管理
进度是对执行的活动和里程碑制定的工作计划日期表
进度管理是为了确保项目按期完成所需要的过程
按时完成项目是项目经理最大的挑战之一
时间是项目规划中灵活性最小的因素
进度问题是项目冲突的主要原因，尤其在项目的后期。
（2）进度计划管理过程
活动定义
确定为完成项目的各个交付成果所必须进行的诸项具体活动
活动排序
确定任务依赖、前置任务、里程碑（里程碑显示项目进展中的重大工作完成）
活动历时估计
每个任务的历时估计、项目总历时估计，可采用定额算法、经验算法。
任务资源估计
每个任务需要的资源类型和数量有一定的考虑，这些资源包括，人力资源，设备资源，以及其它资料资源
（3）关键路径
关键路径是项目计划中最长的路线。它决定了项目的总实耗时间。项目经理必须把注意力集中于那些优先等级最高的任务，确保它们准时完成，关键路径上的任何活动的推迟将使整个项目推迟。向关键路径要时间，向非关键路径要资源。所以在进行项目操作的时候确定关键路径并进行有效的管理是至关重要的。
（4）里程碑
在进度时间表上设立一些重要的时间检查点，这样一来，就可以在项目执行过程中利用这些重要的时间检查点来对项目的进度进行检查和控制。这些重要的时间检查点被称作项目的里程碑
3、成本计划
（1）资源计划编制:
确定项目需要的资源种类和数量，参考计划书
（2）成本估算：
编制一个为完成项目各活动所需要的资源成本的近似估算
（3）软件项目规模
软件项目规模即工作量，是从软件项目范围中抽出的软件功能，然后确定每个软件功能所必须执行的一系列软件工程任务
包括：软件规划，软件管理，需求，设计，编码，测试，以及后期的维护等任务。
计量单位：
LOC(Loc of Code)
源代码程序长度的测量，单位K代码行
FP(Function Point)
用系统的功能数量来测量
人月
人天
人年
4、质量计划
（1）质量管理过程
质量的多种定义 符合目的或者用途 用户的感觉就是质量 符合顾客在其合理价格下对产品的要求 产品或者服务满足明确和隐含需要能力的性能特性的总体
（2）质量保证 QA
确定项目应达到的质量标准
决定如何满足质量标准的计划安排和方法
通过评价项目整体绩效,建立对质量要求的信任
提供项目和产品可视化的管理报告
例如：《总体设计规格》质量审计
这个任务本身并不能提高产品的质量
一般由质量保证部门人员实施
（3）代码质量活动
静态分析
不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。也称为静态测试技术。
?动态测试(Test)
单元测试、集成测试、系统测试
?缺陷追踪
使用项目管理工具(如ClearQuest)跟踪缺陷解决程度
（4）质量计划文档
5、人力资源计划
（1）组织结构主要类型
职能型
优点：
可以充分发挥职能部门的资源集中优势
部门的专家可以同时为部门内不同项目使用
便于相互交流 , 相互支援
可以随时增派人员
可以将项目和本部门的职能工作融为一体
缺点:
项目和部门利益发生冲突，职能部门更重视本部门的目标,会忽视项目目标
资源平衡会出现问题
权利分割不利于各个职能部门的交流和团结协作
行政隶属关系使得项目经理没有充分的权利
?项目型
优点：
项目经理对项目可以负全责
项目目标单一，可以以项目为中心,有利于项目顺利进行
避免多重领导
组织结构简单，交流简单,快速
缺点：
资源不能共享
各个独立的项目处于相对封闭状态,不利于公司政策的贯彻
对项目组织的成员缺少一种事业上的连续性和安全感
项目组织之间处于分割状态,缺少信息交流
?矩阵型
优点：
专职的项目经理负责整个项目 , 以项目为中心,
公司的多个项目可以共享各个职能部门的资源
即利于项目目标的实现,又利于公司目标方针的贯彻
项目成员的顾虑减少了
缺点：
容易引起职能经理和项目经理权力的冲突
资源共享也能引起项目之间的冲突
项目成员有多头领导
（2）人员管理计划
人员管理计划描述了项目团队的组织结构，团队成员及角色、成员加入到团队和离开团队的时间、人员培训计划等。作为项目计划一部分，详细程度因项目而异。
6、沟通计划
（1）沟通计划基本原则
及时性 准确性 完整性 可理解性
（2）沟通方式
书面沟通和口头沟通
语言沟通和非语言沟通
正式沟通和非正式沟通
单向沟通和双向沟通
网络沟通
7、风险计划
（1）风险的定义
损失发生的不确定性；
对潜在的，未来可能发生损害的一种度量
（2）风险三要素
一个事件
事件发生的概率
事件的影响
（3）风险类型
预测角度
已知风险－Known known
可预测风险-Known unknown
不可预测风险-unknown unknown
范围角度
项目风险
技术风险
商业风险
（4）风险管理四个过程
（5）风险识别领域
产品规模
商业影响
客户相关
过程定义
开发技术
开发环境
人员数目及经验
（6）风险识别方法
头脑风暴法
情景分析法
面谈法
风险条目检查表
（7）风险评估
确定风险发生概率的估计和评价，项目风险后果严重程度的估计和评价，项目风险影响范围的分析和评价，以及对于项目风险发生时间的估计和评价。
风险概率值：
没有可能（0）
确定（1）
风险概率度量：
高、中、低
极高、高、中、低、极低
不可能，不一定，可能和极可能
等等
风险后果
风险影响项目目标的严重程度
从无影响到无穷大
风险后果度量
高、中、低
极高、高、中、低、极低
灾难，严重，轻微，可忽略
等等
（8）风险措施
回避风险
对所有可能发生的风险尽可能的规避，采取主动放弃或者拒绝使用导致风险的方案。例如放弃采用新技术
转移风险
为了避免承担风险损失，有意识将损失或与损失有关的财务后果转嫁出去的方法:例如出售、分包
损失控制
损失预防、损失抑制
自留风险
由项目组织自己承担风险事故所致损失的措施
1、项目实施与控制
2、配置管理
（1）配置管理定义
记录软件产品的演化过程。
确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置。
最终保证软件产品的完整性、一致性、追溯性、可控性。
（2）配置管理作用
版本管理
变更管理
（3）配置项
软件配置项是项目需定义其受控于软件配置管理的款项。
系统规格说明书
软件需求规格说明书
设计规格说明书
源代码
测试规格说明书
等
（4）配置管理委员会
配置项标识、跟踪
配置管理环境建立
变更管理
配置状态统计
配置管理计划
3、需求分析
需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书
需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。
4、系统设计
（1）概要设计
（2）详细设计
5、系统开发
6、系统测试
（1）单元测试
（2）集成测试
（3）系统测试
1.制定结束计划
项目计划的一部分
与客户一同评审项目结束计划
细化并实施项目结束计划
2.完成收尾工作
范围确认
项目验收
费用结算
合同终结
3.项目结束评审
是否实现项目目标
是否遵循项目进度
是否在预算成本内完成项目
项目进度过程中出现的突发问题以及解决措施是否合适，问题是否得到解决
从该项目的实践中可以得到哪些经验和教训
4.项目总结
总结成功的经验和失败的教训
软件项目历程文件
将项目中的有用信息进行总结分类，放入信息库，它是软件项目记录的资料。
它对将来的项目是有用的，并从中提取一般教训
标签：
原文地址：http://blog.csdn.net/opopopwqwqwq/article/details/51724347
