第1部分 融合BSS项目案例

第1章 融合BSS项目

融合BSS上线整一年的某一天，刚好在S省出差，一起战斗过的用户和同事都挺感概。当项目接近尾声时，我曾半开玩笑地说，工程结束后写本书，就叫“我在融合BSS的日子”，或“我和融合BSS不得不说的故事”。但真等上完线，就彻底歇了。时隔一段时间后，还是不时回想这个项目，因为它真的很特别。

1.1 项目背景

融合BSS被看作是L电信运营商打造全国一套系统、拥抱互联网策略的前奏，但信的人并不多。系统向集约化、全国一体化发展方向虽成立，但要落地成为现实，难度很大，且充满不确定性。对比京东、淘宝这样的互联网企业，后者没有三十一个省份公司，没有各省发展了几十年的大小上百套系统，没有几十万从业人员，更没有业务规则的各省差异。一个要搞拆迁才能建设，另一个骑着马拉根绳圈地，不是一个概念。

但我们还是要搞。并且“创新”性地提出了先招标统一版本，再招标多个实施厂商、全国（部分省份）同步实施的模式。统一版本，意味着这个行业第一个国产套装软件要诞生了。最后，业内市场份额最大的A公司中标统一版本；在多省同步实施的招标中，我司中标B省、S省（本人负责的省）。工程要求在T+9月内完成（T为起始点，即甲方发出中标通知日）。

由于我司在此项目中90%的工作是“实施”，所以有大量的工程组织、数据迁移、系统部署、接口联调、验证测试等工程范畴工作，而研发性工作并不多。以此为案例分析项目管理过程具有典型意义。

1.2 工程概要进展

■ 启动阶段（T+1月）

发布中标结果之后约一个月时间，都属于启动阶段。

这段时间我们的主要工作：

1．参加各种启动会。

2．内部疯狂抓人。

3．以T+9月为目标排计划，制订项目策略。

我们最大的困难：

1．没人

在投标时我们承诺S省投入280人（售前一个疯子想出来的），而在启动时两省加一起也没有80人，我要疯了。

2．真的要用A公司的统一版本

很多人不相信这个行业能在9个月内落地实施全国统一版本。我们也不信，所以项目启动初是做着“适时”替换成自己公司版本的打算。但参加了甲方组织的几次启动会后便相信了。一是“政治”上的高压；二是在项目管控上采取了总部统一调度、集中实施的方式，不像原来开完启动会就不管了；三是将系统前后端分离，前端业务受理独立出一套系统，放到总部，后端业务分省实施。

但核心生产系统多个省实施统一版本的确没有先例。不仅要有电信业务支撑系统，还要有产品管理、业务受理、订单、渠道、三户、基础域、计费批价、预处理、账务处理等十几个核心子系统。使用传统方式，每个子系统做大版本升级建设，都要几十号人在现场，和用户折腾半年以上，投资几百万元；如果是核心主生产系统全面大版本升级，一般工期在18个月左右，要投资数千万元，甚至上亿元。各家集成商付出数年心血搞版本统一，用以实现软件的边际效益，但多数以失败告终。现在要一次性地使用一个竞争对手的版本，且在9个月内实现多省同步上线？做梦。

梦的解析：应用系统=应用软件+系统及应用参数+数据。统一版本意味着，应用软件是唯一的、不允许各省间有差异，所以，业务差异及系统差异都要通过各类参数配置实现。套装软件成立的前提是业务的强一致性。在国内，由于各种原因，31个省份公司业务特性差异很大，每个省份公司都是年收入几十亿元以上的独立运营主体，绝大多数信息系统也是独立的。数十年的演进过程中，总部的角色是出规范、标准、监督检查。而这次，系统被上收并交由总部统一建设。但市场运营的主体还是在省份，业务规则流程也不可能一夜间全部简单划一，尤其对于存量用户、存量业务，比如小灵通。运营商想放弃、通过业务替换保留用户，但终端用户可能并不买账。甲方的意图是想通过系统的统一倒逼业务市场统一，从而推动互联网模式转变，这是一场巨大的博弈。如果因系统混乱造成运营商收入下降，这对极度重视业绩指标的运营商来说是不可容忍的大事。一切皆有可能。

有人拿银行系统举例（那时提阿里的还少），它就是全国集中或双中心模式。但毕竟电信和银行不一样，至于怎么不一样，这里就不展开了，其中很重要的一点是，两者在历史进程中的建设策略不同。

启动阶段除了启动会，更重要的是会下的沟通，以及与用户高层的沟通。我们马不停蹄地在总部、省份各级领导间拜访、汇报。得到的信息量如下。

1．这个事必须成功。

2．统一版本的决心很大。

3．你们要干不了就早说，我们找别人。

4．我们最关心的是你们怎么保证自己的人力投入，我们要你们最得力的人。

5．这个事史无前例，对甲方影响非常之大，本来就很难，如果还有人留心眼、使绊子，我们不会让他好受。

你看，越是高级别的人，说话越实在。

在启动阶段，我们完成的工作如下。

1．形成公司级PMO。

2．明确项目策略：积极投入，通过实施工作抢占核心系统地位，为今后在本省站稳脚跟、扩大份额打造基础。

3．初步形成60余人的现场实施团队（S省），明确总技术负责人、各大组责任人。

4．按照局方T+9要求形成初步项目计划。

5．编制《融合BSS项目管理指南》，明确工程实施方法。

6．与用户形成沟通对应关系。

■ 集中实施阶段（T+4月）

集中实施，就是把大项目群组中共性的工作让所有人一起来干。实施人员主体是实施厂商、版本提供商，也包括甲方信息支撑口、业务口人员，共有几百人。

而我们要做的是：

1．在某培训中心集中各厂商、甲方人员进行统一版本培训，为期20天，约300人。

2．在某培训中心集中所有厂商数据移植组人员，开始数据移植，为期2个月左右，约200人。

3．在某高级酒店集中所有厂商开发、接口、报表组人员培训，为期20天，约150人。

4．在某四星酒店，集中约200人，在一个半月内进行S省份业务需求与目标系统比对，编写新需求规格说明书及测试用例。

以上用的都是付费的培训中心或酒店场地，每人每天费用300元左右。在项目启动头三个月，我司在S省实施的花费就接近千万元，花光了合同中标的那点儿钱（低价投标）。甲方次年补了个大合同，那是后话。而对于上线，我们却连需求都没搞利落呢！疯了，一切都疯了。我们意识到自己陷入了一场疯狂的烧钱游戏，停也停不下来。

这时我公司参加上述任务的人员当中，CRM侧由于有我公司在S省份支底子，所以还好。而计费侧则是临时搭的草台班子，基本两眼一抹黑。新系统一直没下来，就只能先拿着版本提供商A公司某一省的老版本数据在那儿折腾。总部的管理模式，一上来就是细化到天的进度表管控、各省排名和红头文件通报。这还没完，刚启动3个月时，各项基础工作八字没一撇，便要求上报割接方案。主版本还没下来，就要求T+4月内完成配套接口工作。

进入到集中实施阶段的那三四个月里，我们感觉自己像是进入了一个巨大的漩涡。坐在金融街办公室里的几个人，加上某高级咨询公司的十几员干将，对着墙上的进度表，指挥调动着全国上千人的集团军作战。方法简单、粗暴，要求各省的各项工作齐头并进，却全然不顾各厂商对承担省现状的了解情况。而总部承诺的统一版本的交付，一拖再拖。各实施商不断向项目投入人员，花费着巨大成本，却不能按照自己熟悉的、科学客观的方式干活儿。这时候我们才知道“大跃进”是怎么回事了。

项目结束很长时间后，我们才能稍微客观地看待这种集中实施方法。

如果你是这个工程的总负责人，面对全国性的复杂局面，让一个临时拼凑起来的队伍，把各省老系统、老业务整明白，提交给新系统集中开发团队开发，估计要用一年时间。再拿到省里实施，又一年过去了。先不说承诺的9个月工期，当两年以后业务环境发生了变化，这期间的增量需求就有上千条。所以你的选择很可能一样，不管那些老系统、老业务、老朋友是什么样，一切以目标系统为标准。先告诉你目标系统已定，一切以T+2月结束的需求比对为基础，过期再提交的一律不“伺候”。所以工程一上来就是实施阶段。

通过集中实施我们明白了，这个项目的模式是：不用你写一行代码，全是实施，一心就等核心版本。

我们为核心版本总结两句话：

1．千呼万唤始出来。

2．想说爱你不容易。

核心软件的基础版本是A公司入围测试招标时的版本，但要以各省的业务梳理（T+2月内完成）开发增量需求，形成基线版本。开始告诉我们1个月就能出来，结果没有出来；7.15是终级版，虽然下来了，但我们T+2月提交的需求在哪儿呢？看来业内老大的研发能力不过如此。

核心版本的交付延迟是在总部极其严肃地对各省调度工作下发生的。好，我们什么都不信了，先踏踏实实干好自己本省的活儿吧。由此形成了S省的项目策略——跟随，我们等别人先上。它在各省里厂商关系比较复杂，体量最大，业务也最复杂。而统一版本的实施谁都看得出会是一路坎坷。难道说跟随有错吗？

有错，看看后来发生的事情就知道了。

■ 分省实施阶段（T+12月）

T+5月中旬在某省召开的项目月例会是这个项目的转折点。

激动人心的誓师大会过去了，各种红酒、白酒、地方酒也喝过了，集中实施也暂时告一段落，此时大家心里基本有个谱儿：T+9月没戏。而问题在总部的核心版本，不在大家。于是T+5月中旬在某省召开的项目月度会中会议日程前99%的各省发言，都是在摆困难，提要求。上百人的会议形成风向：要求分版，要求支持本省个性业务，要人。而割接时间，谁也不说。更出乎所有人意料的是，本次工程计划第一个上线的试点省H省也是这个态度。

但在最后时刻，总部领导讲话时形势发生逆转。结论：不分版，工程时间不变。强呀！有没有庐山会议的感觉？于是大家各回各家。

然而，好戏还没完。会后没两天，黑马LN省跳出来，说自己完全有信心，希望替代原试点省先期上线。要知道，试点省的确定是非常严肃的事情，因为它和总部有着特殊的关系。于是风向彻底扭转，各省开始纷纷“求上进”。凭借数十年的系统建设经验，大家都很清楚，这类项目只要在一省成功，就可证明当初的决策是正确的。而没有成功的省，只能是你配合有问题。而比烂尾楼更要命的是，信息系统干到一半时骑虎难下，左手要生产，右手要新建，十分难缠。

于是S省开始改变项目策略，从“跟随”转为“争先”。

变化是颠覆性的，S省甲方主建部门几乎全员加入，连地市抽调人员也增加了几倍。而在厂商这边，首先我差点被拿下（谁让你是头儿来着）；又被要求成倍增加人员；移植、对账、测试、配套、接口、培训、系统平台各项工作，也要以争取集团资源、第一批割接为目标来全面推进。

你不得不佩服这个项目的控局者。不用说这么大的工程，且是集团军作战，即使你负责的只是几十万元的小项目，你能做到使你的团队成员不惜一切代价，穷尽自己的智慧，在转变作战方向时唯你马首是瞻？很多人做不到。因为你不知道如何带领他们，更找不到让他们把项目目标作为自己个人终极目标的办法。你只能和大多数人一样，拿小鞭子抽着，或好酒好肉伺候着，让这帮人替“你”干活。这的确是门学问，只有最优秀的管理者、最老到的精英才能做到。

转变策略后省份实施阶段的工作一言以蔽之，就是根据形势需要，多轮次突击赶指标。主要是看业务验证通过率及计费对账准确率，并以此争取总部资源倾斜，而另一方面也希望借此不同寻常的工程方法，加快进度，以人力的加倍投入换取时间。这个期间工程实施的“新”方法、“新”思路层出不穷，也是加班时间最长、最辛苦的一段时间。

这期间的重要事件：

1．人员组织方式调整

打破厂商界限，按职能混合编组，即按照开发、移植、计费对账、测试、配套、技术与接口、培训、系统平台、割接职能分组，这是从来没有过的。而每个组里有不同厂商人员、甲方人员，我们既要按招标时厂商分工界面分配工作，也要考虑个人的工作能力。这种组织方式最大的好处是消除厂商间壁垒与竞争，使参与各方将大项目组目标作为自己公司项目组的目标。你想单搞一套也不行了，因为你的人不一定归你管，他首先要听自己所在组组长的。

在甲方强大压力下，我司从本部、各省分支抽调人员，又加入第三方外包公司，使人数从60人扩到160人，高峰时达到200人。大项目组人员在400人左右。参与人员数量急剧上涨。

2．各项工作并行开展

这是本次工程最重要的特色，也可以说是经验。极大地压缩、降低、人为拆解工程实施工作间的依赖关系，极力使各项工作并行开展，以缩短工期。而作为关键保障，每项并行工作都由专门小组执行，极大减少人员复用，这才使策略得以真正执行，但人员数量也极度膨胀。

割接方案。最难的并行工作是割接方案。以往我们一般在接口联调、用户接收测试通过后再出割接方案，做割接演练。而在本工程中，版本开发阶段就启动了割接策略、割接方案的制订。

计费对账与数据移植。对于传统模式下CRM与计费同步升级的项目而言，计费对账要待数据移植准确率达到一定比例后启动，本次反而是以计费对账工作校对移植效果。

培训。一般项目里培训是最后一项进行的工程实施工作。本次考虑到上万名人员接受培训，务必要分多个轮次，并且还要求经过培训的营业员进行工单补录。再怎么算，没有3个月都是不够的。因此，版本不稳定、数据不准确、环境资源紧张、项目组抽调不出培训讲师，都没能阻挡大规模培训开展的脚步。

3．办公地点更换

从市内办公地点转战到S省培训中心，这是一个方圆十公里以内很难见到城里人的地方。几百人全封闭，心无旁骛地干活儿。

4．京沪高铁开通

这个重要吗？重要。车站离培训中心很近，到其他中心城市很方便。我好几次周六晚下班乘坐最后一班火车回家，周一早上乘坐第一班火车，赶在上班前到办公地点，竟没人知道我回去过。

5．反复多次的数据移植、对账

数据移植组集中了约80人，计费对账组也差不多，都是史上最大规模。从T+6月开始，到T+13月试点地市上线，7个月里搞了不下30轮对账突击。而在传统项目里只会做4、5轮。这意味着多少个夜晚无人入睡，多少次攻坚围城，大家开始很痛苦，后来反而有驾轻就熟的感觉了。

6．版本测试

我们这个组四十人左右随着项目进程进行了各种测试：功能测试、贯通测试、拨测、冒烟测试（151个核心业务场景）、市场部业务验证测试、性能测试、高可用测试、版本接收测试、兼容性测试。看着那些脸色发灰的小姑娘的脸，真心觉得测试组也不容易呀！看来，女也怕入错行。

总的来说，测得还可以。从T+4月只有30%通过率，到上线前已达到99%以上。

还有一个很重要的成就是测试组积累了数千个场景的测试案例库，形成了冒烟测试规范，为版本迭代升级提供了质量保障。

7．配套项目

项目配套是唯一让人欣慰的一个组。为什么？因为接口少，基本不依赖那个千呼万唤出不来的主版本。尤其我司承担的三个主配套系统，在这个大项目开始前就已说服用户启动解耦项目，所以分库、接口标准化，实施比较顺利。

8．接口组

生产系统里最易出故障的就是对外接口。它的建设过程比核心版本还难。要等核心版本的对外服务协议下来才能做开发，然后再和上百个外围系统（客服、网厅、短厅、银行、财务、办公OA、互联网等）联调。过程很曲折，好在最后上线表现极佳。

9．培训

据统计，生产系统升级导致投诉的有50%是由于培训不到位、营业员使用不熟练引起的，可见培训的重要性，而培训这个组做得也不错，取得了骄人的成绩。在版本、测试一直进展不怎么样，以及工程一直极度紧张的背景下，我们还是在三个月里做了几轮全省级培训，近两万人次。这次培训很彻底，为上线后无营业积压立下汗马功劳。

10．平台

新建机房、搭建开发、测试、移植、对账、并行录单环境，到上线前这些条件完全具备，很给力。

最后不得不说工期。T+9月最终还是没有实现。但从另一个角度上也可以说实现了，因为后来确定的试点省LN省实现了，其他各省也号称“初步具备割接条件”。在这种局面下，各省份的自主性增加了，当然也包括S省。T+9月后，我们一边收集试点省上线后的问题，一边把前期“萝卜快了不洗泥”的那些基础工作，尤其数据移植准确率、差异性需求的应对方案、版本测试等夯实，又把割接演练进行了5次，这在其他工程里是没有过的，很好地起到了练兵作用。

■ 割接阶段（T+15月）

这个阶段反而简单，一切为了割接。T+13月割一个试点地市（约200万用户），T+15月一次性割接全省（约5000万用户）。

然而，这个阶段也是惊心动魄的。千年等一回，割还是不割？什么时候割？是按原计划割一个域（约1200万用户），还是改为一个地市以减小风险？割接后怎么保障？印象最深的是试点地市范围的变化，后面再细说。

不管怎么说，割接成功，三军过后尽开颜！一年多，数百人的辛苦，在投入全省营业的那一刻得以回报，这种感觉难以言表！

写了这么多，都是融合BSS项目，相当于本书的序。

“序”很重要。它是各个行业每年都在发生的重大工程中的一个。它既特别，又普通；既不空前，也不绝后。但做项目管理的人，正是在这样的工程里对自己从事的行业，以及人类生产活动的客观规律有了更真切的认识。它再次验证：

1．人性最阴暗、最光明，最愚蠢、最智慧，最虚弱、最强大的一面，在巨大的压力和变革下都会展现得淋漓尽至。

2．只有实践，才会使人对职业有更进一步的了解。有专家说，最痛苦的时候，也是成长最快的时候。

值得多说一点的是，电信行业运营支撑系统，与现在方兴未艾的互联网系统有相同点，也有差异。从本人视角来看，二者类似的是承载的数据量大、业务并发高，以及7×24小时的高可用性。不同点在于，电信运营商财务充足，购买的都是高端设备、商用软件。而互联网企业，花的是投资者有限的钱，所以去IOE成为必然选择。同时，电信业务运营支撑系统各省差异很大，统一版本只能是核心一致、外围差异化；而互联网系统就是一套系统，用部署多个实例实现负载分摊。后者貌似已走在了信息应用技术的前沿，不少传统IT应用行业正开启追赶模式。

此处商务模式上也不同。前者是传统的乙方向甲方交付的方式，工程项目的政治因素很强。作为承建的乙方，有一个不太好的前提，即开发的系统自己并不用，完工的标准是甲方验收。而后者，不论规划、购买设备、功能开发、交付运维，都是自己负责。所以他们自然怎么省钱怎么来，怎么高效怎么来。实践是检验真理的唯一标准，所以慢慢地，他们近乎开创了一个在开源架构上搭建巨大规模系统的奇迹。这也是其后发而领先的重要因素。当然从项目管理者角度来看，当系统规模大到一定程度，企业机构足够细分之后，传统IT建设遇到的问题互联网企业也会碰到，而其该有的政治因素也会接踵而来。毕竟，我们都在地球上。

所以，我坚信项目管理者的经验和认知是行业性的，而行业的边界在模糊化。

下面进入正题，从项目经理的角度谈项目管理，也从项目管理的角度谈项目经理。

本书对话的假设对象是项目经理。然而，我不总结电信专业与IT技术知识，这方面有成千上万的人比我有水平。所以我主要总结项目管理规律与准则，以及项目经理需具备的技能。这个虽然也有很多人比我有水平，但希望能以我的视角，为读者提供多一点借鉴。