项目_管理工程师

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u010209842/article/details/89419808

项目

定义

是为了达到特定的目的、
使用一定的资源、
在确定的时间内、
为特定发起人
提供独特的产品、服务 或 成果 而进行的一次性努力

项目特点

1.临时性 ——有明确的起始/结束时间

每一个项目都有一个明确的开始时间和结束时间,项目是一次性的

2.独特性 ——独有的

项目要提供某一独特产品,提供独特的服务或成果,没有完全一样的项目

3.渐进明细 ——逐步完成

项目的产品、成果、服务事先不可见,在项目前期只能粗略的进行定义,随着项目的进行才逐渐明朗、完善、精确。

在项目逐渐明晰的过程中,一定会有修改,产生相应变更



项目目标

1.成果性目标

满足客户要求的产品、系统、服务或者成功

2.约束性目标

时间、成本、质量

项目目标特性

1.有不同的优先级

2.层次性

信息系统集成项目 的特点

1.以满足客户/用户的 需求为根本出发点

2.客户/用户的需求常常不够明确、复杂多变,由此应加强需求变更管理,以控制风险

3.不是选择最好的产品的简单行为,而是选择最适合用户的需求和投资规模的产品和技术

4.不是简单的设备供货,是高技术的集成,更多体现的是设计、调试、开发,都是高技术行为

5.包含技术、管理、商务等方面,是一项综合性系统工程

6.团队年轻,流动性高

7.强调沟通的重要性

项目管理 运营管理 区别

相同点

都需要由 1.人完成、2.受制于资源、3.需要计划执行与控制

不同点

项目:临时性、独有性、目标是达到项目目标

运营: 连续性、重复性、目标是维持已有业务

软技能

有效沟通、施加影响、领导、激励、谈判和冲突处理、解决问题

项目经理一般要求

1.足够的知识
2.丰富的项目管理经验
3.良好的协调和沟通能力
4.良好的职业道德
5.一定的领导和管理能力

如何当好一个优秀的项目经理

1.真正理解项目经理的角色
2.领导并管理项目团队、
3.依据项目进展的阶段,组织制定详细程度事宜的项目计划,监督计划执行,根据实际情况/客户要求/其他变更要求,对计划的变更进行管理
4.真正理解“一把手工程”
5.注重客户和用户参与

项目经理 应具备 和 无需具备

广博的知识、丰富经验、良好沟通能力、协调能力、职业道德及学习通用管理、领导能力

但项目经理不可能具有所有的知识和技能,但是需要了解

在沟通管理中,项目经理出于项目的 核心位置

项目干系人

定义

指积极参与项目、或是其利益会受到项目执行的影响、或项目结果影响的个人和组织

客户/用户、项目经理、项目团队成员、项目发起人、智能经理、影响着、项目管理办公室PMO

项目经理必须管理项目干系人的期望
--项目经理的主要挑战

解决项目干系人质检不同意见,应该以是客户满意为主,
但不要忽略其他项目干系人的要求和希望,找到分歧的恰当解决方案,是项目经理的主要挑战

事业环境因素

项目启动时,必须考虑 影响项目成功的环境、组织因素、系统

1.实施单位的企业文化和组织机构

2.国家标准或行业标准

3.现有的额设施和固定资产

4.实施单位现有人力资源、人员的专业和技能,人力资源政策

5.当时的市场状态

6.干系人对风险的承受能力

7.行业数据库

8.项目管理信息系统(可能是工具或软件,总之能帮助人们管理项目)

组织过程资产
–影响项目成功的资产都可以作为组织过程资产

过程和程序

1.组织的标准过程
2.标准知道方针、模板、工作指南
3.用于满足项目特定需要的标准过程的修正指南
4.组织的沟通要求、汇报制度
5.项目收尾指南或要求
6.财务控制程序
7.问题和缺陷管理程序
8.变更控制程序
9.风险控制程序
10.批准与分布工作授权程序

组织的全部知识

1.项目档案
2.过程测量数据库
3.经验学习系统
4.问题和缺陷管理数据库
5.配置管理知识库
6.财务数据库

组织的沟通能力,对项目的执行方式有很大影响

项目的组织结构

1.职能型
-用于规模较小,侧重于技术的项目

项目经理无权无资源/所有项目人员兼职

优点

1.充分发挥职能部门的资源集中优势
2.专家可以同时为部门内不同项目使用
3.便于交流、支援、可随时增派人员
4.项目和本部门只能工作融为一体

缺点

1.项目和部门利益发生冲突,职能部门注重本部目标,忽视项目目标
2.资源平衡会出现问题
3.权利分割不利于各部门交流和团队协作
4.行政隶属关系使项目经理没有充分权利

2.项目型
-用于规模大、技术复杂的项目

项目经理领导有权/所有项目人员专职

优点

1.项目经理对项目负全责
2.项目目标单一,以项目为中心,有利于顺利进行
3.避免多重领导
4.组织结构简单,交流简单、快速

缺点

1.资源不能共享
2.各独立项目组相对封闭,不利于公司政策贯彻
3.对项目组成员缺少一种事业上的连续性和安全感
4.项目之间分割状态,缺少信息交流

3.矩阵型
-用于规模巨大、分工明确,跨职能部分的项目

兼具项目型和矩阵型特点
项目经理领导权不确定/所有项目人员专职/兼职

分类

弱矩阵
项目经理>职能经理

平衡矩阵
项目经理=职能经理

强矩阵
项目经理<职能经理

优点

1.专职的项目经理负责真个项目,以项目为中心
2.公司的多个项目可以共享各个只能部门的资源
3.利于项目的实现,利于公司目标方针的贯彻
4.项目成员顾虑少

缺点

1.容易引起职能经理和项目经理权利的冲突
2.资源共享也能引起项目之间的冲突
3.项目成员有多个领导

项目经理权利排序 项目型>矩阵型>职能型




项目管理办公室 PMO

可以为一个项目设立一个PMO
也可以为一个部门设立一个PMO
还可以为一个企业设立一个PMO

PMO可以在一个组织内可以同时存在,PMO不一定要位于组织的中心

关键特征

1.所有PMO管理的项目之间共享和协调资源

2.明确和制定项目管理方法、最佳时间和标准

3.负责制定项目方针、流程、模板、和其他共享资料

4.为所有项目进行集中的配置管理

5.对所有项目的集中的共同风险和独特风险存储库加以管理

6.项目工具(如企业级项目管理软件)的实施和管理中心

7.项目之间的沟通管理协调中心

8.对项目经理进行指导的平台

9.通常在企业级对所有PMO管理的项目的时间基线和预算进行集中盟控

10.在项目经理和任何 内部/外部的 质量人员/标准化组织 之间协调整体项目的质量标准

PMO有 1.支持型、2控制型、3.指令型

项目管理 和 PMO 的区别

1.项目经理和PMO追求不同的目标

2.项目经理负责在项目约束条件下完成特定的项目成果性目标
PMO是具有特殊授权的组织结构,其工作目标包含组织级的观点

3.项目经理关注特定的项目目标
PMO管理重要的大项目范围的变化,以更好的达到经营目标

4.项目经理控制赋予项目的资源以最好的实现项目目标
PMO对所有项目之间的共享组织资源进行优化使用

5.项目经理管理中间产品的范围、进度、费用、质量
PMO管理整体风险,整体机会和所有的项目依赖关系


项目生命周期

特征

1.项目阶段一般按顺序首尾相接

2.人力投入和费用,开始时低,随之增高,在项目结尾时迅速降低 (低高低)

3.项目成功可能性随着项目执行逐渐上升,风险和不确定性逐渐下降 (成功 逐渐升高,风险 逐渐下降)

4.项目干系人对项目的影响力对项目执行逐渐下降 (高到低)

技术上

需求分析—>系统分析—>系统构建—>系统运行

按管理活动出现的先后

启动—>计划—>执行—>收尾

项目生命周期 和 产品生命周期

相同点:一般产品生命周期包含项目生命周期

不同点

项目:概念/启动、开发/计划、实施/执行、结束/收尾

产品:介绍、增长、成熟、衰退

典型信息系统项目周期

瀑布模型 (最常用)(典型软件生命周期模型)

每个软件过程顺序衔接、一次性通过

优点:由文档和风险驱动,利于提高大型项目开发的质量和效率

缺点:建设周期长、风险大、难以满足用户需求

适合场景:需求明确且很少变更的项目,如二次开发或者升级型项目

四个阶段:1.可行性分析(计划)
2.需求分析
3.软件设计(概要设计、详细设计)
4.编码(含单元测试)
5.测试
6.运行维护

螺旋模型

演化软件过程模型,将原型实现的迭代特征与线性顺序(瀑布)模型 中控制的和系统化等方面结合起来

优点:由文档和风险驱动,利于提高大型项目开发的质量和效率

缺点:建设周期长、风险大、难以满足用户需求

适合场景:需求经常变化的大型复杂系统。

四个阶段:
1.定制计划
2.风险分析
3.实施工程
4客户评估

增量模型

采用随时间进展而交错的线性序列、每个序列产生一个可发布的增量、每个增量产生一个可操作的产品,第一个增量就是核心产品

优点:开始时不需要投入大量人力资源、可以现推出核心产品以稳定用户,可以有计划的管理技术风险

缺点:需要开放式体系结构,可能会产生设计效果差、开发效率低的情况

适合场景:需求经常发生变化的软件开发过程

快速原型模型

快速构件和运行的软件模型,一边理解和澄清问题,进一步细化需求,在新获取需求基础上进行系统开发

优点:避免由于用户需求不明带来的开发风险

缺点:快速建立的模型加上连续的修改可能造成产品质量低下

适合场景:用户需求模糊不清的情况下

迭代模型

一次迭代过程中包括了所有软件开发流程,每一次迭代均产生一个可发布的产品,该产品为最终产品的一个子集
在一个阶段内部,可以完成一次到多次的产品迭代

适合场景:实现不能完整定义产品的所有需求,计划多期开发的项目

四个阶段:1.初始、2.细化、3.构造、4.移交

V模型

已测试为中心,为软件生命周期每一个阶段制定相应的测试界别

对应关系
编码阶段 -> 单元测试
详细设计阶段 -> 集成测试
概要设计阶段 -> 系统测试
需求分析阶段 -> 验收测试

敏捷方法(极限编码XP)

一种轻量、高效、低风险、更强调团队协作和沟通的开发方式,适用于中小型开发团队

适合场景:客户需求模糊或者多变

统一过程
RUP Rational Unified Process

即UP/RUP,基于构件,具有用例驱动、已基本架构为中心、迭代、增量的特点

四个阶段:
1.初始化阶段
2.细化阶段
3.构建阶段
4.交付阶段


项目阶段的特征

特征

1.每个项目阶段都以一个或数个可交付成果的完成为标志

2.可交付成果是某种有型的、可验证的工作成果

3.一些可交付成果对应这项目管理过程,另一些可能是最终产品的一部分

4.项目阶段的结束通常以 --对完成的工作和可交付成果的技术和设计评审为标志。
–目的是确定是否验收、是否仍然需要增加工作、或者是否考虑结束这一阶段

5.–阶段末 可进行一次 --审查,–目的是去的对结束当前阶段并启动下一阶段的核准,阶段生产也称作阶段放行口、阶段关卡、验收站

三分技术七分管理,任何项目的阶段中都包含管理公祖和技术工作,

论技术工作还是接管工作出现的先后来划分项目阶段,项目的每个阶段至少包含管理工作和技术工作


PDCA 戴明环

即计划(plan)、执行(do)、检查(check)、处理(act)

5个项目过程组

启动过程组

定义并批准项目或阶段

计划过程组 plan

定义和喜欢目标,规划最佳的技术方案和管理计划,以实现项目或阶段所承担的目标和范围

执行过程组 do

整合人员和其他资源,在项目的生命周期或某些阶段执行项目管理计划,并得到输出与成果

监控过程组 check

要求定期测量和监控进度、识别实际绩效与项目管理计划的偏差、必要时采取纠正措施,或管理变更以确保项目或阶段目标的达成

收尾过程组

正式接受产品,服务、工作成果、有序地结束项目或阶段

5个项目过程组具有明确的依存关系并在各个项目中按一定的次序执行。

5个过程组是所有项目应必须的。

项目过程组很少会是离散型的或者只出现一次,他们是相互交叠的活动



猜你喜欢

转载自blog.csdn.net/u010209842/article/details/89419808