SaaS 全稱是 Software as a service，軟件即服務 ，當用戶需要這個產品時，可以在網絡環境下隨時租用，而不需要承擔更多的開發成本和人力成本等。這就是初期 SaaS 產品帶給用戶的工具屬性的價值。
做事有原則的人，更容易被人信任；做產品有原則，更容易減少部門內耗，超脫情緒和環境的影響，自覺選擇最佳方案。 我們來看一看 SaaS 軟件設計時的原則。
01
我們先看看看產品需求階段的原則。
原則一：產品需求階段首先要考慮到產品使用場景， 滿足用戶需求
B端產品基本上是將「線下已有需求」系統化，迴歸場景是一切的基礎。 「不以用戶場景為基礎的設計都是耍流氓」，深以為然，產品經理在設計原型時，要考慮的重要因素之一就是「用戶場景」，甚至在拿到一個需求的第一時間，就需要在腦海中思考用戶在不同場景下的需求能否被滿足，該如何滿足，以此來進行需求的初步篩選，「場景思維」的重要性可見一斑。
現在我們部門溝通交流的過程中，除「需求」外，高頻出現的另一個詞就是「場景」了，在平時工作中，產品與研發夥伴對接需求時，也常常會被抓耳撓腮的研發大哥問到：你這個需求的場景是什麼？
對「場景」這個詞來做解釋的話，其實就是什麼「人」在什麼「時候」在什麼「地方」出於什麼「目的」做了「什麼事」。 場景是設計和驗證原型時最重要的依據，也是減少產品和開發矛盾的潤滑劑。
我們來想象一個畫面，一個上班快遲到的人在到達公司的時候打卡，這時候他一定不希望遲到，打卡操作越簡單越好。 這個畫面就是場景，也是在設計產品或驗證產品可用性時的重要參考依據，從整個產品宏觀來講是這樣，具體到單個的頁面也是這樣。
再來看看「完美工事」這款打卡的app，驗證這個產品設計就可以得到比較符合這個場景，打開程序直接就是打卡頁面，用戶操作非常簡單。
原則二：好的產品滿足用戶價值並帶來商業價值
你首先要知道你的用戶是誰，如果你不知道用戶是誰，就好像你是一個籃球運動員，你不知道籃筐在哪，你不知道要面向誰去做你的產品。
然後再思考能給用戶創造了什麼價值。B端軟件思考用戶價值的時候一定要從兩方面考慮，首先是給企業帶來什麼價值，比如提高效率，降低成本等等，還要考慮為決策人帶來什麼價值，比如是否能提升 KPI、話語權或者掌控力。
大家常說的用戶體驗並不是用戶價值，提升用戶體驗固然好，但是B端軟件核心是解決問題，是否能創造用戶價值，只有這樣才能帶來商業價值。
商業價值的判斷，第一個是盈利，第二個是持續的盈利，第三個是持續的更多的盈利，所以產品模式必須是持續正向增長的，需求理解->解決方案->客戶成功->客戶數量增長形成正循環。
02
產品設計階段有以下幾個原則：
1. 功能需要滿足所有角色核心場景下的需求
SaaS 產品要確保業務鏈路每個角色的核心場景都能跑通，如果有一個角色無法正常使用，那該功能就不算完整，會導致整個鏈路上的每個角色都沒法正常使用。
以「完美訪客」小程序舉例， 來訪用戶可以掃碼登記，管理員可以生成訪客碼，還可以添加子管理員協助來訪統計分析。 麻雀雖小，五臟俱全，雖然是一個簡單的程序，但是能滿足所有角色的使用。
2. 每個客戶都應該都獨立、個性化的
傳統軟件流程是把軟件賣給客戶，客戶自己要出錢部署，買服務器存儲，搭建網絡環境，還要用運維的人員。而 SaaS 軟件現這些都不用了，硬件由供應商自己出，放在公有云上，以服務的方式租給客戶，所以叫賣服務。SaaS 本質上是由賣軟件改成賣服務，幫助用戶降低成本。
但是客戶的使用的方式還應該是一樣的，每個客戶之間不應該有交集，還要適當的滿足企業個性化配置，對於大客戶可能還需要定製化開發。不過儘量的降低定製化開發比例，如何降低定製開發的比例，我認為還是取決於產品對行業的理解深度，產品本身的成熟度。
「完美工事」從開始就設立了微服務的軟件架構，把企業的個性化需求在微服務上實現，內部多用API的方式互通，不影響主產品的升級迭代。給一個企業做的定製化的功能，有時候還能同時提供給其他企業使用。
3. 低耦合，高內聚
低耦合：指產品結構內不同模塊間的聯繫弱，關係簡單。修改一個模塊不會影響到另一個模塊。
高內聚：指產品結構中單個模塊內各個元素聯繫緊密。簡單來說，就是一個模塊內的代碼只完成一個任務，即單一責任原則。
低耦合，高內聚會給產品帶來什麼好處呢？
從短期來看，並不會給產品帶來明顯的好處，甚至會使開發週期變得更長。但隨著產品迭代，你會遇到更多複雜的需求。如果產品耦合度高，則牽一髮而動全身，輕易不能改動功能，因為會牽涉到產品架構層面的問題。
Saas是把賣軟件變為賣服務，放棄一次性收入，按照客戶是否使用來收費，就必須把軟件產品真正做到客戶喜歡，持續滿足絕大數客戶需求，SaaS 產品結構及呈現方式必須可延續、可擴展。而低耦合，高內聚會給產品帶來更好的擴展性，靈活性，複用性，可維護性。建議在產品開始設計時考慮好產品未來的長期規劃，避免後期產品難以迭代，需要重構。多和架構師溝通，防患於未然的同時，留給未來更多可能。
4. 權限控制儘量細緻
SaaS的產品業務相對複雜，面對的企業客戶規模和業務方向都不同，權限訴求也不一樣，根據不同公司業務權限設計需要設計的儘量細緻。
處理權限是一個比較麻煩的事，設計階段如果沒有考慮好後期再改成本是非常大的。一個賬號在一個系統可能對應多個角色，部分產品可能還涉及到不同地區不同分公司。那麼根據業務需要在角色定義層或權限分配層，先確定好集團、地區屬性，再確定數據權限、菜單權限、功能權限等等。
權限控制方面可以參考一下RABC模型：基於角色的訪問控制。
RABC是Role-BasedAccess Control的英文縮寫，意思是基於角色的訪問控制。模型認為權限控制的過程可以抽象概括為：判斷Who是否可以對What進行How的訪問操作，即將權限問題轉換為Who、What、How的問題。Who、What、How構成了訪問權限三元組，Who，What，How分別對應著用戶，資源，操作。RABC的核心在於通過為用戶分配對應的角色進而將用戶與對應的操作聯繫起來，已實現用戶對資源的操作。
5. 產品要保持一致性，拒絕設置專業門檻
一致性包括視覺一致性、交互一致性、文案一致性、跨平臺一致性。
對用戶來說，一致性可以降低用戶學習成本，用戶在不同頁面之間不會感到陌生，提升用戶體驗，更容易展現獨特的品牌感、品質感。 對團隊來講，利用一套風格統一的視覺、交互組件能提升設計作品的一致性，團隊之間溝通對接也會更有效率，不會出現風格不統一的情況。
不要設置一些專業門檻，以文案舉例，之前看到過我們開發的產品有一處提示信息「企業id不能為」，雖然開發能看懂，但是我相信很多用戶都會不理解，這句話可以改成「企業不能為空」或者 「需要加入企業」等等。 類似的專業文案有很多，比如 PV 改成瀏覽量，UV改成用戶訪問量等等。
6. 按照優先級順序去迭代
無論在哪家公司，我相信技術資源都是非常緊張的，所以在進行需求排期時的溝通就非常重要了，可以按照下面的優先級去迭代。
- 我們先保證有穩定的功能，滿足所有角色使用，如果功能不能正常用了，其他任何都是扯淡；
- 是否有競品打動決策者的功能，能讓客戶轉用另一家產品的功能必然是好功能，就是很好的買單功能；
- 跟客戶收入直接掛鉤，客戶能用來增加營收、縮減成本的功能。哪怕別的地方做的一般，能給客戶省錢，客戶也是接受的；
- 是否提升軟件使用者的工作效率，用戶每天都在頻繁使用的產品功能，需要能高效操作，能少一步操作是一步；
- 是否易用，易用指的是別讓我思考，我看一眼就知道該怎麼操作，這一點利於商務對使用人培訓。這一點有時候不太好評判，開發難度可能也比較大，優先級排在後面了；
- 最後是好看，當你做了前面所有的， 如果有資源，儘量讓頁面好看，而不是一味追求好看。
03
產品研發階段也需要注意幾點原則。
（1）首先保證系統的穩定性新，增或定製功能，要最大程度避免系統改造和重構，能夠穩定迭代
對SaaS服務商來說，系統穩定性的保障一直是一個非常複雜的命題。通常情況下，業界比較優秀的服務商，系統穩定性一般能做到99.9%，相當於全年無休。系統不穩定對品牌口碑影響很大，還會直接帶來經濟損失。比如某盟就2020年2月23日出現刪庫事件導致系統幾乎癱瘓，數據到月底才逐步恢復，對客戶造成了很大的損失，對公司也造成了很大的影響。
這裡的關鍵是業務和技術層面，需要產品和技術共同努力。產品經理要有對業務邏輯的深入理解和未來業務的預判性，並且對業務產品的各個維度組成有抽象化能力。
可以從用戶維度、商業維度、需求場景、功能服務維度多去考慮；用戶上把 SaaS系統的幾類角色好好分析下，商業上把付費模式、增值模塊好好構思下，凡事多想一步，讓團隊各成員心裡有數，落地執行時多做少做心裡也有底，在把產品方案傳遞給技術研發時，整體架構上也便於預留擴展，做到系統的耦合或內聚的決策更加精確，業務模塊的複用性更好。
（2）技術架構上要考慮服務化、分層化、可配置化、自動化。還要要考慮架構高可用性、伸縮性、可維護性等。
- 高可用性即系統不依賴單點（一臺服務器掛了不至於影響業務系統，一臺數據庫當了不至於數據丟失，被非法攻擊了能很好地轉移）；
- 伸縮性，好的架構在用戶1萬時你能支撐業務，用戶突增至100萬時能否簡單加機器來解決等；
- 可維護性，隨著你業務的增加，技術複雜性增加，系統的自動化運維能否跟上，系統的發佈回滾，運行時的監控、日誌系統是否完善，自動預警和恢復，而不能簡單堆人維護。
04
最後總結下，本篇文章從需求、設計、開發三個階段闡述SaaS的幾個原則：
需求階段要多思考，注意使用場景和滿足用戶價值和商業價值；設計階段要考慮不同角色的場景和需求；注意客戶之間是獨立的個性的；產品功能模塊要低耦合、高內聚；權限控制儘量細緻，產品要保持一致性，不要有專業門檻；按照優先級順序迭代； 研發階段要和開發配合，保證系統穩定性和可擴展性。
一點小經驗分享給大家，祝願彼此都能打造成功的SaaS產品。歡迎關注，共同交流。
題圖來自 Unsplash，基於CC0協議。
閱讀更多 人人都是產品經理 的文章
