六問CIO，OA軟件選型產品化還是項目化?
由于工作的原因，5年以來筆者認識了許多CIO并成為了朋友。回顧筆者和他們認識的過程，幾乎都源于OA選型，這個過程中，筆者注意到一個有趣的現象：越是大型或特大型企業(yè)的CIO，在OA項目選型時越是謹慎。
在與這些信心十足的CIO的溝通中，筆者發(fā)現由于種種原因，與這些CIO們對于OA項目的哲學層面的本質很少有深入的思考，大多過于從技術角度的眼光去關注具體的功能或應用。同時，在眾多廠商關于OA的宣傳冊或者標書中，很多只是提供了根據自己理解的需求拼湊出來的功能特征細節(jié)要求，而組織發(fā)展的具體戰(zhàn)略與OA之間的關系、從管理角度對OA的要求等連只言片語都沒有。
第六問：如何認識產品和項目對自己的意義
事實上，CIO在OA方面只能有三種選擇，一是標準產品，二是個性化(項目化)開發(fā)，三是產品+局部定制。信息化程度、管理成熟度不同的客戶對OA的期望值是不同的，另外CIO的技術偏好會導致對需求的客觀性不足。
先認識一下產品：
產品化的OA從視覺上看到的只是包裝盒中的光盤、加密狗、印刷說明書(印刷品是批量的標志)、服務卡，但實際上它是一個復雜的商業(yè)系統(tǒng)，由需求流程、概念設計、構架設計、程序代碼、測試流程、銷售、實施交付、售后服務、升級服務等多種崗位專業(yè)人員協作構成的。
產品化有它的好處，也有它的不足。好處是意味著在你之前有無數用戶驗證了功能的適用性、性能的穩(wěn)定性，并且還可以持續(xù)升級，是成熟的象征，是與客戶的長期合作，如同婚姻。產品化還意味著高性價比，這是絕大部分客戶所關注的。產品化總得來說是低風險的。
由于用友致遠開創(chuàng)了OA的產品化格局，因此最近不少廠商都在宣稱自己是產品化。有CIO為此困惑，問及我如何識別，我告訴他很簡單，可以通過該廠商的網站來識別，產品化供應商能看到升級公告，沒有版本升級公告的則屬于李鬼。客戶可以從致遠的網站上的客服公告中看到我們是如何從2.1版花了近5年數萬個人工日一步步走到今天的。
產品化的不足是，不能一次滿足所有細節(jié)需求，客戶在選擇時需要對需求有所舍棄，另外產品化的升級節(jié)奏可能與你的需求的成長的速度之間的匹配是個問題，這就需要你在產品化廠商中選擇那些內部資源雄厚，流程順暢，支撐保障機制健全的廠商。
再看看項目：
項目是只有些代碼是為客戶量身定做，與此同時喪失了標準化升級的可能性的系統(tǒng)，其關鍵在后者而不是個性化代碼的多少。
其實大部分項目化供應商都恨不得一行代碼都不改就交付給另一個客戶，但局限于上一個客戶的個性化代碼的存在，使得他們不得不吃下自己為滿足一個客戶的需求代來的苦果。
項目化是高成本的，首先技術人員比實施人員成本高，你們要告誡客戶，如果優(yōu)質的程序員是價值昂貴的稀缺資源，客戶最好不要相信花1萬元就能作出個好項目。二是長周期的，短期趕出來的，不可能沒有問題，看看微軟這么偉大的公司還有不少bug呢。項目漫長的測試、優(yōu)化周期造成了高成本;三是供應商的商業(yè)模式造成的，如果是項目型的廠商，只能通過盡可能通過每一個項目的價格最大化回報來掙錢，因為他們沒有把握像產品化公司一樣通過客戶數量掙錢。
項目化是高風險的，從需求分析開始，到技術路線選型、構架的擴展性設計考慮、優(yōu)質高效的代碼實現、完善的測試，所有這些環(huán)節(jié)，都需要客戶和供應商雙方投入最頂尖的人力資源，才足以做到業(yè)界一流水平，悲慘的是，這根本不可能大面積出現這種理想情況，一個供應商只能有一個頂尖項目經理，他不可能在每一個項目上投入，而客戶方，更是稀缺能夠精通OA，具備戰(zhàn)略思維，又能細致深入把握需求、協調實施的PM(項目經理)，這種人月薪身價都在2萬以上的。所以我們不難理解為什么這么多OA的爛項目，說穿了，就是2-3流人員在瞎折騰。他們在我提到的這些環(huán)節(jié)中任何一個失誤都會讓客戶未來付出代價。
項目化最大的局限性是長期發(fā)展機制，如果沒有每年配套的充足的預算，你怎么可能長期要求供應商持續(xù)為你研究、優(yōu)化、升級?在技術日新月異的今天，沒有最好的，只有更好的。
中國式項目化是與客戶的短期合作，是一夜情模式。
比較了兩種模式之后，客戶無疑要作個決斷，大部分客戶會選產品化。有極少的客戶選擇項目化，但有一些客戶還是期望在購買時獲得承諾滿足產品化尚無法滿足的個性化需求。這種情況下，導致了第三種模式的出現——產品化+局部定制。
產品化+局部定制仍然會導致兩個結果，客戶的需求如果產品構架可以支持以擴展模塊的方式滿足，那么萬事大吉，如果產品化的技術構架不支持，客戶的需求如果要滿足，就只能以調整構架，犧牲升級來換取。A6的構架最早根本不支持，現在開始逐步支持到逐步成體系，這是一個漫長的接口的發(fā)育過程，需要漫長的實踐積累才能保證接口的成熟度。
我也曾經多次遇到客戶個性化需求的重壓，提出如果不滿足就不買或者不付余款之類的，我會客觀地與研發(fā)評估其需求實現屬于可升級型或不可升級型，成本有多大。如果屬于可升級型，我會坦率提出版本升級或付費局部定制成本問題，如果屬于不可升級型而用戶又堅持要這個功能，我會告知用戶我作的先決條件是客戶簽署一份“放棄升級的聲明”。有意思的是，這種魚和熊掌不可兼得的局面下，我們與所有的客戶都達成了一致——部分版本升級滿足、部分以不影響升級的局部定制滿足，部分舍棄。從而保持了系統(tǒng)的可升級性，因為從長遠看，升級所換來對全局性的價值遠遠多于局部的個性化滿足所帶來的價值。
由于項目的個性，實際上持續(xù)服務是不可能的。我曾經和一個CIO開玩笑，當他宣稱必須完全滿足需求的時候，我說，你只能選項目。另外一個問題是你有宗教信仰嗎? 他說他是黨員。我回答說:你最好選擇一個宗教，管他是佛教還是基督教，重要的是你要養(yǎng)成每天禱告的習慣，你要學會相信老天和神靈保佑你這些事情：項目文檔不要在2年后丟失、供應商項目經理不要離職、不要跳槽、不要考研究生、不要出國、不要開車超速出車禍或者游泳淹死……這些情況中任何一種發(fā)生，都將導致你不能享受到以前的服務水平;你不能期望一個對你項目代碼、構架需求毫不了解的家伙能夠給你高質量服務。
呵呵，想到這一切的可能性，他差點當即暈倒。
反觀產品，如此眾多的客戶不僅使得產品經受了個體完全無法達成的覆蓋性測試，這些測試中的bug反饋和需求反饋又進一步導致了產品加速完善。最重要的是使得我們的客服能夠形成版本知識庫，有了這樣的知識庫，我們幾乎能夠回答90%稀奇古怪的問題——其中大部分是IT環(huán)境問題(病毒、插件、IE版本、補丁沒有打之類的)，而且并不因個體人員的變動導致服務質量下降。致遠的客服不僅在積累知識，而且在學習和研究不同階段客戶的應用特點，早已經從被動客服(出了問題找客服)上升到了主動式客服。我們知道新客戶會遇到什么問題，在應用深化時能夠給客戶來自其他客戶應用的經驗參考，我們的主動式客服月刊就體現了這一點?？傊a品化讓我們見多識廣，知識庫讓我們專業(yè)化，眾多的客戶經驗讓我們從解決問題型上升到專家指導型。
這幾年來，約有15%的A6客戶是廢棄了原先的OA重新購買了A6，這是因為過去的OA的項目化導致了項目發(fā)育停滯——我常告訴客戶，項目化的驗收之日就是OA成長的死亡之日，只不過要1-2年才顯露出來.供應商撤離，客戶PM轉移到其他項目，對OA項目來說，無異于根須死亡，樹葉發(fā)黃凋零是遲早的事情。
產品化是中國大部分客戶能接受的長期發(fā)展保障機制，項目化要想長期保障，太貴了，你想想你是否玩得起!
