(六)项目规划时相关概要(68)

 一.  范围计划
1 ) . 项目范围 :  指项目应该包括什么和不应该包括什么进行相应的定义和控制。
1.1 目标 : 用以保证项目能按要求的范围完成所涉及的所有过程有序进行 !
1.2 所包含过程 : 确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实 2 ) . WBS任务分解  :

1.1 基本概念 :                                 指 : 工作分解结构（Work Breakdown Structure，简称WBS）就是把一个项目按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再
把一项项工作分配到每个人的日常活动中，直到分解不下去为止。
1.2 详解 : 
            　工作分解结构以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。

        小结 :  
          1.  项目→任务→工作→日常活动                   2.WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。    1.3 分解结构

1.4 工作包  : WBS的最低层次的项目可交付成果称为工作包(Work Package)

    特点 : 
•工作包可以分配给另一位项目经理进行计划和执行。 
•工作包可以通过子项目的方式进一步分解为子项目的WBS。
•工作包可以在制定项目进度
4000
计划时，进一步分解为活动。 
•工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时，称为委托包(Commitment Package)。

    注意 : 
　 工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule)，即任何工作包的完成时间应当不超过80小时。
    在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。

1.5 任务分解原则
1、将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成；
2、每个任务原则上要求分解到不能再细分为止；
3、日常活动要对应到人、时间和资金投入

                  1.5 任务分解方法
1、 采用树状结构进行分解    
2、 以团队为中心，自上而下与自下而上的充分沟通，一对一个别交流与讨论，分解单项工作。                   1.5 任务分解标准
1、 分解后的活动结构清晰，从树根到树叶，一目了然，尽量避免盘根错节；
2、  逻辑上形成一个大的活动，集成了所有的关键因素包含临时的里程碑和监控点，所有活动全部定义清楚，要细化到人、时间和资金投入。
1.6 实例
 

小结 : 在我们日常管理项目时，要学会分解任务，只有将任务分解得足够细，足够明了，才能统筹全局，安排人力和财力资源，把握项目的进度。

 二. 进度计划

1 ) . 基本概念 : 
1.1 进度是对执行的活动和里程碑制定的工作计划日期表
1.2 进度管理是为了确保项目如期保质保量的完成任务交付结果的一个过程
             注意 : 
1.3时间是项目规划中灵活性最小的因素,要严格把控
1.4进度问题是项目冲突的主要原因，尤其在项目的后期。

2 ) . 进度计划管理过程
2.1    活动定义 :           确定为完成项目的各个交付成果所必须进行的诸项具体活动
2.2    活动排序 :          确定任务依赖、前置任务、里程碑（里程碑显示项目进展中的重大工作完成）
2.3     活动历时估计  :  每个任务的历时估计、项目总历时估计，可采用定额算法、经验算法。
2.4    任务资源估计  :   每个任务需要的资源类型和数量有一定的考虑，这些资源包括，人力资源，设备资源，以及其它资料资源

3 ) .  关键路径与里程碑
                        3.1关键路径  ; 指可达成任务所需走的路径,向关键路径把控时间,向非关键路径把控资源,才能对项目进行有效管理,
                                             关键路径上的任务是优先等级最高的任务,决定了项目总体耗时
                       3.2 里程碑   :  也就是重要检查点,对项目进度进行实时监测,时间资源进行实时控制,问题进行实时反馈项目,从而达到里程碑式的效果
4 ) . 制定MPP
4.1 使用MPP工具制定进度计划。     小结 :  
          1.  参考：软件项目计划.mpp                  
三.  成本计划

1 ) .   核心点 : 
1.1 资源计划编制  :  确定项目需要的资源种类及数量，参考计划书
1.2  成本估算：       编制为完成项目各活动所需资源成本的近似估算    
2 ) .  软件项目规模 :  也就是,工作量,抽取出来是从软件项目范围中 抽出的软件功能,从而确定每一个软件功能所必须执行的一系列软件工程任务
               2.1  任务 包括 :    软件管理,软件规划,需求设计,编码开发,测试运营,后期维护等任务
3 ) . 规模的单位  
3.1 LOC(Line of Code)   源代码程序长度的测量，单位K代码行
3.2 FP(Function Point)  用系统的功能数量来测量
3.3 人月
3.4 人天
3.5 人年
4 ) .  软件的规模和成本的关系
4.1 规模(指量,也指功能项)是成本的主要因素,是成本估算的基础
4.2 有了规模便可确定成本
5 ) .  估算的注意点  : 5.1  算法有误差
5.2  经验(历史数据)很重要
5.3  切记不要太迷信数学模型
6 ) .  成本估算  :
6.1 直接成本 :  具体项目相关成本
6.2 间接成本 : 不能具体到某个项目中的成本，可以分摊到各个具体项目中的成本  例子 : 培训、房租水电、员工福利、市场费用、管理费、其他等等
7 ) .  成本的单位 :  人民币 ,美元             
 
四. 质量计划
1 ) .  质量定义 : 
1.1   质量是满足要求的程度,包括符合规定的要求和满足顾客的需求
1.2  软件质量是软件满足明确说明或者隐含的需求的程度
明确说明 : 查询功能
隐含说明 : 查询速度
 
2 ) .   质量检验 方式 : 
2.1  符合目的或者用途(是否解决需求)
2.2  用户体验就是质量
2.3  是否符合顾客在其合理价格下对产品的要求
2.4  产品或者服务满足明确和隐含需要能力的性能特征的总体(是否解决痛点)
3 ) .   质量的重要性
3.1 软件危机的主要矛盾
3.2 低质量的软件就像定时炸弹
3.3 低质量的产品,增加成本
3.4 质量是生命也是信誉
4 ) .  质量的管理过程 : 

5 ) .  质量保证方式 :
5.1  确定项目应达到的质量标准
5.2  决定如何满足质量标准的计划安排和方法
5.3  通过评价项目整体绩效,建立对质量要求的信任
5.4  提供项目和产品可视化的管理报告 :例子 <总体设计规格>质量审计
5.5 任务本身并不能提高产品质量,应由质量保证部门人员实施 
6 ) .代码质量活动 :6.1  静态分析 : 通过检查和阅读源代码等手段来发现错误并评估代码质量的软件测试技术,而不实际运行程序的方式称为 静态测试技术
6.2 动态测试(Test) : 单元测试,集成测试,系统测试 
6.3 缺陷追踪 : 使用项目管理工具(例 : ClearQuest)跟踪缺陷解决程度  

小结 :  
          1.  参考：质量计划文档 : 参考项目计划书
 

 五. 人力资源计划

1 ) .   组织结构的主要类型  
1.1 职能型
1.2 项目型
1.3 矩阵型 2 ) .  职能型

2.1  优点 : 
2.1.1 可以充分发挥职能部门的资源集中优势
2.1.2 部门的专家可以同时为部门内不同项目使用
2.1.3 便于相互交流,相互支援
2.1.4 可以随时增派人员
2.1.5  可以将项目和本部门的职能功能融为一体
2.2  缺点 : 
2.2.1 项目和部门利益发生冲突,职能部门更重视本部门的目标,忽视项目目标
2.2.2 资源平衡会出现问题
2.2.3 权利分割不利于各个职能部门的交流和团结合作
2.2.4 行政隶属关系使项目经理没有充分的权利
 3 ) .  项目型 

3.1  优点
3.1.1 项目经理可以负全责
3.1.2  项目目标单一,可以以项目为中心,有利于项目顺利进行
3.1.3 避免多重领导
3.1.4 组织架构简单,交流简单,快速
3.2 缺点
3.2.1 资源不能共享
3.2.2 各个独立的项目处于相对封闭状态,不利于公司政策的贯彻
3.2.3 对项目组织的成员缺少一种事业上的连续性和安全感
3.2.4 项目组织之间处于分割状态,缺少信息交流 

4 ) .矩阵型 

4.1  优点 : 
4.1.1 专职的项目经理负责整个项目,以项目为中心
4.1.2 公司的多个项目可以共享各个职能部门的资源
4.1.3 即利于项目目标的实现,又利于公司目标方针的贯彻
4.1.4 项目成员的顾虑减少了
4.2  缺点 : 
4.2.1 容易引起职能经理与项目经理权利的冲突
4.2.2 资源共享也能引起项目之间的冲突
4.2.3 项目成员有多头领导 
5 ) .   人员管理计划

5.1 指描述了项目团队的组织结构，团队成员及角色、成员加入到团队和离开团队的时间、人员培训计划等,是项目计划的一部门,详细程度因项目而异!
  小结 :  
          1.  参考 : 项目计划书         
 六.  沟通计划

1 ) .   沟通的基本原则 : 
1.1 及时性
1.2 准确性
1.3 完整性
1.4 可理解性
2 ) .  沟通方式 : 

2.1 书面沟通和口头沟通
2.2 语言沟通和非语言沟通
2.3 正式沟通和非正式沟通
2.4 单向沟通和双向沟通
2.5 网络沟通

3 ) .沟通计划编制   

3.1 沟通的需求分类
3.2 沟通的内容
3.3 沟通的方法
3.4 沟通职责3.5 沟通进度
3.6 沟通计划维护
 
 小结 :  
          1.  参考 : 参考项目计划书                     六.  风险计划

1 ) .  基本概念 : 
1.1  风险的定义 :  
1.1.1 损失发生的不确定性
1.1.2 对潜在的,未来可能发生损害的一种度量
1.2 风险的三要素 : 
1.2.1 一个事件
1.2.2  事件发生的概率 
1.2.3  事件的影响 2 ) .  风险类型 : 

2.1  预测角度
2.1.1 已知风险 - Known Known
2.1.2 可预测风险  - Known UnKnown
2.1.3 不可预测风险  - unKnown  unKnown
2.2  范围角度
2.2.1  技术风险
2.2.2  项目 风险
2.2.3  商业风险 3 ) . 风险管理的四个过程 : 
  
 

4 ) .  风险识别领域 : 

4.1  产品规模
4.2  商业影响
4.3  客户相关
4.4  过程定义
4.5  开发技术
4.6  开发环境
4.7  人员数目及经验
5 ) .   风险识别方法

5.1  头脑风暴方法
5.2  情景分析法
5.3  面谈法
5.4  风险条目检查表
6 ) .  风险评估 :
6.1确定风险发生概率的估计和评价
6.2 项目风险后果严重程度的估计和评价
6.3 项目风险影响范围的分析和评价
6.4 项目风险发生时间的估计和评价
  
7 ) .  风险概率
7.1 风险概率值 :  >没有可能(0)  <确定(1)
7.2  风险概率度量 :  
高中低
极高,高,中,低,极低
不可能,不一定,可能,和极可能 等 
8 ) .  风险后果 :   风险影响项目目标的严重程度
8.1 风险后果度量 : 
高,中,低
极高、高、中、低、极低
灾难，严重，轻微，可忽略
 9 ) . 风险规划 : 
                指针对风险分析的结果,为提高实现项目目标的机会,降低风险的负面影响而制定风险应对策略和应对措施的过程,也就是制定一定的行动和策略来对付,减少,以至消灭风险事件
10 ) . 风险措施 : 
10.1 回避风险 : 对可能发生的风险尽可能的规避,采取主动放弃或者拒绝使用导致风险的方案 例 : 放弃采用新技术
10.2 转移风险 : 为了避免承担风险损失,有意识将损失或与损失有关的财务后果转嫁出去的方法,例如 : 出售,分包
10.3 损失控制 : 损失预防,损失抑制
10.4 自留风险 : 由项目组织自己承担风险事故所致损失的措施 

 小结 :  
          1.  参考 : 风险管理工作表