【www.arisingsemi.com--软件系统】

pm是什么
项目经理怎么知道每天该干什么
——也许一本《项目经理手册》能解决问题
神州数码 软件服务本部 潘东
[内容提要]2004年神州数码在西安建立了软件开发基地,随着基地规模的不断扩张,大批新任的项目经理感觉管理工作繁杂,流程规范众多,经常是“一头雾水”、“无所适从”。问题的原因之一,是因为项目经理是个综合性很强的岗位,需要参与很多管理过程。为此,我们以项目经理为“中心”对流程进行了梳理,整理出了一本《项目经理手册》,使得项目经理的工作条理清晰,显著提高了流程“落地”的效果。
1 规模快速扩张时遇到的问题
2004年开始神州数码在西安建立软件开发基地,到07年时已经接近千人,成熟度达到了CMMi4,70%以上的金融软件开发任务也成功地转移到了西安基地。
但随着规模的快速增长,也出现了一个问题:尽管有明确的流程和规范,大批新任项目经理在执行时却不断出现错误和遗漏,过程逐渐“走形”,规范慢慢“退化”。而且,虽经不断提醒,甚至采取严厉的惩罚措施,仍没有好转的迹象。
“新项目经理”的不胜任,同时造成“老项目经理”的严重短缺,一时间合格的项目经理成了继续扩展的重要的瓶颈。
2 项目经理是怎么说的?
怎么解决这个问题呢?“解铃还须系铃人”,最直接的办法就是听听项目经理的意见。于是,管理团队多次与项目经理开会、沟通和访谈,就想弄清一个问题:为什么总是出现错误和遗漏?项目经理反馈了各种各样的原因,集中在以下几个方面:
a管理头绪多,弄不清什么时候该干什么;
b流程太多了。常用的还能弄清楚,不常用的很不熟悉,要用时找不着;
c有些流程只规定了怎么做,但没规定该什么时候做,不知道与日常工作什么关系;
d一遇到突发事件就比较慌乱,忘记了必须要作的事情;
听了这些意见,我也从项目经理的角度看了一下他们所需要面对的流程和规范,发现数量确实比较大,但这是因为项目经理岗位的综合性强所决定的客观事实。
但同时也发现,过程文档的结构和流程定义的方式不利于指导项目经理的工作:
流程定义一般是将“某件事情分一二三四五步,其中有ABCD四个角色,每个角色的职责是什么”。从流程制定者角度看,这样的文档结构非常清楚。但对于项目经理这种要参与很多流程角色来说,要从“堆积如山”的流程中“挑出自己的职责”,并且弄清该什么时候去做,的确不是件容易的事。特别是那些新上任的项目经理,为此经常感觉“一头雾水”、“无所适从”也就可以理解了。
联想到有一种团队操表演:很多人同时举起不同的颜色的板子就可以拼出不同的图案,对观众来说,关注的肯定是“图案是什么”;但是,对于每个负责举板子的人来说,最重要的是要知道“什么时候该举哪块板子”。
此时大家才恍然大悟,明白了以前工作的失误之处:我们一直在跟项目经理描述每个图案是什么,而没有告诉他们该在何时举起哪块“板子”。要想让项目经理清楚什么时候该做什么,就必须从项目经理的角度出发组织过程文档。
3《项目经理手册》—以PM为中心重组过程
“从项目经理的角度出发组织过程文档”这一思路的具体措施,就是整理一本《项目经理手册》。
这个想法很好,但如何做却不是件简单的事情,《手册》至少需要满足下面几个条件:
a只是换个角度梳理现有管理流程,而不是重新创造。因此,必须与现有流程保持一致,不能有遗漏或者冗余;
b不能简单的抽取,内容必须按照一定的规则组织起来,保证条例清晰
c内容必须与项目经理日常的工作内容挂起钩来
简单说,《项目经理手册》除了要让项目经理知道什么时间该做什么,还要保证“按照要求做了,所有的流程就被正确执行了”,这必须要一个的系统的方法才行。
这时候,自然想起了“法宝”——《PMBOK》。受到其中过程组分类方法的启发,经过大家的讨论之后确定了以下的思路:
(1). 建立项目管理矩阵,纵向按照启动、计划、执行、控制和结束五过程组分类,横向按照项目管理9个管理域分类;
(2). 按照上述矩阵结构重新组织,将现有的过程和规范分别放到矩阵的不同“格子”里,形成一个描述项目经理工作内容的“项目管理框架”。
(3). 对于项目管理框架上的活动,按照发生频度或场景进行分类,形成项目经理“活动一览表”。
(4). 对活动一览表中的每个活动进行详细描述,包括具体的步骤,使用的模版、工具或者IT系统,以及验证的检查点,完成《项目经理手册》。

下面以梳理神州数码西安开发基地所使用的《项目经理手册》为例,完整介绍一下整个过程。
4《项目经理手册》实例
4.1 建立项目管理矩阵
如前面所述,项目管理矩阵纵向按照启动、计划、执行、控制和结束五过程组分类,横向按照项目管理9个管理域分类。理论上这很简单,但实际上却需要化些功夫。
这是因为,PMBOK中的启动、计划、执行、控制、结束五个过程组理论上的定义,不能直接与业务流程进行映射。
因此,必须从实际的业务流程中找到“标志”性事件作为切分点,将具体的管理流程进行分类重组。通过比对PMBOK定义和实际业务,找到了公司实际项目生命周期管理中的6个标志性事件:
(1)售前立项:识别出一个商务机会,在系统中建立项目号;
(2)签定合同:以法律形式确定项目责任;
(3)售中立项:内部准备完成,在PMC系统中批准执行;([注]:PMC,Project Management Center,神州数码内部使用的项目管理信息系统)
(4)组织监控:项目 “执行”过程中,项目经理正常的管理活动是“执行”活动;但是,某些受到组织级监控,并可以强制采取纠正措施的活动被认为是“控制”活动;
(5)验收开始:验收的条件已经具备,开始启动验收过程
(6)关闭项目:项目完成验收,收款完成,系统中关闭项目号

参见图 1,依照上述6个“标志”进行切分,就可以将五个过程组直接映射到业务流程的不同阶段:启动,对应从“售前立项”到“签订合同”之间的活动,重点是确定范围,估算成本。计划,则对应“签订合同”到“售中立项”之间的活动,重点是完成各种计划的制定。执行,是项目经理对项目的控制过程,控制,是组织级队项目的干预活动;结束则是指从“验收开始”到“关闭项目”之间的活动。
横向划分为范围、进度、成本、质量四个主过程,以及风险、人员、沟通和客户四个辅助过程。
因为采购管理在开发类项目中很少遇到,因此将其替换为了客户管理,这对于软件项目管理来说其实是非常重要一个方面。

4.2构造项目管理框架
根据项目管理矩阵构造项目管理框架的过程相对比较简单,只要将所有项目经理参与的管理过程分别放到矩阵的不同“格子”里。为了方便使用,框架分为主过程框架(图 2)和辅助过程控家(图 3)两个部分。
对项目经理来说,这个管理框架非常直观地给出了其在整个项目生命周期所需要管理的所有事项。从中,也可以看到不同活动的一些特点:
有些活动是具有非常明确的阶段性的。例如,立项、结项和计划;
有些过程则贯穿项目生命周期,比如,问题和风险管理;
执行和控制有比较强的关联性,并且是日常活动的主要内容







4.3项目经理“活动一览表”
项目管理框架明确了项目经理该做什么,但为了进一步让项目经理知道“什么时候该做什么”,对所有的活动按照执行的频度或者使用的场景进行了划分,完成了项目经理“活动一览表”。因为活动一览表是从框架中导出的,可以确保“每天这样做了,所有的流程被正确执行”。
同时,表中还规定了活动所必需使用的模版、工具和信息系统,因此,项目经理知道自己需要掌握哪些东西,用的时候能迅速上手。
限于篇幅,这里仅节选了“执行”和“控制”的一部管理活动进行说明。参见图 3,一个项目经理的典型工作场景如下:
每天:每天必须召开晨会,更新底层计划和完成度矩阵(一种度量任务完成比例的表格),记录个人周报的工作进展;
每周:每周必须完成周例会,更新范围矩阵。
每个季度:每个季末必须完成客户满意度调查和员工满意度调查
里程碑:到达每个里程碑的时候完成里程碑评审,签收阶段完工证明(财务确认收入用),并为即将进入的阶段进行导入培训,包括下个阶段的规范、流程和技术培训:
事件触发:遇到风险、问题、重大变更、人事变动、运行事故和客户投诉等突发事件的应对流程
日常工作:这类活动没有固定的时点要求,可以根据项目实际情况安排。
例如,每周应该与一名员工进行一次面对面地成长沟通;根据客户的要求定期汇报项目进展沟通;遇到范围超过阈值之后进行的项目重估算;人力资源变化时在报派工系统中进行操作;至少每个季度召开一次的团队会议等等。


4.4 活动的详细描述
基于活动一览表,从原有的过程体系中抽取相应的部分,详细描述每个活动的过程、模版和检查点(过程审计的依据)。这样,一本项目经理手册就形成了。这里以“周例会”活动的为例,说明手册的内容是怎么组织的:
范例:
周例会:跟踪中层计划
(1) 过程
a. 会前准备
b编写《个人周报》:项目组成员完成《个人周报》的编写,提交到配置库中。
c 更新《完成度矩阵》:小组长根据上周底层计划完成情况更新《完成度矩阵》,测算各项任务的完成比例。
d跟踪《中层计划》:项目经理根据各小组长提交的《完成度矩阵》和测算完成比例,更新《中层计划》中的各任务完成情况。
e更新《项目控制面板》:。

本文来源:http://www.arisingsemi.com/it/69744/