从0开始运营APP之三,不懂技术怎么防开发外包忽悠?

你需要一个能够监控你应用质量状态的工具，请外包花的钱，必须对质量有所要求，比如Crash率低于多少，个别Crash对用户的影响有多大，都是要去关注的。不是开发说一句“这个错误影响小”你就可以忽略的。开发不是喜欢“用数据说话”吗？你就让他看数据呗！

上周我在逛知乎的时候，看到了下面这个问题《作为产品经理 如何对应用的质量状况进行监控》，问题描述如下：

我是一个移动应用的产品经理 目前负责一个有几百万用户的应用 最近上线了一个新版的产品之后 在用户群里面收到一些用户的反馈 表示使用过程中容易卡 有的甚至闪退 我将这个问题反馈给我们开发同学之后 他说这只是个别情况 不需要理会 目前他正在提离职 一个月后就走 我觉得他有点心不在工作上了 一切需求都是在敷衍 我需要怎样才能知道开发说的是不是真的呢 突然意识到自己对应用的质量有点失控了。

这个问题把我拉回了之前一段痛苦的经历：产品规划做好了，发布时间也定好了，但是移动开发工程师一直还没有招到，因为战略原因，必须在定好的时间发布这一款应用，实在找不到人了，只好去找外包开发同学。给我们做应用的这位同学也是兼职做外包的，有自己的本职工作，非常忙，在这样的背景下，我和他的拉锯战就这么开始了。

那个时候，每次拿到包，我都会去内测用户群里面让大家体验，然后收集用户反馈，整理后发给这位开发同学，经常会遇到一些无名的crash，我这边无法重现，于是开发同学就不去解决了。但是每次更新包拿给用户体验后，都会发现总有几个用户的机型会重现这个错误，这个crash的一直未修复，已经引起了他们的不满。

但是开发同学说：那只是个例，影响不大。我竟然不知道该怎么反驳他。

这几个用户使用的机型是现在市面上流行的机型，而直觉告诉我，这绝不是个例。

1、几个你需要关注的与质量相关的指标

Crash次数：在选定的某段时间内，应用程序报错的次数；单纯只看这个数字没办法看出什么问题，这个错误次数要跟错误覆盖人数、活跃用户数、用户留存率等指标进行重叠查看。

Crash覆盖人数：指的是在选定的某段时间内，应用程序报错的设备数，这个指标就很能说明问题哦，如果这个指标很大，就说明你的应用的质量问题已经影响很广泛了，用户这个时候可能已经准备卸载你的应用并且上社交网络叼你了。

每次启动的Crash次数：在选定的某段时间内，你的应用平均每启动一次会出现多少次错误，计算方法：Crash次数 / 启动次数。这个字数越小越好。

接下来以腾讯云分析的报表作为例子来解读这些指标。

可以看一下下面的这个图，从这个数字可以看到这个应用昨天错误次数有208，错误覆盖人数/设备是84，还好每次启动错误的次数仅有0.0686。但是我们看一下错误覆盖活跃用户占比，达到了1%，也就是每100个经常使用我们应用的用户（活跃用户）里面，有1个人就会发生错误。活跃用户是我们需要重点去维护的群体，有一句话叫做“好事不出门，坏事传千里”，一个应用用得好，用户可能不会在社交网络上去发声，但是如果一个应用给用户带来了不好的体验，那么他会有很大几率去社交网络上去发泄。 

2、如何判断错误是个例还是普遍存在 

之前的那个案例中，我有提过那几个不满的用户使用的是流行的机型，也恰恰是这个报表中显示的错误频发的五大机型之一。内测阶段，错误一旦发生在这么几个流行机型当中，如果错误没有被解决，那么公测的时候这些错误很有可能会被放大到几个数量级，对于我的习惯来说，不管错误是个例还是普遍存在，在内测阶段，绝对不允许错误的存在。

于是我在那个诡异的crash上进行了标注（需要注意），然后又在公司内部跟同事找来了错误频发的那几个机型，然后把内测群的那几个用户都细细询问了发生错误时的具体操作。接着设置了一个告警，然后，安装上我的应用，连续在10台手机上按照用户描述的步骤进行操作。很快，QQ弹窗、微信推送、邮件push的提示声同时响起，我的嘴角不由地浮起了一个微笑：我是对的！！！（有没有觉得我好贱啊好贱啊哈哈哈）

（1.备注错误）

（2.设置告警）

当然，当你获得你想要的说服性数据之后，还是要保持谦卑的状态，去跟开发同学提bug修复需求。不然就没人给你做事啦！