你会百分百重现设计师或者产品经理的东西么？

完成工作是分内之事，假如闷头按要求做完全无可厚非。
与设计和产品多做沟通提出自己的见解也是理所当然，有能力做好交流并在设计里体现自己的想法那是能力的体现，要是无法说服就努力提升自己让自己有能力有资格去实现自己想要的东西。

没任何矛盾，只有自己能力的问题。不管是自己的眼界还是和团队沟通的能力。

还有一种情况是，他没想到他的2个想法其实是互相冲突的，不可能2个都实现
这种情况下只有解释清楚了，不去解释就是你不负责任了。当然对方没考虑好他也有责任

实际工作中，如果他自信心很强大不觉得2个想法有冲突，那我没办法了，先实现其中一个想法，让他看过之后数落我一通让我改，我再改回另一种。来回改几次他就会意识到他的想法有多蠢了。

当然啦，这种拉锯战都是费时费力，负合游戏。但你还能怎么办呢？
只有一个终极的解决方法：换雇主。
当然，你牛的话，也可以让对方走人。

试图说服他们，但是最终由他们来决定

如果要增加很多工作量，就让他们知道需要很多工作量，让他们自己去决定

最后一点：没有报酬的加班免谈。控制不好进度是管理的问题，不是开发人员的问题

不会。反正最终做成啥是我自己决定和负责的…

默认情况下，是按照最初商量好的方案做。
中间我想改的话会找他们商量，他们不同意就按他们的想法去做，反正不是我的产品（我是外包的临时工……）
如果他们途中要改我会尽量推到下个版本去。反正原则是增加的工作量另外算，交货时间顺延。

@66450146
对，你根据不同的设计估算出来工作量让他们决定好了。

关于设计，你可以提出自己的意见，给设计师参考，让专业的人来做决定。

我以前在的那家互联网公司是这样的：设计、产品、开发同属一个一个团队，大家是平级的，理想情况下是产品经理给出策划案，然后设计和开发作为下游在策划案的基础上工作，设计师的工作成果最终也是给开发用的，于是开发者就是最终的下游了。

实际实施的时候肯定会有上游想错了、下游做错了的情况出现，那么发生这种事情的时候肯定是要尽早沟通的。另外作为上游，如果经常搞飞机；或者作为下游，发现问题仍然硬上，那么就有必要反省下自己是否称职了。

对于来自上级的要求，假如有问题的话也很简单，问题肯定还是要好好反馈的，如果上级决定硬上，那么也没问题，出了问题我这边不负责就是了。

知己知彼，百战百胜。

码代码的不一定什么都懂，产品/设计也不一定什么都不懂。

搞清楚自己是不是真的能不能做，以及搞清楚对方是不是为了敷衍kpi或者推卸责任到开发身上，或者装逼比较重要。

这样看问题就能够客观了。该拒绝的还是要拒绝，做不了的要上升到管理层去讨论。这才是高效做事。
太差的码字员要早点换，太恶心的产品/设计要早点滚蛋。

剩下的就是磨合问题了。

产品经理也有区别的，有的产品经理非常地感性化，这种类型多出现在女性身上，容易陷入局部思维，对某个细节狠扣，其实呢，捡了芝麻，丢了西瓜，而且还总容易站上道德制高点，比如说“用户会觉得难用”这种话，就是经常用来说服开发的理由；另一些，是理性化的，喜欢全盘分析，抓重点，这样的产品经理关注目的，在手段方面，容易妥协，比如开发说，这样不行，他会说，那那样也可以，比较好说话；

我比较倾向于喜欢以理服人的产品经理，使用数据、实验结果说话，而不是把自己当成用户去代入，然后给出情感化的论断。

关于产品经理的职权问题，这很重要，如果公司是产品经理导向，你有些时候，真的不得不执行一些自己不喜欢的命令，实现一些自己不喜欢的特性；我的leader在这方面很值得人学习，他很有耐心，反复从多方面论证并说服，就算无法说服，他会先接下来，然后实现它，想办法用更好的证据，证明这是个错误，比如数据说话，用户说话之类；但是我很难有这个耐心，就容易生出对工作的倦怠，觉得一群扯淡的家伙，但事实证明，这没给我带来任何好处，也没有解决问题；

现在，我似乎更容易妥协，一般我肯定会指出我觉得不妥的地方，然后告诉产品经理说，关于这个潜在的问题，你要确定你是知道的，对方如果确定，我就会去实现那个功能；这些无非就是浪费一点时间而已，对产品的伤害往往没有想像得那么大，不过要因此助长了产品的歪风，危害到更大；所以，作为一个热爱产品的开发，要尽可能爬到高位，到时候选择余地要大一些

设计那个也是我。