范文一:IT项目经理成长手记
IT 项目经理成长手记
前言 伴随着信息时代的到来,我国 IT 行业飞速发展, IT 项目的投资已经位居全国各个行业 的前几名。多年来我国对于 IT 项目管理人才的需求日益增长, IT 项目经理也已经成为国家 急需的热门职业,正面临着前所未有的良好发展机遇。
现在项目管理理论方面的书籍比较多,但系统地介绍一线实战经验的并不多。本书以虚拟 人物小 M 的成长路径为主线、案例故事为引导,从一个实践者的角度介绍项目管理的实战 技能和经验教训。
围绕小 M 在职业生涯发展的不同阶段所遇到的不同挑战,本书的内容分成了三个部分: 1) 第一部分介绍了技术出身的小 M 选择和规划项目经理的职业路径的过程,并结合 IT 项 目的特点介绍了项目管理的一些基本概念和知识,作为读者阅读本书的预备知识。
2) 第二部分介绍了小 M 担任了项目经理之后,从四处碰壁到能够独立管理一个大型项目 的成长过程,介绍单项目管理实战技能和经验教训。
3) 第三部分重点介绍了小 M 升任项目总监之后,在管理一组相互关联的项目群过程中遇 到的各种问题以及解决的过程,分享项目群管理的实战技能和经验教训,帮助读者从组织 级角度思考项目管理体系建设的要点。
本书以案例为基本单元,案例从项目管理、质量管理,软技能三个方面进行组织。每节均 以主人公小 M 相关的一个案例故事开头,之后结合案例进行分析和讨论,介绍问题解决方 法和经验教训。
本书的重点是介绍实战中如何将理论
1) 理论到实践的最后 1公里。掌握了项目管理理论还不能立刻成为项目经理,还需要掌 握一些必要的工具、方法和经验,提高实践技能才能胜任。
2) 人际关系的
本书的预期读者一是工作在一线的项目经理、质量经理、项目总监;二是有志于向项目经 理方向发展的软件开发和测试人员;三是主管交付的总经理或公司高管。希望读者通过阅 读本书,可以在以下方面有所收获:
1) 为那些有志于向项目管理方向发展的技术人员,提供一条可以参考的 IT 职业发展路径; 帮助他们了解项目经理的发展前景、要求和方法,明晰职业规划。
2) 帮助读者通过案例了解理论怎样
3) 帮助读者从组织级角度思考项目管理体系,以便拓展更广阔的职业发展空间。
4) 本书分享了一些简单实用的项目管理工具,可以拿来在工作中使用,帮助理清思路、 提高效率。
最后需要说明,书中的案例故事尽管来源于实践,但为了方便读者阅读,进行了必要的编 撰。书中主要人物也是虚拟的,切勿对号入座。主要角色有以下几个:
1) 小 M :主角,本书主要以其职业生涯的历程为线索。
2) S总:事业部总经理,小 M 的顶头上司和导师。
3) 老 Q :小 M 的搭档,主管质量,与小 M 既是好朋友,但工作中也会经常发生争执。
4) G总:客户方的项目负责人,小 M 的客户接口人。
目录
序一
序二
自序
前言
第 1章
1 2我适合做项目经理吗
1 3项目经理的知识和技能
1 3 1专业知识
1 3 2实践技能
1 3 3软技能
1 4项目经理的职业规划
1 4 1涉足项目管理
1 4 2成为项目经理
1 4 3成为资深项目经理
1 4 4成为项目总监
第 2章 IT 项目管理的那些事 --入门知识 2 1项目的基本概念
2 1 1什么是项目
2 1 2项目的特点
2 2项目管理的入门知识
2 2 1什么是项目管理
2 2 2项目的生命周期
2 2 3项目的组织结构
2 3项目管理的知识体系
2 3 1项目管理过程
2 3 2项目管理的知识域
2 3 3项目管理的框架
2 3 4小结
第 3章初为项目经理
3 1项目经理难当 --理想和现实
3 1 1
3 1 3
3 1 4经验与教训
3 2最忙乱的第 1周 --项目启动
3 2 1第一周的工作计划
3 2 2第一天的工作成果
3 2 3启动的准备工作
3 2 4项目启动会
3 2 5培训开始了
3 2 6经验与教训
3 3甲方乙方 --商务项目全过程
3 3 1需求背后的需求
3 3 2双方眼中的不同生命周期
3 3 3客户为什么做这个项目
3 3 4经验与教训
3 4都是婆婆 --认识项目干系人
3 4 1项目的组织关系
3 4 2项目打破了组织的平静
3 4 3婆婆也能帮你
3 4 4经验与教训
第 4章理论到实践 --
4 1做不完的项目 --目标和范围
4 1 1目标和范围
4 1 2
4 1 3为什么会产生分歧
4 1 4重要的文档 --范围说明书
4 1 5经验与教训
4 2三个臭皮匠 --计划制定的方法
4 2 1计划的
4 2 2形成活动清单
4 2 3排序和网络图分析
4 2 4资源和进度计划
4 2 5项目预算
4 2 6经验与教训
4 3计划还是计
4 3 1计划怎样
4 3 2任务的分解和委派
4 3 3检查和调整
4 3 4经验与教训
4 4赚钱比花钱难 --被忽略的成本
4 4 1用真实数据套概念
4 4 2绩效指数的含义
4 4 3怎样预测成本
4 4 4活学活用的实例分析
4 4 5经验与教训
4 5提心吊胆的那些事 --正视风险
4 5 1风险管理流程
4 5 2识别风险
4 5 3风险分析
4 5 4风险计划
4 5 5风险监控
4 5 6经验与教训
4 6什么都改,客户就满意了吗 --如何管理变更 4 6 1为什么会变更
4 6 2变更失控的后果
4 6 3变更控制的流程
4 6 4经验与教训
第 5章项目中的沟通
5 1不要所有问题都自己扛 --沟通的层次 5 1 1沟通不畅惹的祸
5 1 2事半功倍的高层沟通
5 1 3沟通的层次
5 1 4经验与教训
5 2开会也是任务 --有计划地沟通 5 2 1项目沟通计划
5 2 2项目与外部的沟通
5 2 3非正式沟通的利与弊
5 2 4经验与教训
5 3需求和需要 --如何与客户沟通 5 3 1了解需求的
5 3 2满足
5 3 3真诚比技巧更重要
5 3 4经验与教训
第 6章质量
6 1质量经理该管什么 --质量管理几件事 6 1 1项目经理的冤家
6 1 2质量管理管什么
6 1 3质量经理温柔的一面
6 2摸不着的财富 --项目配置管理 6 2 1什么是配置管理
6 2 2配置管理的准备工作
6 2 3配置管理的日常工作
6 2 4项目结束时的配置管理工作 6 2 5经验与教训
6 3你是来找茬的 --改变对评审的观念 6 3 1为什么要做评审
6 3 2怎样组织评审活动
6 3 3一次有效的评审
6 3 4经验与教训
6 4别让别人揭家丑 --让测试深入人心 6 4 1悲壮的
6 4 2为什么要设这么多道
6 4 3如何组织测试活动
6 4 4紧张的
6 4 5经验与教训
6 5找出问题之后 --缺陷追踪
6 5 1为什么要进行缺陷跟踪
6 5 2怎样进行缺陷跟踪
6 5 3使用缺陷跟踪工具
6 5 4缺陷的分析与度量
6 5 5经验与教训
第 7章团队建设基本功
7 1没权就不能管好团队吗 --项目经理的领导力
7 1 1权力之外的招数
7 1 2项目经理双重角色
7 1 3领导力过头的错误
7 1 4经验与教训
7 2谁是谁 (Who Is Who)--如何让项目组快速热身
7 2 1事前准备 --个人自画像
7 2 2个人介绍 --简直是一次才艺秀
7 2 3自由组队 --形成兴趣小组
7 2 4项目大家庭的档案
7 2 5经验与教训
7 3我不是超人 --渡过团队的震荡期
7 3 1同舟共济的团队
7 3 2自己的问题自己最清楚
7 3 3改变团队
7 3 4团队才是超人
7 3 5经验与教训
7 4别人眼中的你 --怎样与
7 4 1项目组中的个性员工
7 4 2团队会议的作用
7 4 3一次团队会议
7 4 4经验与教训
7 5饭桌上的话题 --如何让聚餐更有意义
7 5 1提前设计的话题
7 5 2饭桌上的
7 5 3感人肺腑的留言
第 8章身为项目总监
8 1忙!不知道忙什么 --项目总监是干什么的
8 1 1项目总监的生态环境
8 1 2从哪里入手
8 1 3新官上任三把火
8 1 4经验与教训
8 2项目经理怎么知道每天该干什么 --《项目经理手册》的诞生 8 2 1问题的原因
8 2 2解决问题的思路
8 2 3《项目经理手册》的建立过程
8 2 4如何推进《项目经理手册》
8 2 5经验与教训
8 3三分钟怎么说清项目进展 --三层计划方法
8 3 1从
8 3 2三层计划的分层
8 3 3三层计划的制定过程
8 3 4三层计划的跟踪
8 3 5经验与教训
8 4总经理的肩膀 --怎么创造项目
8 4 1跟客户谈什么
8 4 2如何整合资源
8 4 3怎样签新项目
8 4 4经验与教训
第 9章项目群的质量管理
9 1将交付物集中起来 --组织级的配置管理
9 1 1从
9 1 2从
9 1 3从
9 1 4经验与教训
9 2再好的过程不执行也没用 --如何进行过程审计
9 2 1怎样确保过程规范
9 2 2怎么进行过程审计
9 2 3怎样让审计深入项目
9 2 4找出问题是为了改进
9 2 5经验与教训
9 3捂不住的问题 --如何让交付过程透明化 9 3 1项目经理为什么想
9 3 3敢不敢把问题
9 3 4经验与教训
第 10章项目群的团队管理
10 1败则拼死相救 --资源规划和调配
10 1 1为什么要人总这么急
10 1 2报工到报派工系统
10 1 3执行中的问题
10 1 4资源调配和协调
10 1 5人力资源规划
10 1 6经验与教训
10 2
10 2 1了解清楚情况
10 2 2采取什么态度处理
10 2 3问题处理过程
10 2 4项目组中的沟通
10 2 5经验与教训
10 3项目经理的摇篮 --项目经理的社区
10 3 1为什么建立项目经理社区
10 3 2什么是项目经理社区
10 3 3活动的内容安排
10 3 4几次经典的活动
10 3 5经验与教训
尾声组织级项目管理之路
附录 IT 项目管理工具索引
参考文献
自序
我 1998年博士毕业后加入联想,后随集团的分拆转入神州数码。十多年来一直从事应用软 件领域的项目管理工作,从一个普通技术人员开始,踏上了项目管理的职业生涯。
从最初负责几个人的小型项目都很吃力,到慢慢地能硬着头皮顶住 60~70人的大项目,再 到后来逐渐成为一名管理十几个项目的项目总监。 2005年初,我担任了神州数码融信软件 有限公司副总裁,开始全面管理西安开发中心,这是我项目管理职业生涯的最高点。这期 间虽然工作压力非常大,但我有幸亲历了一个开发中心从小变大的全过程,也有机会从公 司的角度思考项目管理的一些问题。
2007年底,我调任神州数码的一个合资子公司任 COO ,开始负责公司的整体经营,也离 开了我熟悉的项目管理领域。本来一些项目管理的经验教训只会成为一段回忆了,但是一 个偶然的机会促成了我写此书的想法。
2009年我在软件协会过程改进分会的大会上作了一个关于组织级项目管理实践的演讲,引 起了圈内很多朋友的兴趣;后来,又多次以沙龙的形式与同行朋友们分享。交流中我发现 很多问题都是我曾经遇到过的,一些经验教训对大家很有帮助。在一次沙龙活动之后,一 位资深的 IT 圈朋友向我提议:
籍非常多,但是关于实战经验的书籍就太少了。
我觉得这是个很好的提议,但是写书对我来说却是件非常有挑战的事。因为自己虽然有一 些实践经验,但理论水平有限,写出来的东西都很
犹豫中想起了发生在郭为先生(神州数码董事局主席)身上的一个小故事:2005年郭总带 领神州数码一些干部参观西安开发中心,在了解了开发中心的情况之后非常开心。同行的 人员中一部分很振奋,但是也有一部分不以为然,觉得与国际化的开发中心相比,西安开 发中心无论规模上、水平上都有很大的差距。
当时正值神舟 5号载人飞行成功,听到这些意见之后郭总就问了个问题:
在座的人异口同声地说:
郭总继续又问道:
是的,国际的先进经验再好,那是别人的;我们的管理经验再
于是,从 2010年初开始就和我共事多年的好友韩秋泉一起着手撰写本书。其中,韩秋泉负 责了质量管理相关的第 6章和第 9章,我则撰写了其他章节。在撰写的过程中,重点从三 个方面分享了我们个人的一些实践体验。
第一,项目经理的职业生涯规划。对很多从事技术工作的朋友来说,项目经理不仅是个
的人适合做项目经理,项目经理的知识和技能要求,以及今后可能的发展路径。希望读者 在了解了这些之后再慎重做出职业选择;而一旦选择,也必须要有
第三,项目经理的软技能。项目经理中的
我们自知水平有限,疏漏错误之处难免,之所以仍愿意将这些最基层的经验教训与读者分 享,是因为我们觉得:虽然自己刚从一条崎岖的小路上蹒跚穿过,虽然自己还满身伤痕, 但只要将我们在小路上经历的或看到的各种困难告诉他人,就可能帮到他人。这就是我们 写此书的目的和最大的心愿。
特别要感谢我的良师益友周伯生老师。他在健康欠佳的情况下仍细致地审阅了全书,提出 了很多中肯意见和宝贵建议,并特别为此书作序。让我印象深刻的是周老师还特别指出了 原书稿中的一些文字错误,让我对一个前辈学者的严谨风范肃然起敬,也为自己的疏漏而 汗颜。
最后,想把此书作为送给女儿的一个礼物。她刚刚出生不久我就离开家到西安工作,一眨 眼的功夫她就长大了。希望通过此书让女儿知道,不在她身边的日子里,我还是做了一些 有意义的事情。
潘东
2012年 11月 IT 项目经理成长手记
编辑推荐 来自项目第一线的管理经验!
知名软件企业高管的原创手记整理 --为你讲述 IT 项目经理是怎样
亲历情景案例分析 +实用职场工具分享! --各种悲催!各种吐槽!帮你应对 IT 项目中最不愿 意碰到的那些事儿!
口口相传,倾囊相授 --做 IT 项目经理不得不掌握的三重修炼:明确自己的职业生涯规划, 跨越理论到实践的最后一公里,用
名家点评 我和潘东是战友,我们曾经一起艰苦的奋斗。由于年长,也见证了潘东毕业后的 成长历程。他把自己的经验和心得写出来,我很高兴。从一个实践者的角度,完成这样一 个作品,可贵,可敬。对于从业者,具有很强的阅读性。 --神州数码董事局主席 郭为 项目管理对于软件行业的意义,怎么说都不为过。因此,我鼓励软件工程技术人员要多学 学项目管理,这本《 IT 项目经理成长手记》就是一本很好的备选读物。作者潘东曾就职于
中国最大的系统集成企业 -神州数码、他带过典型的中国式大项目,他熟悉来自西方的项目 管理在中国落地生根的所有细节、他亲身走过技术人员到项目经理到大企业副总裁职业道 路、他是名校博士、他是很棒的演讲者,还有最后一点,他一直爱
项目管理与技术开发是一条完全不同的职业道路,要实现从技术到管理的转变与成长,最 需要更多的实践与前辈的指导。主人公小 M 在项目管理职业发展道路上碰到了诸多困惑、 障碍与磨难,但最终在 S 总的指导下实现了跨越,收获成功与喜悦,成长为一名合格的项 目总监。您是否也正行进在项目管理职业之路上?没有谁天生就是成功的项目管理者,让 我们一起追随小 M 留下的
作者简介
潘东,毕业于上海交通大学计算机系,获博士学位。现任鼎捷软件股份有限公司副总裁, 中国软件协会过程改进分会副会长。
潘东 1998年加入联想,后随分拆加入神州数码。曾经负责多个大型软件项目以及组织级 项目管理,曾任神州数码西安开发中心总经理,神州数码通用技术有限公司的 COO 的职务。 潘东在软件领域从业多年,具有丰富的实战经验。他根据项目案例开发的《项目管理实战》 课程曾为业内多家知名企业培训,目前仍兼任
韩秋泉,毕业于华东师范大学软件学院,获工程硕士学位。现任神州数码融信软件有限公 司的 PMO 总经理、事业部总经理。
韩秋泉曾任多个大型软件项目的项目经理,历任神州数码西安开发中心的质量总监、总经 理等职务。他在质量和测试方面有深厚功底,在西安开发中心建立了一支约 200人的专业 测试队伍和完整测试体系,并成功地将交付能力推向市场,为建设银行、兴业银行、中信 银行、光大银行等客户提供了测试服务。
序一 潘东提出让我给他的书写点什么。我犹豫了一下,还是答应了。
犹豫的原因,我不是项目管理专家,我无法给出专业的评价。一怕辱没了潘东的成就,二 怕误导读者。
答应的原因,我们是战友,我们曾经一起艰苦的奋斗。由于年长,也见证了潘东毕业后的 成长历程。他把自己的经验和心得写出来,我很高兴。
读了周教授的序,我就释然了。周教授的评价是中肯的。有了专家的评价,我就不用担心 我有误导的嫌疑了。
第一次见到潘东,是我们在一个大型银行的项目上,因为需要同另一家国际知名的 IT 企业 合作,所以压力来自两方面。整个项目经历了两年,三方演绎了一场三国演义,虽然过去 快十五年了,但记忆犹新。这也许就是我和潘东一起真正体会什么是项目管理的开始。 神州数码的转型,很重要的一点就是核心能力的改变。作为 IT 服务的综合提供者,项目管 理是核心能力之一。而其他核心能力的积累也往往依靠项目管理能力的转化。譬如,核心 技术的积累,首先是基于最佳实践,而最佳实践只有依靠强有力的项目管理能力才能脱颖 而出。而把最佳实践转化成解决方案,也是靠项目管理能力的支撑。最后再通过项目管理, 把解决方案转化成核心技术产品或平台。
潘东的作品是对我们过去项目管理工作的总结和提升。作品中甚至用了很多我们的习惯用 语和案例。在读的过程中,很多画面跃然纸上:我们对方法论的争论,我们被合作伙伴挤 兑的痛苦,人员流失的烦恼,项目经理权限的讨论 ?? 项目管理不仅会涉及内部员工,还有 客户,合作伙伴。它是典型的系统工程。如果没有系统思维是无法理解和完成项目管理的 全部内容的。
在工业化的过程中,中国最缺少的就是流程化和项目化。而两化融合的过程中,我们又往
往忽视了信息产业的工业化。因此从一个实践者的角度,完成这样一个作品,可贵,可敬。 对于从业者,具有很强的阅读性。
神州数码控股有限公司董事局主席
郭为
2012年 12月 7日序二
序二 20世纪初期,享有 “ 科学管理之父 ” 美誉的弗雷德里克 ·温斯洛 ·泰勒(Frederick W. Taylor )先生开创了项目管理领域,并相继有甘特图、关键路径法、工程评价和评审技术 等项目管理技术的出现。 20世纪中期,曾获得美国总统勋章、享有 “ 现代管理学之父 ” 美誉 的彼得 ·德鲁克(Peter F. Drucker )先生,则提出了从目标管理到知识工人管理的思想。工 作分解结构、基线、项目干系人、项目三角形等概念相继引入管理领域。当代项目管理界 根据对项目管理所关注的重点,可以归纳为最优化、过程学、组织学、成功学、决策学、 权变学、治理学以及营销学等八个学派,项目管理作为一门学科和专业化管理职业在全球 得到迅速的推广和普及。
目前我们所处的信息化时代,是人类进入综合利用物质、能量和信息三种资源的知识经济 时代,许多组织的未来,将取决于它们驾驭信息技术的能力,与之相应的 IT 项目管理已经 成为一个热门的前沿领域。在这方面的理论著作很多,有描述经典软件开发的项目管理 ; 有描述新型软件开发的项目管理 ;还有描述迭代增量式开发的统一软件开发过程 。
在总结项目管理最佳实践方面,最具有代表性的有美国项目管理协会组织编写的《项目管 理知识体系指南》 (PMBOK GUIDE) 第 4版,以及美国 CMU/SEI主持编写的《能力成熟度模 型集成》 (CMMI DEV V1.3) 。项目管理是把知识、技能、工具和技术应用于项目活动,以达 到项目的要求,前者通过合理运用和整合启动、规划、实施、监控和收尾 5个过程组的 42个项目管理过程来实现,后者则从直接涉及项目管理的需求管理、项目策划、项目监控、 集成 2002. 项目管理、定量项目管理、供应商协议管理以及风险管理等 7个过程域的 59个 实践的优化组合来实现。
但是,迄今为止,系统介绍一线实战经验的项目管理书籍很少,因此,《 IT 项目经理成长 手记》一书就显得特别珍贵。我有幸率先拜读了这本著作。本书以项目管理、质量管理、 软技能三个方面进行组织的案例为基本单元,采用叙事的风格,首先结合 IT 项目的特点介 绍项目管理的基本概念和知识,接着介绍单项目管理的实战技能和经验教训,再进一步介 绍项目群管理的实战技能和经验教训。其中的重点是介绍实战中如何将理论联系实际,项 目经理如何处理好客户关系、人员沟通以及团队建设。
本书不仅可供一线项目经理、质量经理和项目总监阅读,也可供有志于向项目经理方向发 展的软件开发和测试人员,以及公司的各级高管阅读,当然还可以供对项目管理领域感兴 趣的所有人员阅读。
北京航空航天大学计算机学院教授
周伯生 于北京
2012年 6月 19日
第 1章 “ 迷你 ”CEO—— 项目经理不简单
1.1 项目经理是干什么的 小 M 是一名毕业于名牌大学软件专业的研究生,在学校中随导师 参加过一些国家级的科研项目。毕业后,小 M 如愿加入某知名 IT 公司。
为了适应管理要求,该公司已经引进并实施了 “ 项目型 ” 管理模式,企业内按行业划分成事 业部,项目是事业部最基本的业务运作单位;各事业部内设专职的项目经理,项目经理对 项目的全过程负责 , 因此是公司最重要的基层管理角色之一。
小 M 觉得,项目经理受人尊重、令人羡慕。不仅羡慕他们每次完成一个项目回到公司后受 到英雄般的欢迎,跟公司高层可以面对面直接沟通,还有老客户、老同事经常寄来的土特
目标的综合协调与优化。项目管理应综合协调好时间、费用及功能等约束性目标,在相对 较短的时期内成功地达到一个特定的成果性目标。
对于 IT 公司来说,项目管理能力是核心竞争力之一。尽管针对具体行业特点会采用不同的 管理方法,但基本的管理要素相同,包括以下几个方面:
范围(Scope ):指为了实现项目目标必须完成的所有工作。它指出了 “ 完成哪些工作就可 以达到项目的目标 ” ,也说明了 “ 完成哪些工作项目就可以结束了 ” 。如果没有工作范围的定 义,项目就没有结束的标准。
时间(Time ):指完成项目所有工作需要的时间,也指每个活动的具体开始和完成日期。 项目管理一个关键是确定活动的开始和结束时间,并考虑清楚它们之间的依赖关系。
成本(Cost ):指完成项目需要的所有开销,包括人力成本、原材料、设备租金、分包费 用和咨询费用等。 IT 项目中人力成本占相当大的比例,又难以准确估计工作量,是管理难 点之一。
质量(Quality ):指项目满足明确或隐含需求的程度。包括各种特性及这些特性需要满足 的要求。有时还可能对项目的执行过程设定明确要求,必须遵循一定的规范和标准,提供 过程得以有效执行的证据。
以上 4个要素,范围、时间、质量、成本,简称为 S-TQC 。对一个项目来说,最理想的情 况就是 “ 多、快、好、省 ” 。 “ 多 ” 指工作范围大, “ 快 ” 指需要的时间短, “ 好 ” 指项目的质量高, “ 省 ” 指项目的成本低。但实际上这 S-TQC 之间是相互关联的,改变一个指标的同时会影响 另一个指标,如图 2-1所示。图 2-1项目管理要素间的关系
举个大家熟悉的例子 —— 装修。假定原计划需要两个月完成,但由于原住房提前拆迁,必 须 1个半月内完工。因此, “ 时间 ” 的要素发生了变化,为了缩短工期可能采取什么样的措 施呢?
措施一:原来厨房是自己做框架,买贴塑门面,现改为买整体厨房;显然代价是成本提高 了。
措施二:原来墙面要刷 4遍立邦漆,这非常耗费时间,现在刷两遍就算了;但代价是质量 降低了。
措施三:先不铺木地板,灯具以后再安装;注意,这时已经改变工作范围了。
措施一和措施二没有改变范围,但改变了成本、质量,对应图 2-1中的路径 B ;而措施三 改变了项目的范围,对应图 2-1中的路径 C 。从这个例子可以看出,在项目中往往需要均 衡多种因素做出取舍,才能使最终的方案实现项目的目标。
2.2.2 项目的生命周期
为了有效完成某些重要的可交付成果,在需要特别控制的位置将项目分段,就形成了项目 阶段。项目生命周期是通常按顺序排列,而有时可能相互交叉的各项目阶段的集合。[4]各个项目阶段的工作重点不同,涉及组织不同,人员技能不同,将项目划分成合乎逻辑的 一些子集,有助于管理、规划和控制。
项目的可交付成果以及中间的活动会因为项目的不同而有很大的差异。因此,项目阶段的 名称和数量取决于参与项目的组织的管理与控制需要、项目本身特征及其应用领域特点。 但是,不论项目的规模和复杂性,不论划分方法的大小简繁,一般的生命周期大概包括 4个部分:启动项目、组织和准备、执行项目工作和结束项目,如图 2-2所示。图 2-2项目 的生命周期
项目生命周期与产品生命周期不同。产品生命周期是指创造产品的过程,通常各个阶段 按顺序排列且不相互交叉。
完成阶段工作的标志称为里程碑。里程碑包括 4个要素:时间点,标志性事件,交付物, 关闭条件。到达里程碑后要对项目进行评估,确定是按计划继续执行,还是进行必要的变
更和调整,如果有必要甚至会终止项目。
里程碑上的交付物通过了正式评审而进入受控的状态就形成了项目的基线。基线其实是一 些重要的里程碑上的交付物,是后续工作的基准;基线一旦建立之后,如果要改变,需要 通过变更流程进行有序的控制,否则会引起后续工作的混乱。
2.2.3 项目的组织结构
项目的组织结构有两个含义:一是一个项目组的内部结构,二是在公司内如何组织一个项 目组。这里所说的是第二种情况,包括如项目的资源获取和运作方式。参考《项目管理知 识体系指南》[4],项目的组织结构包括职能型、项目型和位于两者之间的矩阵性, 3种 典型组织结构的特点比较见表 2-1。表 2-13种典型组织结构的特点比较
结构特征 职能型 矩阵型弱矩阵 平衡矩阵 强矩阵 项目型项目经理职权 很小或没有 有限 小 到中 中到大 大到几乎全权可用的资源 很少或没有 有限 少到中 中到多 多到几乎全部预算 控制者 职能经理 职能经理 职能经理
项目经理 项目经理 项目经理项目经理角色 兼职 兼职 全职 全职 全职项目管理行政人员 兼 职 兼职 兼职 全职 全职
1. 职能型
典型的职能型组织是一种层级结构,每名雇员都有一位明确的上级。向下根据专业、权限 和管辖范围分成各职能部门,通过内部管理流程确保职能部门之间相互协调完成工作。 例如,公司内有市场、销售、产品、交付和服务几大部门,各部门相对独立工作。这种组 织结构中也有 “ 项目 ” ,但没有专职的项目经理,项目管理的概念相当弱,可能仅仅是将一 些持续运作业务的某些方面按项目方式进行管理,例如按 “ 项目 ” 归集每一笔订单从售前到 结束的所有费用。
职能型组织具有专业化程度高、专家集中、利于个人发展等优点。但也有明显的缺点,例 如个人工作内容面向流程的输入 /输出,缺乏沟通和合作;没有项目经理全局负责,一旦中 间环节出了问题没人关心;人员强烈忠诚于自己部门,而非客户或项目;多个项目存在谁 前谁后的矛盾,如图 2-3所示。图 2-3职能型组织 2. 项目型
与职能型组织相反的是项目型组织。项目型组织的大部分资源都用于项目工作,会为特定 项目专门组织项目组。项目经理有相当的权力,可以整合内部和外部资源,并直接管理所 有项目组成员,团队成员通常集中办公。
项目型组织中也有被称为 “ 部门 ” 的组织单元,但这些部门或者直接向项目经理汇报,或者 为各个项目提供支持服务。
项目型组织的优点是项目经理统一领导,所有人都为项目经理工作;项目组对客户高度负 责;目标一致,一切围绕项目进行组织。缺点是组织资源利用率较低,项目之间沟通和协 作程度低;由于没有专业技能和知识交流的场所,不利于个人发展;人员也没有归属感, 临近项目结束时非常焦虑。而且一旦启动一个新项目,就会打乱了原有的组织结构,如图
2-4所示。图 2-4项目型组织
3. 矩阵型
矩阵型组织同时具有职能型组织和项目型组织的特征。项目组成员隶属于职能部门,但会 为特定项目成立项目组,在项目执行中小组成员服从项目经理领导。
矩阵型也分三种类型。弱矩阵型组织保留了职能型组织的大部分特征,其项目经理的角色 更像是协调员或联络员,而非真正的项目经理,如图 2-5所示。强矩阵型组织则具有项目 型组织的许多特征,拥有掌握较大职权的全职项目经理和全职的项目行政人员,如图 2-6所示。平衡矩阵组织虽然承认全职项目经理的必要性,但并未授权其全权管理项目,如图 2-7所示。图 2-5弱矩阵型组织
注:灰框表示参与项目活动的职员
图 2-6强矩阵型组织
注:灰框表示参与项目活动的职员
图 2-7平衡矩阵型
注:灰框表示参与项目活动的职员
矩阵型组织的优点非常明显:职能部门的基础核心技能可以供所有项目组使用;各职能部 门的员工在项目组内协同工作,可增进横向交流;员工有归属感,并有交流和学习的机会; 各部门对项目进展有清楚的了解;员工的双向汇报可以避免压制。缺点是员工要为两个上 级工作,管理比较困难;沟通环节多,平衡项目经理和部门经理的权限困难。
现在的 IT 企业中,矩阵型的居多。而且,很多组织可能在不同层次上用到上述不同结
构。例如,在强矩阵型组织中,也有可能在某个职能部门中建立专门的项目团队,实施重 要的项目。职能部门中的团队可能具备项目型组织中项目团队的许多特征,拥有来自职能 部门的全职人员,可以制定自己的办事流程,甚至可以不按照标准或正式的汇报结构运作。 这种类型的组织称为复合型组织,如图 2-8所示。
图 2-8复合型组织
注:灰框表示参与项目活动的职员
2.3 项目管理的知识体系 2.3.1 项目管理过程
过程是指为了完成预定的产品、成果或服务而执行的一系列相互关联的行动或活动。项目 管理过程则描述了如何组织、规划和完成项目的各项工作,确保项目自始至终顺利进行的 一系列过程。
项目管理包括 42个管理过程,每个管理过程包括输入、输出、所需工具和技术等要素。根 据其逻辑关系,把这 42个过程归类为启动、规划、执行、监控和收尾 5个大的过程组 [4],如图 2-9所示。
图 2-9管理过程组之间的关系
启动过程组。包含获得授权,定义一个新项目或现有项目的一个新阶段,正式开始项目或 阶段的一个过程。启动过程组可以由项目控制范围以外的组织完成。
规划过程组。包含明确的项目范围,定义和优化目标,为实现上述目标而制定行动方案的 过程。项目生命周期中发生重大变更可能会引发重新的一个或多个规划过程。每个里程碑 也会对计划进行重新的审核。
执行过程组。完成项目管理计划中确定的工作以实现项目目标的一组过程。过程中不但要 协调人员和资源,还要按照计划推进和实施项目活动。执行中可能根据进展情况更新项目 计划,这时要进行变更请求。变更请求批准之后,需要对项目管理计划进行修改。
监控过程组。跟踪、审查和调整项目进展与绩效,监控和评估项目偏差,必要时采取纠正 行动,保证项目计划的执行,实现项目目标。
收尾过程组。为正式结束项目、项目阶段或合同责任而实施的一组过程。需要正式验收项 目或阶段成果,按正规的程序结束工作任务。
项目管理的各个过程,通过输入和输出相互联系起来就构成整个项目管理活动。根据重要 程度,项目管理过程可以分为核心过程和辅助过程两类。核心过程指那些大多数项目都必 须具有的项目管理过程,这些过程具有明显的依赖性,在项目中的执行顺序也基本相同。 辅助过程指那些视项目实际情况可取舍的项目管理过程。
2.3.2 项目管理的知识域
《项目管理知识体系指南》[4]总结了项目管理实践中成熟的理论、方法、工具和技术, 把项目管理知识划分为 9个知识领域(整合、范围、时间、成本、质量、人力资源、沟通、 风险和采购),每个知识领域包括数量不等的项目管理过程,如图 2-10所示。图 2-10项 目管理的知识域
项目整合管理:指为确保项目各项工作能够有机地协调和配合所展开的综合性和全局性的 项目管理工作和过程。其作用是保证各种项目要素协调运作,对冲突目标进行权衡折中, 最大限度满足项目相关人员的利益要求和期望。
项目范围管理:指为了实现项目目标,对项目的工作内容进行确定和控制的管理过程。其 作用是保证项目计划包括、且仅包括为成功地完成项目所需要进行的所有工作。范围分为 产品范围和项目范围。产品范围指将要包含在产品或服务中的特性和功能,产品范围的完 成与否用需求来度量。项目范围指为了完成规定的特性或功能而必须进行的工作,项目范 围的完成与否是用计划来度量的。二者必须很好地结合,才能确保项目的工作符合事先确 定的规格。
项目时间管理:指为了确保项目最终按时完成的一系列管理过程,其作用是保证在规定时 间内完成项目,包括活动排序、活动资源估算、活动持续时间估算、制定进度计划以及进 度控制等过程。
项目成本管理:指为了保证完成项目的实际费用不超过预算费用的管理过程,其作用是保 证在规定预算内完成项目。
项目质量管理。是指为了确保项目达到客户所规定的质量要求而实施的一系列管理过程, 作用是保证满足承诺的项目质量要求。
项目人力资源管理。是指为了保证所有项目相关人员的能力和积极性都得到最有效地发挥 和利用所采取的一系列管理措施和管理过程,以确保最有效地使用人力资源完成项目活 动。
项目沟通管理:指为了确保项目信息及时且恰当地生成、收集、发布、存储、调用并最终 处置所需的各个管理过程。《中国项目管理知识体系》[3]中取消了沟通管理,设置了信 息管理;把一部分沟通管理的内容纳入了信息管理。
项目风险管理:指对项目可能遇到的各种不确定因素进行风险识别、风险估计与量化、制 定对策和风险监控等一系列工作,其作用是识别、分析以及对项目风险进行即时的响应。 项目采购管理:指为了从项目实施组织之外获得所需资源或服务所采取的一系列管理措施。 项目采购管理由下列项目管理过程组成:采购规划、发包规划、询价、卖方选择、合同管 理以及合同收尾。对于执行机构与其他部门内部签订的正式协议,也同样适用。当涉及非 正式协议时,可以使用项目的资源管理和沟通管理的方式解决。
2.3.3 项目管理的框架
项目管理知识体系,可以看成是由 5个过程组与 9大知识域形成的矩阵,对应地把 42个 项目管理过程,归入矩阵相应的 “ 格子 ” 中,就确定了项目管理的整体框架。这个矩阵中的 内容就是一个项目经理应该掌握的基本管理过程,见表 2-2。但是,特别要注意的是,项 目管理过程不等于项目的执行过程,而是做事情的方法。
表 2-2项目管理框架
知识
领域 项目管理过程组启动过程组 规划过程组 执行过程组 监控过程组 收尾过程组整合
管理 制定项目章程 制定项目管理计划 指导与管理项目执行 监控项目工作
实施整体变更控制 结束项目或阶段范围
管理 收集需求
定义范围
创建工作分解结构 核实范围
控制范围 时间
管理 定义活动
排列活动顺序
估算活动资源
估算活动持续时间
制定进度计划 控制进度 成本
管理 估算成本
制定预算 控制成本(续)
知识
领域 项目管理过程组启动过程组 规划过程组 执行过程组 监控过程组 收尾过程组质量
管理 规划质量 实施质量保证 实施质量控制 人力
资源
管理 制定人力资源计划 组建项目团队
建设项目团队
管理项目团队 沟通
管理 识别干系人 规划沟通 发布信息
管理干系人期望 报告绩效 风险
管理 规划风险管理
识别风险
实施定性风险分析
实施定量风险分析
规划风险应对 监控风险 采购
管理 规划采购 实施采购 管理采购 结束采购
2.3.4 小结
项目管理的知识体系详细地概括了项目管理的各个方面,但对于项目经理来说这仅仅是必 须知道的内容。一方面,项目经理需要将这些理论知识与具体的业务领域结合起来才能发 挥效益;另一方面,这些知识还应该与具体的实践相结合,知道该怎么做,什么时候做, 用
什么工具做,才能实际落地。而这些,就需要在项目中逐渐积累,掌握实践技能和软技能 之后才能实现。
第 3章 初为项目经理
3.1 项目经理难当 —— 理想和现实 小 M 经过了项目管理培训,属于懂项目管理的人了。在 领导的安排下,又作为助理项目经理实际管理了一个小型研发项目,取得了不错的成绩。 鉴于其良好表现,小 M 被提拔为项目经理,并被派入一个具有战略意义的项目组。
初为项目经理,小 M 沉浸在被提拔的喜悦中 , 踌躇满志地奔赴项目组。在去项目组的路上, 小 M 盘算着上任之后如何展开工作,如何开始项目经理生涯的第一站。
首先,要 “ 运筹帷幄 ” ,系统地制定一份详细的计划。
其次,要 “ 沉着应战 ” ,遇到困难不能在项目组面前表现出丝毫的慌乱。
第三 , 要 “ 同仇敌忾 ”, 搞好项目组的团队建设 , 共同解决各种问题。
小 M 甚至还设想项目结束凯旋而归时,在公司受英雄般的迎接,然后对项目成员 “ 论功行 赏 ” ,让他们知道跟着自己没白干!
对未来还没有畅想完,小 M 已经到了项目组。迎接他的是几个满脸疲惫的项目成员,其中 两人还是刚刚走出校门的学生,他们对小 M 的到来没有丝毫热情的表示,只是简单地打了 个招呼就又各自忙自己的工作去了。就靠这几个人就能完成具有 “ 战略意义 ” 的项目?小 M 的希望开始破灭了。
初步了解情况之后小 M 才知道,这个项目刚刚签约,还没有正式启动。见到第一个客户就 听到了抱怨:客户的主要人员已经到位,而公司关键人员还没到位。公司的每一个人都在
应付客户!
项目的混乱可想而知,压力下有的成员控制不住情绪经常争吵,项目组内外人际关系都比 较紧张,小 M 理想中 “ 同仇敌忾 ” 的团队根本不存在。甚至,当项目组成员听小 M 说起 “ 同 仇敌忾 ” 这个词时都笑起来,开玩笑地说:“ 同仇敌忾?我们这里同床异梦都算好的,一般 都是同室操戈。 ”
进入项目组才两天 , 内忧外患使得小 M 已经有些 “ 惊惶失措 ” 了,甚至患了 “ 电话恐惧症 ” ,听 到电话铃响就心惊肉跳,不知道又有什么情况出现。
刚刚听说公司方面已经接到了客户投诉 , 认为小 M 没有工作思路 , 要求换个项目经理。听到 这个消息小 M 非常沮丧,没想到成了 “ 替罪羊 ” !回想起自己在路上对项目的幻想,发现与 现实的差距如此之大。苦笑道:“ 项目经理难当啊! ” 理想与现实的差距如图 3-1所示。 图 3-1理想与现实的差距
3.1.1“ 研发 ” 和 “ 商务 ” 项目的差异
小 M 不是一个轻易认输的人,绝不会中途放弃。不过,仍然很是不解,自己技术出身,不 乏项目管理的理论知识,甚至还有很好的沟通表达能力,也有研发项目经验。这次为什么 会感觉这么困难呢?
小 M 第一个管理的项目是内部 “ 研发 ” 项目,仔细想来虽然研发项目与商务项目在管理方法 上有很多共同之处,但仍然有一些显著的区别:
1. 学费 vs.官司
以前作研发项目的时候没有客户, “ 客户 ” 就是自己的领导。如果遇到了挫折,领导总是鼓 励说 “ 失败是成功之母 ” 。即使努力后真的失败了,领导也说 “ 好好总结,积累经验,就当交 学费了! ” 。
现在的项目有真正的客户,有商务合同。客户总是拿着合同说事儿,如果失败了就要面对 巨额的赔偿,甚至是官司。来项目组之前,领导还特别交代过,这是公司在该领域的第一 个大型项目,如果失败了,意味着公司以后可能再也没有机会进入这个领域了。
小 M 觉得,两种项目失败的后果有巨大的差异,在商务项目上自己本身心理承受的压力要 大很多。
2. 创新 vs. 规范
做研发项目的时候,不仅允许失败,更允许创新,甚至鼓励创新。小 M 以前都认为文档、 流程和规则是一种束缚,因此对于团队的管理相对松散,很多工作都是先试验,成功之后 再补文档。
但是,看到项目组现在松散和混乱的工作状况,小 M 第一次意识到文档和规范在项目中的 重要性。很多事客户说了好几遍也没着落,确定的东西过两天又说忘了,连个记录都没有, 自己要是客户也会不耐烦了。
小 M 反省,以前觉得整理文档是浪费时间,现在觉得不仅不会浪费时间,而且能提高沟通 效率,不用一遍一遍说,一遍一遍澄清。以前觉得一些打破流程的做法是创新,现在觉得 本文档下载自 360文档中心, www.360docs.net 更多营销 , 职业规划 , 工作简历 , 入党 , 工作报 告 , 总 结 , 学 习 资 料 , 学 习 总 结 ,PPT 模 板 下 载 , 范 文 等 文 档 下 载 ; 转 载 请 保 留 出 处 :http://www.360docs.net/doc/info-ed204dfa1ed9ad51f01df2b6.html
范文二:《IT项目经理成长手记》读后感---王森122909
《 IT 项目经理成长手记》 读后感
国际教育学院
中法计 121
王森
122909
《 IT 项目经理成长手记》是来自项目第一线的管理经验!它来源于真实的 工作经验。通过口口相传,亲囊相授的叙述手法交给读者 --做 IT 项目经理不得 不掌握的三重修炼:明确自己的职业生涯规划,跨越理论到实践的最后一公里, 用“软技能”解决硬问题。
本书的两位作者:一潘东,毕业于上海交通大学计算机系,获博士学位。现 任鼎捷软件股份有限公司副总裁, 中国软件协会过程改进分会副会长。 潘东 1998年加入联想, 后随分拆加入神州数码。 曾经负责多个大型软件项目以及组织级项 目管理,曾任神州数码西安开发中心总经理,神州数码通用技术有限公司的 COO 的职务。 潘东在软件领域从业多年, 具有丰富的实战经验。 他根据项目案例开发 的《项目管理实战》课程曾为业内多家知名企业培训,目前仍兼任“联想之星” 特训班讲师,为创新企业的高管提供项目管理培训。
二韩秋泉, 毕业于华东师范大学软件学院, 获工程硕士学位。 现任神州数码 融信软件有限公司的 PMO 总经理、 事业部总经理。 韩秋泉曾任多个大型软件项目 的项目经理, 历任神州数码西安开发中心的质量总监、 总经理等职务。 他在质量 和测试方面有深厚功底, 在西安开发中心建立了一支约 200人的专业测试队伍和 完整测试体系,并成功地将交付能力推向市场,为建设银行、兴业银行、中信银 行、光大银行等客户提供了测试服务。囊相授——做 IT 项目经理不得不掌握的 三重修炼:明确自己的职业生涯规划,跨越理论到实践的最后一公里,用“软技 能”解决硬问题。 他们都在自己的工作领域中取得了不小的成功。
《 IT 项目经理成长手记》非常适合作为国内众多 IT 企业中的项目经理、质 量经理、 项目总监, 以及主管交付的总经理或公司高管提升管理技能的案例教程, 同时也为有志于向项目经理方向发展的软件开发和测试人员描绘了一条极具参 考价值的职业发展路径, 并有助于读者从组织级高度理解项目管理, 拓展更广阔 的职业发展空间。
我认为成为项目经理必须要具备以下的技能:
第一, 沟通和协调能力一定要高。 随着解决方案的逐步深入和复杂, 一个项 目可能涉及的内外部资源越来越多, 需要大量的沟通和协调工作。 过程中, 需要 取得多方的支持, 整合各方力量, 平衡全局和伙伴利益, 才能顺利完成方案制定、 售前支持、合同签订等过程。另外,因为经常要面对众多客户和员工,不仅需要 点对点的沟通能力,还要有比较好的宣讲能力,能感染众多的受众。
第二, 团队工作和激励员工必不可少。 作为项目群中人力资源的调配者, 除 了要从公司中获取资源, 更多情况下需要自己获取和组织资源, 有计划地培养骨 干和建立团队。有些事情要“举重若轻”,尽管自己要承担很大压力,却要在下 属面前表现得非常轻松。有的事情要“举轻若重”,除了自己要承担压力,还要 向下传递压力, 让项目团队重视并激发员工潜在的能力, 提升效率。 这种激励的 传递还要因人而异把握好尺度,不能把人压垮,也不能完全放松的工作。
范文三:敢问路在何方——项目经理成长手记
敢问路在何方——项目经理成长手记
唐僧师徒赴西天取经,不畏艰险,锲而不舍,历经八十一难最终修成正果。这是一段伟大的旅程,敢问路在何方——路在脚下~世上没有不能到达的目标,最远的路途就在脚下,这是西游记让我们深深感动的地方。西游记绚丽多彩的魔幻世界其实是现实社会的投影,平凡的人们为了生存和发展都会历经磨难。作为一名IT业的项目经理,我深刻地体会到:这是一个充满挑战和艰辛的职业,但也是一个自我发展和提升的途径。一帆风顺的经历不会增长才干,帮助个人成长的其实是困难和障碍以及克服它们的过程,只有经历风雨,才能迎来彩虹。
本文以我负责的某大型教育培训网站(简称教育网系统)建设项目为背景,结合项目实战经验谈一些体会。这个项目是我初任项目经理时经历的,现在回顾起来,当时所遇到的问题以及解决过程还历历在目。
甲方不提供硬件测试环境,争取提前试运行发现问题
该项目要建设一个在线学习和教育管理网站,提供在线学习和考核的平台,实现培训工作的信息发布和组织管理。平台所使用的课件由其他系统制作,本系统需提供课件上传管理功能。系统采用Oracle数据库、WebLogic应用服务器,通过F5实现负载均衡,使用基于J2EE技术的B/S架构,要求能够运行在Unix平台上。
接手这个项目后,我首先对系统的运行环境做了初步了解。客户方的机房有多台IBM AIX小型机和PC机。WebLogic应用服务器将部署在AIX小型机上,在一台AIX小型机上会同时部署多家公司的应用系统,每个应用系统在WebLogic中都通过建立独立的域(Domain)来进行管理。
任何应用系统在上线前都应进行严格的测试,而且测试环境要与实际运行环境一致,因为应用系统的功能、性能在不同操作系统环境下的表现是不一样的,因此为了保证系统的稳定运行,需要准备AIX小型机作为测试环境。但是我们以前承接的项目使用的基本都是HP和SUN的服务器,没有AIX服务器。
我意识到这是一个重要风险,必须妥善应对。客户的机房有一些测试设备可供使用,我与销售经理沟通,看有无可能得到客户许可使用机房的测试设备。这个项目当时还处于售前阶段,正在签署合同。销售经理反馈回来的结果是,客户不负责提供测试环境,并且在合同中对此增加了明确的条款:甲方不负责提供任何测试设备和环境。我在客户这边碰了壁,只好另外想办法,首先想到的是从公司获得支持。
项目启动后,我在项目计划中上报了这个风险,希望公司帮助调配一台测试用机,或者采购一台AIX小型机,在各个项目之间共享,解决多个项目可能会遇到的同样问题。项目管理部很快打来电话,询问了详细情况,表示公司调配有一定困难,其他项目并没有闲置的小型机,目前也没有采购机器的预算,希望项目组尽力设法解决,并强调一定要妥善处理,不能因此发生问题。
回想我当时的心情真不好受,感觉孤立无援,但是我从这个过程中也学到了重要的一课:项目经理的作用不只是发现问题、提出问题,更重要的是解决问题。系统测试的硬件环境不具备,客户和公司都不能提供支持,这是一个必须解决的难题。
这个问题放在现在是很好解决的,可以花少量费用短期租赁,但当时IT租赁业还没有发展起来,可以提供设备的大公司价格很高,而价格较低的小公司设备又不全。我询问了两个关系不错的合作伙伴公司能否借用,对方当下没有正好闲置的机器。看来这个风险不能避免,那就要从如何减小风险的影响程度上寻找对策。我一方面继续寻找机器,一方面积极与客户沟通,最终得到客户的支持,允许我们提前到正式环境下部署,在系统大范围试运行前先小范围试运行一段时间,这样就为解决可能面临的问题赢得了时间。
排查问题定位原因,但遭咨询方质疑
在我的推进下,系统得以提前部署到正式环境中,但不久就发现了一个严重的问题:课件的视频文件通常在几百兆左右,在上传到AIX平台时,速度非常慢,只有40KB/s,以至于浏览器页面失去响应,只有十几兆的小课件可以上传成功,稍微大一点的课件就传不上去了。 我组织项目团队深入分析了这个问题,通过比较测试环境与正式环境的不同之处,定位问题的原因可能来自“网络环境”或者“操作系统”,此外应用程序上传组件在正式环境下能否正常运行也有待验证,根据初步分析,我们制定并实施了以下问题排查措施: 在客户方环境下使用FTP工具上传大视频文件,并使用网络监测工具观察上传过程是否正常,结果上传速度很快,网络监测也完全正常,基本排除了网络因素;
在客户方Windows环境下搭建WebLogic应用服务器进行测试,在上传代码中增加日志输出功能,打印分段传输文件过程中每段的用时和传输速度,结果上传速度很快,可以确定上传组件正常运行;
对操作系统的问题,为进一步缩小问题范围,我们在公司搭建了HP Unix测试环境,上传速度仍然很快,这样基本确定问题是由AIX操作系统带来的。
我组织项目团队成员继续奋战,查阅了AIX操作系统的大量资料,在团队技术骨干的分析和论证下,最后定位问题原因在于一个AIX操作系统的网络传输参数。于是我们写了一份分析报告提交给用户,说明了排查的过程和结论,请求客户方允许我们调整AIX操作系统的一个参数,问题就可以迎刃而解。
但是事情并不像预期的那样顺利,客户方请的咨询公司认为我们的报告证据不足,认为问题是应用系统的错误造成的,应修改应用系统,不应调整参数,而且由于AIX系统上运行着多家公司的多个应用系统,调整参数可能对其他系统产生影响,因此咨询公司坚持在没有得到权威结论前不同意调整参数。
我们一时找不到AIX系统验证我们的结论,但是客户方要求我们尽快解决问题,迫于时间压力,我们只好采用了权宜之计,修改了技术方案,从系统设计上做了调整,增加了一种课件上传管理的方式,避开了直接通过应用系统上传,这样做会增加一些操作步骤,但能够满足课件后台维护的要求,客户也认可这种修改方案,这个问题基本得到了解决。 用事实回应质疑,赢得甲方肯定
问题虽然得到解决,但我的心里却很不踏实:我们的排查结论是否正确还没能在AIX系统上进行验证,这次绕开陷阱的做法只是权宜之计,对系统今后的推广和产品化等工作会带来隐患,也许我们在未来还会再次遇到这个陷阱。此外,由于咨询公司多年服务于客户方,有重要的地位,他们的意见会左右客户方对我们的评价。这是我必须彻底解决的又一个重要问题:如何用事实证明我们的实力和价值。
我一直没有放弃多方寻找问题的解决方法,也一直保持和合作伙伴的联系。当时我还负责另一个项目,需要第三方测试,为此请了专业的第三方测试机构。他们拥有各种品牌、型号和配置的服务器,这让我看到了转机。在第三方测试工作开展的过程中,我与测试机构的负责人建立了良好的关系,在我提出需要免费借用设备时,对方很爽快地答应了。 我们很快在AIX操作系统上搭建了应用系统,进行了期待已久的测试。选定几个不同大小的视频文件样本,在网络传输参数tcp_nodelayack为缺省值0的情况下进行测试,结果与在客户方现场的表现一样,文件上传速度为40KB/s左右,50MB以上的文件就不能成功上传。当把该参数改为1,再用样本文件测试,结果上传速度显著提高,达到4MB/s。我们详细记录了验证过程,写了一份报告发送给客户方和咨询公司,用事实证明了应用系统没有问题,排查结论是正确的,赢得了客户方对我们工作的肯定。
软件供应商中断业务,拒绝提供支持
教育网系统正式上线运行取得了很好的效果,客户方决定在其20个分支机构推广,经过方案
论证,确定以建成的教育网系统为中心,在20个机构采用分布式结构部署系统。客户方很快召开了全体会议,要求分支机构尽快完成硬件准备工作。我们了解到,分支机构的设备很多是以前客户方总部统一采购的,AIX小型机占主导,有些分支机构的业务量较大,资源比较紧张,就为此又购置了AIX小型机。
硬件准备好后,客户与我方签署了“软件开发服务”合同,要求分别根据分支机构的个性需求对教育网系统进行改造和完善。在系统推广的工作中,又出现了一个棘手的问题:系统需要使用R公司的视频服务器R Server用于播放课件,R公司在中国已经中断了基于AIX的R4及以上版本的产品销售、服务和技术支持,即使是R4也仅在AIX 4及以下版本的操作系统上进行过严格测试,而分支机构购置的AIX小型机都是AIX 5以上版本,所以根本无法得到可靠的视频服务器。总部通过一段时间积累了很多课件资源,这些资源都是基于R公司独有的视频文件格式,并需要与分支机构共享,所以不可能转移到其他视频服务器。 针对以上问题,我组织项目团队进行了分析,根据我们对R公司视频服务器的技术积累和掌握程度,可以确定:在AIX 5版本上运行未经严格测试的R4并没有问题,我们可以考虑采购R4替代高版本产品用于AIX 5。下面的问题就是如何说服R公司破例出售给我们R4。 我为此与R公司进行了多次沟通,详细说明了我们遇到的问题,希望得到支持,R公司的负责人在与美国总部沟通多次后明确表示这是总部确定的销售政策,不能破例,而且R4缺少某些新特性,对项目开发、实施不利,强烈建议我们改用其他操作系统,采购最新版本。但这就意味着客户方花费几十万购买的小型机不能投入使用,这是客户绝对不能接受的,事情一时陷入僵局。
这个问题并不孤立,还连带一些潜在问题。根据用户数量的发展情况,系统总部及其分支机构以后很有可能需要做视频服务器的集群,因此并不是只解决目前的问题就可以了,一定要未雨绸缪,否则未来仍然会面临这个问题。
在这个项目中,我方按照“软件开发服务”合同的要求,只负责软件部分,并不负责软硬件系统集成,但这个问题不解决,就无法顺利推动项目进展。突破责任的界限与职责范围,站在项目整体利益的高度,我必须设法使软件供应商改变拒绝的态度,全力支持,破例出售足够数量的R4软件使用许可,并与我们共同面对、解决出现的问题,这是关系到系统是否能顺利推广的一个关键问题。
借助甲方力量,协调软件供应商共担风险
我仔细分析了现状,列出要解决的两个具体问题:第一是说服R公司出售R4低版本产品,第二是要保证不能因为采购了R4而造成未来有些业务需求不能实现。我仔细分析了高版本新增的功能特性:在分布式环境中实现课件共享和支持移动设备。前者可以通过应用系统实现,我们已经在这方面有了扎实的技术积累,而后者虽然目前客户没有需求,但是未来怎样没有把握。
这些未定因素需要尽早摆到桌面上,把风险提出来,引起相关各方的重视,最好能够促成客户方与R公司直接对话,这样在客户面前我们可以共担风险,而且也可以借助客户方的力量推动R公司按特例处理这个问题,避免我方独立面对客户,处于不利的地位,承担过重的责任和压力。
为此,我组织了由客户方相关分支机构(包括业务部门和信息中心)、项目监理方、R公司和我方参加的项目专题会议,在会议上我详细汇报了目前的问题、建议的解决方案以及我们和R公司已做的工作的进展情况,并听取客户方的指导意见。
客户方的业务部门明确表示:未来五年内不会考虑升级到更高版本,不会有移动设备视频服务的需求。这样,我顾虑的第二个问题就打消了。R公司在会议上也表示虽然很难,但通过努力能够向美国总部申请一定数量的许可满足客户需求,如果在实施过程中出现任何问题,也将协调国内、国外的技术人员给予解决,将大力支持系统的建设。
我安排专人对此次会议做了详细的会议纪要,与会各方都在纪要上签字并各自留存纪要副本,通过协调会,各相关方都充分意识到这个问题,并进行了深入的分析和探讨,最后明确了问题的解决方案并作出承诺,为项目的顺利进展扫清了障碍。
通过解决这个问题,我体会到:在项目实施过程中,项目经理一定要主动与客户方密切合作,加强沟通,客户方的充分参与能有效地协调供应商,增强项目经理对项目的控制能力。此外,对于己方不完全掌握的技术,不能单方面过度承诺。我们要有高度负责的敬业精神,但同时也要善于通过沟通、协调与合作伙伴分担责任。
总结
项目经理在项目实施过程中经常要承受来自各方面的压力,面对各种问题,例如缺少软硬件资源或者人力资源等,在孤立无援的情况下面对各方的不支持、质疑和拒绝,项目经理要施展自身的沟通协调能力,用事实证明实力和价值,改变各方的态度,为项目赢得更多的支持、认可和帮助。
困难和障碍是最好的老师,它能够引导我们在通往成功的阶梯上一步步向上攀登。宝剑锋从磨砺出,梅花香自苦寒来,项目经理朋友们:祝愿你们在取得“真经”的路上走得更远,祝愿你们的旅程更丰富、更精彩~敢问路在何方,路在脚下~
作者简介:
董轶,IPMP B级国际高级项目经理,IBM 360?精英讲师团成员,自1996年起从事软件开发,曾任软件架构师、售前咨询顾问、项目经理、项目总负责人,具有多年大型复杂项目的管理经验。
范文四:敢问路在何方——项目经理成长手记
敢问路在何方?——项目经理成长?手记 文 / 董轶
作者以某教育?网系统建设项?目为背景,分享自己真实?的实战经验
与?心得,对项目经理的?成长有很好的?指导意义。唐僧师徒赴西?天取经,不畏艰险,锲而不舍,历经八十一难?最终修成正果?。这是一段伟大?的旅程,敢问路在何方?——路在脚下~世上没有不能?到达的目标,最远的路途就?在脚下,这是西游记让?我们深深感动?的地方。西游记绚丽多?彩的魔幻世界?其实是现实社?会的投影,平凡的人们为?了生存和发展?都会历经磨难?。作为一名IT?业的项目经理?,我深刻地体会?到:这是一个充满?挑战和艰辛的?职业,但也是一个自?我发展和提升?的途径。一帆风顺的经?历不会增长才?干,帮助个人成长?的其实是困难?和障碍以及克?服它们的过程?,只有经历风雨?,才能迎来彩虹?。 本文以我负责?的某大型教育?培训网站(简称教育网系?统)建设项目为背?景,结合项目实战?经验谈一些体?会。这个项目是我?初任项目经理?时经历的,现在回顾起来?,当时所遇到的?问题以及解决?过程还历历在?目。
甲方不提供硬?件测试环境,争取提前试运?行发现问题
该项目要建设?一个在线学习?和教育管理网?站,提供在线学习?和考核的平台?,实现培训工作?的信息发布和?组织管理。平台所使用的?课件由其他系?统制作,本系统需提供?课件上传管理?功能。系统采用Or?acle数据?库、WebLog?ic应用服务?器,通过F5实现?负载均衡,使用基于J2?EE技术的B?/S架构,要求能够运行?在Unix平?台上。
接手这个项目?后,我首先对系统?的运行环境做?了初步了解。客户方的机房?有多台IBM? AIX小型机?和PC机。WebLog?ic应用服务?器将部署在A?IX小型机上?,在一台AIX?小型机上会同?时部署多家公?司的应用系统?,每个应用系统?在WebLo?gic中都通?过建立独立的?域(Domain?)来进行管理。
任何应用系统?在上线前都应?进行严格的测?试,而且测试环境?要与实际运行?环境一致,因为应用系统?的功能、性能在不同操?作系统环境下?的表现是不一?样的,因此为了保证?系统的稳定运?行,需要准备AI?X小型机作为?测试环境。但是我们以前?承接的项目使?用的基本都是?HP和SUN?的服务器,没有AIX服?务器。 我意识到这是?一个重要风险?,必须妥善应对?。客户的机房有?一些测试设备?可供使用,我与销售经理?沟通,看有无可能得?到客户许可使?用机房的测试?设备。这个项目当时?还处于售前阶?段,正在签署合同?。销售经理反馈?回来的结果是?,客户不负责提?供测试环境,并且在合同中?对此增加了明?确的条款:甲方不负责提?供任何测试设?备和环境。我在客户这边?碰了壁,只好另外想办?法,首先想到的是?从公司获得支?持。
项目启动后,我在项目计划?中上报了这个?风险,希望公司帮助?调配一台测试?用机,或者采购一台?AIX小型机?,在各个项目之?间共享,解决多个项目?可能会遇到的?同样问题。项目管理部很?快打来电话,询问了详细情?况,表示公司调配?有一定困难,其他项目并没?有闲置的小型?机,目前也没有采?购机器的预算?,希望项目组尽?力设法解决,并强调一定要?妥善处理,不能因此发生?问题。
回想我当时的?心情真不好受?,感觉孤立无援?,但是我从这个?过程中也学到?了重要的一课?:项目经理的作?用不只是发现?问题、提出问题,更重要的是解?决问题。系统测试的硬?件环境不具备?,客户和公司都?不能提供支持?,这是一个必须?解决的难题。
这个问题放在?现在是很好解?决的,可以花少量费?用短期租赁,但当时IT租?赁业还没有发?展起来,可以提供设备?的大公司价格?很高,而价格较低的?小公司设备又?不全。我询问了两个?关系不错的合?作伙伴公司能?否借用,对方当下没有?正好闲置的机?器。看来这个风险?不能避免,那就要从如何?减小风险的影?响程度上寻找?对策。我一方面继续?寻找机器,一方面积极与?客户沟通,最终得到客户?的支持,允许我们提前?到正式环境下?部署,在系统大范围?试运行前先小?范围试运行一?段时间,这样就为解决?可能面临的问?题赢得了时间?。
排查问题定位?原因,但遭咨询方质?疑
在我的推进下?,系统得以提前?部署到正式环?境中,但不久就发现?了一个严重的?问题:课件的视频文?件通常在几百?兆左右,在上传到AI?X平台时,速度非常慢,只有40KB?/s,以至于浏览器?页面失去响应?,只有十几兆的?小课件可以上?传成功,稍微大一点的?课件就传不上?去了。
我组织项目团?队深入分析了?这个问题,通过比较测试?环境与正式环?境的不同之处?,定位问题的原?因可能来自“网络环境”或者“操作系统”,此外应用程序?上传组件在正?式环境下能否?正常运行也有?待验证,根据初步分析?,我们制定并实?施了以下问题?排查措施:
在客户方环境?下使用FTP?工具上传大视?频文件,并使用网络监?测工具观察上?传过程是否正?常,结果上传速度?很快,网络监测也完?全正常,基本排除了网?络因素; 在客户方Wi?ndows环?境下搭建We?bLogic?应用服务器进?行测试,在上传代码中?增加日志输出?功能,打印分段传输?文件过程中每?段的用时和传?输速度,结果上传速度?很快,可以确定上传?组件正常运行?;
对操作系统的?问题,为进一步缩小?问题范围,我们在公司搭?建了HP Unix测试?环境,上传速度仍然?很快,这样基本确定?问题是由AI?X操作系统带?来的。 我组织项目团?队成员继续奋?战,查阅了AIX?操作系统的大?量资料,在团队技术骨?干的分析和论?证下,最后定位问题?原因在于一个?AIX操作系?统的网络传输?参数。于是我们写了?一份分析报告?提交给用户,说明了排查的?过程和结论,请求客户方允?许我们调整A?IX操作系统?的一个参数,问题就可以迎?刃而解。 但是事情并不?像预期的那样?顺利,客户方请的咨?询公司认为我?们的报告证据?不足,认为问题是应?用系统的错误?造成的,应修改应用系?统,不应调整参数?,而且由于AI?X系统上运行?着多家公司的?多个应用系统?,调整参数可能?对其他系统产?生影响,因此咨询公司?坚持在没有得?到权威结论前?不同意调整参?数。 我们一时找不?到AIX系统?验证我们的结?论,但是客户方要?求我们尽快解?决问题,迫于时间压力?,我们只好采用?了权宜之计,修改了技术方?案,从系统设计上?做了调整,增加了一种课?件上传管理的?方式,避开了直接通?过应用系统上?传,这样做会增加?一些操作步骤?,但能够满足课?件后台维护的?要求,客户也认可这?种修改方案,这个问题基本?得到了解决。
用事实回应质?疑,赢得甲方肯定?
问题虽然得到?解决,但我的心里却?很不踏实:我们的排查结?论是否正确还?没能在AIX?系统上进行验?证,这次绕开陷阱?的做法只是权?宜之计,对系统今后的?推广和产品化?等工作会带来?隐患,也许我们在未?来还会再次遇?到这个陷阱。此外,由于咨询公司?多年服务于客?户方,有重要的地位?,他们的意见会?左右客户方对?我们的评价。这是我必须彻?底解决的又一?个重要问题:如何用事实证?明我们的实力?和价值。
我一直没有放?弃多方寻找问?题的解决方法?,也一直保持和?合作伙伴的联?系。当时我还负责?另一个项目,需要第三方测?试,为此请了专业?的第三方测试?机构。他们拥有各种?品牌、型号和配置的?服务器,这让我看到了?转机。在第三方测试?工作开展的过?程中,我与测试机构?的负责人建立?了良好的关系?,在我提出需要?免费借用设备?时,对方很爽快地?答应了。
我们很快在A?IX操作系统?上搭建了应用?系统,进行了期待已?久的测试。选定几个不同?大小的视频文?件样本,在网络传输参?数tcp_n?odelay?ack为缺省?值0的情况下?进行测试,结果与在客户?方现场的表现?一样,文件上传速度?为40KB/s左右,50MB以上?的文件就不能?成功上传。当把该参数改?为1,再用样本文件?测试,结果上传速度?显著提高,达到4MB/s。我们详细记录?了验证过程,写了一份报告?发送给客户方?和咨询公司,用事实证明了?应用系统没有?问题,排查结论是正?确的,赢得了客户方?对我们工作的?肯定。
软件供应商中?断业务,拒绝提供支持?
教育网系统正?式上线运行取?得了很好的效?果,客户方决定在?其20个分支?机构推广,经过方案论证?,确定以建成的?教育网系统为?中心,在20个机构?采用分布式结?构部署系统。客户方很快召?开了全体会议?,要求分支机构?尽快完成硬件?准备工作。我们了解到,分支机构的设?备很多是以前?客户方总部统?一采购的,AIX小型机?占主导,有些分支机构?的业务量较大?,资源比较紧张?,就为此又购置?了AIX小型?机。
硬件准备好后?,客户与我方签?署了“软件开发服务?”合同,要求分别根据?分支机构的个?性需求对教育?网系统进行改?造和完善。在系统推广的?工作中,又出现了一个?棘手的问题:系统需要使用?R公司的视频?服务器R Server?用于播放课件?,R公司在中国?已经中断了基?于AIX的R?4及以上版本?的产品销售、服务和技术支?持,即使是R4也?仅在AIX 4及以下版本?的操作系统上?进行过严格测?试,而分支机构购?置的AIX小?型机都是AI?X 5以上版本,所以根本无法?得到可靠的视?频服务器。总部通过一段?时间积累了很?多课件资源,这些资源都是?基于R公司独?有的视频文件?格式,并需要与分支?机构共享,所以不可能转?移到其他视频?服务器。 针对以上问题?,我组织项目团?队进行了分析?,根据我们对R?公司视频服务?器的技术积累?和掌握程度,可以确定:在AIX 5版本上运行?未经严格测试?的R4并没有?问题,我们可以考虑?采购R4替代?高版本产品用?于AIX 5。下面的问题就?是如何说服R?公司破例出售?给我们R4。
我为此与R公?司进行了多次?沟通,详细说明了我?们遇到的问题?,希望得到支持?,R公司的负责?人在与美国总?部沟通多次后?明确表示这是?总部确定的销?售政策,不能破例,而且R4缺少?某些新特性,对项目开发、实施不利,强烈建议我们?改用其他操作?系统,采购最新版本?。但这就意味着?客户方花费几?十万购买的小?型机不能投入?使用,这是客户绝对?不能接受的,事情一时陷入?僵局。 这个问题并不?孤立,还连带一些潜?在问题。根据用户数量?的发展情况,系统总部及其?分支机构以后?很有可能需要?做视频服务器?的集群,因此并不是只?解决目前的问?题就可以了,一定要未雨绸?缪,否则未来仍然?会面临这个问?题。 在这个项目中?,我方按照“软件开发服务?”合同的要求,只负责软件部?分,并不负责软硬?件系统集成,但这个问题不?解决,就无法顺利推?动项目进展。突破责任的界?限与职责范围?,站在项目整体?利益的高度,我必须设法使?软件供应商改?变拒绝的态度?,全力支持,破例出售足够?数量的R4软?件使用许可,并与我们共同?面对、解决出现的问?题,这是关系到系?统是否能顺利?推广的一个关?键问题。 借助甲方力量?,协调软件供应?商共担风险
我仔细分析了?现状,列出要解决的?两个具体问题?:第一是说服R?公司出售R4?低版本产品,第二是要保证?不能因为采购?了R4而造成?未来有些业务?需求不能实现?。我仔细分析了?高版本新增的?功能特性:在分布式环境?中实现课件共?享和支持移动?设备。前者可以通过?应用系统实现?,我们已经在这?方面有了扎实?的技术积累,而后者虽然目?前客户没有需?求,但是未来怎样?没有把握。
这些未定因素?需要尽早摆到?桌面上,把风险提出来?,引起相关各方?的重视,最好能够促成?客户方与R公?司直接对话,这样在客户面?前我们可以共?担风险,而且也可以借?助客户方的力?量推动R公司?按特例处理这?个问题,避免我方独立?面对客户,处于不利的地?位,承担过重的责?任和压力。
为此,我组织了由客?户方相关分支?机构(包括业务部门?和信息中心)、项目监理方、R公司和我方?参加的项目专?题会议,在会议上我详?细汇报了目前?的问题、建议的解决方?案以及我们和?R公司已做的?工作的进展情?况,并听取客户方?的指导意见。
客户方的业务?部门明确表示?:未来五年内不?会考虑升级到?更高版本,不会有移动设?备视频服务的?需求。这样,我顾虑的第二?个问题就打消?了。R公司在会议?上也表示虽然?很难,但通过努力能?够向美国总部?申请一定数量?的许可满足客?户需求,如果在实施过?程中出现任何?问题,也将协调国内?、国外的技术人?员给予解决,将大力支持系?统的建设。
我安排专人对?此次会议做了?详细的会议纪?要,与会各方都在?纪要上签字并?各自留存纪要?副本,通过协调会,各相关方都充?分意识到这个?问题,并进行了深入?的分析和探讨?,最后明确了问?题的解决方案?并作出承诺,为项目的顺利?进展扫清了障?碍。
通过解决这个?问题,我体会到:在项目实施过?程中,项目经理一定?要主动与客户?方密切合作,加强沟通,客户方的充分?参与能有效地?协调供应商,增强项目经理?对项目的控制?能力。此外,对于己方不完?全掌握的技术?,不能单方面过?度承诺。我们要有高度?负责的敬业精?神,但同时也要善?于通过沟通、协调与合作伙?伴分担责任。
总结
项目经理在项?目实施过程中?经常要承受来?自各方面的压?力,面对各种问题?,例如缺少软硬?件资源或者人?力资源等,在孤立无援的?情况下面对各?方的不支持、质疑和拒绝,项目经理要施?展自身的沟通?协调能力,用事实证明实?力和价值,改变各方的态?度,为项目赢得更?多的支持、认可和帮助。
困难和障碍是?最好的老师,它能够引导我?们在通往成功?的阶梯上一步?步向上攀登。宝剑锋从磨砺?出,梅花香自苦寒?来,项目经理朋友?们:祝愿你们在取?得“真经”的路上走得更?远,祝愿你们的旅?程更丰富、更精彩~敢问路在何方?,路在脚下~
作者简介:
董轶,IPMP B级国际高级?项目经理,IBM 360?精英讲师团成?员,自1996年?起从事软件开?发,曾任软件架构?师、售前咨询顾问?、项目经理、项目总负责人?,具有多年大型?复杂项目的管?理经验。
范文五:敢问路在何方——项目经理成长手记[资料]
敢问路在何方——项目经理成长手记文 / 董轶
作者以某教育网系统建设项目为背景,分享自己真实的实战经验与心得,对项目经理的成长有很好的指导意义。
唐僧师徒赴西天取经,不畏艰险,锲而不舍,历经八十一难最终修成正果。这是一段伟大的旅程,敢问路在何方——路在脚下~世上没有不能到达的目标,最远的路途就在脚下,这是西游记让我们深深感动的地方。西游记绚丽多彩的魔幻世界其实是现实社会的投影,平凡的人们为了生存和发展都会历经磨难。作为一名IT业的项目经理,我深刻地体会到:这是一个充满挑战和艰辛的职业,但也是一个自我发展和提升的途径。一帆风顺的经历不会增长才干,帮助个人成长的其实是困难和障碍以及克服它们的过程,只有经历风雨,才能迎来彩虹。
本文以我负责的某大型教育培训网站(简称教育网系统)建设项目为背景,结合项目实战经验谈一些体会。这个项目是我初任项目经理时经历的,现在回顾起来,当时所遇到的问题以及解决过程还历历在目。 甲方不提供硬件测试环境,争取提前试运行发现问题 该项目要建设一个在线学习和教育管理网站,提供在线学习和考核的平台,实现培训工作的信息发布和组织管理。平台所使用的课件由其他系统制作,本系统需提供课件上传管理功能。系统采用Oracle数据库、WebLogic应用服务器,通过F5实现负载均衡,使用基于J2EE技术的B/S架构,要求能够运行在Unix平台上。
接手这个项目后,我首先对系统的运行环境做了初步了解。客户方的机房有多台IBM AIX小型机和PC机。WebLogic应用服务器将部署在AIX小型机上,在一
台AIX小型机上会同时部署多家公司的应用系统,每个应用系统在WebLogic中都通过建立独立的域(Domain)来进行管理。 任何应用系统在上线前都应进行严格的测试,而且测试环境要与实际运行环境一致,因为应用系统的功能、性能在不同操作系统环境下的表现是不一样的,因此为了保证系统的稳定运行,需要准备AIX小型机作为测试环境。但是我们以前承接的项目使用的基本都是HP和SUN的服务器,没有AIX服务器。
我意识到这是一个重要风险,必须妥善应对。客户的机房有一些测试设备可供使用,我与销售经理沟通,看有无可能得到客户许可使用机房的测试设备。这个项目当时还处于售前阶段,正在签署合同。销售经理反馈回来的结果是,客户不负责提供测试环境,并且在合同中对此增加了明确的条款:甲方不负责提供任何测试设备和环境。我在客户这边碰了壁,只好另外想办法,首先想到的是从公司获得支持。
项目启动后,我在项目计划中上报了这个风险,希望公司帮助调配一台测试用机,或者采购一台AIX小型机,在各个项目之间共享,解决多个项目可能会遇到的同样问题。项目管理部很快打来电话,询问了详细情况,表示公司调配有一定困难,其他项目并没有闲置的小型机,目前也没有采购机器的预算,希望项目组尽力设法解决,并强调一定要妥善处理,不能因此发生问题。 回想我当时的心情真不好受,感觉孤立无援,但是我从这个过程中也学到了重要的一课:项目经理的作用不只是发现问题、提出问题,更重要的是解决问题。系统测试的硬件环境不具备,客户和公司都不能提供支持,这是一个必须解决的难题。
这个问题放在现在是很好解决的,可以花少量费用短期租赁,但当时IT租赁业还没有发展起来,可以提供设备的大公司价格很高,而价格较低的小公司设备又不全。我询问了两个关系不错的合作伙伴公司能否借用,对方当下没有正好闲置的机器。看来这个风险不能避免,那就要从如何减小风险的影响程度上寻找对策。我一方面继续寻找机器,一方面积极与客户沟通,最终得到客户的支持,允许我们提前到正式环境下部署,在系统大范围试运行前先小范围试运行一段时间,这样就为解决可能面临的问题赢得了时间。 排查问题定位原因,但遭咨询方质疑
在我的推进下,系统得以提前部署到正式环境中,但不久就发现了一个严重的问题:课件的视频文件通常在几百兆左右,在上传到AIX平台时,速度非常慢,
只有40KB/s,以至于浏览器页面失去响应,只有十几兆的小课件可以上传成功,稍微大一点的课件就传不上去了。
我组织项目团队深入分析了这个问题,通过比较测试环境与正式环境的不同之处,定位问题的原因可能来自“网络环境”或者“操作系统”,此外应用程序上传组件在正式环境下能否正常运行也有待验证,根据初步分析,我们制定并实施了以下问题排查措施:
在客户方环境下使用FTP工具上传大视频文件,并使用网络监测工具观察上传过程是否正常,结果上传速度很快,网络监测也完全正常,基本排除了网络因素;
在客户方Windows环境下搭建WebLogic应用服务器进行测试,在上传代码中增加日志输出功能,打印分段传输文件过程中每段的用时和传输速度,结果上传速度很快,可以确定上传组件正常运行; 对操作系统的问题,为进一步缩小问题范围,我们在公司搭建了HP Unix测试环境,上传速度仍然很快,这样基本确定问题是由AIX操作系统带来的。
我组织项目团队成员继续奋战,查阅了AIX操作系统的大量资料,在团队技术骨干的分析和论证下,最后定位问题原因在于一个AIX操作系统的网络传输参数。于是我们写了一份分析报告提交给用户,说明了排查的过程和结论,请求客户方允许我们调整AIX操作系统的一个参数,问题就可以迎刃而解。
但是事情并不像预期的那样顺利,客户方请的咨询公司认为我们的报告证据不足,认为问题是应用系统的错误造成的,应修改应用系统,不应调整参数,而且由于AIX系统上运行着多家公司的多个应用系统,调整参数可能对其他系统产生影响,因此咨询公司坚持在没有得到权威结论前不同意调整参数。
我们一时找不到AIX系统验证我们的结论,但是客户方要求我们尽快解决问题,迫于时间压力,我们只好采用了权宜之计,修改了技术方案,从系统设计上做了调整,增加了一种课件上传管理的方式,避开了直接通过应用系统上传,这样做会增加一些操作步骤,但能够满足课件后台维护的要求,客户也认可这种修改方案,这个问题基本得到了解决。
用事实回应质疑,赢得甲方肯定
问题虽然得到解决,但我的心里却很不踏实:我们的排查结论是否正确还没能在AIX系统上进行验证,这次绕开陷阱的做法只是权宜之计,对系统今后的推广和产品化等工作会带来隐患,也许我们在未来还会再次遇到这个陷阱。此外,由于咨询公司多年服务于客户方,有重要的地位,他们的意见会左右客户方对
我们的评价。这是我必须彻底解决的又一个重要问题:如何用事实证明我们的实力和价值。
我一直没有放弃多方寻找问题的解决方法,也一直保持和合作伙伴的联系。当时我还负责另一个项目,需要第三方测试,为此请了专业的第三方测试机构。他们拥有各种品牌、型号和配置的服务器,这让我看到了转机。在第三方测试工作开展的过程中,我与测试机构的负责人建立了良好的关系,在我提出需要免费借用设备时,对方很爽快地答应了。
我们很快在AIX操作系统上搭建了应用系统,进行了期待已久的测试。选定几个不同大小的视频文件样本,在网络传输参数tcp_nodelayack为缺省值0的情况下进行测试,结果与在客户方现场的表现一样,文件上传速度为40KB/s左右,50MB以上的文件就不能成功上传。当把该参数改为1,再用样本文件测试,结果上传速度显著提高,达到4MB/s。我们详细记录了验证过程,写了一份报告发送给客户方和咨询公司,用事实证明了应用系统没有问题,排查结论是正确的,赢得了客户方对我们工作的肯定。
软件供应商中断业务,拒绝提供支持
教育网系统正式上线运行取得了很好的效果,客户方决定在其20个分支机构推广,经过方案论证,确定以建成的教育网系统为中心,在20个机构采用分布式结构部署系统。客户方很快召开了全体会议,要求分支机构尽快完成硬件准备工作。我们了解到,分支机构的设备很多是以前客户方总部统一采购的,AIX小型机占主导,有些分支机构的业务量较大,资源比较紧张,就为此又购置了AIX小型机。
硬件准备好后,客户与我方签署了“软件开发服务”合同,要求分别根据分支机构的个性需求对教育网系统进行改造和完善。在系统推广的工作中,又出现了一个棘手的问题:系统需要使用R公司的视频服务器R Server用于播放课件,R公司在中国已经中断了基于AIX的R4及以上版本的产品销售、服务和技术支持,即使是R4也仅在AIX 4及以下版本的操作系统上进行过严格测试,而分支机构购置的AIX小型机都是AIX 5以上版本,所以根本无法得到可靠的视频服务器。总部通过一段时间积累了很多课件资源,这些资源都是基于R公司独有的视频文件格式,并需要与分支机构共享,所以不可能转移到其他视频服务器。
针对以上问题,我组织项目团队进行了分析,根据我们对R公司视频服务器的技术积累和掌握程度,可以确定:在AIX 5版本上运行未经严格测试的R4并没有问题,我们可以考虑采购R4替代高版本产品用于AIX 5。下面的问题就是如何说服R公司破例出售给我们R4。
我为此与R公司进行了多次沟通,详细说明了我们遇到的问题,希望得到支持,R公司的负责人在与美国总部沟通多次后明确表示这是总部确定的销售政策,不能破例,而且R4缺少某些新特性,对项目开发、实施不利,强烈建议我们改用其他操作系统,采购最新版本。但这就意味着客户方花费几十万购买的小型机
不能投入使用,这是客户绝对不能接受的,事情一时陷入僵局。
这个问题并不孤立,还连带一些潜在问题。根据用户数量的发展情况,系统总部及其分支机构以后很有可能需要做视频服务器的集群,因此并不是只解决目前的问题就可以了,一定要未雨绸缪,否则未来仍然会面临这个问题。
在这个项目中,我方按照“软件开发服务”合同的要求,只负责软件部分,并不负责软硬件系统集成,但这个问题不解决,就无法顺利推动项目进展。突破责任的界限与职责范围,站在项目整体利益的高度,我必须设法使软件供应商改变拒绝的态度,全力支持,破例出售足够数量的R4软件使用许可,并与我们共同面对、解决出现的问题,这是关系到系统是否能顺利推广的一个关键问题。
借助甲方力量,协调软件供应商共担风险
我仔细分析了现状,列出要解决的两个具体问题:第一是说服R公司出售R4低版本产品,第二是要保证不能因为采购了R4而造成未来有些业务需求不能实现。我仔细分析了高版本新增的功能特性:在分布式环境中实现课件共享和支持移动设备。前者可以通过应用系统实现,我们已经在这方面有了扎实的技术积累,而后者虽然目前客户没有需求,但是未来怎样没有把握。 这些未定因素需要尽早摆到桌面上,把风险提出来,引起相关各方的重视,最好能够促成客户方与R公司直接对话,这样在客户面前我们可以共担风险,而且也可以借助客户方的力量推动R公司按特例处理这个问题,避免我方独立面对客户,处于不利的地位,承担过重的责任和压力。 为此,我组织了由客户方相关分支机构(包括业务部门和信息中心)、项目监理方、R公司和我方参加的项目专题会议,在会议上我详细汇报了目前的问题、建议的解决方案以及我们和R公司已做的工作的进展情况,并听取客户方的指导意见。
客户方的业务部门明确表示:未来五年内不会考虑升级到更高版本,不会有移动设备视频服务的需求。这样,我顾虑的第二个问题就打消了。R公司在会议上也表示虽然很难,但通过努力能够向美国总部申请一定数量的许可满足客户需求,如果在实施过程中出现任何问题,也将协调国内、国外的技术人员给予解决,将大力支持系统的建设。
我安排专人对此次会议做了详细的会议纪要,与会各方都在纪要上签字并各自留存纪要副本,通过协调会,各相关方都充分意识到这个问题,并进行了深入的分析和探讨,最后明确了问题的解决方案并作出承诺,为项目的顺利进展扫清了障碍。
通过解决这个问题,我体会到:在项目实施过程中,项目经理一定要主动与客户方密切合作,加强沟通,客户方的充分参与能有效地协调供应商,增强项目经理对项目的控制能力。此外,对于己方不完全掌握的技术,不能单方面过度承诺。我们要有高度负责的敬业精神,但同时也要善于通过沟通、协调与合作伙伴分担责任。
总结
项目经理在项目实施过程中经常要承受来自各方面的压力,面对各种问题,例如缺少软硬件资源或者人力资源等,在孤立无援的情况下面对各方的不支持、质疑和拒绝,项目经理要施展自身的沟通协调能力,用事实证明实力和价值,改变各方的态度,为项目赢得更多的支持、认可和帮助。 困难和障碍是最好的老师,它能够引导我们在通往成功的阶梯上一步步向上攀登。宝剑锋从磨砺出,梅花香自苦寒来,项目经理朋友们:祝愿你们在取得“真经”的路上走得更远,祝愿你们的旅程更丰富、更精彩~敢问路在何方,路在脚下~
作者简介:
董轶,IPMP B级国际高级项目经理,IBM 360?精英讲师团成员,自1996年起从事软件开发,曾任软件架构师、售前咨询顾问、项目经理、项目总负责人,具有多年大型复杂项目的管理经验。
转载请注明出处范文大全网 » IT项目经理成长手记