从一句“名人名言”想到的一点项目研发经验

martinspear

“没有任何一个项目是因为UI成功的，所以他们的UI不会乱改。”
这句“名人名言”源自业内一篇比较火的文章，而如今这句名言却成为了一些人甩锅必备套路。比如
“没有任何一个项目是因为房子漂亮成功的，所以场景的房子不会乱改。”
“没有任何一个项目是因为死亡姿势漂亮成功的，所以死亡姿势不会乱改。”
……
即便你举出恰当的例子做出反驳，他也一定会辩解说你这个例子其他地方也很成功啊又不是因为xx才成功……

今天我遇到了组内同事用上面罗列的语句来甩锅，而我因为自知反驳也没用，所以沉默下去。但是由此我却觉得类似的事情似曾相似。

“没有任何一个项目是因为XX成功的，所以他们的XX不会乱改。”这句话被他们理解为了“没有任何一个项目是因为XX成功的，所以XX不改。”甚至于“没事儿别提XX的问题。”这样的策划如何进步？

其实我并非第一次遇见类似的问题。之前做的项目曾经非常执着于UI导致影响了项目进度，这种事情，我也是经历过的，当然我也遇到过没事儿找茬的那种寻找“bug”的人。不过，矫枉过正，更是我遇到更多人、更容易犯下的错误。即便是当初一起工作的、而今已经成为某公司项目经理的一个朋友，至今偶尔也会不同程度犯点矫枉过正的毛病。

矫枉过正，这是第一个问题，而我至今也不知道该如何避免。……

然后再说第二个。

当一个团队反反复复测试了一款游戏，几乎不能再发现什么问题的时候，找个局外人来跑一跑有时候会有意外的惊喜。这是人尽皆知的道理。然而，如果这个局外人是一个新人（尤其是表面看起来是新来的、实际并不缺少研发经验的人的时候），那么一定会有人以“大家都没觉得有问题，为什么就你觉得有问题”的句式来反驳，这种反应也是人之常情，但是更应该注意到这种常情并不利于游戏完善。


如何避免此类情况发生？我认为首先还得在于自己能力提升，也就是说，作为策划必须能分辨出哪些问题是组内成员挑刺可以忽略、哪些问题确实是个问题可以改进、还有哪些问题暂时改不了先记录备忘，等等。其次就是学会平等待人、尊重他人。当你对一个人的过往不甚了解的时候，不要莫名其妙的先认为自己比对方高一等。——同理，我也希望一些新人在面对团队里挂着“资深”脸的同事时，也不必先认为自己比对方低一等。只有大家心里平等，互相尊重，才能发挥出研发团队里每一个人的力量。


回头一看，觉得自己写了一篇废话。不过，很多道理，一说出来谁都懂，做的时候就不是一回事了。所以我还是发表出来，权作给自己也做一个提醒。如果耽误了你的阅读时间，请见谅。


===========================
至于到底是什么事儿引起这篇文呢？
2个月前我被调到另一个项目组，刚进组的时候就听周围同事们偶尔提到这边的策划太烂，而我却没放在心上。闷头做分内事儿一直到现在。最近抽了点时间进游戏跑一跑，发现了UI一些问题。具体问题如示意图：



而我以“是要做成这样吗”的语气询问，得到的却是开篇那句“名言”。于是我瞬间理解了，为什么大家都觉得这边策划烂。
当然也许你觉得我画的图有些过分？那么请看实际图片的缩略图吧。爆出最大的字的效果：


一个小故事而已，博君一笑。

__BlueGuy__

如果连UI都做不好，又怎么能做好游戏呢？

__BlueGuy__

这种细节问题有点类似于程序代码规范，如果不及时解决，日积月累，最终会给项目造成致命的伤害。
界面难看还好补救, 因为表面的错误很容易被发现，如果代码难看就无药可救了。