close
這是一篇在 Gamasutra 上的好文章
檢視裡面所舉出的十項錯誤
不幸的是，我們至少犯過一半以上
根據經驗法則：專案開始的第一步，以及執行的過程 就已經決定成敗
這篇文章中有列出幾項
有不少項是我們曾經犯過的錯誤... 而且還是不斷的再犯
1. Content added too late
不愧是名列第一，我們幾乎是每一個專案都有
這項錯誤可是照三餐在犯的
因為多數人信奉『東西總是要看到之後，才知道怎麼做，怎麼改』
要看了之後才會有Fu上來
因此，在製作過程中....
多數的情況之下，是在製作完成之後
不斷添加東西，與修修改改... 幾乎是成了標準流程的一部分
許多不容易被察覺到的成本於是就產生與浪費掉
時間成本、機會成本.....
2. Communication
這一項錯誤，許多時候是導致其它錯誤的原因，而其它錯誤有會導致這樣錯誤
因此就陷入了可怕的循環
因為一開始沒跟客戶或使用者有妥善的溝通 (需求分析)
或者是跟客戶喬好之後，卻沒跟內部人員溝通 (可行性分析)
於是就發生了第一項錯誤，陷入無止境的修修改改
當然就會導致非常大的專案時程壓力...
當時程壓力出現時，所有的心思就都放在要快點交付
因此所謂的溝通就理所當然的不存在了
3. Scope and scale
Schedules aren't always determined by developers, but they are agreed upon by them. Keeping the schedule and the scope of your game within reasonable limits while still doing the best you can is not easy. But it's absolutely critical.
當有了第一項錯誤發生，這一項就理所當然了
5. Juggling projects, lack of leads
當第一項錯誤發生時，導致了時程壓力，許多人力被牽制在一個專案之中
或者是想要快點結束延宕的專案，或者是有其它的差件
於時開始暫停部分執行的的專案
將人力重新洗牌調度，就變成了家常便飯
甲君本來在處理A案
乙君本來在處理B案
因為A案時程較趕，於是乎暫停B案
將乙君調度來A案
當甲君負責的部分完成，而乙君協助處裡的部分尚未完成
於時又先將甲君挪來處理B案
6. Lack of technical documentation
既然都很趕，連程式註解都沒時間寫了
哪來美國時間寫文件
全站熱搜
留言列表
