PaaS的诅咒
一位朋友告诉我，不久前，某知名SaaS公司正式解散了PaaS项目组，并裁掉了相关团队。
要知道，该公司在去年才融资了几个亿，正是要大展拳脚的时候。推翻这样一个战略级项目，无疑是一个重大而又痛苦的决定。
但是，在我看来，这件事件并非个例。它反映了在“看起来很美”的背后，也隐藏着致命的诅咒。如果只看到其美好的一面，这样的裁员故事，未来还会重演。
一、绕不开的PaaS
只要是面向大客户的SaaS产品，都绕不开PaaS这个话题。
十几年前，我还在Oracle公司的时候，我们的项目就已经有很大一部分个性化需求，通过PaaS来交付。
效果当然立竿见影。
和全代码开发相比，PaaS不但可以快速满足客户需求，更重要的是可以节约大量二次开发成本。
和过去Oracle的PaaS相比，如今的PaaS平台不但更为易用，而且通过聚焦垂直赛道，满足个性化需求的能力大大增强。
一家头部SaaS公司的PaaS负责人告诉我：对于大部分企业，他们的SaaS产品能满足70%的通用需求，而剩余30%个性化需求，基本都能够通过PaaS的无代码、低代码能力完成交付。
这意味着，拥有成熟PaaS平台的SaaS公司，在交付效率和成本上都拥有着巨大优势，从而对竞争对手形成降维打击。
然而，PaaS这么美好，为什么知名SaaS公司还要主动放弃呢？
二、PaaS的诅咒
如果美好愿望变成不可承受之重，原因很可能在于我们过于关注美好的一面，而忽略了其背后巨大的风险。
1. 烧钱机器
Paas的美妙之处在于积木化、低成本的程序搭建能力。
为了尽可能多的降低开发成本，同时尽可能高的匹配用户需求，PaaS往往需要搭建一个强大而又复杂的功能架构。而强大能力的背后，则是巨大的投入。即便是在2007年就开始建设PaaS的Salesforce，在几年前仍然保持着4000人的PaaS团队。
这个规模甚至超过国内大部分SaaS公司。
除了强大的能力——和SAP、Oracle等传统软件不同——SaaS公司对PaaS的交互体验也有着更高的要求。
毕竟，只有让企业用户、合作伙伴都能够低成本的使用，PaaS的价值才能得到最大程度的挖掘。
而“高度复杂功能+高标准交互体验”，就必然导致PaaS系统的构建需要耗费大量资金——根据可靠消息，国内相对成熟的PaaS系统，耗资都在数亿以上。
这可能就是，该知名SaaS公司最终推翻PaaS项目的主要原因。
2. 改造风险
2014年，北森决定搭建PaaS平台。
然而他们很快发现，独立存在的PaaS平台价值不大，必须让SaaS在新的PaaS平台上重新“长出来”。
这是因为，最常见的个性化需求，往往不是在标准功能外新增一个独立表单或流程，而是对现有标准功能或流程的“二次改造”。
结果，北森顶着巨大的压力，将所有SaaS产品在PaaS平台上“重做”了一遍。用北森联合创始人纪伟国的话来说，“之后在生死边缘徘徊了好几年”。
造成这一局面的关键在于，2014年的北森SaaS已经不是一个简单的产品，而是一个包含招聘云、继任云、绩效云等多个模块的大型SaaS产品。
对于北森来说，这无异于打碎骨头，再重新拼起来。也就是说，越是成熟、庞大的SaaS产品，将底层改造为PaaS平台就越为困难。对于创业已经好几年的SaaS公司来说，这可能是一个巨大的风险。
那么，什么时候是最好的改造时机呢？
我觉得应该符合以下两个条件：
- 已经验证了PMF。
- 确认走大客户路线。
没有验证PMF，搭建PaaS可能是白费力气；如果还不确定走大客户路线，就没有建设PaaS的必要。
满足了这两个条件，越早建设往往就意味着越低的重构成本和风险。
3. 规模化陷阱
如果目标赛道不够大，比如某些行业垂直型SaaS，如果贸然投入PaaS，可能就会掉入规模化陷阱，即PaaS的投入不能得到合理的回报。
目前来看，PaaS建设比较成功的SaaS公司，都有几个特点：
- 产品线长，比如北森的产品涵盖了从人事、招聘到BI的完整HR模块。
- 覆盖行业广，比如纷享销客就重点覆盖了装备制造、快消品等八大行业。
- 建设早，比如北森在2014年就把PaaS平台作为战略目标。
这些特点使得SaaS公司有更大的机会获得回报。
这也意味着，后入场的SaaS公司——特别是所在行业已经有成熟PaaS平台的公司——需要更谨慎的衡量ROI。
4. 创新风险
在某种意义上来说，PaaS是SaaS的替代——对于交付人员来说，如果能用PaaS搭出一个60分的系统“应付”客户，又何必用10倍的时间和成本去交付一个100分的标准化功能呢？
这就导致了PaaS的终极风险：创新风险。即对SaaS功能的过度替代效应。
我注意到，凡是PaaS能力很强的公司，项目组的重要性都在逐步升高，而产品部的重要性则在逐步降低。
这就意味着，SaaS公司正在变成项目制公司。
虽然它的交付成本远低于传统软件公司，但也正在丧失作为一家SaaS公司最宝贵的东西：产品创新能力。比如，面对一个新需求，如果标准功能不满足，项目人员大概率会通过PaaS能力进行交付，而不是给产品部提交一个功能需求。
这就意味着，客户的需求无法传递到产品部，从而错失了产品化的潜在机会。
但实际上，SaaS标准功能的意义，远不止满足需求。在提升用户体验，以及沉淀最佳实践等方面，也具有不可替代的作用。
而用PaaS搭建的应用，往往追求60分原则——用户接受即可——这也导致它不如SaaS功能完美，后期维护的成本、风险也很高。
另外，PaaS能力足够强大以后，项目经理的重要性大大增强，成为“最懂客户的人”。
这当然是好事。但也意味着产品经理的重要性和专业性都大大弱化。我们曾经自嘲的“原型仔”，在未来可能成为更普遍的现象。
然而，项目经理的本职工作是交付项目，而不是产品迭代。其他部门又缺乏对一线场景的把握，那么未来，谁又来负责SaaS公司的产品创新呢？
三、不要盲目追逐PaaS
Paas不是SaaS成功的唯一路径。
对于以中小企业为主，或者专注于细分赛道的SaaS公司来说，打磨好行业解决方案，深挖专业护城河，才是优先级最高的工作。
更重要的是，一个细分行业不需要两家一样的企业。
良性的生态应该充满多样性。优秀的企业家，也不应该去做“别人已经做得足够好的事情”。
PaaS只是一种手段，真正重要的，是要把自己打磨成一家“不一样”的企业。
作者
王戴明，微信公众号：To B老人家，多年互联网产品与信息化管理经验。
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！