美业SaaS的创业分享之[技术]:产品研发和架构在组织管理中的挑战

原文链接:https://mp.weixin.qq.com/s/Y1MCooXNVPdjbNEVTAWNwg

“万事俱备，只差一个程序员”。

这是一篇从技术、研发角度来分析美业SaaS的文章。

我们在立项做美业SaaS的时候，国内的技术圈中刚好迎来一波热潮。什么前后端分离，restful接口，前端三驾马车，Vue.js全家桶，后台微服务架构springcloud的风靡，微服务架构体系等等，让人眼花缭乱。

窥一斑而见全豹，本文尽量不去从技术的细枝末节来谈美业SaaS，而是从技术选型、技术团队管理、架构体系等方面谈一谈。

美业SaaS是一个美业互联网+的行业，所以，我们接触过的大多数公司，可以粗放的分为两类。一种是美容体系里面搭建技术班子开始做系统，典型的案例就是类似于广州奈瑞儿、江西可诺丹婷、浙江静博士等知名连锁体系内孵化出来的技术班子。另外一种当然就是互联网团队发现美业需要用到店务系统，于是组建团队拉融资开始做，典型的案例就是深圳的美丽加，广州的一禾美云等。

做美业SaaS，从技术和产品上需要考虑的因素有哪些？很多不懂行的老板，大手一挥，招技术拉团队过来开干就行了。秉承着能实现能用就行的宗旨，哪儿那么多门门道道？毕竟这个东西本身也没多少技术含量。但最终，不少团队都前赴后继的迷失在这个没多少技术含量的东西上，要么烧钱融资，要么实业输血，最后一地鸡毛散场。

美业SaaS，无论和美业有多深的渊源，归根结底还是互联网产品，技术选型、项目管理、研发管理，很多东西都是和公司的全盘战略息息相关，每一个看似不重要的决策和举动。对后期的营销、战略具有不可忽视的重大影响和决策作用。

一、技术选型的重要性
我们见过好几个美业SaaS产品，到目前为止深陷泥潭，面临艰难转型中。其中有些就是技术选型的问题导致的后续根本无以为继，我曾经打开厦门一家竞品的公司招聘信息，要招聘Delphi开发工程师。那么看到这个，我就知道他们一定要再招一个叫做实施工程师这样的一个岗位。因为Delphi是很久以前类似于VB这种用于开发桌面应用程序的语言，开发的也是需要安装的桌面应用，那就肯定需要实施工程师上门安装和维护了。这自然就意味着人力成本的居高不下，以及面临产品的艰难更新和换代。

技术选型有多重要呢，举个例子。我们接触了一个做美业SaaS的团队，初衷是自身的美业连锁门店经营多年之后，决定进入信息化时代，自己组建团队开发了一套系统。用的过程中随着时间推移，系统已经逐步完善和适应门店的日常经营和管理。于是老板决定投入经费将自己的系统进行完善和包装，开始推向市场。

此时技术人员就面临两难选择。因为SaaS是多租户共享的数据体系，在早期建表、分库时候就要开始考虑多租户的情况，但是这套系统因为是给自己内部专属定制的，压根不存在多租户的概念和模式。就像一栋房子，一开始建的初衷就是为了给自己住，后来自己住着舒服要给同行住。在外行人看起来就是开个账号这么简单，但实际上，如何保障数据的独立性、私密性，安全性，以及相互之间的互不影响，这些都需要在架构初期考虑进去。而不是突然哪一天独栋别墅要改成单位宿舍这么简单，这些，对于不懂技术的老板来说，尤其是软件这种虚拟商品，貌似就是复制粘贴的一件事情，没有任何成本。但对于技术人员来说，就是一场噩梦。这种定制化的系统要给到市面上第三方用户使用，只能给每个客户独立部署一套系统。部署的越多，运营和维护的成本越高。随着用户越多，占用的资源越多，服务器、带宽、人工都会开始暴涨，此时老板才会意识到这是个问题。

当然我只是举了一个比较具有代表性且比较极端的技术选型失策的案例，严格意义上来讲，这是个技术架构问题。这种问题，在任何一个有一点点互联网基因的公司里都不会发生，但是这种问题，在传统美业老板为主导的公司里，并不少见。

二、技术选型的考虑因素
做美业SaaS的技术选型，老板大多数是不关心技术选型的。只要能实现，谁知道你用的什么技术，什么方案。只要别出问题，别搞出麻烦。客户用的爽，成本越低越好。但是对于管理者，尤其是技术选型的负责人，需要考虑的问题就比较多了。

首先从宏观上来说就是产品形态的选择，美业SaaS是一种联网服务，随着浏览器技术和web技术的日新月异，传统的C/S架构的大部分软件都已经被逐渐淘汰(当然除了微信QQ这种高频刚需且具有强大的研发实力的产品)，大多数SaaS主流的形式都是B/S架构，这种架构的好处也非常明显。第一就是成本低，这个成本主要体现在开发人员的招聘成本低和客户使用的成本低。

举个例子，如果我们要做安装版的产品，至少要招多个会C++或VB或QT的开发人员，最低起薪15K起步。而且安装版的开发周期至少是Web版的几倍不止，这意味着真金白银的人力和时间投入，安装版除了开发周期长之外，还需要运维人员上门帮助实体门店安装，如果遇到门店的电脑重装系统了、换电脑了，都会面临着维护成本的飙升，光是开发和售后，就是巨大的人力成本。所以，基本上，目前的美业SaaS市场，除了历史包袱等原因，当前的SaaS服务商，都会采取BS架构体系。

其次就是在BS体系下的技术选型，即便如此，也会有很多的琳琅满目的技术和工具摆在我们面前。但是对于决策者来说，一定要清楚，技术选型不能简单的只看能不能实现，或者快速开发迭代交付即可。

技术是有生态的，在进行技术选型时候，这个技术栈的生态是否完善，关系着后续的可持续发展。很多负责技术选型的人，首先当然考虑的是自己熟悉的技术体系，这些无可厚非。但是在后续的维护和招聘时候，就会遇到各种各样的问题。

因为阿里巴巴的强大，阿里系出来创业的人将Java语言和生态逐步形成了国内最完善的技术体系。所以，在招聘网站上我们会发现招Java开发工程师特别好招，而且后续的大数据分析和更深层次的人工智能等等技术都能够无缝对接。但是如果选择了PHP、asp.net等语言，就会面临招聘时候没有Java那么容易的问题，这个不用抬杠。打开boss直聘用企业招聘账号看，就能够感受得到这个来自Java的热情和小众语言的冷淡。

同样，对于求职者来说，当大家都知道阿里等大公司都以Java为主流开发栈时候，也会优先考虑找一份容易找工作且不那么冷门的语言和体系进行发展。所以如果我们在技术选型的时候，用的并不是市面上热门或主流的技术体系，无形之中就给自己增加了招聘成本，也降低了公司岗位对技术人才的吸引程度。

几年前，国内Vue.js还没有那么全面开花的时候，我们招聘一名前端工程师，待遇和薪资其实和市面上没有太大区别，但是吸引了很多优秀人才过来，主要原因大多都是在原有的岗位上用的都是jQuery之类陈旧的技术，希望能够在我们这个岗位上提升和实战vue.js

Java只是我举的一个案例，我们也接触过有些选型用Python做的很好的产品。技术是一个日新月异的行业，雷军上大学时候用的是DOS编程，我们上大学时候用的是WindowsMFC编程，现在已经升级换代到了go语言和Python、Java的时代。

技术选型，选的不是一个技术，而是一个生态。围绕着这个生态存在的技术语言、工具、文档、从业者不断的形成正向推动，才能让这个生态更百花齐放，就像操作系统一样，以中国目前的实力，完全有能力造一个牛逼的操作系统，但是真正难的是什么，是生态，如何让更多人接受和使用，让更多从业者在这个系统上开发、盈利，可持续发展。

所以如果我们做一个互联网产品而不去考虑技术选型，那等于缘木求鱼。最后只能在枯竭的生态中艰难跋涉。

在技术选型上，我认为曾经开创了美业信息化时代的美业邦是非常具有战略眼光的，即使今时今日，美业邦倒闭了我也依然这样觉得，从产品角度上来说，他们当时主打iPad版本，就是一件非常明智的选择。第一，iPad版本原生的体验，是web版和手机APP版完全无法达到的。第二，当时iPad就两个尺寸，9.7寸和7.9寸。在适配上根本不存在任何问题。不像web版本，需要去适配各种尺寸的电脑显示器。第三，美业邦首创了平板电子签名，彻底杜绝了连接硬件过程中的驱动等第三方系统和插件问题。完美的扬长避短，既提升了产品体验，又杜绝了大量的售后和不稳定因素。所以，直到美业邦被爆雷之后，官方指定推荐将客户迁移到博卡，依旧有很多客户舍不得换系统。

三、项目管理者面临的问题和挑战
美业SaaS是租赁式服务。按年收年费，每年进行续费，所以本质上，就是卖系统，对于大型连锁机构来说，我一年要交的费用也不菲，能不能直接把源代码买过来，自己找个人来维护下？而且对于连锁机构来说，他也不放心将数据放在SaaS服务商的数据库中。

大客户的需求就来了：能不能卖代码？

大多数的美业SaaS服务商当然不乐意卖代码。毕竟是投入了数年的人力物力资源去开发的，多少钱卖掉合适呢？贵了没人买，便宜了不划算。但需求还是存在的，此时就出现了部分技术人员把代码私下出售的情况。（美业邦倒闭后，好几家美业SaaS突然冒出来，产品跟美业邦一模一样就改了个名字）

对于项目负责人来说，如何保障公司资产安全？这是个问题。而且这个问题对于很多美业SaaS公司来说基本是无解的。大公司如华为等，都有自己的内网，有完善的保密机制。而很多小公司的产品，比如一个商城、一个社交工具，颇具价值的并非代码，而是运营和品牌。而美业SaaS，本身就是个工具。工具在没有形成规模之前，最具有价值的就是这套代码，用这套工具的人都想拿到这套代码去修改成和自己最匹配的模式。项目负责人如何去保障代码不被入职三天的人顺走拿到竞争对手那里去卖？就拿最常见的案例来说吧，一个新人招进来，你不安排做事也不行，安排做事吧就要给代码，干了三天留不住，代码不像工厂的机器搬不走，他可以将代码随手打个包压缩丢到网盘或QQ就带走了，这些都是实实在在管理者面前的问题。

有人说保密协议。傻子都知道，保密协议也只是个防君子不防小人的协议，大公司有专门的法务部和竞业协议。而大多数美业SaaS公司，都是小公司，这种协议，说实在的，能够起到多大作用？

在传统的软件研发中，所有人共同开发一个项目，那么每个人都要有一份这个完整的代码，否则就无法编译通过，每个人修改完毕然后通过svn等代码管理工具进行代码合并和汇总，此时，如果有新人入职，就需要给他开通一个SVN账号，他就有权限获取整个代码。如果这个人干了三天不干了，就有带走代码和数据的风险！

所以，这里又提到技术圈风靡一时的微服务架构，每个技术的出现和风靡，都是为了更好的解决之前无法更好解决的问题。微服务的出现，就做出了很好的拆分，技术层面的好处和优势，我们不去多讲，网上一搜一大把，我们从管理的角度来说，微服务的架构体系，解决了什么问题？微服务是采用了搭积木的方式，每个人只负责跟自己相关的工程，比如有人负责支付，那么他就只负责支付整个链路的开发，他甚至不用管在哪个地方付钱了，为什么付钱了，因为这些都是业务层关注的问题，他只需要关注自己的服务是否正常稳定即可。那么核心的微服务交给授信度最高的研发人员（比如主管、组长等相对可信度高一些的开发人员）而新员工，基层员工，可以负责一些外围非核心开发，这样基本上就能够解决大部分代码的安全性问题。

凭心而论，美业SaaS的产品架构和研发，本身不具有太大的技术挑战性。因为毕竟是一个垂直领域的SaaS产品，不会出现C端常见的高并发和海量数据。但是最大的挑战就是来自于行业熟悉度和报表。垂直领域的B端产品，没有绝对的标准。你之蜜糖我之砒霜，每个人都有自己的理解和想法，所以在做的过程中会出现很多冲突和抉择。而技术上最大的考验，还是报表。B端的使用者，会有各种身份和侧重点，财务出身的管理者要看的内容，和业务出身的人看的内容绝不会一样，而服务人员和店长经理看的内容，又不一样。

报表要解决三个问题，一是普适性，二是准确性，三是时效性。如何让报表能够在众口难调中准确、稳定、快速统计出来，且不出纰漏，是一个不小的挑战。很多人认为报表嘛，不就是统计一下嘛，只要MySQL的select玩得转，so easy啊。

但是真正下沉到业务中，每个问题都有不小的挑战。首先是普适性，每个人关注的点都不一样，一张表要统计的纬度应该从哪些地方开始才能满足大众化的需求？这个是对产品经理业务能力的考验。

第二是准确性，报表的准确性不在于运算，而在于定义。京东淘宝上一年消费多少，非常容易统计，看你一年支付多少钱退款多少钱就行了。但是在B端，就没那么容易了。会员删掉了算不算呢、门店禁用了算不算呢、品项禁用了算不算呢、提成百分比改了没、充卡算不算、现金算不算、现金退掉的算不算、员工自提算不算、折旧算不算、会员跑到其他门店去消费了算不算呢、活动期间和平时的算法又不一样了种种因素汇聚在一起，最终，门店还经常操作出现失误和手误，失之毫厘谬以千里，如何确保报表最终数据是“对”的，并不是一个技术活儿。更多的，是一个系统化的工程。

第三个是时效性。了解MySQL的人都知道，MySQL语句越长，连表查询越多，资源占用越高，而一旦CPU飙高，就直接导致系统雪崩。相当于拒绝服务。在我们早期的报表中，因为要呈现的内容既有员工会员门店又有品项业绩消耗，最终导致一张表的SQL语句充满了各种查询，甚至长达4-5千行。慢查询达到了几十秒。而此时用户看见界面上没反应，就会狂点一通。导致数据库的CPU持续飙升最终系统down掉。所以，select实时查询当然能够解决问题，但是一旦数据量开始上来，系统很快就会陷入瓶颈。此时很多公司就会采用历史缓存，比如凌晨夜深人静时候算好数据，第二天直接展示算好的数据。这样就不会把CPU拉高，但是这样又会让客户抱怨数据没有实时更新没有时效性。所以必须要做离线+实时双模式。

很多东西，看似简单，实则真正下沉去做，就会发现没有那么简单。少年时，看到有句话说“韩信点兵，多多益善”，不以为然，带兵打仗嘛，当然人多好办事，给我一百万军队，我也能分分钟取西蜀定南蛮。但是人成长之后，再来看这句话，才深知不易。一百万人，先不说如何发号施令做到令行禁止，光百万人吃饭喝水上厕所随便一件事情都是个大工程。更别提带领这一百万人征战四方了。

美业SaaS产品研发和团队的管理，因为具有强烈的行业特性，所以很多事情需要因地制宜，不能生搬硬套，千万不能看了三天产品经理手册，就头脑一热下决定，体现在产品上就是千疮百孔和不能自圆其说的问题。

美业SaaS的研发，难吗？真的不难。但是想要做好，真的太难。所以目前为止，中国没有一家做美业SaaS的能够独步江湖，这是一片待开采的领域。2018年美业邦倒闭，2019年大量的美业SaaS开始停止更新，逐步转行。一禾美云叶沙野曾提出“美业SaaS是一个伪命题”的说法。美业的分散、非标准化，中国付费意识的淡薄，都是阻碍美业SaaS发展的大山。没有人能够拨开眼前的迷雾，登上辉煌的顶峰。

但谁知道呢，沉舟侧畔千帆过，病树前头万木春。