最后期限——BOSS工程项目的管理(转)

http://www.billingchina.com/forum/Announce/announce.asp?BoardID=102&ID=77964&r=54648&p=4&q=1

写在前面的废话

管理这个东西，看起来好像很”高级“，其实“弱智”得很，适用面往往很窄，所采用的方法、经验甚至于理论，都常常只适用于特定的环境、文化和团队素质等等。越具体的管理经验，越是如此！所以，我这里要罗里罗嗦的预先做一些限制，以尽可能的为自己的”谬论“开脱，呵呵！见笑见笑！

——这里，顺便插一句：在遇到具体的管理方面的问题时，切不可相信或期望有那所谓的灵丹妙药。因为真正适用你的东西往往不具体，而具体的东西又往往并不适用。管理，是太受”人“本身这个因素的影响啦！俺这里所说的，权作为一种交流吧。。。。。废话少提，下面言归正传：

对所谓的“BOSS工程项目”，我们来做一个明确的定义。

这里要突出的，是“工程”这个词。这是个与“研发”相对的概念。其特定的限制，指得是已经完成BOSS系统软件的大部分设计、代码编写，已经有了一个至少是基础版本的BOSS软件系统；现在工程阶段，虽然也会做一些软件的开发工作（一般来说主要集中于做一些客户化定制，满足一些特殊的需求和业务限制等），但是主要的工作内容，还是在于客户协调、设备安装调测、数据倒换、系统测试、割接等等”实施性质“的工作。

离了这个基本前提，”BOSS项目“就变成了一个”软件开发项目“，而不是具有特定要求和含义的”工程“项目了。可以这么说：BOSS工程实施的操作步骤、方法等，往往大同小异，积累出来的经验，主要受客户环境、系统本身的特性等方面影响，在不同企业或项目之间具有较强的可通用性；而软件开发项目的操作步骤、方法等，与所操作企业本身的企业文化，员工技能水平，软件产品的定位等等，有着非常强的关联性，从而在不同的企业之间，甚至同一企业的不同项目之间，都很难具有实际操作上的通用性。

下面对”BOSS工程项目“做一个相对量化的界定：

1、实施得是与中移动BOSS系统（业务运营支撑系统）类似的国内电信运营支撑系统。

2、采用的基本工作模式，是运营商提出系统建设需求，集成商负责实施的方式。这其中集成商的负责实施，不包括从零开发一个完整的BOSS系统，而是已经有了一个成熟或至少核心的BOSS软件版本（这实际上是软件产品商，而不是集成商的职责）。这里说一下个人的观点：这种在一个成熟或基础核心版本上进行集成的系统建设模式，应该会是至少近几年内的趋势，甚至会成为以后运营商能够认同的成熟工作模式。一家之言，权当参考。

3、项目周期，指得是从集成商项目组进场，到整个项目结束的”售后“阶段。一般包括这几个典型的项目阶段：需求分析、客户化定制配置和开发、系统用户测试、系统割接、系统初验、系统终验。这里不包括项目的售前招投标，和后期的纯维护阶段。

与大部分影视节目的开头俗似，俺这里也要来一段：这里所讲述的故事，纯属个人通过对一些实际工作经验的总结，将其理解虚拟为故事表达出来的，其中如有任何情节与某个实际工程中的场景“貌似”，纯属巧合。


最后，这里罗列一下下文中将要适用的字体和图示（后面会随时补充完善）：

1、大标题、小标题，这太明显了，就不罗嗦了；

2、红色字体。建议不要违反或疏忽的东西，如果违反将会对项目产生致命的、或长远的伤害；

3、黄色字体。警告，不要范这样的愚蠢错误。

4、蓝色字体。重要提示和技巧，其中大号蓝色字体表示重要经验、感悟的总结。对于管理来说，其实感悟，尤其是自身对人性、管理技巧等方面的感悟非常有价值的，这才是管理的真正积累。

〇、引子

孙乙， S 公司的一名工程师，曾经写过2年左右的代码，也曾经在BOSS系统的某个模块担当过1年多的负责人，有一些技术业务方面的积累。因为表现一贯比较“骚包”，喜欢总结团队方面的工作经验，尤其在安排多人的工作任务和协调同事之间的关系上，喜欢一群人而不仅仅是自己一个人把事情做好的感觉，也喜欢和别人讨论各方面的工作问题，为此而得到了某些领导的“赏识”。

为了考验孙乙，某领导曾经让这位仁兄先尝试负责过一些小项目，经过“三关六难”的考验，孙乙同志已经逐步形成了自己相对以往项目经理而言更为“精细”的管理风格——这应该是技术人员转向管理岗位的优势吧！领导们也认为孙乙同志已经具备一名项目经理的基本素质，可以考虑给予其更多的机会，让他开始尝试完整的BOSS工程实施。

刚好，S 公司近期完成了一个BOSS软件版本的研发，该软件系统在结合S 公司多年所积累的BOSS建设经验基础上，做了一些整合、调整和发展，尤其是在架构、系统性能等方面，做了一些设计上的优化；更采纳和考虑了eTOM最新理论，融合了很多国际化的先进理念。。。。（这里省略1000字）。采用这种“核心版本”＋“客户化定制”的模式，也是 S 公司希望将来成为固定工作模式的方式，经过和客户和业界人士各方面的多次接触和沟通，再加上吸取近期炒得比较火得竞争对手A公司得所谓“统一版本”泡泡经验， S 公司的领导认为这种方式值得尝试一下。从而系统不久的将来，也就是在1、2年之后吧，彻底的改变本公司的工作模式。

因为这种方式一旦成功，S 公司的管理层认为本公司就在BOSS软件的产品化方面打下了一个基础，而软件产品化是一个必然的趋势。为此，对于这个新研发的BOSS软件，S 公司将其命名为“XXP-BOSS”。因为领导们的意思，是希望这个产品，将会为客户带来“终极终极的体验”。 并且，该产品的版本号，从2.0开始。也就是目前研发的版本，是XXP-BOSS 2.0。因为，领导们又听说，一个软件，往往是1.0版本还凑合，2.0版本就特别烂，到3.0才稳定，为了打破这个狗屁理论，也为了避那个忌讳，就决定直接从2.0版本开始了！


到目前为止，应该说，XXP-BOSS 1.0——哦，不！XXP-BOSS 2.0 经完成了核心版本的研发，已经在严格按照经过深思熟虑、各位首席架构师和业务专家们历经百多个日日夜夜的争吵、而得出来的完美架构要求上，开发出来了！

经过各专家组的多方评测、研究、分析和在一个基本运行模拟环境下的测试（虽然 S 公司没有多少钱，无法搭建一个500万用户量行环境，但搭建一个500用户量的环境还是非常有把握的），各方面感觉，基本已经达到了预定的设计目标。现在所苦的，就是没有真实的运营环境对这个XXP-BOSS 2.0 进行实际运营的生产测试了。

此时，非常幸运的，在销售部门的积极配合下，更主要是在集团公司的一声令下的基础上，某省运营商 T 公司，已经和 S 公司签订了建设新系统的合同， 打算让 S 公司一展自己 XXP-BOSS 2.0 的风采。

考虑到以往的很多 BOSS 工程实施中，项目控制的过于粗放，从而导致项目出现很多进度、质量、成本方面的问题，而孙乙同志经过这2年领导的刻意锻炼，已经形成了鲜明的“精细”风格，为此，领导们经过讨论，觉得可以让孙乙在这个项目中一展身手啦！

考虑到 T 省公司给予的这次 BOSS 工程项目非常关键，它不但是首次验证 XPP-BOSS 2.0 的成功， 而且还将成为后续客户的推广依据。为此， S 公司的高层对此也非常非常的重视，打算严格按照新近认证通过的 CMM 要求，来实施项目的管理。

首先，S 公司的领导小组经过讨论，首先任命技术副总 李丁 来作为项目总监，对整个项目进行负责，并正式任命 孙乙 作为项目经理，这已经通过书面材料的方式，下达给李丁和孙乙两位。

然后，在孙乙同志收到通知后激动得还没有醒过神的第二天，李丁找来了孙乙，与其进行了一次沟通。一方面对其以往的工作给予了肯定，一方面传达了公司高层对该项目的期望，和要求孙乙同志必须实现的明确目标，最后还好好鼓励了一下。。。。。（这里省略2000字）最后还带孙乙同志一起喝了不下8瓶左右的二锅头。孙乙同志怀着激越的心情，和一种原本不太把握得住但喝过酒后就腿脚又特别有力量的感觉，很牛比的打了一辆大奔，回到了自己的蜗居。

孙乙同志在入睡前，心里头还一直乱哄哄的在想象着明天该如何召开项目启动会，找哪些伙计来参加这个项目等等。。。。。。

一、项目启动

（一） 公司内部的项目启动

项目总监和项目经理确定后，现在就要正式启动项目了。让项目尽早的进入正轨，是每个正常项目都希望的。于是，第三天一大早上班，孙乙就再次找到了李丁，就项目启动相关事宜进行了一个简单的讨论。两人都一致认同当天下午13：30召开项目启动会议，并初步确定了需要参加项目启动会的人员名单。具体包括的人员大致有如下范围：

1、技术负责人。由于公司高层在制定项目经理的同时，也基本确定了本项目的技术负责人，那就是一名叫 牛技的技术大拿。牛技其实也是在XPP-BOSS2.0产品研发的架构设计师之一，而且具备8年以上的BOSS技术经验。所以牛技的参加是必不可少的。

2、七大模块负责人。由于项目规模比较大，需要分多个模块来负责。于是两人又按照XPP-BOSS2.0的模块划分，和公司以往同类项目的惯例，共确定了 七个模块的负责人。这些模块负责人一方面是本模块的技术专家，另一方面将作为“子项目经理”，协助项目经理进行本小组成员的管理工作。由于项目组到高峰时期，人数将超过50人以上，所以这是非常有必要的。这七个模块技术兼管理负责人，也必须参加项目启动会的。

3、项目7大模块所涉及技术部门的经理。由于公司采用矩阵式管理，由于今后项目组将陆续加入的更多工程师来自于这些部门，为了今后能够“名正言顺”的和这些部门经理协调人力资源，这些部门的经理（在PMBOK中，这被称为直线经理）必须参加。

4、公司相应领域的专家。这些专家，将不一定会作为项目组的正式成员，但由于他们曾经在本项目所涉及领域的丰富经验，将会为本项目的开展提供必要的帮助。包括一些技术、商务、管理等方面的建议，以及参加后期项目开展过程中的一些技术评审等。所以，能够请到他们参加，也会对项目有所帮助。

5、项目的售前代表。由于项目所涉及领域，是公司目前的主营业务，大家都比较熟悉，就不进行单独的售前售后交接了，通过项目启动会一并进行。

6、公司采购、工程管理等非技术部门的代表。不可小看了这些部门，他们的工作，虽然对像类似BOSS这一类的项目没有突出的贡献，但他们具备“合法伤害权”，所以能够让他们参加，对于大型项目能够让他们的经理直接参加，并让公司高层直接告诉他们需要给予本项目什么样的优先处理等级，将会非常重要。看过《潜规则:中国历史中的真实游戏 》的同志将非常认同这一点。

7、最后。当然，不能少的，就是代表公司高层意志的相应领导。除了项目总监李丁同志必须参加，并作为项目启动会的正式发起人外，对于BOSS这种重大项目，至少还应该让1名以上公司的实权高层人物参加。公司高层对于项目启动会的成功召开，起到至关重要的作用。

在确定人员名单后，孙乙还考虑了一下会议方式和地点。地点就定在公司12楼大会议室（公司最好会议室，体现项目重要性）；而会议方式，由于销售代表、技术负责人牛技、个把领域专家都在外地，考虑开一个电话会议。

孙乙发完会议通知后，忽然发现自己遗漏了一个重要角色：根据公司CMM 过程的要求，需要QA全程跟踪本项目。于是，孙乙又来到李丁办公室。李丁嘿嘿一笑：还算自觉嘛，我已经安排啦！否则我哪有那么多空闲，天天盯着你啊？

接下来，要确定的是会议议程和会议目标。

对于项目启动会议来说，一定要达到相应的工作目标，切不可成为“过堂会”，否则浪费时间不说，还会因为没有“真正召开”项目启动会而导致后续的很多项目协调工作上存在许多障碍。这是很可悲的！

结合本项目的实际情况，已经考虑孙乙是第一次从事这类项目的项目经理，李丁和孙乙一起，为项目启动会制定了如下目标：

1、介绍项目售前背景，明确项目目标和范围。

2、明确公司对于项目的要求，该项目对于公司运营的意义。

3、正式授权项目经理。

4、明确提出各技术部门、非技术部门对于本项目的响应级别和要求，并要求各部门经理给出承诺。

5、正式成立项目组，并当场确定项目组第一批进入成员名单，和得到各成员对进入项目工作的认可。

为了确保会议目标的顺利实现，孙乙拟定了如下的会议议程，并和李丁讨论确认通过：

0、会议主持人为李丁，整个会议自始至终由李丁负责引导。

1、李丁启动会议，做简单说明，并请公司领导讲话。李丁经过和相关领导联系，确定让另外一名公司实力外副总王富来负责。主要内容是介绍大致的项目背景，公司对项目的要求，以及明确项目总监（李丁）、项目经理（孙乙）、技术负责人（牛技）的任命和职责等。限时30分钟。

2、让销售代表做一次口头的售前售后交接。主要将项目的销售情况，客户期望，售前的相关方案和承诺等，做一次说明。并明确说明本项目在售前阶段和客户共同确定的粗略目标和规划。这个议程，可以允许大家发问，并进行相关讨论，尽可能避免含混不清之处，但需要控制讨论发散到后续的项目实施中问题上去。限时1小时。

3、李丁正式向所有人员传达正式任命孙乙为项目经理，并就任命孙乙的情况做一简要说明，表明公司高层是经过慎重考虑和选择的，并表态公司将强力支持孙乙的工作。然后，重要的是，李丁要引导孙乙开始工作：让他介绍对项目的理解，以及对项目工作安排的大致说明，和可能需要各技术部门、非技术部门提供的配合要求等进行说明。限时10分钟。

4、孙乙开始工作，对项目可能需要各部门配合的情况和主要风险等进行简要介绍。在这里，孙乙认识到自己需要注意自己的方式方法：不能操之过急，也不能过于软弱，要尽可能客观和留有余地的阐明项目对资源的需求，和做一些必要的说明，要表现得自己考虑得的确比较全面而重点突出。

为了达到这个目的，孙乙实际上在一知道自己要承担这个项目开始，就要做相应得准备工作，甚至包括向前面提到得领域专家进行一些咨询，不能显得没有太多准备和考虑。否则会大大降低启动会的工作效果。

5、项目经理就重点资源配合问题和各部门经理进行原则性确认。对于BOSS项目来说，尤其是工程师的人力资源问题，需要在李丁的主持下，让孙乙和各部门经理做一个初步讨论，在李丁的协调下，能够让孙乙和各技术部门、非技术部门经理得到原则上的认可即可，无须过分细节的确定。

尤其需要注意的是：项目组马上需要进入的人员，主要是各模块负责人，以及其它的特殊技能人员、核心工程师等，也需要孙乙立即宣布，并同各技术部门经理当场敲定下来。

关于非技术部门的确认，特别的，由于往往这些部门管理上相对独立，可能需要王富参与协调，明确公司对他们的要求，从而尽可能消除今后发生协调冲突的隐患。

本议程和上一议程可以混合进行，限时1~1.5小时。

6、就项目的主要风险进行技术性讨论。这需要公司高层、销售代表、项目技术负责人、各模块负责人、项目外领域专家等一起参与讨论，让大家就自己认为的项目最重要的风险进行讨论。这一方面，可以让大家对项目的难度有更感性的认识；另一方面，让孙乙在接下来的项目计划过程中，充分考虑这些因素。

这个地方，就是牛技发挥其大拿位置的场合了，他作为技术负责人，需要拿出自己的观点和建议，并力主引导大家朝一致的方向努力。

这里需要提示的是：不要过多的陷入细节讨论，也不要就谁是谁非进行争论，孙乙要做到的是将所有人的不同观点都记录下来，作为自己考虑的素材。在讨论过程中，孙乙也要向大家传达这一原则，不要让会议变得过分冗长。

该议程限时1～1.5小时。

7、最后，领导总结性发言，再次明确公司的希望、态度、要求，等等。

从会议的议程可以看出，项目启动会议的内容非常丰富，时间要非常好的控制。所以需要孙乙做不少的准备工作。

在考虑清楚这些后，孙乙向相应人员发布了会议通知，并通过公司相应管理部门开通了下午1:30~5:30的电话会议，和预约了会议室的使用时间。

办完了这些，孙乙总算松了口气。嗨，还真不轻松啊！不经意的，孙乙忽然想：怎么感觉，所谓的项目启动会议，好像就是自己导演的一场戏啊？啊！这就是明悟啊！所谓的悟啊！想到这儿，孙乙有些激动：

项目经理的一个角色，就是担当导演，安排合适的舞台和布景，让合适的演员来演合适的角色。

下午 6:30，虽然努力控制了进程，但会议还是多开了半个小时。孙乙和大家一起走出会议室时，已经有些晕乎乎的了。

回到坐位上，孙乙将会议的主要内容整理了一下，并将结果进行了记录，然后创建了一个项目组的邮件列表，将会议纪要按照公司文档模板的要求email发给了所有会议参与人。

这个会议纪要整整写了孙乙将近1个小时，写完后，孙乙眼都花了，才想起要去吃饭。在吃饭时，孙乙忽然想到：除了这个会议纪要，还有项目章程、项目范围说明书等等公司CMM过程要求的文档等要编写，实在非非常琐碎。自己这么干下去可不行，非累死不可，该找个秘书或者说助理来帮助自己。顺便，这个助理还可以帮助自己安排很多后勤方面的工作。于是打定了主意，准备明天找李老板（现在李丁被孙乙称为老板了）要一个来。呵呵！可不可能是那个漂亮的周MM呢？

吃完饭，孙乙想想后面的工作，发现接下来最重要的，就是尽快将项目组开到现场开始工作。这种工程实施的项目，呆在家里是没法工作的。

次日一上班，孙乙就决定立即召开项目组工作会议，对到现场进行工作的安排讨论一下。另外，孙乙还想到，需要对昨天项目启动会中设计到的客户期望、公司管理层要求、项目工作范围说明书（SOW）进行一个初步的沟通，以便在到现场后，大家可以有一个一致的基本认识。

于是，在经过约30分钟的考虑，孙乙在基本确定了一个出发到现场的初步安排后，就召集牛技、各模块负责人、核心程序员等项目组全体（到目前为止）人员——也不过10人左右，并邀请了项目总监李丁，在一个小会议室共同召开了一次项目工作会议。

在会议期间，孙乙首先再阐明了一下客户和公司管理层对项目整体进度、范围、和质量等方面的要求。

关于进度，由于是个死要求，而且也随着项目范围的变化有着很大的弹性空间，大家目前都还没有太多的看法。

而在讨论到项目范围和质量方面时，孙乙拿着售前的胶片、技术方案建议书等投影到墙面上和大家讨论时发现两个重要问题：

1、有些方面有些模糊空洞，需要和客户做更加具体的讨论确认；

2、还有些方面可能要考虑对现在刚研发完成的XXP-BOSS2.0核心版本的技术实现做一些工作量相对较大的调整。如果真的这么调整的化，可能会对项目进度、质量目标产生较大的影响。

讨论到这儿，各位模块负责人普遍感觉，需要尽快到客户现场，和他们相应的业务模块负责人进行沟通讨论，将具体的要求细节、期望解决的业务问题（而不是现在技术建议书中的实现方式）搞清楚，否则后面的工作无法安排。

在讨论工作范围时，牛技提出了一个问题，引起大家的激烈争论。牛技认为：在本公司以往的BOSS系统中，对于内存技术的使用不足，导致了一些实时性、并发压力非常大的客户资料、费用信息查询性能没有很好的满足客户需求，为此客户一直都有些不满。所以希望在本项目中，由他本人来牵头负责，引入相对完整的内存数据库技术并进行相应的开发测试，将这些关键数据的查询，移到内存中进行。

但孙乙觉得，考虑到项目已经存在的很多工程实施方面的挑战和风险，在本项目中引入这一重大技术变化可能时间、费用、人力等资源不足，为此建议不要采用。

于是各位技术专家们进行了一场热烈的讨论。孙乙在讨论过程中，为了不让讨论无休止进行下去，果断的采用了一个策略，最后取得了大家的一致认同。该策略就是：求同存异。所有人一致认同的观点是：在确保时间进度，以及将来可获得的人力资源限制条件下，和在到现场和客户确认解决掉前面的2个重大项目范围问题的基础上，对采用内存数据库技术做一次相对详尽的分析，看看到底有多大的影响，如果该影响可以被接受，就采用内存数据库技术，否则暂时不考虑。但有一点是必须保证的：对于相应查询模块，要改造其接口设计，使得将来从数据库查询切换到内存数据库查询时，能够做平滑、无缝切换，从而确保即使将来在系统维护阶段，通过软件升级的方式来替换为内存数据库时，能够最大的降低在线系统进行软件升级更新的风险——也就是要实现所谓的“拔插件”效果。

由于这个讨论，这次会议花了将近3个小时才开完。这让孙乙充分体会到：求同存异，及时作出决断，对于项目来说是非常重要的。

在完成了项目整体进度、范围、和质量等方面要求的讨论后，进入了关于出发到现场的安排。正如孙乙预先设想到的，各模块负责人普遍认可到需要尽快到达现场，否则项目走到现在就很难高效的开展下去了。

由于有了前面的讨论，再加上各模块负责人本身也都是一些非常敬业的家伙，大家也都觉得本次项目非常具有挑战性，所以对接下来孙乙建议大家后天就出发到客户现场没有太大的异议。除了有个别家伙有些私事还需要料理下外，大家都基本没有问题。另外，讨论中大家还提到，由于后面项目组高峰期将发展到50人以上，以及这个项目成功后，T省运营商将会和公司成为长期合作伙伴，考虑在当前价格条件下的可怜的公司成本限制和一贯惯例，都住酒店吃不消，也需要这次到现场尽快将当地的办事处建立起来，包括租房、请保姆、聘请当地行政人员等等。

于是，会议结束后，孙乙统一给大家订了后天出发到客户现场的机票。

（二）和客户一起进行的项目启动：首次工程协调会

接下来，孙乙要做的，就是考虑关于带队到客户现场的相关事宜了。

首先，凭以往的经验，孙乙意识到要开一个项目启动性质的工程协调会。通过这个会议，让客户相应部门和责任人真正意识到项目开始了，需要配合做相应的工作了。其次，孙乙还觉得，为了让客户相应部门和责任人尽快进入状态，还需要给他们来段“热身”运动。为此，孙乙打算安排一个从项目组下飞机到达现场的宾馆开始的、一个严格的、维持一周左右的时间安排表。在这个时间安排表中，将安排一系列的工作，包括第一次工程协调会、售前技术方案的讨论、项目整体规划安排的讨论、自己和销售代表到客户各部门的拜访、各模块负责人和局方对口人员的沟通、以及接下来的到各部门的需求调研前期安排等等。

用了一天多的时间，通过自己不断的思考分析、以及和牛技、各模块负责人、李丁等的不断沟通讨论，孙乙总算拿出来一个相对完备的、长达10多页的详细时间安排表，以及相应的工作任务要求、项目组参加的人员、需要局方参加的人员，等等。

看着这份相对厚实的表格，孙乙满意的笑了。这下俺要开始折腾你们这些大佬啦！总不能老是让俺一个人这么忙吧？嘿嘿！

项目一开始，项目经理是最忙的，因为他要做很多的策划和启动工作。但要注意：项目经理就像一列火车的车头，必须尽快的将所有人发动起来，这对于减少项目资源的浪费非常关键！

考虑到和客户第一次开工程协调会，局方的高层领导会参加，孙乙就再次邀请了李丁、王富两位领导参加本次到客户现场的工程协调会。这两位领导在受到邀请后，也都很乐意的答应了下来，承诺到时候一定到场。其中王富还特意对李丁做了一下工作要求，认为即使自己不能到场，李丁也一定要到场（领导一般只会要求别人工作，呵呵！）。

做好这些准备后，李丁、王富、孙乙、牛技、七大模块负责人（以下与牛技合称八大罗汉）中的六位（有一人需要晚两天，处理点私事），就顺顺当当的来到了客户现场，并于当天入住了销售代表已经预先帮忙定好的（谈好协议价格的）的宾馆房间。在冲过热水澡后，孙乙、李丁和销售代表碰了下面，决定和局方约定第二天上午9点开项目启动会。

下面轮到局方人员出场啦！

局方中心主任赵丙，项目经理钱甲，已经预先通过和李丁、销售代表的联系知道了S 公司项目组到达现场的时间，以及孙乙提供的详细的工作任务时间表，也感到任务非常紧张。在收到电话后，立即和相应部门的领导、公司高层进行了充分的沟通，确定下来第二天到场的人员名单和大致的会议议程。

关于工程协调会议程，在孙乙、钱甲的建议下，李丁和赵丙（这两人已经算是老相识）沟通的结果是：

1、双方人员互相介绍认识；

2、T公司局方领导讲话，对各部门提出工作要求；

3、S公司领导（王富）讲话，应答本公司对项目的重视程度、资源调度安排等；

4、T公司赵丙作为实施负责部门，介绍目前的项目状况、安排和相应情况；

5、S公司李丁介绍S公司对项目的安排、人员情况等；

6、S公司项目经理孙乙介绍项目的初步计划，接下来一周内的详细工作安排；

7、T公司项目经理钱甲针对孙乙的计划、工作安排，介绍局方相应人员的工作安排；

8、问题讨论；

9、甲乙双方领导总结性发言；

会议时间：2.5～3小时，开始时间 9：00。

第二天的项目启动会，还算开得比较顺利。除了孙乙有些紧张，让局方感觉有些不老练外（后来的项目庆功会上，局方钱甲透露），基本感觉比较满意。公司领导王富也在最后时刻匆匆赶到，算是没有给大家带来太多的尴尬。由于准备充分，甲乙双方领导和责任人对接下来一周内的工作安排，除了有一些小的时间上、顺序上的变动外，基本感觉满意。同时局方也感觉项目组非常负责、积极，管理比较规范，准备的很充分，问题考虑的相当全面。这种认同感，为孙乙后续的工作开展起到了很好的铺垫作用。

在会议上，项目组的8大罗汉，结识了局方计费业务中心的4大金刚，分别找准了对口关系，也为后面大家结对交流打下了基础。

最后，在融洽的沟通气氛下，局方领导宣布项目启动结束，并给大家做了高标准、高质量、高速度的三高要求。局方各部门领导也都明确表态将全力支持这一关键性项目。赵丙还代表甲乙双方的项目组，表了决心。午餐时，王富作为S公司的领导，代表公司请所有与会人员吃饭。在饭局上，赵丙、钱甲、四大金刚以及孙乙、八大罗汉，大家同仇敌忾，意气奋发。从这一刻开始，甲乙双方的项目组，尤其是钱甲、孙乙分别带领的四大金刚和八大罗汉，算是捆绑成了利益共同体。

从项目一开始，取得局方对管理方式方法的认同感，以及将甲乙双方的项目组捆绑为利益共同体，对于项目后期的实施至关重要！

二、项目规划

项目规划对于一个项目，甚至可以说，无论多么扩大它的重要性都不为过。因为对于一个项目来说，存在着太多的不确定性。而项目规划的过程，就是将不确定性转化为尽可能的确定性的过程。

“项目”的三大特性之一——逐步明确的特点，注定项目规划不可能是一蹴而就的。为此，项目规划并不是仅仅在项目之初要进行，而需要在项目的整个进展过程中都不断的延续。事实上，项目规划应该可以说是项目经理的主要工作内容之一；一个好的项目经理，其项目规划的能力必然是好的。

再次提醒的是：项目第一次的规划，将会需要花去不少的时间，而此时切不可让项目组其它人员处于等待计划的状态之中，而应该让他们立即行动起来。对于BOSS工程这种实施性质的项目来说，就有很多工作可以提前做，无须要等待规划的。比如：系统建设方案的讨论沟通，网络建设的需求和步骤，软件需求的确认和差异分析，对客户进行新系统设计的培训等等。这些工作，往往立即就可以让项目组的老大们立即忙起来，而又不用太多的规划考虑。所以，前面项目启动阶段，孙乙同志的那个一周行动任务时间安排，是切合实际且非常必要的。

当然，能够预先就找到适当的任务，让项目组成员最快的进入状态，这和项目经理本身在领域内的业务、技术背景非常有关系。没有好的业务、技术背景，项目经理往往难以作出适当的决定。这应该说是为什么说“PM不能是纯粹管理人员”的原因之一吧！

一边忙忙碌碌的组织八大罗汉们和客户进行诸如需求确认、系统技术方案更技术细节层面的讨论、对客户进行新系统设计培训等等的工作，孙乙一边积极的进行项目规划相关的工作。

（一）范围定义与规划

项目规划的第一步、也是最基本的前提，就是对项目的范围进行界定（范围定义），以及对以后在项目中如何管理和控制这个项目范围制定游戏规则（范围规划）。

孙乙意识到了这一点。严格来说，这个项目的范围从售前技术方案建议书开始，就已经在开始定义了。孙乙从售前队伍那里接收过来，技术方案建议书中应该已经对项目范围做了基本的界定（对于有些项目来说，甚至已经界定到了非常详细的程度），但往往还不够细致和准确。

一切管理的真正目的，都不是从一些文档生成另一些文档这么简单。孙乙觉得，应该将项目的范围用一些简单的条款罗列出来，甚至用生动的语言描述出来，这样大家才能记住，包括客户和项目组本身。而只有真正记住项目的工作范围，才能让每个人更好的控制自己不要走偏，不要过于盲目的浪费项目资源。注意，这里用的是“不要过于盲目”。意思是说：任何项目，资源的盲目浪费，从某个角度来说是无可100％的避免的。管理的作用，就是尽可能的降低那些消极的趋势，但并不能做到真正彻底的消灭。

为此，孙乙首先在整合这几方面信息（技术方案建议书、商务合同、和客户初步沟通的情况、公司领导的期望、和项目组八大罗汉的讨论）的基础上，用一个简单的ppt胶片将项目范围罗列了一下，并根据自己的判断，对这些项目范围所涉及的工作内容进行了一个大致的优先级别排序。

然后，孙乙找到钱甲，两人针对这个项目范围进行了一次沟通。从沟通的情况来看，钱甲和孙乙发生了一些分歧。但大家本着务实的原则，坦诚的交换了各自的意见。虽然没有对具体的条款、以及他们的优先级别得到完全一致的认同，但至少对系统割接上前的工作内容还是有80％以上的一致的（实际上，包括割接后、初验终验前，只占到整个项目工作量的一半左右）。而对一些有争议的内容，钱甲、孙乙双方又达成了一个一致的做法：1、各自向自己的领导汇报后再沟通一次；2、目前先重点关注割接上前的工作内容，对于之后的内容，找合适的时机再沟通。

从这里可以看出：售前合同的内容签订的过于粗糙，甚至有过于其实的情况出现，导致后续的工程实施过程中很多东西都处于一种模糊的、非常容易发生争执的状况。就目前国内的市场环境、甲乙双方的管理水平来看，还难以短期内改变这种现实！这种情况下，本着务实的态度，甲乙双方应该在售后多做开放、互助互谅式的沟通。只要是朝着为了把事情本身做成功的目标出发，都不应该有任何成见！

和钱甲沟通后，孙乙回来又进行了项目范围定义的相关确认和考虑，包括找李丁沟通确认，对某些重点工作找相应技术人员讨论，找销售代表和售前技术支持人员了解售前承诺等等，结合钱甲的意见，孙乙做了一些调整。尤其是个别重点任务的具体工作内容、优先级别等。

当日下午，钱甲也找到了他的领导：赵丙。就相关问题进行了汇报、沟通。当天晚上，孙乙邀请到钱甲，对项目范围的定义再次做了沟通。

从第二次沟通的情况来看，大家对割接前的工作范围都已经基本没有太大的异议。当然，孙乙、钱甲双方也都做了一些适当的让步或变通。最后，两人盯着自己经过将近一天的辛苦工作，得出的一张简单的ppt胶片，有些苦涩而满意的笑了！包括前台业务的181个功能必须支持；割接时必须100％支持在网客户资料和费用数据的转换；必须支持规范要求的15大性能指标，等等，总共有5条，两人给其取了个好记的名字——五大纲要。

不仅如此，两人都深感，有必要为了尽可能提高以后范围可能发生调整时的沟通效率而制定游戏规则。由于有了前面沟通氛围的惯性，双方就这个问题没有争论太长时间，很快就确定了下来。包括双方的范围变更只能通过钱甲、孙乙两位沟通确定，其它人无权擅自决定；割接前2周停止非参数配置性质的需求变更，割接前半周停止一切新需求；等3条。两人对这个也给了个名字——三大纪律。

有了这三大纪律、五大纲要，钱甲、孙乙二位总算松了口气，在晚上23点左右总算各自打道回府休息。

次日，孙乙拿着这个五大纲要、三大纪律的ppt胶片，给项目组开了个会，也算是一次简单的沟通和培训。让大家都基本清楚了项目的实际工作范围（至少是割接前这段时间内，后面的还需要再沟通协商）和控制规则。

另外，孙乙也开始了编写《项目背景培训》胶片，该材料是作为后面进入项目组的员工进行基础培训的内容之一。这样，孙乙就顺势将五大纲要、三大纪律，扩充到这个胶片中去了。

在项目开始后，立即要做的一个非常关键的事情就是：将项目范围、任务优先级、变更范围的控制规则明确下来，和客户进行充分的沟通，得到双方的认同，并将这一成果在全项目组内不断的宣传、培训。这项投入将会为项目赢得出人意料的回报！！！

（二）进度计划和费用预算

接下来，孙乙知道，要立即着手开始制定详细的项目进度计划，这对于安排项目成员工作任务、后续人力资源调度等等，将是必须的前提。

制定进度计划的第一步，是制作工作分解结构。也就是将BOSS工程项目所涉及到的工作，从粗到细的识别出来，一直细化到可执行、可跟踪、可分配明确责任人和资源的程度。

根据以往的经验，结合自身对BOSS工程的认识，加上像诸位高人请教，孙乙认为从最粗的粒度来看，应该包括如下这四大方面的工作：

1、环境准备；

2、需求分析和确认；

3、软件客户化定制；

4、系统实施；

另外，项目规划本身也应该作为一项正式的工作内容管理起来，也应该在计划中考虑其所需要投入的资源、时间、费用等等。一方面，为了制定、评审出一个合情合理、综合多方利益的项目计划，以及后续的有效执行，必须将这个工作认真做好计划，并在项目进展过程中不断的重复执行这一任务；另一方面，要知道一个认真详尽的项目规划并不是项目经理一个人就可以搞定的，还需要项目组成员、客户、高层领导等多方面风险承担者（stakeholders）的参与，这些资源的消耗也会占去项目组不小的成本，为此也应该和必须科学有效的管理起来。

为此还需要增加第五类工作：

5、项目规划；

对于这5大项工作，孙乙的理解，认为包括如下这些内容和要求：

1、环境准备

对于BOSS工程现场项目组来说，一般主要包括这3方面的环境准备：

1）项目组办公、生活等方面的环境准备。

考虑到现场项目组成员的办公、生活环境，一般都是临时准备临时使用，项目结束后就要取消的，所以需要特别考虑这部分的工作安排。

这个办公场地，从信息安全、沟通效率、实施成本等多方面考虑，一般有甲方直接提供。于是，在经过和钱甲的协商后，钱甲承诺在1周内提供出来。而孙乙负责再用1周的时间，将接下来S公司马上要开到现场的近50人准备所有的网络、通讯等环境。另外，住宿、伙食等方面的事宜，孙乙认为这也是一个非常重要的工作（正所谓兵马未动，粮草先行）。于是，在将周MM立即调到现场让她这位经验老到的行政人员负责这项事务外，孙乙还为S公司将来在T省维护BOSS系统计，另外又在3天内招聘了一位家就住T省会的能干的吴MM来配合周MM的工作。

这下，孙乙想，周吴两位MM应该可以搞定了，自己就可以一门心思腾出来做业务上的事情。孙乙对周吴二人的要求是：2周内，搞定50人的生活、伙食等等方面的后勤事宜！而现在先头到达现场的10多人（孙乙、八大罗汉、李丁等领导）就住在宾馆，吃在外面饭店采用游击式了。

2）开发测试环境的准备。

无论是否采用产品化的软件，对于BOSS这一复杂系统来说，是不可能通过简单的“下一步”、“下一步”方式的安装配置，就能够立即投入生产系统使用的。它不可避免的会有一个复杂的安装、配置、客户化开发、测试、模拟运行等等复杂的过程。为此，必须为项目组搭建一个用于客户化定制所进行的参数配置、定制开发、确认测试等等工作而需要的软硬件环境——一般称为开发测试环境。这一开发测试环境，硬件方面不需要达到像生产环境那么高档的配置，但软件环境一定要做到尽可能得一致。比如：操作系统版本、数据库系统版本、开发语言等等。

经过和钱甲的讨论，认为可以利用T省公司原来的两台旧主机搭建开发测试环境。而至于本次XXP-BOSS2.0所使用的新系统软件，包括操作系统、数据库系统、中间件系统软件等，双方都通过商务渠道去找相应原厂商努力，让他们先提供评估版本（否则，等他们的正式发货到，黄花菜都凉了）。

由于这一个工作需要马上行动起来，在孙乙指定了项目组搭建开发测试环境的工程师，钱甲指定了相应局方配合工程师后，双方确定了2周内搭建完成这一环境的工作目标，并排定了详细的工作时间表。

3）生产环境的准备。

一般来说，BOSS工程主要的工作量，都是花费在客户化定制上。在客户化定制的同时，就完全有必要将生产环境的硬件、系统软件等安装配置好，以便于BOSS软件客户化定制完成后，能够立即着手将BOSS软件到生产环境安装、配置好，从而着手进行模拟生产环境运行的压力、联调测试等。

这一工作，应该在局方采购的主机、网络、系统软件等到货后，才能开始实施。

顺便提一下，孙乙记录项目计划的方式，是采用MS project 2000这个工具，在其中既包括记录WBS，也包括已经分配具体资源和时间的信息。

2、需求分析和确认

虽然说S公司的XXP-BOSS2.0 是个产品化的软件，已经实现了很多BOSS系统所需要的软件功能和特性，但这仍然是S公司研发团队在综合多个客户市场需求开发出来的最“核心”的版本，很多具体的功能仍然需要进一步客户化定制。

客户化定制的方式包括两种：参数配置和代码开发。孙乙知道，无论是哪一种，都属于自己项目组要做的工作，都必须调查清楚T省公司客户的具体需求细节，才有可能真正将系统实施上线。

为此，孙乙已经同牛技代表的八大罗汉确认成立以他们为主的需求调研小组，承担需求调研的工作任务。并在经过和T省公司项目经理钱甲的协商后，双方确定下来以项目的最初2周为需求调研的限期。这其中，当然，钱甲也已经和自己的领导——赵丙沟通过，并已经和T省公司市场部、各业务部门做过充分的沟通。

经过钱甲、孙乙、八大罗汉、四大金刚的共同讨论，大家认为：需求调研的结果，也就是需求规格书，应该按照七大模块来组织；而需求调研的步骤，应该按照局方的部门来安排，这些部门包括：计费中心、市场部、集团客户部、大众营销部、数据部、各市县公司人员（市场部、系统管理员、业务骨干等）等。而不同的部门，面对不同的人员，又需要安排不同内容的调研。为此，需要画出一个矩阵式表格，以八大系统模块为列，以所调研部门或对象为行，分别针对不同的部门或对象，设计不同的调研内容和问题，并注意安排调研部门的顺序和方式方法等。

在这个基础之上，孙乙、钱甲共同制定了为期2周的需求调研工作计划，其中包括到市场部、各业务部门进行走访的时间、人员等等。并且，针对需求调研的结果，提出了明确的成果物要求：《需求调研问卷及应答》、《需求规格书》、《需求项确认列表（含优先级、实现方式等）》等。

通过环境准备（办公生活环境、开发测试环境）、需求调研和确认这两项工作的情况再次可以看出：需要立即着手开展的工作任务，就需要立即确定下来的详细的工作计划。而不是或者没有计划就开始工作，或者等计划完全制定后才开始工作。项目经理采用不同的工作方式，越早、越积极的驱动项目组全体成员进入工作，对项目时间、成本等资源的浪费就越少。

2、需求分析和确认

虽然说S公司的XXP-BOSS2.0 是个产品化的软件，已经实现了很多BOSS系统所需要的软件功能和特性，但这仍然是S公司研发团队在综合多个客户市场需求开发出来的最“核心”的版本，很多具体的功能仍然需要进一步客户化定制。

客户化定制的方式包括两种：参数配置和代码开发。孙乙知道，无论是哪一种，都属于自己项目组要做的工作，都必须调查清楚T省公司客户的具体需求细节，才有可能真正将系统实施上线。

为此，孙乙已经同牛技代表的八大罗汉确认成立以他们为主的需求调研小组，承担需求调研的工作任务。并在经过和T省公司项目经理钱甲的协商后，双方确定下来以项目的最初2周为需求调研的限期。这其中，当然，钱甲也已经和自己的领导——赵丙沟通过，并已经和T省公司市场部、各业务部门做过充分的沟通。

经过钱甲、孙乙、八大罗汉、四大金刚的共同讨论，大家认为：需求调研的结果，也就是需求规格书，应该按照七大模块来组织；而需求调研的步骤，应该按照局方的部门来安排，这些部门包括：计费中心、市场部、集团客户部、大众营销部、数据部、各市县公司人员（市场部、系统管理员、业务骨干等）等。而不同的部门，面对不同的人员，又需要安排不同内容的调研。为此，需要画出一个矩阵式表格，以八大系统模块为列，以所调研部门或对象为行，分别针对不同的部门或对象，设计不同的调研内容和问题，并注意安排调研部门的顺序和方式方法等。

在这个基础之上，孙乙、钱甲共同制定了为期2周的需求调研工作计划，其中包括到市场部、各业务部门进行走访的时间、人员等等。并且，针对需求调研的结果，提出了明确的成果物要求：《需求调研问卷及应答》、《需求规格书》、《需求项确认列表（含优先级、实现方式等）》等。

通过环境准备（办公生活环境、开发测试环境）、需求调研和确认这两项工作的情况再次可以看出：需要立即着手开展的工作任务，就需要立即确定下来的详细的工作计划。而不是或者没有计划就开始工作，或者等计划完全制定后才开始工作。项目经理采用不同的工作方式，越早、越积极的驱动项目组全体成员进入工作，对项目时间、成本等资源的浪费就越少。

4、系统实施

我们知道，所谓的系统需求，一部分是通过软件来实现的，一部分是通过硬件方案（包括主机、网络、磁盘阵列等）的人工劳动来实施实现的。

所谓的系统实施，指得就是除需求调研、软件定制外的所有人工劳动过程和内容。一般包括：

1）应用软件系统在主机部署的设计和实施；

2）磁盘阵列划分的设计和实施（对于容灾工程，尤其内容多且重要）；

3）数据库方案的设计和实施；

4）其它合同范围内的集成方案设计和实施（如口令安全、系统备份、数据管理等）；

5）BOSS和外围接口方案的制定和实施；

6）BOSS应用软件的安装调测；

7）新旧系统客户资料、帐单数据等的转换；

8）生产环境下的系统压力、联调、模拟测试等；

9）最后一步：系统割接上线；

所有的这些工作，应该说才是BOSS“工程实施”类项目的重点工作内容，而且往往涉及到甲乙双方、多个厂商、多个工种人员的相互配合协调等等，所以非常复杂。

5、项目规划

对于BOSS工程来说，需要如下这些角色参加所有项目任务的计划过程（尤其是工作量时间等方面的估算、每个人可以投入的工作量和时间等等）：

1）项目经理；

2）项目整体技术负责人、各模块开发负责人、测试负责人；

3）开发人员代表；

4）测试人员代表；

5）主机、网络、DBA等参加工程实施人员；

6）公司能够提供资源的相关部门（直线）经理、财务人事等部门经理、高层领导等；

7）客户项目经理；

8）客户在主机、网络、数据库等方面的实施配合人员；

9）涉及到客户上述方面实施人员所在的部门负责人；

从这里可以看出，参与项目规划的人员，几乎涉及到项目相关的所有人员。这其实有两个简单的判断原则：

1）具体工作的工作量、时间等，最好由其具体执行人（如承担某个开发任务的程序员）或其代表参与讨论，而不应该简单的从上面“压”下去；

2）所有能够提供、控制资源的权力人（包括客户方），也要作为计划制定参与人考虑；

制定计划其实是一个自下而上、逐级汇总的过程。就是一方面，充分考虑具体执行责任人的估算（实际也是一种承诺），另一方面也结合项目总体的要求在上层进行控制和反馈。

经过上述的考虑，孙乙认为项目计划的第一个完整稿，必须在需求调研完成的2天内给出，并且大概总共需要消耗10～15人周左右的工作量，加上今后将不断的维护和细化该计划的内容，总得算起来，估计至少要占整个项目工作量的5%~10%左右。

孙乙觉得，除了需求调研和确认、办公环境准备、开发测试环境准备这些工作的计划必须立即确定下来外（其实，在那个一周时间表安排中，已经考虑了部分），其它工作计划的制定，还需要进一步和相应的人进行讨论沟通。

在基本已经考察完所有项目涉及工作的内容和结构后，孙乙汇总出来和一个初步的project WBS文档。拿着这份文档，孙乙开始开始进行了第一轮的活动定义、顺序安排、工作量估算、费用估算等工作。

首先，对于已经明确下来的需求调研和确认、办公生活环境准备、开发测试环境准备、项目规划这几个工作，由于这些是立即就要开展的工作，孙乙在项目范围（五大纲要、三大纪律）确定后的第二天，就制定了下来详细的内容（包括详细的任务名称、责任人、工作量人日、工期、先后次序等），并分发到相应人员的手中，并从第三天让所有相关人员都进入了工作状态。

其次，对于生产系统软硬件环境准备、客户化定制、系统实施等工作，孙乙先将其分解到目前能够分解到的、且仅仅是必要的细致程度，而对于活动的顺序、时间、成本等，根据自身和从其它大佬讨论得来得认识，先做了一个大致的估算。通过这个大致得估算，孙乙对项目的整体工期、成本预算、所需人力资源等，有了一个初步的认识，但还不能作为真正的计划内容。

按照孙乙的打算，是希望随着需求调研的完成，自己在每天参与的需求调研工作结束后，利用当天收集到的新信息，不断的同步希望自己的计划内容，知道2周后需求调研完成后的第二天，才真正完成第一轮的计划制定过程。

两周左右的需求调研工作非常辛苦。一方面，孙乙需要白天不断的跟踪、协调和组织八大罗汉在钱甲或四大金刚的带领下，到客户的各个部门去进行需求调研，而且这中间还由于局方相应部门工作时间的调整而不断的调整调研顺序；另一方面，孙乙和八大罗汉，以及钱甲、四大金刚，还要每天晚上将当天的调研结果总结出来，并对某些疑问作出应答。最令孙乙痛苦的，就是完成这些工作后，自己还要再坚持考虑及时的将工作计划方面的相应安排进行细化或调整。

两周的辛苦调研结束了（实际上，2周的需求调研是不够的，这里假设八大罗汉是超牛的人，他们对T省公司的需求基本已经有个了然；并且局方的配合也是无微不至的。后面孙乙就不再次安排单独的需求调研时间啦！虽然还会有些需求细节的反复，但应该不影响项目的计划安排了——改需求？大家加班搞定！实在搞不定的，就相应的调整工作计划吧？反正有详细的项目工作计划，每个任务的调整，到底产生什么样的影响，一下子就能看出来的。），孙乙委托牛技负责最后完成需求调研所需要的应答、规格书、需求实现方式和优先级列表等文档，而自己专心下来做项目规划的工作。

在牛技完成需求调研相应的工作成果后的2天，孙乙根据和牛技等八大罗汉的反复讨论，已经非常明确软件客户化定制的工作内容，甚至有些模块负责人已经非常清楚的知道某些需求具体该配置哪些参数、或者需要修改和增加哪些代码。

由于大家的拼命努力，才有了这个良好的基础，孙乙就制定出了几乎80%完整的工作分解结构（WBS），也就将80%以上的项目活动定义了出来，并对这些活动按照其本来的先后关系和优先级进行了顺序，然后让八大金刚为代表，为自己组兄弟们大致估算了每项开发、测试或实施任务所需要的工作量，自己部门可能参加的人选（当然，这期间经过N轮和其部门经理的交涉），以及这些人选能够投入的精力。考虑了种种的这些后，并经过N轮的反复调整，孙乙总算制定了一个第一版本的project计划。这个计划包括：WBS、工作量估算、资源安排（主要是人员安排）及其可投入时间百分比、工期估算等。

根据这个project文档，孙乙对每个资源赋予了其成本参数（当然，人员的加班工资基本是零的），作出了项目费用的人力成本估算，并在人力成本的基础上，考虑差旅、住宿、伙食、办公、活动等等费用后，给出了整个项目的预算。

最后，在带领项目组八大金刚来到现场后的第三周后，孙乙按照S公司的要求，提交了整个项目的计划和预算表格，在得到李丁和王富为代表的公司领导审批通过后，以及在现场办公生活、开发测试等环境顺利准备好的前提下，再加上接下来制定的人力资源计划，就开始调动大批的项目人员进驻现场，项目总算正式的如火如荼的开展了起来。

这里，要补充一个孙乙制定计划后的重要成果：里程碑计划。孙乙在制定项目进度计划的同时，也通过和局方钱甲的沟通，结合前面的工作分解结构，为了更好的控制项目进度，也为了方便汇报进展情况和不断得给项目组成员以信心，给出了如下几个项目里程碑：

1、生产环境硬件安装配置完成（要求设备到货后2周内）；

2、需求分析确认完成（要求项目启动后2周内）；

3、软件客户化定制完成（含功能确认测试，要求需求分析后8周内）；

4、生产环境软件安装配置完成（要求硬件安装后2周内）；

5、数据倒换脚本准备完成（要求项目启动后4周内）；

6、生产系统联调和关键性能指标压力测试通过（要求客户化定制后3周内）；

7、计费、出帐对比测试通过（要求客户化定制后2周内）；

8、系统割接上线（要求项目启动后12周内、或系统测试通过后1周内）；

虽然里程碑看起来比较多，但孙乙觉得有这个必要，因为这些里程碑能够清楚得反映出来BOSS工程建设的进展状况，而且里程碑控制得越细，就越容易及时发现问题和纠正偏差。

另外，从这个里程碑进度可以看出：设备到货时间，如果控制不当，将会影响整个项目的割接时间。关于这一点，孙乙已经和钱甲做过充分的沟通，钱甲也表示理解和支持这个观点。

到了这里，孙乙才真正找到了感觉，对项目的成功越来越充满成功的信心，对作为项目经理的辛苦工作也更加的充满了兴趣。

从这里的项目计划的制定过程可以看出：这里面充满了特定行业的业务、技术方面的知识和经验，同时也充满了对客户环境的理解和工作技巧等等。所以说：一个好的项目经理，并不是仅仅具备管理经验和技巧就可以的。也就是说，不仅仅通过一个PMP的认证就能够成为项目经理，还需要很多的行业特定的业务、技术背景，已经多年的实际项目管理经验。这里所说的，实际上只是项目管理所需要的“九牛一毛”。好的项目经理，至少需要经过5年甚至10年的实际项目经验的积累！

（三）人力资源规划

有了进度计划（包括WBS），实际就可以进行很多的、连带的相关项目规划工作了。这里，我不打算对所有需要规划的内容都罗嗦一遍，而只对我认为对BOSS工程比较重要几个方面进行介绍，包括：人力资源规划、风险规划、沟通规划。

要特别说明一下的是：随着项目规划的不断开展，往往会在做后续规划的过程中，发现前面的规划结果需要调整。尤其是在做风险规划时，更是如此。这对于一个项目来说，是非常正常的。实际上，不但如此，即使在项目规划完成后，项目实际开展过程中，项目规划的内容往往还是会发生调整。如果从项目规划的角度来看，甚至可以说项目经理80％以上的精力都是花在那个“计划”上面（当然，这优点夸张。实际上，应该说是为计划而进行的工作。包括后面在调整计划时，和各类人所进行的大量沟通协调工作）。所以，有人说：计划、计划、再计划。


对于前两项内容，一般比较简单。因为是由S公司的企业管理制度和惯例所决定的。也就是说：对于一个特定的企业，项目怎么做，往往都已经是确定的了。而项目中能够取舍的，往往就是根据项目实际需要而确定的特定角色和人员的有无。比如：是否需要DBA，是否需要网络工程师等等。

根据S公司的CMM 3级过程的管理制度要求，以及公司在BOSS工程项目方面的惯例，孙乙确定了如下的

1、项目角色和职责

1）管理类（各1人）：

项目经理（项目总负责）

项目助理（辅助项目经理工作，行政事务等）

QA（质量保证，监控者，领导的耳目）

配置管理员（负责配置管理）

2）技术管理类：

技术总监（1人，即技术总负责）

各模块开发组长（7个模块，负责各模块开发组的技术和管理）

测试组长（1人，负责测试组的技术和管理）

3）技术类：

系统分析师（2～3名，负责项目重大技术问题研究和决策）

开发工程师（按7个模块划分，若干名，负责相应模块的参数配置、定制开发）

测试工程师（按7个模块划分，若干名，负责相应模块的集成、压力、系统测试等）

DBA（1名，负责数据库管理系统的维护管理）

网络工程师（1名，负责网络方案的实施）

主机工程师（1名，负责主机设备的安装配置、环境搭建）

数据倒换工程师（2名，负责新老系统数据的转换，含脚本编写、测试和执行）

2、项目组织结构（即汇报关系）

1）项目经理对整个项目绩效负责，技术总监对项目技术方面的决策、问题负责。所有人均对项目经理负责，而技术总监对项目组所有人在技术方面的决策、问题均有权进行控制、把握和建议。技术总监的技术要求，通过提交项目经理后，在项目组得以计划和执行。

2）开发、测试组，人数众多，采用两级汇报机制。各工程师向其组长汇报（含技术、管理两方面）；各开发组长、测试组织在管理方面向项目经理汇报，而技术方面的问题、决策提交技术总监。

3）除开发、测试组采用两级汇报机制外，其它人员一律直接向项目经理汇报。

真正让孙乙头疼的，还是第三个东东——人员配备计划（或称人员调度计划）。大致说来，孙乙觉得当前的这个BOSS工程，人员的调度需要考虑这些因素和问题：

1）总的原则：任务驱动。当某项任务需要人进入时才进入，任务完成后即让其退出。但同时要考虑这些余量：进入项目的熟悉时间；新员工的学习时间；离开项目的交接时间。

2）管理类、技术管理类人员，必须在项目一开始就要进入。包括：项目经理、助理、QA、配置管理、技术总监、各开发模块组长、测试组长。其中测试组长可以稍晚进入，但也不能迟于2周以上。

3）开发、测试工程师根据实际的工作任务时间需要进度。

4）搭建开发测试环境的工程师，包括：主机、网络、DBA、测试组负责搭建环境人员，必须一开始就进入。

5）主机、网络、DBA等，在搭建环境后，如果设备没有及时到货，可以离开一段时间直到设备到货。

6）在协调开发、测试工程师时，需要至少提前一周、最好提前2周以上和相应部门的直线经理进行沟通，直线经理是不可能有空闲人员“随时候命”的。而各部门经理在到达人员到位时间至少3天前给出明确答复。

7）当人力资源调度与其它项目发生冲突时，当天就要和李丁反映，其当天也必须给出判断，是牺牲其它项目还是本项目利益。

8）各开发、测试组工程师的素质、数量，甚至具体人选，主要由各组长负责建议。项目经理根据实际协调情况做出抉择。必要时，需要明确人力不足时的补救方法。

9）其它直接向项目经理汇报的人员素质、数量、人选名单，由项目经理根据自己了解的部门情况提出申请。

10）人员配备计划，一开始规划的结果，在实际执行时肯定会有偏差。既包括到位时间等量化偏差，也包括人员能力水平、工作量、工作难度等方面的软性偏差。要实时跟踪实际工作状况，并在发生偏差时及时调整人员配备计划。

11）人员离开项目组的时间，由于是在客户现场的工程项目，需要及时和客户相应负责人沟通，要考虑至少1～2天的沟通余量时间。另外，还要考虑后续其它类似工程的人员需求，尽可能支持公司其它BOSS工程的人员需求。

对这些考虑因素，孙乙头皮发麻的发现，需要和这些人进行相应的沟通：

1）在需求明确的前提下，首先要和各开发、测试组长沟通，让他们在限定的总体进度时间要求下，通过WBS中列出的开发、测试任务，估算工作量人日，并依此给出自身模块人员的调度建议（含进入退出时间、各级别工程师数目要求、工作时间长度等）。

2）和技术总监牛技沟通，确认是否有一些特殊的技术要求，需要特殊技能的人员进入（比如：具有丰富内存数据库开发经验的人选）。

3）开发、测试、配置管理、项目助理、DBA、主机、网络等人选，都需要和各自的部门直线经理一一沟通，和他们通过“讨价还价”的方式，确定下来其部门涉及人员的调度计划。

4）对于某些部门经理来说，由于人手不足，可能还存在考虑人员招聘的问题。这样，又存在一个通过李丁去和HR部门沟通，给出人员招聘计划并实时跟踪其执行情况。

5）但人力资源调度不满足要求，或者是与其它项目冲突，或者是需要招聘人员，都需要通过李丁提交公司相应管理层决策。这里又存在一个和公司高层管理沟通的问题。

6）根据和各部门沟通的结果，人员配备不可能是计划的那么好，这样就可能导致项目进度计划，或任务优先级发生变化，此时又要回头和项目组内部相应人员（如组长、相应工作配合人员）、以及客户进行沟通。其中，与客户的沟通又是最需要花费精力的。甚至可能涉及到重大进度、范围计划的调整。

7）由于本BOSS工程后，还有后续的BOSS工程需要实施，这就需要和这些省份市场的相应经理进行沟通。

8）再考虑到本BOSS工程实施后，后续的日常维护工作需要交接，这就还需要和负责T省市场的经理进行沟通，以确定合适的后续维护人员交接计划。

人员配备计划让孙乙忙了个昏天黑地，差点累个半死——沟通的工作量实在太大了。在接下来不到一周的时间内，孙乙几乎每天的工作，就是不断的和别人讨价还价，打电话，讨论问题等等。而且，还要随时因为人员调度计划的明确、调整，而不断的调整孙乙那个可怜的project计划。

在project计划发生调整的过程中，孙乙最痛苦的，还包括要和相应开发、测试组长沟通进度计划的调整，或者是需要其减少人员需求，或者是需要其加快进度承诺，或者是让其接受进度延长。而这些都不是这些家伙愿意接受的。总的看来，这些组长们提出的人员需求，能够满足80％就是很美的啦！一般也就60～70％左右。在这中间，孙乙不知道费了多少口舌，和做了N多的信誓旦旦的承诺。

当然，在这期间，孙乙并不总是能找到人沟通人员配备问题。在这个间隙里面，孙乙还做了很多的沟通规划、风险规划的工作。

经过将近一周的拼命工作，孙乙总算将人员配备计划做了个七七八八，同时也对进度计划做了一遍调整。

在基本完成时，孙乙就调整后的进度计划和客户钱甲做了一轮沟通，钱甲又和T省公司的相应人员做了些沟通，最后发现了若干问题要求孙乙解决。于是孙乙同志又回来吭哧吭哧的忙活了大半天，总算尘埃基本落定。

最后，孙乙同志拿出了一个很伟大的excel表格——人员配备时间表。在该表格中，以时间为横坐标，给出了各部门、各类人员的计划数量、到位时间、退出时间等。并将这个表格发给了李丁，和给相应部门的直线经理。当然，主要是给他们啦！

当然，除了这个表格外，还有一个很重要的东西——人员培训计划。由于并不是每个进入项目组的员工都是熟练员工，于是孙乙只好自己根据各部门经理提供的人员名单，结合这些人的实际技能，自己制定了培训计划，并打算委托周MM负责实施这一培训计划——当然，培训导师的人选，是孙乙又一个沟通协调工作的结果啦。

除此之外，孙乙看到得是一个将近50人的人员规模，这里就还涉及到现场的办公、住宿等环境的安排，配合人员到位时间，他还对周、吴两位MM提出了更具体的各项行政后勤事务的时间要求。

最后，孙乙要提醒自己的是：别忘了：人员的培训、行政后勤工作的安排，也非常重要哦！这两个工作，将直接影响项目人员的工作效率和情绪。

（四）项目沟通规划

相对前面的几个规划，项目沟通的规划比较简单。主要就是要考虑到项目的各类利益关系者（stakeholder），让他们都能够获得自己需要的信息，并及时反映和沟通解决问题。

虽然这个规划工作不是很复杂，但非常重要，所以这里要特别提出以下。

对于BOSS工程项目来说，可能最重要的，就是要和局方明确在出现问题时，谁负责解决。否则，沟通规划等于没做。因为一些历史的原因，可以说中国的电信运营商内部有些部门之间的职责存在重复，听报告时大家都要出头，而出问题时往往又相互扯皮、难以一下子解决问题。

孙乙觉得，在汇报工作方面，能够对多一些部门、多一些人员汇报，就多汇报一点，一方面沟通联络感情，更重要的在于让相应部门和人员都能够及时了解问题。

而在问题解决责任方面，在钱甲、赵丙的努力下，基本已经明确下来，但仍然有些含混的地方。为此，孙乙打算在第二次工程协调会上通过公司领导王富向局方高层提出来，希望能够得到很好的解决。

这里，有个比较中国特色的东西：一般对于BOSS工程来说，需要有个工程协调会的计划安排。这种会议，虽然难以在桌面上解决重大问题，但对于一些容易解决、无伤大雅而在平时又难以引起重视的问题（比如前面提到的某些问题的解决责任人。当然，是否这样靠得是感觉。这种东东，这里说得也不一定对！唉。。。），倒是蛮有工作效率的。

在明确的汇报、沟通的部门、人员（包括局方、S公司内部两方面），制定了通讯录，并给出了沟通方式、频率后——当然，包括工程协调会的计划安排，孙乙完成了沟通规划。

（五）风险规划

对于一个项目的管理来说，最烦琐的应该各种各样的沟通工作，需要极大的耐心；而最困难的，应该就是风险的规划和控制了。

对具备某特定行业相当丰富知识或经验的项目经理来说，某些风险可能显而易见，凭直觉就能够一下子判断出来；而对于其他人来说，这可能又是非常困惑的。对孙乙来说同样有这个问题。他清楚的知道这个困难的存在，所以也告诫自己：要尽自己可能的去挖掘那些存在的风险，并尽所能的去积极的应对它们。

首先，孙乙打算先设置一个风险管理的游戏规则；然后，按照这些规则和方法，找到所有可能的风险，并按照接受的规则，确定下来要纳入管理的风险列表，以及相应的应对策略和工作安排等等。这样，风险规划就算有个基本结果了。

首先，是确定游戏规则。游戏规则的内容，包括：风险的来源，风险的量化指标，风险评估的方法，风险纳入管理的标准等等。对于风险的来源，孙乙罗列了如下几条：

1、风险检查表；

2、项目组八大罗汉的建议；

3、客户钱甲、四大金刚的建议；

4、李丁、赵丙的建议；

5、其它行业专家的建议；

同时，对于风险的含义，孙乙认为应该既包括消极的风险（就是发生后将会出现损失的风险）和消极的风险（就是发生后会给项目带来利益）。

对于风险的量化指标，孙乙简单的确定了两个：发生概率和影响程度。对于发生概率，按照百分比来表达。对于影响程度，按照5分制来表达，分数越高影响越大。然后，根据这两个的乘积，计算出风险系数并排序。

风险评估的方法，孙于确定在Delphi法的基础上，辅以外地的电话沟通，最后再通过正式的评审会议。

风险纳入管理的标准，按照风险系数的从大到小排序，孙乙将风险分为三大类：需应对风险，潜在需应对风险，暂不考虑风险。对于需要应对的风险，孙乙认为应该控制在3～5个（同时应对太多的风险，是不明智的做法，应该集中资源解决重点问题），潜在需应对风险不超过5～7个，而所有被识别出来的其它风险作为暂不考虑风险。

风险再识别的频率，固定为不超过2周，并在每个项目里程碑都重新识别。通过不断的重新识别和实时监控（比如，某个需应对风险关闭，则从潜在需应对风险中“提拔”一个出来），不断的实时调整上述三类风险的内容。

风险管理情况的汇报，通过项目周报的方式，与项目周报一同汇报。并在必要时和相关利害关系人沟通（因为有些时候，某个利害关系人是难以接受某个风险的发生的，或者难以接受为某个风险投入相约的资源，所以需要大量的沟通）。

根据这些规则和风险，孙乙通过“不懈”的努力，终于给出了三个风险管理表格（分别对应于需应对、潜在需应对、暂不考虑三类）。这三个表格，包括这么几列：编号、名称、发生概率、影响程度、风险系数。对于需应对风险，经过广泛的沟通讨论，孙乙确定下来应对的方式（规避、减轻、或接受等），和相应的应对责任人，时间限制等等。

对于需通过规避或减轻方式来应对的风险，孙乙发现，需要在项目计划project文档中，将这些应对的措施落实为具体的工作任务，并同其它诸如设备安装等任务一样，安排相应的资源、进度计划等，认真的管理起来，才能真正将风险控制落到实处。

同时，孙乙还发现：既然需应对的风险内容可能会定期发生变化，那么项目计划project文档中对应的这一部分工作内容就在实时的发生调整（增加或减少），不像其它工作任务，实际上一开始就是基本框定下来的。这也说明：考虑到风险管理，项目资源和预算是要做一定比例的预留的。也就是要给项目设置一个“风险预算”的比例或额度，而这部分预算，也应该纳入整个项目成本来考虑。这就好比做生意，在计算其可能收益时，必须将可能的风险率考虑在内。

发现了这一点，孙乙及时和李丁进行了相应的沟通。结果李丁告诉孙乙，实际上公司在设置项目管理制度时，是有风险预算规定的。根据两人讨论的结果，考虑本项目的实际难度，将本项目的风险预算设置在公司同类项目的偏高值――15％～25％左右。

（六）规划评审

经过2周左右的辛苦工作，在完成了所有的这些规划，并编写了相应的文档之后，孙乙基本完成了项目规划的内容了（实际上，还有一些其它的内容，限于篇幅，再考虑它们并不是本项目的重点，就不介绍了）。

孙乙知道，光凭自己和项目组，虽然已经做了相对非常细致的工作，项目规划仍然不是完整的。因为对于这么一个重要而复杂的项目来说，缺乏了技术性质的评审，以及甲乙双方管理层的认可，项目计划的执行会有很大难度。

为此，孙乙再次和李丁、钱甲、赵丙等沟通，为项目规划的内容安排了一次评审会。在这个会议上，孙乙邀请了钱甲、赵丙、甲乙双方的四大金刚/八大罗汉、甲乙双方的相关涉及部门领导、甲乙双方的高层代表郑贵、王富等。并邀请李丁来负责主持这个“计划评审会”（为了符合大家的习惯，还是叫计划评审会比较容易接受）。

在计划评审会期间，局方提了不少相对激烈而认真的问题，孙乙也都一一尽心应答或说明，并记录了一些重要的问题或争议。但是总体来说，郑贵、王富两位老总对于项目规划的工作还算基本满意。最后达成的结论是：在会议最终确定下来的争议或问题得到解决并得到赵丙、李丁二位的认可后，项目按计划开展。

三、项目执行与监控

（一）团队建设与激励

对于孙乙来说，当前最紧急也是最重要的工作就是赶快落实人员的到位，也就是前面所谓的人员配备计划的落实执行。

为了确保人员按照计划到位，并且到位人员的素质能够满足项目要求，孙乙积极的和各部门直线经理进行了相当大工作量的沟通。由于一方面，在孙乙制定人员配备计划之处，就将人员的配备计划交给各部门经理去预先考虑，并且也通过公司内部的相关正式的沟通会议让各部门经理正式确认了这些需求，再加上项目组已经进入的八大罗汉的共同努力（这些罗汉们也都来自各自的部门，他们和自己的部门经理沟通更加容易，而且也更加有说服力），基本上来说，人员起初的到位情况还是比较令人满意的。

但是，随着项目的逐步开展，孙乙发现，某些模块的人员到位出现问题。有的是原先计划到本项目的人员被领导抽调到其它项目，有的是原先计划的人手不足需要再补充，而有的是到位的人员不是原来计划的素质能力要求。

为此，孙乙和各方面人物（从部门经理、人力资源部门、到公司高层领导）进行了“艰苦卓绝”的斗争，采用各种各样的手段，包括“坑蒙拐骗”、“求爷爷告奶奶”、“恐吓”等等的办法，总之是“不择手段”的尽最大的努力和积极性去争取人力资源。最后，大部分的人员都“基本”得到了“大致”的满足，包括按时到位、招聘补充、延迟到位等等的方式。

对于某些实在无法按计划到位的人员，孙乙只好项目内部解决――通过和某些罗汉的讨论，将工作安排进行调整，或部分下降质量，或部分调整工作量，或通过进一步细化任务分解、调整任务顺序并更加细致的跟踪实际进展等。当然，同时也增加了管理成本。而孙乙只能认为自己每天多劳动几个小时反正也不值钱只能认了（唉，谁叫自己命苦，做项目经理）。

在这个过程中，孙乙感觉到：作为项目经理，在真正执行项目的过程中，为达到目的，几乎是采用一切可能的手段。需要将一切所有可能找到的方式方法，都转化为完成目标的资源。从这个角度来说，项目经理的思维习惯有点和销售类似。所以说：具备适当的销售心理和素质，对于项目经理来说，是非常必要的。

光有了团队还不行，孙乙还发现，随着项目的进展，项目组明显表现出一种“疲沓”的现象。这可不是好事情。很显然，项目组的整体工作效率，在项目启动之处的那段激情过后，已经在不断的下降！

另一方面，孙乙还发现，对于在项目中不断出现的需要合作的工作，越来越多的人之间不断的相互抱怨，而不是积极的沟通解决。

也就是说：孙乙必须要解决这两个问题――团队的积极性和凝聚力。

孙乙找了很多方法。诸如：

1）对各个小组，要求其组长在总体里程碑计划的基础上，分解出更小的里程碑计划，并尽可能的将各个里程碑落实到具体的1～2人身上，让他们明确自己“量化”、“小步骤”的工作目标，并采取更加严格的项目任务绩效考核和检查机制（这实际上又是在增加管理成本），来促使项目组所有人“更加清醒”的工作。

2）对于表现良好的员工，适当的给予可见的奖励――但这种奖励必须是能够兑现的，在公司制度范围内的；而对于表现有所欠缺的员工，适当的进行一些刺激――但这种不能是损害短期利益的（如薪水等），要是足够委婉而有鼓励作用的。

3）向领导李丁汇报，给大家一定的团队性鼓励，如申请公司制度外的旅游活动等。

4）根据公司工会的制度，充分利用它，由周武两位MM出马，组织大家进行体育活动等，并和局方的人员共同参加，以促进大家相互之间的感情，从而提高凝聚力。

5）孙乙自己和八大罗汉打成一片，经常和大家一起喝酒；而八大罗汉依次类推，也同意孙乙提出的建议，经常性在熬夜后请自己小组的兄弟消夜，或者周末喝酒打牌等。当然，也包括一次孙乙“无意识”的和某些正在聚会的“民间组织”偶遇，然后和大家海阔天空一把，顺便发表点自己对项目中某些任务成效的优劣判断，并引起伙计们一定程度的共鸣，进而影响他们后面的实际工作态度。

6）给项目组过生日的同事开生日party。孙乙发现：尤其是给美女或者项目组的活跃分子过生日，会引起更多的关注。

7）。。。。。多得很啦，要去想。。。。。。

关于团队建设的重要性，可以说是项目管理中最具备挑战性的责任，一个好的项目经理必然是一个好的团队建设者，否则只能空谈项目管理。建议有兴趣的兄弟，去看看那本真正的《最后期限》（Tom Demarco，UML China译）。它里面有个观点，非常值得借鉴：

优质管理的四大要素：

1、选择正确的人；

2、为他们分配正确的工作；

3、保持他们的积极性；

4、帮助团队凝聚起来并保持团队的积极性；

（其它一切都只是文案！！！）

（二）执行跟踪与对外沟通

一方面，作为项目经理，孙乙必须要对自己项目的”脉络“把握的非常清楚，清晰的知道项目范围内各方面的工作都进展到什么状况，有哪些问题，需要做哪些决策，等等。

另一方面，孙乙要每周写项目周报，将其发送给所有相关的利害相关者，并和他们做一定的沟通。为了更加准确的描述项目进展状况，以及准确的判断需要那方面的利害相关者提供什么样的帮助，来解决什么样的问题，孙乙也必须”真正的“把握自己项目的所有神经的跳动。

为此，孙乙知道自己必须建立一套工作机制，一套作为常规性”运营“手段的机制，来保证这两个目标的实现。

首先，为了准确的收集项目各模块的实际进展状况。孙乙为项目组建立了周五下午开项目例会的制度，要求所有模块组长（八大罗汉）和相关核心技术骨干参加。

在项目例会上，有一个简单的议程，就是先各个小组将自己本周的工作进展情况、问题、建议做一个汇报，然后孙乙提出一些重点讨论的问题或需要重点关注的工作说一下并给出一个初步结论，最终确定下来待解决问题列表全体确认完成。

在例会之后，孙乙会和各小组长具体沟通其小组详细工作任务的完成情况――以那个project计划为依据。当然，这个project进度计划，要能够详细到每个小组所有人每周的工作任务，并且有明确的成果物完成标准。沟通确认的目的，是为了搞清楚每个详细任务的实际完成状况，并根据实际完成情况做适当的调整――既可能是进度也可能是任务内容。这样，在调整后，就形成了下周每个小组的工作计划。

通过这种方式，孙乙和八大罗汉形成了一种常规的工作方式：

1）每周五睡觉前将本周工作”盘点“完；

2）孙乙汇总完成后，统筹考虑，对下周每个小组的工作给出具体的完成要求；

3）每周一上午一上班，孙乙将本周经过调整后的各小组任务完成要求发给各小组长确认，他们可以在周一下午下班前提出反馈，否则任务没有问题。

当然，孙乙和各小组沟通的文档，还是那个MS project文档。所以需要大家都熟悉使用MS Project的啦。还有一点值得提的，就是八大罗汉和孙乙所沟通确认的内容，孙乙也基本上都知道他们在做什么，按照他们的描述，各项任务实际上已经进展到什么真实的状态――虽然有时候孙乙对于具体的技术业务细节可能不是很懂，但他会不懈努力的去向罗汉们请教到底是什么东西。所以，对于项目的执行跟踪来说，项目经理具备相应领域的技术业务知识，是非常必要的。如果他真的不懂，也一定要通过学习弄懂！

其次，除了周五忙于例会和周报编制、周一忙于各组任务确认和对外沟通以外，孙乙给自己规定了每天必须考虑这么两个问题：

1、到今天这个状况，当前项目最重要的3个工作是什么？

2、今天，需要我通过协调来解决的最重要的3个问题是什么？比如，今天有某两个模块的接口歧义问题必须解决，否则将影响项目整体进度。

思考清楚了这两个问题，孙乙就要求自己必须当天将发现的3个最重要问题落实下来，并用一个简单的项目问题跟踪列表持续不断的跟踪直到它们彻底得到解决。

忙于这种性质的协调工作，每天至少消耗孙乙2～3小时以上。

最后，对于项目组内部经常发生的一些比较令人困惑的问题（一般来说，IT项目往往会遇到一些需要摸索的东西），如果不是非常具备技术性，相反基本上是仅仅考虑这个问题到底该通过什么样的组织、和确定什么样的工作标准才能执行好它，孙乙会适当的让自己”亲手“体验一下这种性质的工作。比如：由于某个软件组件要经常进行新版本发布，那么，是应该安排一个专职人员每天晚上单独针对所有引用这个组件的模块重新联编，以确认软件的接口没有被破坏？还是采用某种代码审查制度来确保？对于这种工作，孙乙一直认为自己应该亲身体验一下――当然，不是自己一个人搞定，而是临时找几个相关的工程师，大家一起来探索一下。

由于一般来说，这种性质的工作，难以一下子在项目之处都能够预见得到――技术上也是做不到的。所以，这种工作往往没有明确的责任小组，所以需要孙乙自己临时组织相应的人员进行研究。

通过这三种类型的执行跟踪手段，孙乙应该说已经相当准确的把握了整个项目的“脉络”。这种情况下，孙乙所写出来的项目周报，当然能够相当准确的反映实际状况，而且能够抓住重点，及时发现和解决问题，从而真正推动项目组高效的工作。

诚然，要做到这一点，还是要得益于孙乙具备相当丰富的领域技术和业务背景（这里是BOSS）。

在项目对外和各方面利害相关者的沟通方面，孙乙至少每1、2都会和钱甲做一次口头的沟通，至少每周向李丁、赵丙做一次基于周报的汇报沟通。当然，和甲乙双方的其它部门的相关领导沟通，也是不可或缺的，孙乙基本上是每1、2周找一个可能需要配合的部门做一次当面或电话方式的沟通。

（三）范围和质量控制

BOSS工程的范围控制，一向都是非常玄妙的。无论从前期的售前技术方案，到项目启动后各方面领导所大谈特谈的各种希望，还是乙方厂商为了赢得合同所做的各类夸大其词的承诺，等等的这些前提都使得售后的项目工程目标变得那么“虚无缥缈”，或者说“雾里看花”。

但从严格的项目管理与控制的角度来说，为了使得项目在合理的进度时间内、完成合理的工作内容、达到合理的目标，都必须进行适当的范围控制。否则项目的成功永远都只是一个梦想，而不会真的到来。

S公司和孙乙碰到的T省BOSS工程当然也不例外。

其实，无论甲方乙方，无论钱甲还是孙乙，无论赵丙还是李丁，甚至包括郑贵和王富，心里都非常清楚，很多所谓的项目目标都只是说说的，或者说充其量是一种拿出来”冠冕堂皇“的政治口号。而真正的目标，一般在大家的心里，或者说在手里――能够通过手来实现的那些目标。

哈哈，这就是大部分目前国内厂商所面临的BOSS市场环境，也是非常有中国特色的一种东西，而且乙方还不能表示太多的异议。孙乙虽然感觉很无奈，但对于项目能够实现目标――让领导满意，这才是项目真正的目标――还是有信心的。

当然，这里面包括一些适当的工作技巧，也需要在一个特别的方面付出特别的努力――沟通。

所谓的工作技巧，其实已经是公开的秘密：BOSS工程一般分割接、初验、终验三大主要阶段。很多需求和希望，应该说应该是项目终验时所应该达到的目标。所以，我们可以将项目目标按照实际的工作状况分为割接时实现、初验时实现和终验时实现这三种类型。但凡由于割接工期紧张，实在来不及在割接前实现的，就尽可能推到割接后――当然，努力在初验前――完成；系统割接后，就有少则3个月，多则半年甚至一年的时间，用来实现那些曾经承诺的东西。而对于这些曾经承诺的东西，往往一部分是的确实现了，而有的却由于甲方环境的变化或者领导的更替而取消了，有的被转化为其他的需求，甚至有一部分压根就凭空消失了。况且，最后还有一个终验呢！即使初验来不及完成，也可以作为“初验遗留问题”在初验后、终验后再解决嘛！

况且，即使真的是有初验、终验期间不得不做的工作量狂大的需求，乙方实际上也可以通过割接成功带来的“政治效应”，争取通过其他各种各样的方式获取其他合同来“补偿”这一部分损失。

可能有的DX会说，这样做的乙方，也太不地道了吧？可是，如果不这么做，乙方――尤其是这些国内的、没有太多“权威发言权”的厂商又如何生存？要知道，甲乙双方原来的合同条款就是非常模糊而含混不清的。举一个简单的例子说明：大部分BOSS合同都要求“必须完全符合BOSS规范”。而这些所谓的规范，往往是由很多言辞含混、界限模糊的内容，甚至可以说是大而全，如果真的要全部100%满足，恐怕就意味着要满足甲方无止境的提出的各种各样的需求――这样的话，乙方还如何生存？要知道一个项目的合同额是有限的，乙方企业的投入也必然是有限的。