不懂技术的产品小王,聊聊他的日常囧事
产品经理,尤其是B端产品经理,是需要懂技术的,否则在方案设计和方案取舍上以及和RD的沟通上,都会吃亏。下文模拟了两个场景对话,向大家演示了这个问题。
情景对话1:RD和不懂技术的产品经理小王
小王:一名工作1年的初级产品经理,非计算机科班出身,不懂技术。
老李:一名工作5年的RD,经验相对丰富,做事相对保守。
(在老李工位前面,对话开始了。)
小王:“老李啊,找你聊个需求。咱们的分销运营管理后台上线了,业务人员中的新人比较多,我们想在管理后台的知识搜索功能中(画外音:案例中后台系统的搜索功能调用的是知识库系统的搜索引擎,分销运营管理后台本身没有搜索功能)加一个热词推荐的功能,也就是点击搜索框后,会弹出一些推荐的热词,这些热词是管理员在后台配置的。你看看,效果图类似这样(见下图的右上角)。”
老李:“嗯嗯,听起来比较合理,功能也是一个常规标准功能。后台怎么管理呢?”
小王:“我已经设计好啦,有一个热词管理页面,你瞅瞅,就是这样的(下图),能添加、删除热词,还能调整热词的顺序,功能强大!”
老李:“嗯……看起来设计得中规中矩,但是有必要这么复杂吗?”
小王:“这个功能设计得多讲究啊,绝对好使。做这个大概需要多久啊?”
老李:“呃,那就这样吧。这个功能想要做出来,预计前端开发需要5人日,后端开发需要10人日,测试需要5人日,总共预估20人日。”
小王:“啥?这么简单的功能,要20人日,你在坑我吗!?”
老李(有点生气):“什么叫坑你,我是实事求是地评估!”
小王:“不就是配几个词,然后用户搜索的时候提示一下吗?怎么需要20人日?你给我讲讲凭什么,讲不清楚我就找你领导!”
老李(愠怒):“爱找不找随便你,不过我跟你说清楚,实现你这个设计就需要20人日。首先实现热词配置表需要设计数据库表结构,然后要做各种代码读写数据库的处理,还有,前端要实现完整的增删改查操作,交互点非常多,编辑按钮、删除按钮、调整位置,这些都要处理!”
小王:“我不管,我的诉求很简单,就是能配置热词,能调顺序,为什么这点诉求都要开发20人日!”
老李(叹了口气):“你是不是想尽快上线?”
小王:“当然!多简单的功能!”
老李:“小伙子,是否简单,不是你说了算的,你都不理解背后需要做哪些工作。我问你,不就是配一张热词表么,你看这样做行不行,就一个文本框,一行一个词,要调整顺序什么的直接编辑这段文字就可以,想要增加或删除热词,都通过编辑这段文字来实现(下图)。”
小王(迟疑并思索):“这个,好像也可以,操作也不复杂,并且完全满足诉求。这样做需要多久?”
老李:“这样做的话,不需要设计数据库,只保存一个文本文件,前端控件也非常简单,预计前端开发需要2人日,后端开发需要1人日,测试需要0.5人日,总共3.5人日吧。”
小王(有点不好意思):“那要不就按您这个设计来吧,咱效率第一。”
老李:“小伙子,可以可以,知错就改,听得进去建议。”
小王:“还有一个问题,可以统计不同热词的点击量吧?”
老李:“呃,按照我给的设计方案,有点麻烦。因为这个方案中热词的配置是按照文本存储的,如果想记录每个词的点击数量,必须对文本进行解析,并且记录每个单词及其对应的点击量,处理逻辑又会变得非常复杂。”
小王:“那怎么办?我要统计热词点击量啊!”
老李心想:你咋啥都不会,都让我帮你想方案,那我直接和业务对接好了,要产品经理干啥?
但是,老李嘴上说道:“哎!年轻人,要么就按照你说的方案做,那样可以统计。还有一个办法,你去确认一下搜索框跳转的知识库系统,能不能识别出访问来源,我们可以通过对访问知识库的URL做一些处理,让知识库系统能够识别出搜索跳转的来源和词语。如果知识库系统有类似百度统计那样的功能,就可以通过知识库系统来统计热词来源和搜索量。”
小王一脸晕菜,心想:还能这样!URL怎么配置?怎么就能识别出来源和关键词呢?妈呀,我需要学的东西好多!嘴上说道:“好的好的,我去找知识库系统的产品经理了解确认一下,再来找您。”
上面案例中的类似场景在日常工作中很常见,产品功能的过度设计会导致技术人员进行无谓的开发工作。如果是负责任的RD,可能会刨根问底,和产品经理一起修正方案;如果是工作很被动的RD,可能就直接排期开发了,造成开发资源的浪费。如果产品经理对技术有基本的认知和理解,则可以避免这类问题的发生。
下面是第二个场情景对话,不懂技术的小王换成了懂技术的小刘。
情景对话2:RD和懂技术的产品经理小刘
小刘:一名工作5年的高级产品经理,非计算机科班出身,自学了很多技术知识。
老李:一名工作5年的RD,经验相对丰富,做事相对保守。
(在小刘工位前,小刘在思考。)
小刘(思考中):嗯,实现这个需求需要增加热词搜索功能,需要有一个热词配置界面。嗯,业务人员不需要查看热词编辑历史,只希望能够每周调整一次热词内容,并且希望能够统计热词的点击情况。热词配置界面可以尽量简化,一个文本框加一个保存按钮是个好办法;至于统计功能,已经和知识库的产品经理沟通好,可以通过跳转知识库的URL做一些格式调整,知识库可以识别并记录检索来源和关键词,这样就能统计出热词的检索量。好了,想得差不多了,拿着原型图去找开发人员吧。
(在老李工位前,对话开始了。)
小刘:“老李啊,我这儿有个需求,给你大概讲一下。”小刘讲完上述想法说道:“你看开发这个功能需要多久,大概估一下呗。”
老李暗想:这小子前段时间给我的需求积压了不少,我得缓缓。他咳嗽了一下说道:“这个嘛,你这个还是比较复杂的,这个搜索框要改,还有这个配置页面,看起来很简单;但是后台设计很复杂。我预估前端开发需要3人日,后端开发需要5人日,测试需要2人日,一共10人日。”
小刘(惊诧):“啥!?实现这么个玩意儿要10人日,你别忽悠我!”
老李:“我咋能忽悠你呢?这个后台设计可麻烦了,要有数据存储、处理、编辑啊,复杂得很!”
小刘(诡笑):“得了吧,就这么一个文本框,没有任何处理逻辑,写啥存啥,改啥存啥,后台要么就一个文本文件,要么就在数据库中找一个表维护一条数据的事儿,你这个评估好像不太合理哦,要么你再琢磨琢磨?或者我们让老杨(老李的leader)一起看一下?”
老李(一惊):“呃……你等等,我再看看,嗯,好像可以做得简单点,估计两三天搞定吧,也别找老杨了,就这么着吧。”
小刘(微笑):“好嘞,那我大概知道了。”
在本案例中,小刘自己对产品功能的实现复杂度有充分的判断,并且因为老李预估的水分太大,所以拿老杨稍微压了一下老李,老李最终重新给出合理的工时预估。
结语
以上两个情景对话,列举了不同能力层级的产品经理与RD,在方案设计和方案取舍上的沟通。 两个例子说明了,产品经理一定要懂得一些技术基础,才能在方案沟通上避坑避雷。
作者:杨堃,《决胜B端》作者,微信号公众号:goYangKun,11年互联网研发、产品设计经验,曾就职于传统外资保险公司、百度,现就职于vipkid。
本文由 @杨堃 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议
作者暂无likerid, 赞赏暂由本网站代持,当作者有likerid后会全部转账给作者(我们会尽力而为)。Tips: Until now, everytime you want to store your article, we will help you store it in Filecoin network. In the future, you can store it in Filecoin network using your own filecoin.
Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: