您当前的位置:宇宙旧居网>科技>产品经理吐槽大会,程序员勿入

产品经理吐槽大会,程序员勿入

2019-11-07 11:43:46 来源:宇宙旧居网

两天前,有一个在线程序员抱怨会议。我看见很多人转过身来。除了娱乐效果,这样一个开放的黑色产品经理确实反映了许多问题。作为一名前程序员和现任产品经理,我想我还需要说几句话。首先,我从产品经理的角度考虑我自己,然后我将谈论程序员。这是一次公平的礼貌交流!

在我制作产品之前,我做了技术,主要做前端开发,安卓和ios一体机。我之前也做过一段时间的后端开发。

自从我换产品以来,已经有五年多了。作为一名产品经理,我能理解为什么程序员对产品经理有这么多的看法。

事实上,最关键的一点是“不确定性”。

举几个例子,你就会明白。

第一个例子是需求审查。如果有一些问题在评审会议上没有明确定义,通常有两种方法来解决。一是当场讲清楚,二是以后再讨论。

如果是第一个,当时可能已经很清楚了,但是当产品经理后来改进文档时,他可能会从会议中得出不同的结论,或者他可能只是忘记了改进文档。

当程序员得到要开发的文档时,他们可能会对问题产生误解,从而导致开发的产品出现问题。谁来承担责任?

因为每个人都参加了会议,并且达成了共识,但是文件没有反映出来。毫无疑问,产品经理会带着这只锅。

产品经理是决策者,需要确保计划以确定的状态进入开发阶段,无论是沟通还是文档。因此,这种“不确定性”经常使程序员不喜欢它。

如果是第二种类型,如果评审会议中的不确定点在会后讨论,则该问题很可能由于其他优先级插入或其他原因而被忽略。

也就是说,当它们再次恢复发展时,以前的问题是不确定的。如果程序员按照他们自己的理解去做,最终的结果肯定不符合预期。

如果你不这样做,你会被困在那里,然后和产品经理谈谈。

这一次,效率实际上相当低。一旦不能进入代码编写链接,程序员觉得是在浪费时间。

真的,我以前也这么认为。聊了很长时间后,我不确定,还有很多变数。这种不确定性让我不敢轻易编写代码。

为什么,一个害怕返工,另一个害怕拿回罐子。

因此,如果产品经理想做好他们的工作,他们需要提高对计划需求的确定性,并提前做好功课。

不仅是需求背景、意义目标、方案细节、可能的冲突、数据嵌入点,还有过程中的不确定性管理,如需求变化、优先级调整等。,都需要给程序员非常明确的结论。

一是一,二是二,不要夹在中间。真烦人。

第二个例子是提高需求。

程序员在会议上抱怨说,产品经理和程序员就像唐僧和孙悟空。唐僧说:“我要学习经文。”孙悟空说:“那会杀死白顾靖变成的怪物。”唐僧觉得无辜的人是不能被杀死的。孙悟空又说:“我该怎么办?”唐僧说:“我不在乎,我要向经文学习。”

老实说,我非常同意这篇文章。我在从事技术工作时确实遇到过这样的产品经理,我在从事产品工作时也遇到过这样的商业聚会。

这个要求非常简单。我不在乎它是如何实现的。我明天将上网。这太简单了(沙雕)。

作为一名程序员,面对这样的产品经理,作为一名产品经理,面对这样的商业方面,一万匹草泥马疾驰而过。

他们不能听你的,也不能理解你的表情。他们坚持自己的需求,给你强大的推动力。这种情况通常有两个原因。第一个是你真的不明白。第二个是你发射麦克风。

首先,我不太明白第一种情况。

我不得不说,大多数产品经理不了解技术,这是行业的现状。

然而,越来越多的产品经理开始学习和理解技术。我一直说产品经理不需要有技术能力,但是他们需要掌握技术思维。

简而言之,技术能力就是写手写代码和纠正错误的能力。技术思维是理解程序员的表达和函数背后的技术原理。

一些产品经理带着需求,或者确切地说,带着原型来与程序员交流。他们也没有说他们为什么想这么做或者他们能带来什么好处。一开始,他们描述了应该如何实现这些功能。

要么功能对现有技术实施方案有很大改变,要么技术成本很高。

程序员用技术语言告诉产品经理为什么他不能这样做。产品经理无论如何也不能理解它,然后他继续把需求推给程序员,这样就产生了冲突。

在第二种情况下,发射器。

领导者或业务部门提出了一个需求,而产品经理对这个需求没有很好的理解,他也没有转换需求,这个需求直接落到了程序员身上。他手持御剑,说这是上天的要求,只能这样做。

程序员此时无言以对。我必须写代码来满足一个奇怪的需求。我不能做好沙雕。

让你的产品经理同时吸气和呼气,你试试!

这就是我在从事技术工作时满足类似需求的感受。我很不舒服。然后我想产品经理一整天都在做什么?

这种情况是典型的不转化需求的情况,有些甚至不经过中间产品计划就直接将业务计划转化为技术需求。

这是产品经理的工作不到位。世界上有如此多的软件和如此多的需求。如果需要建立一个逻辑合理的场景,那么在技术层面实现它是没有问题的。

此外,产品计划不是唯一的计划。老板或商业方面的先入为主的计划是唯一的解决方案。只能说,仅仅用大脑和不展示自己的专业知识来在商业和技术之间找到一个良好的平衡是不够的。

回想一下一些沙雕需求是否真的有最佳实践计划。

说到这里,产品经理,是时候向程序员吐口水了。

“这一页对应一项活动。如果我想添加一个按钮来打开一个新页面,我需要更改布局,并在代码中写入一个新的意图。”

说实话,哪个产品经理理解上述纯技术语言?很少,不是吗?这是安卓开发语言。

简而言之,一个页面对应于一个布局文件,按钮放置的位置和它们的样子都记录在这个文件中。每个页面的操作由相应的中央处理单元(活动)控制,并且页面的跳转和更新逻辑被注册在其中。意图就是一条信息,通过这条信息传递一个事件。

我是一名程序员,也和程序员一起工作。使用技术术语与外行人交谈的问题确实需要纠正。不是每个人都理解这些天书。说话很重要。

企业用一系列营销和行业术语与你交谈,你同样感到困惑。

还有一件事。

“你可以找到一个后端来清晰地定义这个字段,我不知道具体的数据类型是什么,”产品经理肯定遇到过这样的前端。

事实上,后端程序员坐在他面前,不得不求助于产品经理。拜托,你不能直接谈谈技术问题吗?没必要这么微妙。

还有。

不要总是认为产品经理安排了工作。如果没有人安排工作,你会每天在那里写错误吗?市场在变化,需求也在变化。互联网变化如此之快,以至于我们不能一次吃掉它。

被阻挡是什么感觉?

这时程序员说“这个要求不能满足”。的确,在你说了很多之后,最后一句话不会告诉你为什么你不能做。

每个人都是专业人士,专业人士都在谈论科学依据和合理证据。为什么他们不能说出来?得出结论容易,推断过程难。

如果没有,还有其他可行的计划吗?不要用一句话堵住每个人的路。如果你阻塞道路并不重要,关键是阻塞你的心。

我们都是合作伙伴,相互支持是生意!

可能有程序员认为产品经理不好。同样,程序员如何证明他们的水平真的很好?每个人的认知界限都是有限的。

早上和老板谈话,早上撕毁业务,中午写计划,下午开一个检讨会,晚上把需要修改的东西带回来返工。

也许程序员只看到了他们自己和产品经理的这一部分,但是仍然有很多不好的事情他们没有感觉到。

据说产品经理无事可做,工作没有饱和。过来试两天。

程序员认为这对产品经理没有意义。一定是他们没有尝试与企业沟通有多难。产品经理需要切割多少把刀来筛选技术要求。

这对每个人来说都不容易。互利共存才是真正的事业。

以上当然不是针对程序员或产品经理的,有些只是笑话。

程序员和产品经理在同一家公司。这家公司对每个人都有好处。最重要的是要快乐。

带着更少的怀疑和批评,更多的耐心和理解,狗和猿仍然可以和谐相处。

当产品上线并被市场认可时,我相信所有的随地吐痰都会消失,我们将一起享受成功的快乐。

祝程序员和产品经理工作愉快!

瑞安,微信公众号:唐仁,每个人都是产品经理专栏作家。《产品经理必须了解哪些技术》一书的作者、前juliye care产品总监,负责初创公司从0到1的许多产品,目前负责一家电子商务巨头的产品工作。

这篇文章最初发表于《人人都是产品经理》。未经允许禁止复制。

主题地图来自unsplash,基于cc0协议。

贵州十一选五

  • 上一篇:脱欧协议修改文件未达欧盟要求 爱尔兰:仍存鸿沟
  • 下一篇:Austrian Solar:签署又一86MW智利太
  • 新闻
    栏目资讯
    推荐

    Copyright 2018-2019 hdpau.com 宇宙旧居网 Inc. All Rights Reserved.