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

     以前看到的一篇很好的关于项目管理的文章，转到这里来收藏。

转自中国计费网论坛。

 

[原创]最后期限——BOSS工程项目的管理

写在前面的废话 管理这个东西，看起来好像很”高级“，其实“弱智”得很，适用面往往很窄，所采用的方法、经验甚至于理论，都常常只适用于特定的环境、文化和团队素质等等。越具体的管理经验，越是如此！所以，我这里要罗里罗嗦的预先做一些限制，以尽可能的为自己的”谬论“开脱，呵呵！见笑见笑！ ——这里，顺便插一句：在遇到具体的管理方面的问题时，切不可相信或期望有那所谓的灵丹妙药。因为真正适用你的东西往往不具体，而具体的东西又往往并不适用。管理，是太受”人“本身这个因素的影响啦！俺这里所说的，权作为一种交流吧。。。。。废话少提，下面言归正传： 对所谓的“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省运营商将会和公司成为长期合作伙伴，考虑在当前价格条件下的可怜的公司成本限制和一贯惯例，都住酒店吃不消，也需要这次到现场尽快将当地的办事处建立起来，包括租房、请保姆、聘请当地行政人员等等。

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