产品经理提需求时，该优先考虑技术实现难度嘛？
笔者在某平台看到这样一个比较热门的问题：产品经理提需求时，该优先考虑技术实现难度嘛？
目前有243个答案，笔者用最原始的方式把每个问题依次数了一遍。统计出目前有42人支持优先考虑技术实现，占比17%，剩下的201个回答占比82%。
不过这201个回答里面又包含3类观点，其中占据主流的是反对优先考虑技术实现难度，有大约65%左右；另外一类是认为要根据公司业务情况进行判断，占比约10%；还有一个1类观点认为这个问题本身就有问题，应该在这个问题基础上追溯本质的答案，占比约5%。
支持优先考虑技术实现的答案主要有以下方面：
（1）公司技术不能支撑都是白搭，产品需要降低要求，来实现需求。
（2）技术实现难度应该属于优先考虑的范围之一，这是产品经理设计产品时对产品能否成功的一个要素之一，也就是面对实际情况做事的需求，同市场调研一样重要。
（3）技术解决方案必须提前做好调研，这样才能避免技术实现难度导致项目延期或者不可实现。优先考虑技术实现难度，再结合业务需求推进项目进度，不考虑技术实现难度的，遇到很多创新性项目就可能到底不能落地，空谈。
（4）要考虑，因为这可能是决定产品研发周期的关键因素。
（5）会优先考虑技术实现难度，考虑在开发周期内找到最容易的实现方案。
（6）优先考虑功能的用户价值是否高于研发的成本。
反对优先考虑技术实现的答案主要有以下方面：
（1）产品提需求时，考虑技术难度是应该的，但不赞成优先考虑技术难度！技术难度只是考量需求价值的因素之一。
在提产品需求的时候，个人觉得应当优先考虑的是需求的用户价值和商业价值，其在产品不同阶段，各有偏重。
技术难度一般用于衡量需求的开发价值，主要是出于成本考虑，包括开发量，开发周期等。
如果开发成本超出需求的商业价值和用户价值，一般这个需求就不具备开发价值。
（2）考虑技术会阻碍产品的创新。
（3）产品不应该被技术限制，可以和技术一起沟通评估实现成本和难度。
（4）反对优先考虑技术，技术实现难度是技术来评估的。
（5）客户的需求永远是第一位的，我们需要做的就是解决一切困难，在别人之前满足客户的需求。
（6）技术可以迭代，产品是否解决真实需求而非伪需求才是产品经理需要优先考虑的。
（7）技术必须建立在市场需求之上，没有市场认可的技术，毫无价值。
（8）先从产品的角度考虑，应该实现哪些需求，然后去设计。关于技术实现部分，可以利用迭代的思想，先做优先级高，技术上可以实现的需求。
技术人员也是需要跟随市场发展，公司战略去成长的。为什么不推荐先考虑技术实现，就是怕因为考虑实现过程，从而降低了需求过滤排序工作，影响产品设计工作的质量。
（9）容易让产品框在一个固定的范围内，等于一个绝顶的高手被束缚住双手，无法完全发挥水平。
做产品还是要先根据场景，设定目标，做出解决方案，优先考虑的还是用户体验，交互友善，使用方便，之后再考虑技术实现难度。
认为这个问题本身有问题的答案主要提到以下方面：
- 产品调研阶段就应更多考虑这个需求能给用户带来多大价值，价值越大，使用频次越高，技术难度高也要实现。
- 需求来源用户和市场，需求的提出是蕴含了价值，技术难度只是一个点，所以这个问题本身就不是问题。
- 产品这种事情，不是非黑即白吧？应该根据实际情况来定吧，这种问答难度不会给一些产品误导么。
根据公司业务情况进行判断的答案：
（1）在考虑功能性的同时个人觉得应该考虑技术入股技术达不到，想办法解决，技术不可能解决的时候协调产品变更。
（2）具体需求还要看具体情况，从公司定位，实力，技术团队能力，开发周期，资金，需求前景多方面因素进行考虑而定是否提新需求。
（3）这两个答案我认为不应该对立。首先，资深的产品会分清楚强需求及需求场景，刻画对标用户。
再考虑技术实现程度，再和技术讨论可实现和技术待解决的问题。
有时候，产品不应过分关注技术如何实现层，不如要技术架构师闲的吗？
再说，需求引领技术创新，技术也反馈给需求真实情况。
还有许多优质的答案，就不一一转述了，有兴趣的同学可以自己去瞅瞅。
笔者也表达下自己的观点，比较认同具体情况具体分析，很多时候不同行业、企业在面对市场会有不同的角度和难点。
产品经理在提需求的时候是否优先考虑技术实现难度需要因地制宜，根据所在行业和公司的情况进行选择。
举个例子：我们现在要设计一款内容平台，关于一个点赞功能，对于大部分产品经理而言，会基于用户场景和业务需求为出发点考虑。
而不会考虑点赞这个功能的技术能不能实现，只会考虑这个点赞功能是否必要？
因为对于大环境来说，点赞功能是十分成熟的方案了，一个点击事件绑定参数保存同步给服务器即可（真正实现过程还会考虑一些其他因素，但是大环境确实不需要优先考虑技术实现问题）。
所以这类情况，我认为完全不用考虑技术实现难度，如果真的需要考虑，那这个团队的技术同事需要反思了。
然后是另外一种情况，我们产品人也会遇到许多维护项目，这类项目可能已经经历了好几代的技术、产品人员操刀了。
所以项目本身的代码和架构新接手的技术人员不一定能把握住，简单说就是现在的技术人员没办法对之前的系统具备掌控力，只能做有限的修补或者新增。
面对这种情况，产品经理有时候还真的需要优先考虑技术能不能实现，要不然一个在其他地方很容易实现的方案，可能在这里就会遇到滑铁卢。
总之仁者见仁、智者见智，笔者也是各种情况都遭遇过了，所以对于这类问题都是以更客观和务实角度来考虑。
希望大家身边有技术大牛，这样工作起来真的会轻松很多。
关于技术和业务笔者认为相辅相成，互相成就才是王道，孤阴不生，独阳不长。
作者：明远；5年互联网工作经验，主要涉及智慧养老、智慧社区、智能安防等方面。
本文作者 @明远 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
