计算机分社微信服务号

    下载网站， 网址：

    出版时间：2013-01-01小编自己做了一个电子书

    出版社：机械工业出版社

    潘东 韩秋泉 著

    IT项目经理成长手记目 录

    序一

    序二

    自序

    前言

    第1章 “迷你”CEO——项目经理不简单

    1.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.2 “理论”和“实践”的差距

    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 谁是谁(Whoiswho)——如何让

    项目组快速热身

    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.2 怎样让项目经理愿意“亮”问题

    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项目管理工具索引

    参考文献序一

    潘东提出让我给他的书写点什么。我犹豫了

    一下，还是答应了。

    犹豫的原因，我不是项目管理专家，我无法

    给出专业的评价。一怕辱没了潘东的成就，二怕

    误导读者。

    答应的原因，我们是战友，我们曾经一起艰

    苦的奋斗。由于年长，也见证了潘东毕业后的成

    长历程。他把自己的经验和心得写出来，我很高

    兴。

    读了周教授的序，我就释然了。周教授的评

    价是中肯的。有了专家的评价，我就不用担心我

    有误导的嫌疑了。

    第一次见到潘东，是我们在一个大型银行的

    项目上，因为需要同另一家国际知名的IT企业合

    作，所以压力来自两方面。整个项目经历了两

    年，三方演绎了一场三国演义，虽然过去快十五

    年了，但记忆犹新。这也许就是我和潘东一起真

    正体会什么是项目管理的开始。

    神州数码的转型，很重要的一点就是核心能力的改变。作为IT服务的综合提供者，项目管理

    是核心能力之一。而其他核心能力的积累也往往

    依靠项目管理能力的转化。譬如，核心技术的积

    累，首先是基于最佳实践，而最佳实践只有依靠

    强有力的项目管理能力才能脱颖而出。而把最佳

    实践转化成解决方案，也是靠项目管理能力的支

    撑。最后再通过项目管理，把解决方案转化成核

    心技术产品或平台。

    潘东的作品是对我们过去项目管理工作的总

    结和提升。作品中甚至用了很多我们的习惯用语

    和案例。在读的过程中，很多画面跃然纸上：我

    们对方法论的争论，我们被合作伙伴挤兑的痛

    苦，人员流失的烦恼，项目经理权限的讨论……

    项目管理不仅会涉及内部员工，还有客户，合作

    伙伴。它是典型的系统工程。如果没有系统思维

    是无法理解和完成项目管理的全部内容的。

    在工业化的过程中，中国最缺少的就是流程

    化和项目化。而两化融合的过程中，我们又往往

    忽视了信息产业的工业化。因此从一个实践者的

    角度，完成这样一个作品，可贵，可敬。对于从

    业者，具有很强的阅读性。神州数码控股有限公司董事局主席 郭为

    2012年12月7日序二

    目前我们所处的信息化时代，是人类进入综

    合利用物质、能量和信息三种资源的知识经济时

    代，许多组织的未来，将取决于它们驾驭信息技

    术的能力，与之相应的IT项目管理已经成为一个

    热门的前沿领域。在这方面的理论著作很多，有

    描述经典软件开发的项目管理 [1]；有描述新型软

    件开发的项目管理 [2]；还有描述迭代增量式开发

    的统一软件开发过程 [3]。

    在总结项目管理最佳实践方面，最具有代表

    性的有美国项目管理协会组织编写的《项目管理

    知识体系指南》(PMBOK? GUIDE)第4版，以

    及美国CMUSEI主持编写的《能力成熟度模型集

    成》(CMMIDEVV1.3)。项目管理是把知识、技能、工具和技术应用于项目活动，以达到项目

    的要求，前者通过合理运用和整合启动、规划、实施、监控和收尾5个过程组的42个项目管理过

    程来实现，后者则从直接涉及项目管理的需求管

    理、项目策划、项目监控、集成项目管理、定量

    项目管理、供应商协议管理以及风险管理等7个

    过程域的59个实践的优化组合来实现。但是，迄今为止，系统介绍一线实战经验的

    项目管理书籍很少，因此，《IT项目经理成长手

    记》一书就显得特别珍贵。我有幸率先拜读了这

    本著作。本书以项目管理、质量管理、软技能三

    个方面进行组织的案例为基本单元，采用叙事的

    风格，首先结合IT项目的特点介绍项目管理的基

    本概念和知识，接着介绍单项目管理的实战技能

    和经验教训，再进一步介绍项目群管理的实战技

    能和经验教训。其中的重点是介绍实战中如何将

    理论联系实际，项目经理如何处理好客户关系、人员沟通以及团队建设。

    本书不仅可供一线项目经理、质量经理和项

    目总监阅读，也可供有志于向项目经理方向发展

    的软件开发和测试人员，以及公司的各级高管阅

    读，当然还可以供对项目管理领域感兴趣的所有

    人员阅读。

    北京航空航天大学计算机学院教授

    周伯生于北京

    2012年6月19日

    [1] BobHughes, MikeCotterel l .软件项目管理[M].周伯生，廖彬

    山，任爱华，译.北京：机械工业出版社，2004.[2] WalkerRoyce.软件项目管理[M].周伯生，廖彬山，译.北

    京：机械工业出版社，2002.

    [3] IvarJacobson, GradyBooch, JamesRumbaugh.统一软件开发过

    程[M].周伯生，冯学民，樊东平，译.北京：机械工业出版社，2002.自序

    我1998年博士毕业后加入联想，后随集团的

    分拆转入神州数码。十多年来一直从事应用软件

    领域的项目管理工作，从一个普通技术人员开

    始，踏上了项目管理的职业生涯。

    从最初负责几个人的小型项目都很吃力，到

    慢慢地能硬着头皮顶住60～70人的大项目，再到

    后来逐渐成为一名管理十几个项目的项目总监。

    2005年初，我担任了神州数码融信软件有限公司

    副总裁，开始全面管理西安开发中心，这是我项

    目管理职业生涯的最高点。这期间虽然工作压力

    非常大，但我有幸亲历了一个开发中心从小变大

    的全过程，也有机会从公司的角度思考项目管理

    的一些问题。

    2007年底，我调任神州数码的一个合资子公

    司任COO，开始负责公司的整体经营，也离开了

    我熟悉的项目管理领域。本来一些项目管理的经

    验教训只会成为一段回忆了，但是一个偶然的机

    会促成了我写此书的想法。

    2009年我在软件协会过程改进分会的大会上

    作了一个关于组织级项目管理实践的演讲，引起了圈内很多朋友的兴趣；后来，又多次以沙龙的

    形式与同行朋友们分享。交流中我发现很多问题

    都是我曾经遇到过的，一些经验教训对大家很有

    帮助。在一次沙龙活动之后，一位资深的IT圈朋

    友向我提议：“为什么不把你遇到过的问题整理

    成一本书？现在国内的理论书籍非常多，但是关

    于实战经验的书籍就太少了。”

    我觉得这是个很好的提议，但是写书对我来

    说却是件非常有挑战的事。因为自己虽然有一些

    实践经验，但理论水平有限，写出来的东西都

    很“土”，与主流的项目管理书籍相比实在拿不出

    手。

    犹豫中想起了发生在郭为先生(神州数码董

    事局主席)身上的一个小故事：2005年郭总带领

    神州数码一些干部参观西安开发中心，在了解了

    开发中心的情况之后非常开心。同行的人员中一

    部分很振奋，但是也有一部分不以为然，觉得与

    国际化的开发中心相比，西安开发中心无论规模

    上、水平上都有很大的差距。

    当时正值神舟5号载人飞行成功，听到这些

    意见之后郭总就问了个问题：“虽然神舟5号载人

    飞行比美国晚了整整三十多年，你们感觉高兴

    吗？”在座的人异口同声地说：“当然高兴了!”

    郭总继续又问道：“为什么高兴呢？”

    “因为这次是我们自己的!”

    是的，国际的先进经验再好，那是别人的；

    我们的管理经验再“土”，但是毕竟是我们自己

    的!想到这个故事，便有了如何写这本书的思

    路：我虽没有能力写一本理论水平多高的书，但

    可以将一个项目管理实践者所经历的、看到的案

    例整理成“手记”，如实地告诉大家我们曾经遇到

    了什么问题、采取了什么解决方法、获得了什么

    经验和教训……这样，对于遇到类似问题的读者

    来说就有了一条可以参考的路径，至少可以多一

    个选择、少走些弯路。

    于是，从2010年初开始就和我共事多年的好

    友韩秋泉一起着手撰写本书。其中，韩秋泉负责

    了质量管理相关的第6章和第9章，我则撰写了其

    他章节。在撰写的过程中，重点从三个方面分享

    了我们个人的一些实践体验。

    第一，项目经理的职业生涯规划。对很多从

    事技术工作的朋友来说，项目经理不仅是个“光

    环笼罩”的职位，也是走向管理的一条“捷径”。但

    是，“捷径”并不代表最快，更不代表最容易。回

    想我刚刚满心欢喜地成为项目经理的时候，前任曾经意味深长地对我说：“以后无论多难，都要

    记住一点：只要别人不赶你走，你就厚着脸皮待

    下去，这样你才有可能熬到项目成功。”后来发

    现，项目经理其实是个实实在在的苦差事，过程

    中我曾经几度想要放弃，但正是前任的这句话支

    撑着我“熬”了下去，并走到今天。为了给想做项

    目经理的朋友一些职业规划的参考，本书开头花

    了一些笔墨，说明了项目经理是干什么的，什么

    样的人适合做项目经理，项目经理的知识和技能

    要求，以及今后可能的发展路径。希望读者在了

    解了这些之后再慎重做出职业选择；而一旦选

    择，也必须要有“熬”下去的心理准备。

    第二，如何跨越理论到实践的距离。在我踏

    上项目管理岗位之前，就看过一些项目管理的书

    籍，接受过一些培训；对如何制定计划、如何管

    理项目“胸有成竹”。但是进入项目之后才发现，理论好比是教人如何在地图上规划一条路，而实

    践则好比是要在现实中一步一个脚印地走完这条

    路。虽然从地图上也能看到山川河流的标记，但

    是和实际的跋山涉水、翻山越岭比起来有天壤之

    别；不仅地面上荆棘丛生、沟壑纵横等情况在地

    图上看不到，而且突然从山上滑落的巨石更是制

    定计划时想不到的。理论和实践之间的这个距

    离，是成为一名成熟的项目经理所必须跨越也是

    最难跨越的沟壑。为了帮助读者尽快跨越这个阶段，本书结合自己的成长经历，按照时间顺序记

    录了从初出茅庐开始所遇到的各种困难和挑战。

    这样的案例组织方式可能最接近读者们的实际体

    验，希望这些案例能帮助刚刚涉足项目管理的朋

    友尽快进入实践，帮助已经遇到了困难的朋友得

    到启发、找到方法。

    第三，项目经理的软技能。项目经理中

    的“经理”二字就像班主任中的“主任”二字一样，不是什么官职，项目经理更像是个专业岗位，没

    有什么权力，更不能振臂一呼、应者云集。因

    此，项目经理更多需要靠领导力来影响和激励团

    队，靠沟通和协调推进项目，甚至需要一定的政

    治和文化意识才能获得支持。这些软能力很难通

    过理论教导获取，但或许可以通过案例学习和借

    鉴。因此，书中设置了几个具有代表性的角色并

    贯穿于各个案例故事，这些角色之间有时冲突、有时合作，案例中还描述了他们之间的沟通、协

    调和谈判的过程。希望通过这些情景能够帮助读

    者了解在一个由“有血有肉”的人组成的组织中，如何通过“软技能”去获取支持、解决问题和建设

    团队。

    我们自知水平有限，疏漏错误之处难免，之

    所以仍愿意将这些最基层的经验教训与读者分

    享，是因为我们觉得：虽然自己刚从一条崎岖的小路上蹒跚穿过，虽然自己还满身伤痕，但只要

    将我们在小路上经历的或看到的各种困难告诉他

    人，就可能帮到他人。这就是我们写此书的目的

    和最大的心愿。

    特别要感谢我的良师益友周伯生老师。他在

    健康欠佳的情况下仍细致地审阅了全书，提出了

    很多中肯意见和宝贵建议，并特别为此书作序。

    让我印象深刻的是周老师还特别指出了原书稿中

    的一些文字错误，让我对一个前辈学者的严谨风

    范肃然起敬，也为自己的疏漏而汗颜。

    最后，想把此书作为送给女儿的一个礼物。

    她刚刚出生不久我就离开家到西安工作，一眨眼

    的功夫她就长大了。希望通过此书让女儿知道，不在她身边的日子里，我还是做了一些有意义的

    事情。

    潘东

    2012年11月前言

    伴随着信息时代的到来，我国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章 “迷你”CEO——项目经理不

    简单

    1.1 项目经理是干什么的

    小M是一名毕业于名牌大学软件专业的研究

    生，在学校中随导师参加过一些国家级的科研项

    目。毕业后，小M如愿加入某知名IT公司。

    为了适应管理要求，该公司已经引进并实施

    了“项目型”管理模式，企业内按行业划分成事业

    部，项目是事业部最基本的业务运作单位；各事

    业部内设专职的项目经理，项目经理对项目的全

    过程负责，因此是公司最重要的基层管理角色之

    一。

    小M觉得，项目经理受人尊重、令人羡慕。

    不仅羡慕他们每次完成一个项目回到公司后受到

    英雄般的欢迎，跟公司高层可以面对面直接沟

    通，还有老客户、老同事经常寄来的土特产。就

    拿小M的顶头上司事业部总经理S总来说，原来

    是做技术的，后来成了项目经理，之后连续做了

    几个大项目，就成了领导眼里的“红人”，在客户

    那里也有很高威信。现在，年纪轻轻已经成了一名总经理，独立负责了公司的一大块业务。

    项目经理也是公司的稀缺资源。由于公司的

    项目技术性比较强，需要既懂得IT技术又具备项

    目管理技能的人才，因此鼓励技术人员转型做项

    目经理。小M觉得自己符合项目经理的要求，但

    是，做一名项目经理是个严肃的职业选择，在进

    入亮丽的光环之前，首先需要弄清楚，项目经理

    是干什么的？

    于是，小M找到了S总，谈了自己的想法，希望得到S总的指导。S总热情接待了小M，并回

    答了小M的问题。

    小M首先问：“S总，请问项目经理是个什么

    样的角色呢？”

    S总答道：“项目经理是公司委派的负责实现

    项目目标的个人，是公司授权的项目负责人，是

    项目的直接组织者和领导者。项目经理对外代表

    公司与客户和分包单位进行联系，处理合同有关

    的商务事宜；对内全面负责项目的实施。一些企

    业中由职能经理代替项目经理，项目经理是兼职

    和客串的角色。这种兼职的项目经理实际上并不

    承担上述职责。”

    小M接着问：“那项目经理的具体职责是什么

    呢？”S总答道：“公司里的项目经理的职责有三个

    方面：

    ■对项目全过程进行组织和管理，按预期交

    付项目的成果；

    ■管理客户关系，以取得客户对交付的成果

    及过程的最满意评价；

    ■管理项目团队，使之高效而又愉快地工

    作，并获得最满意的工作体验。

    也就是说，一个合格的项目经理必须同时做

    到‘按预期交付成果’、‘让客户满意’、‘让员工满

    意’。”

    小M又问：“那IT项目经理的主要任务是什么

    呢？”

    S总说：“第一，支持售前过程。IT项目一般

    比较复杂，交付风险比较大，需要在合同中约定

    工作范围、进度计划，要估算成本和人力资源。

    项目经理近距离地了解需求、资源等约束，制定

    的项目实施方案才会切实可行。参加售前过程不

    仅有助于项目经理深入了解客户需求，也可以帮

    助客户了解项目经理的能力。有的时候，客户会

    因为相中‘项目经理’而促成合同的签订，甚至要

    求将锁定某位项目经理作为合同的条件。第二，负责项目交付。签订合同之后，项目

    经理负责围绕预期目标、遵循确定的规范执行项

    目。项目经理不仅要制定思路清晰、考虑周密的

    计划，还要调集资源、委派任务，推进计划的执

    行；过程中，还要及时处理出现的问题，定期向

    有关人员汇报进展，保证在规定的时间和预算内

    交付项目成果。

    第三，完成项目收尾。完成交付成果之后，要将成果移交给客户，确保客户可以稳定地使用

    系统。然后，将后续服务移交给服务部门，确保

    客户得到持续的服务保障。项目经理交付的成果

    直接决定客户满意度、影响客户是否愿意付款，因此公司还要求项目经理负责完成收款工作。

    第四，管理干系人的关系。一个IT项目可能

    涉及投资方、客户、分包单位、合作伙伴，甚至

    可能包括政府、社会等各方面的关系；面对的‘客

    户’也不是一个人，而是一个群体。项目经理作为

    各方的桥梁和纽带，要随时处理各方信息，保持

    密切沟通，解决矛盾冲突，只有这样才能让‘客

    户’满意。

    第五，管理项目团队。由于项目团队的临时

    性，项目经理需要花费很大的精力寻找合适的资

    源，优化资源配置，建立合理的组织结构，确定

    清晰的职责分工。项目过程中还需要通过各种措施进行团队建设，打造高效团队。”

    “从这些工作任务的性质来看，项目经理是

    项目的推动者，也是关系的协调者。”S总边说边

    画了一张图(见图1-1)，描述了项目经理前前后

    后、上下左右的关系。

    图1-1 项目经理的角色

    小M感叹道：“原来项目经理要面对那么多

    人、负责那多事，还要确保项目的成功，这是多

    么有挑战的一件事啊!”

    S总说：“确实，项目经理往往是决定一个项

    目成败的关键人物，要求素质高、综合能力强、职责范围广，几乎涵盖了一个CEO的范畴。所以，项目经理也被戏称为‘迷你CEO’。”1.2 我适合做项目经理吗

    小M了解了项目经理的职责，虽然觉得非常

    有挑战，但这些事情都是自己感兴趣的。因此，更加坚定地想成为一名项目经理。

    但是，项目经理是条无悔路，后面可能遇到

    的困难无数，如果半路发现实际情况和最初想象

    有很大的差距，觉得自己不适合做项目经理，那

    问题可就大了。因为，这不仅对客户和团队会造

    成非常大的不利影响，对自己也非常不利，毕竟

    技术的发展实在是太快了，再想退回到技术路线

    的难度也很大。

    小M非常想知道，到底自己适合做项目经理

    吗。于是再次找到了S总。

    S总说：“是否适合首先考虑的是个人素质。

    具有不同素质的人对同样的事情会采取完全不同

    的反应。项目经理是项目中的瞩目人物，一旦做

    出失当的反应，会影响多方人员，因此对素质有

    比较高的要求。

    素质包括性格特征、能力倾向和处事态度

    等。尽管谁都可以做项目经理，但真实的情况是

    可能某些人更适合做项目经理，甚至IT圈子里很多人都认为项目经理是天生的。当然，‘天生项目

    经理’并不是说他们不需要学习和实践，而是说具

    备某些素质的人员担任项目经理可以充分发挥特

    长，从而比较自信，发展得也比较顺利。

    反过来，有些人确实不太适合做项目经理，所以需要慎重选择。例如，一个人天生就不善言

    辞，不愿意与人打交道，如果让他去跟客户谈

    判，不停地‘讨价还价’，他的心理就会承受很大

    的压力。一旦突破了心理承受能力极限，可能会

    放弃最初的选择。当然，这也不是说不善言辞一

    定就做不了项目经理，只是要比其他人付出更多

    的努力，可能在成长的路上会艰苦一些。”

    小M问：“那么‘天生的项目经理’具备的素质

    是什么呢？”

    S总答道：“可能很多素质都是必要的，但有

    几个基本素质不仅重要，而且先天赋予的成分较

    多。

    第一，领导力。领导力是指通过他人来完成

    工作的能力。项目经理虽然是项目领导核心，但

    需要依赖团队完成任务。由于项目组的动态性和

    临时性，项目经理对于团队成员并不具备完全的

    管理权力，更多需要将一组成员凝聚成一个团

    队，激发和影响他人为了一个共同的目标而努力工作。

    领导力重要并不意味着‘领导’是‘官’，领导

    应该是个‘领头的’，跟大家是平级的，但是却走

    在别人的前面。不仅要求别人做到的事自己先做

    到，而且知道‘下一步’应该干什么，下一个目标

    在哪里。项目经理的口号应该是‘跟我冲’，而不

    是‘给我上’。

    ‘领导力’其实很好判断，如果让一组人在一

    个封闭的环境中让他们共同去完成一个任务，但

    是不说明谁是这组人的负责人。不用多长时间就

    会发现，这组人中有一个人(或几个人)会自然

    而然地成为了领导者。

    第二，责任心。项目执行过程中，会遇到很

    多困难，经常会超出原先的想象。这个时候，能

    够帮助项目经理坚持下去的可能只有‘责任心’。

    具备强烈责任心的人，出于对承诺的负责，会倾尽全力达成目标而不言放弃，因此也是可

    靠、可信的人。这样的人，公司、客户和团队才

    会对其放心，才会全力支持。

    具有强烈责任心的人，还有个特点，会非常

    注重细节，能主动发现问题。他会不自觉地在脑

    子中模拟一件事的执行过程，设想各种意外情

    况，考虑如何应对。这样的人就是我们常说的‘操心命’，但这样的品质在项目管理中特别有用，有

    助于发现潜在问题、防范潜在风险，这样的人也

    比一般人看得远，想得透。

    第三，积极主动。桌子上放着半杯水，消极

    的人会说，唉!只剩半杯水了。而积极的人会

    说，耶!我们还有半杯水。项目经理需要成为后

    者，总是能同时看到事情‘有利’和‘不利’的两个

    方面，善于利用自身的优势转变局势。

    积极主动的人最大的特点是不抱怨。项目经

    理是‘主心骨’，主心骨乱了，项目也就乱了。项

    目经理必须时刻保持好的心态，如果团队始终看

    到一个信心满满、镇定自若的项目经理，大家也

    会充满信心。如果团队总是看到一个整天愁眉苦

    脸、满腹牢骚的项目经理，大家可能担心他随时

    会撂挑子，士气可想而知。

    积极主动的项目经理会积极寻找方法，相

    信‘方法总比问题多’。他们能够引导大家集思广

    益寻找方法，领导团队走出困境。

    积极主动的人会提出建设性意见，从而更容

    易获得帮助和支持。被敌人包围了，一个指挥官

    报告说：‘我被包围了，该怎么办？’，而另一个

    指挥官报告说：‘我被包围了，需要空中支

    援。’哪个更容易获得帮助？显然是后者。因为，向司令部解释清楚复杂的状况就不是件容易的

    事，还要他们帮你做出决策，贻误战机不说、决

    策也不一定正确。其实，最能提出正确建议的人

    正是掌握丰富信息的一线指挥官。

    第四，压力承受。项目中会出现各种突发事

    件，有时需要忍受极大的压力。有压力承受能力

    的人当困难来临的时候仍能镇定自若，仍能冷静

    思考，即使在无能为力的时候，还能保持‘风

    度’和‘幽默感’，从而稳定军心、解决问题。”

    S总说：“有一个项目经理在半夜3点、离系

    统正式运行4个小时前发现一个凭证打印错误，可能直接影响第二天业务的正常运行。他连夜把

    程序员叫过来修改程序，在别人忙得焦头烂额的

    时候，他自己却在旁边的椅子上呼呼大睡。别人

    问他：‘这个时候你还能睡得着？’他说：‘我现在

    帮不上忙，现在能做的事就是让大家放松点。明

    天才是我该紧张的时候’。这时候能睡着，才需要

    真正的抗压能力。”

    小M听得非常入神，但是仍不知道自己是否

    满足这些素质要求。S总拿出了一张表，告诉小

    M这是从公司一些优秀的项目经理身上抽取的行

    为特点和思维习惯，你可以参考看看，自己是否

    是这样的人：■对复杂问题，会去考虑“怎么思考”，再去

    思考要思考的问题。

    ■能够从操作层面、细节层面考虑计划的可

    行性，并主动征求他人意见。

    ■时刻关注质量，深信质量是决定成败的要

    素。

    ■众说纷纭的时候，会选择到现场获得一手

    资料，独立思考和判断。

    ■先设想事情最坏的结局是什么，再努力避

    免无法挽回的错误。

    ■遇到困难时积极寻找解决问题的方法，而

    不是找“行不通”的借口。

    ■失败时勇于承担责任，而不是急着解释原

    因和推卸责任。

    ■犯了错误之后一定会总结经验教训，保证

    不犯重复的错误。

    ■与人沟通时会有意识地换位思考，试图理

    解如果我是对方会怎样。

    ■倾听时脑子想的是“对方的想法是什么”，而不是想怎么给对方一个回答。■评价他人的时候会先看优点再看不足。

    ■有问题当面谈，背后不飞短流长。

    ■有人向你抱怨和指责他人时，第一反应是

    为不在场的人说好话。

    ■如果有两方在你面前争执，不听完双方的

    表达绝不下结论。

    ■谦虚认真、不懂就问，不为了面子装内

    行。

    ■认可别人比自己强，认为需要别人帮助。

    ■至少有一项业余爱好可以让自己放松。

    ■能够忘却烦心事，不将烦恼带出办公室。

    ■一旦开始项目就必须要看到结果，没人赶

    你走就坚决不离开项目。

    ■泰山压顶的时候，至少可以做的一件事是

    保持“风度(镇定)”。

    ■对无能为力的事，仍能保持乐观和幽默。

    S总说：“如果你对这些问题80%以上的回答

    都是肯定的，说明你具有一名优秀项目经理的潜

    质，选择项目经理作为自己的职业方向，就会有

    比较顺畅的路径和光明的未来。”1.3 项目经理的知识和技能

    几次谈话之后，S总通过观察觉得小M是个

    好苗子、“天生项目经理”；小M成为项目经理的

    意愿也非常强烈，恨不得立刻买本书，投入项目

    管理的学习中去。

    S总向小M推荐了几本项目管理方面的书，但同时强调：“项目管理是实践性很强的学科，项目经理不仅要掌握项目管理知识，还要掌握实

    践技能和人际关系的软技能，而且这些知识和技

    能不是光从书本上就可以得来的，需要通过多种

    途径学习和掌握。”

    “专业知识、实践技能、软技能？”，小M没

    有想到项目经理要知道这么多的东西。因此，请

    S总先做个整体的介绍，以便对需要学习的内容

    和方法有个底。

    1.3.1 专业知识

    项目经理需要熟悉和掌握的专业知识包括项

    目管理知识、IT专业知识以及行业知识。

    第一，项目管理的专业知识。项目管理知识

    比较成体系，有很多专业书籍，内容涉及项目和项目管理的基本概念，项目的生命周期、组织结

    构、管理过程、知识领域，以及整个的管理框

    架。只要参加必要的培训或通过看书学习便可以

    掌握。对软件领域的项目经理来说，软件工程方

    面的过程知识也非常必要，没有这些知识就像一

    个厂长不知道产品的生产过程一样不可思议。

    第二，IT专业知识。也许有人认为，项目管

    理是一种通用的理论，可以适用于各个领域，所

    以项目经理可以不懂IT专业知识。但是，要制定

    合理的计划、解决实际问题，就必须掌握必要的

    IT专业知识。不仅如此，由于IT技术发展迅速，项目经理还应该不断加深、加宽专业背景，这样

    才能做出正确的决策，才能有效领导团队。想想

    看，建筑行业的项目经理如果到IT行业可能就会

    遇到很多困难，反之亦然。实际上，IT行业多数

    项目经理都是从技术线转过来的，也是这个道

    理。

    第三，行业知识。做技术的人有时候更关心

    的是“如何实现系统”，其实并不关心系统干什么

    用。而系统是为客户的业务服务的，项目经理必

    须理解客户的需求，知道客户的业务需求，才能

    做出正确的取舍。特别是从事应用系统开发的项

    目经理更是如此，如果不了解客户的基本业务流

    程，甚至连一些客户的术语都听不懂，又怎么与客户沟通呢？从职业发展角度来看，行业知识也

    是项目经理“增值”的重要方法。项目经理要想继

    续成长发展，可能需要独立拓展业务，这时必须

    有一定行业知识才能理解客户的需求，才能说清

    项目对客户的业务的价值。1.3.2 实践技能

    相对专业知识而言，实践技能比较难获得，需要一定的时间积累才能逐步掌握。知识就像拳

    谱，但想要变成拳师，还必须练习和实战。因

    此，仅理解公认的专业知识还不足以实现有效的

    项目管理，还必须掌握IT特定应用领域的工具、方法和技术，以及操作级别的流程，才能达到管

    理目的。

    就拿接手一个具体项目来说，进入项目时有

    两项技能就很关键：

    第一，商务技能。项目经理代表公司管理项

    目、履行合同，需要熟悉商务环境，具备基本的

    商务技能。例如，必须具备起草方案、商务谈判

    的能力。技术线出身的项目经理刚开始可能很不

    适应这一点，因为既不习惯咬文嚼字的文字工

    作，也意识不到商务合同的法律效力。

    第二，项目启动。真正进入项目的第一周是

    最慌乱的，因为你不知道到底每天该干什么，而

    这时客户正好在看着你，一旦手忙脚乱客户就会

    形成不好的第一印象，直接影响你在客户那里的

    威信和话语权。因此，实践中的“启动”阶段必须

    知道每天该做什么，才能有条不紊地展开工作，体现一个成熟项目经理的能力。

    再来说说计划。项目管理知识介绍了项目计

    划的一般方法，但项目中涉及的人员可能很多，需要团队一起制定计划。在这样的情况下，不光

    要有方法，还要有合适的工具，具体的步骤，以

    及合理的约定。否则大家根本不在一个层面谈事

    情，计划会变成天书一样，更别谈执行了。

    到了执行阶段，计划制定好了挂在墙上并不

    会自动被执行下去。如何让每个人知道该干什

    么，如何知道每人干得怎么样，如何检查是否完

    成了工作，如何进行工作调整，只有这些操作层

    面的问题解决了，才能做到对项目状态了如指

    掌，才能将计划用于每个团队成员的时间管理。

    还有质量问题，大家都知道质量管理是项目

    管理的一部分，都知道质量管理的重要性。但项

    目中质量管理人员到底应该做什么，什么情况下

    有权喊停，这些必须明确。如果没有制度上的保

    障，质量管理就会不断让路，最终的后果是质量

    管理变成了摆设，效果可想而知。1.3.3 软技能

    项目管理需要大量的沟通协调工作，涉及到

    客户、伙伴、项目团队，项目干系人等多方面人

    员。是“人”在确定项目目标、推动项目进程，使

    用项目成果创造价值。因此，处理人际关系的各

    种“软技能”是项目经理的一项重要修炼。

    而软技能“软”在没有标准的工具和方法可

    寻，仅有一些原则，更多依赖于项目经理的素质

    和经验，因此是最难掌握的技能。有时会发现两

    个人使用同样的方法，取得的成效却不同，就是

    因为软技能水平的差异造成的。

    软技能包括很多方面，例如沟通和协调、团

    队建设、政治和文化意识。

    1.沟通和协调

    沟通和协调一直被认为是决定项目成败的最

    重要的因素之一。事实上，只有少部分项目是因

    为技术的原因失败的，有的项目经理甚至本身就

    是一个技术专家，但是因为沟通出现了问题，所

    以无法获得客户和团队的支持，从而使周密的计

    划变成了废纸，最终导致项目失败。

    沟通包括识别沟通对象、建立沟通渠道和明确沟通信息。其难点在于要根据不同的沟通对象

    的性格和背景采用适当的沟通方法和谈话角度，才能进行有效沟通。有个误区认为能“说”的人才

    是会沟通的人，其实“倾听”才是沟通最重要的环

    节之一，出色的沟通者会首先掌握他人的意愿及

    需求，然后才洞察问题所在，最终达成共识。谈

    判也是沟通的一种，目的是与利益相同或相背的

    人进行会谈以期达成妥协或协议[4]。谈判不仅是

    信息的交流，还要涉及利益的交换，几乎是项目

    经理的一项生存技能。

    项目中的协调同样重要。项目需要满足一群

    人的期望，这些人员往往拥有不同的行为规范、背景和利益。弄清谁是干系人并不困难，困难的

    是要满足不同干系人的期望。如果各方对利益没

    有达成共识，会使项目从一开始就暗藏危机。

    因此，巧妙地运用沟通技能协调各方关系和

    利益，寻找到各方共同点，将各方的关注点聚焦

    在同一个目标上，最终实现共赢，这是对项目经

    理最大的挑战之一。

    2.团队和激励

    “找一些优秀的球员并不难，但让他们一起

    打球就困难了”。找到各方面的专家还不能保证

    项目成功，项目经理必须分享权力，让成员能够团结协作，为了共同的目标而努力工作。

    团队建设需要员工之间的沟通，解决成员之

    间的冲突，营造和谐的氛围；但最重要的是迅速

    凝聚成员，建立相互之间的信任和依赖。团队建

    设的难点在于团队成员都是活生生的人，“人”的

    工作态度，责任心和满意度直接影响项目的质量

    和效率。因此，项目经理个人能力多强并不重

    要，让团队具备超强的能力才是重要的。

    有的项目经理虽然具备多方面专业知识和技

    能，但因为缺乏团队建设能力，因而团队人际关

    系紧张、骨干流失，甚至团队分裂，从而带来惨

    痛的损失和项目动荡。

    项目经理有时觉得自己担负了这么多的重

    任，却好像没有什么权力进行奖惩。其实，项目

    经理更多时候需要靠领导力进行管理，需要靠决

    策过程透明、巧妙使用影响力来激发个人积极

    性。例如，员工满意度的最大来源之一是通过项

    目学到新的东西，项目经理分配有挑战性的任

    务，激发员工的学习热情，指导和鼓励他们成

    长，可能获得比经济激励更好的效果。

    3.政治和文化

    组织中的政治因素是无法避免的，为此而失

    败的项目也非凤毛麟角。例如，出于“政治”目的而提出无法达到的目标(一般是过高的时间要

    求)，或者为了遵从不同“上级”的意图而不断“折

    腾”造成动荡，或者高层的人事变动直接造成项

    目被迫终止。

    政治因素可以带来冲突和压力，但也可能带

    来动力和契机。具备政治和文化意识，能巧妙利

    用“势能”影响决策过程，或者在正常组织关系难

    以驱动的情况下取得支持，可以帮助项目经理在

    困境下获得成功。反之，如果忽略或回避项目中

    的政治因素并且不恰当地运用权力，则会使项目

    经理陷入“四面楚歌”的困境。1.4 项目经理的职业规划

    小M想知道，如果做出了职业选择，成为一

    名项目经理，在工作中应该怎样开始自己的职业

    生涯呢？成为项目经理之后，又可以走向什么样

    的岗位呢？

    S总结合公司的职位体系，给出了一条可以

    参考的职业生涯路径，从助理项目经理开始，到

    项目经理、资深项目经理，直到总监，如图1-2所

    示。图1-2 项目经理的发展地图

    1.4.1 涉足项目管理

    涉足项目管理可以从一个助理项目经理——

    项目经理的“助手”开始。在一个项目中，除了本

    职工作，可以向项目经理要求分担一部分项目管

    理工作。对于上级的项目经理来说，有人愿意主

    动帮他分担工作自然十分乐意，自然也会愿意进行指导和帮助。

    在这个阶段的重点是“掌握知识”和“学习技

    能”。

    第一，系统地阅读书籍和参加培训，掌握项

    目管理的知识，技术最好不要放手。

    第二，学习项目管理技能。可以在项目经理

    指导下学习使用各种管理工具，了解工作流程。

    比如，组织一个会议，会前需要什么准备？怎么

    确定日程？怎么协调多人的时间？会议上怎么形

    成决议？事后怎么进行跟踪？这些执行中的问题

    在理论体系中可能不会提及，也可能只是短短的

    几句话，但在实践中却是形成执行力的基础。

    第三，学习软技能，体验项目经理的角色。

    观察项目经理每天都做什么、处理问题的方法、与人接触的技巧。如果有机会独立管理一个小

    组，就借机学习如何进行团队管理。如果有机会

    帮着项目经理处理一些外部关系，也可以学习如

    何与客户和合作伙伴打交道。

    这个阶段工作起来可以放松一点，因为还有

    老项目经理帮着补台，所以不必过于担心。如果

    觉得自己不适合做项目管理，还可以果断地退

    出，对自己和项目都不会造成太大的损失。1.4.2 成为项目经理

    在掌握了基本知识、熟悉了基本技能之后，一旦开始独立负责一个项目，就正式踏入了项目

    经理的职业生涯了。哪怕是担任一个小型和中型

    项目的项目经理，都不能再想“撂挑子”了，否则

    对于项目、客户和团队都有重大的影响。

    这个阶段的重点是掌握“实践技能”和“软技

    能”。

    第一，实践技能。独立负责一个项目时就会

    发现，项目的情况千变万化，照搬书本上的知识

    一定不够，根据实际情况选择适当的方法，将理

    论知识和具体实践相结合，才能处理各种情况。

    在实践中要不断积累经验，举一反三，将项目管

    理知识变成项目管理技能。

    第二，软技能。这时可能会体会到：一把手

    和二把手的区别是很大的，遇到事情没有退路，遇到冲突没人补台。因此，需要学会韧性和斡

    旋，通过沟通解决问题，需要努力锤炼沟通和协

    调能力，勇敢面对“谈判”。

    项目经理虽然已经成为了全权“负责人”，但

    是需要通过他人完成工作，团队建设、激励鼓舞

    的能力就成为必备的能力。虽然软技能很难从书本上学习，但也并非没有经验可循。如果希望能

    有个可以商量和请教的人，原来的“教练”——老

    的项目经理的重要性就显示出来了，可以向他请

    教一些具体的问题。

    在做项目的过程中，也是学习一些专业知识

    的好机会。项目一定属于某个行业，项目经理的

    周围往往就有行业内各方面的专家，朝夕相处的

    日子也是难得的学习机会。积极参加各种方案论

    证和评审，深入一些专业小组工作，不但可以增

    长行业知识，还能加深对项目细节的了解，增强

    对项目的把控。

    另外有两点需要注意：第一，不要放松对技

    术知识的学习和更新，这样才能与项目成员顺畅

    地沟通。第二，财务知识的要求是无法回避的，尽管不需要很深入的了解，但至少学会“算账”，否则无法对项目的损益负责。1.4.3 成为资深项目经理

    在项目经理的道路上经过不断地经验积累，对于各种实践技能和软技能“精通”之后，就算是

    该领域的“专家”了，暂且称之为资深项目经理

    吧。资深项目经理与项目经理的区别在于有能力

    管理大型复杂项目，这类项目往往由若干子项目

    构成，各个子项目被相对独立地进行管理，但子

    项目之间的依赖关系密切。

    这个阶段的成长主题是“传授和指导”。对子

    项目不能通过命令进行管理，更多需要的是经验

    传授和案例指导。例如，帮助解决子项目中的具

    体难题，预见风险并提前帮助项目经理进行防

    范，指导团队建设和塑造氛围，在项目组中传

    递“企业文化”。

    善于在项目中去培养和指导新入行的项目经

    理，可以让自己的项目有吸引力，很多人都愿意

    加入这样的项目，主动当助手，谁不想跟着大师

    好好学习一下。传授的过程也是自我提高的过

    程，对经验和教训进行系统地总结，会将项目管

    理知识、技能和经验融会贯通，可以达到理论讲

    解而不是事例讲授层次。

    如果一个项目经理能够走到这一步，已经有相当的成就了，对于单项目的管理已经完全不在

    话下。如果继续发展可以考虑转向业务。

    资深项目经理对于挖掘新的项目机会有得天

    独厚的优势。他们能够接触到客户的高层，对于

    客户的业务和组织情况都非常了解，如果具备一

    定行业知识，了解新产品和新技术，就能够将客

    户的需求和公司的能力有机结合起来形成新的商

    机。1.4.4 成为项目总监

    项目总监在不同企业中有不同定位，但是基

    本都是负责一个(类)客户的项目群，为客户提

    供长期服务的唯一接口。项目总监与项目经理的

    区别：

    ■管理方式上不再直接管理项目，而是通过

    项目经理管理项目。

    ■时间跨度上也要大很多，从最初的需求理

    解、业务策划一直到最终的运维服务。

    ■从职责上也从单纯的交付，过渡到发现新

    的机会，提供新的服务，拓展新的客户。

    为了达到这些目的，项目总监需要几个方面

    的成长。

    第一，客户关系。项目总监是客户服务的统

    一接口，在客户面前直接代表公司，与客户建立

    相互信赖关系是必须的。客户关系的第一个层次

    是要把客户的事情做好，没有这个前提没有信赖

    可谈。第二个层次，是帮助客户个体成功，了解

    不同个体的期望，通过项目让“客户”体现价值，建立稳固的关系。

    第二，需求理解。技术人员往往更关心“系统怎么实现”，其实并不关心系统是干什么用

    的。但项目总监恰恰要关心“系统需要干什么”，因此，应该对客户的行业进行比较深入的了解，用客户的“语言”谈问题，才能识别客户需求。

    第三，业务策划。从项目生命周期的角度

    看，如果能够与客户一起进行业务策划，进行可

    行性分析，帮助客户内部立项，不仅有助于承接

    项目，而且能了解项目对客户的业务运营的价

    值。这个过程需要项目总监具有一定IT规划的能

    力，以及对新技术、新产品的了解，将新的业务

    需求和新的方案相结合创造新的应用价值，不断

    为客户的IT进程注入新的内容。

    第四，财务知识。由于项目总监是业务策划

    者，需要评估项目的投资收益、估算项目成本，确定收款节奏、最终核算项目损益，以保证项目

    的成果能够给客户带来预定的业务价值，同时给

    公司带来合理的利润。

    到了项目总监阶段，对于基本素质和软技能

    也有了更高的要求。

    第一，沟通和协调要求更高。随着解决方案

    的逐步深入和复杂，一个项目可能涉及的内外部

    资源越来越多，需要大量的沟通和协调工作。过

    程中，需要取得多方的支持，整合各方力量，平衡全局和伙伴利益，才能顺利完成方案制定、售

    前支持、合同签订等过程。另外，因为经常要面

    对众多客户和员工，不仅需要点对点的沟通能

    力，还要有比较好的宣讲能力，能感染众多的受

    众。

    第二，团队和激励成为必要技能。项目总监

    作为项目群中人力资源的调配者，除了要从公司

    中获取资源，很多情况下需要自己获取和组织资

    源，有计划地培养骨干和建立团队。有些事情

    要“举重若轻”，尽管自己要承担很大压力，却要

    在下属面前表现得非常轻松。有的事情要“举轻

    若重”，除了自己要承担压力，还要向下传递压

    力，让项目团队重视并激发效率。这种“压力”传

    递还要因人而异把握好尺度，不能把人压垮，也

    不能没有压力。面对的人抗压能力强就直接把话

    说透，面对的人比较敏感就只能把话点到为止。

    如果经历了上述的过程，知道了怎样开辟一

    个项目群并进行管理，就可以不断发掘新的项目

    机会、不断拓展和成长。具备了业务开拓能力，在公司的支持下基本就可以独立负责某一类客户

    的业务了。沿着这样的轨迹发展下去，距离一名

    总经理也就并不遥远了。第2章 IT项目管理的那些事——入门

    知识

    小M按照公司的安排，开始参加项目管理的

    培训。学了没多久，小M就觉得理论很枯燥，好

    像与实际工作距离很远，不知道到底有什么意

    义。

    S总告诉小M，虽然项目管理的知识体系比

    较成熟，但要结合IT项目的特点提出问题来，才

    能在实践中有效运用。

    于是，S总针对项目管理理论中的一些内

    容，说明了其实战意义。经过S总的讲解，小M

    觉得这些内容生动多了。2.1 项目的基本概念

    2.1.1 什么是项目

    项目源于人类有组织的活动。随着人类社会

    的发展，人类有组织的活动逐步分化为两大类

    型：一类是连续不断、周而复始的活动，人们称

    之为“作业”或“运作”(Operations)，如企业流水

    线生产大批产品的活动；另一类是临时性、一次

    性的活动，人们称之为“项目”(Projects)。从古

    代的都江堰水利工程、现代的三峡工程，到著名

    的“阿波罗”计划，神舟飞船工程等，都是项目。

    什么是项目？项目是为创造独特的产品、服

    务或成果而做的临时性工作。[4]

    从广义上定义，项目是为实现特定目标的一次性任务。[3]

    通俗地

    讲，项目是面向特定目标的一组任务，项目受目

    标驱动，其本质是任务。

    项目的定义尽管不同，但是包含的共同要素

    却非常一致：

    ■项目都有明确和具体的目标，这是项目发

    起的动因。

    ■项目是指为完成特定的目标所需要完成的任务，具有一次性。

    ■项目都有明确界定的工作范围，虽然项目

    的目标是明确而具体的，但实现目标的方案是可

    以选择的，因而项目的工作范围需要定义。

    ■项目在实现其目标的同时，有预算、时间

    和质量指标的要求。

    什么是IT项目？习惯上将以计算机为主体的

    各种项目称为IT项目，但随着信息技术的发展，信息技术和信息化综合起来视为一体，与此对应

    的项目都认为是IT项目。

    IT项目按应用的领域分类，可以分成行业应

    用(金融、电信等跨地域的大型系统)、企业应

    用、个人应用。按照厂商的类型分类，包括软硬

    件产品制造、系统集成和信息服务。按照项目属

    性分为开发型项目和应用性项目。IT项目的内容

    包括：

    ■基础设施：机房、外部网络等支持系统。

    ■硬件系统：基本的服务器、路由器等。

    ■软件系统：系统软件，包括操作系统、数

    据库、中间件等；应用软件，为特定客户的应用

    需求所开发的软件。■系统实施与转换、运行与维护。

    IT项目因为其规模和复杂度较大，可能会划

    分成多个项目进行统一的管理。“多项目管理”大

    概分成几类。

    项目集：为了实现对单个项目分别管理所无

    法实现的利益和控制，将一组相互关联且需要协

    调的项目集中管理。例如，客户需要一个新的业

    务系统，可能包括需求咨询项目、流程和组织再

    造项目、应用开发项目、系统运维等多个项目。

    这些项目产生共同的结果，为整体的利益而相互

    联系，管理的重点是项目之间的依赖关系，包括

    解决项目直接的资源制约或冲突，调整对项目目

    标有影响的组织方向和战略方向，处理同一个组

    织结构内的相关问题和变更问题等。例如，业务

    需求要受技术方案的制约，咨询项目要受整体预

    算的制约。

    项目组合：为了有效管理和实现战略目标而

    组合在一起的项目、项目集和其他工作，项目或

    项目集之间不一定有依赖关系。项目组合可能共

    享资源，例如同一个解决方案为不同的客户服

    务。管理内容主要涉及资源调度，最大程度提高

    资源效率；共享知识经验和流程方法，提高整体

    的交付能力，以取得最大的组织效益。2.1.2 项目的特点

    与公司的运作(Operation)不同，项目具有

    非常明显的特点：独特性、临时性和不确定性。

    1.独特性

    每个项目都会创造独特的产品、服务或成

    果。尽管某些项目的交付成果中可能存在重复的

    元素，但这种重复并不会改变项目工作本质上的

    独特性。

    独特性在IT服务领域表现得非常突出，也具

    有重要的实战指导意义。例如，即使采用相同的

    产品、由相同的团队来建设，也需要根据客户的

    特殊要求进行一定的客户化工作，根据客户的不

    同要求提供不同的解决方案。因此，每个项目都

    有区别，每个项目都可能做某些前所未有的工作

    ——“没有完全一样的项目”。

    “没有完全一样的项目”也就“没有完全相同的

    产品或服务”，就是说预期的“产品或服务”在项目

    完成之前是不可见的，这与普通的产品交易非常

    不同。

    普通商品交易在买卖前产品可以看得见，摸

    得着，合适就买，不合适就算了。但如果交付成果在买卖前看不见，双方对要提供什么没能定义

    清楚或达成一致，则最终交付产品或服务时将很

    容易发生纠纷。

    为了解决这个问题，项目开始前要通过合同

    (或等同文件)明确地描述或定义最终的产品是

    什么，合同意义非常重大。某种程度上说，在签

    合同时已经决定了项目成败，这就是独特性的实

    战意义。

    2.临时性

    项目有明确的起点和终点。项目的临时性决

    定了项目的历时有限，具有明确的起点或终点。

    当项目目标达成时，或项目因不能、不会达到目

    标而终止时，当项目的需求不复存在时，项目就

    结束了。

    项目的临时性决定了时间约束非常重要，甚

    至是决定性因素。比如解决著名的2000年问题的

    项目，如果一旦突破了2000年的时间限制，项目

    就失败了。

    实际上，在日常项目管理中的时间观念非常

    重要，每一个任务都必须明确时间要求。团队每

    个人都要有严格的时间观念，在接受任务时必须

    明白“需要什么时候完成”，只有这样团队才能协

    同工作。临时性带来的另一个问题是团队动态性强，项目开始时组成跨专业项目小组，结束后小组即

    解散，并且在项目执行的过程中成员还可能会发

    生变化。因此如何将项目组成员快速组成一个有

    效的团队对项目的成败意义重大。特别是一些项

    目周期较短项目，如果团队成员短期内不能融洽

    合作，甚至内部分裂，则可能直接造成项目的失

    败。可以毫不夸张地说：优秀的团队效益显著，而松散的团队风险巨大。

    项目的临时性并不意味着项目持续的时间

    短，一个大型项目可以持续数年。项目交付的产

    品、服务或成果，一般不具有临时性。大多数项

    目所产生的社会、经济和环境影响，也往往比项

    目本身长久得多。

    3.不确定性

    项目不可能完全在规定的时间内、按规定的

    预算由规定的人员完成。这也是项目管理的难度

    大的重要原因之一。造成不确定性的原因包括几

    个方面：

    ■项目目标虽然明确，但事前可能对达到项

    目目标的途径并不完全清楚，对项目完成后的确

    切状态也不一定能完全确定。

    ■项目的干系人涉及多个组织单元和个人，人员多、变数大。

    ■项目团队面临的任务可能是全新的，可能

    有许多考虑不周的地方。

    ■计划和预算都是基于对未来的“估计”和“假

    设”，在执行过程中与实际情况难免有差异。

    ■项目在执行过程中还会遇到各种始料未及

    的“风险”和“意外”，使得项目不能按计划运行。

    面对不确定性，在实际工作中存在两种极端

    看法：一种倾向是反正“计划跟不上变化，索性

    不要计划”，即使制定计划也是为了应付，计划

    不切实际导致根本无法按计划执行。

    另一种倾向则是过度计划，必须将项目中非

    常微小的事情都考虑清楚才动手，但过度计划其

    实是在试图精确地预测未来，也是不切实际的，在执行中会发现难以与实际一致，而不得不频繁

    地进行调整。

    为了减少不确定性，应该在能够满足要求的

    前提下，尽量用成熟的技术和方法。有人总觉得

    别人做的东西不行，喜欢抛弃过去、尝试新的东

    西。实际上，过去的方法可能有不尽如人意的地

    方，但缺陷我们都清楚，可以避开。而新方法中

    存在的缺陷却难以预料，可能会出现新的问题，增加了项目的不确定性。2.2 项目管理的入门知识

    2.2.1 什么是项目管理

    项目管理就是将知识、技能、工具与技术应

    用于项目活动，以满足项目的要求。[4]

    而《中国

    项目管理知识体系》对项目管理有更深入的阐

    述：项目管理是一种基于系统思想与权变理念，面向对象的组织管理方法论。[3]

    它包括以目标为

    导向的临时性组织系统管理方法体系和以项目为

    导向的长期性组织变化管理方法体系：

    ■临时性的专门的柔性组织，对项目进行计

    划、组织、指导和控制。

    ■全过程的动态管理。在项目的生命周期

    内，不断进行资源的配置和协调，不断作出科学

    决策，从而使项目执行的全过程处于最佳的运行

    状态，产生最佳的效果。

    ■目标的综合协调与优化。项目管理应综合

    协调好时间、费用及功能等约束性目标，在相对

    较短的时期内成功地达到一个特定的成果性目

    标。

    对于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-1 3种典型组织结构的特点比较

    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反省，以前觉得整理文档是浪费时间，现在觉得不仅不会浪费时间，而且能提高沟通效

    率，不用一遍一遍说，一遍一遍澄清。以前觉得

    一些打破流程的做法是创新，现在觉得“一个天

    才的创新可以引起一场技术革命，但在交付项目

    中的一个创新却可能会引起一场灾难”，项目组

    必须遵守流程和规则。

    3.花钱vs.赚钱

    以前做研发项目经费是内部拨付的，成本控

    制的目的是不要超出预算，最多也就是怎么省

    钱。但如果真的超出了预算，也可以向公司领导

    申请增加，只要有相应的理由，都可以通过。

    而现在的项目是从客户兜里掏钱，如果超出

    了预算，项目就不能赢利。如果客户不满意就会

    投诉、拒绝支付。小M以前对“尊重客户、让客户

    满意”的理解，仅仅停留在要对客户态度好等表

    面层次上，今天才意识到“客户是上帝”真正的含义是“客户是给钱的”，客户对项目满意了才会心

    甘情愿的付款，公司才能赢利，自己才有工资、奖金。至于这两者的难度的区别，是一个所有人

    都应该明白的简单道理：“赚钱比花钱难”。3.1.2 “理论”和“实践”的差距

    小M作为“懂”理论的项目经理，以前还经常

    向其他同事传授知识，说起来过程组、知识域来

    一套一套的。而真正到了项目中，却发觉自己学

    过的项目管理知识一直都没用上，也不知道该怎

    么用。

    面对错综复杂的问题竟然理不出头绪，不知

    道该从哪里下手。自己现在好像已经被打晕了，根本不知道该出哪招。小M觉得，书本上的知识

    好比套路，但实战中的情况千变万化，不可能照

    着书本管理；原来运筹帷幄、决胜千里的想法非

    常幼稚，就像以为自顾自地练套路就能顺便击倒

    对手那样可笑。

    另外，很多事情仅仅是知道理论上该怎么

    做，但不知道实际上怎么“动手”。比如当前应该

    进行需求分析，但一天工作下来几个同事的成果

    五花八门，有的有书面记录，有的连个文档都没

    有。而小M自己也不知道开发这样的系统业务需

    求应该写成什么样子。实际上，缺的就是一个实

    践验证过的模板和流程，但这个差距就像“理论

    到实践的最后1公里”，看着就差一点点，但效果

    就成了“隔靴搔痒”，收不到实效。要想越过这最

    后1公里，需要的是实践经验，或者是有经验的人的帮助。3.1.3 “对事”和“对人”

    还有个问题小M刚刚意识到：学习项目管理

    时，觉着管理的对象是“事”；但实际工作中，管

    理或协调的对象全是“人”。

    人是活的，是有感情的，同样的事情，不

    同“人”做，或者用不同的态度应对，得到的结果

    会完全不同。

    例如，项目小组内一个刚刚毕业的年轻同

    事，能主动找相关客户了解情况，几天时间可以

    写完一个接口系统调研报告；另外一个老员工，整天坐在电脑前却什么也做不出来，做的一个切

    换方案也漏洞百出。刚刚在这名老员工提出调离

    项目组的时候小M才恍然大悟，他早就不想干

    了。这些情况不注意是看不出来的，项目管理书

    上也没有教过该怎么应对这样的问题。如果还沉

    浸在“振臂一呼应者云集”的想象中，距离一个“成

    熟”的项目经理就还有非常大的差距。

    项目中涉及的外部人员也很多，其间利益关

    系错综复杂。人际关系能力以及对“政治”的敏感

    与否，都可能造成不同的结果。例如，同样一件

    事情，A去说客户会拒之门外，B去说就会手到擒

    来。事后才知道，A受阻的原因是在某个场合上一句不合时宜的话让这位客户在领导前丢了面

    子，而B却在关键时刻帮他渡过难关。3.1.4 经验与教训

    初为项目经理往往豪情万丈，对未来充满憧

    憬和乐观。但是，必须做好一些准备和调整，才

    能避免被突如其来的问题搞得懵头转向。小M反

    思下来有几个方面的经验教训。

    首先，要调整好心态，做好应对困难的心理

    准备。

    其次，进驻项目前要阅读合同等商务文件。

    现在对于项目的范围、约束一概不清楚，对客户

    提出的要求甚至都不知道该不该做。

    第三，项目的目标是按期交付，整个项目组

    必须遵守流程和规则；在项目过程中文档和记录

    可以节省沟通时间，要不断与客户确认。

    第四，团队不是从天而降的，而是需要主动

    的建设过程。小M从来没有与团队成员好好沟通

    过；项目组里成员来来去去，每个人并不知道全

    局，相互之间也不熟悉，确实称不上团队。

    第五，面对面与客户沟通，了解他们的想

    法。小M除了与客户打了个照面和一起开会，没

    有一对一地与客户认真沟通过，不了解他们为什

    么不满，不了解他们的期望，因此很多事情没有做到点子上，必然事倍功半。

    知道了这些差距，也就知道为什么觉得项目

    经理难当了。3.2 最忙乱的第1周——项目启动

    小M思考之后觉得客户的投诉说得没错。一

    周马上要过去了，但这几天自己每天做了什么都

    不记得，没有一点工作思路。客户需要的不是个

    应付问题的人，而是指挥若定的项目经理。与其

    这样像没头苍蝇一样忙乱，不如好好规划下一周

    每天应该做点什么，抓住几件关键的事情集中解

    决。

    小M整理了自己的工作思路，觉得最重要的

    有5件事：

    1)建立组织和制度。建立项目的组织结

    构，确定职责分工，确定基本规章制度和工作流

    程。

    2)明确工作思路。应该兵分两路：一路确

    认工作范围，制定工作计划；另一路确定开发方

    法，特别是马上要确定需求文档的格式和工作流

    程。

    3)申请专家支持。为了弥补自己经验不足

    的问题，小M请领导派一个经验丰富的业务专家

    过来，对工作进行指导和把关。

    4)拜访客户。尽快拜访客户的主要相关领导，了解他们对项目的期待。

    5)集中培训。召开启动会，随后集中全体

    成员进行培训，介绍项目的规章制度、工作计

    划、工作方法、需求分析流程等。

    按照上面的思路，小M向S总进行了汇报，S

    总同意了小M的想法，并答应立刻派业务专家W

    老师到现场支持，这让小M心里踏实多了。

    后面希望有所改变，但究竟会怎么样呢？

    3.2.1 第一周的工作计划

    经过一个晚上的准备，早晨小M鼓足了勇气

    找到了客户方的项目负责人G总。说明了来意，然后拿出一份最近一周的“启动工作计划”征求G

    总的意见；同时说明，公司已经决定派业务专家

    W老师指导启动工作，今天就能到位。

    G总看了看计划，略微思考了一下，询问为

    什么只有一周的计划？后面的计划呢？

    小M解释，项目现在多方面工作搅在了一

    起，所以非常混乱。因此希望先建立组织，然后

    兵分两路。一路是业务组，负责进行需求分析工

    作，通过一周的时间完工成模板和方法的准备，一周之后进入正轨；另一路是项目管理办公室(ProjectManagementOffice, PMO)，负责进行项

    目的启动准备，筹备启动会。待工作启动、进入

    正轨之后，再腾出时间来同步制定后续计划。这

    样现在的人员就不会窝在一起互相等待了。启动

    工作流程如图3-2所示，启动工作计划见表3-1。

    图3-2 启动工作流程

    表3-1 启动工作计划G总觉得这样的安排没有问题，但还有一些

    细节需要考虑。例如，工作范围确认中发生分歧

    怎么办？会不会让所有的人等待？小M认为，确

    认范围是为了发现问题，有分歧可以先记录下

    来，然后一项一项地处理；目前无法弄清楚的事

    情，就作为项目假设记录下来，之后逐步确认。

    G总又问了W老师的经验背景，使用的模板和工作方法从哪里来等具体问题。小M说明模板

    是在以前的项目中使用过的，W老师来了之后会

    带领大家结合客户的具体情况进行一定修改。听

    了这些解释，G总脸上露出了难得的笑容。“好

    吧，就这样吧，明天开会，晚上请W老师一起吃

    饭。”

    走出了G总办公室，小M心中一块石头落了

    地，立刻开始准备明天的会议。

    晚餐G总、W老师、小M也谈得非常愉快，G

    总向W老师请教了很多问题，对第二天的会议安

    排也提前进行了讨论。

    回到了旅馆，小M觉得前几天的郁闷已经消

    散了许多，“如果早这样开始就好了，就将明天

    作为新的开始”。3.2.2 第一天的工作成果

    第一天，双方的主要骨干到了。除了G总、W老师、小M之外，还有公司的架构师、系统工

    程师，以及客户方面几个业务部门的代表，一共

    八九个人。

    G总主持会议，宣布当前各位就是项目的核

    心团队，今天的任务是确定这两个星期的“启动

    工作计划”，制定“项目管理计划”，确定组织结构

    和基本管理流程。

    小M接过G总的话题开始讨论。

    “启动工作计划”很快通过，大家的问题都是

    昨天G总问过的，小M胸有成竹地进行了回答。

    “项目管理计划”已经提前起草了草稿，所以

    问题讨论比较有针对性。这份计划确定了项目的

    阶段划分和工作方法、每个阶段的交付物、关键

    里程碑和关闭条件；还确定了项目的组织结构、规章制度、职责分工，以及基本管理流程、沟通

    和决策机制。

    尽管会议一直持续到晚上8点多，但是最终

    全部达成了一致。这一天的会议成效显著，项目

    管理计划、项目组织结构和职责分工出台了，如图3-3、图3-4和表3-2所示。

    图3-3 项目管理计划图3-4 项目组织结构

    表3-2 职责分工表3.2.3 启动的准备工作

    小M和G总等PMO成员，根据《启动工作计

    划》在随后的几天里紧张地开始工作了。

    1.确认项目范围

    项目中范围包括了两大类：一类产品范围，也就是应该覆盖的业务需求；另一类项目范围，是为了实现项目目标所需要完成的工作。

    第二类项目范围，大多是事务性工作。相对

    比较好界定，比如开发环境准备，系统安装调

    试，系统切换等。因为讨论的目的仅仅是界定需

    要做哪些事情，对于工作范围中理解的偏差，双

    方记录了下来，列为待决事项希望后续进行讨

    论，所以还算顺利。初步确定的工作范围见表3-

    3。责任矩阵中，P表示主要负责，S表示支持。

    W老师建议，产品范围使用统一的功能清单

    进行确认。为了规范大家的工作，根据经验将功

    能的层级进行了统一的约定：

    ■第一层是子系统，指相对比较独立、完整

    的一组业务功能。例如：存款子系统、贷款子系

    统等。

    表3-3 项目范围■第二层是功能集，指在子系统内按照业务

    特性归集的一组操作。比如客户信息管理、利率

    管理、还款管理等功能集。

    ■第三层是执行单元，是指一次完成的一个

    独立业务操作，比如新增客户、修改客户信息、查询客户信息等。

    这个简单的分类方法对于多个小组并行工作帮助很大，讨论不再像以前没有章法，工作成果

    也非常一致，效率很高。这就是经验啊!

    2.粗略工作量估算

    开发的工作量由于需求还没有最终确定，请

    W老师按照经验估算一下最高、最低、最可能三

    个值，作为基本的估算数据。对于项目范围内的

    事务性工作，按工作所需人数和大约持续的时间

    估算了工作量。汇总起来，得到了项目总体工作

    量。

    小M向上级书面汇报粗略估算的项目总体人

    力要求。S总、W老师和公司几个专家一起帮助

    小M对估算结果进行审核，认可了估算的结果。

    3.人力资源配置

    当前最重要的是确认启动项目的人力需求。

    小M比较详细地测算了启动之后需要的人员数

    量，各级岗位人员的技能要求、工作开始日期、工作结束日期等信息。S总确认之后，开始向小

    M的项目中派遣人员。

    同时，事业部也开始根据估算数据从公司内

    协调和寻找资源，为后期工作做准备。客户方

    面，G总从各个业务部门调集所需要的资源，并

    约定下周一参加项目启动会。4.客户沟通

    《项目管理计划》整理出来之后，G总让高

    层领导在上面签字批准，这下项目组可有了“尚

    方宝剑”。小M、W老师在G总的带领下，逐个拜

    访客户各个方面的相关领导。

    拜访内容一是让干系人了解这个项目，了解

    干系人对项目的要求和期待。二是提交《项目管

    理计划》，说明项目与这些部门的关系，并借此

    机会邀请他们参加下周一的启动会。

    按照公司的要求，小M还确定了三名客户主

    管作为满意度调查对象，获取其联系方式(电子

    邮件、电话)，通知了公司负责调查的部门。

    5.确定开发过程

    业务小组在W老师的指导下，进展非常有

    序：

    ■W老师与架构师、业务负责人一起，根据

    项目实际情况对开发过程进行裁剪，制定一个

    《项目开发过程》文件。按照项目的开发阶段，明确各阶段交付物，制定交付物的模板。

    ■对于需求分析过程的模板进行了确认和修

    改，并选择了几个典型功能作为案例，进行实际

    使用的演练和改进。■经过演练之后，结合客户的特点对需求分

    析的过程进行了调整，制定了完整的模板、流

    程；演练的结果做成了“样例”，参加过演练和方

    法整理的人员成了可以培养和指导他人的“种

    子”了。

    最后W老师与大家一起，将这些资料整理成

    了培训资料，准备启动会之后对所有参加项目的

    人员进行培训。3.2.4 项目启动会

    经过一周的忙碌，就要召开项目启动会了。

    但在启动会之前，PMO召开了一个准备会，确定

    启动会的议程，审核整理启动会资料。

    会议上要说明项目目标、阶段划分、组织结

    构、管理流程等关键事项，需要大家达成一致；

    对于关键角色任命，事前也听取了大家的意见。

    终于等到了召开启动会的时刻，这是项目的

    一个重要的标志性事件。参加会议的不仅有双方

    的高层领导、相关部门负责人，还包括核心团队

    和新报到的项目组成员。

    启动会由G总主持，议程如下：

    ■G总介绍议程和来宾。

    ■小M介绍项目目标、阶段计划、管理方

    法。

    ■发布项目的组织结构图和任命。

    ■关键角色确认了职责并作出承诺。

    ■双方高层领导做项目动员发言，激励和鼓

    舞士气。■各个相关部门领导表态支持项目工作。

    会后，会议的内容整理成《项目启动会纪

    要》。纪要中记录了项目的启动过程，项目组成

    员的承诺，而且有各级领导的明确表态。这份资

    料作为项目组的第一份正式公告发布了，同时宣

    告了项目的成功启动。3.2.5 培训开始了

    启动会之后趁着大家都已经到位的机会，立

    刻展开了紧张的培训。培训计划根据项目对员工

    知识和技能的要求设置了一系列课程，以帮助项

    目组成员尽快进入状态，培训计划见表3-4。

    表3-4 培训计划

    为了达到培训的目的，每次培训后还要进行

    测试和培训反馈，一旦发现项目组在能力上有什

    么弱点，就要进行补救，或者以后加以注意。

    过去的一周好忙啊!现在好了，其他人忙起

    来了，小M终于有时间和G总仔细考虑项目长远的事情了。3.2.6 经验与教训

    项目的启动阶段多方面工作混杂进行，容易

    忙乱，造成项目经理应接不暇。这个时候，最需

    要的是一个“周计划”，迅速建立组织结构和分

    工，让大家分头进入工作状态，然后再着手制定

    后续详细的项目计划。

    启动阶段如果有一个有经验的专家指导，帮

    助项目经理落实很多关键环节，可以让客户信

    服，还可以让启动工作有序进行。

    启动会非常重要，其意义不仅在于宣布项目

    的启动，而且是要求人员到位的关键时间节点。

    会议请双方高层领导出席和表态，可以让项目后

    续的推进获得广泛的支持。

    启动之后立刻进行培训，不仅可以统一大家

    的工作方法，而且可能形成统一规范。3.3 甲方乙方——商务项目全过程

    需求分析已经开始，其中一个业务主管对项

    目组的抱怨非常大!

    事情是这样的：开发工作分成多个子系统，每个子系统有一个小组在分头整理需求。但这名

    主管还要求安排一名人员跨系统统筹，负责统一

    各子系统业务规范。

    比较强烈的一个要求是统一各个业务子系统

    的代码表。代码表是一张参数表，例如，凭证种

    类中“01代表身份证，02代表户口本”，操作的时

    候从小键盘输入数字比鼠标操作快得多，能减少

    操作时间，便于系统存储和查询。

    但原来各个子系统是由不同厂商开发的，编

    码不同，客户希望改变现状。但是，项目组的技

    术人员对这样的工作不重视，迟迟没有理会。这

    让主管非常恼火，多次在会议上强调这项工作的

    重要性。

    为了应付此事，技术人员出了个评估报告，说明如果真的要统一，不光要花大量时间去梳

    理，而且会多出很多额外的工作。比如，维护各

    个子系统的对应关系就需要很大的工作量；如果使用动态的参数表，每次操作都从数据库中读取

    数据可能会影响系统性能等。

    客户的业务主管不是技术专家，对这些解释

    听不太懂，但对这样的反馈非常不满，认为都是

    在找“借口”。小M知道之后找到了这位业务主管

    进行协商。

    3.3.1 需求背后的需求

    客户主管终于等到有人关注这个问题，于是

    打开了话匣子，向小M说明了提出这个需求的背

    景。

    原来，这是“综合服务窗口”的要求。以前客

    户办理不同的业务需要到不同的窗口，这样服务

    网点里有的队伍很长，有的队伍很闲，工作效率

    低，客户满意度也低。而“综合服务窗口”要求同

    一个柜员能够处理多种业务，因此，客户到任何

    一个窗口都可以办理业务，这样既可以提高工作

    效率，也可以提高客户满意度。

    以前，不同业务系统由不同的厂商开发，业

    务流程和界面差异较大，代码表也是各有各的标

    准。但因为一个窗口只用一个子系统，不会有太

    大问题。但如果改成“综合服务窗口”，如果有的

    业务中“身份证”代码是01，有的业务中代码是02，则会引起很大的混乱。

    小M经常在项目组里听到“综合服务窗口”这

    个词，不过刚刚才闹明白是怎么回事。为了获得

    更多信息，忙问业务主管在哪里可以看到这些需

    求的详细说明。主管很诧异，“这是项目立项的

    时候就提出的业务流程改进方案啊，你可以去看

    看招标书，投标的时候你们就承诺了，不会现在

    不认账吧？”

    小M只看过合同，还真没看过标书。于是找

    来了这些文件，发现其中不仅有对”综合服务窗

    口”的详细描述，还有很多其他方面的业务需

    求。而几乎所有的功能需求，都是围绕着这些业

    务需求提出来的，这些“需求”背后的“需求”，让

    小M对很多分歧恍然大悟。

    这是因为，虽然甲乙双方在谈需求，但出发

    点不同，造成了双方关注点和思维方式不同。客

    户关注的是系统如何支持业务流程，背后的需求

    是“实现业务目标”。技术人员关注的是合理技术

    方案，背后的需求是“工作量”、“实现难度”和“系

    统性能”。就拿这个例子来说：

    ■从客户角度考虑，业务目标之一就是“提高

    工作效率、提高客户满意度”。为了实现这样的

    业务目标，流程改进方案就是实现“综合服务窗口”。为了支持“综合服务窗口”，就需要业务规范

    统一，因此提出了“代码表一致”、“统一维

    护”和“子系统对应”等需求。

    ■从技术人员角度考虑，上述需求只会影响

    到“界面操作”，不是一件重要的事情，但付出的

    代价很大：需要在数据库保存代码表，要为子系

    统作映射表，还要统一进行维护；而为了实现这

    个技术方案，需要付出额外的工作量、牺牲系统

    性能、增加了实现难度，如图3-5所示。

    图3-5 甲乙双方关注点的差异

    由于最根本的出发点不同，在双方进行沟通

    的时候，尽管在谈同样的需求，但是一面的出发

    点是“提高工作效率、提高客户满意度”，另一方面的出发点是“工作量”、“难度”和“性能”，不一

    样的思维，不一样的语言，沟通不畅就可以理解

    了。3.3.2 双方眼中的不同生命周期

    甲方、乙方眼中的生命周期有什么不同呢？

    小M眼中“项目”的起点，在客户眼中已经是“执

    行”阶段了。因为在小M进入项目之前，客户

    的“项目”早已经开始了，已经做了大量的论证和

    分析工作。这个过程有点像接力赛，但是因为遗

    漏了接棒之前的信息，所以造成了一些偏差。

    小M按照客户所说的一些项目的关键点，结

    合项目管理中的生命周期概念重新进行了梳理。

    发现客户眼中生命周期是这样的，如图3-6所示。图3-6 典型生命周期实例

    第一，启动项目，目的是识别需求。最初

    的“需求”是来自业务部门，比如工作效率低、客

    户满意度低等。为了解决这个业务问题，客户内

    部对需求进行了确认，提出了主要的改进方法和

    改进目标，计算投资收益比，分析厂商所应具备

    的条件，最终完成了可行性分析。根据可行性分

    析结果，客户批准了预算，完成了立项，项目就

    产生了。之后一个小组与咨询公司一起细化了项

    目的需求和各种规格，发出了《招标书》。小M

    看到的很多业务需求，就是这个阶段产生的。

    第二，组织和准备，目的是确定解决方案。

    各个符合资质的厂商收到了招标书之后，根据规

    格提交了《标书》介绍自己的解决方案，以及报

    价。最终客户根据公司实力、方案优劣和报价情

    况，选择了小M所在的公司，进行商务谈判并最

    终签订合同。小M在这之后才正式开始接手项

    目，这也是乙方眼中的项目开始。

    第三，执行项目工作。目前小M要做的就是

    带领项目组完成合同规定的任务。这时，项目成

    败的责任通过合同转移到了小M的公司头上。小

    M要代表公司与客户确认项目目标和范围，制定

    计划，协调资源完成需求、设计、实施工作，直

    到项目顺利上线。上线标志着完成了项目交付成果和执行阶段的结束，但是，项目并没有结束。

    第四，结束项目。系统上线之后，小M的项

    目组要移交工作成果，将系统交接给维护人员，结清各种款项。这时对小M来说项目可以结束

    了，项目的责任又重新回到了客户身上。但是，对于客户来说项目还没有结束。客户在接受新的

    系统之后，要使用系统实现原定的业务目标，根

    据运行的情况评估“工作效率是否提高、客户满

    意度是否提高”，从而确定项目的成败。

    如此看来，小M只是经历了项目中的一段。

    由于没有参加论证阶段，所以可能遗漏一个非常

    重要的信息——客户“为什么要做这个项目”。客

    户一定知道在项目完成之后，“可以解决什么问

    题，能带来什么价值”，这才是客户心中的项目

    成功标准。3.3.3 客户为什么做这个项目

    客户为什么要做这个项目？这是最本质的业

    务需求。需求分析确定的功能需求，都是从业务

    需求推导出来的，都必须为业务需求服务。

    举个例子，客户去买衣服的时候，一定知道

    自己为什么要买衣服吧？可能是“御寒”，可能

    是“漂亮”，也可能是“体面”，也可能是因为在打

    折。

    一般的营业员会问客户颜色、款式和面料等

    方面的要求，拿到一件就努力说明“这件衣服最

    适合你”，可能一件一件不停地试，但客户始终

    都会挑出其他的毛病。

    而有的营业员会努力弄清楚你为什要买，问

    你什么场合穿。然后，再帮助客户作出取舍，如

    果为了御寒会强调保暖性能，并请你适当牺牲漂

    亮；如果是为了漂亮，就要找款式新颖、颜色流

    行的，强调价格是合理的；如果为了“体面”就要

    找面料和做工好的，就要适当牺牲价格；如果是

    为了便宜就要强调性价比，并对比以前的价格。

    小M他们犯的错误，是第一种营业员的错

    误。上来就聚焦在功能需求上，一下子扎在了功

    能需求如何实现上，而忽略了“客户为什么做这个项目”。

    这样看来，“按期交付”只是项目的最低要

    求。交付的成果能“解决客户的问题、给客户带

    来价值”，才能让客户成功，才能让客户满意。

    想让客户满意，就一定要站在客户立场上考

    虑问题；站在客户立场上考虑问题，就要了解客

    户的业务，弄清楚客户为什么有这样的要求；如

    果弄清楚了这个“为什么”，对于什么是重要的、什么是不重要就容易判断了。

    想到这里，小M和技术人员再次找到了业务

    主管，认真倾听了主管的需求，并一起讨论解决

    办法。讨论中发现了一些重要信息。例如，其实

    代码表并不经常改动，所以每次从数据库访问的

    方式确实不可取。而比较合适的替代方案是帮助

    客户建立一个数据字典管理各种代码表，并在需

    求分析的过程中进行维护。而开发的时候，可以

    通过一个小程序自动根据数据字典产生下拉列

    表。为了便于项目结束后客户能自己维护，还专

    门设计了一个使用方便的小工具。

    这个方案开发工作量不大，对性能没有影

    响，主要工作由客户方面承担，还可以保证客户

    的长期维护。因此，客户的业务主管对这样的结

    果非常满意。其实，项目组并没有按照客户最初的要求去工作，但是在了解了客户真正的需求之

    后，提供了一个更好的解决方案，达到了双赢的

    局面。3.3.4 经验与教训

    由于甲乙双方的立场不同，关注点不同，很

    多事情会产生分歧。要想获得客户的满意，必须

    从客户的角度看问题，了解客户表面需求背后

    的“需求”，因为这是客户判断项目成败的标准。3.4 都是婆婆——认识项目干系人

    在清理外部系统接口的时候，小M遇到了不

    小的麻烦。

    部分老系统在新系统上线之后仍将被保留。

    但是，为了界面一致性，需要将保留功能的界面

    用新系统重新开发，方便用户操作和培训。

    为了重写这些老系统的功能界面，需要原来

    的设计文档和接口资料。但是，负责老系统的厂

    商D与小M的公司存在着竞争关系，而且新系统

    上线之后厂商D的系统会被逐步取代，对工作自

    然不支持，因此以技术保密为借口拒绝提供设计

    文档，仅提供了最初的客户需求文档和接口标

    准。如果没有设计文档，就无法知道操作流程和

    页面栏位的控制关系，只能仿制页面的样子先做

    出来，再一遍一遍地去试验。这样的方式进度极

    其缓慢，几乎无法完成工作。

    小M找到了G总寻求帮助，G总表示会出面协

    调。但等了几天没有进展，多次催问之后，G总

    表示因为D公司是竞争对手，所以没法帮忙了。

    小M觉得项目中婆婆太多了!没想到还会碰

    到自己的竞争对手，这的确是件麻烦的事情。该怎么办呢？!

    3.4.1 项目的组织关系

    项目的组织关系挺复杂的，其实小M一直都

    想整理一下，看看内、外部有哪些主要的角色，他们主要职责是什么。小M对照着项目中的具体

    部门和人员画了一张草图，将他们之间的汇报关

    系和沟通渠道标示了出来，如图3-7所示。

    图3-7 项目干系人对号入座

    项目中主要人员和客户的人员组成，见灰色

    的部分。这些成员来自不同的部门。

    这个项目的用户实际上是各个业务部门，他

    们直接提出项目的要求，并最终使用项目的成果

    实现业务目标。但在客户内部，这个项目由信息中心负责；为了便于管理，信息中心任命了甲方

    项目经理G总。

    G总原来是信息中心主管开发的副主任，代

    表客户对项目整体进展和结果负责。他直接向信

    息中心主任汇报，项目中的重大事项甚至直接向

    总裁汇报。G总带领信息中心一部分开发人员共

    同参加了项目组，还负责领导多个部门的业务骨

    干。项目中的需求确认、验收测试、用户培训、系统实施等许多工作，都是由G总的团队承担

    的。

    从公司角度来看，项目经理是小M，平时的

    汇报途径一是公司内事业部总经理S总，二是客

    户方G总和信息中心主任。S总与客户的信息中心

    主任关系比较好，一直保持着密切的沟通。

    G总和信息中心主任向客户方的总裁汇报。

    这个项目就是总裁批准的，也是他一直在推动

    的。尽管总裁不关心项目的细节，但是经常直接

    过问项目的进展，并为项目组从各个部门协调资

    源。

    S总向公司的CEO汇报，一般情况下如果想

    与客户方总裁沟通，需要通过公司的CEO。

    项目组中的公司内部员工，有来自事业部的

    顾问和技术人员，还有是来自产品部门的支持人员。他们有自己的部门经理，但在项目执行过程

    中对小M负责，按要求完成任务后就可以离开项

    目。

    除了这些角色，项目中还有很多合作厂商。

    一些合作厂商是客户直接的采购对象，另外一些

    是小M的采购对象和支持伙伴。因此，一部分伙

    伴通过公司联系，另一部分通过客户联系。

    问题是，厂商D不属于项目的伙伴和供货

    方，而是信息中心的供货方。信息中心的另一位

    副主任负责与厂商D联系。3.4.2 项目打破了组织的平静

    如果说组织原来是一池平静的水，项目就好

    比一块石头，不仅会改变组织的结构和流程，而

    且重新分配了人员的利益和权力。自然有些人是

    受益者，有些人是“受害者”。

    小M了解到，这个项目是一把手主抓的项

    目，是客户业务转型的重要举措，对客户来说意

    义重大。信息中心主任当着一把手的总裁立下了

    军令状，G总也是总裁点的将。

    G总虽然面临着很大的压力，在新系统上线

    之后他的团队将承担运维和升级任务，客户内部

    都认为他是信息化的“明日之星”，因此其团队积

    极性很高。

    而负责旧系统运维的人员，新系统上线后有

    些会逐步转到新系统运维团队中，而有些人到底

    今后怎么安排现在还不明确，负责与厂商D联系

    的那位副主任就是这种情况。

    虽然他负责老系统的维护，但是新系统上线

    之后前途未卜，对于这个项目自然有一些抵触情

    绪。而厂商D本来就是竞争对手，更不可能支持

    这个项目，因此想推动他们帮助解决问题自然十

    分困难。现在的情况比较清楚了，但矛盾和困难的事

    情是需要推动抵触项目的组织，为项目做事。3.4.3 婆婆也能帮你

    从组织关系上分析，要想解决问题必须通过

    信息中心主任。小M与G总商量，希望向信息中

    心汇报这件事情。厂商D在信息中心还有其他的

    业务，不会为了这样一点事情得罪信息中心的主

    任。另外，建议G总从信息中心调集一名懂原有

    系统开发的人员，如果真的拿不到文档，至少有

    人能说清楚是怎么回事。

    G总同意这样的安排，并说自己的一个下属

    原来就是负责老系统维护的，也非常愿意进入这

    个项目。但他自己不太愿意出面进行汇报。一方

    面，负责老系统运维的那位副主任是自己的老上

    级，因为这个项目G总提升了，变成了他的平

    级；项目启动之后又从他那里调集了很多人，对

    他的工作造成不小的影响，本身就有点过意不

    去；如果继续从他那里要人，还要指责他负责联

    系的厂商D不支持项目，恐怕会影响两个人之间

    的个人关系。

    小M完全能够理解G总，自己没有什么人际

    关系的负担，于是提出可以从项目角度直接反馈

    问题。但是自己直接找信息中心主任好像级别不

    够，有点犯憷。突然想到自己的上级S总与信息

    主任关系不错，也许他出面可以帮助解决问题。小M向S总汇报了事情的原委，并希望得到

    支持。隔了一天，S总反馈已经与信息中心主任

    谈过了，会解决问题的。很快，信息中心主任就

    找到了小M和G总了解情况，并要求小M提交一

    份书面报告。

    第三天，G总告诉小M，在信息中心主任主

    持的工作例会上，讨论了小M的报告，信息中心

    对此事形成了几点决议：

    ■再次重申了项目的重要性，各个部门必须

    全力配合。

    ■确定调集一名参加过原有系统开发的人员

    加入项目开发团队。

    ■通过正式渠道通知厂商D，按照原来的合同

    要求应该提供设计文档；如果其不能履行合同义

    务，将中止与其任何合作。

    烦恼了很久的事情，突然间就圆满解决了。

    小M自己也没有想到，S总出面可以发挥这么大

    的作用。

    不仅如此，此事也改进了小M和G总的关

    系。以前两个人“各为其主”，因此冲突比较多。

    这次两人能够密切合作顺利地解决了问题，有

    点“英雄惜英雄”了。3.4.4 经验与教训

    项目中的干系人关系非常复杂，遇到困难的

    时候，冷静分析谁是项目的得益者，谁是项目的

    失利者，就可能发现解决问题的关键点。项目经

    理不用将“所有问题都自己扛”，可以巧妙利用非

    组织关系，可以设法获得高层支持，就有更多解

    决问题的钥匙了。第4章 理论到实践——“落地”的那几

    招

    4.1 做不完的项目——目标和范围

    在确认项目范围的时候，小M发现甲、乙双

    方存在着比较大的分歧。

    事情是这样的，客户有好几百网点分散在各

    地，安装调试工作除了要在主机房内进行，还要

    到各个网点进行。但这项工作由客户来做，还是

    项目组来做，合同中并没有写清楚。

    客户觉得合同虽然没明确写明，但是肯定应

    该由乙方做。因为项目的目标是“确保系统被客

    户正常使用和实现商业目标”，显然应该包括安

    装、培训和支持!

    但这项工作如果乙方来做，就算项目组全体

    人员一个一个网点地去安装，至少也要大半个月

    的时间。更让小M傻眼的是销售承诺了一年的免

    费维护，也就是1年中如果有任何升级和版本更

    新，都需要覆盖到几百个网点。这是小M的团队

    无力承担的，如果按照这个要求去做，这将是个几乎做不完的项目。

    小M找到了公司内的销售人员，询问当时是

    怎么回事。销售人员说当时已经看到这个问题

    了，一般这部分工作都是客户的IT部门做，为了

    快点签约就没谈。销售轻松地说：“咱们不做就

    得了，可以让客户自己做。”这让小M非常恼火!

    现在面对客户可不是这么简单的一句话能解决

    的。

    小M陷入两难境地，如果接受这部分工作就

    需要投入大量人力，项目就亏大发了!如果不做

    这部分工作，系统不可能上线，不要说客户满意

    度了，公司不被告就不错了。

    4.1.1 目标和范围

    确实如客户所说，在公司的投标方案中承诺

    了“确保系统被客户正常使用和实现商业目标”。

    但是，对于其中的一些工作怎么做、谁来做，却

    并没有说清楚。对小M来说，如果工作范围和职

    责都没弄清楚，项目的边界就是不明确的，就很

    难按照预定的时间、成本和质量完成任务。

    这件事必须跟客户讨论清楚，最现实的解决

    方案是请客户帮助一起做。小M只好找到G总商

    量。G总拿着合同上的条款明确地告诉小M，乙

    方负责系统开发和顺利移交，从合同上看没有什

    么好谈的。小M也承认，在签订合同的时候，没

    有识别出这背后隐含的工作量。但是，实际情况

    是执行起来确实有困难，希望得到G总的帮助，商量一个解决的方法。

    G总态度缓和了一些，告诉小M他对于这个

    问题其实也有同样的烦恼。因为新的系统上线之

    后，客户的组织结构也要进行相应调整，IT支持

    将集中运维，IT支持人员大大减少。小M的团队

    总有离开的时候，之后升级和维护的烦恼就是G

    总自己的了。

    在这点上两个人的有个目标是一致的。如果

    能够实现远程的运维管理，就不需要很多人到现

    场安装和维护，这才是真正的解决方法，这下两

    个人的共同语言多起来了。

    分析下来，实际上工作量主要来自于版本的

    升级和简单故障排除。目前除了硬件的故障需要

    到现场，一些简单故障可以通过远程接入解决，比较麻烦的是版本的升级工作。有的网点可能某

    些日期不开门，错过版本升级的时间。如果能设

    计一个自动升级系统，主动下载补丁，控制版本

    序列，网点就能够自动升级，减少很大维护工作

    量。对解决方案的思路达成一致，此事大大往前

    进展了一步!但是，额外开发这样一个系统需要

    一定的工作量，而且这个功能不包括在功能清单

    中，对于公司来说属于一个比较大的工作范围变

    化，该怎样说服公司呢？4.1.2 “增加范围”还是“减少范围”

    “工作范围是实现目标的途径，是为目标服

    务的”。目标公司已经承诺了，路径有两种选

    择：一种是调集大量人力帮助客户安装；另一种

    是增加一个版本自动升级系统。

    版本自动升级系统是因为客户潜在的需求而

    引发的额外工作，但从目前分析看却是最佳解决

    途径。小M与S总就此事进行沟通，介绍了背景

    和可选方案。并说明了自己的观点：虽然额外开

    发一个版本自动升级系统增加了工作范围，但是

    从另一个角度来说，大大减少了实施的工作量。

    而且，这样一个版本自动升级系统不仅可以在这

    个项目中用，将来也可以在其他客户那里复用，提升解决方案的竞争力。

    对于小M提出的“无法拒绝的理由”，S总同意

    与产品部门协调，希望将这样一个模块算做产品

    的一部分。果然，小M很快接到答复，这个方案

    获得了公司产品部支持，产品部会派人参与该系

    统的开发，并且不计入小M项目的成本。这让小

    M喜出望外!

    但是，尽管版本自动升级系统以后可以自动

    升级网点的系统，可是网点的首次系统安装和配置仍需要到现场执行，因此，至少要到网点跑一

    次。

    小M再次找到了G总，说明公司已经决定免

    费为客户开发一套版本自动升级系统，以后的升

    级工作可以自动进行了。但是，初次安装工作希

    望G总的部门派人参与，共同承担。

    G总对于能够免费获得一个版本自动升级系

    统非常高兴，这样以后他的团队就省事多了。对

    于现场的初次安装，愿意共同负责。但这不仅是

    工作量问题，还有一些现实的困难：

    ■各个网点系统都在工作中，并行安装另外

    一套系统只能晚上进行，比较辛苦。

    ■需要确认新系统的安装是否会影响原系统

    的正常运行。

    ■自己部门的人员对新系统不熟悉，怕出错

    误，不能保证安装的成功率。

    听到这些问题，小M知道G总已经在从执行

    的层面考虑问题了。于是回去与几个骨干仔细研

    究G总的问题。很快拿出了更新的方案：

    ■在网点的系统中建立一个独立的分区，可

    以通过一个命令在新老两套系统之间切换，这已

    经在测试机上通过了验证。■将安装程序完全自动化，安装人员仅需输

    入几个简单的配置参数。

    ■开发了一个检测程序，对安装结果进行验

    证。

    ■安装的日志可以导出，出现问题也可以拿

    回来进行分析。

    ■安装之后组织一次全网点参加的绿灯测

    试，验证基础安装完毕。

    ■项目组会安排一些工程师，带领客户的技

    术人员完成头几家的安装。

    这样，小M只要承担10%的网点安装工作即

    可；如果客户动员所有的IT支持人员参加安装，只要一周的时间就可以完成所有网点的首次安

    装。

    方案至此，客户方已经完全接受，也同意安

    排技术人员晚上加班进行。为了避免夜长梦多，小M与客户签署了一份补充协议，就上述的内容

    进行了书面纪录。

    这样，客户获得了一套系统，解决了长期维

    护升级问题；尽管不马上给钱，但是对于这部分

    额外工作至少有了书面的认可。公司通过了这个

    项目获得了一个新的模块；而小M终于解决了项目中最大的一个工作范围的分歧。4.1.3 为什么会产生分歧

    此事过去之后，小M又陆续遇到了一系列工

    作范围的分歧，看下来主要由三类原因造成：

    第一，没说清楚，是商务谈判过程中的遗漏

    造成的。例如上面的实施问题，销售人员当时的

    关注点是迅速签约，而不是如何交付，遇到模糊

    问题怕节外生枝，所以避而不谈；而甲方有最终

    验收的主动权，有回旋余地，遇到这样的问题也

    没有意愿主动提出来。一旦项目经理接手之后，随着项目的深入这些早期的隐患都将陆续暴露出

    来。因此，售前过程最好项目经理能同时参与，一定程度上能够避免类似的问题。

    第二，没想清楚。理想中的项目一开始就有

    明确的目标，但因为项目的独特性，一定会还有

    很多不明确的地方早期谁都没有想到。现在的IT

    项目，已经不是简单的业务流程的“电子化”，而

    是通过信息技术对业务流程进行再造或业务创

    新。因此，对到底要做成什么样，可能会遇到哪

    些问题，开始确实很难想清楚，需要在过程中逐

    步进行明确。

    第三，没法控制。一些大型项目可以长达几

    年，这样长的时间内，商业环境、政策法规的变化会对项目范围、需求造成重大影响，这是双方

    都不愿意看到的变化。客户组织结构变化、人事

    变动等因素，对项目的影响更加直接。例如，新

    的领导思路的变化，甚至对项目的重视程度的变

    化，都可能直接影响项目的走向。

    这些因素之间还可能相互影响，叠加之后造

    成的后果就可能造成项目的工作范围不断变化，因此，“如果没有对范围的定义和说明”，项目可

    能做不完。4.1.4 重要的文档——范围说明书

    为了能做完项目，需要一个比较清晰的项目

    范围基准文件——《范围说明书》。项目的《范

    围说明书》的作用是详细记录项目可交付的成

    果，以及为提交这些可交付的成果所必须开展的

    工作。有了《范围说明书》，项目团队才能展开

    更详细的计划，才能评估变更请求是否为额外工

    作。

    《范围说明书》中主要的内容之一是活动分

    解(Work Breakdown Structure, WBS)，WBS将

    项目的“交付物”自顶向下逐层分解成易于管理的

    若干元素(这些元素组成一个树形图)，结构化

    地定义了项目的工作范围。WBS每细分一层都是

    对项目元素更细致的描述，细分的元素称为工作

    细目，其中最底层的工作细目(树形图的叶节

    点)叫工作包。为了方便分层统计和识别，WBS

    中的每个元素都被指定一个唯一的标识符，并分

    层表示。

    除了WBS，《范围说明书》还包括以下内

    容：

    ■前言。介绍编写《范围说明书》的主要内

    容、编写目的、适用范围和效力、生效和终止的条件及日期等内容。

    ■项目概述。说明项目要实现的主要业务功

    能；项目与现行系统和其他系统的关系；目标系

    统的硬件和软件结构等。

    ■产品范围。描述所提供的产品、服务和成

    果的特征，可以通过需求文件记录。

    ■项目范围。为完成项目目标所必须完成的

    工作；明确哪些内容不属于项目范围，有助于避

    免分歧。

    ■双方职责。对于双方需要配合完成的工作

    (如需求分析)，要明确说明双方各自承担的工

    作内容和担负的责任。

    ■交付成果。交付成果包括组成项目的产品

    或服务的各种结果，也可以包括各种辅助成果，比如项目管理报告和文件，对于可交付的成果描

    述可详可简。

    ■验收标准和流程。定义已经完成的产品、服务或成果的验收过程和标准。

    ■项目的约束条件。是指与项目范围有关，且制约项目团队的约束条件。例如，预算限制、强制性的里程碑时点、政策法规、合同条款等。■项目的假设条件。与项目相关的假设条

    件，以及万一不能成立而造成的可能结果。

    ■变更流程。明确规定项目发生变更时的处

    理流程，并对照组织结构说明最高的决策机构。

    按照上述的内容，小M整理了《范围说明

    书》，如图4-1所示。

    实际上，与客户讨论和确认《范围说明书》

    确实比较费时间。但小M觉得，这项投入是非常

    值得的，哪怕是知道与客户有哪些分歧也很重

    要。范围核实的过程秉承了几个原则：

    图4-1 范围说明书■对于没有说清楚的，现在就进行澄清，或

    者至少记录下来这里有个问题。

    ■对于没有想清楚的，设定假设条件，比如

    目前的构想是什么，将来可能变化；或者，明确

    说明某个地方还需要进一步讨论。

    ■对于无法控制的外部政策等变化，在项目

    的制约条件中进行了列举。例如，说明某个模块

    是依据×××政策的标准开发的，如果政策发生了

    变化，则需要进行必要的变更分析。

    ■对于依赖的、无法控制的外部条件，在假

    设条件中进行列举，例如，系统期望用一个尚未

    发布的新的操作系统版本，那么假设条件就是这

    个操作系统能够按期发布。

    ■核实过程中，不但要确认范围，还要确认

    双方的分工和职责。

    ■不但确认交付成果，还要确认中间的过程

    文件。中间结果并不一定向客户提交，但却是一

    个工作完成的证据。

    完成之后，小M召集各方面的人员，对《范

    围说明书》进行了重新的评审，确认之后小M心

    里踏实多了。4.1.5 经验与教训

    项目的目标不等于工作范围，工作范围是项

    目目标的实现途径。善于发现项目潜在需求，是

    确定工作范围的一个要点。

    一份清晰的工作范围说明书，是后续工作的

    依据；就算有不清楚的地方，也可以通过假设的

    方式先记录下来。

    如果发生分歧，不要回避，必须进行澄清和

    谈判。否则拖到最后更为被动；宁可事前消除客

    户不切实际的“期望”，也不要事后让客户“希望破

    灭”。

    项目经理最好能参与售前活动，帮助客户经

    理识别模糊的范围，与其事后花时间打官司，不

    如签合同前费点工夫讲清楚。4.2 三个臭皮匠——制定计划的方法

    范围总算是理出来了，制定计划是小M最拿

    手的了。按照标准流程小M花了1天时间就完成了

    一个“详细”的计划。但是把计划拿出来之后，立

    刻受到了挑战：很多工作步骤“太外行”，任务之

    间的依赖关系不符合实际，时间安排也有很多不

    合理的地方。

    W老师建议，既然项目骨干已经基本到位

    了，应该大家一起制定计划；毕竟小M不可能每

    个方面都熟悉，多听听大家的意见肯定有益，小

    M接受了W老师的建议。

    会议开始了，大家采用头脑风暴的方法列出

    任务。一旦打开了话匣子，每个骨干都能如数家

    珍地把自己负责的工作讲解一遍。小M感受到了

    集体的智慧，也切实体会到了项目的复杂性和专

    业性。

    很快任务就密密麻麻地列了一白板，问题也

    来了，依赖关系越来越复杂，箭头越来越多，白

    板越写越乱，画出来的网络图是让神仙也头晕的

    蜘蛛网。而七嘴八舌、零七碎八的讨论过程让场

    面越来越混乱。自己一个人制定计划“智慧”不够；团队制定

    计划“智慧”够了，但理不出头绪。“三个臭皮匠、赛过诸葛亮”不假，但是臭皮匠应该怎样合作

    呢？

    4.2.1 计划的“计划”

    小M觉得，为了让大家能够合作制定计划，首先要整理一下工作思路，做一份制定计划

    的“计划”：

    第一步，根据WBS制定活动清单。因为活动

    都有一定的工作步骤，重点是大家一定要约定分

    解到活动的哪个层次。

    第二步，确定活动之间的依赖关系，绘制网

    络图；网络图可以让大家看到整体格局，然后再

    进行调整就比较直观和方便。

    第三步，根据网络图的依赖关系和工期要

    求，确定各个小组的资源配置。根据资源的情况

    进行调整和平衡，完成进度计划和资源计划。

    第四步，根据资源和进度计划，制定项目的

    预算。

    对于这个计划的“计划”，开发组提出了一个

    问题：产品功能需求清单有好几百项，这几百项再按照需求、设计、编码、单元测试、集成测

    试、系统测试和验收测试等工作步骤展开，会形

    成一个好几千项的活动清单，估算和管理都非常

    困难。

    讨论后大家觉得产品范围内的活动分解，只

    要写清标准的工作步骤就可以了。而具体的内

    容，则通过需求矩阵进行管理。

    需求矩阵按照子系统、功能集、执行单元的

    结构列出所有的功能需求，每列则对应每项功能

    的工作步骤以及每个步骤的工作量。工作量参考

    一份估算标准，并用最低、最高、期望三个值描

    述，见表4-1。

    表4-1 需求矩阵

    产品范围的分解问题解决了，小M将计划

    的“计划”整理了出来，如图4-2所示。4.2.2 形成活动清单

    (1)活动分解

    理论上说WBS定义了交付什么，活动清单描

    述了怎么交付的工作步骤。但实际上WBS中的一

    些内容好像本身就是一项活动。比如客户培训，到底这是“范围”还是“活动”呢？其实，WBS中的

    交付成果包括产品和服务两类，软硬件是可见产

    品，“客户培训”是服务，是不可见的产品。

    图4-2 计划过程

    可以看见的产品验收比较方便，不可见的服

    务要特别注意文档，否则最后怎么证明做过了呢？所以，要保留培训记录、培训考试等资料，无形的交付更要通过有形的“文档”作证明。

    澄清了任务的分类问题之后，各组分头进行

    活动分解和工期估算。

    1)开发组分解的结果：

    ■需求分析工作开始之前，首先要对客户进

    行产品培训，1周可以完成；然后逐个功能比较

    客户需求与产品的差异，这个过程大约需要2

    周；最后需要1周时间整理需求报告并完成评

    审。

    ■外部接口调研和分析整理3周就可以完成，版本自动升级系统功能定义1周可以完成，这两

    项工作与应用系统开发没有关系。

    ■系统设计可以按照子系统分头进行，包括

    确认时间3周可以完成，4周比较安全，关键要看

    设计的工程师能力。

    ■开发工作包括编码、单元测试，在资源有

    保障的情况下，需要4周时间完成。

    ■测试总共需要4～5周，包括集成测试1周、系统测试2周；验收测试如果顺利的话1周，如果

    不顺利需要再来1轮，则还要1周时间。2)转换组的反馈结果如下。

    ■数据移植：总共需要7周，包括映射关系分

    析2周，数据转换程序开发3周，数据补录2周。

    数据补录工作量较大，请客户的人员帮忙比较

    好。

    ■用户培训：手册编写可以在需求分析之后

    进行，4周搞定，培训需要2周；在系统切换前用

    户培训必须完成。

    ■系统管理员培训：手册编写在设计之后进

    行，需要2周，系统管理培训1周，在验收测试之

    前应该完成管理员培训，以便其有时间在上线前

    熟悉系统。

    ■系统切换：安装和配置软件系统需要1周，切换应该1天可以完成，但客户要求试运行至少1

    周，总共2周比较保险。

    3)系统组反馈信息如下。

    ■主机环境：确定配置参数1周可以完成；设

    备采购客户负责，一般需要4周时间；安装调试

    需要1周，在开发开始之前应该就位。

    ■网点环境：设备调查需要2周，制定配置标

    准需要1周，客户采购和改造至少6周。网点环境

    系统切换前准备就绪。因为只有一个系统工程师，这些工作不能重叠。

    4)管理方面。

    ■需要项目经理全程负责项目的管理工作，并负责项目的启动和收尾。

    ■项目启动已经过了2周，试运行之后的移交

    和收尾工作需要1周。

    ■质量经理应该全程参与，并负责过程规

    范、评审、测试、缺陷追踪和配置管理。

    5)业务小组的反馈如下。

    ■客户方面已经从各个业务部门专门抽调出

    来一批骨干，会在从需求分析到试运行结束的整

    个过程中全力配合项目组工作。

    根据这些信息，完成了活动清单的相应内

    容，见表4-2。

    (2)确定责任矩阵

    按照工期优先的原则，项目组分别估算了各

    个小组的投入资源。因为，很多工作的角色和分

    工不能替换，需要分别估计每类人员的资源需

    求。

    比如，需求分析、系统设计需要的是系统分析员，开发和实现需要软件工程师，测试不仅需

    要测试工程师，还需要质量经理来管理。

    根据任务的特性，确定每项任务需要的角

    色，以及他们承担的责任，主要参与者用P表

    示，S表示支持，R代表审核。

    根据这些信息，完成活动清单的相应内容，见表4-2。

    表4-2 活动清单(3)确定依赖关系

    活动清单的格式比原来口头描述清楚多了。

    从这样的清单中，寻找任务之间的依赖关系就方

    便许多。依赖关系分以下几种。

    ■逻辑约束：一件事必须在另外一件事之

    后。需求、设计、开发、测试必须顺序进行；系

    统切换前用户培训必须完成，这是明显的工作步

    骤的逻辑顺序，不能改变。

    ■资源约束：一种资源不能同时为两个活动

    所用。例如，因为只有一个系统工程师，确定主

    机参数、确定网点参数不能并行进行。资源约束

    在改变资源投入之后可以消除。

    ■条件约束：一定的隐含条件限制形成的约

    束。用户手册在差异分析之后进行，是为了避免

    手册内容和系统实际功能不一致，减少无用功。

    在验收测试之前完成管理员培训，是为了验证客

    户可以驾驭系统，有更长时间熟悉系统，如果不

    需要满足这些条件，就可以消除这种约束。

    根据这些信息，完成活动清单的相应内容，最终完成的活动情况见表4-2。

    (4)如何确定活动分解的级别表4-2的活动清单已经包含几十个节点了。为

    了清晰表达项目的所有活动，理论上可以继续细

    分活动，划分成不同层次。但是，应该分解到什

    么层次合适呢？哪些活动应该放在一个层次上管

    理呢？为了便于进行分析和控制。作为第一个层

    次的活动应该符合以下原则：

    ■产生了不同的交付物。例如，需求分析、系统设计都有明确的交付物，直接放在第一层；

    类似数据转换、用户培训等活动中间会产生不同

    的交付物，就需要将继续分解，否则没法控制中

    间状况。

    ■责任人发生了变化。系统环境类工作，中

    间责任人发生了变化，所以需要继续分解到下一

    层。系统安装、系统切换等活动尽管有多个操作

    步骤但责任人没有变化，所以可以不再继续分

    解。

    ■活动周期大于了检查周期。假如项目的检

    查周期是4周，测试活动的总周期大于了检查周

    期，就应该继续分解为集成测试、系统测试和验

    收测试三个活动。另外，这三个测试活动的责任

    人也不同，也符合继续分解的原则。

    这样，作为项目第一层需要管理的活动(应

    该画在第一层网络图中的活动)，在表4-2中用灰色背景标出。4.2.3 排序和网络图分析

    有了活动清单和依赖关系，接下来可以进行

    排序了。在排序之前，需要先了解网络图的基本

    原理和规则。

    (1)网络图简介

    网络图有两种，一种是用节点表示任务，用

    箭头表示依赖关系；另一种是箭头表示活动。小

    M使用了第一种，每项活动用一个节点表示，节

    点是一个“框”，其中记录了活动的名称、代码、工期，最早最迟开始时间，最早最迟结束时

    间，总时差，如图4-3所示。这些概念的具体含义

    见后面的介绍。

    图4-3 网络图的节点

    网络图通过箭头表示活动的先后关系和执行

    顺序，一项活动只有在指向它的所有活动完成之

    后才能开始。活动开始所依赖的事件，叫做该活

    动的前驱事件(predecessorevent)，活动的结束

    之后才能执行的事件，叫做该活动的后继事件(successorevent)。

    通过对网络图进行分析，可以得到项目与时

    间相关的一些重要信息：

    ■给定项目的预计开始时间，能够计算每项

    活动必须开始和完成的最早时间。

    ■给定项目的要求完工时间，能够计算出每

    项活动必须开始和完成的最迟时间。

    ■确定项目的关键路径，也就是最长活动路

    径。

    还有一些涉及网络图的重要概念，在使用之

    前需要弄清楚。

    最早开始时间(EarliestStarttime, ES)：指某

    项活动能够开始的最早时间，可以以项目预计开

    始时间为基础，根据所有前驱事件的活动工期进

    行计算获得。

    最早结束时间(EarliestFinishtime, EF)：指

    某项活动能够完成的最早时间，可以在这项活动

    的最早开始时间的基础上加上这项活动的工期估

    算出来。

    公式1：EF=ES+Duration(最早结束时间=最

    早开始时间+活动工期)规则1：某项活动的最早开始时间必须等于

    或者晚于所有直接指向这项活动的所有活动的最

    早结束时间中最晚的一个。

    最迟结束时间(LatestFinishtime, LF)：指为

    了使项目在要求完工的时间内完成，某项活动必

    须完成的最迟时间。最迟结束时间可以在项目要

    求的完成时间的基础上，根据各项后继事件的活

    动工期计算出来。

    最迟开始时间(LatestStarttime, LS)：是指

    为了使项目在要求完工的时间内完成，某项活动

    必须开始的最迟时间。最迟开始时间可以用这项

    活动的最迟结束时间减去工期计算得出。

    公式2：LS=LF-Duration(最迟开始时间=最

    迟结束时间-活动工期)。

    规则2：最迟结束时间必须等于或早于该活

    动直接指向的所有活动的最迟开始时间中最早的

    一个。

    (2)初步网络图

    确定了网络图包括的第一层活动之后，下一

    步 ......