你们产品经理会帮你们减少技术债务吗？

论懂技术的产品重要性

@pigbug 很难

产品经理：需求要如期交付，其他我不管

@pigbug 实际上，职位转变带来的思路转变影响非常大。我司就有位前开发转产品，现在完全没有技术方面的思维了。

产品经理需要考虑的东西很多，技术只占 10%不到，各方面要权衡考虑

强势一点，产品提出无理需求的时候，先好好说，说不通就和他说这个功能比较麻烦，要加工期。你预估的工期*3 就行。

不会，所以技术负责人很重要，要做好协调，管理好技术债务

@Leonard 懂技术的产品大概率不会用技术思维帮你减负，但是他大概率能看出来你预估的工期 * 3.....

@jisi724 #8 没事，你飙几个术语忽悠一下就行，就说 xxx 这里要改很麻烦，改了以后 xxx 都要重写之类的。注意忽悠的时候和你的队友通好气。

又学到一个新词，“技术债务”

技术出身的产品经理表示:
我真的会为去主动做减法减少技术债务,甲方需求中途直接发生了变化的也有,工期被迫延长的也有,前期考虑不周后面算法需要变动的也有,我一般都是诚恳地道歉并说明情况,我的团队也不会用术语来忽悠我.
但是我的一切减负的手段 都是产品侧的减负 并不会因为技术上难度过大而采用简单粗暴的方案,维持一个较为敏捷的版本研发周期,把版本做细,其实大家也都能接受。
把一个版本的功能迭代堆太多东西，团队就很容易陷入畏难情绪中。

论老板懂技术又管产品的重要性

产品经理管技术债务，那技术负责人干哈？

碰过两个极端，一个三周的活说一周，一个一周的活给了三周，还问，有问题在和我说
能不能两人调和一下。。

@harde 添油加柴

高情商产品经理：
1.我不管。。。
2.为什么一开始你们不。。
3.你去跟老板解释去。
4.不要跟我扯，设备不行换设备，人不行换人。。
5.我们是一个团队，如果每个人都只做到 80%，那我们交付出来的东西就远远达不到 80%的水平。。。
6.xx 我再多给你 2 天时间，这个项目完不了，年终奖和绩效清空。。
7.如果你每个事情都跟我说做不了做不了，那我怀疑你平时都在干什么，公司给你开的是溢价工资，你有没有拎清楚。。
8.不要跟我扯 xxx，不行就是不行。。
9.如果你们拿不出更好的方案来说服我，那就按我说的去做。。。
10.如果你们用自己的解决方案瞒着我把这事做了，只要他出一点问题，你给我滚蛋。。

为啥是产品经理去帮助研发减少技术债务？

可以理解，但必须充分的、公开透明的沟通。

这个可以通过职责拆分来直接解决。
将核心生产工作大体上拆分为技术和产品两部分：
产品部分负责做需求收集、业务评估、产品设计、产品验收；
技术部分负责做需求评审、技术设计、开发实施、质量保证。

其中两部分协作的关键环节是需求评审，产品经理提出方案，由技术评估可行性和成本（对于水平不高的产品经理，技术还要承担起合理性评估的工作），然后产品经理根据自评估的业务收益和技术评估的成本来评估 ROI，以及是否能达成 ORK/KPI 。产品经理为收益评估结果负责，技术人员为成本评估结果负责。

实施成本的评估是纯技术侧的工作，产品经理不专业也不该做这个事，而且需求评审阶段本来就是需要产品放和技术方互相沟通，在实施成本和收益上达成共识。
那么技术经理在给出成本评估的时候不能只包括短期成本，应该是涵盖短期、长期以及各方面的综合性的成本，技术债务也应该包含其中，这个其实也很好说得通，有了技术债务以后可能每个类似功能都要有更多的成本，而且系统的性能下降（运营成本上升）、可靠性下降，而解决或规避了技术债务之后每个类似功能会有更低的成本。

产品经理只会帮自己解决智商债 <(*￣￣*)/

还好题目正确的打成产品经理会帮你们减少技术债务吗？ 产品经理：滚！

。。。。。。

这次真的不是产品经理问题。
是技术人员的问题。

自己写的屎，自己吃下去。

哈哈，不会，很多时候文档不清楚跑去问，问就是最难的实现方案

技术债务理论上不是产品的问题吧

@bing0 这是乔布斯 后来的事情大家都知道了 就是他死了

@libook 解决技术债是短期赔本 长期也不一定赚的事情 特别是双月 OKR 导向的公司 很难得到支持

有些产品会.....碰到技术实现上的问题, 找产品沟通, 会一起商量.

看看能否从设计上优化, 在实现需求的同时让技术实现起来更容易,或者更换一些实现方式. 当然如果是很重要的功能点, 那还是得硬着头皮上. 在开发效率和需求实现上做些妥协.

我是产品，可行性和实现成本肯定是首先要考虑的。项目从需求阶段就会反复拉着开发测试一起过，哪怕实现上没困难，你也得清楚自己做的东西在实现上是什么量级。就像盖楼，设计师可以不清楚每个房间的细节，但是楼盖多大多高，成本多少，达成目标的概率有多大，是要有 b 数的。

@bing0 说话风格为什么这么像女朋友

@hq136234303 产品经理应该考虑的是怎么把产品做好而不是技术容不容易实现。

如果一个产品经理跟技术混得非常和谐，那么我觉得应该评估一下这个产品经理是否称职。

#18 @libook 说的就很好。

只有技术出身的产品经理才能叫产品经理。
其他的只能说是做产品的人。
Oracle 、QQ 、微信、微软等等，莫非如此。

很多没从事过技术类工作的做的产品很不错，但这样产品经理做出的产品能够成功都是 99%的靠着外部强推或集团流量倾斜。

不动技术的产品就不会 debug，没有 debug 就没有自我改良基因。

@vindurriel #25 技术债也不是一定就要避免，或一定就要还清，这个还是得综合业务经营情况来看，有一些对于业务确实比较关键的节点甚至应该主动欠一些技术债务，来换取业务业务的保障，关键就是产品和技术双方达成一致。权责分离之后，出了问题该是哪边的责任就是哪边的责任，比如技术方已经通过正式的文档或邮件将成本和风险表达清楚了，产品经理在 ROI 低的时候一意孤行进行实施，那么最终的业务亏损要算在产品经理的头上。至于如何说服他人，这是一门学问，需要经验和技巧的。

技术债务？

我一直不理解为什么需要 pm 懂技术？
技术债务需要产品来减负的话，那薪资是你几倍的技术 leader 是干啥用的。
至于排期忽悠我也是看得一愣一愣的，忽悠产品可以，还能忽悠到 leader 吗...

技术强势些，但也不能不讲理，要符合实际情况。该砍砍，该改改

产品为何要关心技术落地？更不要提技术债务了。

技术实现成本和功能效果之间的取舍确实需要沟通交流，但这并不意味着产品要一味地为技术部门的错误与合不合理实现买单。

我们产品经历跟个 2b 似得, 做啥大功能模块就是 "你先做出来一个我看看效果" ,他真以为别人做个程序跟他画个原型图一样, 在软件上拖拖控件就行了一样.

老外的软件工程那套根本就不适合现在的互联网项目开发.
因此代码整洁、可维护扩展一类的东西完全就是程序员自己理性主义在作祟, 一厢情愿罢了.

国内互联网就是捞快钱, 看到什么山头可以占, 就立马进场. 因此效率至上最重要, 其他有坑填坑. 后边坑填不动了就推倒重构, 更有意思的是, 大部分项目的寿命还到不了需要重构的时候.

因此花 3w 找一个程序员, 从地基开始慢慢搭建项目, 做成一个符合理想的稳固架构, 对公司收益来说几乎为 0, 可能还没一个 3000 块钱的实习生来的高.

从这贴看可以看出很多每天吐槽产品经理的人，甚至都不知道产品经理真正的职责在哪，无怪乎互相看不起是常态了

软件架构师应该考虑如何（指导队员）降低技术债务

你自己事情 自己不去争取 指望别人施舍?

技术债不是由产品产生的，而是由架构师决定的

@pigbug 懂技术还好，就怕不懂还硬要装懂的 我上个产品就是 在他眼里 总是觉得 这些只是 CURD 罢了 可惜人家连对象和数组都没搞懂就在那大谈技术架构

美团的产品经理还有懂算法的，牛逼哥斯拉

好像毕业后呆的两家公司，都是技术转 PM 。当然我说的 PM，是 project manager，而不是 product manager 。

并且两家公司，都没有 product manager，并且都是做开源的。[:doge]

业务流程图给团队所有人看
时序图给前后端看
erd 给后端看
原型给前端看

通常领导都会来一句：能用就行，不用搞这么复杂
甲方看完方案也会来一句：这些都不是我想要的功能啊

然后我回去安装领导和甲方意见修改，交付后花了两倍的时间去改进，最后改成了我一开始的方案，本来两个月交付的项目，做了半年

我：这个页面加载太慢了，极端情况要十五秒
研发：请求接口太多了，改不了
我：性能要求是 3s 完成
研发：历史版本太多，改不动啊
我：性能要求是 3s 完成
研发：做不了做不了
我：架构，你说这个能做吗
架构：理论上可以，但是。。。
我：好，我只关注业务的合理性，怎么实现你们讨论吧。

研发和架构开始开会。

@vindurriel #25 双月 OKR 不就是跳动公司么

估算一下只做核心需求的时间+支线需求的时间
以上两个时间相加，在已经规定好的开发时间内，我会尽量再减少一些需求量来再挤出一些时间
主要是以下几个原因
1.我不想加班
2.开发不想加班
3.我不想陪着开发一起加班
4.即使是开发中途有技术难点，我的产品也会有挤出来的时间解决掉并顺利上线

产品经理这个岗位就不应该存在

我都现在都很疑惑为什么有些产品经理能那么菜还菜的那么心安理得

@harde 我这边是技术的会帮产品添加更多他认为的不错的需求。加大工作量。反正他不用 coding