一直以来，产品经理与程序员之间就像是水与火般难以相融。许多初入社会的年轻开发，估计都曾动过要跟产品经理打一架的念想。
但这种坏念头一定只能压抑在心底，不然会被产品经理们通过一系列抓手对需求的底层逻辑的论证，同时结合产品思维、用户意识以及培养心智等概念上的组合拳，直接拉通对齐你的直属领导，从而将具体问题抽象成不同颗粒度的方法论，进行形成辩证闭环，说得你手无缚鸡之力。
初入职场的我，也经历过数次想要与产品经理唇枪舌战的大场面，想要与之辩证唯物主义，不醉方休。后来想了想，还是不至于、没必要、莫生气。
于是今天在这里总结几点程序员眼中最讨厌的七大产品行径。
1需求文档不完善
俗话说的好，代码未敲，文档先行。这意味着研发的代码并不是无中生有，而是围绕着需求文档来进行设计和实现。特别是以业务为主的技术团队。
在这个过程中，研发与产品经理交战的第一个场地便是需求文档，一个充满了硝烟和孤*野*的战场。
一个好的产品经理的基础就应该能够产出完善且细致的需求文档，能够将需求的背景目的以及改进细节都描述的恰到好处，同时在产品维度上能够提出关键性兜底或兼容方案。
尽可能的将需求改动的重点描述清楚，降低不同角色的理解成本，能够让研发围绕着这一份文档来进行技术设计，这样的文档或许才称得上完善。
但是实际上许多产品的文档并不尽如意，要么完全沉溺在自己的表达中，让人抓不住重点；要么大篇大论，或苛求一些并不核心的细节点。
一旦遇到这样的需求文档，通常意味着需要永无止境的确认、争论以及成本取舍。最终影响的就是开发流程中负责每个节点的负责人的体验。
可能有些人会觉得产品提出的需求文档就是要跟开发一起讨论才能得出最终的完善版本。我觉得这种观点完全就是产品不负责任的表现，可以根据需求文档来进行更深层次的讨论。
但是前提一定是文档是完善的，是需要产品经理事先站在产品的维度上进行过思考和沉淀。而不是依赖别人来帮忙查漏补缺。
2需求进行反复变更
这一点相信是让所有参与需求推进的人员都最为恶心的事情。在我眼中，需求变更的程度与产品经理的能力直接挂钩。
很多时候，经常性的需求已然进入开发阶段，甚至是临近开发完成时，产品经理总是阴差阳错的发现了某些功能或改动的不合理性，从而肆意发起需求变更，甚至是需求反复变更。
需求的反复变更不仅影响的是整体需求推进效率，还有可能会导致开发质量降低以及多方协作不对齐的问题。说起来可能只是工作量的问题，但其实影响面十分广泛。
站在开发的视角，我觉得作为一个成熟的产品经理，就应该在开发介入前或者开发前期能够将所有需求点都确认下来，并且能够打通各方都质疑以及资源支持，不该想到一茬是一茬。
我见过很多产品经常受不了别人的质疑，一旦听到有质疑的声音，就会去变更需求以避免争议。这种的行为实在是无力吐槽。
3对需求缺乏