项目管理及知识转移.docx
《项目管理及知识转移.docx》由会员分享，可在线阅读，更多相关《项目管理及知识转移.docx（18页珍藏版）》请在冰豆网上搜索。
项目管理及知识转移
项目管理及知识转移
项目管理面临的挑战
项目管理流程
2.1
项目管理流程
2.2
项目生命周期
.4
需求管理
3.1
需求工程内容
.6
3.2
需求分析
.6
3.3
需求变更
.7
创建工作分解结构
时间管理
11
5.1
项目时间管理的过程
11
5.2
项目时间管理工具
11
成本管理
13
风险管理
15
变更管理
16
知识和文档管理
18
1项目管理面临的挑战
在企业的项目管理过程当中，常常会遇到项目进展不顺利的情况，有时候项目甚至会失败。
真正的项目管理人员必须有能力对项目进行预判，并及时加强管理采取必要措施，同时还要积累经验，帮助团队吸取教训。
如何有效地管理项目，解决项目过程中遇到的诸如以下问题：
统一协同：
项目进展过程不同阶段分别用不同的工具管理，数据不能有效整合，部门间形成信息壁垒；
全局视图：
项目进度：
缺乏管理层项目汇总全局视图，难以实时掌控众多项目的进展与情况；分散的信息，无效率的流程，项目进度不可控，项目过程不透明，项目周
期难交付；
面管控资源利用率？
质量管控：
如何统筹考虑项目风险防控、技术评审、系统测试、质量保障，全面保障交付高质量产品？
知识积累：
项目实施中，能否不断积累知识和经验？
有效的知识如何被反复的利用？
绩效决策：
项目人员工作量如何考核？
项目管理哪些方面需要改善？
如何解决？
2项目管理流程
该方案专门针对企业项目管理面临的问题，帮助企业有效管控项目及研发全生命周期，通过一个全面的组织级项目管理平台，帮助企业实现项目及管理的“过程透明化”和提升组织级
进度、质量和成本；
项目管理能力；从横向上让项目团队能在组织级层面全面跟踪项目的需求、从纵向上打破业务部门与外包团队的壁垒，全面贯通项目的需求、计划、开发和测试；为高层领导提供多项目信息的全局视图，帮助宏观监督和调控多个项目并提供直观的管理手段。
2.1项目管理流程
在项目管理的流程中，每个阶段都有自己的起止范围，有本阶段的输入文件和本阶段要产生的输出文件。
同时，每个阶段都有本阶段的控制关口，即本阶段完成时将产生的重要文件也是进入下一阶段的重要输入文件。
每个阶段完成时一定要通过本阶段的控制关口，才能进入下一阶段的工作。
制定项目章程
制定项目初步
范围说明书
需求分析
!
项目知识转移
f
1
1
1
1
1
1
1
1
1
1
1
1
1
1
收集、分析、细化需求
!
J
1.
["
定义项目范围
1
1
确认范围、控制范围1
——1
厂1
初步范围说明书
项目章程
需求文档
创建WBS'〜
细化项目工作
1
（工作分解
*结构）
细化项目可交付成果
1L
1
1
1
V
定义活动、排列活动顺序
」估算活动资源、估算活动持续时间
工作分解结构
活动、资源、
时间管理
进度文档
制定进度计划、控制进度
估算成本、制定预算
成本管理
控制成本
成本估算文档
质量管理
质量保证制度
控制质量
质量控制标准
风险管理
识别风险、定性风险分析
定量风险分析、规划风险应付措施
风险应对措施
控制风险
变更管理
了解、评估、执行变更
1
1
变更日志
变更控制
1■
1
1
1
^变日志、
J
结项
项目监控
Z
2.2项目生命周期
项目生命周期管理是从项目的立项阶段、各里程碑阶段（需求、设计、开发、测试）、到
结项阶段，整个项目生命周期的管理。
实际工作中根据不同领域或不同方法再进行具体的划分。
在项目生命周期运行过程中的不同阶段里，由不同的组织、个人和资源扮演着主要角色。
根据项目具体情况，定义项目生命周期的流程，包括所有可能的状态和工作流操作。
审批通过
审批通过
审批通过
发起测试审批1——片
开发完成--测试
斗1审批不通过
测试审批
审批通过
测试完成--结项
发起结项审批1—k
结项审批
审批不通过h
审批通过
结项完成-关闭
3需求管理
需求管理是指在组织范围内协作并管理需求、功能点、项目的创意，以及和需求相关的任何功能或技术设计文档。
通过将来自各个业务部门的需求有效的过滤筛选，并且进行组织和合并，把需求按照业务系统进行组织和管理；同时对于需求的版本和基线提供有效管理，保证需
求的有效性、完整性和正确性。
通过整合，可以直接基于需求有效驱动开发和测试。
3.1需求工程内容
项目需求工程包含以下内容:
需求工程
3.2需求分析
需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图，需求分析常用的方法有:
1）问答分析
做什么/解决什么问题?
谁做？
怎么做？
输入输出有什么？
约束、限制条件？
Rose
Visio
表单
系统、子系统、模块、功能点，自顶向下、逐层细化
功能业务要素操作特性
3.3需求变更
随着项目的进展，用户和开发方对需求的了解越来越深入，原先的需求文档很可能存在错误或不足。
另一方面，市场会发生变化，原先的文档也可能跟不上当前的市场需求。
可见需求变更总是不可避免的，有些是为了修正缺陷，有些属于增强功能。
对项目开发小组而言，变更需求通常意味着要调整资源、重新分配任务，并修改前期的工作成果，有时要付出较大的代价。
如果动不动就变更需求，某些项目也许永远不能按时完成。
为此，需求变更必须遵守利大于弊的原则。
需求变更通常按变更申请一审批一更改一重新确认的流程进行。
需求变更申请书
开始
提交变更申请书
变更审批
4创建工作分解结构
工作分解结构（简称WBS）跟因数分解是一个原理，就是把一个项目，按一定的原则分解,项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。
即：
项目7任务7工作7日常活动。
工作分解结构以可交付成果为导向,对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。
WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。
（一）分解原则
1）
将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成；
（二）任务分解的方法
1）采用树状结构进行分解；
2）以团队为中心，自上而下与自下而上的充分沟通，一对一个别交流与讨论，分解单项
工作。
（三）任务分解的标准
1）分解后的活动结构清晰，从树根到树叶，一目了然，尽量避免盘根错节；
2）逻辑上形成一个大的活动，集成了所有的关键因素包含临时的里程碑和监控点，所有
活动全部定义清楚，要细化到人、时间和资金投入。
WBS（工作分解结构）示例：
项目管理
规划
会议
管理
产品需求
软件
用户文件
培训资料
软件产品版43.0
详细设计
软件
用户文件
培训资料
图：
工作分解结构示例
构建
软件
用户文件
培训资料
V
整合与测试
软件
用户文件
培训资料
5时间管理
项目时间管理，主要工作包括定义项目活动、任务、活动排序、每项活动的合理工期估算、
制定项目完整的进度计划、资源共享分配、监控项目进度等内容。
时间管理工作开始以前应该先完成项目管理工作中的范围管理部分。
如果只图节省时间，
把这些前期工作省略，后面的工作必然会走弯路，反而会耽误时间。
项目一开始首先要有明确
项目目标、可交付产品的范围定义文档和项目的工作分解结构（
WBS）。
由于一些是明显的、
项目所必须的工作，而另一些则具有一定的隐蔽性，所以要以经验为基础，列出完整的完成项
目所必需的工作，同时要有专家审定过程，以此为基础才能制定出可行的项目时间计划，进行
合理的时间管理。
5.1项目时间管理的过程
1）
活动定义：
涉及确定项目团队成员和项目干系人为完成项目可交付成果而必须完成对
具体活动（WBS）；
2）
活动排列：
设计确定项目活动之间的关系，并形成相应的文档；
3）
活动历时估算：
估计完成具体活动需要的工作时间；
4）
制定进度计划：
分析活动顺序、活动历时估算和资源要求，制定项目进度计划；
5.2项目时间管理工具
甘特图、网络图和关键路劲分析
lb
1莉目启功
3生威北摒宇喜
开玄环廉性維刮试—模型幵妊—呻丰总释
AJ
號幡预处盍
參寒最分桂
6.6
損型tl能剧試
K芫或总结扯吉
9'电晁謂
图:
甘特图
6成本管理
项目成本管理指为保障项目实际发生的成本不超过项目预算，使项目组批准的预算内按时、按质、经济高效地完成既定目标而开展的成本管理活动。
项目成本管理过程:
IT项目的资源按其使用特性分为以下三类:
1）项目环境资源：
通用的标准化的资源，如：
软件和硬件;
1盗源名a
r资混单价
1资源数量
维护费用
服务■器文件数据库
SAS
建模工具报表工具
合计
—
2）可重用资源：
多个项目中可以重复使用的资源;
3）人力资源：
项目实施所需要的人员以及人员的可得情况。
1任务名称
人力资源
T件包月/A）
资蹲屋/人1
TSfl/月1
顷a管理
项目经理
10
1
10
系统需求分析
系统分析师
4
2
2
系统总体设订
弄统荣构师
4
2
2
详细设讣
系统设计师
6
3
2
ffi型开发
模型幵发师
60
15
4
系统测试
系统测试工程师
6
3
2
文歸写
文档编辑
2
2
1
合计
92
23
图:
人力资源估算
7风险管理
对项目风险从识别到分析，乃至采取应对措施以及风险跟踪等一系列过程的管理，主要包括：
风险识别、风险量化、风险对策。
风险状态跟踪包含：
风险识别风险量化跟踪风险进展情况设置风险预警级别风险复用与借鉴
风险和具体项目关联
来判断风险的影响力。
风险可以和具体的项目关联，根据风险在项目里面的预警级别,通过不断的风险积累来形成完整的风险库，保障项目的正常进行。
风险管理示例：
图:
风险管理
8变更管理
变更管理是对项目中突发的，可能导致项目计划严重推迟的重大变更进行管理。
目的是评
估该变更是否一定要发生，是否有其他更好的解决方案规避或者减轻影响，同时也通知所有干
系人变更后的结果。
有些大型项目设有专门的变更委员会。
变更申请内容包括变更原因，变更方案等。
有效地识别变更和准确地分析变更影响，变更
申请通过后，及时将变更的内容通知给所有干系人，保证变更实施后的结果得到一致的执行。
项目变更管理的目的是以一种对于项目影响最小的方式改变现状。
它包括以下主要内容：
1）
了解变化。
在项目实施过程中，项目组织要经常关注与项目相关的主客观因素，及时
发现和把握变化，认真分析变化的性质，确定变化的影响，适时进行变化描述。
2）
进行变更处理。
当变化了的各种因素影响到了项目的顺利实施时，项目组织必须及时
进行计划变更，以确保项目目标的实现。
项目计划的变更应征得项目主体的同意，项
目组织还应及时向其反馈变更及变更执行情况。
3）
监控变更合理性。
变更处理总是根据项目实施的客观需要进行的，但并不是每次变更
都是合理的。
I开始
干系人提出变更请求
项目团队了解变更
团队评估变更对影响
总结经验教训
更新组织过程资产
结束
图：
项目变更管理流程图
9知识和文档管理
移和传播知识避免知识的重复开发和充分利用知识资源。
知识主要是以文档的形式保存下来,因此，知识转移中项目文档管理是最核心的内容。
项目文档管理，是指在一个系统（软件）项目开发进程中将提交的文档进行收集管理的过程。
通常，文档管理在项目开发中不是很受重视，当发现其重要性时，往往为时已晚。
整个项目可能因此变得管理混乱，问题产生后无据可查。
文档管理对于一个项目的顺利进行有着至关重要的作用，其关键性不容忽视。
作为管理完善的项目文档，管理者完全可以依顺它的轨迹看清整个项目进展的脉络，同时通过对阶段性文档的把握使整个项目质量得到很好的掌控。
制定一套完整有序的项目文档管理规定十分必要。
管理者结合实际情况制订出适合自身的文档管理规定。
例如，从项目周期角度可分为开发文档、产品文档、管理文档；更细致一点还可分为14类文档文件，具体有：
可行性研究报告、项目开发计划、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、用户手册、操作手册、模块开发卷宗、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
这样的分类细化了项目进度中各个阶段所需管理的文档。
项目文档在各个阶段的提交情况示例
SHS阶段运営维护阶段
可行性需求分析设计阶段实施阶段
硏究与计划阶段
项目H瞬理项目计划业务需求数掘需求开发文档系铳SK用户手册上线文档培训资料
升级会员 