如何在撕逼之战中战胜程序、美术及老板
游戏观察9月13日消息，作为一个什么都要做的打杂游戏策划(类似PM+UX)，平日里有大量时间都需要和程序、美术讨(撕)论(哔)。经过常年累月的实战经验与理论总结，目前的胜率差不多有80%左右。分享一些个人经验，虽然没法保证百战百胜，但是对于提高胜率，应该还是能够做一些微小的贡献。
VS 程序
与程序PK，要能用程序语言与之沟通
了解程序语言，并不是说要会写代码，只是为了能听懂程序们在说什么。
据本人不完全观察，对于一些策划新人，程序经常会以类似「这没法讨论了，根本不在同一个频道上」这样的话宣告一次PK的结束。
这种鸡同鸭讲的情况，双方的内心都是一样的崩溃。
如果把程序语言比作汉语这种一般意义上的语言。我们只需要拥有旧社会文盲的水平就足够，而程序员就好比是那些能写文章的读书人。
厉害点的程序员属于新概念作文大赛得奖的水平，Torvalds(写Linux的)、Wozniak(写Apple的)这种神级程序员就好比诺贝尔奖得住。
我们作为文盲，虽然写不了文章、看不懂文章，但是正常交流没有问题，即使对方偶尔会说些我们听不懂的成语、典故，但只要不是满口晦涩的文言文，并不会对沟通造成太大的障碍。
那么问题来了，如何学习用于沟通的程序语言?个人觉得自己捣腾下个人网站是全面了解程序语言的有效方式。我靠着高中里搞论坛的那一年多经验，吃老本吃到现在。鉴于我时至今日仍是只会改不会写的初级水平，对程序的理解肯定不够深刻，不敢妄谈如何学习，就简单说一下各种程序语言对我的一些实际帮助吧。
HTML&CSS
了解各种页面元素都有哪些属性可以设置，各元素之间的相对位置关系、对齐方式
关于这些，其实更多是属于程序和美术之间的交流鸿沟。相对坐标还是绝对坐标?相对于屏幕对齐还是相对于其他元素对齐?当美术不了解程序语言的时候，只有我们这种既不会美术又不会程序的中间岗位来翻译了。
JavaScript
了解各种操作事件的具体差异
就以最简单的「点击一下鼠标」，对程序而言，可能需要确定具体是click、down还是up事件，会不会有额外的hold事件。
SQL
了解了基本的数据结构，以及读写、查询等数据处理方式。
写系统规则时先自己建立好表结构，即使不是最优解，程序也更能理解，讨论时也不至于空谈。
一个界面里的列表用select写一遍，排序规则对程序而言就一目了然，用人话来写反而太啰嗦
当然，还有很多其他的一些基本的概念，比如遍历、析构之类等等，都在后来工作中慢慢积累的「新单词」。
对于懂程序的人来说，这些都是非常非常浅显的入门级别。不过日常工作中的讨论沟通，也大多为这些鸡毛蒜皮的小事，惊天动地的跨服架构一款游戏能有几次?
了解一些程序语言，避免与程序沟通时一脸茫然、二脸懵逼的窘境。
无限茫然
VS 美术
与美术PK，要强调目的、不要说具体方式
在我刚工作时，虽然是新人，但是连色值都想要自己定(然而并不是因为自己NB，这和土老板要求大红配大绿的脑残性质其实是一样的)，当然结果并不理想。
后来接触了很多UX/UI方面设计书籍和文章，再加上确实没有精力事无巨细的什么都管。遍逐渐开始「不管」美术效果，只看是否满足功能需求。
在收到美术的第一版效果图后，通常第一件事是检查一下我的线框图里所列的各种状态和边缘情况是否齐全。
大部分情况下美术都会漏一些状态，或者发现在某些状态下很不好看。(这里不是黑美术同学，但在设计感性的美观时，确实比较容易忽略掉纯理性的状态逻辑)。
然后再看看各个界面各个元素之间的组合关系和主次关系，是否和规则匹配。
如果你想把一个图标移到一个文字旁边，可以改成“我希望这个图标和这个文字之间的关联性更强一些”。
如果你觉得一段文字太小、想放大，可以改成“我希望这段文字再醒目、突出一些”。
说目的、而非具体方式
你在提出一个具体的改动意见或是建议时，必然是有一个更深层的实际目的需求，要找到这个实际的需求告诉美术。
只提这些理性、客观的需求，尽量少提主管的审美意见，美观的问题完全交给美术(以及美术老大)。
不过，还是有一些列外情况下，我还是会干预美观问题：
各种没对齐
标尺一量就知道对不对，完全不需要撕。
资源浪费
游戏界面的特殊性，比如增加了一个很难复用又很大的图片素材，一般都会让美术换成更经济的方式，或者做成更通用的素材。
风格不统一
因为有的项目不只有1个UI人员，难免会有差异，虽说可以由最后UI主管、主美什么去把握，但毕竟我更早接触，发现了还是会先提出。
美术主动要求建议
就像我们有时也会征询其他部门的建议、做简单的用户调研一样。这时候就尽情的发表主观的看法吧，但是会强调「仅供参考、不必采纳」。
审美这玩意儿，没有什么绝对的标准，还是让更专业的美术去掌握。如果真觉得美术做的不忍直视，那也是应该考虑更换美术人员。我们还是专注精力在逻辑规则上。
VS 老板
与老板PK，把老板当普通用户
我们的老板在程序和策划方面都很厉害，因此大部分意见和建议都是很靠谱的。
但是毕竟老板更多考虑的是战略，并非奋战在第一线，因此对于战术细节不会非常深入的了解。
因此我更倾向于把老板当做一个重要的核心用户来看待。
核心用户提的意见肯定不能忽视，但也决不能无脑接受，要去发掘意见背后的真实诉求。
特别是当老板的建议会导致增加大量的工作量时，可以一方面威逼(说清楚关联改动牵扯甚多、可能会造成进度延期)，另一方面利诱(提供一个相对简单、但也能部分解决问题的代替方案)。
由于老板的诉求已经得到了一定的反馈，加上延期这种事情是老板非常不愿意看到的。一般都会同意那个折中的方案。
当然，这都建立在老板是讲道理的前提上。
老板就是不讲道理怎么办?炒他鱿鱼!
VS 自己
PK之前，自己的分内工作一定要先做到位
如果你的文档、示意图都非常马虎，别人问起来都是“没想过、随便放的”，那无论与谁PK都是毫无胜算。
只有双方实力接近时才有PK技巧可言。
假设对手是巴西男足，并不是一定要意大利、德国这种强队才能出战。
只要能达到中国男足的水平就有资格同场竞技，说不定可以进一球、得一分。
但倘若派出的是益民食品厂代表队，那真的只有依赖膜法才能获胜了。
回顾一下我战败的那些情况。通常原因只有一个：逻辑不够严密，考虑不够周祥。
前面说我与程序的胜率有80%，其实是排除了我与我们那个变态主程的战绩，和他的胜率最多只有50%。
由于主程负责的通常都是大系统，几乎每次都会被他的一连串「极端边缘情况如何处理」的连击给打到。
面对这种失败，除了继续提高自己的姿势水平，只能微微一笑、无可奈何。
最后
一次又一次撕哔之战，目的是什么?不是为了争输赢，最重要的是为了推动项目。
切莫本末倒置，为了赢而赢。。
