企业软件之殇

·

1 min read

  1. 动词

    未成年而死。

  2. 名词

    战死者。

笔者经历了两家打着云原生旗号的企业软件/解决方案公司,都是中途加入,项目都以解(失)散(败)告终。

云原生解决方案

NB 公司:一个传统的 IDC 小厂,想着借云原生的热度,进军企业软件市场。

在加入这个项目之前,笔者考取了 CKAD 认证,彼时对 K8s 相当着迷。先简要介绍一下这个项目背景:

基于 Rancher (换皮肤)的二次开发项目,名字叫:HCaaS ,在笔者加入这个团队之前,项目已经开发近两年了,除了 TL 之外,其它人之前都没接触过容器化,更别说 K8s 了,所以工作状态我称之为:带薪学习。人员配置如下:

  • 5个后端:包括 TL 和一个实习生

  • 2个前端

  • 1个测试

  • 1个产品:很有趣的一个人,只是不怎么懂技术

讲真,这是一家挺不错的公司,团队关系融洽,公司有自己的食堂,伙食也不错,笔者记得当时每周1、2、4 需要加班到晚上 9 点。

印象中,项目组做的几件比较重要的事情:

  • 集成 minio

  • 集成 harbor

  • 集成 prometheus

  • 集成 jenkins

  • 集成 spark operator

  • ……

团队的 K8s 测试环境节点不超过 10 个。笔者依稀记得当时公司有一套内部使用的平台,在各方斡旋下,都没有部署到 HCaaS 平台上。突然要改变用户习惯,确实不太容易。

因为团队新且小,接触的客户不多。印象中笔者接触过的厂家有:西南某水利水电局、某新能源出行公司,但全部止步于 poc 阶段。记得参与某新能源出行公司的 poc 会议时,对方负责人问我司团队规模时,售前回答是 30+ 人。事后我才知道,甲方爸爸们的担心:研发团队规模小,以后万一采购了我司的产口, 团队解散岂不尴尬,所以公司售前一般都会虚报研发团队规模。

由于迟迟未能盈利,在笔者加入团队半年后,公司高层要求 HCaaS 必须在三个月内实现盈利。顶着巨大的压力,TL 决定从私有化转战 SaaS,在不使用关系型数据库的情况下,监控、支付等全部 on K8s,后来还搭建了社区……前期靠着现金券吸引了一波高校羊毛党, 将 HCaaS 当作练手平台。但,还是未能实现盈利,最后的结局是:项目解散……

项目总结

事后我跟 TL 聊过这事,当时做 SaaS 也是逼不得已,实在没有办法,就闭着眼睛瞎做而已。现在想想:当时做云原生平台,互联网小公司可能就没有这类需求,用不上;稍大一点的公司,互联网企业,有自己的运维团队调研推进,而传统行业则相对保守,购买私有化部署平台时,恨不得你把全部代码都给过来,虽然他们未必看的懂,而且经常会要求驻场,钱少事多。

云原生大数据运维平台

DC 公司:原福报厂大数据团队高 P 创办的公司,号称要对标 CDH,项目名称之为 big 吧。笔者于近期得知:该项目已解散……

同样是想蹭云原生的热度,不同之处在于,团队初始研发人员,基本上完全不懂大数据,人员配置如下:

  • 1个前端:从隔壁团队借调的

  • 1个测试:测试也是借调的,实际情况平均人力投入大概 0.5 吧

  • 1个产品:完全不懂大数据……

后端开发人员变化较大,最初有的开发人员有 3 个: 公司初创牛马,其中两人实习期便已在 DC 。后来又陆续招了些人,又走了些人,以毕业生或实习生为主。主打一个便宜,但又不给予培养,这招人策略笔者也是完全看不懂。

技术设计

四字总结:乏善可陈。这么说吧,开源竞品,至少是在试图将复杂的事情简单化,架构设计很干净;big 做的,将复杂的事情进一步复杂化,做了更多事情,嗯,总结一下就是看起来还是很厉害的样子。笔者在 big 团队经历了从业以来,唯一一年,删除的代码要多于新增代码,读者可细细品味。

迭代

三周一个版本迭代的节奏。

理想:一周调研,一周开发,一周测试。

现实:上一个版本延期,当前版本要改上一个版本/更久以前某个版本的 bug,在还没有搞懂技术名词的情况下,要出技术设计方案。因为参与评定方案的大佬们也不太懂大数据,所以客观事实是:大部分情况下,所谓的技术评审,基本上也就走个流程而已。由于粗糙的调研与评审,技术实现可想而知。做过的需求,只修 bug,绝不给额外的时间重新梳理,更别提重构了。大佬们只要开发时间节点、deadline、插入新增需求。就这样,一个完美的恶性循环就诞生了。

开源

自打笔者加入 DC 公司就一直听说 big 项目要开源,说是为了融资的需要。因为准备开源这件事,还单独开了一个 repo,派专人写测试用例,目标是达到 50% 以上测试覆盖率。实际情况是所谓的测试用例代码都看不到断言,一切都是为了应付而已。直到笔者从 DC 离职,big 都未开源。借一位 DC 老员工的原话:真要开源,惨不忍睹……

PoC

笔者支持过至少 5 家公司的 poc,大部分以传统行业(如汽车制造业)、金融行业(如银行)为主。由于 big 没有做部署的适配和标准化,每次 poc 必定不顺利。神奇的是,甲方爸爸们都非常有耐心,笔者都感觉到不可思议。事后才知:所谓 poc,要签合同,但是,钱非常少,通常不到 10w。传统行业,项目审批、立项等流程慢,慢一些,不算什么,对甲方的对接人员来说,也有更多时间摸鱼。

项目总结

专业的事情,还是需要招专业的人来做。初期以实习生为主的阵容去做大数据运维底座,笔者仅从技术上分析,这是管理层大佬们的一次判断失误。做加法容易,做减法难,后期有大数据专家加入 big 团队,指出 big 在技术路线上的问题,但管理层大佬们给出的态度是:积重难返,骑虎难下。笔者曾自告奋勇兼任 PM,希冀于能扭转颓势,力有不逮,终未能如愿。好在笔者学到珍贵的一课:管理层的认知上限大概率是软件项目的上限。可惜的是,团队的伙伴们一度非常努力,可如果方向本就是错的,努力,又有什么意义呢?这是偏见,也是事后诸葛亮。

总结

企业软件,私有化部署,很容易衍生出各色各样个性化的订制需求,难以做成标品,最终结果可能就沦为一个个交付型的外包项目。话说回来,想做标品,就需要制定标准和规范,有自己的内核,这本身对设计就提出了很高的要求。企业软件,要先有饭吃,才能反哺研发,这是一个矛盾体。这两次企业软件的研发经历,目标客户均以传统行业为主,笔者能感受到,技术本身,对甲方爸爸们来说,并不是那么重要。一位知情人告诉我,在银行业,每年的研发投入都需要申报,不申报就浪费了。申报了,各个参与方还能从中抽点油水,至于技术好坏,用户体验,who care?

企业软件,路在何方,犹未可知。笔者经历过,也学到了,足够了

去爱,去生活,去受伤