谈谈验证能力

本文来自微信公众号：caoz的梦呓（ID：caozsay），作者：caozsay，题图来自：视觉中国

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

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

那么也是分几种场景。

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

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

先说前置验证。

1. 核心诉求验证。

   
   

2. 商业转化模型验证。

   
   

3. 技术验证。

   
   

4. 团队磨合验证。

1. 核心诉求验证

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

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

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

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

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

2. 商业转化模型验证

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

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

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

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

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

3. 技术验证

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

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

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

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

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

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

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

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

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

4. 团队磨合验证

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

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

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

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

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

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

下面说一下回溯验证。

1. 验证预判。

   
   

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

1. 验证预判

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

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

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

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

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

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

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

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

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

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

本文来自微信公众号：caoz的梦呓（ID：caozsay），作者：caozsay