程序员对游戏设计师提出的需求表示反感怎么办？
情况有如下几种（几种情况会并列出现）：
1.对设计本身不理解，反复解释后表达不认同，然后就是不做！
2.在项目经理或者老板高压必须要做之后，表示极大的反感，表现出威胁行为（威胁要骂人或者打人）的举动。
3.策划发现前提某个需求的设计（细节）不合理，提出修改，表示不耐烦，威胁“不准再改，否则不干、扣工资……。
4.每次提出要修改的需求，都要策划表明：“不会再进行修改”，然后才能做。
5.一旦策划的需求出现BUG或者不合理的地方，表示嘲笑，不耐烦，态度比较恶劣。PS：多数情况下，上述情况都是在大家的忍让下过去的。
但是我会产生疑问：为什么策划理解程序做的功能“一定会有BUG”，而程序不理解策划提的需求“一定会修改”？
合理的逻辑不应该是：你既然要求我的需求“不要再修改”，那么你做的“功能就不要出现BUG”？请不要讨论包含以下极端情况：
1.策划口头要求程序做某个大功能，而没有具体方案。
2.程序与策划进行殴打行为……
如果出现以上情况，那么这就不是谁对谁错的问题了，而是相关责任人直接可以走人了。
————————————————————
针对某些老板和运营/策划在项目中反复对需求进行修改的问题，作为策划我表示同样反感——而且是极其反感。
在下作为策划跪求获得可行性措施啊啊啊啊啊……
而不是【谁背锅】这个无关紧要的问题：一般情况下项目内成员都不会被因为项目本身的功能BUG处罚，所以追究谁的责任没有作用。
从两方面先分析一下原因。
先说程序。
程序分两种，一种可称为产品型程序，一种为技术型程序，有些人可能觉得自己两方面都有注意，但其实肯定还是有侧重点的。
产品型程序的特点就是，对于自己所做的项目前景，项目实际情况，以及所面临的问题均有自己的看法，十分关心自己所做的这个项目，这种程序有自己对于游戏开发的抱负与理想，很大部分对于许多为了坑钱而坑钱的功能需求抱有天然抗拒，但随着自己对行业的深入了解，会慢慢接受这种现实，而且到后期会转换为另一种心态，觉得坑钱可以，但游戏一定要优秀，坚持认为游戏只要做的足够好，挖坑赚钱属于分分钟的事情，加上本身对于游戏了解比较深入，基本上已经有了自己对于游戏各个系统以及功能的较为成熟的看法，对于策划新人来说，遇到这样的程序是对自己非常大的考验，因为自己的想法或者说需求很容易被程序发现其不合理或者不完美的地方，加上你的资历尚浅，程序就会怀疑你的能力，当然并不是说只要你是新人，程序就会觉得你不行，往往都是因为策划提供的案子实在是槽点太多，一次两次大家笑笑就过，但很长的开发周期里，你提的需求每次都是这样，或者说自己对于这个系统没有一个全面的认知，有一些东西翻来覆去的改，而这些东西一开始程序提醒过你更好的解决方案，后来改了五六次最终拍板的结果和程序一开始的建议相同，那你基本上就很难过了，这个程序一定会认为你是个水货，下一次你再提不合理的需求，他就会吐槽你，甚至跟你挑明，这玩意儿定好了就不能改，你拿上级拿老板压他都没用，有能力的程序都有股傲气，你敢压他他就敢跟你拍板，大不了离职，有能力外面一大堆人排着队等着，跳槽还会涨工资，凭什么示弱？
技术型程序的特点是，我不关注或者很少关注你这个项目怎么样，我只关注我能提升多少自己的技术，我的梦想不是做多牛逼的游戏，我的目标是求伯君那种大神，解决技术难题才是我的G点，按理说这种程序和策划应该不会有冲突才对啊，错，这种程序在对待有些事情上会比产品型程序粗暴的多，比如说，一开始我们定义好了技能的数据结构，游戏框架整个已经搭建好了的情况下，你跟我说我们要改技能机制，而这个改动可能会导致底层大范围重构或者产生许多垃圾代码，这个时候，脾气好的就会跟你讲这个不能改，改了的话这一两个月白干了，或者说我们这边实现起来很恶心，我不太乐意改这个，能不能再考虑考虑，换个方式，脾气差的就直接一句，滚，你当老子是傻逼么。程序一般比较爱惜自己的代码，技术型程序更甚，你一句话抹杀掉他很长一段时间的努力，是很难受的。
再说策划。
国内的游戏大环境其实一开始还是好的，上古时代的策划都是非常专业的，早年的单机游戏策划，你敢说人家水平不够？光粉丝都分分钟喷死你，网游火了之后，网游公司一下子雨后春笋般开遍了一线城市，策划出现了极大的缺口，这个缺口不可能一下子堵上，所以很多公司根本就没有策划，招几个新手填表，靠老板和程序美术头脑风暴，这样的游戏自然活不下去，死了之后又去别的公司，新手慢慢长大了，觉得自己牛逼了，就和别人创业，招其他新手，按原来的路子培养，这样行业内就慢慢出现了一批“资深策划”，但这批资深策划，始终没意识到一个问题，就是其实自己根本就没见过牛逼的策划是什么样子的，只是觉得为什么人家设计的东西细微处见功夫，我干了好几年了还是感觉抓不住重点，虽然数值不会，但那些游戏系统其实也都挺熟了，有名的游戏那些系统我都能倒背如流了，可为什么还是感觉缺点什么，到底缺什么呢，这就是没有见过高山，自学成才的人所面临的困扰，很多策划觉得自己不是新人了，可跟程序沟通还是被喷，是不是程序员都是奇葩，他们都是外星物种，本来就不能和我们正常交流，我去知乎问问，看看是不是，如果大家都说程序员奇葩，那我就平衡了。
你要知道，策划这个职业，你不专业，就算你干了二十年，你提的需求不合理，照样还是个新人，是不是新人，跟你的工作年限有关系，但不成正比，专业策划应该是什么样子呢，在我的认知里，策划应该是通晓天文，地理，宗教，历史，文学，哲学甚至程序等等一系列的东西，我这样说你肯定不服，有这种人么，你这不是吹牛逼么，这么牛逼的人还来做游戏策划？你是在逗我么？不，我是认真的，顶级策划一定是这个样子的，就算不能通晓，熟知是应该的，就算你觉得这是顶级主策的配置，小兵们不需要这样，那你应该也明白，小兵们起码要熟悉其中的一部分，你若不信，去鹅厂，网易，里面必然能找到让你觉得自己白干策划了的人，若你还是不信，如果你觉得我侮辱了你作为策划的尊严，仙剑玩过吧，轩辕剑玩过吧，你觉得面对这些策划前辈，光从文学素养，历史架构上，你差了多少？我知道你想说什么，你想说的是，那些有用么，现在的氪金游戏只看战斗，谁管你这些没用的，那好，来，你告诉我从0做一款动作游戏，技能这快需要程序提供给你什么功能，浮空，击飞这些要怎么做？什么？你擅长的是卡牌手游？那好，你告诉我刀塔传奇为什么没有像其他卡牌游戏一样做好友助战，而是做成了公会助战？而且不能用重复英雄？抽卡概率要怎么控制？
其实大家最怕的不是说策划什么都不懂，我上面所说的这些，毕竟只是凤毛麟角，不可能人人都这样，算是一种追求，策划最重要的品质，在于认真与虚心，认真对待自己的工作，如果自己有缺点，虚心接受并改进，如果一个策划拿着自己辛辛苦苦搜寻了很久的资料弄出了各种方案对比，没有人会嫌你小白，就算你查了很多资料给出的方案还是很扯，但至少你努力过了，不至于让程序一看到策划案就觉得那是你拉屎的时候随随便便想出来的，游戏开发本来就是协作，心态放平去做，肯定不会有问题。
当然，这不是策划的错，主要还是老板和制作人的态度问题，策划这个职业变成现在这样，完全是因为一大批的公司高层对于策划这个职业的无知造成的，以前有很多同事，虽然也是新手，但他们确实很努力的去做，提需求会准备一大堆的资料来说清楚为什么这么做，可往往是准备了很久的东西，因为整个公司都认为策划就是填表的，导致很多需求被主程和主美莫名其妙的干掉，被制作人干掉，或者老板干掉所有人的想法，按自己的来，这种事让很多同事伤心不已，纷纷离职，好几年过去了，有些被接二连三的坑，有些最终熬出头了，去了西山居等大厂，其实有时候也替策划着急，但这几年过来，发现很多事情人力有限，真的是看机遇。
其实如下面评论里的一位小伙伴所说，同等级的人相互合作是很愉快的，往往有一方实力不行，才会出现题主遇到的这种问题，牛逼的策划遇到实力不行的程序，你猜他会不会吐槽？他可能喷完你连具体实现都告诉你了。
那么现在，针对题主的问题，我们讨论一下怎么有效避免这种问题。
如果和产品型程序冲突了，那么一般都是你自身问题，注意，我说一般，这个时候，你要反省自己，虚心请教，自己的需求有什么问题，和他慢慢沟通调整，他肯定很乐意，要么你在提需求的时候拿着五个同类型游戏的系统分析，去跟他说，其他游戏是怎么做的，你是怎么想的，为什么要这么做，正常人都会虚心接受，尤其是这种程序，如果发现自己理解有问题，一定会及时纠正。
如果和技术型程序冲突了，那么这个就不一定是你的问题了，当然，只是不一定，有经验的策划在提需求的时候心里是明白会有多大的程序工作量的，如果你和制作人已经沟通过这种大的调整，而且只是这个程序的洁癖或者惰性在作怪，沟通解决，再说了，作为同事，平常多聊聊，关系搞好了，这都不是事。
当然，我不能否认说程序每个人都是对的，只能说，问题的原因很多，但都不是死结，力所能及范围内，愿行业越来越健康，多做一些有料的游戏吧。
---------------------------------------------------- 原答案的分割线 ----------------------------------------------------
题主问解决方法，就不谈对与错了，分享一下自己的经历与感悟，希望对题主有帮助。
我刚进游戏公司的时候，策划提什么东西我都以最快的速度做完，过了一段时间，对整个开发流程比较熟悉之后，加上自己本身也是一个还算狂热的游戏玩家，开始意识到一个问题，就是策划水平有限，容易犯一些低级错误。
小团队认识不到策划的重要性，觉得策划就是填表的，他们戏称为填表策划，所以招人的时候捡便宜的招，能招新人就招新人，再加上人员流动，导致整个团队里新人的比例极高，制作人不可能面面俱到，所以分发下来的任务就会以很喜感的策划案到了程序这里，有些程序不玩游戏，觉得工作一天就是挣一天的工资，他们当然不会管你这个功能怎么样，但总有些程序，他本身就是游戏的狂热分子，而且他本身涉猎广泛，或者他所喜欢的游戏刚好就是自己项目的类型，当你的策划案没有深度或者说很多坑你没有想明白而程序已经帮你想明白之后，这个时候程序就或多或少会有些抵触了，因为程序的逻辑思维较强，很多时候他们已经意识到这个系统的设计有种种不合理，后续会引发什么样的问题，程序就会去跟策划商量，想办法避免这些问题，当然这都属于合理交流，我没见过哪个程序从一开始就发脾气或者拒绝的，但一般策划的反馈都是：”唉，不管了，先这样吧，以后再说“。你试想你生了个儿子，老婆过来说咱们儿子就叫王小短吧，你跟她商量说，这样不好吧，儿子以后会被人歧视的，然后她说，不管了，先这样吧，等有人歧视他再说吧。你什么心情？
我上一家公司的游戏，都开充值内测了，里面一键强化花费的钻石是金币数除以一百这么算的，点金是十个钻石买两万多金币，有玩家抱怨说自己钻石丢了，我拉着服务器的伙伴查数据，查出来发现是点了一键强化一下两千多钻被扣光了，我跟策划说，这个收费太不合理了，还是赶紧改一下吧，你猜策划怎么说？“先不管，以后再说”。
来这边工作之后，做动作游戏，我发觉游戏里没有帧冻结功能，心想要不要跟策划提提建议，结果第二天还没来得及开口就收到需求，帧冻结，冻结抖动，受击位移，动作位移，硬直，等等等等一系列的功能，卧槽看着那张表我当时就觉得真TM爽，终于遇到靠谱的策划了，不说设计能力了，至少基础知识是有的啊，硬实力在这摆着，还有什么可BB的？
说了这么多，题主你明白了么？程序吐槽策划功能，抵触你的设计，抛开极个别奇葩程序，大部分都是因为你的设计或者策划案在他看来是不合理甚至于幼稚可笑的，策划要让程序闭嘴，就是用你的专业技能把他秒成渣，让他明白他知道的那些东西还很肤浅。策划完全不懂程序，不能用程序员的思路和他们交流的话，当然很难获得对方的认同。（注意，这个逻辑反过来也成立！完全不懂游戏性的程序，也只能用实现不了/做不完/不想修改之类不负责任的理由来扯皮）程序员如果对一个新功能或者玩法提出了技术实现层面的质疑，作为策划没有足够的知识和经验去理解的话，讨论就会变成鸡同鸭讲，然后长此以往就会演变成题主所说的这些恶性循环的情况。
国内很多策划除了 office 三件套（可能再加个 PS），别的动手技能几乎为零，这种情况下去设计一个新的界面或者菜单功能，你都不能做到高保真原型验证，凭什么让程序员傻乎乎的帮你实现以后，你一玩才发现各种设计上的问题？
另外经验也是一回事，一个新手策划没做过什么项目，遇到问题除了自己拍脑袋想就只能抄别的游戏，问题是这两种方案都不靠谱啊。把别人的一个设计硬搬到自己的游戏里，9成9都会有很多后续问题在功能完成、测试一两周以后才会暴露出来。而资深策划就能够凭自己的经验实现设计的融会贯通，尽可能的减少或者控制设计风险，也就是在提出方案时就考虑到了9成以上出问题的可能，然后把剩下的风险明确告知所有参与者。如果你是这种程度的策划，想必再难搞的程序员也不敢（也没有必要）当面表现出不配合。
策划不要觉得自己做了设计稿，程序员就有义务替你实现，而且还要反复实现设计需求的修改。每一次没有获得实践者认同就强行推进的功能，都在消耗你的信用度。如果策划的设计返修率（不管是不是由于 boss 的错误意见，程序员只认给他分配任务的人；所以说 boss 给的无脑意见策划要怎么替程序员挡住，是门艺术）很高，每个功能都要改2、3次以上，程序员对策划信任度下降，甚至等着看笑话都是很正常的结果。游戏开发中确实不可能杜绝改需求的情况，而且好的游戏一定是经过反复迭代的，但如何在每次迭代的时候都说服你的队友，让大家心甘情愿一起决策，一起努力实施，一起承担责任才是正道。
总之，在程序 vs 策划，研发 vs 产品这套经典矛盾体系里，坚持两个点就能解决大部分的问题：
- 多了解对方的知识体系，至少每次对方跟你讨论时要尽可能弄懂他的逻辑，不要别人说了一百次这里会有问题你都不明白为什么。
- 多为对方着想，怎么减轻对方负担，怎么给对方更多有用的信息，怎么让对方也参与到决策过程中。就算是管理者，也是一样的思维方式才能带好团队，别说你们是平等的合作伙伴了。
我是个程序员，业余爱好是画点小画，偶尔搞点小策划做个独立游戏。因为在背后评论公司不太好所以先匿名了。
——————————5)一旦策划的需求出现BUG或者不合理的地方，表示嘲笑，不耐烦，态度极其恶劣。
事情是这样的。如果我看到一个美术画画还没我好，我会质疑他的能力，因为他是专业的而我是业余的，我对他的要求理所当然应该比对我自己高。
如果有一个搞画画的拿着程序来找我说你这里可能会溢出，那我也会很羞耻。因为我是靠这个吃饭的还不如人一业余的搞的好。
如果有一个策划…呃，拿着策划案来找我做实现，被我几个问题问住了，那我肯定会怀疑你的能力。
——————————
我作为一个程序，肯定希望自己能够高效的完成自己的工作。
我理解每个人都有疏忽，所以我必须追着你把问题讲明白再开工。这也是对我自己的工作负责。
4.每次提出要修改的需求，都要策划表明：“不会再进行修改”，然后才能做。
但是有些时候，并非策划案中有明显的矛盾之处，
而是设计本身意图没有得到表达，或者设计意图本身存在问题。
这种时候我作为一个程序，去追着策划问每一个设计的设计意图，显然不太合适也没那么多时间。我能做的只是默认你的设计意图是正确的而且确实的能够表达出来。
在这种情况下如果你要修改，我也不太好意思说跟你一条一条确认设计意图。只能问你有没有真的想清楚想明白。
你说想明白了，我才敢开工，设计意图这种东西如果出了问题，往往不是两天加班能搞定的。
——————————
但是我会产生疑问：为什么策划理解程序做的功能“一定会有BUG”，而程序不理解策划提的需求“一定会修改”？
合理的逻辑不应该是：你既然要求我的需求“不要再修改”，那么你做的“功能就不要出现BUG”？
合理的逻辑是，每个人都会犯错，所以我们要思考怎么避免这个错误。
错误分两种，一种是难以避免的，另外一种是可以避免的。不要将这两个混为一谈。
如果你一定要说“一定会修改”，那么至少你要想一个小时怎么(在第一次提出方案时)避免这个修改，然后想不到，确定这是一个不可预知的错误，才敢这么说。
不断的学会避免那些可以预知的错误，效率才能提高，你和我才能进步；如果不去思考怎么避免错误，把每个错误都留到做完了再改，你怎么能让自己变得更强呢？
至少对于我来说，如果我犯了一个可以预料的错误，我会很伤心。
所以我不能理解为什么策划会理直气壮的说”策划案总是要改的“而不是说”我尽量做到不需要改需求”
更不能理解一些策划会说“反正总是要改的所以我们先做一版试一试发现问题再改”
最不能接受的是“你不出成品我怎么知道有没有问题”
如果你真的这么说了，我觉得相对于一个策划，更适合做一个测试。
因为你就真的只是在测试而已。
——————————
而不是【谁背锅】这个无关紧要的问题：一般情况下项目内成员都不会被因为项目本身的功能BUG处罚，所以追究谁的责任没有作用。
背锅的不是在于让你受到惩罚。
惩罚本身也没有什么意义。一般来说惩罚的意义在于避免再犯，但是我觉得效用极低。
（主动的）背锅的意义：
第一是结束“谁的锅”这么一个烦人的讨论，进入“怎么办”或者“怎么避免再出错”这样一个讨论中。
第二是可以发泄一下感情，让其他成员感觉更开心一点。对你的评价也会好那么一点。
至于谁背锅，但是第一背锅备选肯定还是制造出这个问题的人。
但是在主动背锅的情况下，我觉得只要是有机会避免错误而没有避免的人都可以背。
比如说我拿到策划案没自己检查就开始做了，我也可以背个锅。
（虽然这么背可能反而让策划不好办）
所以一般还是等第一备选表态以后再背锅。
毕竟第一备选都看在眼里，谁心里都清楚。你逃也逃不开。
反而你背锅了他们会觉得你“勇于承担责任”，实际上你啥惩罚都没有，你不是白赚了吗。
但是，有一种情况是不能随便背锅的。
这个情况是工作方法或者工作流程有问题。
举个例子：美术或者表现直接和老板沟通进行了修改和创作，结果和策划意图不合，然后要改策划是一改改一堆，要改美术也是一改改一堆。
这种就不是谁背锅的问题，是应该在进行修改之前必须找策划确认的问题。
——————————
针对某些老板和运营/策划在项目中反复对需求进行修改的问题，作为策划我表示同样反感——而且是极其反感。
遇到问题要想办法解决，不要反感不爽背后一通骂就完事了。
老板说的话（对你来说）也不应是不可抗力。正如同对于程序来说，策划说的话也不是不可抗力。
如果你能在讨论中说服老板，也可能让老板把修改意见吞回去。对程序来说你也是一样。
另外，在提出方案时多想一点，尽量不要给老板改三改四的机会，就更好。
比如我经常做设定的时候就会考虑若干个其他方案。最后选定一个做出来。
如果老板要改，我就会跟他臭屁一番：你那个方案我早就想过了，你这里如何如何不合适，我这里如何如何好。
然后老板信服。我声望提高又不用改代码，皆大欢喜。
我一个程序都能开嘴炮打翻老板，
你作为策划，不管是对方案的理解，还是口才，应当更加在行才对。
当然也有老板固执己见一定要做出来看看的情况。
这就是我刚才说的，老板当了测试员。
这种事情一般不会太多，验证个一两次觉得你说的有道理就应该认怂了。
如果真的老板就每次都这样…
这说明老板根本就没信任过你。
你还是离职算了。
——————————
剩下几条就不评论，太具体的事都有前后因果。我不是当事人也不知道事情原委，不好说三道四。
这段仅说一下我自己写东西的经验和我对策划的希望。
知识水平方面的期望就不提了，这个是积累和wiki解决的问题。
一，写策划文档的时候，声明核心乐趣。在每个设计之后都注明设计意图。
——别人不看没关系，这个主要是给自己理清逻辑用的。
二，写任何具体的实现的文档，声明某个功能有可能更改，或者在接下来的版本中可能会增加某个功能，而某些需求是真正想好的不会更改的东西。
——这样有助于实现者为接下来的更新做好准备预留出空间，而不是突然要推翻之前所写的所有内容。
三，试图否定自己文档中的每一个条目。
——每个人都不习惯质疑自己。但是如果不质疑自己出了问题就会被别人质疑。所以策划应当尽量多考虑自己策划文档中可能出现的问题。
你需要问自己的问题大概列一下：
这个功能是否必要？
这个功能的设计意图是？
这个实现方式的优缺点是？
脑补一个典型的利用这个功能的场景和过程是什么样的？可能出现什么问题？
有没有其他的利用这个功能的情况？有没有利用这个功能作弊的可能？
在极端条件下这个功能的缺陷是否可以容忍？
这个功能是否有其他的实现方式？
这个功能的若干实现方式中哪个最好？为什么？
（——而不是，“因为隔壁就是这么做的，他们一定认真思考过了”。）
——永远不要跟别人说什么“总是会出错”的屁话。如果你的东西出了问题给别人造成了困扰，你一定要承担责任和错误。
另一方面，程序也不是傻子。你不能一直以“我不会再改了”来忽悠人家。你需要真正的思考怎么避免这个问题。并且和程序交流。
如果你想了很久也没想到怎么避免一个问题，你认为这个问题是无法避免的，也要认真的和程序说明这个问题为什么是难以避免的。
楼上都是程序员，所以站在程序员的角度来说这个问题。不过问题和回答显然有戾气的趋势。
所以我换一个角度，以一个老Designer和Product Owner的角度来看这个问题。
首先是结论：在整个事件中，策划要承担的责任为95%或者更多，5%来源于一些本身脾气古怪的程序员。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
我们不去逐条分析题目中每一条特征是怎么样的，这么个原因，归纳起来其实只有一句话：
开发团队对策划团队缺乏信任。
这样的矛盾其实并不是一天两天，一次两次就会出现的，一定是日积月累的结果。很多人认为，游戏策划就是写写文档，玩玩游戏，这种想法是非常可笑的。游戏是一个非常注重teamwork的工程，而在一个team里，策划团队是串联美术团队，开发团队，测试团队，乃至整个项目的灵魂，当然，如果有一个牛逼的Producer也是可以的。所以这也要求策划团队比较具备非常强的沟通能力，这里的沟通能力并不是简单的指说把一件事情说清楚，而更多的是指能够说服别人来帮助你达成目标的能力。
那么这样的能力建立在很多方面：
1.良好的思维能力。
我见过很多策划，提出一个方案或者需求，和开发确认一下需求，被开发反问了几个问题，“呃……”，卡壳了，或者回答的驴唇不对马嘴，如果你是开发，你会怎么想？
“这熊孩子行不行啊，想的还没我多，不靠谱。”
“我靠，你都没想好，叫我做个锤子，尼玛做了回头又来改，老子是傻的么。”
如何解决，很简单，尽力去思考清楚，想明白每一个细节，为什么这样做，自己是怎么考虑的，只有比开发想的更多，才能不被质疑。而无论是开发也好，美术也好，在反问你的时候，你都可以对答如流，“噢，这个问题我考虑过，我认为这里应该balabalabala，这样可以解决balabala的问题，所以我这里的设定是没有问题的”。这样几次一来，一方面开发本身对你的质疑也很更少，另一方面对你的信任也会更高，“嗯，这小子靠谱，我就不操心啦”。
所以：“不要给别人质疑你的机会”。
2.适当的话术能力。
我们先来看一下话术这个词：
话术（来源百度百科）：
1）说话做人的艺术，一般多用在仕途和商道之上；
2）说话的技巧，可以更加完善的表达出自己的意愿，收获到良好的结果或者自己预期的结果；
3）说话的方法，使用各种行文，语速的方法，可以恰当的表达出自己应该表达的意思，比如抑扬顿挫，排比，拟真等；
4）是一种统称，是对于心术、权术等一系列为人处事技巧的统称，表达出某人很是心思敏捷、才智过人的特点。
这里面有几个要点，说话做人，完善表达自己的意愿，行文语速，心术。
说话做人，这种事情其实不用多说，没有人喜欢别人扯着嗓子，昂着头跟自己说话，和程序祖宗沟通的时候，放低点姿态，夹着尾巴，毕竟你是求人办事，先把自己放在一个较低的身段下，取得好的开端。
完善表达自己的意愿，和上面第一点说的一样，你得表述清楚，准备充分。
行文语速，这是基本功，不赘述。
心术，这里需要提一下，所谓心术，其实更多的是要了解对方的心理，能够戳中对方的G点，那你就赢了，所以这里说的简单一点，作为一个普通策划，也要擅长给程序祖宗们“画饼”。
“我靠，强爷，这个匹配算法屌爆了啊，代码齐整开销小负载低，就一个字，绝！”，自我满足饼一张。
“这一改，年终奖就哗哗来了啊！”，现实利益饼一张。
人与人交流，无外乎投其所好，你的话打动了对方，对方自然也会对你客气和善。
3.策划的方案没有不修改的，那么这种时候你需要…
如果是因为没想好，或者是没想清楚导致的修改，脸皮要厚，要无耻，要下流，要把能用上的招数都用上，或者事先就和开发协商好，这里可能会有修改，你要预留好一些空间。但其实在我的工作经历中，很少会做这样的事，因为如果你的第一条足够优秀，第二条使用得到，很少会走到这一步。
如果是经过测试发现存在问题，那么简单一些，摆事实，讲道理咯，但依然要记得这种时候，策划本身是没有做好的，就像开发的bug一样，你不能趾高气昂的去和别人沟通，就像开发也不会趾高气昂的去改bug一样。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
所以综上所述，无论出于哪个方面，策划是所有事情的源头，有责任和义务仔细想清楚每一个设定每一个细节应该如何去做，因为你的一点失误，会导致别人的辛苦白费，因为务必要对自己的设定负责，不要让自己成为一个不负责任，总给别人添麻烦的人。
而从团队关系本身，国内的策划和美术团队可能没什么共同语言，和开发团队还是可以谈得来的，都是一群直男宅男，没事出去撸个串喝个酒，增进一下感情，两三百一顿的撸串就可以收买几个替你做牛做马的好开发，多划算的生意啊。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
有人问到如何恢复团队之间的信任，其实方法就是不要犯第一条错误，这是沟通的基础，我们坐下来面对面的沟通需求，应该是双方都有充分的准备，所以首先是提高策划自己本身的思维能力。
然后有很多方法，但原则是一条，第一步就是要让开发团队认为：“这个策划不错，有担当，有责任感”。
我所在的团队以前也遭遇过这样的问题，一个大的端游团队在主策的带领下愣是和开发没什么交集，沟通核对需求也是老夫老妻交公粮似的照章办事，开发经常质疑策划的方案和能力。后来我们出了一个方法，每一个系统都有自己所属的责任team，然后team里面的策划是这个系统的负责人，如果这个系统出现了任何问题，那么责任人要请全工作室人吃papa johns（一顿就是15张15寸pizza啊…）。这个规章出来以后的第一个黑锅就是再下背了，我们的后台老程序员在自己优化物品栏的代码时，优化出了一个非常隐蔽的复制道具的bug，然后被外网玩家发现了，折腾了一宿，修复，扫挡，查log，封号，删复制的物品，折腾了一宿。其实我那周没有提任何跟物品栏有关的改动，但我这一顿papa johns还是请了，几个老开发都觉得不好意思说要不我AA，我说没事，算我的。打那以后，开发和策划的关系逐步改善，我没事就会去开发那边转转，闲聊之余顺便关心一下进度，一起做事那就是交心的兄弟。
这件事的潜在台词是什么？如果出了问题，我会受到最大的罚则，那么我提出的需求一定会经过我自己的仔细思考，而对应的程序也会更加小心，因为自己的问题导致别人受罚，终归不是好事儿。
当然这只是我自己亲身经历的例子，目的还是在于修复关系，树立责任感以及给自己也敲响警钟，凡事要三思，只是有人问起，就给大家做个参考，未必要照做了。ps：当时的收入，一个月要是来两顿papa johns，发完工资就别活了。
同意排名第一的 @王子笑 的答案，我就站在策划的角度上补充一下
曾几何时，在我刚入行的时候，也遇到过类似题主的麻烦，很快我意识到程序抵触的原因是策划给出的设计案转化为程序功能时有困难。（比如联网游戏里很典型的一类策划需求：对离线玩家进行状态监控及数据操作。对于大部分游戏服务器来说，对玩家的操作都应该是在玩家登陆后，游戏数据从数据库装载至服务器内存后才能进行操作的。）
另外有些不那么勤快的策划会为了避免承担工作量重新设计，或基于“策划就要有决断的权力”这样难以启齿的理由而要求程序就照着案子做，而且还总是加上“以后绝对不改了”这样的宣言来搞霸王硬上弓，久而久之就会让程序觉得这策划“不靠谱”。
而这个“不靠谱”的标签，就是题主遭遇到的一切问题的根源。当程序觉得策划不靠谱到一定程度后，在每次看到策划的时候就会开始本能的进入自我保护心理状态，对策划说的一切都抱持怀疑和抵触。更严重的情况下就是该程序被坑惨了之后会给“策划”这个职位贴上“不靠谱”的标签，导致所有与之打交道的策划都需要承担额外的沟通成本。（所以每次遇到这样的程序，我的第一反应是揣测他之前曾经被策划怎样惨痛地伤害过……）
好了，说到这里，我要表达的意思就应该很明白了。那就是要让自己变得“靠谱”。靠谱的意思是：
1. 不要老是提一些程序框架内很难搞的需求。什么频繁操作离线玩家数据啊，什么超智能AI啊，什么超级物理模拟啊，什么超省心游戏内容自动生成啊blabla。游戏里的脏活累活那是逃不掉的，遇到这些问题的时候，负担起策划的职责，要记住这个职位虽然中文叫策划但是英文叫Designer，你不仅要提出需求，还应该设计出这个需求的解决处理方法
2. 诚恳与虚心。不懂的东西要即时问，被程序嘲笑抵触了不要马上进入防御模式先问清楚程序抵触的理由，设计不合理的时候，主动承担起重新设计的职责。一来二去，就算程序知道你确实不懂，至少程序知道你不是个没原则的人，会愿意花时间详细跟你解释不合理的地方在哪儿，也会愿意跟你分享他自己的解决问题思路。这么来上几次，你也就知道哪些设计是坑哪些东西要避免，策划案就更容易一次过。等到策划案经常能一次过的时候，程序就不会再跟你摆谱了。
3. 不要乱下承诺。对，我说的就是“以后不改了”。这个承诺不仅仅是向程序隐瞒工作量，更有可能导致程序在写功能的时候按照“以后不改了”的前提写框架。等到你再去跟程序说要改，这代码可能就得伤筋动骨地大改，这程序不跟你撕逼可能么？所以我的习惯就是，首先跟程序说清楚哪些功能可能会处于长期演进频繁迭代的状态，这样程序在做的时候就会考虑预先留好接口啥的；然后就是在开发过程中不断积累经验，尝试在下一次提出功能需求的时候，给出一个更具弹性的设计。比如将大部分的数据剥离出来交给策划配置，不用修改程序框架就可以尽可能多的满足策划的需求变更。如果策划可以坦诚交流，并帮助程序减少工作量，程序才不会抵触策划呢，相反程序还会变成你的拥护者，为你的设计案提供更多改进建议。一旦你能和程序达到这样的沟通状态，那工作起来是超省心的～
4. 条理清晰的沟通。遇到不懂的问题，首先先仔细想想自己应该问什么问题、怎样问，以占用他人最少时间的方式获取最多的信息；有了设计案后，先自己的读一遍，把冗长繁复的文字表述精简掉，把核心规则提炼一下；如果一个设计里面细节很多，想办法在文档里写成一个明晰的列表，让程序可以轻易转化成自己的TODO List；向程序讲解时，说清楚你的设计目的，然后配上简洁的文档，两边都舒服。说到这里，其实我很不喜欢那些动辄万字的文档，基本上这类文档在我的概念里都属于策划感动自己的产物（“我好辛苦啊好敬业啊一份文档写了好几万字啊”），我自己成文交给程序的文档一般都会尽量控制在3000字以内（一个正常的小系统），宁可多做示意图/流程图/交互式RP来减少文档字数。这样子结成的文档看起来才不会有精神压力。
5. 尊重程序。既要尊重程序员本人和他的正常需求（比如要开小差要玩乐会有自己喜欢的游戏也希望自己的工作有意义），也要尊重“游戏开发的本质是软件开发”这一基本事实。学习程序知识，了解项目的程序基本框架，以程序员熟悉的方式进行沟通。没人喜欢被屁都不懂的外行指挥和领导，你需要向他们证明自己是一个称职的开发人员。如此，你们才能成为互相尊重的朋友，而成为了朋友那就一切都好说了。不要觉得学程序不是策划的分内事，Valve是明确要求Designer了解程序知识的。
6. 追求共同价值。虽然这件事其实主策/制作人之外的普通策划能做的不多，但还是要提出来说一下。很多程序入行也是因为他们喜欢游戏，他们也有明确的爱憎，这一点和策划是一样的。作为策划，在能力范畴内努力做些能让大家都感到自豪的东西是必要的。对游戏的尊重、对高精尖的技术追求，是真有可能调动起热爱游戏的程序的热情的，而这些程序的热情一旦被激发出来，你就笑吧～
以上，当你把这些都做好之后，程序就不会再跟你摆谱了，相反，你会发现他们愿意成为你的好伙伴，而且还会经常要求你请他们吃饭，捂脸……
我早就担心这个，所以自己学了程序。有时费心与人沟通不如直接和机器沟通。
自己懂程序的另一个好处是，与程序员沟通起来双方都能轻松很多。
泻药。手机怒答。
我没有遇到过题主说的那种程序员，不知道是运气好还是其他原因，不过可以告诉楼主几大自己总结的沟通原则。
1 放低姿态，别把话说满
2 提交需求前跟直接领导，对接程序员，主程等人开碰头会，或者邮件确认，再开始制作。
3 可能的变量，尽量走配置，不写死
4 制作过程中外部来的需求或自己的新想法，三思而后行
5 确认有需求变更，尽快积极沟通，并做好文档修改
6 开发过程中最好去跟进下进度，2次左右为宜（具体频次视功能大小而定）,多正面鼓励:哥你太牛x了，这么快就做完了！
7 最重要的是多培养下基情以我的经验很多时候都是真心是策划水平问题，因为我接触过不少靠谱的高级策划设计的东西一开始就很成体系，其实程序不是反感策划改需求，是反感笨策划，设计的东西各种yy不成体系，然后动不动就推翻自己。牛b的策划给你的需求基本一看漏洞就很少，然后和程序对一下完善一下。后面难免要改要完善，但是更改理由有理有据，程序一看哦却是有道理我也没想到那就该吧。
所以不能一概而论，笨策划那就不断提高自己，同时贵在有自知之明，有的笨策划很虚心，会和程序请教讨论，有修改也是各种好言好语给你交朋友，这种所谓伸手不打笑脸人，就当帮朋友了；有的策划很笨还自以为是，明明能力有限还案子里连程序流程图都敢瞎画，跩的二五八万，这种绝对拍死不给好脸的。
综上所述，要么有能力智商高；要么会交流情商高。两样都不沾的混的苦就认命吧。
策划，不匿
从名字就能看出了吧，背锅的总是我
首先我必须说，游戏是个TEAMWORK，如果出现状况1和2，那么策划或者程序之中有一人有严重问题
1.对设计本身不理解，反复解释后表达不认同，然后就是不做！
2.在项目经理或者老板高压必须要做之后，表示极大的反感，表现出威胁行为（威胁要骂人或者打人）的举动。
说实话吧，策划几乎没人自己提需求的，大多数策划的工作是吧各路需求转化为可供给程序员的文档，如果是这个需求不出自你，而是别人，直接告诉程序这个不是你定的就好了，如果就是不做，直接找PM。
无论怎么说，威胁要骂人或打人。我只能建议录音存证并且和PM主策沟通。申请尽量不和这个程序合作了。
这是态度问题（没想到我会提这个词），你的安全受到了威胁的时候，你要保护自己。
上面的程序员这么多，我敢问一句，你们对最扯淡的策划/产品会进行人身攻击的威胁吗？我觉得这个是不可接受的。
3.4.5是另一种问题，写好策划案，以至于对整个项目进行跟进和把控是你的工作，把自己的工作尽量做好是本职。策划是流程的最上层，你所做的决定着整个游戏的品质和项目开发进度是否顺畅。
策划案的修改和BUG是有一个质的不同的
策划案的修改是因为没有达到预期的作用才会修改。为什么没有达到，就是因为再设计的最初，构思就不完善。要么是你想的实现方式不切合游戏具体情况（时间，人员，底层架构）
而程序的BUG是实施过程中产生的疏忽。
理论上策划案在进入开发流程之前需要做些验证，感受一下操作是否舒适啊，逻辑是否正常啊，然后才进入开发流程，之后除非出现大问题或者改版就不应该进行修改了。
但是实际上现在的设计周期非常短，策划往往赶了一个案子就拍给程序了。
改案子和改代码不是一个概念，尽量悠着来吧。
如果你的案子是错字稍多的问题（比如我）只有主策会告诉你改过来。程序很少因为这个挑刺……
我个人建议是，写案子的时候，一些设计到技术会出问题的点，提前问问程序能否实现或者实现的时间。一些具体配置问题，尽量做成动态加载的自己调试。
沟通才是策划第一位的工作啊
其实很多时候，策划案不能代表策划自己的意思，制作，渠道，运营往往有些各种奇怪的点子啪的就拍过来了。很可能你们见到的已经是策划撕逼几轮之后的结果了
很多时候，我们也没办法。
策划案改了我们也很麻烦的，有这个时间知乎水一下不好吗~
如果不爱，请不要伤害
题主说的这个问题，实际上是一个游戏开发过程中典型的“边界问题“，2年前我在GameRes上曾经分析过一些这个问题（这里我不直接转过来，发一个连接是对GameRes的尊重[研发经验] 导致游戏研发不顺利的几个典型“边界问题”）
但是针对题主疑问中特指的程序，也是存在一定问题的，我在这里进一步分析一下，一些程序员在开发中可能存在的问题，也会导致项目出现不和谐：
1，程序员抱着一套熟悉的东西，不愿意接受新鲜事物。
这是一个典型的问题，尤其会出现在一些水平不行，但资格很老的”程序员“当中，他们往往还是”主程”“技术总监”甚至是“CTO”。实际上这是一个本性问题——人比较喜欢选择自己习惯的东西，但正因如此，才限制了自己的成长。比如一个程序员居然会跟你说项目代码管理用SVN，而不用Git，首先这说明他并不知道SVN的一些问题在项目开发中得不到解决，而GIT解决了，比如我们在开发中会面对多个方案，这时候我们可以很好地利用Git的分支，最后开发完后，我们Merge所有有价值的分支，而把一些不需要的分支放弃了（也不是删除了，丢那里就行了，没准哪天……），而这一环的处理上SVN甚至会丢版本。当然这里就不扯开说了，不然就歪楼了。为什么他选择SVN，因为他熟悉SVN。但是作为一个程序员来说，你必须要学习观察新的东西，因为世界是新的。尤其是作为程序员，技术更新太快了，所以才真的是“活到老学到老”，尤其是CTO，他的职责就是分析最前沿的技术，选择一个合适的技术走向，这时候如何选择能够成熟的技术很重要。如果你一贯抱着老的思路、做法做事情，纳什万万不行的。
这个问题还会体现在一些内容开发上，很多程序员参与过一些项目，用硬编码打补丁的方式完成了开发（当然这些开发内容我个人认为是策划做的，但是国内的情况你也知道），然后他就抱着这套思路到处这么做，永不接收别人的建议，直到遇到问题了才临时想一个办法，也就是拿这一把锤子，看什么都是钉子的思路。这里我就又要说一个关于游戏中buff的做法，曾经我在GameRes也发过一个Buff机制，但是到今天，他又得到了很大的改进，大多是来自行业里面程序和策划朋友的实战经验的总结，通过不断的Merge一些想法和做法，我不断的优化他，也不断的分享他希望得到优化，但是我很难让一些思想守旧的人接受他， 他们认为这套东西太重了，也认为自己的做法能解决一切问题了，不愿意Merge新的东西，但我看到的是——他们的思路都是我大学毕业前（2002年）的做法，已经过时很久了，连一个简单的小任务都需要硬编码去做（大菠萝模式的ARPG，任务内容是：丢香蕉在地上，然后吸引最近的一只猴子过来吃香蕉，通过反复丢香蕉把猴子骗到笼子里面）。当我设计了玩法之后，他们又楞眼了，要么说设计的太复杂无法实现，要么就在表格不断加列（通常一个项目挂掉的核心原因之一是表格长达数百列，且大多是MagicNumber导致策划无法工作，最后产品缺乏内容挂掉），但在我看来实现这些东西（包括我自己去做）都是几个小时就能完成的（我曾经挑战过用朋友的Entity System构架在他的引擎上开发H5游戏，2小时左右就完成了一个小游戏开发，但是他没有成功作品，所以不能想egret这么拽，只是产品推广问题但这里不细说，详细做法我在GameRes也发帖说过）。
对于一个程序员来说，最要不得的精神就是不愿意去接受新的东西，不愿意去Merge别人的思路。这通常就是最后导致题主所说问题的导火线。
这也是一个很有意思的问题，通常出现在程序和策划沟通的时候，而这个问题往往也会导致程序员做出来的东西0扩展性，或者一些功能永远无法说服自己去写（通常这也是一种缺乏抽象能力的表现）。具体表现在程序员过于关心一个系统的设计，比如你设计了一个签到系统，和开心消消乐一样，每天签到，只是增加1点进度，而不是签到在几月几号，可是一些程序员就会怀疑这个设计。每一个设计本身都会有争议，如果没有争议，就不需要设计师去设计，这才是关键，所以这个系统最后的好坏，你并不需要花时间去争论。尤其是当你是一个实现者的时候，你要理解一点——只要这个玩法本身没有逻辑问题，他就是好的，你应该相信你的设计师设计的东西是好玩的，或者就换一个工作（或者设计师），找一个更靠谱（确切的说适合自己更志同道合）的设计师。
为什么我会说这样的程序员往往缺乏抽象能力，我并不认为有责任心是坏事儿，但是有时候责任心必须有个限度。比如我做一个Buff，他的功能就是“让携带者每3秒受到释放者(caster)魔力值30%的伤害，如果Caster为Null，则受到30点伤害”。我不应该关心这个设计是否合理，因为设计师花了很多心思去设计，有它的道理，同时我更不应该关心Caster会是谁，只要设计是给了我明确地Caster定义——它是通过调用CreateBuff函数传递给我的，并且可能是Null。整个逻辑中没有问题，那么我就不应该问Caster怎么来，Caster怎么来呢？他可能是一个AOE产生的，他的Caster也许就是AOE的释放者；可能是一个Bullet产生的，他的Caster可能就是这个Bullet的释放者，请注意这里我用到了“可能”而不是肯定的就是这样，因为我并不关心是哪儿来的，因为产生这个Buff的可能性还有一条GM命令，一段其他的逻辑代码。因此在合作开发中，我不能“太过有责任心”，因为这样刨根问底，不仅浪费时间，还会带来不愉快的气氛，而得到的答案还是让我并不能满意的，事实上错误的根源在于我去问了这个问题，因为我本身要做的事情就是去完成一个Y=F(X)的东西，X只要符合事先说好的类型，就应该能产生Y，而这个Y一定是让人满意的。
1 不认同类的，就是修改的重要和必要性尚不充分，他那还有一票别的事不见得会处理这个。
2 高压类的，如果至少是自洽的还好说，有时有个看起来简单的东西背后深藏一系列复杂关联，策划和施压的人根本一开始就没动脑子想清楚，对一个初级和中级程序来讲，他们往往也不讲究反向验证和推进需求。所以，想不清楚就逼，逼着做时不想，做完发现仍不达标是很常见的。
3 在中途抱怨程序设计不合格时，策划应该去区分是逻辑流程结构要改，还是细节内容条件要改，还是整个需求变更了。判断什么是错的和知道怎么才能做对是两件事，只知其一不知其二是不少策划的常态；而程序有时为了减免脑负荷也不多想设计的合理性问题把包袱都丢给别人，这也是种低素质的表现。两头得至少有一个是靠谱的不然这事没边，得换人牵头设计或改造。
4 说不改才肯做的是二逼。但对于预测修改频度和强度这种事，恐怕连普通pm都是心里没谱的，策划更是如此。但是这很重要! 一旦能想清楚变动的规律，就更加容易对改动隔离、对设计解藕。水平不够时，就只能堆人力改到死。
5 被嘲笑，被黑是很正常的，如果这样就能化解仇恨，达到宣泄的效果。不过为了避免双向累积仇恨，应该是程序笑策划，QA笑程序，策划笑Pm，pm呵呵一生。不请自来。 改功能不会反感，但是请发正式邮件，并抄送给相关需要知道这件事的人，包括各种负责人。因为这表明，你的改需求计划不是一时冲动，你愿意为你负责的东西承担相应责任。开发人员会安排好时间的。
开发人员反感的是，有大体方案，但是方案没细节，然后一会儿跑过来说一下细节，一会儿再来说一下。
所以，发邮件，写好策划案，尽量避免临时需求，其他非策划人员哪怕是boss提出来的需求，你们策划也要内部讨论啊，老板要伺候，方案质量也要保证啊。说难听点，方案差我们一样能按你的方案做出来，到时候第一个被喷的绝对不是开发人员你信不信。
正反两方面，都来讲讲这个问题。
首先说结论
中国 游戏程序员是个非常特殊的工种，如果你不能控制需求的结构，你最后程序也是一片火海。
- 你应该考虑这个需求本身的合理性，做出来会不会给系统带来一些趣味的增加，如果可以，那么即便不是特别合理，也可以试试做一做，做不容易做出来更有挑战的东西，在某些情况下是对你本身有意义的。
- 有时候盲目的拒绝需求，对整个团队的推进并无好处，你看上去的拒绝可能对组内其他人有潜移默化的影响，有些合理的需求也推进缓慢。
反面的结论如下：
- 不合理的需求，不仅仅会影响进度，也会影响到你程序的内部，最终不仅仅是代码腐烂，所有前期看来是生产力的东西都是拖后腿无尽的bug。比如说(以下是黑)，我们策划需要控制所有东西，动画的每一帧的回调，ai的每一帧，ai的逻辑怎么跑，包括ai的参数注入各种在运行期loadstring，在一开始看起来就是，我想配置一下试试更多的可能性，到后期就是，卧槽这个表我不会配置了怎么办，配置一个表程序要修一天bug怎么办。各种各样。
- 不合理的需求，会影响团队士气。一个系统迭代个3遍，那是大家觉得正常，迭代10遍，只能说是无能了。后期就会美术，程序，策划，全部士气失守，项目最后面临所有人骑虎难下的结果。
应该怎么办？
- 首先足够的规划，你能不能开一个项目的时候，先出个白皮书啊，把核心体验论证好啊。不要直接日狗好不好，先看看公母什么的对吧。
- 要有真正的责任感和担当，别一个项目我把程序美术干跑两拨了，下一个项目我又主策去了。立项的时候就说好，干不成我就引咎辞职当众吞粪二选一就好啦对吧。(我要是主策我是敢这么说的)。
作为程序嘛，写好你的代码，提高你的素养，不要一直业务，不能一辈子业务狗。要对代码负责，不能因为别人怎样，就降低自己的要求。
现在游戏厂商上新功能都不需要评审的？
没有评审过的东西给我，我也拒绝实现。btw，我是做企业应用的，我们每一个功能点的需求和设计都至少要经过两轮评审才能开工写。忍不住答一下，以个人经历来看，大部分策划都无法能够达到让程序信任的程度。
策划在设计的时候，需要考虑到数据表的读取逻辑，服务端和客户端各自的分工与实现逻辑，服务器端是否要记录某些值，客户端是采用什么处理流程来实现界面的。
策划不只是写写文档然后扔一个需求过去就可以的，必须要对整个实现制作流程有一个清晰的认识才行，否则你不会去考虑当前机制可以容纳哪些扩展，也不会知道新的需求如何实现成本最低。
我做了5年策划，遇到的这方面能做到的策划屈指可数，大多数就是丢个需求过去，剩下的交给程序去考虑了，完全不在意自己的设计是如何实现在游戏中的，说实话，我要是程序，你随意提修改需求的这么搞几次，我也不信任你，不愿给你做。
先从自己做起，等你做到了这些，再去挑程序的毛病。@Jay Zhuang 说的很好了（程序员对游戏设计师提出的需求表示反感怎么办？ - Jay Zhuang 的回答），原因无外乎那么几点：程序对策划不信任；个别程序消极对待这份只是拿来糊口的工作。
我自己是程序，现在也做一点策划，业余时间自己做游戏。
我拿到策划案后，都会提些自己的想法，通常是一些基本不影响实现效果但制作成本和维护难度大大降低的改动，有时也会质疑策划的设计思路，但这个时候我很希望策划能用他对这个设计的理解来说服我，希望他比我专业，而不是告诉我“xx游戏就是这样的”。如果一个需求，我和策划能达成一致，上线后成不成都没啥可说的，但如果是策划强制要求实现一个我不认可的方案（处于对分工的尊重，程序肯定会做的），上线后两种情况：
1：成功了，你牛逼，你要是一直这样牛逼下去你就是乔布斯
2：失败了，你傻逼，明显不行的东西你非要做，你在我这里扣声望
如果一个策划一直扣声望，最终，就会失去程序的信任。所以，并不是说程序可以出bug而不允许策划改需求，而是说如果策划总是一意孤行又总是失败，那就多反思一下吧。
另外，改需求对制作人员来说，确实是件很痛苦的事，要理解。我自己做小游戏时，有次想加一个新手引导，告诉玩家游戏通过触摸而不是重力感应来操作。开始我想当发现玩家尝试用重力感应操作时给出提示，于是我写了很长很长的代码来判断玩家是否在尝试摇晃手机（考虑各种特殊情况比如玩家躺着玩），最终效果都不理想，于是忍痛删掉了这段逻辑，简化成没有触摸就提示。当时我想要是我为其他策划需求写了这么复杂的逻辑肯定是舍不得删的。
所以，如果团队建设做的好，每个人对产品有很强的责任感，你说的问题会减轻些。怎么让每个人更有工作激情，就是管理者要考虑的问题了，问题太大不细说。
其它的答案里对策划方面需要做的事情说得挺好了。
这种情况挺常见的。当然表现得不会那么极端。
个人觉得这主要是由于程序员（尤其是游戏程序员）对自己的工作没有认同感。因为他做的是“别人提出来的需求”，而且“出了问题是自己承担”。在游戏开发这种需求经常变动的环境下尤甚。设想一下，如果他是一个独立开发者，写的代码都只是满足自己的需求，做得是自己的东西，那么肯定不会诸多抱怨。这也是很多人离开大型团队，自己独立开发的一部分原因。
但毕竟一个大型团队中复杂游戏系统的开发，设计环节和实现环节肯定是要分开的。为了让程序员对自己的工作有认同感，那最好还是令他们看到自己的“作品”，认识到自己的工作成果，并不是“为他人作嫁衣”。
按说游戏行业做到这点本来更加容易的，毕竟游戏不比软件，本身是有趣味性的。
比如说开发AI的程序，在看游戏测试的时候，自己就会觉得“嗯，这个地方敌人的反应有些奇怪，哪些行为需要规范一下”等等，这种时候不用策划去提需求，也会进行改正的。就算是与策划有些争执，那也是良性的，甚至是“开心”的争辩，毕竟大家都是为了改进游戏品质。
但在国内的市场环境下，尤其是手游方面，大家都是抄抄抄，很难在自己做出来的山寨产品中找什么认同感。所以也很难让程序员（其实也包括其它团队成员）找到工作热情。
国外的开发者对国内团队的看法通常是三个字：“不专业”。这并不仅仅指技术上的落后，也包括了对工作本身的态度。其实也就是说，就算对设计颇有微词，可以与设计进行探讨，但不能推卸；就算游戏的玩法自己并不喜欢，也不能消极怠工。多理解理解吧，这个问题很多公司都存在，尤其是迭代速度快的公司。
很多这种开发和pm、设计师之间的问题都可以归结到权责划分不清的问题。修改需求、新设计方案敲定本身没问题，确定方案的权力是谁的，他对哪个团队、部门负责？方案执行、出现问题时谁承担责任、擦屁股？
在国内这样的分工流程，策划的权责显然有些不对等，当然这跟国内游戏重运营和用户黏性有关系。而国外有的公司甚至没有designer和策划，只有工程师（有类似设计师的体验工程师）。这是因为自己的想法要被认可接受需要先自己实现和验证。
题主的问题不是一天两天可以解决的。增进跟开发的感情是一方面，你还需要在开发那里建立”可依赖“度。用数据、市场表现、用户反馈这些显而易见的证据来证明你不是一个吃干饭的。老板下派垃圾任务，你据理力据了没？表现给开发啊，让他觉得你是靠谱的。写了快3000字，删掉了。
我就说几个结论:
1.策划平均水平确实偏低。为什么？门槛。
2.很多策划总觉得自己是需求提出方，实现是别人的事情……先做做看，有问题再改，不详细的再提。大哥，我们是平级，你不是老板，更不是我大爷！
3.很多策划并不把别人的专业性当回事，经常看到看到策划说自己想学程序之类，或者美术。我只能这么说，别觉得自己不专业，别人也不专业。别人不专业是站不到这个位置的，你继续不专业，三心两意，会连现在的位置都站不了。
4.策划是应该专业的。现在做不到专业，不代表就不该专业。有一点大家应该承认，策划能力是一个游戏是否能成功最关键的部分。但是现在却有种风气，认为策划案怎么写都只能这样，认为这玩意怎么写都是错的，没有规律可循，要成只能靠运气。我了个去，那你就这么想下去吧。
别说什么我不懂策划。以前我确实不懂，所以策划和我意见有分歧，我都认为是我不懂，他们懂。经过这么多项目我才知道，原来他们也不懂。
----
突然发现遗漏了非常重要的一点，我刚才一直想的是“相对无法掌控”的系统策划部分。但是题主貌似说的是“细节”，还专门粗体。那个语气，貌似是觉得“细节”不重要？
……
你不在于细节，那我程序偶尔抽个风卡界面也没事吧，美术部分图片直接是草图也没事吧。
反正也不影响玩家游戏，玩家又不会仅仅因为这么个细节就滚蛋
呵呵呵……
以前蓝海的时候是可以。现在？
不依靠细节就想在现在的市场存活，题主对自己的策划能力相当自信啊，看来是大神来的啊。
如此大神请一定尊临本公司，给咱们这些只能靠扣细节谋求活路的蠢才开开光。
现如今，虽然能力强的策划少，态度好的可是比比皆是。
愿题主早日回头是岸，没什么好说的了。
----
补充下，程序是可以不出BUG的，无非是自测，需要花费时间。由测试来进行这一步效率更高，成本更低。你策划案子错了……
以前一个程序跟我说的：
如果策划改了需求，那程序这边就得追加相应的开发时间。造成的延期得由策划这个变动需求的人兜着，只要策划能跟上面争取到对应的开发时间就行。争取不到么，就不要怪别人了。
推薦閱讀：
※怎樣進入國外的遊戲行業工作？
※初創遊戲團隊製作遊戲時，「怎樣讓遊戲好玩有新意」和「怎樣讓遊戲賺錢」何者更為重要？為什麼？