做了几年flash webgame游戏界面UI，1，对UI确实没有什么感觉，2，现在很迷茫不知道该如何规划自己的技术发展，对制作游戏还是很感兴趣。
这个还要分前台和后台。一般来说，前台需要专注界面UI、图像等部分的开发、后台需要注重服务器设计、网络编程。前后台主要用的编程语言有：页游的前台：html5、flash、javascrit ..页游的后台：java、php、.net、C++ ..端游前台：C++.端游后台：C++、J***A..手游就不说了，类似，只是端上的编程现在主要是 obective c 、 J***A
做游戏开发13年了，说点我自己的感受。&br&1.新入行的游戏程序猿一般都从UI做起，因为UI开发中简单重复而琐碎的工作相对比较多。我的从业经历中，见过几个因为UI多次改版不堪其苦愤而离职的程序猿。&br&2.立志做游戏开发的程序猿往往是因为觉得自己算法牛B或者架构牛B，但是核心算法和系统架构这类重要的事情，一个负责人的管理者不会把它交给3年经历以下的程序猿，所以新入行以提升自身能力为主，不要还没学会走路就想跑步。&br&3.程序猿往往看不起UI开发，就是常说的对UI没感觉。个人觉得程序做哪方面的功能其实差别不大，关键是做好该做的事情、提升自己的能力，如果能力能胜任更多更高的工作内容，我相信一个明眼的上司会给你在工作内容和薪资上予以调整，如果他没看到你的提升，你可以找他沟通。抱怨、迷茫不会解决任何问题。&br&4.我的个人经历，初入行我也是做UI的（当年还是用C++和DX来开发pc游戏），做的过程中我发现游戏UI经常会变更需求甚至推翻了重新设计。我也不想每改版一次我就重新全部做一遍，于是就想办法把ui逻辑和ui视图分开（ui逻辑往往变化很小，只是视图会修改），另外UI经常会涉及到坐标调整，我就把坐标从配置文件中读取，如果调坐标直接改配置文件即可，连重新编译都不需要。慢慢的我发现我能预测到哪些地方将来会改，因为设计不合理，然后我发现在用程序实现之前就可以给策划提意见避免一些错误和不良设计的出现。到项目做完之后，我基本上整理出一套UI库，涵盖常用的控件，很方便的调整位置及配图。我的工作变的轻松，于是我就琢磨设计模式和重构，也有时间研究一点自己感兴趣的东西。新的项目我被分配做我更感兴趣的事情，但是我留下的UI代码很大部分可以用到新项目中。&br&5.想说的是代码其实无所谓用在哪里，能不断提升自己能力才是关键。给你的每件事认认真真做好做透，能力就会全面提升。有句古话说的好，一屋不扫，何以扫天下。&br&6.语言不是关键，类库也不是，分析问题解决问题的能力才是。我用C++10年，突然有项目要用C＃，我边做边学，一样上手，差异的只是语法，解决问题的思路几乎没有差异。庖丁解牛，只要有把刀就行……&br&??嗦嗦写了这么多，总结为一点，学好设计模式和重构。&br&设计模式好比独孤九剑，见招拆招。重构好比太极，无招胜有招。
做游戏开发13年了，说点我自己的感受。 1.新入行的游戏程序猿一般都从UI做起，因为UI开发中简单重复而琐碎的工作相对比较多。我的从业经历中，见过几个因为UI多次改版不堪其苦愤而离职的程序猿。 2.立志做游戏开发的程序猿往往是因为觉得自己算法牛B或者架…
后台的话:&br&1. 标准C/C++&br&2. Linux/Unix系统编程&br&3. 分布式程序设计&br&4. 系统架构设计&br&5. AI&br&6. 物理,碰撞检测&br&7. 足够好的数据结构和算法知识&br&
后台的话: 1. 标准C/C++ 2. Linux/Unix系统编程 3. 分布式程序设计 4. 系统架构设计 5. AI 6. 物理,碰撞检测 7. 足够好的数据结构和算法知识
已有帐号？
无法登录？
社交帐号登录
爱生活，爱互联网，爱游戏！程序员对游戏设计师提出的需求表示反感怎么办？
情况有如下几种（几种情况会并列出现）：1.对设计本身不理解，反复解释后表达不认同，然后就是不做！2.在项目经理或者老板高压必须要做之后，表示极大的反感，表现出威胁行为（威胁要骂人或者打人）的举动。3.策划发现前提某个需求的设计（细节）不合理，提出修改，表示不耐烦，威胁“不准再改，否则不干、扣工资……。4.每次提出要修改的需求，都要策划表明：“不会再进行修改”，然后才能做。5.一旦策划的需求出现BUG或者不合理的地方，表示嘲笑，不耐烦，态度比较恶劣。PS：多数情况下，上述情况都是在大家的忍让下过去的。但是我会产生疑问：为什么策划理解程序做的功能“一定会有BUG”，而程序不理解策划提的需求“一定会修改”？合理的逻辑不应该是：你既然要求我的需求“不要再修改”，那么你做的“功能就不要出现BUG”？请不要讨论包含以下极端情况：1.策划口头要求程序做某个大功能，而没有具体方案。2.程序与策划进行殴打行为……如果出现以上情况，那么这就不是谁对谁错的问题了，而是相关责任人直接可以走人了。----------------------------------------针对某些老板和运营/策划在项目中反复对需求进行修改的问题，作为策划我表示同样反感----而且是极其反感。在下作为策划跪求获得可行性措施啊啊啊啊啊……而不是【谁背锅】这个无关紧要的问题：一般情况下项目内成员都不会被因为项目本身的功能BUG处罚，所以追究谁的责任没有作用。
按时间排序
虽然有时候产品经理提的要求确实很难实现，但确实有些可以实现的效果，不过特别麻烦，而且有点难度，最要命的是程序员认为这个需求没有必要实现。iOS上有个switch按钮，我做的app给朋友看后，他说这个按钮不能搞大点嘛。我说苹果就是这么任性，这个按钮苹果已经封装好了，尺寸不可更改的。那你自己做一个啊，你不会这都做不出来吧。。。。。。其实这个按钮也蛮复杂的，是个圆柱体，头尾是圆的，白色边缘，中间有个白色小圆，闭合状态背景是透明的。从点击也就是touchdown的时候，小圆变成大一点的椭圆，然后是一个动画效果：白边像中间聚拢延伸最后充满。松开后也就是touchupInside的时候，小圆会滚到右边，左边漏出的背景被绿色填充。再点一下，小圆重复动作回到左边，右边漏出的白色背景，会像四周延伸最后只剩一个边缘线，漏出透明背景。实现简单开关并不难，主要是细节的动画效果，需要计算很多，考虑很多。再就是变更需求，我想了想，想不到什么好栗子。大致情况就是这样的，有些需求一旦变更，如果之前没有留好坑（降低耦合性，提高扩展性），需求一变就是一个大坑，大多数需求变更会删改很多的代码，少数还会影响到大架构，如果是个经验不丰厚的新手，比重新写一遍不会快太多时间，因为删改的时候总伴随着bug。最后总结下程序员的想法：这个需求根本无法实现，who can who up，你吃屎去吧，老子不干了。这个需求可以实现，但是太难了，而且没有必要，最重要的是我还不会，所以真搞不懂你特么是怎么想的。这个需求可以实现，但是太难了，改动非常大，你为什么不他妈早说。这个需求可以实现，有一定难度，代码量也很多，deadline什么的见鬼去吧。这个需求可以实现，难度不大，但是太麻烦，狗子你得看着我加班不能走，我要好好给你讲讲这特么到底麻烦到什么程度 。这个需求可以实现，没什么难度，但是你已经让我改了三次了，咦，我记得我上次明明写注释了呀。。。你麻痹的都怪你。这个需求可以实现，太简单了，老子早就知道不该这么写，所以都埋好坑等填了，就等你提了。这个需求可以实现，太简单了，老子早就知道不该这么写，也埋好坑了，但是你提的太晚了，我得花时间回想一下当初是怎么埋的。
1.策划队伍良萎不齐最近几年手游大爆发，行业对游戏策划的需求增加，而开了游戏设计这类专业的高校少之又少，高校向行业输送的人才没有相应增加。这就导致了游戏策划的招聘几乎无学历门槛，大量游戏爱好者和互联网相关行业成为了游戏策划（对于游戏策划的认识不足，以为游戏策划就是玩游戏然后提创意的差事）。2.程序队伍良萎不齐很多程序其实是本科混了四年，毕业了进了XX培训机构上了填鸭式半年班出来的，拿着这些培训机构做的两年经验的简历做起了游戏程序。这其中呢，还有至少一半人对于游戏的认识停留在FC时代，对游戏策划的认识就更不奢求了。一个整天玩游戏写文档填表的人来指导我干活？还改需求？WQNMLGBD3.题主说的那些情况，策划和程序中至少有一个人的专业技能or情商是低的。
案子发上来，一看便知
从两方面先分析一下原因。先说程序。程序分两种，一种可称为产品型程序，一种为技术型程序，有些人可能觉得自己两方面都有注意，但其实肯定还是有侧重点的。产品型程序的特点就是，对于自己所做的项目前景，项目实际情况，以及所面临的问题均有自己的看法，十分关心自己所做的这个项目，这种程序有自己对于游戏开发的抱负与理想，很大部分对于许多为了坑钱而坑钱的功能需求抱有天然抗拒，但随着自己对行业的深入了解，会慢慢接受这种现实，而且到后期会转换为另一种心态，觉得坑钱可以，但游戏一定要优秀，坚持认为游戏只要做的足够好，挖坑赚钱属于分分钟的事情，加上本身对于游戏了解比较深入，基本上已经有了自己对于游戏各个系统以及功能的较为成熟的看法，对于策划新人来说，遇到这样的程序是对自己非常大的考验，因为自己的想法或者说需求很容易被程序发现其不合理或者不完美的地方，加上你的资历尚浅，程序就会怀疑你的能力，当然并不是说只要你是新人，程序就会觉得你不行，往往都是因为策划提供的案子实在是槽点太多，一次两次大家笑笑就过，但很长的开发周期里，你提的需求每次都是这样，或者说自己对于这个系统没有一个全面的认知，有一些东西翻来覆去的改，而这些东西一开始程序提醒过你更好的解决方案，后来改了五六次最终拍板的结果和程序一开始的建议相同，那你基本上就很难过了，这个程序一定会认为你是个水货，下一次你再提不合理的需求，他就会吐槽你，甚至跟你挑明，这玩意儿定好了就不能改，你拿上级拿老板压他都没用，有能力的程序都有股傲气，你敢压他他就敢跟你拍板，大不了离职，有能力外面一大堆人排着队等着，跳槽还会涨工资，凭什么示弱？技术型程序的特点是，我不关注或者很少关注你这个项目怎么样，我只关注我能提升多少自己的技术，我的梦想不是做多牛逼的游戏，我的目标是求伯君那种大神，解决技术难题才是我的G点，按理说这种程序和策划应该不会有冲突才对啊，错，这种程序在对待有些事情上会比产品型程序粗暴的多，比如说，一开始我们定义好了技能的数据结构，游戏框架整个已经搭建好了的情况下，你跟我说我们要改技能机制，而这个改动可能会导致底层大范围重构或者产生许多垃圾代码，这个时候，脾气好的就会跟你讲这个不能改，改了的话这一两个月白干了，或者说我们这边实现起来很恶心，我不太乐意改这个，能不能再考虑考虑，换个方式，脾气差的就直接一句，滚，你当老子是傻逼么。程序一般比较爱惜自己的代码，技术型程序更甚，你一句话抹杀掉他很长一段时间的努力，是很难受的。再说策划。国内的游戏大环境其实一开始还是好的，上古时代的策划都是非常专业的，早年的单机游戏策划，你敢说人家水平不够？光粉丝都分分钟喷死你，网游火了之后，网游公司一下子雨后春笋般开遍了一线城市，策划出现了极大的缺口，这个缺口不可能一下子堵上，所以很多公司根本就没有策划，招几个新手填表，靠老板和程序美术头脑风暴，这样的游戏自然活不下去，死了之后又去别的公司，新手慢慢长大了，觉得自己牛逼了，就和别人创业，招其他新手，按原来的路子培养，这样行业内就慢慢出现了一批“资深策划”，但这批资深策划，始终没意识到一个问题，就是其实自己根本就没见过牛逼的策划是什么样子的，只是觉得为什么人家设计的东西细微处见功夫，我干了好几年了还是感觉抓不住重点，虽然数值不会，但那些游戏系统其实也都挺熟了，有名的游戏那些系统我都能倒背如流了，可为什么还是感觉缺点什么，到底缺什么呢，这就是没有见过高山，自学成才的人所面临的困扰，很多策划觉得自己不是新人了，可跟程序沟通还是被喷，是不是程序员都是奇葩，他们都是外星物种，本来就不能和我们正常交流，我去知乎问问，看看是不是，如果大家都说程序员奇葩，那我就平衡了。你要知道，策划这个职业，你不专业，就算你干了二十年，你提的需求不合理，照样还是个新人，是不是新人，跟你的工作年限有关系，但不成正比，专业策划应该是什么样子呢，在我的认知里，策划应该是通晓天文，地理，宗教，历史，文学，哲学甚至程序等等一系列的东西，我这样说你肯定不服，有这种人么，你这不是吹牛逼么，这么牛逼的人还来做游戏策划？你是在逗我么？不，我是认真的，顶级策划一定是这个样子的，就算不能通晓，熟知是应该的，就算你觉得这是顶级主策的配置，小兵们不需要这样，那你应该也明白，小兵们起码要熟悉其中的一部分，你若不信，去鹅厂，网易，里面必然能找到让你觉得自己白干策划了的人，若你还是不信，如果你觉得我侮辱了你作为策划的尊严，仙剑玩过吧，轩辕剑玩过吧，你觉得面对这些策划前辈，光从文学素养，历史架构上，你差了多少？我知道你想说什么，你想说的是，那些有用么，现在的氪金游戏只看战斗，谁管你这些没用的，那好，来，你告诉我从0做一款动作游戏，技能这快需要程序提供给你什么功能，浮空，击飞这些要怎么做？什么？你擅长的是卡牌手游？那好，你告诉我刀塔传奇为什么没有像其他卡牌游戏一样做好友助战，而是做成了公会助战？而且不能用重复英雄？抽卡概率要怎么控制？其实大家最怕的不是说策划什么都不懂，我上面所说的这些，毕竟只是凤毛麟角，不可能人人都这样，算是一种追求，策划最重要的品质，在于认真与虚心，认真对待自己的工作，如果自己有缺点，虚心接受并改进，如果一个策划拿着自己辛辛苦苦搜寻了很久的资料弄出了各种方案对比，没有人会嫌你小白，就算你查了很多资料给出的方案还是很扯，但至少你努力过了，不至于让程序一看到策划案就觉得那是你拉屎的时候随随便便想出来的，游戏开发本来就是协作，心态放平去做，肯定不会有问题。当然，这不是策划的错，主要还是老板和制作人的态度问题，策划这个职业变成现在这样，完全是因为一大批的公司高层对于策划这个职业的无知造成的，以前有很多同事，虽然也是新手，但他们确实很努力的去做，提需求会准备一大堆的资料来说清楚为什么这么做，可往往是准备了很久的东西，因为整个公司都认为策划就是填表的，导致很多需求被主程和主美莫名其妙的干掉，被制作人干掉，或者老板干掉所有人的想法，按自己的来，这种事让很多同事伤心不已，纷纷离职，好几年过去了，有些被接二连三的坑，有些最终熬出头了，去了西山居等大厂，其实有时候也替策划着急，但这几年过来，发现很多事情人力有限，真的是看机遇。其实如下面评论里的一位小伙伴所说，同等级的人相互合作是很愉快的，往往有一方实力不行，才会出现题主遇到的这种问题，牛逼的策划遇到实力不行的程序，你猜他会不会吐槽？他可能喷完你连具体实现都告诉你了。那么现在，针对题主的问题，我们讨论一下怎么有效避免这种问题。如果和产品型程序冲突了，那么一般都是你自身问题，注意，我说一般，这个时候，你要反省自己，虚心请教，自己的需求有什么问题，和他慢慢沟通调整，他肯定很乐意，要么你在提需求的时候拿着五个同类型游戏的系统分析，去跟他说，其他游戏是怎么做的，你是怎么想的，为什么要这么做，正常人都会虚心接受，尤其是这种程序，如果发现自己理解有问题，一定会及时纠正。如果和技术型程序冲突了，那么这个就不一定是你的问题了，当然，只是不一定，有经验的策划在提需求的时候心里是明白会有多大的程序工作量的，如果你和制作人已经沟通过这种大的调整，而且只是这个程序的洁癖或者惰性在作怪，沟通解决，再说了，作为同事，平常多聊聊，关系搞好了，这都不是事。当然，我不能否认说程序每个人都是对的，只能说，问题的原因很多，但都不是死结，力所能及范围内，愿行业越来越健康，多做一些有料的游戏吧。---------------------------------------------------- 原***的分割线 ----------------------------------------------------题主问解决方法，就不谈对与错了，分享一下自己的经历与感悟，希望对题主有帮助。我刚进游戏公司的时候，策划提什么东西我都以最快的速度做完，过了一段时间，对整个开发流程比较熟悉之后，加上自己本身也是一个还算狂热的游戏玩家，开始意识到一个问题，就是策划水平有限，容易犯一些低级错误。小团队认识不到策划的重要性，觉得策划就是填表的，他们戏称为填表策划，所以招人的时候捡便宜的招，能招新人就招新人，再加上人员流动，导致整个团队里新人的比例极高，制作人不可能面面俱到，所以分发下来的任务就会以很喜感的策划案到了程序这里，有些程序不玩游戏，觉得工作一天就是挣一天的工资，他们当然不会管你这个功能怎么样，但总有些程序，他本身就是游戏的狂热分子，而且他本身涉猎广泛，或者他所喜欢的游戏刚好就是自己项目的类型，当你的策划案没有深度或者说很多坑你没有想明白而程序已经帮你想明白之后，这个时候程序就或多或少会有些抵触了，因为程序的逻辑思维较强，很多时候他们已经意识到这个系统的设计有种种不合理，后续会引发什么样的问题，程序就会去跟策划商量，想办法避免这些问题，当然这都属于合理交流，我没见过哪个程序从一开始就发脾气或者拒绝的，但一般策划的反馈都是：”唉，不管了，先这样吧，以后再说“。你试想你生了个儿子，老婆过来说咱们儿子就叫王小短吧，你跟她商量说，这样不好吧，儿子以后会被人歧视的，然后她说，不管了，先这样吧，等有人歧视他再说吧。你什么心情？我上一家公司的游戏，都开充值内测了，里面一键强化花费的钻石是金币数除以一百这么算的，点金是十个钻石买两万多金币，有玩家抱怨说自己钻石丢了，我拉着服务器的伙伴查数据，查出来发现是点了一键强化一下两千多钻被扣光了，我跟策划说，这个收费太不合理了，还是赶紧改一下吧，你猜策划怎么说？“先不管，以后再说”。来这边工作之后，做动作游戏，我发觉游戏里没有帧冻结功能，心想要不要跟策划提提建议，结果第二天还没来得及开口就收到需求，帧冻结，冻结抖动，受击位移，动作位移，硬直，等等等等一系列的功能，卧槽看着那张表我当时就觉得真TM爽，终于遇到靠谱的策划了，不说设计能力了，至少基础知识是有的啊，硬实力在这摆着，还有什么可BB的？说了这么多，题主你明白了么？程序吐槽策划功能，抵触你的设计，抛开极个别奇葩程序，大部分都是因为你的设计或者策划案在他看来是不合理甚至于幼稚可笑的，策划要让程序闭嘴，就是用你的专业技能把他秒成渣，让他明白他知道的那些东西还很肤浅。
虽然不是做的游戏，但是也碰到了这个问题，所以目前我一个人全干了。。。。
作为程序，我一般用如下方法调整心情：1. 接到有问题的需求时先提出自己的想法和意见。2. 如果策划不为所动，那就按他的做。但别忘了说一句：“这个功能以后肯定要改”。3. 过了一段时间，果然要改！此时可以得意洋洋地说：“我早就说这样不行的，你们不听”……4. 当然我还是得改，不过心情会好点……5. 当然新的需求可能还是有槽点，跳转至2……
看了楼主的问题，主要是因为沟通不好（如1、2），还有修改太多（3、4）这2个问题相互有关联，我来给楼主出出主意，从工作方法上优化。1.需求要有文档口头需求不做，口头需求是成本太低，策划都没好好思考过。另外一个是扯皮，会出现策划说“我跟的讲的是这样”，程序说“明明你说的是那样的”，相互说不清的情况。同样的，后期的逻辑、公式、规则也要有文档，不然会出现反复询问确认的情况。所以需求要有文档，文档能让策划好好思考、方便传阅，白字黑字不会扯皮。2.项目开始开个会开会前先把文档发给大家，让大家有时间看。这个会主要是策划介绍下案子，以及大家发表一些很直觉的意见，因为还在很前期的时候，并不能针对性的提出具体意见。这种会议，时间一般很短。这个会还代表这个案子正式开始了，也让大家知道有哪些同事参与了。3.要有高保真原型看到其他朋友说高保真原型没有就做，的确也是问题，所以美术这块也说一下。有了案子要让UI出高保真原型。高保真原型就是按钮、道具框、tab、字号、排版按照完稿的标准来。具体文案可以后期再渲染，但字段的条数、字数的限制尽量真实。高保真原型能把策划的需求形象化、更方便沟通。原型的产出过程也是检验策划的过程，很多逻辑问题在原型时候就会被发现和修正。另外要注意原型要用黑白线框，不要用图片。前者快速，后者慢，原型的特点就是快速的产生、修正设计，慢了就没意义。前者让大家关注信息与交互，后者会在讨论的时候关注样式，还没到讨论样式的阶段，就不要做出来干扰大家。4.有了原型后，开会。有了策划案和高保真原型，就能提实际问题了。上次的会议是传达，这次的会议是讨论。会上有啥问题就提，要大胆发言，切忌会上闷不吭声，会后各种不满。这一步思考要深入，要把交互、逻辑等等各方面都想好，把问题在这一步就解决，避免出现开工了再修改。开会目的是对案子的设计与开发达成一致意见。切忌形式主义，没有成果，这是浪费时间。开会还有个作用是一种正式的沟通，想必程序有意见也会和策划提，但私下说估计最后就会出现上面的“先这样，以后再说”，如果是会上说“以后再说”，那是大家都知晓了问题，大家都同意先暂缓，策划有责任感（因为会上有老大）。如果没有沟通，没有达成一致意见，会出现边做边吐槽，发现问题返工，再发现再返工，坐等看笑话，这都是前期没沟通的缘故。5.要制定项目时间表没有时间限制，频繁修改、效率低下也就无所谓了，不是吗？上面几点都是在促进沟通，达成一致，达成一致为了减少修改，开会是大家一起xiu6.为什么策划理解程序做的功能“一定会有BUG”，而程序不理解策划提的需求“一定会修改”？出现bug会出现：bug&测试&bug&测试的循环。改需求会出现：需求&设计&程序&测试&改需求&设计&程序&测试看不来了没有，工作量不一样，所以需求改动越少越好，越早越好。策划有时候就是把改需求想的太简单，以为大家也是改一下就好了，有些改动会很影响设计与程序。另外程序也要自测一下流程，看看有没实现策划案的需求，不要功能没跑通就提交，这不叫bug，这是没做完。
那是程序对策划这个人的不认可
别的不多说了，大家说得够多了。我就来回答这个问题：为什么策划理解程序做的功能“一定会有BUG”，而程序不理解策划提的需求“一定会修改”。因为出了bug是程序员的过失，锅程序员背，程序员自己加班，自己修bug。如果严重而愚蠢的bug，直接影响素质和声誉和奖金。但是我从来没见过任何一个策划敢对自己“改需求”这件事情背锅的。更过分的是，我从没见过任何一个需求改动，是策划自己完成的。我负责的功能要不是我提前挖坑挖得好，也是要被拉着改需求改到死的。不管是谁策划，一定会拉至少另外一个人下水。不管要不要程序员动手，测试一定已经被拉下水了。这就是为什么大家那么看不起菜逼策划的原因。懂了吗？大家不想为别人的愚蠢买单。当然，这里的愚蠢并不是说改需求就是愚蠢了。谁是真正愚蠢的一些人一些事，我想策划本身都有很多东西可以吐槽。
设计师的美梦，工程师的噩梦。
一个优秀的游戏开发程序员，应该可以很好的预测策划可能会做哪些修改。其实很简单，大部分策划都是参考市面上流行的几类游戏来写策划案的，那么程序只要玩过这些常见的游戏，并把其系统设计都考虑清楚就好了。整体系统框架设计完之后，把所有数值、各个游戏之间有差异的地方都提取出来，扔到配置表或者脚本里去，然后策划再要改需求，就让他们自己去折腾吧。我们的口号是：谁拉的屎谁擦。程序会自己改好自己的BUG，策划也应该自己去改需求。
时间时间还是时间！
一些策划老爱出个大概的文档，然后就让程序做做做。
栗如: 一个模块计划4天，程序按加班加点在第四天下班前做出来了。
策划一看，哎这不好看要换，那不合理要改。。。。。。一通下来要改几十处，额，然后时间还是原来的四天。
呵呵........这些地方已经写过一次了为什么还得写一次真是毫无意义！???
项目经理：xxx这模块怎么还没做完？???
同事：下班咯！一起？???为什么策划不仔细程序要加班！！！！！
还要欢天喜地的加？换你你愿意不嘛？
因为策划水平太差了，程序员根本看不起，重新招聘有水平的策划会是解决办法。
区别是：开发出bug时会有负罪感，题主改需求时觉得理所应当。另外，明明是两个人的问题，请不要直接扩大至两个职业。
从程序员转职的策划几乎没有，大概就是这样容易出现瞎指挥，瞎出主意
正反两方面，都来讲讲这个问题。首先说结论中国 游戏程序员是个非常特殊的工种，如果你不能控制需求的结构，你最后程序也是一片火海。正面的结论如下：你应该考虑这个需求本身的合理性，做出来会不会给系统带来一些趣味的增加，如果可以，那么即便不是特别合理，也可以试试做一做，做不容易做出来更有挑战的东西，在某些情况下是对你本身有意义的。有时候盲目的拒绝需求，对整个团队的推进并无好处，你看上去的拒绝可能对组内其他人有潜移默化的影响，有些合理的需求也推进缓慢。反面的结论如下：不合理的需求，不仅仅会影响进度，也会影响到你程序的内部，最终不仅仅是代码腐烂，所有前期看来是生产力的东西都是拖后腿无尽的bug。比如说(以下是黑)，我们策划需要控制所有东西，动画的每一帧的回调，ai的每一帧，ai的逻辑怎么跑，包括ai的参数注入各种在运行期loadstring，在一开始看起来就是，我想配置一下试试更多的可能性，到后期就是，卧槽这个表我不会配置了怎么办，配置一个表程序要修一天bug怎么办。各种各样。不合理的需求，会影响团队士气。一个系统迭代个3遍，那是大家觉得正常，迭代10遍，只能说是无能了。后期就会美术，程序，策划，全部士气失守，项目最后面临所有人骑虎难下的结果。应该怎么办？首先足够的规划，你能不能开一个项目的时候，先出个白皮书啊，把核心体验论证好啊。不要直接日狗好不好，先看看公母什么的对吧。要有真正的责任感和担当，别一个项目我把程序美术干跑两拨了，下一个项目我又主策去了。立项的时候就说好，干不成我就引咎辞职当众吞粪二选一就好啦对吧。(我要是主策我是敢这么说的)。作为程序嘛，写好你的代码，提高你的素养，不要一直业务，不能一辈子业务狗。要对代码负责，不能因为别人怎样，就降低自己的要求。
多理解理解吧，这个问题很多公司都存在，尤其是迭代速度快的公司。很多这种开发和pm、设计师之间的问题都可以归结到权责划分不清的问题。修改需求、新设计方案敲定本身没问题，确定方案的权力是谁的，他对哪个团队、部门负责？方案执行、出现问题时谁承担责任、擦屁股？在国内这样的分工流程，策划的权责显然有些不对等，当然这跟国内游戏重运营和用户黏性有关系。而国外有的公司甚至没有designer和策划，只有工程师（有类似设计师的体验工程师）。这是因为自己的想法要被认可接受需要先自己实现和验证。题主的问题不是一天两天可以解决的。增进跟开发的感情是一方面，你还需要在开发那里建立”可依赖“度。用数据、市场表现、用户反馈这些显而易见的证据来证明你不是一个吃干饭的。老板下派垃圾任务，你据理力据了没？表现给开发啊，让他觉得你是靠谱的。
做过一段时间介于程序和策划之间负责沟通的角色其实程序对设计不了解是很正常的，以及策划会出现BUG和不合理的地方也是很经常发生的；会出现对立其实来自于，“你动动嘴皮写个文档的工作，我们要做好几天或者好几周，然后还要反复测试，好不容易做完了然后你又要改”，和“我每次有什么改动都要求爷爷告奶奶的那帮程序大爷都不肯做最后做出来还跟我想的不同”题主说的，最后忍让一下就过去了，实际上大家都觉得委屈，最后发展到会出现威胁，不耐烦，需要上级施压才做的情况也不足为奇了；这问题说白了其实是沟通问题；要解决也不太难；程序要能尽早出现在策划的过程中来1. 策划首先要能明确这次需求的目的，游戏性改进也好，玩法bug修正也好，运营压力也好，都应该明确下来，通知到程序；让程序理解需求变动的初衷；2.策划整理出这次需求主要涉及变动点，最理想的改动结果，可接受的最低改动结果，因为策划通常不能理解程序的实现逻辑，所以不会清楚提出的改动对代码上到底会有多少修改，所以最好能给程序一个区间；出文档或者开会，交给程序；3.策划和程序讨论修改方案中的玩法逻辑以及实现逻辑4.策划和程序讨论修改方案中的玩法逻辑以及实现逻辑5.策划和程序讨论修改方案中的玩法逻辑以及实现逻辑,很重要所以说3次，因为策划和程序看问题的角度是不一样的，很多策划案中的逻辑bug会在这个过程中被找出来，很多看似简单的实际很麻烦的修改，以及策划觉得会很麻烦，程序觉得稍微改改就能实现的修改，都会被发现；6. 程序反馈修改方案，工作量，再次沟通开发时间，上线时间需求；7. 安排开发，策划在开发过程中保持跟进，在测试过程中保持跟进；
在我们项目的实践中，程序会可能把所以可操作的接口都脚本导出，然后我们花一个月的时间教策划来写脚本。然后最后所以需求的改变策划都可以自己改脚本来倒腾了，基本没有程序什么事情了。程序只负责维护最底层原子逻辑的正确性，和添加新接口。总的来说。策划可以改需求，改了后自己改脚本，Do it yourself.
不请自来。 改功能不会反感，但是请发正式邮件，并抄送给相关需要知道这件事的人，包括各种负责人。因为这表明，你的改需求计划不是一时冲动，你愿意为你负责的东西承担相应责任。开发人员会安排好时间的。 开发人员反感的是，有大体方案，但是方案没细节，然后一会儿跑过来说一下细节，一会儿再来说一下。所以，发邮件，写好策划案，尽量避免临时需求，其他非策划人员哪怕是boss提出来的需求，你们策划也要内部讨论啊，老板要伺候，方案质量也要保证啊。说难听点，方案差我们一样能按你的方案做出来，到时候第一个被喷的绝对不是开发人员你信不信。“一般情况下项目内成员都不会被因为项目本身的功能BUG处罚，所以追究谁的责任没有作用。”呵呵，真正成熟的运营中的项目，一旦出现运营事故，必须要有人当背锅侠。
已有帐号？
无法登录？
社交帐号登录