软件平台化开发项目实践 起源 对于电信行业而言，这是一个沸腾的岁月——VOIP、小灵通、宽带上网、短消息、预付费等等业务，一股脑的推到百姓面前，让“上帝”们顿时感觉眼花缭乱；而我们，作为电信运营支撑系统（主要功能是计费、营帐）的开发公司，也终于有了用武之地。
面对忽然出现的市场需求，我们迅速做出了本能的反应：尽我们所能满足电信局用户的要求，抢占运营支撑系统的市场份额。本来我们已经拥有了一个针对市级电信客户的小型计费系统，经过不断维护增强而相当成熟；面对一下子冒出来的不同运营商在长话、市话、IP 电话计费营帐以及相互之间结算的系统需求，我们将开发人员分成不同的项目组，在原有基础上分别为不同的客户进行定制开发，并全权负责系统的集成和交付。随着所交付应用的系统数量不断增加，成功的喜悦被一种焦虑和疲惫所代替——客户需求增加/变更和产品缺陷处理。项目团队成员像救火队一样奔赴现场，解决客户的问题。我们就像《人月神话》的描述一样，表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，我们的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质，一个接一个淹没在了焦油坑中。
尽管大家鲜有机会当面交流，但是仍然会通过邮件交流一下现场解决问题的进度和方式：我们发现很多用户的需求是相同或是类似的，由于原有系统缺乏该功能，我们不得不针对不同用户去重复开发相同的特性，我们甚至私下提供代码以相互参考。我们有时隐隐觉得该作些什么使开发效率提高一些，但是这种念头在现场用户焦灼而严厉的目光下转瞬间就消失了。
公司总部也发现了这个问题，为我们空投了一位技术总监。其实我们对他并不陌生，他曾经在硬件和嵌入式系统的项目中从事过管理工作，一个认为系统开发都是类似的、拥有莫名优越感的项目经理。从他参加了一系列昂贵的培训经历来看，总部仿佛期望将他培养成未来的管理明星，而我们这里就好比这位明星的起跳板和出场秀。
刚刚上任，他就为大家宣灌了“平台化”开发的重要意义和方法，声称要将系统开发的像 KFC 配餐一样方便快捷。他要求项目组把各个系统的特性列出清单，然后将这些特性汇总为一张总表，又加上了一些颇为时尚的定语：跨数据库、跨操作系统、三层结构等等。当我们解释跨数据库在技术实现上是多么困难
时，得到的答复是你们可以自行开发一个高效的数据库来彻底解决这个麻烦。在饱受现场客户的抱怨后，我们长久以来被压抑的情绪终于在这种无知和傲慢面前得到了发泄：在一次重要的产品规划会议上，我们将异常乐观的里程碑计划、“乱点鸳鸯谱”般的特性分配进行了彻底的否决，甚至将这个梦想中的“平台产品”戏称为“杀死你三千”（周星驰的一部电影中将各种炸药放在一个篮子里，声称是精心研制出的超级武器，实际上却是派不上用场的废物）。那位曾经踌躇滿志的技术总监在“千夫所指”下黯然离去。
闹剧收场了，尽管我们在心里上得到了暂时的宣泄，但是在业务上却是一筹莫展。我们也认同这种平台化开发是解决目前困境的有效手段，但是仅仅有理念是远远不够的，我们缺乏一个真正能够将理念付诸实践的人物，否则仍然要在黑暗中不断碰壁。更糟糕的，我们已经没有时间来挥霍：来自用户的压力渐渐将我们逼到了墙角却无力扭转；公司总部在核算我们部门的财务状况，如果无法盈利将来就会被拆分或是裁员。
我们将何去何从？ 转机 有时候你不得不承认一个人可以带来转机。
作为一家开发电信支撑系统的公司，Z 公司是我们的竞争对手，其产品质量和研发效率强于我们，我们一直也不明白其中的奥秘。Z 公司的一位资深项目经理被我们“挖”了过来，准确的说不是我们“挖”的，而是这位心直口快的业务牛人得罪了公司高层，居然越俎代庖的妄想染指 Z 公司的产品规划活动，震怒的 Z 公司高层于是将他“推”到了我们面前。我们就将这位业务牛人称为“小马”吧。
在困境中的人们往往期望奇迹的发生，我们就将这个奇迹寄托在小马身上了——小马被任命为我们的技术总监。
由于曾经是竞争对手，小马对我们的产品现状一清二楚，甚至可以说得出各个产品的特点和缺陷。他对我们各自为战的局面感到困惑，明确提出当务之急是必须采取平台化开发方式，开发出能够支撑未来整个产品系列的平台框架，同时针对不同的电信客户进行少量定制开发，在质量和进度方面获得突破。他也指出平台化开发会暂时影响我们对市场的响应，就是说会丢掉一些机会；我们在研发组织、工程师技能等方面也会有很大的调整。
大家对目前糟糕的状况感到深深的厌恶，都希望能够拿出有力的产品去整顿混乱的市场，当然前提是赶在市场机会窗关闭之前。我们已经没有退路，所以也没有犹豫就投入了这场日后看来颇具风险的“赌博”中了。
重整 小马不像他的前任，没有谈论什么高深的理论，而是直接触及了问题的核心—— 什么是我们的平台产品，里面包括了什么。平台对于我们的开发人员来讲并不陌生——我们每天都在和各式各样的平台打交道：开发平台、信息平台、管理平台。但看似简单的问题着实难以回答，似乎每个人都知道一点，有无法达成共识。多数人心目中的理想平台是无所不能的利器，可以定制成所有的产品：小到市县级的简单市话计费、大到省级漫游计费、也要包括营业帐务系统，还要支撑不断出现的新业务，这样我们就可以“一劳永逸”了。
从实际情况看，我们实在过于天真。基于原有系统不断的修修补补已经将问题暴露出来了——原有的成熟的小型系统的架构根本无法支持全系列的产品，我们未来设计的平台恐怕同样无法包打天下。关键问题是，面对如此庞大的市场，我们到底如何规划产品进而确定平台的范围。
这就是产品规划的问题，对于我们这些技术出身的工程师来讲，实在是“不专业”。都知道在“市场导向”与“技术导向”的 PK 中，无疑前者胜出，关键是如何操作。
小马把我们公司负责计费产品的销售人员、客户经理请来共商大计。从这群平日巧舌如簧的人们口中，我们惊讶的发现了许多非常珍贵的信息：南北电信即将拆分，网间结算系统市场增大；移动公司准备出台新的系统规范，其中会有很多新业务描述等等。当我们问他们为什么不将这些有价值的信息早点告诉我们时，他们说以前提供过很多信息后没有反馈，所以现在也懒的说了；开发人员都挺忙，也没有必要多此一举。我们忽然感觉自己就像铁路上玩耍的小孩，只注意了脚下的石子，却没有意识到即将呼啸而来的列车。
好在现在还不算晚。经过几次会议，我们对整个运营支撑系统的市场才算有了大致清晰的看法：
小型系统属于底端市场，用户对系统的质量要求相对不高，尽管数量较大，但是进入门槛不高且价格战激烈，后期维护成本相对较高； CDMA、PHS 网络正在建设，支撑系统的市场需求旺盛，用户对系统要求很高，并且重视系统的维护和增强，具有非常理想的业务利润；
针对国内终端用户的现状，预付费业务需求很大，关键是系统要提供实时处理的能力，这方面我们与很多竞争对手都是空白； 运营商之间竞争加剧，互联互通屡屡出现问题，因此网间结算系统的需求也很大，我公司在交换产品上强大的竞争力可以很好的支持这项业务； …… 经过对各个细分市场的全面评估，我们终于决定将产品定位在中高端运营支撑系统和网间结算系统，放弃了苦苦支撑的底端市场——尽管有些留恋，但还是对未来充满期望。
我们成立了包括销售经理、客户经理、开发工程师的联合调查小组，几个小组分别针对事先锁定的目标客户，专门了解客户的需求。这样一来，客户反倒奇怪了——原来是遇到问题后叫你们过来，现在倒是不请自到了。由于之前维系得良好的客户关系和现场表现出来的积极认真态度，用户非常的配合——原来用户很乐于将新业务的发展方向共享给我们，当然也乐于有机会倾诉一些对产品的抱怨，我们的调查小组都进行了详细的记录。为期半个月的调查活动确实收获不小，我们甚至了解到很多竞争对手的产品信息。
在公司内部，我们也要求开发人员、技术支持人员将需求和建议都提交上来，我们甚至将公司热线电话的记录都进行了搜索以获取有益的信息。我们从行业报告、电信业务规范等文档中了解业务发展趋势，邀请相关国际优秀公司进行交流（名义上是与人家探讨合作意向，实际上是刺探情报，做法有点卑鄙）。
当无法确定某项特性是否必要时，我们就会考虑既然我们无法代表客户，为什么不去直接问问客户的感觉呢？所幸的是我们的问题几乎都在用户那里得到确认。
总而言之，我们从各种渠道收集系统的需求。
根据我们已经确定的目标市场及其关键业务特性，我们进行了整个产品线的开发规划；相比原来的规划，现在多出了一个“平台产品”，这个并不向外正式出售的产品却是我们全系列产品的基础。下面就是产品开发路标的示意图：
一般来讲，我们对于产品进行版本划分是考虑基础版本用于快速推出并抢占市场份额，通过不断推出后续版本来增加产品特性，巩固、增加市场。平台产品的规划也采取了这一策略。我们根据预期的市场发展确定了市场目标，考虑不同产品的版本划分和特性分配、平台产品对应的配套版本，特性实现的优先次序、可用的研发资源等信息，初步规划了整个平台产品系列的开发里程碑计划。
尽管我们已经耗费了很多时间进行产品规划而没有发布一款新的产品，但仍然对未来充满信心，原因是我们努力的目标逐渐清晰了。不过我们却低估了后续开发的难度。
痛并快乐着 我们把研发人员分成若干小组，其中最为重要的就是总体方案设计的小组和平台产品研发的小组，还有针对不同产品进行定制研发的小组。
总体方案设计小组负责更为详细的产品规划、产品特性分配、平台产品的技术方案和架构设计。最为关键和困难的就是确定平台产品和最终产品的需求界限：如果定义得过于宽泛，平台就会过于臃肿和低效，成了四不像的怪物；如果过于简陋，最终产品的开发工作量增加，平台的收益就会大打折扣。原有系统架构的局限性使我们要设计出更为健壮的产品平台。这些在技术和业务方面都颇有造诣的工程师就像在实验室里使用天平一样进行着精心的设计，他们深知其结果对这个产品线意味着什么。
一旦确定了技术路线和总体架构，我们就能够制定出更为准确的研发计划。为了降低风险，在小马的提议下，在一个可发布版本内部，我们进行了增量式开发——在平台产品的一个“小版本”开发并验证完成后，我们就可以进行集成，观察“最终产品”的运行情况，将问题不断反馈到下一个“小版本”的开发计划中，而不是像以前那样直到最后才进行确认。
平台产品研发的小组和定制研发的小组主要是根据方案小组的设计进行实现并验证。在系统实现过程中，我们才发现平台式开发要比想象的困难得多。由于需要考虑模块的重用、兼容、处理效率、容错等问题，相比原来纯粹项目式开发，现在的开发效率大为下降。经验的不足使得总体方案的设计出现变更，引起了后续的连锁不良反应，前面几个“小版本”的验证结果简直是惨不忍睹。大家有些沮丧了。
由于我们把主要资源都投入了平台产品的开发中，已经没有什么精力估计新的市场机会了，现在竞争对手已经抢到了我们的前头。公司高层有些坐不住了：要求我们的研发资源优先考虑市场机会，将平台的开发工作推后。这时候，小马忽然变得异常强硬，说服领导坚持优先进行平台开发，暂时放弃面前诱人的市场机会。在其一番软硬兼施下，公司高层决定让我们放手一搏。
大家对现状都很清楚，事实上我们已经没有退路了。利用一个晚上，我们奢侈地享受了一次视觉盛宴：项目组成员集体观看史诗巨片《TROY》。我们现在的处境好比阿基硫斯率领的勇士们刚刚登上特洛依城外的海滩，只能为了自己的未来和荣耀而孤注一掷。
在管理方面，我们采取了更加灵活的方式：平台开发小组实施更为严格的过程管理制度，主要体现在输出件的配置管理、变更控制、正规检视；而对于定制开发的小组则允许相对宽松的管理方式。这种方法可以最大限度的保证核心系统的质量，加快开发速度。
吸取了以前版本混乱的教训，从编码阶段开始，我们对于文档和代码进行了更加严格的配置管理，要求在每个小版本验证之前必须提交各自完成的代码，其后的变更遵循流程的控制。有一位屡教不改的资深工程师，被恼火的小马直接“派去人力资源部报到”了。
原来我们有一个“潜规则”：升任项目经理后就拥有了不亲自编程的特权。对此，小马认为项目经理会逐渐失去对项目的“嗅觉”，他要求每个项目经理都要从事文档设计、编码和检视工作，没有例外。起初，几个项目经理都是颇为不屑——哪有教授还参加考试的道理，但是发现小马并非光说不练的“嘴把式”的时候，再也没有人行使“特权”了。
如果说，我们的开发进程在开始阶段是跌跌撞撞的话，在历经了三次内部小版本的验证后，就已经步入了顺利的快车道：例行的小组沟通会变得不再劳神，项目进度偏差可控，没有人怀疑会重现以前无法按时发布的情况，最为重要的是小版本验证的通过树立起了必胜的信心。
随着项目完成过半，我们决定再多做些事情：我们提前为销售人员介绍了产品的特性，将部分完成的系统展示给他们，使他们在用户面前拥有更多的“炮弹”；我们要求资料撰写人员提前介入，先期充分的产品规划工作为用户文档撰写带来了极大方便；在进行内部验证时，我们要求技术支持人员使用这个系统，以了解是否符合用户的习惯；由于用户对于系统运行的硬件环境有不同要求，我们搭建仿真环境以验证系统的处理能力和硬件的兼容性；我们要求各个定制小组开发系统迁移计划和实施方案，以应对未来系统部署时可能遇到的问题。
项目在有条不紊的进行着，市场上的竞争日趋白热。为了验证用户对我们产品的看法，销售人员选择了典型客户进行产品试用。从试用反馈情况来看，用户比较认同新开发的产品，同时也对运行界面、部分特性提出了建议，我们都进行了记录和分析。例如原来数据文件的采集都是采用 FTP 方式，现在有用户提出在网络质量不高情况下，FTP 方式可能导致大文件重复传递或者传递失败，建议增加对 MQ 传输方式的支持。我们将这个需求增加到平台产品中，这意味着相关产品都具备了这个功能。
我们的努力终于得到了回报，同时发布了全系列产品。由于平台产品具备系统健壮、便于扩展、接口灵活等优势，使我们在不同的细分市场竞争中取得了领先。我们可以在合同中明确承诺产品交付延期的惩罚措施，而竞争对手在这方面几乎都是遮遮掩掩——这源于我们对产品的信心。
尾声 没有什么系统能够“一劳永逸”，平台产品也是一样，但是它的升级却可以最大限度的延长产品的生命周期。我们现在正在开发下一代的运营支撑系统平台，重点增强对软交换、3G、内容服务的业务支持。从当初的一片空白到现在的驾轻就熟，确实走过了异常艰辛的历程，所幸的是我们坚持下来并迎来了胜利。
有人想知道我们在困难的时候如何坚持下来，小马只是淡淡的说：当时没想什么，只是“我等这个机会等了半年，我不是要证明我比别人了不起，而是要证明我失去的东西我一定要亲手拿回来。”
汉捷咨询 靖爽
相关热词搜索： 开发项目 实践 平台