本文是已经在程序员杂志上发表过的约稿，按照惯例，我会推迟一个月发布在我的 blog 上，这次因为其他事情而疏忽了，所以，今天才发布出来。
1. 最近的几件事情
最近这几个月发生了几件事情：
1、 开心告开心；
2、 参加了软件营销论坛，听了一场关于国际上软件行业标准制定的“闹剧”；
3、 去帮一个医生的公司做电子病历之类的网络平台，结果，经历了一个英国某非牛津 MBA 出来的总经理的很“牛”的管理压制。
4、 模式识别技术的应用之一——森林火灾报警检测方案的最终设计完成。
这几件事情从表面上看，似乎没有什么关联，但是，从本质上他们都包含了如下内容：
第一、 都是软件产品或者都是针对软件产品的。
第二、 都存在技术竞争和对立。
第三、 都需要或者在一定程度上需要一套标准来定义支持。
2. 引发的思考
2.1 开心事件
开心告开心的事情让人感觉真得很开心，从去年开始我发现我很多老同学和周围的朋友在玩开心网，可是，我却一直拒绝去玩，主要是因为比较厌烦开心网的垃圾邮件推广方式，另外，就是我对这类游戏并不感兴趣——很多老同学和朋友甚至刚开始不承认开心网也是游戏，也就是说，他们认为这是一个消遣的娱乐方式。毕竟对于很多人来说，直接宣传自己是游戏，会引起很多人的拒绝，而变化一种面目来操作，行游戏之本质，会让很多拒绝游戏的人不知不觉中进入其境地，当他们意识到自己已经是在玩游戏的时候，就只能给自己寻找借口，说自己的网游是不花钱的云云。
但是随之而来我们看到的开心告开心，以及漫山遍野的开心农场、开心鱼塘之类的重复类似形态的产品不断推出，大家不禁开始关注，谁才是正宗的，谁是山寨的？那么随之而来的问题就是：谁的才是标准，谁是跟进的？玩家问：我们玩谁的游戏最后不会没得玩？开发者问：我们跟进谁的 OpenAPI 做开发，最后不会做不成？——大家都知道，对于 SNS 来说，只有拥有较多的客户群的，开发者跟进的开发才可能因此赚到较多的收益。
因为所有的人都会有一个共同的默认认知，那就是：标准才能持久！其他所有非标准的东西总有一天要跟着标准进行修改，否则就会被淘汰。
2.2 国际标准如何制定
在今年的中国软件营销论坛上，有幸听到了北京邮电大学的一个女教授讲述她参加的国际上的软件行业标准制定委员会的工作内容和工作方式。
从她的描述中，我们得知：
1、 绝大多数国家在参与软件标准制定的时候，都是以国家利益为基础进行竞争的，而不是根据是否符合软件开发的实际情况来制订的。
2、 各国之间的利益竞争，从各方的互利（互相支持对方的标准）模式和争议表决方式（大家举手投票表决）中存在的更多的是利益，而不是对问题的解决。
3、 各个标准组的定义和人员的权限，是根据国家的实力和影响进行划分的。
上面这三点，从商业和国家的利益角度出发，笔者并不表示反对，但是，从一个单纯的技术角度来看待，我只能评价其为一场“闹剧”。
只是从这里我们看到了国际标准到底是什么？是否还值得我们这些软件从业人员在日常工作中去追随，跟进，执行。
2.3 电子病历和模式识别的应用
这两个话题具有很强的相似性，所以放在一起做分析。
今年在欧洲举行的一个关于医疗改革方面的全球大会上，美国的一位发言人表示，他们前期资助 1000 万美元的电子病历失败，后面准备投入几亿美元进行新型电子病历的研发。
“到了去年 12 月，圣巴巴拉郡的数据交换计划却悄然落下了帷幕。在耗尽了 1,000 万美元的资助经费后，该地区的医疗机构却看不到这个项目还有什么继续下去的价值。尽管在该区域还有许多医生仍在使用电子记录，但跨诊所共享数据、轻松地跟踪病人治疗的梦想却已黯然消褪。
……
美国总统布什在 2004 年时曾号召，到 2014 年要让大多数美国人享受电子健康记录。但经过几年的不懈努力，电子记录的使用依然处于落后状态。目前仅有 10% 的医生办公室使用电子记录。医院推广电子病历时，往往还没碰到医疗机构间交换数据的最大难题 ( 尤其是竞争对手之间的数据交换 ) ，技术本身就已出现了问题，如去年由医疗卫生机构凯泽永久医疗集团 (Kaiser Permanente ，下称凯泽永久 ) 所运行的医疗数据网络就发生故障中断。还有法律问题、隐私问题、围绕技术的竞争压力问题和投资回报问题等。而数据共享的具体实践也还未在现实世界中获得广泛测试。”
——以上内容引自《美国的电子病历之痛》，出处：信息周刊 作者：赵红权 编译日期： 2009-06-08 。
在国内，也有众多的公司进行电子病历的开发，还有一些有前瞻性的医生也在投入自己的精力，希望能够制作出让医生和病患都满意而且使用方便的电子病历，当然，在这个基础上，他们自己也能因此获得不小的回报。
这个问题大家都知道的最终结果只能是一家作为标准或者修订后作为标准来进行全国甚至将来全世界的推广，不可能出现多家标准的竞争问题。于是，谁才可能是最后的标准，这将决定了谁才能获得国家最后的投资和支持，以及将来的所有收益。
同样的事情在模式识别应用的智能视频分析技术上也有体现，只是在这个领域更多的竞争是在国外技术对国内的渗透中与国内技术之间的冲突和对抗。
模式识别技术的实际应用应该是在积累了二十多年后的 2006 年才开始可以真正的投入实际环境进行使用，国外也不过比我们提前了最多一年左右的时间（这个是在和多家国外厂商进行交流后得出的结论，因为甚至很多它们宣称已经在国外投入使用的场景的基础数据中的有效信息部分他们都无法提供，它们只能宣称应用了哪些行业，却无法准确的通过结果数据让我们相信他们应用的效果）。
2006 年笔者还在中科院自动化所工作期间，与公安部一所（专门制定安全相关标准的部门）进行过多次洽谈和现场交流，但是迄今为止，仍然没有一个国家标准定义的出台，更不用说什么行业标准。因此很多送去检验的产品执行的都是企业标准，特定环境内达到特定效果的检测，然后很多企业就拿着这个检测报告对外宣称自己能够解决多少实际问题（这些问题其实大都不在它评测中限定的特定环境之内）。
那我们应该如何看待标准，如何使用标准，标准和技术之间有什么样的对立统一关系，如何在标准的指导下应用好合适的技术来完成产品，交付客户，这都是一个十分复杂的话题。
3. 产品、技术、标准
那么对于一个企业而言，应该如何看待标准，如何使用技术，如何完成产品，如何获得市场的认可，这是一个最终的核心问题。这里我们就分为三个层次对这三点进行尽可能详细的阐述。
3.1 标准的选择和看待
一般而言，标准分为三个层面：国家标准、行业标准、企业标准。对于不同的标准有不同的限定要求，而对于软件行业而言，我们还可以看到很多世界级别的标准或者说影响达到了世界层面的一些标准，诸如这些年的 CMM/CMMI 系列就是从一个研究机构推动而出并逐渐被世界接受的标准。
这里我们就拿大家都熟悉的 CMM/CMMI 标准来进行分析。
笔者当年所在的公司在 2001 年就参与了 CMM3 级的部门评估，于 2002 年开始有文字撰写并发表告诉大家， CMM 不是认证是评估，当年我们那位来自印度的 CMM 的主任评估师一直强调这一点。但是发现直到现在，国内还是在说 CMM/CMMI 认证如何如何，诸如：
“截至 2003 年 3 月，全国共有近 50 家软件企业通过 CMM 认证，其中通过 2 级的 32 家， 3 级 9 家， 4 级 2 家， 5 级的 4 家。而全国仅有 1400 多家软件企业，实施 CMM 认证的企业比例己经高于世界平均水平。”
“ CMM/CMMI 认证前的准备工作：
8 ．申请 CMM/CMMI 的认证费用有多大？
关于 CMM/CMMI 的认证费用的问题很难回答，从上面题目的讲解中你可以看到它主要取决于评估者及所属的机构。”
（因为以上两个是反面题材就不注明出处了）。
此外， CMM/CMMI 的评估在 SEI 的建议是：每半年到一年需要进行一次新的评估，每次的评估都只是告诉这个企业你到评估时为止的软件开发程度可以达到什么级别，并不是告诉社会，评估完成后，这个企业的项目开发程度就一定是什么级别的。每年发布的 SEI 报告中也只会评价说，目前为止达到的企业数量和国家分布情况。
我们那位主任评估师还强调的一点是：“我是来帮你们寻找问题的，……”，找到问题后，他会给我们提供相应的指导建议和策略，所以，一次完整的 CMM/CMMI 的评估一般都会持续 6 个月以上，而不是很短的时间。
当然，从另一个角度来看，这是 SEI 成功的基础， SEI 因为它的这种不断评估不断推动的模式，给他自身和它的评估师也带来了大量的现金收入。
下面我们针对 CMM/CMMI 中的一个关键点进行一下分析，看看我们应该如何看待标准：
很多人对 CMM/CMMI 的抱怨在于：文档过多。甚至有人认为 CMM/CMMI 的结果是：“项目经理几乎成了文员，而对于一个程序员却可能成了一个文档编写家。所以最终惹的大家都抱怨过程文档太多了， 70 、 80 个模版，哪里记得那么清楚。”
实际上， CMM/CMMI 从来没有制定一个必须的软件过程框架进行执行，它只是一个抽象层面上的分析结果，看待你的团队是否规范，不仅仅是文档，而在于记录和稳定的有效性上。一般而言，出现这种抱怨结果的企业往往都是采用了 RUP 或者类似的开发过程作为企业软件核心过程来推动自己的软件过程改进的时候出现的问题。采用 RUP ，甚至国外曾经有过的一种更重量级的过程模型 EUP ，他们都是在团队层面要求较大的模式下形成的，而不是针对一般性的中小软件企业，而且其产生的环境是欧美社会制度下的软件企业生存环境，这和我们国内软件企业的生存环境有着很大的差异。而同样在 RUP 中也给出了裁减建议，但是，你即使按照它的裁剪建议进行执行，其结果也往往是一般企业不能接受的程度。如果你采用了敏捷开发中的一些轻量级方法或者笔者的全程建模方法论配合迭代过程模型都可以在很大程度上减少文档的撰写，这些方法同样可以让你达到所谓的 CMM/CMMI3 级以上的内容，因为 4/5 级别的内容主要是在组织层面和数据积累层面的提高，不再单纯是团队层面的提高，所以，可以说能够“真正”达到 3 级别评估的团队在团队层面的开发管理上应该是已经成熟了的。
有些企业通过评估的主要目的是拿政府的奖金，这也是可以理解的。标明自己跟随标准如何如何的紧密，往往只能说明你公司在市场或者技术层面的怯懦。就好像一款劣质汽车上非要贴上一个奔驰的标，来显示自己的出身高贵。要知道，标签不能保证你的企业有收入，只能糊弄一些不明所以的人，而这些人的族群数量只会越来越少，也就是说，欺骗总有现形的那一天。
对于所谓的国际标准，都是需要进行斟酌度量的，如果不是国家要求必须如何如何操作（诸如军方的一些项目的特殊性要求），都不要被标准所误导。前面抱怨文档过多的企业，一般都是犯了“本本主义”的错误。总认为：别人说的就是圣经，圣经就能解决一切问题。但实际上，并不是这样的，圣经也要拿给懂得它的人来读，来分析，来讲述，才能让更多的人接受，几百年来基督教的传播在这方面显示出了其强大的生命力。同样我们也可以看到，仍然有很多教士对福音书和教义的传播是失败的，最后很惨烈，这在基督教的发展史上并不鲜见此类事件的发生。同样的事情，我们也可以从佛教在中国的传播发展过程看到，佛教在汉末唐初时期与道教、儒教进行了几百年的融合和相互学习，最后形成的是很有中国特色的佛教，而不是原始的印度起源的佛教状态。
如果没有听过今年软件营销论坛的那个关于标准的议题的朋友，可以去听一下，那位教授很实际的告诉了我们，所谓的国际标准都是利益的划分和讨论，根本不是以工程实际为基础来看待如何解决问题的标准。也就是说，标准制定的终极目标不是为了软件工程活动进行指导，而仅仅是各国之间的利益划分。
3.2 技术的应用与实践
做好一个产品除了恰当得应用好标准外，就是要采用适当的技术和适当的方式进行推动。
从开心告开心和众多的开心农场、开心鱼塘……的出现，可以看到同类技术的模仿是非常快的，而同样大家也认为最初的那个开心也是模仿照抄 facebook 的东西，并不是自己所独创的。于是，他也很快被别人所模仿照抄， tencent 现在也在做开心农场之类的小游戏，依托他巨大的用户群推动着他的新业务，同样也给开心网带来了不小的冲击。
技术的应用往往不在于其先进性，而在于其合理性。
但是合理的技术应用通常很难形成较高的技术门槛，容易被仿冒。在目前这个社会阶段，信息交流无边界限制的情况下，很难确保你的技术具有足够高的门槛，更多的门槛应该在于你的新功能、新应用的推出和对用户市场的把握程度。
如果你能够在你自己的产品被别人有效仿冒之前就推出新的版本和新的应用点，那么，别人的有效仿冒也不可能带走你的主要客户群，也就不可能对你产生有效的冲击。这样就能在一定程度上形成自己的技术壁垒，这样做的根本在于你的产品规划的合理性和递进性。
完全依靠所谓的高新技术是很难长期占有市场的，更不可能依靠市场人员的单纯推动和关系来完全占有市场，因为客户也在对比您的产品和别人的差异。
最近有几个朋友都问过我一个问题：用户对产品的忠诚度到底有多少？
他问这个问题的时候描述到，他希望依靠客户对产品的忠诚度来形成自己的市场分额，希望不要被他人的模仿给带走。这种思考的方式和定位基础是存在问题的，尤其是在互联网应用上会存在更多的弱点，基本上对于互联网应用而言，用户没有多少忠诚度。他们会有一定的产品黏着度，也就是你的产品如果能够获得更多的用户使用，那么他的黏着度就会越高，用户使用的年限越长，他的黏着度就会越高。因此，如何长期的保持用户的使用，而不是用户的变化和流失，就成了一个十分关键的问题所在。这才是技术上在你无法形成有效技术壁垒的时候需要更多考虑的问题。
比如，微软的 Windows 操作系统就是这样将用户吸附到自己这里来的，即使这些用户没有购买能力，也要让他们无法从自己的系统轻易离开，因为在微软的操作系统上的用户体验做得非常精彩。好像从没有人评价过微软的 Windows 系统的技术多么的强大，有人在 n 年前评价说微软 Windows2000 实现的绝大部分技术其实就是五六年前和 Windows95 做竞争的 IBM 的 OS/2 已经实现了的，但是， IBM 的 OS/2 完全牺牲了，而当时技术相对落后的 Windows95/98 却活了下来。这个问题不得不让我们深思。
因此，在你没有足够技术壁垒的产品上，产品规划（新版本的不断推出）将是至关重要的问题。在你可以形成技术壁垒的产品上，用户体验将是决定你产品被用户接受的程度和忠诚度。
3.3 产品规划和开发管理
说到产品的规划，我总是不禁想到 2001 年底我在托普成都中央研究院工作期间曾经完成的一套移动增值业务的两年期六个产品线的规划。其中有一个很小的功能当时就得到了四川移动 SP 业务的负责人的赞赏，可惜的是托普的目标不在产品上。 2002 年初只立了第一个 GPRS Modem 的项目，这个规划最后就成了泡影，我也很快离开了这个没有希望的地方。四年后，这个精巧的功能我送给了北京一个做 SP 业务的朋友，他在山西网通从事 SP 业务。其他功能因为部分是具有时效性，还有一些需要较高的开发难度，所以就被全部放弃了。
前几天一个朋友问我，中国的软件企业和国外有多少差异。我说，技术上已经没有多大差异了，主要问题在于管理上的差异。
为什么说技术上已经没有多大差异？
这是因为随着互联网的发展，加速了技术的国内外交流，在上世纪九十年代以前我们的技术基本上要滞后于国外 5 年左右，而现在无论从哪个方面来看新技术几乎都是同步发送到世界各地的。
我们主要的缺陷在于管理和人员意识，这是不可能在短时间积累起来的，因为管理不仅仅是某些个人理解了管理的方式和方法，更在于所有参与人员对管理的认识和执行状态。
从团队来看，如果有人无法理解管理上的一些策略和执行方式，那么开发过程的执行就会出现严重的分歧，在项目计划的制定上就会出现很大的争议，同样在执行过程中也不会得到一致的认识。
在国外用了三十多年走到现在的管理水平，我们不可能用十年时间就全部得理解国外的管理水平，另外，加上国外的企业和用户状态都和我们目前有着较大的差异，直接照搬国外目前的管理方法和手段往往是不能立刻获得收效的，只有针对国内的实际情况进行管理模式的理解和管理方法的变更才有可能获得最有效的执行。
这一点就好像有一个曾经做过电信老九七工程的人评价目前的国内行业软件开发：国内目前除了税务、电力行业外，其他行业的信息化水平基本上处于上世纪九十年代的电信的信息化状态，用户意识也处于那个状态，在和用户的交流中可以深切地感受到，用户提出的问题都是我们十多年前作电信老九七的时候当时的用户问过的同类问题的另一个行业的翻版。
在我最近看到的一期医学信息化的国内刊物上，还在阐述 VPN 技术和局域网等给医疗信息化带来的好处，国内的电子病历和医院的信息化都仍然处于一个很基础的状态下。
这样的差距，也同样存在于我们和国外的软件开发之中，他们不是技术的差距，还是管理意识上的差距。
4. 综述
产品、技术和标准之间还有很多的话题可以进行探讨，本文主要是从应用和管理的角度来看待产品开发过程中的技术和标准问题。如果脱离了这个环境来看，本文中的部分观点就会出现错误，因此不能一概而论，更不建议在不同的环境中采用同一套思考方式来看待同样的问题。
理智的分析，不要本本主义，这就是本文最后的劝诫。
