没人会帮你考虑产品逻辑,除了产品经理你自己

记得刚刚开始做产品的工作的时候,内心和网上的萌新一样,总有“产品经理需要懂代码吗”的疑问。

这个问题一直藏在心里,项目评审的时候,内心其实也是有点需的。

直到在某天搬砖的时候,发现产品中一个很小的功能在某些边界条件下的表现并不符合预期。追根溯源发现最开始的错误是需求文档的定义的逻辑有一些方面考虑的不够清楚。

虽然最后是“完美”的修复了这个BUG,但是这件事让我深深的感知到不论是产品还是研发,其实最重要的技能是逻辑思维,最重要的业务能力是深刻理解负责的产品(模块)以及背后运行的规律

产品的定义其实需要考虑的也不仅仅是用户看起来这个功能是怎么样的,更重要的是将边界条件考虑清楚

下面我们以该此“BUG”为例,从发现到解决的过程,最后是一些思考。

事件背景

直播平台的聊天室,在有新消息到来的时候,都设计成会自动滚动的形式,这样用户就能看到实时的消息了。

那么如果消息刷得太多了,自动滚动就会造成某些消息还没看到就被刷上去了,这个时候用户一般都会用手来滑动聊天室。但是屏幕的位置不是无限的,滑动聊天室的时候手指总会离开屏幕,如果在离开屏幕的时候又来了一条消息,那么聊天室就会自动加载到最新消息处。

就需要做一个在滚动聊天室的时候,聊天室不再自动加载新消息进来的功能。

而我在某次确定版本需求的时候,发现PC端该功能已经上线了类似的功能很久了,就直接仿照PC来输出了文档。

功能:用户在聊天室下滑之后,聊天室有其他用户发言,也不再自动滚动,即聊天室停止在当前用户滚动的地方。并且只要聊天室停止滚动,左下角就出现一键置底的按钮提示


偶然发现的BUG

功能看似很简单,文档也考虑到了某些交互,似乎一切看起来是没有问题的,并且需求评审通过,开发没有问题,测试没有问题,验收时候也符合预期。

但是功能上线之后,我在某次几进入万的房间后,发现即使消息悬停了,仍然会刷新,如下图。(左下角的标志就是说明聊天室“停止”滚动了


退出了直播间,进入其他直播间,发现功能并没有问题。又再次进入到这个直播间,刚刚开始的时候功能是没有问题的,过了一会发现功能还是有问题。

为什么在这个直播间就有问题呢?这个直播间和其他直播间有什么区别呢?为什么刚刚进入直播间的时候功能就没有问题,需要过一会才有问题呢?

问题的原因

仔细探究发现这个直播间和其他直播间最大的区别是,这个直播间观众并发数很多,这个直播间的发言也很多

为什么观众人数多就会有问题呢?为什么发言多就会造成功能不符合预期呢?到底是因为人数多而产生的问题还是发言多产生的问题呢?

我突然想到了偶然间读过的公司归档的文档好像写过

聊天室最多储存250条消息,当超过消息的时候会自动删掉最早的消息

在询问了研发之后,证实确实有这个逻辑,防止APP的内存无限增加导致崩溃。但是这个逻辑不读代码,几乎是没有人知道的

因此结论显而易见,这个BUG最根本的原因是观众人数太多,发言的人就多,发言多导致前面的消息被自动删掉了。

推测研发实现功能的时候,是将聊天室由上到下分成0-250个队列,当聊天室停留的时候,实际上是停留在了某个对了区间范围内

例如用户将聊天室界面停在了230-240条的位置。但是此时后面再来10条消息的时候,原先的第230条消息就变成了第240条消息。所以在用户看来,消息莫名其妙的自动向上滚动了,但是其实消息仍然停留在230-240条。

问题的解决

发现了问题之后,由于对技术问题不太清楚,因此询问研发同学解决方案,研发同学提供了三种方案进行选择。

一、增加一个缓存队列,消息到来之后进入缓存队列。

二、换一种实现的方式。

三、增加缓存队列,并且增加缓存队列的删除机制。

三种方案都各有利弊。

第一种方案其实并没有真正解决掉问题,因为只是简单的加入了缓存队列,当缓存队列满了之后,仍然会继续滚动。但是该方案是改动成本最小的,并且继续滚动的概率较低

第二种方案可以完美解决掉问题但是需要付出较大的产品、设计、研发成本,为了一个小的体验功能,显然是不够经济的。

第三种方案是第一种方案的优化版本,改动成本中等,并且不会继续出现这种情况。但是缺点是会使得聊天室未读的消息被删掉

最终在改动成本,用户体验之间抉择,还是选择了第三种实现方案。

实现的动图


这个方案消息虽然被删掉了,但是如果用户一直将聊天室停止,那么他其实也就没看过新消息,也就不知道有消息是被删掉的。对于用户来说删掉和不删掉是没有差别的。

问题的感悟

一、产品经理并不需要懂得代码,但是需要大概懂得一项功能的实现逻辑。不懂得代码无所谓,术业有专攻,具体的实现代码交给专业的人去写,只需要让研发用都能听得懂的语言描述代码实现的逻辑即可

二、除了产品经理,并不会有人关心产品逻辑是什么。对内,研发只考虑怎么实现产品文档,测试只考虑研发实现是否符合文档;对外,用户只考虑功能好不好用。功能合不合理,功能的边界条件,就需要产品经理独自去思考,去定义。例如这个功能就是没有考虑到以前的业务逻辑,就没有考虑到触发了以前的业务逻辑的时候这个功能会怎么表现。

三、产品经理其中一项重要的技能是选择,在成本、用户体验之间做抉择。需求总是无止尽的,但是不论什么公司,人力始终是有限的。如何在最小的成本之中,满足到用户的需求。这也就是俗称的挖坑,当前的功能可能只符合当前的需求。但是按照我的经验,功能最好考虑到接下来三四个版本的情况,无需再远。

四、在做抉择的时候,会有比较多的方案作为备选,到底选择哪一个方案,还是每个方案都不选择而是结合方案创新提出一种方案?其实就是考虑一个人产品的能力。是最完美的方案好?改动成本最小的并且影响面最小的好?

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,922评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,591评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,546评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,467评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,553评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,580评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,588评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,334评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,780评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,092评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,270评论 1 344
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,925评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,573评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,194评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,437评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,154评论 2 366
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,127评论 2 352

推荐阅读更多精彩内容