1. 讓 UXD 成為最有價值的資產

評：UXD指用戶體驗設計，如果想做SAAS的話，忽視用戶體驗將是不可原諒的錯誤

2. 適應更改要求

如果說軟件開發中有什么必然性，那就是客戶端、顧客或產品所有者在完成所有設計、規劃、圖表和原型制作后，他們將更改項目的要求。大部分項目經理都經過傳統的培訓，限制更改是這種培訓的一部分；這可能會影響產品第一個官方版本的發行。

軟件開發的演變速度非常快，以至于在初始開發過程的整個生命周期中，您會發現核心項目管理方法會改變好幾次。因此，每個項目都應該準備好實現新的開發方法或者現有方法的后備方法 。

評：這時一條通用原則，無論是企業應用軟件還是SAAS軟件，應對變更是設計首先需要解決的問題，SAAS則對這方面的需求更為迫切，應對需求變更的手段一般分為兩種：使用工具、引擎；設計

工具和引擎：類似數據字典、規則引擎、業務流程工具等。

設計包括：領域驅動設計，設計模式，IOC，AOP等

3. 采用開放的標準

基 于 SaaS 的公司必須考慮采用開放標準，這樣在將來迭代時，與其他設備、平臺、服務和 Web 應用程序的兼容所需的代碼編寫工作將更少，也將獲得更多的用戶。采用 SaaS 應用程序的消費者將使他們能夠完成多項工作。

評：已經達成業界共識，OpenAPI是SaaS的方向

4. 設計之前做好線框

從功能的角度看，線框（wireframe） 只是軟件程序 UI 特定狀態的形象概念，如圖 4 所示。注意，不要設計細節。這樣做的目的是避免被設計元素轉移注意力，使關注點停留在業務功能方面。應用程序的業務工具確定了之后，設計團隊就可以接手了；但在美化軟件之前必須先設計好功能。

5. 為 SaaS 提供云基礎設施

首先，傻瓜都知道網絡基礎設施對 SaaS 影響巨大。但是，Web 上大部分 SaaS 應用程序運行的基礎設施硬件都不充足，無法根據需要擴展。作為開發人員，我們可以使用自擴展的云系統 —— 常常稱為 Infrastructure as a Service (IaaS)，但這種高級技術的推廣速度很慢。

該 技術的采用范圍不廣很大程度上是因為缺乏該主題的知識。例如，Amazon Elastic Compute Cloud (Amazon EC2) 可以給運行 SaaS 應用程序的公司帶來很多節省，但是對 Amazon Web Services (AWS) 基礎設施知識的缺乏使許多公司回退到遺留系統，因為那才是他們所了解的。但是，ISP 提供帶寬的不斷增長為成功 SaaS 應用程序提供了保證，自動根據需要擴展資源的 SaaS 應用程序需要更高的網絡性能。

6. 開始編寫代碼之前生成完整的設計文檔

評：敏捷設計，我們既不同意那些整天叫囂敏捷的狂熱分子，結對編程，寫了一遍又一遍，號稱代碼即設計（一般這種情況代碼都很爛），也不主張進行全面 的詳細設計，每個雷和方法屬性都要在編碼之前完成。我們推崇敏捷設計，設計一定要有，但要分迭代，設計范圍涉及核心框架，核心類和核心方法，敏捷設計覆蓋 系統的核心業務邏輯，通過設計可以進行業務表達，但并沒有設計開發中的所有細節。

7. 抱住單元測試不放

評：單元測試，重要性總是容易被忽視，在我們的產品中也是如此

8. 不要只見樹木不見森林

評：性能優化的二八原則，優先去做那些能夠大幅改善性能的工作，性能是SaaS應用的頭等大事

9. 學習其他成功的 SaaS 項目

從其他成功 SaaS 項目中學習最簡單的方法是首先挑選一個樂于使用的 SaaS 程序。然后，找兩個或三個所選軟件的競爭對手，然后試用一下，寫下吸引您注意的具體內容，以及為什么您喜歡或不喜歡某個應用程序。

10. 構建可用原型

在軟件開發中，顧客通常希望在投資實際開發之前先看到對概念的驗證。原型只是一個概念驗證。聰明的 SaaS 開發人員會利用創建原型的時間。想想這段時間能做多少工作：

• 設計并布局架構基礎。
• 通過構建定制 XML DTD 創建 SaaS 數據庫模式，并使用 XML 作為原型的數據源。（模式稍后可以導入數據庫引擎并在幾分鐘之后轉換為實際內容）.
• 創建完整大小應用程序的組織包、界面和類結構，即使這些文件的作用只是聲明最初實現的類名稱和接口。

評：這種方法的優點很多，但是有兩點對于 SaaS 的成功很關鍵：在構建實際產品時您已經領先很多；在此基礎上構建原型時往往能夠看到設計模式的沖突以及架構設計的不足。在實際開發產品之前 ，可以做必要的修改。

另外，SAAS應用與項目交付不同，SaaS是線上產品，它應該獲得更長的發布周期和更寬松的開發環境