项目中的非技术因素探讨（一）
有时候确实是能够感觉到，一个项目的成败往往在项目早期就可以预测得到。如果说每个具体的技术点、工具的选择、策划的想法、美术的风格这些都是战术的话，那么项目的战略就是这个项目的上层架构了，包括项目成立之初的意图、版本进度的控制、各个功能单元的安排和配合。
近年来的大部分项目并不是亡于技术细节这些战术上，而是亡于系统的内耗上，也就是亡在战略上。这就好比一部机器，木头做的螺丝、木头做的轮轴，只要配合合理，就能够搭出水车、风车、投石车，它们中的有些直到今天还合用。但是如果各个部件配合不合理，螺丝拿去配了齿轮，那哪怕用黄金也做不出来好的机械。系统工程的关键有两点，一个是系统的组分，一个是系统各个组分之间的配合。时至今日，但凡走了一段时间的公司，系统的组分水准都不会太糟糕，至少是合用的，问题往往产生在组分的配合上。在下见过不少项目组，程序和策划只能说做到了配合，却远远没有做到有效的配合，双方互相经常性否决对方的提案，甚至干涉对方的工作……
最近见到一个项目，全面接口化、全面组件化、设计思想不可谓不先进，项目组主要角色也都是4、5年经验的开发者，但是似乎仍然到最后陷入了“焦油坑”中：组件开发过细，明明适合放到一起的却都分到子组件中去了，导致组件间的交互瞬间增长、变得异常复杂、从而丧失了组件最大的优势。项目组一直重构，却怎么重构都冲不出这个焦油坑。导致一个明明研发了很久的项目，看起来完成度却并不高——并不是表面的完成度，而是系统的完成度，远远没有到达工具化和调细节的层次，内容的提供和储备严重不足。策划干着急没办法，程序则苦于系统修修补补，要解决的问题太多……
私以为，这个团队最大的问题，是在于程序人力太多，整个项目基础玩法刚刚定性，就已经长期维持了数十人的规模。如果一个团队刚上来就来上十几二十个程序，那每个人水平再高、再怎么努力就都没有意义了。
表面上看起来，人员数量多的团队，解决问题，哪怕是解决重构索要花的时间总要优于人数少的团队，可是这种思路有一个先入为主的出发点错误，就是假设软件开发过程是建立在重构之上的。否则，大家都懂的，系统的前期结构设计越完善，才能真正减少后期堆功能时所耽误的时间。项目级别的重构，生命期内两三次已经足够大动荡了，再多那只能说明这个项目的初始设计太糟糕。套用《最后期限》里的话，“通过评审了！他们欢呼着把之前的设计束之高阁。然后开始编码了，然后从这个时候才开始真正的设计！这个时候，才开始真正的设计！”
软件开发拼人力一直是最大的忌讳，与软件规模和当前开发阶段相应的人力数量往往并不是无限增长的，如果人力数量超出了当前开发阶段所需要的人力数量，那么问题往往并不是浪费人力这么简单。
从管理者而言，能做到“韩信将兵多多益善”的管理者举世都可以说罕见，五人团队和二十人团队和一百人团队，消耗在管理上的成本绝不是一个数量级的区别，而软件开发还偏偏不是一个蓝领工作，并不是简简单单拧拧螺丝就完了的，如果无法调动起人的积极性，那么这个人很可能自己拧不好螺丝，还会搞得别人一起弄不好螺丝。
从技术层面而言，前期人员太多，又要保证这些人有事情做，很多系统核心设计必然是只有个大概的方向，甚至都不能囊括整个游戏开发期所有可能出现的需求和预测（一般都只考虑给老板看的第一个Demo），就开始堆人力了。做过系统设计的应该都清楚这意味着什么——这样的设计根本就不能称之为设计。
而且，堆人力的时候，因为人多，又开始出新的状况了：一开始，A负责数值这方面的工作，由于此时没有完善的顶层系统设计，所以所谓的数值就是一个独立组件，全面与战斗绑定。而第二个版本后，A去做更重要的事情了，B奉命过来在A的数值体系里增加升级相关的功能，由于发现A的数值是战斗数值这个现实，于是B自己又写了一套专门处理升级的组件。而此时，C在写技能相关的功能，发现A和B的数值都有没考虑到自己的部分，于是做出了一个艰难的决定——在技能系统内部再加一部分技能相关的数值。
于是到最后，明明一个很简单的概念，发现有三个系统的三套不同的人马在维护……而游戏数值这种东西，追根究底地问一句，该是程序Cpp到工程里的东西吗？
没有最顶层的设计，每个具体的点设计得再好也没有意义，因为你很可能不需要在这个点上去设计。
前段时间看到一篇讲敏捷开发的帖子，其中一个最重要的观点就是，敏捷开发是在优秀设计基础上进行的，并不是说敏捷开发了，就不要设计了，否则再怎样也无法真正敏捷起来。哪怕有最好用的重构工具，重构本身仍然是需要花大量时间和精力的。而且，每重构一次更大的意义上是对团队信心的考验，如果总是重构不到位，老板会开始怀疑这种做法，而底层员工则也会否认这种出力不讨好的工作。重构很可能并不是用来解决这种问题的最好方案，特别是对于项目开发周期本身就被更上层的领导和市场压力不断压缩的中国游戏项目而言，一次重构动辄半个月一个月的工作量让人望而却步，而同时，重构无论如何对于团队而言，都是对现有流程和方法的破弃，对士气造成的影响，人少、有核心还好说，人多，本身就谁都不服谁的情况下，很难说会造成什么好的效果。
核心设计为什么叫做核心设计，恰恰就是要少数菁英突破性地完成整个游戏的上层设计，而前期来那么多人，根本对此事没有任何助力，相反的，为了给这些人找事情做，大概齐这块儿有个什么什么东西，你去做吧，大概齐那块儿有个什么什么东西，他去做吧，设计云云根本就无从谈起。
可是为什么这样有百害而无一利的战术会得到认同并且执行呢？为什么很多游戏项目拼命前期抢人，而且抢过人来就发现有东西能做呢？因为，看似，游戏的工作就有那么多。
一方面分配给程序的工作量，很多时候我们在用专业程序员的CPP在做一些老外的Game Designer用LUA、Python和工具来做的东西，而且，本土Game Designer更喜欢扮演指挥者的角色，但指挥的效果……是否能有人告诉在下，如果一个指战员从未到过一线，他的指挥到底靠不靠谱呢？客观上来说，项目的开发中经常出现程序修正策划需求的情况，这应该足以表述这种方式的结果到底是如何的了。而如果一个策划跟程序的交流过于紧密，又容易产生策划被程序绑架的情况……也难怪似乎中国的项目组里很难出现欧美那种程序和策划相互融洽的将相和结局，策划和程序简直就是互为天敌的存在……任何一方的强势带来的结果往往是不受控的。在下不幸见过这个也做不了，那个也做不了的程序，同样不幸见过这个没考虑到，那个没考虑到的策划。没有指责谁的意思，其实没有任何一方是胜利者。
另一方面就是进度压力，一个核心玩法还没有决定下来的项目，就要求所有的表面功夫都要做到位：要聊天、要组队、要团队、要工会、要帮派、要结婚……这么一堆做完以后，发现核心系统慢慢健全了，于是这块儿开始改，那块儿又开始改……
在下窃以为，这样的研发观念已经足够多地证明了自己的落后了。欧美的游戏研发能够在这几年发力并且迅速超越日本，在于它有一个低内耗的产业环境。对比欧美的引擎思路和日本的引擎思路就发现这种区别了，很长一段时间里，日本的游戏每一次新做，整个底层到上层就会几乎全部废弃重来，而欧美的引擎呢？看看Unreal和Unity能做到的程度吧，即便是稍差一点的CryEngine，却也能通过脚本，在没有引擎代码的情况下完成自己的Mod。很多人都认为，这是欧美游戏能在最近几年大举发力逆转日式游戏的关键之处：这种模式培养起了大批经历过一线风雨的菁英力量。
而一些中国团队的研发观念又是什么呢？只能说具有中国特色，项目前期，只知道我们大概齐要做成（shan zhai）个什么样的东西，中期和后期则开始一会儿山口山，一会儿斗战神……总体战略如此，每一个战役过程自然也高明不到哪里去：
既然前期这么鲜明地明白了目标，自然就是尽快堆着人力往上冲了，设计？我们的需求都明确了，还要什么设计啊。
然后，为了应付版本，“时间紧，任务急，是不是把这块儿绕开？”“我看行”。版本结束后，这事儿就束之高阁了，几个月后有人做到这里，突然才想到哦当时这块儿有个坑。
再然后，发现这个版本老板不满意，老板说那啥啥是个好游戏，我们把那啥啥加进来吧，然后又开始紧张编码……
再然后……
对玩家负责的心态呢？就算不为玩家负责，身为一个程序员，对自己负责的心态呢？身为一个程序员，软件工程强调设计的原则呢？
……归根结底，技术的强大解决不了意识的落后，莫说定远镇远，就算是来条俾斯麦也没用，因为——
几乎没有什么战略错误能用战术去修正