谈谈什么是验证能力

同样过七夕的日本,约会交友市场也正发生变化

日本用户对于被尊重和安全感的重视超乎你想象。

编者按:本文来自微信公众号“caoz的梦呓”(ID:caozsay),作者:caozsay,36氪经授权发布。

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

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

那么也是分几种场景。

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

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

先说前置验证

1、核心诉求验证。

2、商业转化模型验证。

3、技术验证。

4、团队磨合验证。

1、核心诉求验证

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

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

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

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

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

2、商业转化模型验证

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

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

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

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

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

3、技术验证

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

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

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

我们盘了500家新基建企业,最核心的干货都在这里了

寻找最具代表性的“China Built”

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

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

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

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

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

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

4、团队磨合验证

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

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

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

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

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

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

下面说一下回溯验证。

1、验证预判。

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

1、验证预判

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

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

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

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

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

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

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

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

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

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

创投日报 |「雪浪云」完成过亿元A轮融资;「小满科技」获阿里巴巴数亿元D轮融资;以及今天值得关注的早期项目

「36氪创投频道」报道的融资新闻,以及我们正在关注的各个领域早期创业项目。

原创文章,作者:28x29新闻网,如若转载,请注明出处:https://www.28x29.com/archives/31015.html