Debug≈MVP

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

如果你恰好对宇宙/火星感兴趣，也可以访问我做的微信小程序“每天看宇宙”，里面可能捕捉不到天鹅座的来信，但能看到NASA漫游者号回传过来的火星表面。

 

 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 才能关闭提示框。

 

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

 

 

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

 

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

 

 

往期精选：

好的产品需求文档拥有6个共性

增长黑客实战五步曲

微信红包封面热潮的背后