产品经理提需求时是否应该考虑技术实现难度?

产品经理了解技术,有助于和研发人员沟通。但了解技术后,在提需求时,会权衡需求和实现难度。有人说产品经理提需求时,只需要考虑用户需求,不应该考虑技术实现难度,这样做是否正确?
阅读全文
请先 登录 后评论
  • 0 关注
  • 0 收藏 82 浏览
  • 略问用户 提出于 2020-10-22 17:37:52

84 个回答

xxxxxa

从本质上来说,没有实现不了的需求,只是实现的代价有多大,价值高不高,打开需求的姿势对不对

这个问题要从几个方面看:

1. 从产品本身来看需要你确定这个需求的价值,可以从KANO模型,ROI投资回报率上来对需求重要性排序,优先做有价值的东西,时间来不来的及

2. 确定了价值,下面就是需求实现的问题,一般来说需求是有多种实现方式的。不仅仅是技术上的,还有其他表现形式上的。打个比方,用户说要可乐,基本的需求是因为渴了,而你如果提供矿泉水其实一样能解决问题,这个需要你从本质上理解用户需求;技术上,实现一个功能,可能写一个工厂方法就可以简化很多事情,而开发也可以己脑洞大开过度设计(这种对于入门没多久又有理想的程序员是比较常见的)。这个在提需求的时候,你提给开发的需求更应该说用户story,而不是描述解决方案:规定好他应该怎么做。同时尽量找开发领导提前沟通需求,这样有可能他会给你一种更加好的实现方案

3. 最后就是努力充实自己,面向对象的编程思维可以多了解了解。产品经理的UML工具其实就是面向对象的思考方式,你可以不用管这个方法具体是通过写了多少行代码实现的,只需要想通中间的逻辑是怎样的即可,这样又可以反过来促进你了解:你的设计中有没有遗漏什么,下一版功能可以往哪拓展;从整体逻辑的复杂性推算功能的实现时间,对整体开发时间的估算越来越有把握,避免被开发忽悠

请先 登录 后评论
xxxxxa

沟通这个话题永远都聊不完,我见过专业能力不怎么样但是沟通能力强情商高的产品经理在职场上顺风顺水,却从来没有见过不会“说话”不懂人情世故的产品经理能在职场上顺利的。

所以现在抛开流程,机制等等不讲,谈下个人,产品经理的基础素养里面,数据分析,UED这些应该逐渐成为基本技能,说服不了开发和设计的原因不在流程,而在个人。

在假设大家都是做事情的基础上,有以下几点可以办。
1、用数据说话
这次的优化改进预期能带来多少的提升,上次的改进效果如何如何。这些是数据和预估。任何一个做事的人都必须正视数据。是数据反映这个改进有没有作用。当然,预估要准确。
2、尝试用户的视角来看优化
技术,开发在这个产品上有双重身份,一方面是开发者,要评估实现方式,实现成本,开发周期,另一方面是用户,因为这个用户比较“专业”,所以有时会丧失细节,毕竟开发者是按照自己的偏好来看产品的。
尝试从这两个角度来看问题,然后给对方一个理由。是否是成本不可行,还是因为对方在用户视角里面考虑了自己,而没考虑大部分用户?如果是,说出理由,证据。
3、冷静想清楚自己的建议是否是用户的诉求
是否也因为自己的偏好而去改产品,有没有基于用户视角,CE,UED,数据,技术等多角度的思量?

将以上的这三点思考一下,在沟通之前做好被拒绝的准备,心态好一点耐心一点,正常的话整个推动过程是顺利的。如果做到三点研发还是拒绝说实现不了,那么就跟CTO或者CEO沟通吧, 让他们来决策。

请先 登录 后评论
xxxxxa

你认为简单的开发起来并不简单,你认为很难实现比较复杂的对于技术来说也许并不复杂,关于需求是否合理,是否具有开发性,需要多方面的评估

1.需求来源:如果是已有产品的功能更新,用户习惯性问题想更改使用流程,这部分需求提都不要提,相当于是否认开发前期的成果;

如果是功能优化,用户的使用反馈和建议等方面的数据委婉的告诉开发,这种方式忽然好,但是用户达不到这个水平,如果以一种更简单的方式会更容易接受;

2.需求的市场调研:有一些系统性的产品开发,有很多细节的问题大同小异,其实用户既然提出这个需求说明是见过别人有,而且初步认可了这个功能;有些小而精,有些大而全,如果需求的实现结果一致的话,开发那边不会轻易的改变实现的方式;

3.需求的使用:有些功能隐秘性比较强,有些用户不易轻易发现,而且这个功能又是一个亮点;开发一般会把普遍使用的基础性功能放在显眼的地方,个人小小的创意性功能由于位置有限会隐藏起来,而一旦用户发现认可并强烈需求时,可以向开发提出改进的方案;

4.需求的合理性:需求是否合理,且技术上是否可以实现,一般开发工作量比较大,且手头项目都不止一个,时间上面比较紧迫!有些需求异想天开的话,开发几乎都不愿意去了解,所以需求的评估和过滤还是非常重要的!

请先 登录 后评论
xxxxxa

是的。你得站在程序员的角度,他是你的第一个用户。

请先 登录 后评论
xxxxxa

其实技术同样是团队成员,整个团队的目标和氛围与产品经理的主动营造很有关系。

1、目标。

要让团队成员和技术知晓一些重点功能背后的价值和目的。这才能让整个团队清楚重要性。团队成员每个人都可以对产品提建议,有的时候产品人员需要拿出各种方法来说服成员,包括使用客观的调查数据等;

重要功能轻易不能妥协。

2、梳理业务逻辑

技术在实现上本身就是一个逻辑活。

有的时候产品经理与技术沟通过程当中,很多就是因为逻辑的偏差导致需求无法实现。将自己的业务逻辑梳理给到技术很重要。

3、表示难度太大,搞不定?

原因1:技术不懂且是个不主动的人(态度问题)。——产品人员去谷歌、技术社区、找技术的领导一起讨论等,帮他一起找技术方案的资料。

原因2:技术方案可实现但难度大。——假若这个功能真的极其重要,一起讨论解决方案。短时间内有没有低成本的变通的方案;难度大的技术方案局限在什么地方;实现技术方案需要耗费多少时间成本和其他成本。

最后说一点,有时候花费大量精力做出来的功能也许真的与你之前的想象完全不同,所以在没有真正的定论之前,最好用最小成本先上去妥协版的,甚至是个demo,先测试。有数据都好说话。

请先 登录 后评论
xxxxxa

产品经理提需求时要考虑技术实现难度。

WechatIMG2696.jpeg

上图是我自己整理的提出需求时需要思考的问题。

考虑这项需求带来的价值、技术可行性、开发成本。如果这个需求有参考某家产品,考虑该功能该产品的开发资源、大概的开发周期、他们技术开发的技术背景,评估我们的开发周期。如果这个需求目前没有竞品可参考,也要开发们考虑实现难度。

举例,美团最先推出团购购买后支持退款的功能。购买商品支持退款的功能,会提升用户体验,减少客服部门的工作量,但相应的支付流程有调整,有技术开发成本,是否会有用户多次购买多次退款的风险出现不确定。但美团上线这个功能,当时团购产品数据有很大的提升。(案例来自PMCAFF产品经理 线下课分享)

作为一个没有技术背景的产品小白,我在想需求时,之前总喜欢问技术"这个实现起来难吗?"我们技术一般都直接反馈说:“不用先考虑难不难,这个我们来负责实现。你先考虑需求。”【此处笔芯我们帅气的开发们】所以要提出靠谱合理的需求,具体的实现方式再说。

请先 登录 后评论
xxxxxa

产品经理如果懂技术,能考虑到技术可行性是比较好的,开发也喜欢这样的产品经理。但是,不能限于技术细节不能自拔,如果每次提的需求都没有技术挑战性,开发团队始终处在舒适区,以后遇到重大产品升级和技术创新,就可能掉链子了。

所以,还是要优先考虑产品价值,如果一个需求能带来巨大的用户价值,即使技术自我感觉不太可行,也要试一下,不经过开发否定的技术难点,都不算技术难题。开发都没否定技术方案,产品自己“想当然”就放弃了,那是多么的可惜啊。

记得第一份工作的总监亮亮跟我说过,技术上可以实现不了,但产品一定要想到各种可能的方案。

请先 登录 后评论
xxxxxa

产品提出需求时应当考虑技术可行性,因为有些需求可能根本无法实现。

但是,技术实现上的问题不应该过多考虑,原因有二:

1.不是每个产品都懂技术,或者说即使你懂,也不一定能完全判断开发难易与实现成本;

2.什么都由产品做了,那还要其他人干嘛呢。


于我而言,我认为比较合理的是,提出需求之前或当时,从自己的经验和所掌握的技术知识出发,尽可能考虑技术实现难易度和开发成本;在开发评审阶段,与开发详细探讨并确认清楚每一个需求点是否能够实现,这样做的好处:

1.让团队成员了解你作为产品经理,从一开始就有站在他们技术的角度去思考问题,而不是完全凭着自己的想法天马行空;

2.在评审阶段,提出自己的疑惑点,并与开发反复确认每一个点是否都能实现,以及开发成本和工期,并【做好记录!做好记录!做好记录!】,减少甚至避免一开始说可以实现,没问题,而到了开发阶段频繁出现说这也做不了那个实现成本太高的状况。


以上,供参考。

十三

请先 登录 后评论
xxxxxa
这个问题可以从可能性和必要性两方面考虑。产品经理在提需求的时候,可以预期下技术层面的实现难以,但是前提以该需求的必要性判断。接下来分点论述: 1、首先,作为产品,各处收集需求,设计功能,从而迭代实现高转化的目的。那么在第一阶段的需求期,先不要考虑技术实现,一个需求可能有多重实现方案,把多种方案列出,以备评审选最优。而且就现在的发展技术而言,会有多少功能技术实现是有困难的,可能也只是时间和人力的问题。按照麦肯锡的观点,所以这一层要讲的是,提升答案的质量之前,要提升议题的质量。 2、多套需求确认后,可以和开发对接,大概评估功能开发需要的人力和时间,从而考虑实现成本和难度。如果是必须要加的功能,严重影响用户使用体验等,即使成本再高,也要去做。如果目前阶段时间比较紧张,小而不紧急的需求可以先缓缓,排期向后推。 3、说说个人的经历。产品非技术出身,可能对技术并不十分通透,有些时候会跑过去问技术,xxx功能能实现吗?好实现吗?90%的情况研发的回复是没问题啊,可能麻烦点。。。。自己在思考的事,我们现在日常提的需求基本大部分都不是极端需求,就技术而言可能都有解决的方法,前人造的轮子多不胜多。还是那句话,如果有实现难度,可能就是时间和人力的因素。 所以总结,提需求前先给你的需求下个判断,这个需求要做的必要性有多大,会存在技术上实现有难度的可能性,然后在根据实际情况安排开发相应能力开发人员和时间完成功能开发。
请先 登录 后评论
xxxxxa
这样做当然不正确。 在提需求的过程中,常遇到与技术沟通的各种问题。现在的产品市场已呈现红海,更多的需求是在于“在现有的技术上如何去做的更好”而不是“开发新技术”,目前的状态决定了我们不能一味的考虑用户需求,也要去考虑技术的实现成本与难度。当然,没有说要求产品经理会深谙技术之道或者去写代码,但在不考虑技术实现难度的基础上只考虑用户需求,天马行空无限想象,这样的需求就很容易被技术怼回来还欲哭无泪。我们以为脱离了五年前技术导向的市场,但脱离了技术实现的需求可以说是tan90了。记住了,产品不是寻找技术突破口,而是学习在现有的资源上去让用户体验更佳。 现在越来越多的产品要求了解技术或者计算机背景,也是这个原因。在信息泛滥的时代,作为一个产品er,尽管技术背景欠缺,很容易就能在市场调研的时候去通过竞品发现技术是否能够实现或者实现难度,或者直接跟技术沟通了解,再决定需求是否应该去做。为什么产品er重经验重项目?熟悉业务熟悉流程和用户体验一般说来三两年都可以实现,先不说强洞察力的重要性,资深产品人的优势还体现在"知道是否这个需求可以做,投入产出比是多少",而不是兴高采烈的提出自己突然想到的以为amazing的需求,面对开发的拒绝还摸不清原因。 pm考虑技术实现难度,并不需要很深,可以做做简单的调研,或者在提需求前和开发简单聊一聊实现的难度,思考清楚了再去做。顺便推荐一本书,《给产品经理讲技术》
请先 登录 后评论