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是線上產品,它應該獲得更長的發布周期和更寬鬆的開發環境