Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE什麼是標準，什麼是技術，什麼是產品，別人怎麼做，國家怎麼做我們不管，我們應該怎麼做？

本文是已經在程式設計師雜誌上發表過的約稿，按照慣例，我會推遲一個月釋出在我的blog上，這次因為其他事情而疏忽了，所以，今天才釋出出來。

1. 1. 最近的幾件事情

最近這幾個月發生了幾件事情：

1、kai，xin告kai，xin；

2、參加了軟體營銷論壇，聽了一場關於國際上關於軟體行業標準制定的“鬧劇”；

3、去幫一個醫生的公司做電子病歷之類的網路平臺，結果，經歷了一個英國某非牛津MBA出來的總經理的很“牛”的管理壓制。

4、模式識別技術的應用之一——森林火災報警檢測方案的最終設計完成。

這幾件事情從表面上看，似乎沒有什麼關聯，但是，從本質上他們都包含了如下內容：

都是軟體產品或者都是針對軟體產品的。

都存在技術競爭和對立。

都需要或者在一定程度上需要一套標準來定義支援。

 

2. 引發的思考

2.1      kai，xin事件

kai，xin告kai，xin的事情讓人感覺真得很kai，xin， 從去年開始我發現我很多老同學和周圍的朋友在玩kai，xin網，可是，我卻一直拒絕去玩，主要是因為比較厭煩kai，xin網的垃圾郵件推廣方式，另外，就是我對這類遊戲並 不感興趣——很多老同學和朋友甚至剛開始不承認kai，xin網也是遊戲，也就是說，他們認為這是一個消遣的娛樂方式。畢竟對於很多人來說，直接宣傳自己是遊戲，會 引起很多人的拒絕，而變化一種面目來操作，行遊戲之本質，會讓很多拒絕遊戲的人不知不覺中進入其境地，當他們意識到自己已經是在玩遊戲的時候，就只能給自 己尋找藉口，說自己的網遊是不花錢的云云。

但是隨之而來我們看到的kai，xin告kai，xin，以及漫山遍野的kai，xin農場、kai，xin魚塘之類的重複類似形態的產品不斷推出，大家不禁開始關注，誰才是正宗的，誰是山寨的？那麼隨之而來的問題就是：誰的才是標準，誰是跟進的？玩家問：我們玩誰的遊戲最後不會沒得玩？開發者問：我們跟進誰的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      技術的應用與實踐

做好一個產品除了恰當得應用好標準外，就是要採用適當的技術和適當的方式進行推動。

從kai，xin告kai，xin和眾多的kai，xin農場、kai，xin魚塘……的出現，可以看到同類技術的模仿是非常快的，而同樣大家也認為最初的那個kai，xin也是模仿照抄facebook的東西，並不是自己所獨創的。於是，他也很快被別人所模仿照抄，tencent現在也在做kai，xin農場之類的小遊戲，依託他巨大的使用者群推動著他的新業務，同樣也給kai，xin網帶來了不小的衝擊。

技術的應用往往不在於其先進性，而在於其合理性。

但是合理的技術應用通常很難形成較高的技術門檻，容易被仿冒。在目前這個社會階段，資訊交流無邊界限制的情況下，很難確保你的技術具有足夠高的門檻，更多的門檻應該在於你的新功能、新應用的推出和對使用者市場的把握程度。

如果你能夠在你自己的產品被別人有效仿冒之前就推出新的版本和新的應用點，那麼，別人的有效仿冒也不可能帶走你的主要客戶群，也就不可能對你產生有效的衝擊。這樣就能在一定程度上形成自己的技術壁壘，這樣做的根本在於你的產品規劃的合理性和遞進性。

完全依靠所謂的高新技術是很難長期佔有市場的，更不可能依靠市場人員的單純推動和關係來完全佔有市場，因為客戶也在對比您的產品和別人的差異。

最近有幾個朋友都問過我一個問題：使用者對產品的忠誠度到底有多少？

他問這個問題的時候描述到，他希望依靠 客戶對產品的忠誠度來形成自己的市場分額，希望不要被他人的模仿給帶走。這種思考的方式和定位基礎是存在問題的，尤其是在網際網路應用上會存在更多的弱點， 基本上對於網際網路應用而言，使用者沒有多少忠誠度。他們會有一定的產品黏著度，也就是你的產品如果能夠獲得更多的使用者使用，那麼他的黏著度就會越高，使用者使 用的年限越長，他的黏著度就會越高。因此，如何長期的保持使用者的使用，而不是使用者的變化和流失，就成了一個十分關鍵的問題所在。這才是技術上在你無法形成 有效技術壁壘的時候需要更多考慮的問題。

比如，微軟的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. 綜述

產品、技術和標準之間還有很多的話題可以進行探討，本文主要是從應用和管理的角度來看待產品開發過程中的技術和標準問題。如果脫離了這個環境來看，本文中的部分觀點就會出現錯誤，因此不能一概而論，更不建議在不同的環境中採用同一套思考方式來看待同樣的問題。

理智的分析，不要本本主義，這就是本文最後的勸誡。

 

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/257598/viewspace-622749/，如需轉載，請註明出處，否則將追究法律責任。