产品人员需不需要考虑技术实现

[caonan]

最近在设计某 B 端管理系统时，遇到了大量数据管理和处理的需求，我尝试尽量多的去了解后端的设计和实现，但是一个技术大拿始终坚称：

• 「你不用考虑权衡，这跟产品无关」
• 「底层如何处理与你们无关」
• 「请不要浪费时间在如何实现上」
• 「这个实现细节不应该造成任何产品倾向」
• 「应该是无所谓的，根据实际情况定义数据即可」

我尝试通过几个设计时的倾向去说明相互的影响，但现在没有实际的效果，请问大家怎么看，原谅我没有提供足够的细节。

PS ：我们关系很融洽，都是多年的战友，并且对方技术造诣确实很深。

[pimin]

专业的事让专业的人做
既然你不是那么精通,那就让他们去做呗
实现不了的时候他们自然就会反馈,然后再讨论解决方案
你浪费时间在你不专业的事情上而影响总体进度确实没必要
你可能觉得你这个时间无所谓,然而你把这个时间放在你擅长的用户体验,功能设计上,带来的好处可能更多

[yxzblue]

多年的战友这么和你说话，摆明没把你当战友，不考虑踢了他吗 2333

[godtea]

### 前提

> 我是开发转产品的，算是才入门吧？

### 正文

> 我始终没有彻底的摆脱开发的思想。一个产品大拿朋友一直跟我说，不要去管技术人员怎么实现的！但是我就是改不了...现在偶尔还帮他们解决技术问题...

### 结论

> 我个人觉得：了解技术实现会提高产品的设计思想——前提是自己熟悉技术。但是不能去干预技术人员的实现方式，毕竟不是你来写代码。

[caonan]

@yxzblue 哈哈，踢不开啊，必须互相吐槽才能坚持一整天的干劲~

[caonan]

@godtea

支持，不干预是绝对的原则，这个我不会逾越的。

[godtea]

@caonan 加油！

[SlipStupig]

正确流程是，你提出一个牛 x 的想法，技术给你解决，想法拿去市场检验，如果失败继续想

[taine]

你想了解考虑技术实现，对方不想告诉怎么实现，这是两回事。你想了解，出发点是想把产品做得更好，担心对方不能满足你的想法。对方不想告诉你，有多种原因，比如时间紧等等。

[suduo1987]

无关，作为产品你需要提供给技术的是我有什么样的东西给技术，正常情况下技术应该加工成什么东西，异常情况该提供怎样的反馈。中间如何实现不关产品的事。你可以不满足性能要求技术提高或者给出指标，但不要要求用何种技术。如果技术做不到，你可以向你的上级汇报，至于需不需要更换技术团队也，也不是你要考虑的。

[wizardforcel]

你知道能实现就得了，想那么细干嘛，又不把开发工资发给你。

[Lpl]

我了解到的流程是介样子的：产品根据需求设计产品原型，只需要考虑产品的实现和功能。遇到过的很多产品的功能实现上是没有什么问题的，只是可能是对功能做修改会更好实现和扩展，这时候可以让开发那边反馈；如果开发那边解决不了的问题的时候，就需要那边反馈然后一切商量解决的方案。

[HLT]

必须要有，。。。否则就是技术人员嘴里的那种：我们公司那些 我不想说脏话的同事。。。话说，貌似你同事有戒备心理

[powerfj]

我觉得可能是实现的具体的一些业务流程, 你需要确定实现是否符合你的预期, 这个肯定是需要对一下的.
具体实现的技术细节, 感觉应该是可以不用过问的.
在我看来, 开发应该是尽量在不让系统复杂的情况下, 最大的来满足产品的需求, 他如果觉得复杂了, 应该会找你来沟通吧
感觉他的那些回复有一些情绪在里面, 是不是 lz 和他最近关系没搞好..

[unionx]

其实多知道一点是好的

[ksky]

技术足够强 时间足够用的情况下产品为什么去考虑技术实现难度。

上面两个前提没有的情况下就要去考虑，用最简单的逻辑尽量满足业务需求。

[missingbobo]

你可以不考虑，但是你要听取技术的反馈，如果很难实现那就没有意义

[moult]

个人感觉最好适当考虑一下，权重一下需求的重要性和实现的时效跟程序运行效率。
举例来说，列表页中，为了一个可有可无意义不大的字段，要另外关联 N 张表的。

[techme]

「底层如何处理与你们无关」之前也是这么和我说的，然后处理底层代码的同事离职了，还是我来接管

[williamx]

产品考虑技术实现，你的方案会永远停留在草案阶段。

规划你自己最完美的产品方案，让技术来找你沟通其中的技术难点——这是最理想的协作方式，也是原则。实际工作中可能由于各方面的原因，达不到最理想的状况，那么只要坚持原则不变，总会事半功倍的。

[rove]

有这样的技术大拿做搭档是幸事，术业有专攻，把产品方案做的最好最详细，和大家共享上线后数据和总结