不懂技术的产品小王聊聊他的日常囧事

　　产品经理，尤其是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端》作者杨堃，目前在VIPKID任产品总监一职。在工作中，遇见有很多优秀的B端产品经理，但缺少体系化、针对B端产品的实操训练，在成长中走了许多弯路。
　　我努力将自己多年做B端产品的经验提炼总结出来，和起点学院联合打造了一门B端产品体系课《ToB产品实战训练营》希望能给需要的同学一些实质性的帮助。
　　帮助大家构建B端产品知识体系脉络，掌握B端产品建设，从业务诊断、需求分析，到抽象建模、设计落地的全过程的方法思路，最终直接应用于工作实践。