# 企业软件之殇 殇 > 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? 企业软件，路在何方，犹未可知。笔者经历过，也学到了，足够了 > 去爱，去生活，去受伤