——软件产品、技术以及标准的对话

通过开放平台做应用并不是一件很难的事。今天在开放平台上开发出来的应用，大多数都不像传统的软件那样，但换个角度，这些应用产品却同样是一个工程。正因为应用的简洁，竞争对手的效仿就变得更加容易。如何保持技术与应用的创新优势，便成了一个工程问题，因此我们邀请了软件工程的专家青润特别撰文，谈谈如何在开放环境下保持竞争优势。

文／青润

最近几个月发生了几件事情：

开心网状告开心网；

软件营销论坛上，一场国际上关于软件行业标准制定讨论成了“闹剧”；

在做某电子病历之类的网络平台，经历了很特别的“管理压制”；

模式识别技术的应用之一——森林火灾报警检测方案的最终设计完成。

这几件事情从表面上看，似乎没有什么关联，但是，从本质上他们都包含了如下内容：

都是软件产品或者都是针对软件产品的；

都存在技术竞争和对立；

都需要或者在一定程度上需要一套标准来定义支持。

引发的思考

开心事件

开心告开心的事情让人感觉真的很开心，去年开始我发现很多老同学和周围的朋友在玩开心网，可是，我却一直拒绝玩，主要是因为比较厌烦开心网的垃圾邮件推广方式。另外，我对这类游戏并不感兴趣——很多老同学和朋友甚至刚开始不承认开心网也是游戏，也就是说，他们认为这是一个消遣的娱乐方式。毕竟对于很多人来说，直接宣传自己是游戏，会引起很多人的抗拒，而变化一种面目来操作，行游戏之本质，会让很多拒绝游戏的人不知不觉中进入其境地，当他们意识到自己已经是在玩游戏的时候，就只能给自己寻找借口，说自己的网游是不花钱的云云。

但是随之而来我们看到的开心告开心，以及漫山遍野的开心农场、开心鱼塘，大家不禁开始关注，谁是正宗，谁是山寨？谁是标准，谁在跟进？玩家问：我们玩谁的游戏最后不会没得玩？开发者问：我们跟进谁的OpenAPI做开发，最后会不会做不成？

因为所有的人都会有一个共同的认知，那就是：标准才能持久！

国际标准如何制定

在今年的中国软件营销论坛上，有幸听到了北京邮电大学的一个女教授讲述她参加的国际上的软件行业标准制定委员会的工作内容和工作方式。

从她的描述中，我们得知：

绝大多数国家在参与软件标准制定的时候，都是以国家利益为基础进行竞争的，而不是考虑否符合软件开发的实际情况。

各国之间的利益竞争，在各方的互利(互相支持对方的标准)模式和争议表决方式(大家举手投票表决)中存在的更多的是利益，而不是对问题的解决。

各个标准组的定义和人员的权限，是根据国家的实力和影响进行划分的。

上面这三点，从商业和国家的利益角度出发，笔者并不表示反对，但是，从一个单纯的技术角度来看待，我只能评价其为一场“闹剧”。

电子病历和模式识别的应用

这两个话题具有很强的相似性。

今年在欧洲举行的一个关于医疗改革方面的全球大会上，美国的一位发言人表示，他们前期资助1000万美元的电子病历失败，后面将准备投入几亿美元进行新型电子病历的研发。

“到了去年12月，圣巴巴拉郡的数据交换计划却悄然落下了帷幕。在耗尽了1,000万美元的资助经费后，该地区的医疗机构却看不到这个项目还有任何继续下去的价值。尽管在该区域还有许多医生仍在使用

电子记录，但跨诊所共享数据、轻松地跟踪病人治疗的梦想却已黯然消褪。

……

美国总统布什在2004年时曾号召，到2014年要让大多数美国人享受电子健康记录。但经过几年的不懈努力之后，电子记录的使用依然处于落后状态。目前仅有10%的医生办公室使用电子记录。医院推广电子病历时，往往还没碰到医疗机构间交换数据这个最大难题(尤其是竞争对手之间的数据交换)，技术本身就已出现了问题，如去年由医疗卫生机构凯泽永久医疗集团(Kaiser Permanente，下称凯泽永久)所运行的医疗数据网络就发生故障中断，还有法律问题、隐私问题、围绕技术的竞争压力问题和投资回报问题等。而数据共享的具体实践也还未在现实世界中获得测试。”(《美国的电子病历之痛》，信息周刊，2009-06-08)

在国内，也有很多公司在进行电子病历开发，一些有前瞻性的医生也在投入精力，希望能够制作出让医生和病患都满意而且使用方便的电子病历，当然，在这个基础上，他们自己也能因此获得不小的回报。

但这个问题的最终结果只能是一家作为标准或者修订后作为标准来进行全国甚至将来全世界的推广，不可能出现多家标准的竞争问题。于是，谁才是最后的标准，这将决定了谁才能获得国家最后的投资和支持，以及将来的所有收益。

同样的事情在模式识别应用的智能视频分析技术上也有体现，只是在这个领域更多的竞争是在国外技术对国内的渗透中与国内技术之间的冲突和对抗。

模式识别技术的实际应用应该是在积累了二十多年后的2006年才可以真正地投入实际环境进行使用，国外也不过比我们提前了最多一年左右的时间。

这一年笔者还在中科院自动化所工作期间，与公安部一所(专门制定安全相关标准的部门)进行过多次洽谈和现场交流，但是迄今为止，仍然没有一个国家标准定义的出台，更不用说什么行业标准。因此很多送去检验的产品执行的都是企业标准，特定环境内达到特定效果的检测，然后很多企业就拿着这个检测报告对外宣称自己能够解决多少实际问题。

产品、技术、标准

标准的选择和看待

一般而言，标准分为三个层面：国家标准、行业标准、企业标准。不同的标准有不同的限定要求，而对于软件行业而言，我们还可以看到很多世界级别的标准或者说影响达到了世界层面的一些标准，诸如这些年的CMM/CMMI系列就是从一个研究机构推动而出并逐渐被世界接受的标准。

笔者当年所在的公司在2001年就参与了CMM3级的部门评估，于2002年开始撰写文字并发表告诉大家，CMM不是认证是评估，当年我们那位来自印度的CMM的主任评估师也一直强调这一点。但是发现直到现在，国内还是在说CMM/CMMI认证如何如何，诸如：

“截至2003年3月，全国共有近50家软件企业通过CMM认证，其中通过2级的32家，3级9家，4级2家，5级的4家……”

“CMM/CMMI认证前的准备工作”

“申请CMM/CMMI的认证费用有多大？”

“关于CMM/CMMI的认证费用的问题很难回答，从上面题目的讲解中你可以看到它主要取决于评估者及所属的机构。”

……

其实，CMM/CMMI的评估在SEI的建议是：每半年到一年需要进行一次新的评估，每次的评估都只是告诉这个企业你到评估为止的软件开发程度可以达到什么级别，并不是告诉社会，评估完成后，这个企业的项目开发程度就一定是什么级别的。

我们那位主任评估师还强调的一点是：“我是来帮你们寻找问题的……”，找到问题后，他会给我们提供相应的指导建议和策略，所以，一次完整的CMM/CMMI的评估一般都会持续6个月以上，而不是很短的时间。

当然，从另一个角度来看，这是

SEI成功的基础，SEI因为它的这种不断评估不断推动的模式，给他自身和它的评估师也带来了大量的现金收入。

很多人对CMM/CMMI的抱怨在于：文档过多。甚至有人认为CMM/CMMI的结果是：“项目经理几乎成了文员，而对于一个程序员却可能成了一个文档编写家。所以最终惹得大家都抱怨过程文档太多了，70、80个模版，哪里记得那么清楚。”

实际上，CMM/CMMI从来没有制定一个必需的软件过程框架进行执行，它只是一个抽象层面上的分析结果，看待你的团队是否规范，不仅是文档，也在于记录和稳定的有效性上。一般而言，出现这种抱怨结果的企业往往都是采用了RUP或者类似的开发过程作为企业软件核心过程来推动自己的软件过程改进的时候出现的问题。这和我们国内软件企业的生存环境有着很大的差异，在RUP中也给出了裁减建议，但是，你即使按照它的裁剪建议进行执行，其结果也往往是一般企业不能接受的程度。如果你采用了敏捷开发中的一些轻量级方法或者笔者的全程建模方法论配合迭代过程模型都可以在很大程度上减少文档的撰写，这些方法同样可以让你达到所谓的CMM/CMMI3级以上的内容，因为4/5级别的内容主要是在组织层面和数据积累层面的提高，不再单纯是团队层面的提高，所以，可以说能够“真正”达到3级别评估的团队在团队层面的开发管理上应该已经成熟了。

有些企业通过评估的主要目的是拿政府的奖金，这也是可以理解的。标明自己跟随标准如何如何的紧密，往往只能说明你公司在市场或者技术层面的怯懦。就好像一款劣质汽车上非要贴上一个奔驰的标志，来显示自己的出身高贵。要知道，标签不能保证你的企业有收入，只能糊弄一些不明所以的人，而这些人的族群数量只会越来越少，也就是说，欺骗总有现形的那一天。

对于所谓的国际标准，都是需要进行斟酌度量的，如果不是国家要求必须如何操作(诸如军方的一些项目的特殊性要求)，都不要被标准所误导。前面抱怨文档过多的企业，一般都是犯了“本本主义”错误。总认为：别人说的就是圣经，圣经就能解决一切问题。但实际上，并不是这样，圣经也要拿给懂得它的人来读，来分析、讲述，才能让更多的人接受。

因此，所谓的国际标准都是利益的划分和讨论，根本不是以工程实际为基础来看待如何解决问题的标准。也就是说，标准制定的终极目标不是为了软件工程活动进行指导，而仅仅是各国之间的利益划分。

技术的应用与实践

做好一个产品除了恰当得应用好标准外，还要采用适当的技术和适当的方式进行推动。

从开心告开心和众多的开心农场、开心鱼塘……的出现，可以看到同类技术的模仿是非常快的，而同样大家也认为最初的那个开心也是模仿照抄facebook 的东西，并不是自己所独创的。于是，它也很快被别人所模仿照抄，tencent 现在也在做开心农场之类的小游戏，依托它巨大的用户群推动着它的新业务，也给开心网带来了不小的冲击。

技术的应用往往不在于其先进性，而在于其合理性。

但是合理的技术应用通常很难形成较高的技术门槛，容易被仿冒。在目前这个社会阶段，信息交流无边界限制的情况下，很难确保你的技术具有足够高的门槛，更多的门槛应该在于你的新功能、新应用的推出和对用户市场的把握程度。

如果你能够在你自己的产品被别人有效仿冒之前就推出新的版本和新的应用点，那么，别人的有效仿冒也不可能带走你的主要客户群，也就不可能对你产生有效的冲击。这样就能在一定程度上形成自己的技术壁垒，这样做的根本在于你的产品规划的合理性和递进性。

完全依靠所谓的高新技术是很难长期占有市场的，更不可能依靠市场人员的单纯推动和关系来完全占有市场，因为客户也在对比你的产品和别人的差异。

最近有几个朋友都问过我一个问题：用户对产品的忠诚度到底有多少？

他问这个问题的时候描述到，他希望依靠客户对产品的忠诚度来形成自己的市场份额，希望不要被他人的模仿给带走。这种思考的方式和定位基础是存在问题的，尤其是在互联网应用上会存在更多的弱点，基本上对于互联网应用而言，用户没有多少忠诚度。他们会有一定的产品黏着度，也就是你的产品如果能够获得更多的用户使用，那么他的黏着度就会越高，用户使用的年限越长，他的黏着度也会越高。因此，如何长期的保持用户的使用，而不是用户的变化和流失，就成了一个十分关键的问题所在。这才是技术上在你无法形成有效技术壁垒的时候需要更多考虑的问题。

比如，微软的Windows操作系统就是这样将用户吸附到自己这里来的，即使这些用户没有购买能力，也要让他们无法从自己的系统轻易离开，因为在微软的操作系统上的用户体验做得非常精彩。好像从没有人评价过微软的Windows系统的技术多么的强大，有人在n年前评价说微软Windows2000实现的绝大部分技术其实就是五六年前和Windows95做竞争的IBM的OS/2已经实现了的，但是，IBM的OS/2完全牺牲了，而当时技术相对落后的Windows95/98却活了下来。这个问题不得不让我们深思。

因此，在你没有足够技术壁垒的产品上，产品规划(新版本的不断推出)将是至关重要的问题。在你可以形成技术壁垒的产品上，用户体验将是决定你产品被用户接受的程度和忠诚度。

产品规划和开发管理

说到产品的规划，我总是不禁想到2001年底我在托普成都中央研究院工作期间曾经完成的一套移动增值业务的两年期六个产品线的规划。其中有一个很小的功能当时就得到了四川移动SP业务的负责人的赞赏，可惜的是托普的目标不在产品上。2002年初只立了第一个GPRS Modem的项目，这个规划最后就成了泡影，我也很快离开了这个没有希望的地方。四年后，我把这个精巧的功能送给了北京一个做SP业务的朋友，他在山西网通从事SP业务。其他功能因为部分是具有时效性，还有一些需要较高的开发难度，所以就被全部放弃了。

前几天一个朋友问我，中国的软件企业和国外有多少差异。我说，技术上已经没有多大差异了，主要问题在于管理上的差异。

为什么说技术上已经没有多大差异？

随着互联网的发展，加速了技术上的国内外交流，在20世纪九十年代以前我们的技术基本上要滞后于国外5年左右，而现在无论从哪个方面来看新技术几乎都是同步发送到世界各地的。

我们主要的缺陷在于管理和人员意识，这是不可能在短时间积累起来的，因为管理不仅仅是某些个人理解了管理的方式和方法，更在于所有参与人员对管理的认识和执行状态。

从团队来看，如果有人无法理解管理上的一些策略和执行方式，那么开发过程的执行就会出现严重的分歧，在项目计划的制定上就会出现很大的争议，同样在执行过程中也不会得到一致的认识。

在国外用了三十多年的管理水平，我们不可能用十年时间就全部理解。另外，加上国外的企业和用户状态都和我们目前有着较大的差异，直接照搬国外目前的管理方法和手段往往是不能立刻获得收效的，只有针对国内的实际情况进行管理模式的理解和管理方法的变更才有可能获得最有效的执行。

这一点就好像有一个曾经做过电信老九七工程的人评价目前的国内行业软件开发：国内目前除了税务、电力行业外，其他行业的信息化水平基本上处于

20世纪九十年代的电信的信息化状态，用户意识也处于那个状态，在和用户的交流中可以深切地感受到，用户提出的问题都是我们十多年前作电信老九七的时候当时的用户问过的同类问题的另一个行业的翻版。

在我最近看到的一期医学信息化的国内刊物上，还在阐述VPN技术和局域网等给医疗信息化带来的好处，国内的电子病历和医院的信息化都仍然处于一个很基础的状态下。

这样的差距，也同样存在于我们和国外的软件开发之中，他们不是技术的差距，而是管理意识上的差距。

综述

产品、技术和标准之间还有很多的话题可以进行探讨，本文主要是从应用和管理的角度来看待产品开发过程中的技术和标准问题。如果脱离了这个环境来看，本文中的部分观点就会出现错误，因此不能一概而论，更不建议在不同的环境中采用同一套思考方式来看待同样的问题。

理智的分析，不要本本主义，这就是本文最后的劝诫。

作者简介：

青润，本名白慧冬，独立软件咨询师，CSDN特约专家，国内全程建模技术的倡导者之一。

(本文来自《程序员》杂志0908期)