忘记是哪位游戏同业曾经说过，开发游戏很少有不Delay的，唯一的差别就是Delay时间的长短而已。事实上，在银狐个人这三十年的游戏研发经验中，实际参与的游戏研发项目，几乎是每个项目都有发生过Delay的现象。轻微一点的Delay个数周;严重一点的Delay好几个月。而对于游戏公司的老板或是项目负责人来说，没有人希望发生这样的现象的。.

「游戏研发会出现延期的状况，很多时候其实是预估时程就出了问题。」

项目时程会出现延误的原因很多，从单纯的开发人员的异动、离职到各种天灾人祸，象是硬盘挂掉造成程序码损毁或是打雷打坏计算机等等离奇的理由都有。不过让我们先把这些千奇百怪的原因放到一边，专心来看看因为人员评估时程所造成的状况。因为大多数的游戏研发，在进行时研发人员都会针对要开发的项目进行所需时间的评估。而这个时间评估上的正确率，通常也会影响到游戏研发时程的正确性。

游戏研发时程估算的错误，就银狐个人的游戏研发经验中遇到过多种不同的状况。以下，就让银狐列出几个最常造成游戏研发时程估算失准的状况：

过份乐观没有考虑意外状况的预估

有句俗话说『天有不测风云，人有旦夕祸福』，指的是有些灾祸的发生是无法预测的。同样的，在工作时程的预估上，我们也必须要考虑到这些意外事件的发生。如果在预估时间的时候没有考虑到这些，只以最乐观的状况来判断，那么在执行的过程中只要出现一点意外，就会造成时程的延误。

举个简单的例子来说好了。银狐之前有很长的一段时间负责一款在线游戏的营运工作，当一款在线游戏营运的时间久了，就会面临到服务器使用较长时间，有硬件需要进行更换的工程。这一类的工程各间游戏公司都经常面对，因此都有相关的SOP可以参考。不过每一款游戏的硬件配置不同，SOP上通常只会列出需要进行这项工程的流程，每项工作需要花费的时间会由各款游戏自己计算。

有一次，项目又遇到了有硬盘需要进行更换的状况，工程人员依据以往的经验，估算了整个更换硬盘所需要的工程时间，然后将这个时间向玩家公告为维护时间。工程人员所估计的时间，是整个流程完全没有出现任何意外所需要的时间。

结果，实际在进行硬盘更换工程的时候，先是在事前的资料档备份压缩的时候下错了指令导致需要重新进行一次，接下来在更换硬盘的时候发现其中有一条排线太过老旧需要更换，结果花了更多的时间。由于原本预估的时间并没有考虑到这些状况，因此最后停机的时间不足，需要公告延长停机时间，而这自然也引发玩家的抱怨。

预估的时间没有包含除错测试以及调整的所需时间

游戏研发的过程中，每一个项目通常都会需要经过一段除错、测试以及调整的过程。而且这个除错、测试以及调整的过程，有时候花的时间会比原本制作这个项目的时间还要长。当任何的游戏内容从纸上的设计变成实物，操作后通常都会有需要调整的地方，如果在预估时间的时候没有把这个部份考虑进去，那么估算出来的时程一定会有很大的误差。

举个例子好了。在前面银狐提到的那个项目中，有一次营运单位提出了某项需求，银狐经过和程序讨论之后认为这个项目需要占掉一位程序将近一周的工时，因此告知营运单位就目前的人力状况来说拨不出人力做这个项目。

当然营运单位没有办法接受这样的说法，于是私下去找了位熟识的程序询问，那位程序很豪爽的说「这样简单的功能他只需要一个下午的时间就可以完成。」当然，有着这位程序的背书，营运单位就理直气壮的来和银狐理论，说银狐故意找理由不愿意支援他们。在这样的状况下，银狐只好放手让这位程序去做这个项目。

结果，这位程序花了大约一天的时间才把这项功能做出来(和他原本所说的一个下午已经有了点差距)，然后写出来的功能有Bug又修了两天，然后因为实际运作起来的状况和营运预期的又有些不同，因此又花了两三天的时间去调整。最后整整花了七个工作天的时间，才把这个项目做到营运需求的样子。这个半天变成七天的工时预估，就是这位程序忽视了除错、测试以及调整所需要花费的时间。

会不断的有杂事打断你正在进行的工作

记得曾经有国外的文章提到过，许多的程序设计师喜欢在夜晚工作，因为这个时段他们的产能最高。其实，仔细去分析这个状况就会发现，并不是程序设计师的生理时钟有什么问题，造成他们会在夜晚的时间工作效率比较而。而是平常上班的时间，他们的工作可能会不断的被各种事情打断，只有在夜晚没有人干扰的时候才能够专心工作，因此产能比较高。

其实同样的状况在研发游戏的时候也一样会发生。当一款游戏在研发的时候，任何一位项目的成员身上通常都不会只有一件工作，而这些工作可能分别和不同的同仁有关，因此当你在进行一项工作的时候，很有可能会被另外一项工作出现的状况所打断。如果是营运中的游戏，研发成员同时负责维护旧有的内容以及开发新的内容，那么这个状况就更为严重。

游戏研发有很大一部份是脑力的劳动，而思考到一半的事情若是被打断，在打断之后要重新回到原本的状态，通常会需要一点时间。这就好像是汽车加速到100公里后踩了急煞车，之后要重新加速回到100公里通常也需要花一点时间是一样的。而这个重新加速的时间，就会成为时程预估中无法估计到的时间。每多一次打断，这个时间就会不断的增加。

每日工时估算的错误

当一个开发项目出现后，研发人员就会依据这个项目的难易度来预估开发需要的时间。依据工作项目的大小，可能会以天数或是小时数来估算这个项目完成所需要的时间。一般来说，大多数的游戏公司每日的上班时间是八小时(虽然实际的工作时间远超过八小时)，因此有些开发人员会先以小时数估算所需的时间，然后除以八求出所需要的天数。不过，虽然公司规定的每日工时是八小时，实际上每个人一天『真正』在工作的时间是否真的有八个小时呢?

早上到公司吃个早餐、看看新闻，上班的时候上一下脸书、PTT，中午午餐时间以前和同事讨论一下午餐要吃什么，中午午休时间多睡个十几分钟。如果再加上抽个烟、上厕所时顺便到其他同事那里串个门子、或是去茶水间倒水的时候和同事聊聊天，一天真正剩下来可以工作的时间还剩下多少?就银狐自己的习惯，每日的工时如果能有六个小时，那么这位同仁已经算是相当努力工作的，有些夸张一点的人一天真正的工时可能连四小时都不到呢。

在实际每日工时相差如此庞大的状况下，原本估算出来的时程根本无法完成。虽然说大多数的游戏公司加班的状况常见。不过，也有许多的人就算是留在公司加班但是心根本不在工作上。当你的周围有许多下班后留在公司玩游戏的同事时，就算是再怎么有定力的人，恐怕都很难真正的把心思放在工作上吧。在估算工时的这件事情上，银狐个人习惯用每日工时四至六的这个区段来计算实际所需天数。

以上所说的几种状况，都是研发游戏的项目人员在估算时间的时候容易踏入的误区。在发生这些状况的时候，对于预估的时间都会出现程度不一的误差。当然，这些时间上的误差都比不上某些老板/上司喜欢用的『菜市场杀价式』的喊价状况，那种随随便便就把项目时间砍掉1/2或是1/3的状况，其最终的结果都会悲剧收场。

而某些老板/上司习惯用压缩后的时程来逼迫员工加班赶工，他们的想法可能是『反正一年的项目会做一年半才完成，那我不如一开始就把项目时间喊成六个月，这样就算做了一年才完成也比做到一年半要好』这样的想法。这种作法也许一次两次会有效，但是人不是机械，是会弹性疲乏的，当项目的成员陷入这样的状态后，是很难再将大家的士气拉起来的，到了那个时候可就神仙也难救了。

如果你要问银狐有没有避免游戏研发Delay的方法?银狐会告诉你「我没有」。我所能做的，就是在项目预估开发时间的时候，避免项目的成员踏入以上的误区。但是，就算是避开了这些误区，还是有许多会造成项目研发Delay的因素，剩下的就只能『兵来将挡，水来土掩』的见招拆招了。