編輯導語：美業(yè)SaaS即美業(yè)+互聯(lián)網(wǎng)行業(yè)，既然屬于互聯(lián)網(wǎng)產(chǎn)品，那么產(chǎn)品研發(fā)和架構就及其重要，本文為創(chuàng)業(yè)分享之技術篇，主要談了談產(chǎn)品研發(fā)和架構在組織管理中都有哪些挑戰(zhàn)。

“萬事俱備，只差一個程序員”。

這是一篇從技術、研發(fā)角度來分析美業(yè)SaaS的文章。

我們在立項做美業(yè)SaaS的時候，國內(nèi)的技術圈中剛好迎來一波熱潮。

什么前后端分離、restful接口、前端三駕馬車、Vue.js全家桶、后臺微服務架構springcloud的風靡、微服務架構體系等等，讓人眼花繚亂。

窺一斑而見全豹，本文盡量不去從技術的細枝末節(jié)來談美業(yè)SaaS，而是從技術選型、技術團隊管理、架構體系等方面談一談。

美業(yè)SaaS是一個美業(yè)互聯(lián)網(wǎng)+的行業(yè)，所以，我們接觸過的大多數(shù)公司，可以粗放的分為兩類：

一種是美容體系里面搭建技術班子開始做系統(tǒng)，典型的案例就是類似于廣州奈瑞兒、江西可諾丹婷、浙江靜博士等知名連鎖體系內(nèi)孵化出來的技術班子；

另外一種當然就是互聯(lián)網(wǎng)團隊發(fā)現(xiàn)美業(yè)需要用到店務系統(tǒng)，于是組建團隊拉融資開始做，典型的案例就是深圳的美麗加，廣州的一禾美云等。

做美業(yè)SaaS，從技術和產(chǎn)品上需要考慮的因素有哪些？

很多不懂行的老板，大手一揮，招技術拉團隊過來開干就行了。秉承著能實現(xiàn)能用就行的宗旨，哪兒那么多門門道道？

畢竟這個東西本身也沒多少技術含量。但最終，不少團隊都前赴后繼的迷失在這個沒多少技術含量的東西上，要么燒錢融資，要么實業(yè)輸血，最后一地雞毛散場。

美業(yè)SaaS，無論和美業(yè)有多深的淵源，歸根結(jié)底還是互聯(lián)網(wǎng)產(chǎn)品，技術選型、項目管理、研發(fā)管理，很多東西都是和公司的全盤戰(zhàn)略息息相關，每一個看似不重要的決策和舉動。

對后期的營銷、戰(zhàn)略具有不可忽視的重大影響和決策作用。

一、技術選型的重要性

我們見過好幾個美業(yè)SaaS產(chǎn)品，到目前為止深陷泥潭，面臨艱難轉(zhuǎn)型中。

其中有些就是技術選型的問題導致的后續(xù)根本無以為繼，我曾經(jīng)打開廈門一家競品的公司招聘信息，要招聘Delphi開發(fā)工程師。那么看到這個，我就知道他們一定要再招一個叫做實施工程師這樣的一個崗位。

因為Delphi是很久以前類似于VB這種用于開發(fā)桌面應用程序的語言，開發(fā)的也是需要安裝的桌面應用，那就肯定需要實施工程師上門安裝和維護了。

這自然就意味著人力成本的居高不下，以及面臨產(chǎn)品的艱難更新和換代。

技術選型有多重要呢，舉個例子。

我們接觸了一個做美業(yè)SaaS的團隊，初衷是自身的美業(yè)連鎖門店經(jīng)營多年之后，決定進入信息化時代，自己組建團隊開發(fā)了一套系統(tǒng)。

用的過程中隨著時間推移，系統(tǒng)已經(jīng)逐步完善和適應門店的日常經(jīng)營和管理，于是老板決定投入經(jīng)費將自己的系統(tǒng)進行完善和包裝，開始推向市場。

此時技術人員就面臨兩難選擇。因為SaaS是多租戶共享的數(shù)據(jù)體系，在早期建表、分庫時候就要開始考慮多租戶的情況，但是這套系統(tǒng)因為是給自己內(nèi)部專屬定制的，壓根不存在多租戶的概念和模式。

就像一棟房子，一開始建的初衷就是為了給自己住，后來自己住著舒服要給同行住。

在外行人看起來就是開個賬號這么簡單，但實際上，如何保障數(shù)據(jù)的獨立性、私密性、安全性，以及相互之間的互不影響，這些都需要在架構初期考慮進去。

而不是突然哪一天獨棟別墅要改成單位宿舍這么簡單，這些對于不懂技術的老板來說，尤其是軟件這種虛擬商品，貌似就是復制粘貼的一件事情，沒有任何成本。

但對于技術人員來說，就是一場噩夢。這種定制化的系統(tǒng)要給到市面上第三方用戶使用，只能給每個客戶獨立部署一套系統(tǒng)。

部署的越多，運營和維護的成本越高。隨著用戶越多，占用的資源越多，服務器、帶寬、人工都會開始暴漲，此時老板才會意識到這是個問題。

當然我只是舉了一個比較具有代表性且比較極端的技術選型失策的案例，嚴格意義上來講，這是個技術架構問題。

這種問題，在任何一個有一點點互聯(lián)網(wǎng)基因的公司里都不會發(fā)生，但是這種問題，在傳統(tǒng)美業(yè)老板為主導的公司里，并不少見。

二、技術選型的考慮因素

做美業(yè)SaaS的技術選型，老板大多數(shù)是不關心技術選型的。

只要能實現(xiàn)，誰知道你用的什么技術，什么方案；只要別出問題，別搞出麻煩。客戶用的爽，成本越低越好。但是對于管理者，尤其是技術選型的負責人，需要考慮的問題就比較多了。

首先從宏觀上來說就是產(chǎn)品形態(tài)的選擇，美業(yè)SaaS是一種聯(lián)網(wǎng)服務，隨著瀏覽器技術和web技術的日新月異，傳統(tǒng)的C/S架構的大部分軟件都已經(jīng)被逐漸淘汰（當然除了微信QQ這種高頻剛需且具有強大的研發(fā)實力的產(chǎn)品），大多數(shù)SaaS主流的形式都是B/S架構，這種架構的好處也非常明顯。

第一就是成本低，這個成本主要體現(xiàn)在開發(fā)人員的招聘成本低和客戶使用的成本低。

舉個例子：如果我們要做安裝版的產(chǎn)品，至少要招多個會C++或VB或QT的開發(fā)人員，最低起薪15K起步。

而且安裝版的開發(fā)周期至少是Web版的幾倍不止，這意味著真金白銀的人力和時間投入，安裝版除了開發(fā)周期長之外，還需要運維人員上門幫助實體門店安裝。如果遇到門店的電腦重裝系統(tǒng)了、換電腦了，都會面臨著維護成本的飆升，光是開發(fā)和售后，就是巨大的人力成本。

所以基本上，目前的美業(yè)SaaS市場，除了歷史包袱等原因，當前的SaaS服務商，都會采取BS架構體系。

其次就是在BS體系下的技術選型，即便如此，也會有很多的琳瑯滿目的技術和工具擺在我們面前。但是對于決策者來說，一定要清楚，技術選型不能簡單的只看能不能實現(xiàn)，或者快速開發(fā)迭代交付即可。

技術是有生態(tài)的，在進行技術選型時候，這個技術棧的生態(tài)是否完善，關系著后續(xù)的可持續(xù)發(fā)展。很多負責技術選型的人，首先當然考慮的是自己熟悉的技術體系，這些無可厚非。但是在后續(xù)的維護和招聘時候，就會遇到各種各樣的問題。

因為阿里巴巴的強大，阿里系出來創(chuàng)業(yè)的人將Java語言和生態(tài)逐步形成了國內(nèi)最完善的技術體系。

所以，在招聘網(wǎng)站上我們會發(fā)現(xiàn)招Java開發(fā)工程師特別好招，而且后續(xù)的大數(shù)據(jù)分析和更深層次的人工智能等等技術都能夠無縫對接。

但是如果選擇了PHP、asp.net等語言，就會面臨招聘時候沒有Java那么容易的問題，這個不用抬杠。打開boss直聘用企業(yè)招聘賬號看，就能夠感受得到這個來自Java的熱情和小眾語言的冷淡。

同樣，對于求職者來說，當大家都知道阿里等大公司都以Java為主流開發(fā)棧時候，也會優(yōu)先考慮找一份容易找工作且不那么冷門的語言和體系進行發(fā)展。

所以如果我們在技術選型的時候，用的并不是市面上熱門或主流的技術體系，無形之中就給自己增加了招聘成本，也降低了公司崗位對技術人才的吸引程度。

幾年前，國內(nèi)Vue.js還沒有那么全面開花的時候，我們招聘一名前端工程師，待遇和薪資其實和市面上沒有太大區(qū)別；但是吸引了很多優(yōu)秀人才過來，主要原因大多都是在原有的崗位上用的都是jQuery之類陳舊的技術，希望能夠在我們這個崗位上提升和實戰(zhàn)vue.js。

Java只是我舉的一個案例，我們也接觸過有些選型用Python做的很好的產(chǎn)品。

技術是一個日新月異的行業(yè)，雷軍上大學時候用的是DOS編程，我們上大學時候用的是WindowsMFC編程，現(xiàn)在已經(jīng)升級換代到了go語言和Python、Java的時代。

技術選型，選的不是一個技術，而是一個生態(tài)。

圍繞著這個生態(tài)存在的技術語言、工具、文檔、從業(yè)者不斷的形成正向推動，才能讓這個生態(tài)更百花齊放，就像操作系統(tǒng)一樣。

以中國目前的實力，完全有能力造一個牛逼的操作系統(tǒng)，但是真正難的是什么？

——是生態(tài)。

如何讓更多人接受和使用，讓更多從業(yè)者在這個系統(tǒng)上開發(fā)、盈利，可持續(xù)發(fā)展。

所以如果我們做一個互聯(lián)網(wǎng)產(chǎn)品而不去考慮技術選型，那等于緣木求魚，最后只能在枯竭的生態(tài)中艱難跋涉。

在技術選型上，我認為曾經(jīng)開創(chuàng)了美業(yè)信息化時代的美業(yè)邦是非常具有戰(zhàn)略眼光的，即使今時今日，美業(yè)邦倒閉了我也依然這樣覺得，從產(chǎn)品角度上來說，他們當時主打iPad版本，就是一件非常明智的選擇。

1. iPad版本原生的體驗，是web版和手機APP版完全無法達到的；
2. 當時iPad就兩個尺寸——9.7寸和7.9寸。在適配上根本不存在任何問題，不像web版本，需要去適配各種尺寸的電腦顯示器；
3. 美業(yè)邦首創(chuàng)了平板電子簽名，徹底杜絕了連接硬件過程中的驅(qū)動等第三方系統(tǒng)和插件問題。

完美的揚長避短，既提升了產(chǎn)品體驗，又杜絕了大量的售后和不穩(wěn)定因素。所以，直到美業(yè)邦被爆雷之后，官方指定推薦將客戶遷移到博卡，依舊有很多客戶舍不得換系統(tǒng)。

三、項目管理者面臨的問題和挑戰(zhàn)

美業(yè)SaaS是租賃式服務，按年收年費，每年進行續(xù)費。所以本質(zhì)上就是賣系統(tǒng)，對于大型連鎖機構來說，我一年要交的費用也不菲，能不能直接把源代碼買過來，自己找個人來維護下？

而且對于連鎖機構來說，他也不放心將數(shù)據(jù)放在SaaS服務商的數(shù)據(jù)庫中。

大客戶的需求就來了：能不能賣代碼？

大多數(shù)的美業(yè)SaaS服務商當然不樂意賣代碼，畢竟是投入了數(shù)年的人力物力資源去開發(fā)的，多少錢賣掉合適呢？

貴了沒人買，便宜了不劃算。

但需求還是存在的，此時就出現(xiàn)了部分技術人員把代碼私下出售的情況（美業(yè)邦倒閉后，好幾家美業(yè)SaaS突然冒出來，產(chǎn)品跟美業(yè)邦一模一樣就改了個名字）。

對于項目負責人來說，如何保障公司資產(chǎn)安全？

這是個問題，而且這個問題對于很多美業(yè)SaaS公司來說基本是無解的，大公司如華為等，都有自己的內(nèi)網(wǎng)，有完善的保密機制。

而很多小公司的產(chǎn)品，比如一個商城、一個社交工具，頗具價值的并非代碼，而是運營和品牌。而美業(yè)SaaS本身就是個工具，工具在沒有形成規(guī)模之前，最具有價值的就是這套代碼，用這套工具的人都想拿到這套代碼去修改成和自己最匹配的模式。

項目負責人如何去保障代碼不被入職三天的人順走拿到競爭對手那里去賣？

就拿最常見的案例來說吧：一個新人招進來，你不安排做事也不行，安排做事吧就要給代碼，干了三天留不住，代碼不像工廠的機器搬不走，他可以將代碼隨手打個包壓縮丟到網(wǎng)盤或QQ就帶走了，這些都是實實在在管理者面前的問題。

有人說保密協(xié)議，傻子都知道，保密協(xié)議也只是個防君子不防小人的協(xié)議，大公司有專門的法務部和競業(yè)協(xié)議。

而大多數(shù)美業(yè)SaaS公司，都是小公司，這種協(xié)議，說實在的，能夠起到多大作用？

在傳統(tǒng)的軟件研發(fā)中，所有人共同開發(fā)一個項目，那么每個人都要有一份這個完整的代碼，否則就無法編譯通過，每個人修改完畢然后通過svn等代碼管理工具進行代碼合并和匯總。

此時，如果有新人入職，就需要給他開通一個SVN賬號，他就有權限獲取整個代碼。如果這個人干了三天不干了，就有帶走代碼和數(shù)據(jù)的風險！

所以，這里又提到技術圈風靡一時的微服務架構，每個技術的出現(xiàn)和風靡，都是為了更好的解決之前無法更好解決的問題。

微服務的出現(xiàn)，就做出了很好的拆分，技術層面的好處和優(yōu)勢，我們不去多講，網(wǎng)上一搜一大把；我們從管理的角度來說，微服務的架構體系，解決了什么問題？

微服務是采用了搭積木的方式，每個人只負責跟自己相關的工程。比如有人負責支付，那么他就只負責支付整個鏈路的開發(fā)，他甚至不用管在哪個地方付錢了、為什么付錢了，因為這些都是業(yè)務層關注的問題，他只需要關注自己的服務是否正常穩(wěn)定即可。

那么核心的微服務交給授信度最高的研發(fā)人員（比如主管、組長等相對可信度高一些的開發(fā)人員）而新員工，基層員工，可以負責一些外圍非核心開發(fā)，這樣基本上就能夠解決大部分代碼的安全性問題。

憑心而論，美業(yè)SaaS的產(chǎn)品架構和研發(fā)，本身不具有太大的技術挑戰(zhàn)性。因為畢竟是一個垂直領域的SaaS產(chǎn)品，不會出現(xiàn)C端常見的高并發(fā)和海量數(shù)據(jù)，但是最大的挑戰(zhàn)就是來自于行業(yè)熟悉度和報表。

垂直領域的B端產(chǎn)品，沒有絕對的標準。

你之蜜糖我之砒霜，每個人都有自己的理解和想法，所以在做的過程中會出現(xiàn)很多沖突和抉擇。而技術上最大的考驗，還是報表。

B端的使用者，會有各種身份和側(cè)重點，財務出身的管理者要看的內(nèi)容，和業(yè)務出身的人看的內(nèi)容絕不會一樣，而服務人員和店長經(jīng)理看的內(nèi)容，又不一樣。

報表要解決三個問題：一是普適性、二是準確性、三是時效性，如何讓報表能夠在眾口難調(diào)中準確、穩(wěn)定、快速統(tǒng)計出來，且不出紕漏，是一個不小的挑戰(zhàn)。

1. 普適性

很多人認為報表嘛，不就是統(tǒng)計一下嘛，只要MySQL的select玩得轉(zhuǎn)，so easy啊。

但是真正下沉到業(yè)務中，每個問題都有不小的挑戰(zhàn)。首先是普適性，每個人關注的點都不一樣，一張表要統(tǒng)計的緯度應該從哪些地方開始才能滿足大眾化的需求？

這個是對產(chǎn)品經(jīng)理業(yè)務能力的考驗。

2. 準確性

報表的準確性不在于運算，而在于定義。京東淘寶上一年消費多少，非常容易統(tǒng)計，看你一年支付多少錢退款多少錢就行了。

但是在B端，就沒那么容易了。

會員刪掉了算不算呢？門店禁用了算不算呢？品項禁用了算不算呢？提成百分比改了沒？充卡算不算？現(xiàn)金算不算？現(xiàn)金退掉的算不算？員工自提算不算？折舊算不算？會員跑到其他門店去消費了算不算呢？

活動期間和平時的算法又不一樣了種種因素匯聚在一起，最終，門店還經(jīng)常操作出現(xiàn)失誤和手誤。失之毫厘謬以千里，如何確保報表最終數(shù)據(jù)是“對”的，并不是一個技術活兒。更多的，是一個系統(tǒng)化的工程。

3. 時效性

了解MySQL的人都知道，MySQL語句越長，連表查詢越多，資源占用越高，而一旦CPU飆高，就直接導致系統(tǒng)雪崩——相當于拒絕服務。

在我們早期的報表中，因為要呈現(xiàn)的內(nèi)容既有員工會員門店又有品項業(yè)績消耗，最終導致一張表的SQL語句充滿了各種查詢，甚至長達4-5千行，慢查詢達到了幾十秒。

而此時用戶看見界面上沒反應，就會狂點一通，導致數(shù)據(jù)庫的CPU持續(xù)飆升最終系統(tǒng)down掉。所以，select實時查詢當然能夠解決問題，但是一旦數(shù)據(jù)量開始上來，系統(tǒng)很快就會陷入瓶頸。

此時很多公司就會采用歷史緩存，比如凌晨夜深人靜時候算好數(shù)據(jù)，第二天直接展示算好的數(shù)據(jù)。這樣就不會把CPU拉高，但是這樣又會讓客戶抱怨數(shù)據(jù)沒有實時更新沒有時效性，所以必須要做離線+實時雙模式。

很多東西，看似簡單，實則真正下沉去做，就會發(fā)現(xiàn)沒有那么簡單。

少年時，看到有句話說“韓信點兵，多多益善”，不以為然，帶兵打仗嘛，當然人多好辦事，給我一百萬軍隊，我也能分分鐘取西蜀定南蠻。但是人成長之后，再來看這句話，才深知不易。

一百萬人，先不說如何發(fā)號施令做到令行禁止，光百萬人吃飯喝水上廁所隨便一件事情都是個大工程，更別提帶領這一百萬人征戰(zhàn)四方了。

美業(yè)SaaS產(chǎn)品研發(fā)和團隊的管理，因為具有強烈的行業(yè)特性，所以很多事情需要因地制宜，不能生搬硬套；千萬不能看了三天產(chǎn)品經(jīng)理手冊，就頭腦一熱下決定，體現(xiàn)在產(chǎn)品上就是千瘡百孔和不能自圓其說的問題。

美業(yè)SaaS的研發(fā)，難嗎？

不難，但是想要做好，真的太難。

所以目前為止，中國沒有一家做美業(yè)SaaS的能夠獨步江湖，這是一片待開采的領域。2018年美業(yè)邦倒閉、2019年大量的美業(yè)SaaS開始停止更新，逐步轉(zhuǎn)行。

一禾美云葉沙野曾提出“美業(yè)SaaS是一個偽命題”的說法，美業(yè)的分散、非標準化，中國付費意識的淡薄，都是阻礙美業(yè)SaaS發(fā)展的大山。沒有人能夠撥開眼前的迷霧，登上輝煌的頂峰。

但誰知道呢，沉舟側(cè)畔千帆過，病樹前頭萬木春。

本文由 @老居 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Pexels，基于 CC0 協(xié)議