1.前言

这是今年7月我在公司内部沙龙分享的一个话题。由于一些原因当时的分享视频未能保留下来，因此我就萌生了将当时分享的内容转化为一篇有关“工具平台开发实践”文章的想法，对当时现场分享中不尽如人意的地方进行调整，希望能用更全面，更直观，更浅显地内容给看到此文的你一些启发与帮助。

2. 个人介绍

在分享之前，我先对自己在公司内部的经历作一个介绍。我是自2015.8.24加入网易，至今已有5年多时间。期间我先后在易信、云信、猛犸以及现在的项目管理部效能工具团队工作过， 主要做的事情有：

• 易信：星币商城、看一看、运营平台，在线娃娃机开发。也就是在易信时期，我独自构思并开发实现了设计稿管理平台 D-BOX ，期间陆陆续续独自开发维护了4年有余，随着不断的版本迭代，D-BOX的功能也越来越趋于完善。先后为易信、智慧企业、游戏、教育、考拉、云音乐以及严选等提供服务，从WEB端，上传助手，sketch插件，开放接口等多种入口与能力为业务方的设计稿/需求稿管理保驾护航。直到最终因工作精力有限，才将接力棒交给了UEDC的开发同学，让他们继续完成让D-BOX发展壮大的使命，赋予她新的“生命”。
• 云信：音视频质量平台、音视频WebSDK以及在线教育全功能DEMO开发。也正是这段经历，让我对代码重构，技术选型有了更深的理解。
• 猛犸：负责猛犸主WEB平台的版本迭代与前端团队内部管理工作，期间接管了严选的数据指标管理系统。这段短暂的经历，让我在代码质量控制，架构演进上积累了宝贵经验。
• 项目管理部：我来到PMO就是为了创造 项目管理平台 EP 。眼看着她从0到1初长成，人员不断地扩充，内部产品的接入越来越多，产品的使用越来越频繁。我很开心能见证这整个过程，也希望未来能让EP进一步发展壮大，真正让她成为一个小而美的工具平台，实现PMO对她的期许。

3. 本文主要内容

上面讲了那么多，好了，言归正传。按照惯例，我先简单提一下这篇文章的整体结构，让大家对后面所说的内容有一个简要的了解。

本文主要从以下几个方面来介绍工具平台开发涉及的通用理论内容：

• 引子
• 论理论的重要性
• MVP
• 核心痛点提炼
• 关于技术选型
• 快速迭代可使用的工具
• 种子用户选定
• 运营管理
• 北极星指标
• 二八原则
• 连接上下游
• 数据化分析
• 数据增长
• 技术债与架构演进

在文末【附录】中有本文涉及的所有理论内容，大家可按需查阅。通用理论中的内容整体是按一个产品的生命周期来组织，各章节内容相对独立可直接跳过进行查看。

注：以下内容仅为我个人经验的总结，如若有讲的不好的地方还请大家多多见谅，也欢迎大家在文末评论交流，共同学习成长。

3.1 引子

在我开始正式介绍通用理论前，我想请大家思考一下下面这两个问题：

• 产品与工具的关系是怎样的？
• 怎么样的工具才算一个好工具？

几年前张小龙在“微信公开课”演讲时说过这样一句话，我想在这分享给大家：

“我们认为任何产品都只是一个工具，
对工具来说，好的工具就是应该最高效率的完成用户的目的，
然后尽快的离开。”

—— 张小龙

从张小龙的话中我们可以了解到，在他看来：

好工具的意义 = 用完就走

其实在那次演讲后，行业内对这些言语有过很多讨论。所以张小龙在下一年的演讲中，他又进一步解释道：

如果工具好用的话，用户还会回来！

这是一个小故事。我想透过这样一个故事传递给大家这样一个理念：

做好工具并不容易，要始终保持“与用户在一起”打磨产品的初心，
只有这样才能成就一个用户喜欢的好工具，好产品。
真正达到用户“用完就走”，“好用再回来”的境界!

3.2 论理论的重要性

正如《穷查理宝典》中芒格所说：准备做一件事前，我们必须对这件事足够了解，必须要拥有多种思维模型，从多种角度来看待事情本身。那么当开始做事时才更可能把它做好，有所回报。

芒格还提到一个重要概念叫做：“普世智慧”。

那在工具平台开发领域，什么才是对应的“普世智慧”呢? 

下面我就来为大家揭开她神秘的面纱吧~

3.3 MVP

想必大家都听过这样一个说法叫：从0到1，这个说法用产品领域的专业术语表达则是：MVP。

问：什么是MVP？
答：MVP用一句话表达就是：最简化可实行产品（Minimum Viable Product）！

从它的基本定义，我们可以了解到MVP有两个核心关键点：

• 最简化的
• 可实行的

“最简化的”是针对产品功能集来说的，而“可实行的”则是针对产品的可用性来说的。一个经过精简化处理，在保证核心业务功能可用下最简产品就是MVP的精髓所在。

虽说是“最简”，但它却是一个完整可用的产品。麻雀虽小，五脏俱全，它的“简”强调的最小成本。“可实行”意味着MVP也能跑通核心流程，它并不是断胳膊少腿的残疾人。

所以从做工具角度来看，在一个工具的前期我们需要关注的是 核心业务流程 以及让其 可用的最小成本方案 本身。只有这样才能为我们在后续工具版本迭代中，快速试错提供基础保障。

从概念模型实现为提供给用户正常可使用的具体功能，这中间还有两个关键步骤需要我们关注。它们与MVP一同为衡量工具对于用户的价值提供了统一的标准，让工具真正能沿“正确”的道路前进指明了方向。这两个关键步骤分别是：

• 测试与度量，数据收集
• 学习与迭代

工具的功能千千万，到底哪个才是用户真正所需要的呢？这个即使是经验丰富的产品经理想必也无法告诉大家答案。

那我们怎么来进行功能取舍呢？这里的解决方案就是：试错。

试错即代表需要我们提供多种功能方案，不断地尝试不同的功能方向。
通过度量，反馈，改进来持续优化调整功能，最终真正满足用户需求。

而试错常常意味着现在实现的功能可能会在未来被移除，因此这就需要我们保持以最小的成本来设计功能实现解决方案，保证可以 “快速”、“低成本” 的试错。

如果只有功能上线，没有用户使用功能的埋点数据，那么我们就如无头苍蝇般找不到改进方向。因此在试错功能开发的同时，我们还需要建立一套完整，可衡量功能价值的反馈系统。

一般来说，最小成本的反馈系统就是接入数据埋点系统。
通过页面PV，UV，用户使用功能的触发事件分布来了解用户，发现功能存在的潜在问题，从而有针对性的改进。

试错 -> 反馈 -> 改进，这样就构建了一个良性的反馈环，可有效地将核心人力投入到关键工作中去，从而提升工具对用户所产生的价值。

MVP的有效反馈环主要包含两个阶段：

• 用户探索阶段
• 用户验证阶段

顾名思义，这是两种不同的用户价值阶段，探索与验证相互交错编织了一张巨大的“用户价值网”。通过分析这两个阶段得到的用户反馈，便可有效抓住用户核心价值点，进而成功构建工具的价值。

有一本书叫《从0到1：开启商业与未来的秘密》，也推荐大家可以读一读。

3.4 核心痛点提炼

MVP的核心价值点即为用户痛点。痛点的基本定义为：

痛点（pain point ）: 当用户在使用产品或服务时候抱怨的、不满的、让人感到痛苦的接触点（touchpiont）。

一个工具价值的大小往往是由”核心痛点”为用户所解决问题的重要程度决定，因此这便要求我们根据用户遇到的问题来设计解决方案。

汽车大王亨利·福特曾说过:“如果我最初问消费者他们想要什么，他们会告诉我‘要一匹 更快的马!’”。而福特却从消费者回答中找到真正的用户痛点，最终为消费者创造了一辆更快的四轮汽车，从而使人们加速进入了汽车工业时代。

这里还有一个更极端的关于解决用户痛点的故事：

"有些人说，消费者想要什么就给他们什么，但那不是我的方式，
我的责任是提前一步搞清楚他们将来想要什么。"

—— 乔布斯

乔布斯的话从另一个角度来看，是“超用户心理预期”的满足用户诉求，解决用户的实际问题。因此核心痛点对应的解决方案必须是一个对于用户来说 超过预期 的，只有这样才能体现 核心价值。

3.5 关于技术选型

只要涉及技术实现，必然摆脱不了对于技术如何选型的考虑。内部工具在MVP的早期我推荐的技术选型思路如下：

• 最小解
• 简单
• 通用
• 轻量

1. 最小解

MVP阶段只求最小解是极其重要的。正如本文上面提到的MVP阶段最重要的事是通过反复试错来找到用户痛点，其中不可避免的导致部分功能在上线验证后因达不到预期而快速被砍下线。

在这个时期，最小解即可保持能快速地进行MVP试错验证，有利于工具迭代进程。相反地，我们应当极力避免在MVP阶段就在技术方案上追求“最优解”。

这样不仅技术实现成本高，而且有过度设计之嫌。如后续被无情砍掉或因工具方向调整，这些原本设想很美好的“最优解”就可能成为“技术债”，这么低的ROI（return on investment - 投资回报率）我想是技术团队不想看到的。

所以在这个维度上，技术人员要尽量克制自己，不要过分追求大而全。毕竟现阶段更多关注的是验证价值，在未来适当的时候再进行技术演进是一个更好的选择。

2. 简单

现如今各类技术更新换代极其频繁，在众多的技术框架中选择适合早期MVP开发的技术，这需要经验的积累与长远的眼光，在这点上我想强调的保持技术足够简单。

“简单”主要体现在两个方面：

• 简单开发
• 简单部署

从后端技术角度看，“简单”意味着能用单体应用解决的就绝不上分布式，能用单实例数据库支撑的就绝不上数据库读写分离，能用本地缓存解决的就绝不上像 memcache/redis 这样的缓存系统。

而从前端技术角度看，“简单”意味着保持开发与部署地简洁性。目前前端三大主流框架: React/Vue.js/AngularJS 都可以很好的满足业务对路由管理，组件化拆分，数据请求与存储，组件数据通信等需求。选择哪个前端框架完全是由开发团队人员的技术普遍性，易用性，可维护性角度综合考虑，选择一个最适合自己的框架进行业务开发即可。

框架之与团队只有最适合的，没有最好的。

很多考虑在前期都显得有点多余。静态资源上CDN，多静态资源域名，动效等这些属于有了更好的举措可以提高体验与性能，但似乎我们选错了时机。每增加一个机制所带来的复杂度往往不是单一的，这其中我们还得考虑叠加效应。始终保持简单，有利于聚焦。

当业务快速扩张，用户增长快，存量用户多时这些可以有针对性地考虑。但如果用户尚在非常小的量级，考虑这些只会增加无形成本，收益并不明显。

因为技术是为工具/产品服务的，选错方向的工具/产品业务，再好的技术也“无力回天”。

抓住重点后再逐步变得更好才是上上策，小步快跑重要性不言而喻

从“简单”方面我们应该清醒地认识到，工具所处的发展阶段决定了技术选型。

不是说永远不用更好的技术方案，只是应用这些方案所要解决的问题在当前阶段我们尚未遇到，现在就用上有点为时尚早。

每个阶段都有对应的技术瓶颈，只有真正分析过后，再选择适合的技术进行调整才能保证工具的发展。不要让过高的技术复杂度，维护成本过分地消耗技术人员的有限精力，让技术在前期保持“简单”尤为重要。

3. 通用

技术选型保持“简单”，我们很好理解，它是为了降低成本。而其实选择“通用”，也是为了降低成本。两者的差异主要在于:

• 简单降低的是 “当前” 的成本，
• 通用降低的是 “未来” 的成本。

通用性的技术可以保证未来进行技术架构演进时有一个很好的底子。

大家应该都听说过这样一个故事：

淘宝早期的系统是使用PHP开发的。当淘宝业务初具规模后，他们就决定将底层技术语言由PHP切换到JAVA。系统中的很多业务都需要逐步切换到新的语言与基础设施上去。这样做犹如在高速公路上更换汽车的四个轮子：“既要保持前进，还要保证安全与稳定”。最后淘宝的技术人员完成了这项极具挑战的工作，淘宝也在随后发展成为了电子商务2C领域的佼佼者。

从A到A’的成本是相对较小的，而从A到B的成本却是巨大的。 那为什么淘宝却选择了A到B，而非A到A’呢？我想其实有一个原因是由于技术的“通用”性。

一个通用的技术底子可以让你在未来的业务发展中，不断地向 A’， A’‘… 进行跃迁升级。但一个不够通用的技术底子，可能意味着技术需要从A到B，从B到C的不断变迁。

我想对于技术人员来说，应该没几个人愿意每发布几个版本后就进行一次翻天覆地的技术调整吧。那意味的不仅仅是成本，还有业务稳定性的巨大风险。

因此，为了降低未来的可见成本，我们还是尽量在前期就选择“通用”性的技术吧。

4. 轻量

最后一个技术选型的原则是：轻量。

轻量可以说是以上三个原则选择后的一个表现结果。当我们选择了最小解，简单以及通用的技术解决方案后，最终发现它往往也是轻量的。

如同软件架构中常见的一种说法：

好的软件架构往往是清晰的，有层次的，极具美感的。
而不好的软件架构往往是混乱的，层次不明的，丑陋臃肿的。

保持轻量，轻量，再轻量是MVP阶段技术选型的重中之重。

3.6 快速迭代可使用的工具

做任何一件事，选好工具往往都是一个重要环节。

工欲善其事，必先利其器，说的就是准备好工具的重要性。

随着公司对内部基础设施的建设越来越重视，近几年来内部也诞生了非常多好用的工具。

下面我就介绍几款对于工具开发极其有用的服务：

• OpenID
• NOS
• 哨兵及消息中心
• CMDB及NDP
• Overmind

1. OpenID

OpenID 是公司内部一款接入极其方便，使用广泛的用户认证服务。几乎内部的全部服务均使用它来完成用户认证。

它帮助我们简化了用户认证的过程，为我们提供了多种公司内支持的账号系统，以及内外网的认证方式配置，员工信息获取等功能。

因为有了OpenID，我们可以更加专注于工具内的业务功能，而不必再为用户认证浪费宝贵的精力。

从OpenID用户认证开始，就已经让我们的工具可以快人一步了。

不过有几个额外点，我在这里多说一句。

• OpenID认证后获取的昵称默认为邮箱前缀，但不同域的邮箱账号，前缀规则不同(corp邮箱为普通前缀，mesg.corp邮箱则为 “wb.” + 普通前缀，易信邮箱则为 “yixin.” + 普通前缀 )，这点大家用时需要注意
• OpenID认证通过后可配置返回用户的工号，姓名，二级部门/三级部门，部分信息（如部门信息）需要走邮箱审批由主管同学方可用

考虑到工具面向对应群体的差异，我建议大家在使用OpenID时也需要考虑一套纯粹的用户认证机制，以便与OpenID解耦。

毕竟“商业化”是目前的主旋律，每一个工具都应随时做好服务公司外用户的准备。

2. NOS

一般来说，常用的工具类服务都会需要存储图片，常见文件类的资源。如果自己做应用文件管理，需要考虑比较多的细节。如文件分片与备份，图片类资源再处理（缩略等），视频类资源取特定帧等等，然而这些工作公司内部的NOS服务都已经为我们做好了，我们只要申请一个资源桶就可以用起来了，非常方便。

对于NOS的具体内容可以参见网易云的 NOS 相关文档，这里我就不再赘述了。

3. 哨兵及消息中心

目前在公司里，相信多数JAVA类应用都已经接入了 哨兵系统 来监控应用了吧。

哨兵为我们提供了一站式的从服务器基础监控（内存，硬盘，IO），应用进程监控（方法调用，URL请求响应），数据库实例监控（慢SQL，连接池信息）以及JVM运行时监控等多方位的内容。

在此之上也可以提供各类监控规则，方便应用运维/开发人员配置报警触发规则，并快速跟进处理不同应用/不同集群的报警。

真正做到了为应用在前线“盯哨”的职责，保障了应用稳定运行与问题及时跟踪。

整个哨兵应用接入也非常简单，只要将对应的jar与相关的配置文件放到工程指定位置即可。

除了哨兵系统，哨兵还提供了一个消息中心的接口服务。大家可以自主登录 消息中心 创建应用以获取对应的key和secret，就可以通过消息接口发送接口来触发分类通知消息了（泡泡，邮件，易信消息，语音消息等）。具体的接口描述大家可以自行查看 消息中心wiki文档，此处不再赘述。

这里有一点需要提醒大家：默认泡泡消息的发送方均为【哨兵系统 shaobing@mesg.corp.netease.com】。

如需要指定发送方的话，需要额外在泡泡平台申请一个公共账号( 申请流程 )，再通过邮件向消息中心发起配置指定泡泡消息发送方的申请。当消息中心配置完成后，最后将泡泡消息发送接口的参数(popoClient)调整如下即可：

// 指定发送方的账号(POPO_CLIENT是具体需要指定的账号常量)
params.add(new BasicNameValuePair("popoClient", POPO_CLIENT));

内部工具少不了协作，而协作的一个关键就是提醒相关人员完成下一步工作。

无论是正式的邮件，或者是即时的泡泡消息。消息中心都为我们简化了接入成本，这么好用的工具我们为什么不去使用呢！

4. CMDB及NDP

功能开发完成了，最后一步就是应用部署了。无论是早期的 OMAD（现已停止服务） 还是现如今的 NDP ，他们都协助我们完成工具上线部署的最后一公里工作。

至于CMDB它管理维护了所有服务器，产品，应用，集群以及权限。NDP的部署权限就受CMDB上的部署权限限制，如要加人就得在CMDB上首先操作，NDP上后续方可有权限操作。

NDP目前支持部署的应用类型还是挺全的，如JAVA application, springboot应用，java web应用，静态资源应用以及NodeJS应用等。

使用NDP部署一个应用主要分为以下几步：

• CMDB上创建产品（已有产品跳过）
• CMDB上创建产品下的应用（已有应用跳过）
• CMDB上创建应用下的集群（已有集群跳过）
• CMDB上配置应用的管理员，部署负责人等
• NDP上搜索/点击进入应用
• 进入不同集群完成构建配置
• 进入不同集群完成部署配置
• 执行构建+部署操作完成不同集群的应用部署

也许有人会说，手工源码部署其实成本也不大，用NDP那么费劲干嘛？

这里有一个点我觉得有必要说明一下：

假定：1天只部署1次1个应用
成本消耗：NDP=1秒，手工部署=10秒
节省时间成本：9秒

假定：1天需要部署10个应用，每个应用1天10次
成本消耗：
- NDP=1（秒）* 10（应用）* 10（每个应用次数）=100秒
- 手工部署=10（秒）* 10（应用）* 10（每个应用次数）=1000秒


NDP对比手工部署有10倍的效率提升（如果换成更多的应用，更高的部署频率呢？）

在大批量规模效应下，手工部署毫无优势。换个角度看，把这些时间节省下来做更重要的事不是更好嘛。所以在部署这件事上，我们还是交给专业的工具来做吧。

标准化+规范化后，我们收获的不仅仅是更少的时间成本，而是更大规模的处理能力。

5. Overmind

Overmind 是同属项目管理部-效能工具组的兄弟产品。它提供有完善的环境治理，CI，CD以及流程卡点（如提测，上线，发布）等功能支持。如果你对研发流程规范化有兴趣的话，可以考虑使用Overmind来帮助团队转型。

研发过程中我们最经常遇到的就是质量问题，对于这个点，就可以使用Overmind的CI流程进行控制。

如常见的后端代码提交后，编译失败，静态扫瞄问题频出，单元测试通不过等都使用Overmind内建的解决方案来跟进解决。这样做不断提高每个研发同学的质量意识，完善代码质量控制流程，有利于产品迭代与长期发展。

当然作为兄弟产品，我们也通过Overmind的CI流程来整体控制EP前后端工程的代码质量，应用效果初显。未来还将进一步地深度使用其功能，来保证产品健康稳定地发展。

关于快速迭代可使用的内部工具，我暂时先讲到这里。 其实在不同的业务中，还存在很多“私货”。每一件“私货”都是业务团队同学的实践结晶，在解决业务问题与提升业务效率方面都独树一帜。

希望未来不同的横向业务间，能抽离出更多通性服务/工具，构建属于全公司的基础设施生态。让业务开发过程更简单，更快速，更有保障。

3.7 种子用户选定

何为种子用户，它的基本定义是：

在产品早期愿意和开发者或者运营者进行互动，
对产品充满期待，
对产品迭代和发展起着重要作用的用户。

在《种子用户–获取与运营策略》这本书中，把种子用户类型分为以下6类：

• 建设型种子用户：具有内容生产能力和活跃社区氛围能力的用户
• 验证型种子用户：出于市场，需求不确定，纯粹用于验证需求是否存在的用户（多见于电商领域，尤其是细分/垂直领域）
• 扩散型种子用户：为吸引用户参与，提高产品影响力与名气而寻找的有影响力和名气的用户，最终达到推广产品的目的
• 社群型种子用户：主要特别是需要用户间彼此识别身份，基于共同的基础形成社群，并且要有社交关系链
• 营销型种子用户：能够帮助公司达到营销产品目的的用户（通常指KOL，关键意见领袖）
• 数据型种子用户：针对特定数据，为使“数”看起来漂亮而拉拢的用户，最终达到打动投资者的目的

种子用户与初始用户最大的差别就是：参与产品的深度。

在我看来对于选定种子用户，主要看以下3点：

• 对痛点有共识：认同工具价值点
• 对工具容忍度高：允许试错
• 愿意参与工具改进：共生性（工具越好用，自己收益最大。自己提出更多改进，工具越好用）

满足以上条件的用户，才是我们在早期需要着重关注的用户。不要因为一些非关键因素而过分消耗精力，避免回头总结时追悔莫及。

3.8 运营管理

坊间流传有这么一句话：

好的产品是运营出来的。

看看现如今的各类产品，无一不重视产品运营。电商领域更甚，各类线上线下活动此起彼伏。什么阿里双11/双12，京东618，苹果开学季等等。

而对于内部工具而言，运营管理我个人总结下来是这么几点：

• 用户群沟通
• 版本更新日志与演示
• 改进需求池管理

1. 用户群沟通

当一个新工具上线后，我首先会做的事就是：创建一个工具用户群。把群号放到工具内的显要位置，让用户能尽快找到反馈通道。

用户群不仅仅只是把全部工具用户聚集到一起，更能有效地收集用户潜在的需求，可以快速的接收问题反馈，可以更频繁地保持与用户的沟通交流。

成本小，收益大。那为什么不这样做呢~

不过用户群运营中，我认为最关键的一点在于：

快速响应，即时解决用户问题。

如果一个用户声音在群里长时间得不到“官方”响应，那么用户的内心是崩溃的，无助的。

这将会在一定程度上对工具口碑造成影响，进而不利于工具长期发展，这些结果都不是我们创建用户群的初衷。

因此，既然决定要做了，就尽量把他做到最好。让尽量多的用户感到满意，受到尊重。

2. 版本更新日志与演示

每一次迭代周期可能不固定，但迭代涉及的内容是固定的。那么对于用户来说，他们希望看到每一次版本升级所带来的变化，而且这种变化是可预期的，可感知的。

因此，我推荐大家持续维护版本更新日志。详情描述每一个新增的功能点，优化与问题修复。

这些信息触达用户的方式有很多种，常见的如：泡泡服务号，工具内部的版本历史页，邮件。这里我推荐使用前两种方式：

• 泡泡服务号
• 内部版本历史页

泡泡在公司内正在成为官方唯一的沟通渠道，每天我们都需要接收和处理大量的即时消息，而泡泡的服务号很好的满足了工具的“对外服务”的需求。

每次发版本推送一条更新日志与功能演示，这将会为希望了解工具前后差异的用户提供一个便捷的信息渠道。如遇问题也可通过服务号，泡泡用户群立即反馈，快速得到响应。加深了用户对工具迭代速度，功能演进差异的印象，有利于用户对工具的全部了解。

除此之外，工具内部的版本历史页，也便于用户反馈时直观地截图告诉用户功能变迁的发生时间点与版本。历史信息检索与查看效率比泡泡会更高，我强烈推荐大家持续维护。

至于为什么不推荐邮件呢，主要是出于两方面的原因：

• 邮件信息爆炸问题
• 邮件列表引发的惨剧

邮件信息爆炸问题主要是指现在我们的邮箱功能已在分化。每天邮箱里躺着各类工具的通知流程，以及各类繁多的广告，真正有价值的沟通邮件正在逐渐被其他工具或功能所取代。如果我们通过邮箱过滤器设置各类过滤器再来看，真正有价值的邮件内容有几封呢。邮箱已被“滥用”，我们能在邮箱收获的价值正在变少，这也正是我为什么不推荐邮件的原因之一。

另一个原因是早些年在内部工具中发生的一个小故事：

一个内部工具通过邮件列表向订阅的全部用户发布了一个版本更新信息。
然后一个用户反馈：“我不想接收该邮件，求帮忙清除出邮件列表。”
然后更多的用户反馈：“请求从邮件列表中移除，谢谢！”
这如同发生了一场雪崩，事情朝越来越不好的方向前进。

再然后，有人就直接在列表中回复：“请不要在邮件列表中发布以上信息，有需求请私聊。因为邮件列表中的所有人都会收到持续不断的申请邮件。”
然后，该工具的邮件列表就被用坏了。

通过邮件列表发版本更新信息的小编，估计当时想死的心都有了: 本来只想送份报纸，怎么大家都直接退订了呢！

上面的故事直接说明了一点：邮件列表是一把双刃剑，好好利用可以达到很好的效果。如果不能，那么后果也是极其可怕的。

通过以上的这些内容，我想表达的是：

邮件应被用于正式性的双向沟通，如果不是，那么就请不要选择邮件。

3. 改进需求池管理

重视每一个用户提出的建议，既是尊重用户，也是尊重工具。将用户提交的所有改进建议/问题都纳入到统一的唯一优先级的需求池中，让每一个需求都得到充分讨论，每一个人的意见都得到重视。一个人的力量有限，但一个团队的力量是无限的。

能用10分钟解决的问题，为什么要让用户等1个月，这是一个很现实的问题。

产品态度，开发态度，测试态度，运营态度直接决定了需求演进落地的速度。

团队成员通力合作，将小优化需求尽快地验证上线，让大功能调整能有节奏的稳定发布，让工具平台的体系逐渐完善与发挥价值。

每个成员都是木桶的一块板，最慢的那块决定了木桶能承载的水量。

收集 => 改进 => 发布 => 告知，一个完整的闭环才能真正地做好运营管理，环环相扣，缺一不可。

3.9 北极星指标

什么叫北极星指标，北极星指标的作用是什么？只有搞清楚用力的方向，力量才能发挥它的价值。

北极星指标，又被称作“OMTM”，全称为：One metric that matters。
它是产品当前阶段唯一关注的重要数据指标。

就如”不以结婚为目的的相亲就是耍流氓”。类似的，我们脱离数据谈业务价值，一样也是在耍流氓，而且这流氓耍的很没有“水平”。

每个工具发展的不同阶段，我们都会定义大量的KPI数据指标。如使用工具的用户总量，日活/月活，以及周留存/月留存等等。这样数据指标之所以被定义出来，就是为了满足衡量当前业务价值的需求。

而其中最能体现业务价值的指标就是：北极星指标。现实中，我们往往会将北极星指标逐层拆解，分离出更多细化具体的指标。这样具体可衡量的小指标就会让每位团队成员找到“价值归属”，更有利于大家朝着一致方向而共同努力。

团队的努力并不直接作用于北极星指标，但每一份汗水却都是间接影响着北极星指标。

这里我举个例子来说明一下：

假设一个工具A在公司内部已得到广泛的业务应用，但是小问题频出，界面简陋，交互反人类，那么这个北极星指标可能就是：“提升工具A的产品质量与体验”。

逐步将此指标细化拆解后，具体小指标及措施如下：

* 优化用户体验：完成工具A的交互+视觉大改版，内部UI进行组件化统一设计与实现。
* 优先处理存在已久的“牛皮藓”问题：广泛收集未接入或已接入业务的团队遇到的问题，并通过迭代逐步落地，时刻关注新加功能对已有设计的影响。
* 提高工具A的稳定性，可用性，吞吐能力：工具A的软件架构与内部代码完成适应性调整，清理代码中的“坏味道”，优化代码组织结构。
* 提升测试自动化能力：重要场景进行自动化用例开发与维护，投入更多精力跟进用户遇到的各类问题。
* 组织用户访谈有奖活动：聆听用户声音，找到频繁出问题的功能点，推进研发优化。

北极星指标并不是一成不变的。随着产品进入不同的发展阶段，我们需要根据实际情况调整对应的北极星指标。

而北极星指标存在的意义就在于：衡量业务价值。

3.10 二八原则

在任何一组事物中，最重要的只占其中一小部分，约20%，其余80% 尽管是多数，却是次要的。

20/80法则又称为帕累托法则，它代表人或组织需要花费时间、精力、金钱和人事在最重要的优先顺序上，用20%的时间收获成果的80%。

对于工具开发来说，二八原则指示我们将核心精力聚焦到80%的用户功能需求上，而不要过多地消耗在20%不重要的事情上。

产研之间资源不对等的矛盾，在现实工作中很难有效解决。如何最大化每个人的价值，使重点问题着重解决，次要事务延后或舍弃。这是我们每一个做工具/产品需要考虑的关键点。

只有真正把握了大多数人的需求要点，才能有效发挥工具价值。
否则如同病急乱投医，到头来白费工夫。

因此，我们需要使用二八原则进行聚集、聚焦、再聚焦工具价值本质，将时间，精力分配到能体现北极星指标的关键功能点上去。只有这样，工具才更有可能获得成功，赢得用户。

3.11 连接上下游

工具的本质就是“连接”。从A到B，从B到C，从C再到A，如此循环…

通过工具连接不同角色的人员，让大家互相保持高效协作，进而提升整体工作效率。一般团队中，有两类人是值得特别关注的：

• 产品及设计人员
• 研发与测试人员

如上节所述，产研不对等的矛盾始终存在，而工具可以通过业务流程将两种人群有效的连接起来。

相互之间的“流动”如同一根无形的指挥棒，协调所有音乐家的演奏，共同创造出动听的旋律。

这里，我通过D-BOX来介绍一下工具“连接上下游”的突出能力。

D-BOX定位为设计稿分发与管理平台，几乎所有业务的交互稿，需求稿，视觉稿都通过它来管理。

设计师/产品完成稿件后，通过上传到D-BOX后就会自动触发稿件更新通知。这是一个看似很小的变化，但它的意义巨大。

我们来回想一下以往的沟通链路：

1. 完成设计导出成HTML包
2. 放置到网盘对应目录，截图圈重点
3. 打开泡泡群，描述更新内容，粘贴截图和查看链接，@相关功能开发与测试人员
4. 开始在群中进行“无尽”的讨论
5. 如此反复...

而当你切到D-BOX后管理设计稿呢，链路就是这样的：

1. 完成设计导出成HTML包
2. WEB上传更新设计稿（系统自动下发变更通知给所有人员）
3. 不明确的内容直接在D-BOX的稿件上进行标注
4. 如此反复...

可以看到D-BOX旨在节省人工介入的操作成本，让“连接”的成本更低，每个团队成员只要关注变更内容本身就可以很好的协作。

3.12 数据化分析

从工具诞生上线那时起，数据化分析就需要“如影随形”。只有通过挖掘数据隐藏的内在逻辑，才会助工具一臂之力。那么关于MVP阶段的数据化分析主要需要关注哪些内容呢，我认为主要体现在以下几个方面：

• 业务数据分析
• 行为数据分析

1. 业务数据分析

业务数据分析主要是用于对北极星指标及其细分指标的 “定量分析”。

一般来说业务数据分析会包含以下几个步骤：

1. 对业务所涉及的核心领域模型进行指标口径，指标含义描述，指标计算周期等进行定义（如数科的指标系统）。
2. 通过数据开发平台（如猛犸）来完成数据清洗、数据转化、数据抽取、数据合并、数据计算等数据加工步骤。
3. 最后通过数据可视化平台（如有数）来便捷地可视化/定制显示数据，快速分析数据。

对于内部工具来说，通常对核心领域模型涉及的表实现以下几个指标，即可满足基本的数据分析需求。

• 用户截止日总量/当日增量
• 其他核心业务数据的截止日总量/当日增量
• 核心业务不同状态下的数据截止日总量/当日增量

以上数据指标都在每日凌晨定时跑即可。

透过【截止日】看规模，透过【当日】看增长。

2. 行为数据分析

行为数据分析主要是用于对工具所面向群体用户行为的 “定性分析” 。

定性分析一般关注的是以下几方面内容：

• 用户设备及来源分布
• 活跃用户分布
• 功能事件分布

我们常说的埋点就是指行为数据分析。行为数据分析的工具有很多，内部有哈勃，外部有GA，百度统计等等。

我比较偏爱GA，功能强大，使用便捷。经常看看个人博客的流量，人群分布，哪篇文章更受大家关注等等，还是很好玩的。

这里有几个小点可以分享给大家：

• Client ID与User-ID的用处
• 用户分层图表

2.1 Client ID与User-ID的用处：

默认情况下，Google Analytics（分析）会为每台设备分配一个唯一的 Client ID，并在报告中将每个 Client ID 视为一个唯一身份用户。借助 User-ID，您可以全面衡量横跨多台设备的用户互动，例如将在某台设备上进行的与营销广告系列的互动归为在另一台设备上发生的某次转化的原因，或在多台设备上确定唯一身份用户（去重）。

根据 官方文档 ，两者的主要差异如下：

2.2 用户分层图表：

功能位于：网站数据 -> 受众群体 -> 用户分层图表下。点击某个客户ID可以进入其详情页，这里可以查看该用户的三块核心内容：

• 基本信息（客户ID，上次查看日期，设备类别，设备平台，流量获取，渠道，来源/媒介，以及广告系列）
• 生命周期价值（会话数，会话时长，收入，交易次数，目标达成次数以及目标价值）
• 页面访问与事件触发明细记录（他在什么时间访问了什么页面，干了哪些事）

可以说通过标记User-ID加上用户分层图表，我们就可以精确了解每一个用户如何工具的方式。

通过这些定性行为分析可以反过来指导我们作一些功能方案的改进，达到使工具为用户所用，好用的目的。

3.13 数据增长

数据增长领域最经典的要数AARRR漏斗模型啦。

每个字母是单词Acquisition、Activation、Retention、Revenue、Referral的缩写，分别对应用户生命周期中的5个阶段:

• 获客（Acquisition）
• 激活（Activation）
• 留存（Retention）
• 变现（Revenue）
• 推荐（Referral）

1. 获客

正如前面“种子用户”部分所提到的，获客意在获得早期用户，获得早期的精准流量。通过在不同阶段引入不同的种子用户，来使工具/产品“冷启动”。

通过功能不断吸引新的用户，让功能源源不断地为工具提供流量。相辅相成，闭环式稳步地实现数据增长。当然，如用户引入不当，也会造成不良的成本浪费，甚至是产品走向衰落地后果。

不分质量或目标的获客是无意义的，我们要认清自己的工具所面向的群体，有针对性地拉拢目标用户，这样才能达到数据增长事半功倍的效果。

2. 激活

激活意味着我们需要不断地让进入工具的用户，更深度地去探索工具/产品。了解与使用工具/产品所提供的功能，并在一段时间的“沉睡”后有效地唤醒他们。

如果把工具的“注册”比作“获客”，那么“登录”及功能使用，则代表“激活”。

工具的总注册用户量只能代表过去，而工具的活跃用户量只代表的是当下。
我们更应关注当前，而非总是缅怀过去。

3. 留存

用户注册了，也试用了一下工具/产品功能。但是如果用户感受不到特别大的价值点，那么这些用户是很难继续留下来，长期频繁地使用工具本身的。因此为了让用户持续不断地使用工具，通常来说我们需要使用一些小技巧。

• 高光时刻
• Hook模型
• 关注路径转化漏斗
• 优化用户与服务体验

3.1 高光时刻

就是设定工具/产品的“高光时刻”，即让用户眼前一亮的功能点。让用户记住这个时刻，让这个功能成为与用户在当前或未来之间的连接点。让他想起，喜欢，需要时，工具的老用户就回来了。

3.2 Hook模型

正如《上瘾——让用户养成使用习惯的四大产品逻辑》中提到的，通过“触发”、”行动”、”奖赏”、”付出”这四步，可以让用户发现你产品的真正价值，帮助用户完成“首次体验”和“重复使用”达到上瘾状态，让用户真正留存下来。

3.3 关注路径转化漏斗

用户进入工具/产品的路径不相同，用户离开工具/产品的路径也不相同，用户使用功能的路径更加不相同。那么在这条错综复杂的路径图中，我们就要梳理出主要路径的转化漏斗。通过转化路径中的每个环节去分析用户流失的关键点，重点问题重点分析，以解决用户留存低的问题。

3.4 优化用户与服务体验

工具外在的视觉感观，交互体验以及用户服务体验，这些因素也在一定程度上影响着留存。为了拥有更高的用户留存，我们需要在以上三方面分别用力，用心地去让用户满意，让他们感觉“贴心”。

留存的关键是让新来的用户留下来，让既有的用户能长期的使用工具/产品。但对于非目标用户来说，很多时候我们的努力他们并不关注，因此很难留下来。对于这种情况，我的建议：随他去吧！

没有哪个工具/产品能让所有人都达到满意的，我们做工具的目标是: 尽量让期望的用户达到满意。

4. 变现

任何工具/产品要想长期发展，在发展到一定规模后都需要考虑这样一个问题：商业变现，它是任何工具/产品可持续发展的基石。

俗话说：巧妇难为无米之炊。

现实生活中，有很多这类例子：坐拥大量用户，却苦于没有有效的商业模式。因长期无法变现渐渐衰落，最后走向毁灭。

对于内部工具来说，这种压力相对较小。但由于整体大环境的影响，我个人觉得当工具发布可用之时，工具的核心团队就必须时刻考虑这个问题了。

它无关乎当下，只关乎未来。
早做打算，好过不知所措。

5. 推荐

如果工具需要渠道推广，可想而知，他的成本有多高。而如果工具是通过用户的口碑传播的话，毫无成本，而且更容易让用户留存。有这么好的方式，我们为什么不用呢。

对于”推荐”我们需要注意的点是： 只有真正好的工具/产品，用户才愿意推荐给其他人。如果工具/产品本身不够好，即使发生了推荐，完成了试用，往往也会在留存那一步掉链子，无法转化。

越往后的每一步就比前一步实行起来更加困难，需要我们不断推陈出新地挖掘数据增长空间。但对于MVP来说，我们一般只需要重点关注前3个阶段，即：获客，激活，留存。做好这三步，打好数据增长的扎实底子，才能为以后变现与推荐提供保障。

3.16 技术债与架构演进

早期的技术选型，随着工具功能不断新增，变更，再加上开发时间紧张，自我要求不严格，那么很可能底层代码实现已经是一锅粥了。

当第一次review发现代码丑陋时我们可以忍，当第2次review时依然觉察到代码应该适当重构时也还可以忍，但当第3次时，那么这就到了不得不偿还技术债的时候了。

俗话说：出来混，迟早都要还的。

适时，适量地进行代码重构与优化，会对工具本身长期发展来说产生积极影响。关于技术债，我个人认为主要是以下几块内容层面的优化：

• 架构合理性
• 扩展性
• 服务稳定性
• 文档支持

1. 架构合理性

根据业务功能来发现架构中的不合理，讨论，设计，规划，实现。逐步将糟粕调整过来，让代码回归最初时，简单，清晰，Good的状态。如之前所说的技术维度的架构调整，就可以根据现阶段的业务规模与性能状态进行合理选择了。

单体 -> 分布式，应用会话 -> 集中会话，实时查询 -> 缓存命中等等。根据监控系统给出的反馈，有针对性的进行“微调”，最终达到理想的状态。

架构合理性调整是一个长期的过程，谁都别指望能争取一个版本将所有糟粕去除。
稳定、安全、有效才是长久之计，每次变化一点点。
结果的量化可衡量极其重要，需要我们重视...

2. 扩展性

一个工具的发展之路往往是先核心，再发散，再扩展。核心指的是自身平台的功能集，发散指的是能力开放，扩展指的是与第三方合力共建。多元生态，会为工具开拓更大的机会，也会更能发挥价值。

盘子有多大，决定了工具的未来。

说回技术层面的扩展性点上来，就需要核心开发人员回归思考之路。从哪个点扩展，扩展怎样的能力，为其他生态提供什么，能带来什么价值，是不是一种互利共赢的状态。这些都是现实的问题，值得我们深思。

3. 服务稳定性

再好的工具，如果总是不稳定，经常出问题，也就不能赢得用户长久的口碑。保证工具服务本身的基本稳定性是强制性要求，需要开发与运维人员认真思考。

定下指标，努力向目标前进，只要前进，未来就不会遥远。

4. 文档支持

这里所说的主要是技术型文档，设计文档，架构文档，部署文档等等。诸如此类的内容可以为后面进来的同学提供很多的指引，结合文档看代码，可以进一步加速吸收设计。

换个角度想，这些文档也将为未来可能的“商业化”铺平道路。

过多的文档可能是负担，但适量的文档是必要的。

4. 总结

以上就是我这几年来做D-BOX也好，做EP也好，做其他小工具的一些心得体会，希望真正能给你有所帮助。

最后我用最近公司倡导的价值观来结束本文：

热爱：为热爱全心投入
用户：和用户在一起
创新：从0到1是创新，从1到1.1也是

除此之外，我还有一句话想送给大家：

顺势而谋定！

看清形势，顺应而为。早作打算，果断决定。做一个有执行力的人，而不是只会动嘴皮子的人。

5. 附录

关于本文中涉及的专业内容我统一归整如下，有需要的可以自取！

• MVP（最简化可实行产品）
• 一张图教你发现用户的痛点
• 技术选型指南
• 敏捷软件开发
• 如何理解持续集成、持续交付、持续部署？
• 如何获得第一批种子用户？
• 运营到底是做什么的？
• 5个提问，详细介绍北极星指标的策略框架
• 二八定律
• 团队协作的三个基本要素——分工 合作 监督
• 数据分析
• 增长实战：破解获取、激活、留存的数据思维
• 技术债：the good, the bad, and the tao
• 各大互联网公司架构演进之路汇总-2020最新最全

• Previous
  有效读书的方法——我的读书方法实践
• Next
  谈谈工程代码质量控制的事