I整体管理
1.项目计划编制工作流程：（论文）
- 明确目标
- 成立初步的项目团队
- 工作准备与信息收集
- 编写计划——原则【各干系人的参与、逐步精确】
- 评审与批准项目计划
- 获得批准后的项目计划就是项目的基准计划
2.
（1）项目有不可压缩的最短工期；项目计划编制的项目周期太长也不现实
（2）项目进度和成本的关系：
- 成本以及时间调度限制
（3）项目进度和质量的关系
3.软件项目失控的常见原因：
- 需求不明确；
- 不充分的计划、过于乐观的评估：①工作责任范围不明确，WBS与项目组织结构不明确或者不对应；②每个开发阶段的提交结果定义不明确；③开发计划没有指定里程碑或检查点；④开发计划没有规定进度管理方法和职责，导致进度混乱；
- 采用新技术或关心创新导致的过度费用和风险
- 管理方法缺乏
- 性能问题
- 团队组合，人际因素
TIP
1.项目管理计划的渐进明细——【滚动波浪策划】：计划的编制是一个反复和持续的过程
2.组织过程资产：
- 各种规章制度、指导方针、规范标准、操作程序、工作流程、行为准则、工具方法等
- 项目组织在项目管理过程中形成的所有文档（资料库、模板、表格、清单等）
- 留下的历史信息
3.事业环境因素：项目团队不能控制的，将会造成影响限制等条件
- 基础设施
- 政府或行业标准、市场条件
- 数据库等、现有的人力资源、项目管理信息系统
- 组织或公司的文化组成与结构
4.项目章程：
- 关注的是【建设方的商业需求、项目立项的理由与背景、对客户需求的现有理解和满足这些需求的新产品、服务、成果等】
作用
- 正式宣布项目的存在，对项目的开始实施赋予合法地位
- 确保项目成果实现目标；（粗略规定项目的范围）
- 正式任命项目经理，授权
5.项目工作说明书
6.项目目标
- 必须是量化的
- 可以一个，可多个
- 具体的，可实现的
7.项目管理计划
- 记录了计划过程组的各个计划子过程的全部成果
- 项目管理团队选择的各个项目管理过程；实施水平；所执行的方法
- 监控变更的方式
- 项目干系人间的沟通技术
- 选定项目生命周期和多阶段项目阶段
8.投资回报率ROI
ROI=【税前回报率/投资总额】*100%
9.区分
工作绩效数据——Data
工作绩效信息——可以是正式的或者非正式的
工作绩效报告——正式的报告
II范围管理
1.项目范围管理：为了能够交付产品，项目所必须做的工作
渐进明细（项目范围在项目的早期被描述出来随项目进展更加详细）
【产生项目管理计划的基础】
- 明确项目边界
- 对项目执行工作进行监控
- 防止项目范围发生蔓延
2.产品范围：项目范围的基础；
产品范围定义是【产品要求的描述】
产品范围描述——项目范围说明书的重要组成部分；
产品范围变更后，首先影响的是项目范围。
3.项目范围基准：
- 经过批准的范围说明书、WBS、WBS词典
- 可用来判断项目
4.范围管理各过程
5.收集需求的技术
（1）需求跟踪矩阵：体现需求与后续工作成果之间的对应关系；无法用于防止变更
- 从产品需求到最终产品的一个双向跟踪，用来追溯和回溯；
- 可体现测试策略和测试场景的跟踪结果
（当有独立的设计元素时，说明产品需求发生问题；需求规格说明书有误）
（2）需求开发和需求管理的各项活动，不需要展现产品；展示系统是——范围确认的任务
（3）需求开发的四个过程：
- 需求获取——用户需求说明书；获取用户需求并分析和修正；先获取【总体需求-产品需求】
- 需求分析——对各种需求进行分析并抽象描述；建立可指导系统的概念模型（对需求的抽象描述）
- 需求定义——定义准确的产品需求；需求规格说明书
- 需求验证——开发方和用户共同对需求文档评审，达成共识后的书面承诺；具有商业合同效果
（4）需求验证中有评审活动；需求验证完毕后，确立需求基线。
（5）【做好需求回溯】可确保需求不在开发过程中“丢失”的措施。
（6）需求基线：包括用户需求说明、需求规格说明书等内容
（7）需求管理：在产品开发过程中维持需求一致性和精确性的所有活动
从测试用例和测试报告可知追踪到用户原始需求的过程是反向追踪
6.双向跟踪
- 正向跟踪：
检查需求文件中的每个需求是否都能在后继工作产品中找到对应点
- 反向跟踪：检查文档、构建、测试等工作成果能否在需求文件中找到出处
箭头——表示需求跟踪能力联系链；
7.里程碑——标志着某个可交付成果或者阶段的正式完成。
重要的检查点是里程碑、重要的里程碑式基线
8.工作包
- 位于WBS每条分支最底层的可交付成果或项目工作组成部分；
- 大小需要遵循8/80原则
9.控制账户——管理控制点；（一个工作包只属于一个控制账户）
10.WBS
（1）创建WBS过程
- 识别和分析可交付成果及相关工作
- 确定WBS的结构和编排方法
- 自上而下逐层细化分解
- 为WBS组件制定和分配标志编码
- 核实可交付成果分解的程度是否恰当
（2）进行WBS分解，方式：
- 将项目生命周期的各阶段作为分解的第1层；可交付物为第二层
- 重要的可交付物——第1层
- 子项目——第1层
- 工作包的工作量一般是一个人能在8-80小时内完成的
（3）WBS不是某个项目团队成员的责任，应由全体项目团队成员、用户、项目干系人共同完成和一致确认。
（4）WBS表示形式：
- 分级的树型结构（组织结构图式）——用于中小型项目；层次清晰，不易修改
- 表格形式（列表式）——用于大型项目；直观性差，但可反映项目所有的工作要素
（5）WBS特点
- 可交付成果；组织并定义了整个项目范围
- WBS分解的越细，对工作计划、管理和控制能力就越强；但大量的分解工作会导致生产效率降低，效率低
- 底层应支持计划和控制；（是项目管理计划和项目范围间的桥梁）
- WBS中的元素必须有人负责，且只有一个人负责（多人参与，一人负责）
- 每个WBS元素应只从属于一个目层次的WBS元素，避免交叉从属。
- WBS的指导，控制在4-6层
- 包括项目管理工作，及分包出去的工作
- WBS编制由项目干系人参与，需要项目团队成员的参与
- WBS非一成不变；完成后也可能需要改
- WBS和WBS字典构成了项目范围基线
（6）WBS输出：
- WBS和WBS字典；范围基线；更新的项目管理计划；变更申请
（7）凡是没出现【在经项目干系人认可后的WBS中的工作】，都不属于项目范围。
子项目不可以是工作包，应该对子项目继续进行分解。
（8）
- WBS字典——（工作概述、账户编码、资源需求）管理的规范化、标准化工具；描述和定义WBS元素中的工作文档
- 控制账户——在规划包以下，工作包以上，便于管理监控设置的控制点
- 账目编码——用于唯一确定项目工作分解结构每一个单元的编码系统。（成本和资源被分到这层）
- 活动基线——开发软件文档或源码活动的一个稳定版本，进一步开发的基础
11.确认范围
- 工具与技术：【检查和群体决策技术】
- 是项目干系人（发起人、客户等）正式接受已完成的项目范围的过程
- 贯穿项目的始终；从WBS确认到项目验收时范围的检验；
- 比较
【确认范围】与【质量控制】的不同：
类别 目的 进行状态 验收 确认范围 可交付成果获得客户
或发起人的接受
接受问题
在阶段末尾进行 由外部干系人对项目对交付成果检查验收 质量控制 可交付成果的正确性，
并符合其质量标准
核实
在确认范围前进行
或同时进行
由执行组织的相应质量部门实施
【确认范围】与【项目收尾】的不同：
类别 进行状态 重点 确认范围 在阶段末进行 核实与接受可交付成果
强调验收可交付成果
项目收尾 在阶段末进行 结束项目所要做的流程性工作
强调验收产品
12.范围变更
（1）范围变更时对达成一致的、WBS定义的项目范围的修改
范围变更是整体范围变更控制的一个结果。
范围变更控制必须和其他控制过程综合在一起
（2）造成范围变更的原因：
- 政府政策问题、项目范围的计划编制粗略导致；市场上新技术新方案的出现；
- 项目执行组织本身发生变化
- 客户对项目、产品或服务的要求发生变化
（3）项目范围变更由“项目范围控制过程”来处理；变更后要及时通知项目干系人
（4）提出变更、评估变更、变更决策、变更实施、变更验证、沟通存档
（6）范围变更控制：
变更控制方法——定义项目范围变更的流程。包括必要的书面文件（变更申请单）、跟踪系统和授权变更的批准等级。
（5）范围变更控制的主要工作：
- 影响导致范围变更的因素，并尽量使这些因素向有利的方面发展
- 判断范围变更是否已经发生
- 范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理
13.项目定义过程——详细描述项目和产品的过程，并把结果写进详细的项目范围说明书中，作为将来项目决策的基准。
转载：https://blog.csdn.net/WY_star1/article/details/105536430