闭环 | 从需求到数据到改进，在产品上精益求精

互联网的产品相对传统IT产业而言，需求更富有多样性。传统IT行业的需求点多是固定且符合验收条件。但互联网的产品则更多的从用户体验出发，更多的用数据来说话，不管是PV、UV、转化率、留存等等。很显然在一个接着一个的迭代背后，我们必须要让需求到数据到改进实现闭环，才能在产品上精益求精。

今天就来探讨下如何从项目经理的角度出发，将这些环节形成闭环，更好的为产品精益求精服务。

对于“需求—数据—改进”的闭环，可分解为以下三点：

1. 产品功能交互设计之初，明确方向，设定指标（KPI）

2. 产品开发过程做好埋点，确认数据来源，获取数据

3. 分析数据，并反馈到产品功能交互设计

下面，分别展开每一点在项目中我们应该如何去做。此处只是从项目经理的角度出发，讲讲我们在项目开展中可以关注的环节，对于数据驱动创新等更专业的内容建议大家阅读《精益数据分析》。

功能设计之初，制定指标

产品的孵化和各功能模块的设计在最初的时候都有一个初衷，去解决用户的痛点。从产品初衷到产品形态，如何去衡量我们做的每一个功能用户是买账的。在最初始阶段，我们就需要设定指标来衡量，而其中数据指标是最为量化和直观的。但在这个过程中，不能仅仅就提出数据指标，更要明确定义每个指标的具体意义以及计算方式。

举个例子，比如想用每日活跃用户的数量来衡量app的受欢迎程度。初一看觉得这样的指标很合理，但其实是不够的，因为没有对活跃用户做一个定义，不同的定义会极大的影响我们的判断。所以我们必须做到精确定义，排除可能造成干扰的其他因素。

每个指标的背后，都应该为产品的方向和目标服务。比如一个即时通讯的工具，那么用户之间的消息量、好友数也许是我们衡量这个产品健康度的指标，因为这两个指标和我们的核心功能切合。

通常来说，在产品设计之初，产品经理和策划就应该根据自己对产品的思考整理出核心指标。核心指标也并不是不变的，在产品MVP验证探索阶段，也许产品的方向都可能发生变化，此时核心指标也会发生相应的转变。

在定义好核心的指标之后，我们应该针对这样的指标让整个团队达成共识。这样的方式可以采取多次的头脑风暴，以及讨论会。在这样的过程中，其实大家可以更加深入的去挖掘。参与人员包含运营市场产品设计以及开发测试，只有大家共同理解目标，在每个工作环节才能集中精力为这样的目标去努力奋斗。同时这样的一个过程也建立大家对产品的一种主人翁意识。

铺平数据来源之路

对于数据指标达成一致意见之后，那又如何常规的获取数据呢？

在产品研发过程中，对于数据获取的途径一并考虑，则可以节约很多后期跑取数据的繁复过程。比如数据埋点的接入，核心KPI系统的搭建。都是用来呈现常规数据的手段，随用随查，而无需再让开发人员去跑取。

在我们日常产品中，通常数据的来源有三处，一个是服务器数据库数据，二是日志数据，三是埋点后收集的数据。服务器的数据和日志的数据相对来说比较精准，但很难做用户使用路径的分析。而埋点数据，由于受第三方数据分析系统的上传策略限制，在精确性上存在一定的折损，通常用来做用户路径的分析，数据对比，以及日常观测。

对于埋点，会涉及到埋点事件，以及埋点事件的属性和标签，结合数据分析平台。产品策划同样需要在产品设计过程中，理清楚埋点的需求，提交给开发。而埋点的需求通常会结合分析用户行为、各维度数据呈现的要求。同样埋点需求文档也是需要在产品迭代中不断的维护更新。因此，也建议大家将埋点需求文档和需求管理结合起来。在整体的开发流程中，关注埋点需求的落实和验证。

所谓工欲善其事必先利其器，想让数据驱动，那么这些工作的完备开展会极大的帮助大家的日常工作。

数据指标带来的反馈

有了数据，我们又应该如何去对待数据从而带来正向的反馈呢？

对于团队

数据指标应该定期的反馈给团队，做到数据信息透明。这个有很多的方式，比如例行的数据周报发送，数据平台的权限开放。另外，也需要培养和调动大家对数据的敏感性。我们以前一直在谈如何提高成员的ownership感，而我认为，让大家更透明的了解自己正在为之奋斗的产品的状况则是非常重要的一点。核心数据指标较为健康，整体向上的趋势，对团队来说无疑是最好的激励。而当数据下滑或者出现异常，也便于整个团队提高危机感，从而共同审视当前的工作，是否可以为了数据上扬而做些力所能及的事情。

对于产品运营

上面讲了那么多，其实最终还是要为产品和运营服务。那么最后一环我们应该怎么做，才能真正的达到闭环，让数据真正的被利用起来呢。配合相应案例，希望对大家能有所思考。

（1）案例一：预警和产品、运营的优化

数据的异常变动，可能提示着某个异常，举个例子：某产品在页面上端做了黄条的消息提示，用来做日常信息通知等。但在一次版本改版中，为了便于区分不同的信息类型，新增了灰条。数据后台则会发现，顶端消息通知的点击率大幅度的下降，灰色相对黄色，醒目程度大打折扣。后续产品做了紧急调整，弃用灰条。

又比如用户流失预警系统，下图则是某产品流失预警中的某个表格。很显然，通过这个表格，则可以明显的发现有一部分用户流失概率较高。从而可以抽取这部分用户，对这部分的用户做一些特征的挖掘，或者直接通过电话访问等方式来调查用户流失的原因。从而使得产品在这些方面得到反省和优化。当然，也可以针对高流失概率的用户做一些运营活动的召回。

（2）案例二：验证设想， A/B test

这里举个栗子，某产品需要获取用户的GPS信息，便于补充用户画像的数据。但由于手机系统权限的设计，获取GPS信息会在app启动初始弹窗询问用户是否允许。在这样的情况下，产品猜测会有对新用户的注册转化率有一定的影响。于是，挑取两个小众化的渠道来做测试，只针对这两个渠道下载包的用户做了GPS信息的收集。最终发现注册转化率的数据上和之前对比没有异常和波动。得到这个结论后，则可以大胆的将此功能开放到全局平台。

又如：在某产品的某个页面中，对于商品的展示方式如何能带来更高的点击率，设计了两个模式。因此需要对这两种方案设计A/B test。如下图所示，就是A/B test的数据对比，很显然，下图中的D版本明显点击优于其他版本。最终则考虑所有的页面全部切到D方案。

综上几个案例，我相信大家肯定可以看到数据在产品和运营中的这种反馈作用。而这个过程更多的需要产品策划和运营具有一定的数据驱动意识，在这个方向上的精进，无疑对工作会带来很大的益处。

最后的最后

以上，是笔者在日常项目管理过程中，对于需求—数据—改进闭环形成的看法。对于数据创新驱动业务等课题，已经有很多专业性的文章和书籍做了研究，但笔者想表达的是，在日常工作中，我们关注点点滴滴，踏实做好每一步才是最重要的。