然而这一切都应该发生在你的内心中，权衡利弊之后如果有什么没考虑到的你可以提出来，如果并不是十分确认自己的想法，你可以等会后私下里和你的leader提出自己的看法，这既是对leader的尊重也是节省开会时间。
幸运的是，在互联网这个行业里，需求沟通的过程中，技术人员的话语权通常还是较大的，然而绝不要滥用你的话语权。
我可以扪心自问的说，在我正式入职以后沟通过的每一位产品，没有和任何一位发生过争吵，相反的是产品们都愿意与我对需求。
这并不是因为我把PM们当大爷一样供着，对任何奇葩的需求都有求必应，而是因为我往往把“与PM对需求”这件事放在“人情”这样感性的层面来考虑，而不像很多程序员那样只考虑代码逻辑的理性思维方式。
人是复杂的动物，一个PM提出了一个看似无理的需求，你却不应该不问青红皂白直接拒之门外，设身处地将心比心的想一想，公司里这样复杂的环境下，他/她是否也有自己的无奈和苦衷?如果有，这个问题是否存在其他折中的解决方案?
武断砍需求的程序员往往错过了这样的商讨“折中方案”的机会，同时也错过了一个让PM认可你的机会!这一点其实很重要。
我见过很多同期进公司的校招生，他们把职场中“老油条们”习以为常的做事方式直接照搬到了自己的行事风格当中，内心里对PM的抱怨将会在潜意识里左右你与PM沟通的态度和方式。
换个角度考虑，我倒觉得在其他职位的人眼中，你的技术多么多么的NB他们是无法直观洞悉的，每一个无理取闹的需求也都是一个你证明自己的机会。
更重要的是，公司里与产品交涉问题并不同于市场上买菜那样，你们的工作很可能在接下来的几个月中都存在沟通和交集，今天你卖给他一个人情，明天他也会替你扛一个线上的错误， (说实话程序员在代码上线之前往往喜欢叫PM来做最后确认，言外之意是上线是你确认的，出了问题也得你扛着.我觉得一个项目是大家一起做的，说句良心话，把所有的责任一股脑全部都推给PM我个人认为也是不公平的，PM往往在很多项目中充当“背锅侠”，人要相互理解)人非圣贤孰能无过，任何线上的代码都不可能永远是不出错的.PM对于一个之前敲定好的需求的修改，确实有可能是出于他本人工作上的疏忽，但是这不代表你的工作就不会出错，如果人之间没有“良好的信任关系”，问题就会被相互放大，像手电筒一样给别人挑错很简单，难的是互相的弥补对方的失误从而建立一种长久的友好合作关系，而能做到这一点也正是所谓情商的体现。
小编推荐阅读
