建議準備做項目和正在做項目的都來看看，吸取一下教訓。
1.過多的工作壓到了同一個人身上
在很多小公司[或小項目組]里，總有那么一個核心程序員，負擔了幾乎所有的編程任務。這個人即使是個天才，也會被繁重的工作壓的沒有學習和自我提高的時間。
比如設計模式這樣的思考方式也是近幾年才在中國普及開來，卻并非那么容易學習。整天迫于項目壓力，就無法領悟新的東西，去用更好的方法解決問題。
獨自一個人總攬大局，在項目后期很容易因為想早點結束，而把整個代碼補丁打得滿目滄夷，只求能解決眼前碰到的BUG而不為長遠的結構穩定去考慮了。
結果整個工程無法分出明顯的模塊，各部分耦合度太高，牽一發而動全身，一直到新的BUG出來后無可救藥。
2.過分的彈性工作制
游戲程序員好似天生追求自由的一群人，白天辦公室里經?？床坏綆讉€人，晚上通宵達旦地在電腦前奮戰。不否認好的程序員在精神興奮的時候可以連續工作寫出質量不錯的代碼，但是停下來時幾天沒有進展也是時有發生。尤其到了項目后期，一旦BUG重重，程序員備受挫折，仿佛眼前的活永遠都干不完，而且調試程序也失去了編寫程序時的新鮮感，最終假借彈性工作制的名義，消極怠工拖垮項目的先例已經有很多了。
彈性工作制不等于沒有計劃，不等于可以隨意為之。在項目沒有進展，而程序員卻整天不干正經事，只知道聊天，瀏覽網頁的時候，程序員并非沒有心理壓力，他可能只是不知道下一步該怎么做，或是問題太多已無從入手，這說明項目已經失控了。
3.沒完沒了的變化，沒完沒了的返工
大家都想把自己的作品做的更好，往往正在做的還是自己的處女作。自己的游戲做了一半，看見新上市的游戲有了什么新玩法，新東西，都想抄到自己的東西里來。
新發現什么技術可以讓畫面效果更絢，就迫不及待地實現出來看看。又或者，新做出來的東西老是不滿意，三天兩頭地放棄重做，力求完美。最終，游戲老是做不完，看不到盡頭。如果從投資方來了時間壓力，最后一咬牙將有缺漏的版本交出去，等待著的是玩家沒完沒了的投訴電話。
4.沒有及時的測試
誰都知道軟件做完了是需要做測試的，測試出問題就應該修正，這似乎是天經地義的事情，但是落到實處，早期的國產游戲卻很少有嚴格的測試。因為很多人忽略了一點，無論是哪種軟件開發方法，測試都不是在軟件全部開發完畢后才進行的。等到大家看到項目好像已經完工，這時候對游戲做整體的測試已經完了。必定發現一大堆的BUG，已經到了無處著手的地方，如果只是頭痛醫頭腳痛醫腳那還真的不如借這次的經驗教訓，把程序推倒重來做個更好的設計呢。
5.項目的主導嚴重地偏向了某一個職位上
早期的游戲大多是程序員主導整個游戲的設計的，程序員說應該怎么做就怎么做，說今天要怎么改就怎么改，甚至沒有單獨的游戲策劃一職，全部由程序員包辦。
這對小型游戲倒沒什么，對于規模較大的游戲，最終即使游戲程序本身沒有大的問題，但是在游戲性方面卻讓玩家難以接受。作為技術人員，很容易把目光注視到技術的枝節上，而忽略了玩家的感受，大多數情況玩家并不把技術人員洋洋得意的地方放在眼里，游戲畢竟是給人玩的。
后來又出現了策劃為主導的游戲，策劃拍腦袋一想，我們應該加點什么，那么程序員就日日夜夜地加班完成。如果實在是技術解決不了的還就算了，最怕的是，本來技術解決有問題，可能新加的設計會影響到整體的框架結構、對硬件的過分要求等，暫時像貼皮膏藥一樣把功能補上去看起來工作得很好，可是早早地就給日后的持續開發留下了隱患。程序員在實現的時候盲目聽從策劃的安排，沒有仔細地全面思考，造成了項目無法完成。
我也聽說過美術甚至市場人員為主導的項目，但并沒有接觸過這樣的團隊，就不太清楚會出現什么問題了。
總而言之，游戲開發是一個需要大家共同努力的事情。我們應該把自己的思考都帶入到開發中，盲目地跟從別人的想法或固執地堅持自己都有可能影響整個項目。