产品经理，别这样行吗？
一直以来，产品经理与程序员之间就像是水与火般难以相融。许多初入社会的年轻开发，估计都曾动过要跟产品经理打一架的念想。
但这种坏念头一定只能压抑在心底，不然会被产品经理们通过一系列抓手对需求的底层逻辑的论证，同时结合产品思维、用户意识以及培养心智等概念上的组合拳，直接拉通对齐你的直属领导，从而将具体问题抽象成不同颗粒度的方法论，进行形成辩证闭环，说得你手无缚鸡之力。
初入职场的我，也经历过数次想要与产品经理唇枪舌战的大场面，想要与之辩证唯物主义，不醉方休。后来想了想，还是不至于、没必要、莫生气。
于是今天在这里总结几点程序员眼中最讨厌的七大产品行径。
1 需求文档不完善
俗话说的好，代码未敲，文档先行。这意味着研发的代码并不是无中生有，而是围绕着需求文档来进行设计和实现。特别是以业务为主的技术团队。
在这个过程中，研发与产品经理交战的第一个场地便是需求文档，一个充满了硝烟和孤魂野鬼的战场。
一个好的产品经理的基础就应该能够产出完善且细致的需求文档，能够将需求的背景目的以及改进细节都描述的恰到好处，同时在产品维度上能够提出关键性兜底或兼容方案。
尽可能的将需求改动的重点描述清楚，降低不同角色的理解成本，能够让研发围绕着这一份文档来进行技术设计，这样的文档或许才称得上完善。
但是实际上许多产品的文档并不尽如意，要么完全沉溺在自己的表达中，让人抓不住重点；要么大篇大论，或苛求一些并不核心的细节点。
一旦遇到这样的需求文档，通常意味着需要永无止境的确认、争论以及成本取舍。最终影响的就是开发流程中负责每个节点的负责人的体验。
可能有些人会觉得产品提出的需求文档就是要跟开发一起讨论才能得出最终的完善版本。我觉得这种观点完全就是产品不负责任的表现，可以根据需求文档来进行更深层次的讨论。
但是前提一定是文档是完善的，是需要产品经理事先站在产品的维度上进行过思考和沉淀。而不是依赖别人来帮忙查漏补缺。
2 需求进行反复变更
这一点相信是让所有参与需求推进的人员都最为恶心的事情。在我眼中，需求变更的程度与产品经理的能力直接挂钩。
很多时候，经常性的需求已然进入开发阶段，甚至是临近开发完成时，产品经理总是阴差阳错的发现了某些功能或改动的不合理性，从而肆意发起需求变更，甚至是需求反复变更。
需求的反复变更不仅影响的是整体需求推进效率，还有可能会导致开发质量降低以及多方协作不对齐的问题。说起来可能只是工作量的问题，但其实影响面十分广泛。
站在开发的视角，我觉得作为一个成熟的产品经理，就应该在开发介入前或者开发前期能够将所有需求点都确认下来，并且能够打通各方都质疑以及资源支持，不该想到一茬是一茬。
我见过很多产品经常受不了别人的质疑，一旦听到有质疑的声音，就会去变更需求以避免争议。这种的行为实在是无力吐槽。
3 对需求缺乏关注度
这一点或许跟个人的责任心直接挂钩。对需求缺乏关注度，意味着产品经理在需求上线甚至需求进入开发阶段后，就不再关注需求进展。甚至是产出需求文档后，就像已经完成了任务一样。
许多产品经理往往会同步跟进多个需求，每个需求可能都会对接不同的开发人员。因而当需求较多时就会忽视掉某些需求的关注度。
我见过挺多产品经理在完善好产品文档后，或者是推进完需求评审之后，便不怎么管需求开发的进展了。当遇到一些需要沟通兜底策略或者取舍方案时，积极性都不高。
这应该也是最让研发人员头疼的一件事。
4 不考虑工程成本
「这个做不了」想必绝对是程序员的口头禅之一。
很多时候产品经理找过来，说要实现某个需求时，我们都会礼貌的回复他，这个做不了。
很显然，这并不是我们开发好逸恶劳想要偷懒的行为，而是很多时候，基于工程现状以及技术成本，的确没办法实现某些功能。
所以每当产品提出这样的改动，我们都会很头疼。当我们明确说明的确在技术上实现不了的时候，可能还会引起产品的不满。
很多时候我们都在说，技术是为业务服务的，脱离业务的架构也是没有意义的。
但是事实上很多时候技术的现状就是没办法满足产品的天马行空。所以产品并不是一昧的为达到自己的目的而不考虑技术现状和工程成本。
5 压缩需求排期
一般在大厂，都是遵循所谓「重流程，轻人情」的规则。也就是说，在项目或者需求开发过程中，更多是以流程规则为准，包括研发阶段的各个节点，比如需求评审、技术评审以及开发估时排期等。
项目实际需要的开发时间是通过对工程的现状调研以及实现成本来综合考量的，而不是领导或者产品经理强行给出的开发周期。
当然这只是最理想的情况，大厂之所以内卷这么严重，很大程度还是因为有些职能并不能遵守流程规则。
产品经理可能在节假日来临，或者与竞品赛马时，总是会突破流程规则的限制，疯狂挤压项目或需求的排期。
这就导致本来需要一个月开发量的改动被压缩成两周甚至一周，这造成的结果就是人员的工作压力骤增，开发体验骤降，以及工程项目的逐渐「屎山化」。
盲目追求热点，应对节假日缺乏提前规划，只着重于产品竞争，这些问题都会导致开发流程的形同虚设，造成产品经理为了上需求而肆意妄为。
6 强行堆砌实验变量
对于一个大型的产品而言，往往会采取AB实验的方式来验证新增特性是否满足用户需求。
AB实验本质上就是初中生物化学里学的设置对照组和实验组。然后通过控制变量法来验证某一个改动是否存在收益。
本身用这种方式来验证需求的价值性无可厚非，但是很多时候控制变量会被滥用。
比如想验证一个对用户来说体验最好的按钮颜色，那么在做AB实验时，唯一的变量就是按钮的颜色，然后不同的颜色就可以作为不同的实验组。最终看哪个实验组的数据最好就能够回收结论。
但是颜色数量那么多，该怎么去选取呢？缺乏产品设计经验的产品经理估计可能就会尽可能罗列所有的颜色来验证，而缺乏自己的判断和筛选。
这实际上是一个很常见的问题，产品往往因为自己也摸不清楚用户想要的东西，于是在需求开发中会选择堆砌或者排列组合所有实验变量。
看起来没什么毛病，但是过多的实验组合会导致开发复杂度变高，同时也严重影响业务代码的逻辑和架构。
所以我认为一个好的产品经理应该能够在排列组合的实验变量中有自己出于产品调性和用户理解的判断，筛选出真正值得去实验的变量组合。这样才能净利益最大化。
7 忽略体验，数据为王
产品经理是一个偏感性以及艺术性的岗位，但是在产品快速迭代的过程中，却没办法从感性和艺术性的角度来衡量产品的价值。
于是在实际的需求迭代过程，会引入理性的量化标准来衡量产品的发展水平。比如我们熟知的DAU，MAU等等。
渐渐的，许多需求提出的目的可能就是为了提升某项指标，而评估某个改动是否有价值的标准也是看其对于核心指标是否有影响。
时间一长，就会陷入数据的陷阱。
某些改动有些需求，可能最终实验的结果在指标上有很好的提升，但是可能并不是一个好的产品体验。
数据本身就是将历史量化所作出的归纳和整理，并没有办法完全代表或预测未来。所以数据只能作为一个先验参考，却不能完全作为一个标准。
我们都说好的产品经理往往都是极为克制的，好的想法有很多，但是真正有价值并且值得让人接受的却并不多。
虽然说产品经理在广大程序员中并不是一个十分讨喜的角色，但是吐槽归吐槽。很多时候产研矛盾还是很大程度上取决于个人的能力和做事水平。
事实上，在很久之前，当我还在上大一的时候，就差点成为了一名产品经理。当时是学校的一个创新团队在招新，连C语言都没学过的我就去参加了面试。但是我并不清楚每个岗位之间的差别。
直到我注意到产品经理这个岗位，「这听起来就是个经理，是个大官，说不定是管程序员的那种」。
于是我便充满期待的应聘了产品经理岗位。不过最后终面并没有通过，不然现在可能会成就另一番人生了。
说到底，作为在整个项目流程中最为重要的一个角色，产品经理的工作能力会很大程度上决定项目的整体进展。
希望在与产品的合作协作过程中，少一点套路，多一点真诚；少一分苛责，多一分责任。