[项目管理征文]我的项目管理之路--pharos (5.6更新全篇完) - 项目管理 - ITPUB论坛

pharos
谷雨霖

精华贴数 4
个人空间 4863
技术积分 6454 (186)
社区积分 439 (1414)
注册日期 2001-12-11
论坛徽章:114

#11

使用道具

发表于 2008-3-13 19:04

在部分参与项目管理一段时间后，终于迎来了自己负责的一个项目，实战总是让人既兴奋、又紧张。紧张是怕自己负责的项目不能达成 T/Q/C目标。

　

我负责的第一个项目涉及软硬件开发，是一个比较标准的项目管理过程（这时项目管理组织结构是平衡矩阵模式。关于公司项目管理组织模式演变，以及自己对其有缺点的理解后续再谈）。下面，分享其中的一些理解和体会。

项目分为了以下几个主要阶段：
立项阶段
计划阶段
开发自测阶段
硬件样机阶段
小批量试产阶段
测试阶段
评测开局阶段
结项

1、项目的立项阶段
涉及新产品规划立项书、项目可行性报告、新产品规格定义、项目投入量本利分析等工作。其中，项目可行性分析报告很关键，它是一个总体直接影响项目市场行为是否成功，它主要回答这几个问题：
-项目建设有无必要性？
-项目需要多长时间完成？
-需要多少人力物力资源？
-需要多少资金且能否筹集到足够的资金？
-项目财务上是否有利可图？
-项目经济上是否合理？
-。。。

可行性分析工作通常是产品经理、客户经理、业务经理、中高层管理人员完成，他们与市场最接近。一个关键因素是要考虑，收集的需求中哪些是真正的需求。规格定义书制定需要项目经理、系统架构师等核心技术人员参与，规格越明确越好。规格定义、量本利分析可以延续到计划阶段进行。
这个阶段的工作可以简单归纳为：

输入：市场需求
活动：
制定产品包需求，评审定稿
确定项目目标，组织结构及分工，一级计划内容、二级计划完成时间
立项评审会暨项目启动会
输出：
产品包需求（需求包要满足DFX需求，design for x，X涉及可测试性、可生产性、可维护性、可移植性等）
项目立项书（一级计划、签字备案、财务编号）

2、计划阶段

输入：产品包需求，项目立项书

活动：（项目经理负责）
制定系统需求（硬件、软件、结构、包装），评审定稿
制定系统总体架构方案，评审定稿；
制定产品规格定义书，评审定稿
任务分解，模块划分，工作量评估、进度及配置计划、关键里程碑、项目风险评估、资源估计，计划评审定稿
量本利分析
制定质量保证计划（QA负责）
项目开工会（项目组对计划的承诺、项目考核办法、动员）

输出：
系统需求说明书
系统架构设计方案
项目二级计划（含word，mpp及配置计划，需要包含里程碑、工作量说明、资源估计、风险评估）
项目计划评估表
产品规格定义书
质量保证计划
量本利分析

3、开发阶段
开发阶段是项目的主体，包括软件开发、硬件开发、系统联调和测试几部分。
软件要完成：需求说明书、需求跟踪矩阵、设计说明书、自测方案、自测报告、手册等相关工作
硬件要完成：设计说明书、原理图、PCB、结构设计、原理样机、性能样机、小批量样机评审/测试报告、硬件手册等相关工作。
测试要完成：功能/集成测试策略、方案、报告、更新需求跟踪矩阵、手册验收、BUG跟踪等相关工作。
以及各自相关的评审工作。
其中，在开发阶段项目经理需要关注的要点是保证规范的执行（可以通过QA或配置管理员获取监控信息）
BUG填写/流转规范
配置管理工具在项目中的操作命名规范
变更申请的审批流转规范
基线的打法与注意事项
配置项标识规程
同行评审规程
周报制度
编程规范
代码自测规范
软件版本命名规范
版本正式发布checklist
硬件规范

特别要提及的是需求说明书的撰写和评审。需求是项目范围、工作量、工期、成本的基本依据，需求详实、可依据，那么项目成功了一半。需求说明书要包括：
功能需求
配置需求
性能需求
Debug需求
特殊需求
需求的优先和关键顺序
运行环境规定
需求点数目
建立需求跟踪矩阵
需求分析/设计说明书评审会一定要测试人员参加，并提前至少两天通知待评审材料。测试人员越早介入需求，对于产品工期的保障越有效。在著名的v字形开发流程中，每个阶段都对应着测试人员测试方案的撰写，如系统需求--验收测试方案，功能需求--功能测试方案等等。同时，相关会议信息和评审文档抄送QA，修改后归档受控。

开发阶段的其它环节监控方法业内相对比较成熟，有很多文章可以参考这里就不多论述了。

4、结项阶段
结项阶段的工作主要是对项目开发过程进行回顾、总结经验教训，以及进行相关的考核。

结项活动主要包括：

输入：项目完成的各工作产品（代码、文档、硬件、过程数据等）
活动：
项目组成员编写个人项目总结
项目经理与部门经理考核项目
输出：
项目结项总结报告
项目结项书
结项通知书
质量总结报告（QA完成）
结项评审会
注意：任何情况下，都要组织项目的结项验收

通常，在项目组准备好相关工作产品后，要及时召开项目总结会议。会议的议程可以包括：

1) 项目组成员依次对本人在项目中的工作进行介绍，分享经验教训和改进建议；
2) 大家对项目中的重点问题讨论改进措施，并对好的方法进行总结提炼；
3) 项目组就项目的成功之处讨论申请加分项；
4) 各部门经理对项目组的工作进行总结，肯定成绩，明确不足和今后的改进措施，勉励项目成员再接再厉；
5) 项目经理对项目组全体成员的工作表示感谢，并表扬贡献突出的人员；安排项目组结项庆祝活动，及项目组成员的考评工作；

项目经理根据项目组成员的个人项目总结，及总结会的改进建议共识进行汇总，编写项目结项总结报告和项目过程数据记录。

结项评审会需要审核的资料清单：
《项目结项总结报告》（含《项目过程数据记录》）
《项目配置状态报告》
《项目质量总结报告》
《项目评测报告》（如果有评测）
《项目小批量试生产报告》（如果有小批量生产）
《项目小批量样机质检报告》（如果有小批量生产）
《项目开局报告》（如果有开局）
《项目产品发布清单》（含小批量报告、ECN等生产文件已提交文控归档和发布）

我们整个项目管理过程需要涉及的流程、规范目录，参见

http://space.itpub.net/3433/viewspace-206174

http://space.itpub.net/3433/viewspace-206175

http://space.itpub.net/3433/viewspace-206176

http://space.itpub.net/3433/viewspace-178879

下回，我们聊聊深入项目管理要提升的地方。

[ 本帖最后由 pharos 于 2008-3-13 19:06 编辑 ]

__________________

书案常逢谷雨霖
MSN:cabinhome@sohu.com
BLOG:http://space.itpub.net/3433/
种下思想，收获行动；种下行动，收获习惯；
种下习惯，收获品格；种下品格，收获人生！

“我的项目管理之路”有奖征文活动已截稿！

只看该作者

quhp1978
ITPUB临时雇员

精华贴数 2
个人空间 0
技术积分 12725 (86)
社区积分 47062 (11)
注册日期 2006-3-28
论坛徽章:13

#12

使用道具

发表于 2008-3-14 09:24

写的系统，有条理。

__________________

不会游泳的鱼我快乐  我自在  因为我不在水底下
偶的兄弟姐妹：
lenovosnb 风子 xiaopingcai it01 之乎者也  nlxx rain0903
偶要感激的朋友：
n5281407 flowergirl keaide 风子二月初三 hphubei
偶的联系方式：
不会游泳的鱼--quhuaping-fish@hotmail.com
不会游泳的鱼--438681596

http://www.itpub.net/images/smilies/17.gif

协助朋友诚征GPS代理商，有意PM我。

只看该作者

pharos
谷雨霖

精华贴数 4
个人空间 4863
技术积分 6454 (186)
社区积分 439 (1414)
注册日期 2001-12-11
论坛徽章:114

#13

使用道具

发表于 2008-3-24 22:03

随着对项目管理理解的深入，自己对项目管理的两点有了深刻理解：需求开发与管理、项目组织结构

一、需求开发与管理

宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。我们经常看到的是：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。

需求开发与管理面临最普遍的问题是：用户说不清楚需求。
有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。例如，早期的政府信息化项目用户通常只有一个朦胧的信息化感觉而已，需求分析中会这样写："总之，要实现那种能够想到就能做到功能。"。如果开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消费”。
有些用户虽然心里明白想要什么，但却说不清楚需求。比如说买鞋子。我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋。一些企业的信息化项目，每个子部门对自身的需要很清楚，但不知道如何从系统角度来要求。
因此，我们可以说项目开发最困难的部分也就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。为此，需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。
业内来看，一个成熟、成功的项目，通常它在前期需求、系统设计投入的工作量比例会大于30%。

1、需求开发与分析
需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。一个良好的需求说明书，应该有如下特征
1.1 正确
需求规格说明书应当正确地反映用户的真实意图，开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。
1.2 清楚
清楚的需求让人易读易懂，包括文档的结构、段落等是否清晰。
1.3 无二义性
“无二义性” 是指每个需求只有唯一的含义。
1.4 一致
“一致”（Consistent）是指各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。
1.5 必要
开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。
1.6 完备
“完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求，比如是否覆盖了所有的功能、性能、交叉、安全等需求。
1.7 可实现
《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）。
“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。
1.8 可验证
《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。
1.9 确定优先级
需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。
1.10 阐述“做什么”而不是“怎么做”
开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。他们经常在整理需求的时候习惯性将如何实现的信息涵盖在需求中，导致需求可读性、可验证性无法保证。

2、需求管理过程域 [部分定义摘录于网络]
需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

2.1需求跟踪
需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式：
正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
我们就曾经出现大家埋头于开发，最后才发现项目协议书中的一个小基本功能没有开发的事故。

2.2 变更管理
需求变更通常会对项目的进度、人力资源、经费产生很大的影响。
如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，会导致产品的部分内容需要重新开发。这是要坚决避免的。
如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。

其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。如果需求变更带来的坏处大于好处，那么拒绝变更。
需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题的一个办法是事先建立规则：如，
开发方与客户方达成“事不过三”的约定，即允许客户变更三次需求；如果客户第四此变更需求，开发方有权提请客户补偿开发投入。

3、深入理解需求
需求的开发和管理有一些规律或经验可以参考，核心是沟通确认、沟通控制。

3.1认清谁才是"上帝"
我们说客户是上帝，是因为客户的重要性，客户占有决定性的地位。对于广大不能清楚描述需求的客户，项目开发人员负有教育客户的义务，需要引导客户，让他们说出自己的心声。客户往往都是领域专家，对自己的工作有很深的认识，可是由于对软硬件开发的不了解，往往表达不清，甚至表达不出自己的需求。这时候，就是体现你的功力的时候了，象对待上帝一样对待你的客户。
3.2 耐心是首要的
学理工科的人，一般在逻辑思维上会比较好，可是对于客户来说，可不一定是这样。一些客户在了解需求的时候，扯东扯西，含糊不清，只有耐心才能获得真正的需求。耐心最后会仍会体现为沟通，只有耐心的沟通，你才能揭开需求的重重面纱。人的行为总是会受到思想的指导，如果你解不开客户的心结，你就不可能了解他真正需要的。
3.3 参与是重要的
XP方法的一个重要实践，就是提倡"现场客户"（on-site customer）。也就是说，客户应该随时和开发人员在一起，随时提供资料和做出决策。而这个客户，也必须领域专家，而且能够有权做出决策。非常的贴近客户，甚至可以在做游戏的过程中完成卡片的填写，能带来很强的客户参与度。
3.4 拥抱变化
需求变化是开发人员最讨厌的一件事了。可是，就像我们常说"哭不能解决问题"一样，讨厌能解决问题吗？拒绝客户的变更要求，要求客户在需求规格说明书上签字。这些做法只能是适得其反。没有任何正面的、积极的意义。需求变更要求我们的开发工作要迭代式进行，包括需求、设计、实现等阶段。这样才能将变更风险减到最小。
3.5 测试
这里的测试指的是考核软件项目是否成功的一个"执行性目标"。例如，开发物流系统的目的是为了缩短产品周转周期，降低库存；开发供应链系统是为了加强和供应商的联系，降低库存。这些和具体业务有关的指标都是可以通过细化，用多种分指标来度量的，所以是可以做到的。
我们把这种目标称为测试就是要提醒开发人员，要把满足这种目标当作最终的测试。

有了明确的需求，我们一定竭力做如下几件事情：
什么(WHAT)：按顺序列出达到目标所需完成的工作；
何时(WHEN)：完成工作所需要的时间；
做到的程度(HOW-WELL)：要完成的工作以何标准来度量；
资源(RESOURCES)：完成工作需要的人员/资金等；
谁(WHO)：由谁负责完成任务。

__________________

书案常逢谷雨霖
MSN:cabinhome@sohu.com
BLOG:http://space.itpub.net/3433/
种下思想，收获行动；种下行动，收获习惯；
种下习惯，收获品格；种下品格，收获人生！

“我的项目管理之路”有奖征文活动已截稿！

只看该作者

pharos
谷雨霖

精华贴数 4
个人空间 4863
技术积分 6454 (186)
社区积分 439 (1414)
注册日期 2001-12-11
论坛徽章:114

#14

使用道具

发表于 2008-3-24 22:06

二、项目组织结构历程
一个公司的项目组织结构直接影响项目管理的程度。应该说，只要管理得当，哪种项目组织结构都应该能够获得项目的成功。但是，往往项目的成功与否与项目经理的能力和权力直接相关。因此，项目组织结构就产生重要影响。
项目组织结构通常是企业组织自我形成的，没有内因、外因是不会变动。但，无论是哪种原因，项目组织结构上的改动通常是自上而下，即是一种授权的结果。
我依次经历了职能式项目管理、协调型项目管理、弱矩阵项目管理、平衡/强矩阵项目管理等几个模式，有一些感触给大家分享。

1、职能式项目管理
所谓职能式就是，工作是从一个部门流转到另一个部门来完成，没有明确的项目经理。产品开发计划是在总经理、总工和部门经理之间确定的，各部门开发工作的流转依靠的是自发动力。在这种情况下，员工的归属感很强，也很有所谓的power----说no，“这事情我说了不算，你找我们经理”。这种模式的问题是，会逐渐形成部门壁垒，跨部门流转比较慢，项目T/Q/C基本不可控。问题通常会出现在跨部门的情况，产品上市时间遥遥无期。比较典型，我参与的一个项目，原计划6个月完成，但每个部门延迟1-2月，项目最终1年多才发布，而且问题百出。最终人让参与产品开发的每一个人感到疲倦和对产品的麻木。在这种模式下，奖金盘子通常比较固定，研发人员的激励基本是部门制度，属于旱涝保收型。其根本原因是无法将产品与市场收益很好的联系起来。也正是这种模式，使得开发人员更多的听从部门经理的安排，也会因为激励不好不坏而使得大家积极性不能很好的发挥。

2、协调型项目管理
持续一段时间部门项目管理模式后，在市场和客户的压力下，大家认识到项目管理需要一个对产品开发最终目标负责的人，于是有了项目经理。这个时候，其实，各级领导并没有真正认识到项目经理的关键作用。这个项目经理的地位，主要是项目协调员，其身份、作用和地位也可想而知。

此时，项目经理更多是将各部门估算的项目开发计划整合为一份计划，并设置一些阶段点进行宏观控制。在跨部门工作产生冲突、不一致时，项目经理出面提醒、通知和协调，用一个人的力量来保障跨部门接口问题。可观的说，这种模式比之前的职能式效率要高一些，至少有人对总体目标负责了。但同时，它的缺陷也很明显，项目经理更多起到提醒督促作用，甚至是配置管理、质量保证的部分结合体。因为人力资源不属于他整体协调，因此项目组成员更多还是听从部门经理的安排，在应对突发事件或临时变更时，项目经理的作用少的可怜。由于项目经理向总经理负责，项目经理有很多时间是一个传话筒角色。
我们不难想象，在这样的定位下，虽然最多的时候项目管理部有3名项目经理，其中还不乏有PMP专家，但是由于可以控制的点不多，做的几个项目都有不同程度的延迟、质量也平平，做完项目后便有理智的。但换个角度，这种模式还是有成功的机会的，就是利用个人魅力充分沟通、影响项目组，以及利用总经理的参照权利。可惜，这对人的要求太高了。

3、矩阵式项目管理
事情的发展通常是螺旋式上升的。公司在职能式、协调型项目管理的运作过程中，逐步认识到一个有效、可行的项目管理需要一方面规范化产品开发模型（v型、增量迭代型）、另一方面提升项目经理的权利（使得项目经理有考核项目组成员的权利）。在这种条件下，公司第一次进入矩阵项目管理模式，先后经历了弱矩阵和平衡矩阵项目管理两个阶段。我们这里的弱矩阵，是指项目经理在项目管理过程中有对项目成员的考核能力，但最终的考核还是放在各自的部门经理处。这样，项目经理在保证项目TQC方面有了一定能力，项目经理的威信也逐步提升。弱矩阵下，每个项目成员有两个老板，一个是项目经理一个是部门经理，它覆盖了项目和部门对人力的需求。但在实际操作中，在项目开发过程中，如果职能部门有一些能力提升的临时工作（如，软件平台建设、客户问题解决等），项目成员不敢直接得罪部门经理，会影响项目的有效工作时间。还有一个问题是，项目开发有进度等方面的压力，通常会忽略能力提升方面的总结、分析工作，影响新项目的有效开展。

认识到了弱矩阵的问题，在公司面临开发一款突破性的产品时，选择了平衡矩阵模式，甚至是有一定的强矩阵模式。也就是说，项目经理负责所有项目成员的考核，部门经理提供或多或少的辅助考核（部门工作占用更少）。这样项目组成员归属感有了，同时项目经理根据需要设置了良好的项目激励指标，充分释放了大家的生产力，项目也自然容易成功。

总结起来，矩阵式的优缺点及适用范围如下，大家可以参考：
优点：通过项目协调员或项目经理可以使各项目目标平衡，避免资源重置。对于关联性强的各类复杂项目可以实施成组管理，系统考虑问题。
缺点：中层管理人员为2个以上主管工作，当有冲突时，会处于两难困境；处理不好会出现责任不明、争抢功劳现象。
适用范围：需要利用多个职能部门的资源而且技术相对复杂，但由不需要技术人员全职为项目工作的项目，特别是某个项目需要同时共享某些技术人员时。

btw，纯项目经理管理模式在it行业用的相对少，因为项目资源不能共享会造成不同程度的资源浪费。

总的来说，我一直这样认为：如果项目经理的能力足够，无论哪一种项目组织结构都能保障项目成功；适合的项目组织结构，降低了对项目经理综合素质的要求。

以上是在公司内部对项目管理的理解，下回谈谈外界交流、实践的经验分享。
感谢大家有耐心读了这么久。

[ 本帖最后由 pharos 于 2008-3-25 09:40 编辑 ]

pharos 上传了这个附件：

2008-3-24 22:06

职能.JPG (63.91 KB)

2008-3-24 22:06

项目协调.JPG (62.65 KB)

2008-3-24 22:06

弱矩阵.JPG (53.44 KB)

2008-3-24 22:06

平衡矩阵.JPG (53.33 KB)

2008-3-24 22:06

强矩阵.JPG (70.34 KB)

__________________

书案常逢谷雨霖
MSN:cabinhome@sohu.com
BLOG:http://space.itpub.net/3433/
种下思想，收获行动；种下行动，收获习惯；
种下习惯，收获品格；种下品格，收获人生！

“我的项目管理之路”有奖征文活动已截稿！

只看该作者

goroot
初级会员

精华贴数 0
个人空间 0
技术积分 2 (153494)
社区积分 0 (91038)
注册日期 2003-8-18
论坛徽章:0

#15

使用道具

发表于 2008-3-27 10:01

谢谢分享！

只看该作者

pharos
谷雨霖

精华贴数 4
个人空间 4863
技术积分 6454 (186)
社区积分 439 (1414)
注册日期 2001-12-11
论坛徽章:114

#16

使用道具

发表于 2008-3-31 16:23

一个现代企业我们可以把它比作为自然界的生命体，而项目则是企业的基础细胞。于是，项目管理的成熟程度标志着组织是高级的还是低级的。如果一个企业的项目管理多是分立的，项目之间没有参照、借鉴的，我们可以认为这个企业是一个单细胞动物或低级动物。我们很清楚，单细胞动物抵抗自然界干扰的能力是很低的，应该说它始终处在生存的边缘。如果项目是组织级别，企业内有体系的项目管理制度，包括WBS分解经验库、项目开发效率和质量数据库、最佳实践库、项目通用激励制度等等，相信这个组织的机体是有活力的。
因此，项目管理不是分立的，在企业内部是需要通过管理逐步成熟。当然，对这个的理解，也是后来慢慢体会的。这得益于公司开展的一些培训，个人参加业内的一些交流活动和自身的认证。
在公司项目运作了一段时期后，领导认识到分立的项目管理在资源共享、风险控制方面的不足，恰逢那个阶段CMM认证刚刚风行。于是，公司便拿出一笔钱，要通过CMM2认证。个人很幸运参与到这个认证过程中，并被指派为EPG组长。
起初，我个人对这样的认证比较反感（相信很多公司的技术人员都有同感），认为更多是要求大家多写一大堆文档，项目的效率和质量不一定能提升（很不幸，后来认识到老板也是这种态度，导致项目认证的终止）。在做完项目管理流程制定和后期较长时间的实践后，自己对它深邃的内涵有了深入理解。
关于CMM体系，相信大家现在已经很有认识了，它将组织成熟度定义为5个等级--初始级、可重复级、已定义级、已管理级和优化级。对于CMM2，简单的说可以认为它是项目级的，即建立了项目管理体系；CMM3 是组织级，强调软件工程过程和管理过程已经被定义和集成。从上面的定义，我们可以看出CMM2主要是建立体系的项目管理制度，是有意义的。
在开展CMM2认证的过程中，涉及费用问题，我们选择了一家不是很知名的认证公司帮助咨询（当时CMM认证公司还很少，费用也很高的30-50万）。公司先从各行政部门抽调1-2名工程师作为CMM2认证组成员，然后咨询老师便开始了枯燥、单调的CMM培训。在大家基本了解什么是CMM2之后，开始依据公司现状建立项目管理制度。这个过程是最痛苦的过程。因为本身技术人员在文档撰写工作方面不是很有心得，特别是制定一个从无到有的项目管理制度本身就很有挑战（改变一个人的行为方式是很艰难的，制度的制定势必会激起很多所谓的冲突）。若干个KPA的程序、规程、指导书、模板、checklist等都经历了2-3遍的撰写、评审和修改，CMM项目组很是疲惫，大家占用了大量的业余时间。
最后，终于将体系文档建立起来，进入实际项目参照执行阶段。问题恰恰就在这个阶段爆发了。前面提到，老板有改进的初衷并投了资，同时却对CMM2认证有一定个人成见。在项目参照执行阶段，原计划选定的2个项目组，由于涉及项目产品上线的压力和部门经理的阻力，老板大手一挥--暂不执行认证！于是，认证很遗憾的停止了。但是，整个EPG组整理的项目管理制度和体系后来在大家的努力推动下被落实下来，对项目成功运作打下了坚实基础。特别是，这个过程培养了一批在项目管理有深入理解的人才。
这批人深入理解了项目管理中需求管理的重要性、项目计划制订的严谨性（项目计划包括进度计划、配置计划、质量保证计划等）、变更的严格控制和项目总结（日常、milestone和项目收尾的总结）。这些是项目成功的基础，也是cmm2中的精髓。

进一步说，项目管理的成熟可以参照CMM/CMMI 5层等级的思想来描述，1-5级的项目成功的关键可以用下面这个QA作用图来描述：

我们可以看出，低成熟度的项目管理的成功更多工作是通过在过程中的指导和监督来保障，而高成熟度的则是通过在组织内部的度量和过程改进，用数据、制度来保证项目的成功。
也就是说，在低成熟度等级下，需要抽取各项目最佳实践来定义过程，并指导过程的试施， QA 在这方面的工作最多。随着过程的完善、制度化和实施， QA 的工作重点逐渐转向了过程评审和产品审计。当企业的过程成熟度达到 4 级或 5 级以后，对过程的遵守已经成为员工的一种习惯，过程和产品的审查需求减少，而度量和过程能力的优化又成为 QA 的工作重点。
现在，我们国家的项目管理多处于l2-l3的地位，如何整理最佳实践定义过程指导项目开发是项目总监的重要工作。最佳实践有哪些？需求撰写、需求评审等等，从实践来到实践中去。

回过头来看，一个组织如果提升其项目管理能力，来自内因的动力是最关键的。在这种动力下，人们制定的流程、规范是切合实际的，落实也是扎实的，也能理解、把握 CMM等管理模型的深邃。如果改进的动力来自外因，通常是所谓的“不通过某某认证公司无法接什么什么项目”，那么它的学习是形式化的，势必被开发人员、项目经理最终抛弃，走入形式化。

正是通过CMM2这个项目的锻炼，培养了我系统思维、步步为营推进的工作习惯，也使得自己在项目管理方面获得了升华。拓展了视野，打开了与行业同仁交流的窗口！

下面是在做CMM2认证时，我们做的部分工作成果大纲供大家参考：
当时CMM2认证的部分工作成果

__________________

书案常逢谷雨霖
MSN:cabinhome@sohu.com
BLOG:http://space.itpub.net/3433/
种下思想，收获行动；种下行动，收获习惯；
种下习惯，收获品格；种下品格，收获人生！

“我的项目管理之路”有奖征文活动已截稿！

只看该作者

louis_xu
来无踪去留影

来自深圳
精华贴数 0
个人空间 0
技术积分 1782 (876)
社区积分 267 (1872)
注册日期 2008-1-18
论坛徽章:8

#17

使用道具

发表于 2008-3-31 17:38

留个脚印，相当经典

__________________

拼命赚钱买彩票！

只看该作者

pharos
谷雨霖

精华贴数 4
个人空间 4863
技术积分 6454 (186)
社区积分 439 (1414)
注册日期 2001-12-11
论坛徽章:114

#18

使用道具

发表于 2008-4-8 09:59

      CMM/CMMI体系帮助项目经理从组织项目管理成熟度角度给出诠释，而美国PMI协会的PMBOK则是从项目经理个体角度对项目管理给予深入指导。个人理解，PMBOK对做了一段时间项目管理的项目经理来说很有醍醐灌顶的作用。PMI协会针对PMBOK知识进行认证，也就是我们所说的PMP认证。
      之前我提到，在初入项目管理时结识的项目经理他本身是PMP专家，也是我第一次听说PMP。后来，才了解到PMP考试是美国项目管理协会针对评价个人项目管理知识能力而设计的一项全世界范围内的考试。该考试题量大，涉及面广，通过分数要求高。不仅要求应试者对现代项目管理知识体系和概念有深刻的理解，还要求其对以美国为代表的西方职业文化与道德有广泛的了解。
      当时因为工作时间相对短，而PMI官方要求至少从事3-5年项目管理的人员方可参加，于是报考的念头被暂时搁置下来。
      PMP考试自从九十年代末引入国内，报考人数逐年增加，通过率基本能达到90%。现在，随着大家对PMP逐步认知，越来越多有意于项目管理的人加入到认证考试的行列。这里面，也出现了一些工作时间不长、为了考试而考试的人。同时，这也刺激了PMI协会的赚钱意       图，即对候选者的资质审核投入不足。
      2004年，自己感觉需要在项目管理上系统提升，加之恰好夫人去国外出差几个月。于是，参加PMP认证又重新提到日程上来。于是，开始系统咨询PMP认证的事宜。
      首先，要解决报名资质和报名的事情。
      关于资质，上面说过报考PMP，PMI协会要求报考人员要有3-5年的项目管理经历。这些经历要在PMI官方报名程序中如实填写，整个报名程序是全英文。
      另外的资质，就是考生需要在考前有40小时左右的PDU培训证明费。
      什么是PDU？
      PDU，专业发展单元PDUs（Professional Development Units）：获得和记录专业发展活动提供一个标准的目标机制，凡修读于PMI的注册教育提供者(R.E.P.)的课程，均可取得PDU。
      怎么获得PDU证明？
      这个证明在国外比较容易获得，比如参加项目协会活动、撰写项目管理文章、公司项目管理证明等等，因为欧美有信用体系，他们认可西方国家的这些项目管理活动。但在中国，这种证明很难落到实处，原因很简单--1、欧美不信任中国；2、中国人的外文能力不够。于是，PMI协会认可的培训机构便成为大家获得PDU的主要途径。
      通常，PMP培训机构的培训课程，包括PMBOK资料学习、模考。培训时间也在40小时左右。而培训费的官价是4800元/人，各培训机构各有所不同。
      考试报名费为考试费：3300/人（国家外专局收，全国统一）。通常，培训机构帮助考生报名。有的机构为了吸引学生，声称可以免费一次补考。
      获得了40 PDU，还有一个关键任务就是填写报名书。这项工作可是纯英文工作。你要先将自己的项目管理经历整理出来，然后翻译成文，填写报名表，请培训机构审核，转换为PDF文件，发给PMI协会。对于外文不好的人，这个工作是很痛苦的。当然，培训机构也承揽了这项工作，收费代报名。（只要中国人瞄准了某个认证考试，那这个认证就离流水线作业不远了，比如著名的新东方）
我的报名表整整准备了3天才最终通过。

      其次，选择培训机构。
      PMP认证考试最早是由国家外专局引进的，同期也开展相关的考前培训。同期的其他商业培训机构在很长的时间内非常少，主要以现代卓越为代表（应该向他们收广告费啊）。
      随后，北京还诞生了清华光环项目管理学院和神州巨龙公司。这两家培训公司相对比较专业，负责任。其中，光环是以清华著名的项目管理大师强茂山老师为核心，其他老师辅以管理。它的特点是学院派，系统教学，小组自我学习、交流。而神州巨龙是由几个有志向的PMP个人组建的，他们的特点是小组式教学、团队交流、服务更特质化、跨全国。起初，巨龙的讲师并不著名，多以考试通过的PMP为主。后来，交流的多了，几个讲师也就很著名了，比如肖老师。
      我在选择时，巨龙还不是很大的公司，而光环的考试通过率已经相当高--90%多，而且一个班的人比较多、相互交流的空间比较大--60人左右。加之一个同事曾经在那里培训，说我们公司在那里的声誉比较好。于是，我选择了光环。后来，成为光环学友会的vip会员。
      这里介绍的是几个主要的机构，其他机构也如雨后春笋般诞生，各有千秋。其实，只要你认真通读PMBOK，参加哪个培训都是可以。
      剩下的就是参加培训、准备考试。
      这个阶段是很艰苦的。一方面每个人都有工作，只能在下班后学习，而连续1月的培训都在周末进行；另一方面，PMBOK是纯英文的，它的思想是西方思维，你要理解和遵从西方人的习惯。
      这个阶段主要是看书、做题、交流、答疑。
书主要包括，核心是PMBOK，我通读了3遍。
<<PMBOK>> www.pmi.org 重要描述PMI 知识体系的框架，说明项目经理要做什么。
<<Project management development guide>> PMI的理念
<<如何准备PMP考试>> 其近300道模拟题。
<<PMP 模拟试题>> 非常重要通过做题发现自己的不足，对考试当然很有帮助

做题
快速、准确做题是准备中很关键的，因为考试要求最多60秒一道题。培训机构会提供一些参考题，这些题基本够用，关键是反复训练锻炼西方思维模式。

最后是参加考试
注意：考试如果有时间，可以系统请假3-5天，将PMBOK九大知识模块的输入，输出，工具和技术背一背。
1)．考试时间四个小时，中英文双语，共200道单选题，答对137题通过，题目一般都很长。平时做模拟题时候一定要训练自己1分钟内做1题的速度，否则做不完。
2)参考书尽量看英文的，考题虽然是中英文双语，部分中文翻译有问题（其实问题不是很大，以中文也可以，不清楚再看英文）。

考试通过了，一身轻。但细细品味这个过程，你会发现作为项目管理你已经很系统的学习了。其中，特别是挣值管理的概念很让人深入学习和实践。

PMBOK项目管理大纲基本如下：
第一章  项目管理基础和框架
第二章  项目集成管理
第三章  项目范围管理
第四章  项目时间管理
第五章  项目成本管理
第六章  项目质量管理
第七章  项目人力资源管理
第八章  项目沟通管理
第九章  项目风险管理
第十章  项目采购管理

相关介绍可以参考：
PMBOK项目管理pps

[ 本帖最后由 pharos 于 2008-4-8 10:02 编辑 ]

__________________

书案常逢谷雨霖
MSN:cabinhome@sohu.com
BLOG:http://space.itpub.net/3433/
种下思想，收获行动；种下行动，收获习惯；
种下习惯，收获品格；种下品格，收获人生！

“我的项目管理之路”有奖征文活动已截稿！

只看该作者

alv97
初级会员

精华贴数 0
个人空间 0
技术积分 14 (68547)
社区积分 1 (40532)
注册日期 2007-3-25
论坛徽章:0

#19

使用道具

发表于 2008-4-16 16:20

非常好.慢慢看.

只看该作者

pharos
谷雨霖

精华贴数 4
个人空间 4863
技术积分 6454 (186)
社区积分 439 (1414)
注册日期 2001-12-11
论坛徽章:114

#20

使用道具

发表于 2008-4-16 18:06

QUOTE:

原帖由 alv97 于 2008-4-16 16:20 发表

非常好.慢慢看.

常来

__________________

书案常逢谷雨霖
MSN:cabinhome@sohu.com
BLOG:http://space.itpub.net/3433/
种下思想，收获行动；种下行动，收获习惯；
种下习惯，收获品格；种下品格，收获人生！

“我的项目管理之路”有奖征文活动已截稿！

只看该作者