ONES 万事联合创始人 & CTO 冯斌：企业服务产品的探索实践

想看更多产品干货文章？推荐极客时间专栏《邱岳的产品手记》，一次订阅、永久阅读。即日起，戳此订阅立享以下两大福利：

福利一：原价 ¥58/45 期，极客时间新用户注册立减 ¥30

福利二：每邀请一位好友购买，你可获得18 元现金返现，多邀多得，上不封顶，随时提现（提现流程：极客时间服务号- 我的- 现金奖励提现）

近日， TGO 鲲鹏会广州分会会员、世纪互联交付中心总监李少春作为 TGO 线上分享第五季的嘉宾，以直播的形式向大家分享了数据中心基础与服务探讨。本文根据当天直播内容整理。更多精彩内容请关注公众号： TGO 鲲鹏会。

大家好，我是 ONES.AI 的 Co-Founder 兼 CTO 。之前在金山、网易工作过， 2011 年出来创业，现在负责 ONES 产品的技术工作。非常高兴能跟大家分享我们的项目 —— ONES ，我今天的主题是「企业服务产品的探索实践」。

ONES 主要是做项目管理的产品，下面我主要讲一下我关于行业情况、产品定位策略、跨越 PMF 阶段等方面的经验总结，内容分为三大部分：

• 企业服务从 0 到 1 的实践；
• ONES 万事产品背后的思考；
• 对企业服务的建议。

企业服务从 0 到 1 的实践

为什么做研发项目管理平台

2016 年，那时互联网 ToC 的机会越来越少，很多都是渗透实体经济，以软件为主体的商业机会其实越来越少。当时的比特币还没有现在这么贵、AlphaGo 刚刚赢了李世石。

因为当时 Slack 、 Atlassian 已经有了相当不错的估值，我们就想选一个以软件为主，能盈利的项目。我们发现尽管中国的互联网行业发展蓬勃，科技公司越来越追求产品研发的效率，但我们发现在国内竟然没有一款大家都用得比较好的研发项目管理工具。

我在金山工作的时候，内部用的是 trac ，但这个产品已经几年没有维护了，而且没有敏捷的概念，早就被时代抛弃了。而 redmine 和禅道，在界面、交互、功能等多方面上，都像是上个世纪的产品，不能满足当下研发团队的实际需求，业界的很多朋友都有过不同程度的吐槽。

于是，我们暂时把目标对准了 JIRA 。

从追平到超越

传闻世界 500 强企业里，80% 都用过 JIRA ，JIRA 的功能也非常的丰富。而我们在慢慢接触过一些客户后，也发现产品功能需要积木化、抽象化， 通过一些配置自定义去满足一个 / 多个行业的客户，这与 JIRA 是吻合的。

在基本追平 JIRA 的功能后，产品上线了。很多客户觉得产品能够满足他们的需求，我们也陆续签了不少的单子，但也有部分客户提出"我们用 JIRA 本来就用得不好，我们要的不止是一个中国版的 JIRA 。"

市场的眼睛是雪亮的，这是一个我们无法回避的问题。

其实，在我们看来，JIRA 虽然功能很丰富，但没有太多的思路，产品明显是野蛮生长的，相似的功能点也非常多，而且功能之间有相互依赖性。在很多这种例如 CRM 、ERP 、项目管理的软件里面都会有这些功能，交叉非常复杂。

举个例子，我们一般在做 C 端产品的时候，如果要满足用户的需求，就要给他一个最快最方便的路径。但在 JIRA 里实现同一个场景，你可以找到很多的方法去实现。在 C 端产品上，这并不是一件好事。

因此，除了在体验上做得更现代，我们在产品上跳出 JIRA 来进行思考。

JIRA 在很多情况下都是功能绕行，比如说很多地方需要引用任务列表，通常情况下任务列表需要可以支持过滤。JIRA 这个时候会建议你去专门的筛选器列表完成这个事情，中断体验。而我们采用的是就近原则，处理方式是在每个出现列表的地方尽量提供筛选器。

另外一个方面 JIRA 通常会用太过于 Geek 方式去解决问题，这样会影响其他非技术岗用户的使用体验，比如说明明可以提供比较好的图形筛选器界面，JIRA 是用写类似 SQL 语句的形式做任务的高级查询。

ONES 万事产品背后的思考

企业服务行业情况

在我们刚进入这个行业的时候，我们想的是做很酷的产品，像国外的公司一样，通过 SaaS 向 ToC 销售。但最终在我们收集信息、以及复盘销售情况后，我总结了以下几种情况：

1. 头部客户（ 大 KA ）产生了绝大部分收入；
2. 头部客户在收入上的贡献是 80% - 90% ；
3. 大客户会选择私有部署的方式，小团队愿意用 SaaS ，SaaS 的作用更多是 demo ；
4. ToB 产品的使用和传播方式决定了行业头部效应不明显。

企业服务的增长相对缓慢，会比 ToC 的项目慢很多，所以要做好长期作战的准备，从第一天起就要持续思考营收的问题。因为在企业服务上，先圈用户再收钱，非常危险。

同时，企业服务在 2017 年在普遍涨价。涨价的原因就是大家都聚焦在大客户这边，以及面对大客户的销售方式。

产品战略如何准备

首先 PMF 有一个定义：如果产品功能在同一场景、同一个行业上满足了 3 - 4 个客户，基本上后面还有 30 个客户在等着。

那么，为什么大家在做企业服务的时候，都会觉得 PMF 很重要？因为到达这个阶段后，整个销售的方式会变的完全不一样 —— 公司要计算做一个销售的订单，最终付出的时间成本是多少，人力成本是多少，能得出一个大概的公式。按这个公式，我们就可以扩张团队。

在我们做企业服务产品的时候，经常会碰到你的功能客户听不懂的情况。其实想要真的让客户觉得有用，并不是说用某些功能说给他听，而是告诉他整个行业真正的解决方案是怎么样的。

我们通常把功能比喻成乐高块，其实客户并不关心这个乐高块是什么样，他想要的是飞机火车，你能拼得出来，他就觉得这个产品好。如果功能抽象的好，你可组合出很多不同的场景。用尽量少的功能，拼出尽量多的解决方案，整体销售的效率其实也会得到优化。

所以从真正长远的角度来说，包括现在企业服务的龙头，其实大家都在比谁的乐高多。谁的乐高能拼出更多的飞机，谁的价值就会更大。如果要比竞争对手做的更好，在起初目标设定上就要做的更好。

如果这个目标设定没有东西可以参考，那就需要自己去摸索，所以一开始提炼出来的，不一定是对的，包括版本的迭代，其实都在验证方向的正确性。这方面需要不停的修正，才能使它的正确性、可行性慢慢提高。

企业服务的产品设计

企业服务的产品，基本都是功能密集型产品，需要通过快速迭代不停的去增加功能。因为要拼出很多不同的飞机，至少得有一定量的积木才行。所以我们需要尽量通过各种云基础设施、开源组件来提高我们的开发效率。

从企业服务产品的复杂度上来说，现在有很多功能可以相互组合。这个功能从一个点变成网之后会变得非常复杂了，所以需要招聘工具达人来做你的产品经理。同时，只有小客户才会比较关注设计和体验，大客户其实并没有那么关注。为了实现优秀的用户体验，你需要付出的工作量是非常大的，所以我们必须也要细心平衡。

对于企业服务的建议

企业服务的典型用户

我们从上图中可以看到，在体验方面，一线员工比较关注。但最后是否决定要购买服务，其实并不是一线员工说了算，而是中层管理者。他们真正在做的事情是管控整个全局，他们的要求只有一个 —— 你的积木能不能拼出我想要的飞机。

在表格中第三层的人，他们也许并不认识每一个一线的员工，也不知道一线正在开发的功能是什么，我们把这些层次的人称之为高层管理者。对于高层管理者来说，他们更多会关注总体情况。在决定是否要购买这个系统的时候，他们也有决定性话语权。

企业服务的移动端定位

对于一线员工来说，他们基本不用移动端。因为移动端的功能是整个系统的延伸，让你随时随地都可以工作。但随时随地工作不是大部分一线员工所希望的。中层管理者同样不会对移动端有很大需求，因为可能他们大部分时间都在办公桌工作。他们更关注如何给老板做报告，能不能让老板能直接看到。

但对于高层管理者来说，移动端是一个非常重要的产品。他可以是在手机上以各种方式看到系统里的数据。在这种情况下，高层管理者的需求就是：我每天都要看一次工作概况。所以移动端的需求更多是看完就走。

技术选型的建议

在技术选型方面，我想简单地提几个建议：

首先，因为要实现很多功能，就需要非常多的乐高积木，这些功能之间也是相互关联的。所以我觉得动态语言并不能胜任相关业务逻辑，强类型语言更加适合。ONES 使用的后端语言是 Golang ，而 Java 在招人、社区等各个方面仍然是很不错的选择。

其次，因为企业服务的产品是功能密集型的产品，所以我们依赖云服务，可以快速做出你需要的功能，但是一定不要忘记，你的客户他们要私有部署。

最后，对于一些传统公司来说，同时实施一个私有部署可能要 2 - 3 天，需要装很多东西， 用户手册也非常长。但对于我们来说文档就会非常短，所有东西都打包到一起， 用 Docker 来交付，无论是升级还是初装，都非常节省部署成本。

我们必须从一开始就要考虑开放 API ，因为对大 KA 来说，公司规模可能有 1000 人，会用到各种各样的系统。同时，开放 API 方面有个 Swagger ，会把文档生成各种语言的 API 访问接口以及自动化测试都全部都集中在一起管理，这个项目可以提高大家在 API 设计和对接方面的效率。

最后还是回到大客户对我们的要求 —— 功能要多，所以一个产品同时开发多个功能，是很容易出现的情况。如果我们用 GitFlow 功能分支的管理方式，就会非常合适。ONES 这边也是这样管理我们功能的开发。

这里要提到一点：因为我们的产品要求我们增加越来越多功能，对自动化测试是有一定要求的。当功能快速迭代后，很快就会到达无法人工回归的状态。这时候，自动化测试就会变成唯一覆盖整个版本的功能，确认有无问题的唯一手段。

这种并行开发也有一些问题，产品的同时活跃的分支会很多，合并起来就会很麻烦，所以在这个情况下其实是需要自己去衡量。在 DevOps 的基础设施，包括静态代码检查这块，我建议大家有时间就去优化。

今天分享的这些包括我的一些小建议，抛砖出来，希望大家有更好的一些意见，非常期待在这之后可以跟大家好好交流。