国外包装设计网,seo神马网站推广器,php开发网站怎么做,百度免费推广网站前两天网上有个程序员吐槽大会我看挺多人在转的#xff0c;这么公开黑产品经理#xff0c;除了娱乐效果之外#xff0c;确实也反映了很多问题。作为一个前程序员#xff0c;现产品经理#xff0c;我觉得还是得说几句。首先以产品经理的角度自省#xff0c;然后我再吐槽一…前两天网上有个程序员吐槽大会我看挺多人在转的这么公开黑产品经理除了娱乐效果之外确实也反映了很多问题。作为一个前程序员现产品经理我觉得还是得说几句。首先以产品经理的角度自省然后我再吐槽一下程序员。礼尚往来嘛01 吐槽产品经理做产品之前我是做技术的主要是做前端开发Android 和 iOS 通吃之前也做过一段时间的后端开发。到现在转产品 5 年多了以一个产品经理的身份也越发能理解为什么程序员对产品经理的意见那么大。其实最关键的一点就是“不确定性”。举几个例子你就明白了。第一个例子是需求评审在评审会上如果遇到一些没有定义清楚的问题通常有两种处理方法一种是当场聊清楚一种是事后再讨论。如果是第一种可能当时是聊明白了但是产品经理事后去完善文档时有可能和会上的结论有出入或者干脆忘记完善文档这回事了。程序员拿到文档去开发时很可能对这个问题的理解产生偏差导致开发出来的产品有问题最后这个锅谁来背因为都参会了也有共识但文档没体现。毫无疑问这个锅该产品经理来背。产品经理是决策者需要保证方案以确定性的状态进入开发环节不管是沟通还是文档。所以这种“不确定性”往往会令程序员比较反感。如果是第二种对于评审会上不确定的点进行会后讨论很可能出现因为别的优先级插入或者其他事情而忽略了这个问题。以至于当再次回来进入开发时之前的问题就是不确定的程序员如果根据自己的理解做了最后的结果肯定和预期是不符的。如果不做就会卡在那然后再找产品经理沟通。这中间一来一回效率其实挺低的。一旦不能进入写代码的环节程序员都觉得是在浪费时间。真的以前我就会这么觉得。聊了半天确定不了又有很多变数这种不确定性让我不敢轻易写代码。为什么一怕返工二怕背锅。所以啊产品经理如果想把自己的工作做好就需要提升自己对需求对方案的确定性提前功课做足一点。不仅是需求背景、意义目标、方案细节、可能的冲突、数据埋点这些还有就是对过程中的不确定性管理比如需求变更、优先级调整等都需要给到程序员非常明确的结论。一是一二是二别弄怎么都行的中间状态。那样真的很烦人。02 再次吐槽产品经理第二个例子是提需求。程序员吐槽大会中提到产品经理和程序员就像唐僧和孙悟空唐僧说“我就要取经”孙悟空说“那得杀了白骨精变成的妖怪”唐僧觉得不能滥杀无辜孙悟空又说“那怎么办”唐僧说“我不管我就要取经”。说实话我挺认同这段的。做技术时也确实见过这样的产品经理做产品后也见过这样的业务方。这个需求很简单怎么实现我不管明天上线。就是这么直白(沙雕)。作为程序员面对这样的产品经理和作为产品经理面对这样的业务方内心一万头草泥马奔腾而过。他们听不进也无法理解你的表达死死抓住自己的需求并强烈的 push 给你。这种情况通常是两个原因第一种是真的不懂第二种是传话筒。先说第一种情况真的不懂。不得不说大部分的产品经理是不懂技术的这是行业现状。但也有越来越多的产品经理开始学习和了解技术我一直说产品经理不需要具备技术能力但需要掌握技术思维。简单说技术能力就是能上手写代码、能改bug。技术思维就是能听懂程序员的表达、能理解功能背后的技术原理。有些产品经理带着需求过来找程序员准确说是带着原型过来找程序员沟通也不说为什么要做也不说做了能带来什么好处开篇就描述功能该怎么实现。要么功能对现有的技术实现方案改动很大要么就是技术成本很高。程序员用技术语言告诉产品经理为什么做不了产品经理反正也听不懂然后继续死拽着这个需求向程序员 push矛盾就这样产生了。再说第二种情况传话筒。领导或者业务方来了个需求产品经理本身也没很好的理解也没有对需求做转化直接就落到程序员这里。拿着尚方宝剑说这是上面来的需求只能做。程序员此时是无语的一个奇葩需求还非得让我写代码实现沙雕得不行。让你产品经理吸气的同时呼气你做一个试试我做技术时遇到类似需求就是这样的感觉非常不爽。然后觉得产品经理整天都在干啥呢这种情况就是典型的没有对需求做转化有的甚至是直接把业务方案落地成技术需求没有经过中间的产品方案。这就是产品经理工作的不到位了。世界上这么多软件、这么多需求如果是一个逻辑合理场景成立的需求在技术层面实现是没问题的。此外产品方案也不是唯一的先入为主的拿着老板或者业务方的方案就觉得是唯一解那只能说动脑还不够没有发挥自己的专业性在业务和技术间寻找好平衡。回忆一下是不是一些沙雕需求其实都有 plan B 的做法。03 产品经理吐槽说完了产品经理下面就该吐槽一下程序员了。“这个页面对应的是一个 Activity如果要加个按钮新开一个页面我需要改一下 Layout 然后在代码里新写一个 Intent”。说实话有哪个产品经理看懂了上面这句纯技术语言很少是吧这是 Android 开发用语。简单说就是一个页面对应一个布局文件(Layout)按钮摆在哪长什么样都在这个文件里登记记录了。每个页面的操作都由配套对应的中央处理器(Activity)来控制页面的跳转和更新逻辑都登记在里面。而 Intent 就是一个消息将一个事件通过消息传递出去。我当过程序员我也跟程序员合作过。用技术术语跟外行对话的毛病真的得改不是所有人都懂这些天书说人话很重要。业务用一堆营销和行业术语跟你说话你也懵逼是一样的。再说一个。“你找下后端把这个字段定义清楚吧我不知道具体的数据类型是什么”产品经理肯定遇到过这样的前端。而实际上后端程序员就坐在他的前面非得找产品经理转一下。拜托技术问题你们不能直接面聊么没必要这么含蓄。还有。别总觉得产品经理安排活儿如果没人安排活儿天天在那写 bug 么市场是变化的需求也是变化的互联网变化这么快我们也没法一招鲜吃遍天。04 产品经理再次吐槽被堵住是什么感觉就是程序员说“这个需求做不了”的时候。真的在你说了一堆后最后这么来一句也不告诉你为什么做不了。大家都是专业人士专业人士都讲科学依据、有理有据为啥做不了说出来结论容易下过程难推导。如果做不了是否有其他可行的方案别用一句话把大家的路都堵死堵路不要紧关键是心堵。咱们都是合作方相互扶持才是正事嘛可能有程序员觉得产品经理水平不行同样程序员怎么证明自己的水平真的行呢每个人的认知边界都是有限的。早上跟老板聊、上午跟业务撕、中午写方案、下午开评审会、晚上还要把评审会要修改的东西拿回来返工。可能程序员只看到了自己和产品经理的这一环其实还有很多糟心事他们没感受到。说产品经理没事干的工作不饱和的过来轮岗两天试试就明白了。程序员觉得跟产品经理说不通那一定是没试过跟业务沟通需求有多费劲产品经理是挡了多少刀才把需求筛选到技术那。大家都不容易互利共生才是正事呀。写在最后以上当然不是针对程序员或者产品经理有的也只是玩笑。程序员和产品经理同在一家公司公司好大家好出来做事的嘛最重要的就是开心咯少一些怀疑和抨击多一些耐心和理解狗和猿还是可以和谐相处的。当产品上线被用户被市场认可的那一刻相信所有的吐槽都会烟消云散一起享受成功带来的快感。祝程序员和产品经理们工作快乐#专栏作家#唐韧(Ryan)微信公众号唐韧人人都是产品经理专栏作家。前Juliye Care产品总监《产品经理必懂的技术那点事儿》作者在创业公司负责过多款从0到1产品目前在某电商巨头负责产品工作 。本文原创发布于人人都是产品经理。未经许可禁止转载。题图来自Unsplash基于CC0协议给作者打赏鼓励TA抓紧创作赞赏
