谈谈验证能力

左手的ㄟ右手 2022-12-03 13:00 134阅读 0赞

这其实是 [谈谈调研能力][Link 1] 的姊妹篇，当时想写成一篇的，觉得太长了，算了，分成两篇写。

调研是了解诉求，以及寻找可能的方案，而验证就是检验诉求及方案的可行性。

那么也是分几种场景。

包括前置验证和回溯验证。

前置验证，就是在进行项目的研发和运营之前，进行小范围验证。回溯验证时在运营过程中对一些想法，一些判断进行验证。

## 先说前置验证 ##

1、核心诉求验证。

2、商业转化模型验证。

3、技术验证。

4、团队磨合验证。

### 1、核心诉求验证 ###

典型如游戏的核心玩法，很多时候游戏只是做一个核心的打斗玩法场景，然后找核心玩家测试，看看接受度和期待程度，然后决定是否用这样的方式继续游戏，如果核心玩法未被接受，后面就不用做了。

那么其实远不止游戏，我劝退过不少创业者，想法很多，觉得自己需要一笔投资，做个大事情，那好，做过核心诉求验证么，怎么做，选择最基本最核心的一个点，你的核心目标用户群最关注的一个点，你去做一点尝试，然后拉群，拉微信群，小范围提供某个服务，手工也好，简单脚本也好，哪怕贴点钱外包也好，你看看用户如何接受这个诉求，如何回馈这个服务。

那很多创业者说，不行，用户不接受是因为我提供的服务不完整，我必须把前前后后左左右右都做到位才能测试，这就属于入魔了。

很多创业团队没做过核心诉求验证，脑袋一热就起高楼，最后发现除了一群评论家和自媒体跑来找了点素材，没什么真实用户在用。

这里要说一下，验证和调研的区别是，调研是你去了解用户需要什么，愿意付出什么，验证是你提供了最基本的需要，看看用户是否接受，以及如何反馈。

### 2、商业转化模型验证 ###

其实游戏测试就是一个典型的商业转化模型验证，投一点点广告，跑个测试服，然后统计玩家的留存率，付费率，平均付费金额，玩家生命周期，算下来跑不正，继续优化调整；算下来跑正了，心理就有数了，再稍微做好一些后续的准备，就可以大规模推广和运营了。

那么上市公司跟谁学的一些报道里也提到了，他们也遇到过艰难时期，估值太高，资金消耗太快，当时公司很危险，那么就酝酿转型，但最开始也不知道做什么，开始小范围测试一些直销课程，结果几个月算下来，投入产出比好的惊人，模式跑通，开始铺量，最后铺出一个上市公司。

小范围模式跑通，和大规模成立之间，并不是必然的因果，但相关性还是很高的，很多人说不对啊，规模效应啊，小范围是负的，大规模也可能是正的。是的，有些商业模型，小范围验证是亏的，也是可以铺规模的，因为他们相信规模可以降低成本；但这个也是要测算的，前几年o2o火的时候，很多人对规模的成本效应过度乐观，最后团灭。

小规模验证也需要精益求精，比如营销素材的设计，比如目标人群的选择，否则你可能产品本来没问题，结果数据总跑不正。

验证一定要有数据目标，一定要坚持数据原则。有些时候觉得沉没成本太高，验证数据并不好，但总以为规模化后可以解决所有问题，一意孤行，那验证也就失去了意义。

### 3、技术验证 ###

我以前说过，压力测试在什么时候进行，产品上线前？核心功能完成时？错，是在数据结构设计的时候，压力测试就开始了。

对，代码一行没有写，就开始压力测试了，数据结构确立后，写个脚本建立几百万条测试数据，然后完成核心SQL和核心逻辑的代码，进行压测。

当时我做统计，做社群，都是数据结构和系统设计刚开始，就做压测，压测结果满意才开始动手写代码，其实这就是技术验证，验证这里的技术逻辑能不能支持业务诉求的考验。

那么不止压力测试，还包括其他。

以前在百度做日志分析，日志很大，代码逻辑不复杂，但一次跑通的概率并不高，可是跑一次要很久，很长时间，如果写完代码跑起来，等结果，多半是错误信息，那么需要几十分钟，甚至几个小时。

先做片段分析，核对结果，先保证代码业务逻辑是对的。

然后做断点输出，比如每执行1万条日志输出当前的状态和执行时间，然后观测执行的负载，通常会遭遇内存溢出的情况，大概就知道是执行了多少条会溢出，每1万条的执行时间是多少，然后想办法优化，优化的目标不是追求极致效率或极致资源节省，而是在已有资源可支持的情况下，能够实现效率和资源的平衡。

其实也是 不断对核心负载做技术验证，然后不断调整，最后确认没有问题后才进入正式部署，以及额外增加新的逻辑和能力。

先证明技术方案可行，然后才开始进入项目的研发，如果项目研发进度到相当程度了，才发现一些核心指标满足不了，再去重构，就头大了。

### 4、团队磨合验证 ###

新的团队，新的管理者，能否具有足够的战斗力，挑战足够复杂的任务，可能也需要做个验证。比如先做一个独立小型的项目，考验团队的执行能力，项目管理方式，每个成员的特长和缺点。

有不少游戏创业团队都是先做一个轻游戏，磨合团队，验证团队执行成本，然后才会启动重量级产品。

前置验证，很重要的一点是提炼能力，你必须抓住核心点。抓住最关键的问题点，用最低的成本，去验证整体项目的可行性。

如果你提炼的不是核心，那么验证了也没意义，最后实践的时候还是会掉进坑里。

如果你提炼太多，面面俱到，觉得都是核心，那么验证成本过高，验证也就失去了意义。

小创业团队，务必早期做好必要的验证，再开始进行比较大的项目研发。而一些个体创业者，我也是不断强调过，从最小的范围开始验证模式，验证通过再开始大刀阔斧的进行投入。从微信群开始，从朋友圈开始，验证你的产品，验证你的服务。如果你身边的人都不愿意接受你的产品和服务，你凭什么认为可以做出规模化的产品和服务？

## 下面说一下回溯验证。 ##

1、验证预判。

2、验证反馈及问题猜测。

### 1、验证预判 ###

产品上线前，你应该对一些上线后的数据特征有一定的预判。

产品人员，大概应该能预判用户的行为特征。

技术人员，应该能预判负载压力的构成和请求频次的构成。

运营人员，大概可以预判用户的反馈和交互的可能性。

那么上线后，要有针对性地做数据回溯，分析是否与预判一致，验证自己的判断是否准确。

这需要上线前就做好明确的数据准备，上线后可以根据具体的数据和日志信息进行追溯分析。

### 2、验证反馈及问题猜测。 ###

产品上线后，往往会有人反馈比如卡了，慢了，各种问题，也有人会反馈产品使用中的一些特性被用于预料之外的场景，那么这时候，需要对这类反馈和问题做一个验证。是小范围的问题，还是大范围的问题；是一个极个别的诉求，还是一个相对普遍的诉求；

这往往需要额外增加一些监控手段，分析能力，进行验证。

那么技术上有时候会出现一些偶发性的问题，比如1%的用户出现打不开，加载慢，但当你面对几百万用户提供服务，这1%并不是一个可以忽略的问题。怎么办？可能确实一开始的设计没有做好足够的监控和分析，无法第一时间精确定位，但这时候就要开始做一些监控，一些日志的额外处理，代码中增加一些断点输出，把所有怀疑的可能性，都尽量做到有迹可循，那么经常性的回溯这些监控数据和监控日志，并不断强化这方面的能力，最终定位问题，解决问题。

--------------------

大概就这样吧

最近文章懒得写，广告懒得接，卖货懒得卖，赞商也懒得开。

只有知识星球还是坚持维护的。历史累计付费用户超过2万人，目前依然处于付费状态的用户超过1万人。几年来读者的实际支持就是最好的证明。多少曾经火爆一时的大V已经烟消云散，多少曾经日进斗金的大师已经销声匿迹，时间是对信用最好的证明。

[Link 1]: http://mp.weixin.qq.com/s?__biz=MzI0MjA1Mjg2Ng==&mid=2649869899&idx=1&sn=c5827bcae0634f158511997b1d96597a&chksm=f1075426c670dd3050cdbac32493288e6ce62d261aec6fe7388c90ba2e4e1ed733ca0287fb1a&scene=21#wechat_redirect