我理解的互聯網應用和企業應用開發

前段時間，我寫過一篇該主題的博客，但寫完了，我覺得還是沒有談到本質，這篇文章算是續篇。

互聯網應用(網站或app)，和企業應用的本質區別，應該從使用者談起。

互聯網是陌生使用者，網站對於他們來說是自助系統(類似于ATM取款機)，不需要、也不可能對他們強制培訓，比如使用者註冊。 所以它們要做得絕對的弱智化，儘量降低學習成本。

企業應用是公司員工，帶有強制性，而且上崗前、或系統上線前，一般都有培訓，比如工行櫃檯員工那個Windows用戶端的功能，比如存款，都是通過輸入「2397」調出的。 相對於互聯網應用，使用者體驗並不是優先考慮的。 但有一點會很重視，那就是便捷性，如快速鍵，因為這些應用一般都是運營系統，員工每天都是重複做那些事情，效率很關鍵。

特別提示，像淘寶網，前臺網站是互聯網應用，供買家使用產品、訂單模組屬於企業應用。

對於一家B2C電子商務公司，往往既有前臺的互聯網應用，也有後臺的業務系統。 因為前後台的高度耦合性，如前臺訂單提交和狀態，必須和後臺的訂單處理流程對應，導致專案很難外包給協力廠商軟體公司，互聯網公司一般都有自己的IT開發團隊。 將軟體分包，需要很高的專案管理水準：開發過程解耦+模組解耦。 目前，互聯網開發外包剛剛起步。

使用者行為驅動 vs 業務流程驅動

互聯網是使用者行為(意圖)驅動，帶有隨機性，而且不同的使用者有不同的流覽習慣。 比如我google東西時，一般會先打開上10個頁面，然後才一個個看。 再比如豆瓣網的書籍詳細頁：書籍評分、查看類似的書、查看書評、添加書評等，並沒有嚴格的邏輯或流程。 同一個書籍介面，書商(作者)、讀者、點評者，對該頁面的關注點都不一樣，就如同企業應用裡面的不同使用者角色，登錄到系統看到的介面不一樣。

而且，使用者查到該書後，他的流覽順序、下一步操作都有隨機性。 很可能因為網站速度慢，他點擊了關閉。

這樣的系統如何設計？ 核心原則：研究使用者進入該頁面的場景，在該場景下使用者的需求，以及在此需求下產生的行為。 比如購書網站，使用者從比價網進來，第一關注點是折扣和促銷；如果使用者是購買過程中不經意看到一本陌生書，那麼他會關注該書的目錄和評價；如果使用者已經在購物車添加了一本書，那麼他會看一下 「其他使用者還購買了...」。

其實，企業應用也是這樣，Use Case裡就特別強調了Business Scenarios(業務場景)。

因為企業應用一般是協作式系統，協作式系統涉及到協作流程，也就是工作流，比如訂單處理流程、病人應診流程。 當然了，也有很多模組是沒有流程的，如交電費(電力CRM)。 但它們基本上都可以抽象為表格+表單+流程。

互聯網使用者的行為習慣是自己練就的，而企業應用的使用者習慣，更多是培訓出來的。 互聯網使用者行為極不穩定，比如20歲的年輕人流覽網頁非常浮躁，到 30多歲就沉穩多了；在網頁臭長臭長的年代，滑鼠滾輪就被派上了用場。 而企業應用，介面操作一般是流程驅動，而流程可能上10年都是那樣，使用者操作相對比較穩定、線性。

介面原型 vs 領域模型

無論是互聯網應用還是企業應用，稍微複雜點，一般都會出架構圖，如部署圖（可能4+1架構視圖有點教條），如根據負載，一台伺服器只做批次處理(資料同步和發送郵件)，一台伺服器只做搜索查詢。

比較複雜的業務系統，我們傾向于在需求分析階段，開發用例圖、領域模型圖、序列圖。 當然，我也見過，很簡單的業務系統也畫一堆圖，然後被開發人員扔到垃圾堆裡，其實，一個excel功能需求表就可以解決。

對於互聯網應用，介面即需求，往往不需要給業務需求建模：領域模型圖和序列圖等基本上沒法用。 性能和可伸縮性等非功能需求，可以以功能清單歸納。

軟體過程

因為需求過程的成果物不同，傳統的那套軟體發展方法：從需求規格說明書到詳細設計，即使是RUP等反覆運算過程，也很難照搬。

互聯網進化快，使用者需求非常不穩定，它們往往都是在運營過程中改進；系統上線後，偏向于維護而不是反覆開發。 估計若干年都不會出現針對互聯網領域的業務元件庫，但在企業應用領域卻很普遍，比如SAP的NetWeaver裡針對行業的元件庫。

互聯網應用，一般均採用敏捷過程。 但這種敏捷過程，我們往往搬過來都很教條，如燃盡圖和每日站立會議。 其實它們解決的就是進度和溝通的，本質上也就是風險控制。 這些方法學層面的東西，在《職業經理人》課程裡面，都是常識：時間管理、溝通管理、團隊管理等等。

敏捷是一種理念，不是一種方法學，雖然最終要落實到方法學。 什麼叫川菜，什麼叫東北菜？ 一看就知道，但我們需要用辣椒和醬油來衡量嗎？

IT人員構成

做企業應用專案，一般有三種角色：技術、需求、管理。

技術：架構師、高級工程師、工程師、設計師

需求：需求分析師

管理：專案經理PM、技術經理TL

上面我忽視掉了建構管理和測試等角色。

對於互聯網專案，角色和上面差不多。

技術：也是架構師、高級工程師、工程師，但設計師普遍比做企業應用的強一個層次。 因為他需要處理介面風格、易用性、瀏覽器相容性、SEO等。

需求：產品經理+公司業務人員，可能還會配上使用者體驗專員(交互設計師)。

對於企業應用，偏向于分析性歸納思維(向內)，它只要求你抽象出的軟體，能夠match當前的業務；而互聯網應用，更多是偏向創造性思維(向外)，比如SNS網站的like、poke按鈕，極大活躍了使用者互動。

管理：專案經理PM，可能由產品經理PD擔當，看專案規模了。 可能還有技術經理TL，負責技術人員的績效管理。

兩種不同的人員構成，主要體現在需求人員上。 互聯網需求，是挖掘出來的；企業應用需求，是梳理出來的。 企業應用你可以做業務調研，但互聯網應用，你調研誰？ 像中國移動財大氣粗，可以花十分鐘做一次電話調查，但這往往是選擇題，選擇就意味著封閉。 像蘋果iOS中的視窗，並沒有關閉、最大化、捲軸，這些創造性功能，是不可能通過使用者訪談得到的。

技術架構

做企業應用的那一套，如Hibernate，我是不建議用在互聯網上的。 Hibernate解決領域模型的持久化很有效，而互聯網應用，偏向于頁面而不是領域模型。

另外，互聯網應用偏向于讀，而不是寫操作，這和企業應用是反過來的，Hibernate主要是解決持久化(寫)。

Hibernate的性能、級聯查詢，基本上在互聯網上很難有作為。

如果用JAVA，我傾向于Spring MVC+Spring JDBC，前臺做URLRewrite。 企業應用那種三層架構、五層架構，在互聯網開發上，一定要謹慎。

談到開發語言，可以選擇JAVA，這和. Net基本上沒啥差別，看你的團隊精通哪種了。 因為它們在團隊協作性方面都很強(靜態編譯型)，有強大的開發工具來規範團隊行為，對專案可維護性也很有益。

當然了，如果團隊不大，php應該是首選，因為它運算元據庫非常簡單、高效、靈活。 php優勢特別是在部署上面，因為互聯網應用部署非常頻繁，JAVA一部署就重啟app，原來session全部丟失，這絕不是一個小問題。

對於Ruby這類小眾語言，太過靈活，團隊一大，很容易失控。 我沒有在專案中實戰過，只是曾經研究、學習，不敢妄自發言。

好了，就寫到這裡。

這篇文章，我還沒有談到產品經理在內容建設方面的職責。 像電子商務網站，在內容這塊投入的人力成本，如產品圖片和文字等，僅次於開發。 產品經理在內容建設上，是一個綱領性角色。

這篇文章，只屬於啟發性，還談不上總結。 估計幾年後，會出現比較成熟的互聯網開發方法學。