Debug(代码调试)≈ MVP(最小可行性产品)

最近捡回了代码这门手艺,上线了一款微信小程序。表面上看研发岗和产品岗需要掌握的知识和工作流程都不一样,从近期实践中通过一些技术理念联想到一些产品感悟,下面和大家一起聊一下一下技术和产品有哪些“共性”。

Debug(代码调试)≈ MVP(最小可行性产品)

开发5分钟,调试2小时,这是我最初写代码的真实现状,因为当初不懂如何去debug,写了一大坨代码,然后自信点击运行控制台显示报错,如果用的比较旧的IDE编辑器光靠浏览去发现代码问题,效率非常低下。比如变量名拼写错误,部分语句出现中英文符号等,可能找个大半天。debug能够比较快速的定位代码问题,控制程序的运行节奏,确定程序的运行路径,不断缩小范围,找到出错位置,最终修改成功运行。

做产品有没有像代码debug一样,能够一步又一步的加以验证?特别是做C端的朋友一定经常遇到以下的情景。

一头小马跑到河边,刚抬起前蹄,旁边的松鼠就大叫了起来,你不要命啦!小马说,让我试试吧,它下了河,小心的趟过去。原来河水既不像老牛说得那么浅,也不想松鼠说的那么深。很多事情只有自身去做了,才会有感受。否则听从他人建议或反馈都是相对的,最好的做法就是先做一个最小可行性产品(MVP),一步一步加以验证去达到产品与市场契合度(PMF

在企业组织上字节跳动的部分业务线也是追求快速获取结果,而结果需要尽可能是好的,如果不好就迅速调整。首先会保证管理及执行的人在能力预期上没有问题,其次目标清晰,如果结果不如预期就立马更换下一批顶上,组织的快速调整有助于始终让团队走在正确的冲刺道路上。所以在外界还有另外一个风评,说字节是靠“迭代中高层管理”来推动进展的企业。

不管是代码的debug,利用产品MVP找到PMF,还是字节跳动的管理调整,本质都是通过小步验证测试重复性调整,来达到提高容错,达到成功。

code review ≈ 产品复盘

Code Review可以理解为一群人对一坨代码基于某种规则下进行审查,找出违背相关规则的代码块提出解决方案,既能够提高代码的质量还能够提升个人成长,这算个人及整个研发团队极其有效的进步方式之一。

产品团队也有相似的进步方式,针对项目/版本做有效复盘,也能得到快速的成长,具体怎样才算是有效,包含以下3个结论

  • 什么不该做
  • 什么继续做
  • 什么开始做

以“积分体系”为例,现在积分体系是很多产品的标配,在幻想着上了积分体系就能提高用户活跃和留存,但现实给你来了一大嘴巴子。

在复盘时找准关键要素和预期目标,如积分体系可以按“任务完成度”和“是否贴合业务目标”来来进行复盘调整。

  • 对于完成度低且业务无关的任务尽可能的剔除
  • 对于完成度低且是核心业务的任务,适当降低任务难度并且提高完成任务奖励(缩短任务路径,自动领取)
  • 对于完成度高且与业务目标影响不大的任务,尽可能剔除或者降低完成任务奖励

什么不该做,比如发现点赞完成度非常高且占比积分来源很高,但点赞与被点赞对平台和用户均无有效作用时,是否可以考虑删除。

什么继续做但需要调整,比如“邀请好友”是一个核心任务,但完成度比较低是否应该提高奖励还是降低难度门槛,但如果深挖发现“邀请”过来的用户均是非质量用户,此时是否重新平衡一下邀请难易度,如好友注册后登陆 获得X 次日登陆获得Y。

什么需要开始做,比如发现积分持有人数和数量呈两极分化,即没有养成新用户获取积分习惯,有一个1积分就能兑换的礼物,感受到积分的价值后是否能让新用户养成活跃持续留存。

失败从来不是成功之母,高质量的复盘才是。

代码追求可复用 ≈ 产品追求架构最优

可复用指的是一段代码可被多处地方调用执行,而不需要重新编写一遍,如点击跳转至新闻列表和在新闻列表下拉刷新,两个动作在代码逻辑本质上都是获取最新的内容数据,如果在点击跳转处和列表下拉分别写上两段获取内容数据的代码,显得代码冗余且维护不便,一旦涉及变动则两处地方都要修改。如果把获取内容抽象成一个方法,供点击跳转和下拉请求时调用,则变得十分友好。

为什么有些产品给人感觉十分笨重,有些产品给人感觉流畅清晰的体验,除了产品本身的业务复杂性外,产品架构也有优秀和平庸之分。

张小龙在2021年微信公开课末尾提到的微信依旧保持简单和“小而美”,很多人会把微信占用手机存储空间或者安装包大小来进行反驳。如果以存储空间或安装包大小来衡量产品是否“小而美”,恐怕只有闹钟、备忘录这类应用符合大家胃口。

简单和小而美由微信产品架构带来的结果。简单建立在易理解性上, 确保用户方便找到和轻易使用,如微信内有多个扫一扫入口,并没有追求绝对简单只保留一个扫一扫入口。小而美建立在高拓展性上,如果拓展性弱产品只会越做越臃肿。

从更高维去看,其实代码可复用程度和产品架构高度挂钩,优秀的产品架构能够让多处代码得到复用的可能,同时如果意识到多处代码可复用,能有效遏制不良的产品架构,这也是为什么研发人员的架构能力比产品人员的要更强一些,因为考虑到了技术架构和拓展性。

在微信自带开发者工具中会提醒wx.showLoading和wx.hideLoading必须配对使用,这是为了避免程序进入“死循环”,因为在调用wx.showLoading时会显示 loading 提示框。需主动调用 wx.hideLoading 才能关闭提示框。

为什么有开发会对产品贴上“不靠谱”标签,据了解多数都是因为在对接中产品需求逻辑不够完善,一些异常流程经常性忽略。因为产品经理在设计流程时都往好的一方面去思考,没有考虑到较差的一面。有发布成功的结果就会有发布中状态和发布失败的状态。

关于产品人员需不需要懂技术,该懂多少这一话题一直有两种声音,有人认为产品经理最好的情况是不懂技术,这样才能突破边界。恰好又有人觉得如果懂技术,可能会限制产品本身。个人认为,明确自己边界比突破边界更为重要,因为大多数产品设计是需要在边界认知内完成。

产品人员不能光有天马行空的想法,需要在一定的事实之上,否则只是在无效的工作上浪费时间。如果熟悉前端组件的相关属性以及对应属性的值可以快速得出决策,以调起相机为例, 闪光灯和摄像模式等都是相机组件的属性,而属性又有对应不同的值,比如摄像模式是扫码还是拍照/录像,闪光灯是开启还是关闭等等。知道相机有那么多属性不影响突破产品边界,更不影响做出一款好的相机产品,反而如果不知道则无法评估实现预期和成本。

—— 如果觉得文章还OK,请转发 ——

特别提示:关注本专栏,别错过行业干货!

PS:本司承接 小红书 / 淘宝逛逛 / 抖音 / 百度系 / 知乎 / 微博/大众点评 等 全网各平台推广;

咨询微信:139 1053 2512 (同电话)

首席增长官CGO荐读:

更多精彩,关注:增长黑客(GrowthHK.cn)

增长黑客(Growth Hacker)是依靠技术和数据来达成各种营销目标的新型团队角色。从单线思维者时常忽略的角度和高度,梳理整合产品发展的因素,实现低成本甚至零成本带来的有效增长…

本文经授权发布,不代表增长黑客立场,如若转载,请注明出处:https://www.growthhk.cn/cgo/product/41451.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
kuko1028的头像kuko1028
上一篇 2021-06-24 10:41
下一篇 2021-06-25 11:31

增长黑客Growthhk.cn荐读更多>>

发表回复

登录后才能评论
Optimized by Optimole
特别提示:登陆使用搜索/分类/最新内容推送等功能 >>