程序的背书，营运单位就理直气壮的来和银狐理论，说银狐故意找理由不愿意支援他们。在这样的状况下，银狐只好放手让这位程序去做这个项目。
结果，这位程序花了大约一天的时间才把这项功能做出来(和他原本所说的一个下午已经有了点差距)，然后写出来的功能有Bug又修了两天，然后因为实际运作起来的状况和营运预期的又有些不同，因此又花了两三天的时间去调整。最后整整花了七个工作天的时间，才把这个项目做到营运需求的样子。这个半天变成七天的工时预估，就是这位程序忽视了除错、测试以及调整所需要花费的时间。
会不断的有杂事打断你正在进行的工作
记得曾经有国外的文章提到过，许多的程序设计师喜欢在夜晚工作，因为这个时段他们的产能最高。其实，仔细去分析这个状况就会发现，并不是程序设计师的生理时钟有什么问题，造成他们会在夜晚的时间工作效率比较而。而是平常上班的时间，他们的工作可能会不断的被各种事情打断，只有在夜晚没有人干扰的时候才能够专心工作，因此产能比较高。
其实同样的状况在研发游戏的时候也一样会发生。当一款游戏在研发的时候，任何一位项目的成员身上通常都不会只有一件工作，而这些工作可能分别和不同的同仁有关，因此当你在进行一项工作的时候，很有可能会被另外一项工作出现的状况所打断。如果是营运中的游戏，研发成员同时负责维护旧有的内容以及开发新的内容，那么这个状况就更为严重。
游戏研发有很大一部份是脑力的劳动，而思考到一半的事情若是被打断，在打断之后要重新回到原本的状态，通常会需要一点时间。这就好像是汽车加速到100公里后踩了急煞车，之后要重新加速回到100公里通常也需要花一点时间是一样的。而这个重新加速的时间，就会成为时程预估中无法估计到的时间。每多一次打断，这个时间就会不断的增加。
3、每日工时估算的错误
当一个开发项目出现后，研发人员就会依据这个项目的难易度来预估开发需要的时间。依据工作项目的大小，可能会以天数或是小时数来估算这个项目完成所需要的时间。一般来说，大多数的游戏公司每日的上班时间是八小时(虽然实际的工作时间远超过八小时)，因此有些开发人员会先以小时数估算所需的时间，然后除以八求出所需要的天数。不过，虽然公司规定的每日工时是八小时，实际上每个人一天『真正』在工作的时间是否真的有八个小时呢?
早上到公司吃个早餐、看看新闻，上班的时候上一下脸书、PTT，中午午餐时间以前和同事讨论一下午餐要吃什么，中午午休时间多睡个十几分钟。如果再加上抽个烟、上厕所时顺便到其他同事那里串个门子、或是去茶水间倒水的时候和同事聊聊天，一天真正剩下来可以工作的时间还剩下多少?就银狐自己的习惯，每日的工时如果能有六个小时，那么这位同仁已经算是相当努力工作的，有些夸张一点的人一天真正的工时可能连四小时都不到呢。
在实际每日工时相差如此庞大的状况下，原本估算出来的时程根本无法完成。虽然说大多数的游戏公司加班的状况常见。不过，也有许多的人就算是留在公司加班但是心根本不在工作上。当你的周围有许多下班后留在公司玩游戏的同事时，就算是再怎么有定力的人，恐怕都很难真正的把心思放在工作上吧。在估算工时的这件事情上，银狐个人习惯用每日工时四至六的这个区段来计算实际所需天数。
如果你要问银狐有没有避免游戏研发Delay的方法?银狐会告诉你「我没有」。我所能做的，就是在项目预估开发时间的时候，避免项目的成员踏入以上的误区。但是，就算是避开了这些误区，还是有许多会造成项目研发Delay的因素，剩下的就只能『兵来将挡，水来土掩』的见招拆招了。
而某些老板/上司习惯用压缩后的时程来逼迫员工加班赶工，这种作法也许一次两次会有效，但是人不是机械，是会弹性疲乏的，当项目的成员陷入这样的状态后，是很难再将大家的士气拉起来的，到了那个时候可就神仙也难救了。他们的想法可能是『反正一年的项目会做一年半才完成，那我不如一开始就把项目时间喊成六个月，这样就算做了一年才完成也比做到一年半要好』这样的想法。
以上所说的几种状况，都是研发游戏的项目人员在估算时间的时候容易踏入的误区。在发生这些状况的时候，对于预估的时间都会出现程度不一的误差。
当然，这些时间上的误差都比不上某些老板/上司喜欢用的『菜市场杀价式』的喊价状况，那种随随便便就把项目时间砍掉1/2或是1/3的状况，其最终的结果都会悲剧收场。