Management

[2011] 遊戲軟體管理經驗談(7)-遊戲專案管理其他常見的名言錦句


遊戲軟體管理經驗談

發佈區域:PTT GameDesign版(telnet://ptt.cc),部落閣Black Straits Historical(https://ndark.wordpress.com/)

版權所有,禁止轉錄

作者:NDark,目前任遊戲公司軟體工程師(專案主程式)
時間:2011 秋

遊戲專案管理其他常見的名言錦句

沒人知道怎樣做出好遊戲

好遊戲的定義本身就是不清楚的,多半是賺錢的遊戲事後就被稱做好遊戲。然而,即便是經驗豐富的製作人,也難以掌握市場的脈動。即便是知名團隊有經驗的人員跳出來自己做,也都不斷看到作不完半成品硬推出,結果一敗塗地的案子[註]。某日本掌機製作人的經驗談是持續開發,做一款,試一款,然後不知為何大賣,把之前賠的都賺回來。

[註]Hellgate: London(http://en.wikipedia.org/wiki/Hellgate:_London)

不需要外行人(玩家)來指導我們如何作遊戲

我們要做的是鎖定的市場中多數人都覺得好玩的遊戲,而不是作只討好其中一個高端玩家的那個遊戲。行銷市場面的經驗很有參考價值,老闆給的意見也一定要認真點頭,高端玩家口中 “我覺得要怎樣怎樣"偶爾也可以聽聽。但是每動一個屬性可能會導致很多連鎖反應,不是維維諾諾照單全收,回來思考討論後再決定要不要改。

設計工作與藝術不同

設計的本質是為客戶。設計客戶要的產品,而不是作出一個自己要的作品。不要把自己變成上一條那位高端玩家。

及早找出獲利的方法

不管是公司團隊,業餘或獨立開發,及早找出獲利的方法,也就是我們的專案最後會以怎樣的方式來賺錢:在遊戲發展史上,最早是賣產品,然後是賣服務,最近流行賣加值,有人說接下來是經營社群(G團抽水錢)。獲利的方式用算的,不要用猜的。把代理商跟平台商的抽成算進去,讓殘酷的數字逼迫我們嚴肅地下重要的決定:這門生意到底可不可行?避免辛苦半天結果收不到錢,或是打錯了市場。

不要在自己腦內空猜想

發想後,使用具體可見的工具來互相驗證想法,不要在自己腦內空猜想。可以動動手做點勞作。

明知計劃不可行

當估算時程發現不合理,也就是明知計劃不可行卻苟且接受它,我至今依然分不清楚這是負責還是擺爛。

信任破產無法彌補

傳統的公司組職管理傾向把不同的資訊傳達給外部的股東與內部的員工。然而現今兩者的角色有時卻是重疊的。當員工發現兩種資訊揭露不同的訊息時,造成的信任破產無法彌補。

一切團隊運作的規範就是工作規範

關於企畫規格如何確認,版本如何發佈,機台如何維護,工作如何分派執行,如何測試驗證。可以的話,把工作規範跟團隊人員作溝通,訂出團隊都可以接受的製程,然後在適當的時機讓團隊成員回饋,適度的調整它們。這會變成團隊的資產,別人無法複製的經驗。

品質管理與文件是政治問題,不是技術問題

沒錯這就是多出來的工作,也沒錯就會多出那些時程。若是規格書產生時作不出驗證清單,勢必然那規格書不夠完整。若是規格書與驗證清單的產出時間點不同,勢必然之間一定會有落差。工作完成時若能拿著驗證清單來驗證才能釐清責任歸屬。如果真的產不出驗證清單則只好依賴三位負責人口頭確認工作是否做完。

複數專案團隊間的整合有賴政治力的介入

管理如何重複利用企畫文件,軟體架構,軟體介面,程式碼,函式庫。如何共享?如何維護?更好的是如何讓不同的團隊一起規劃看到相同的願景?

風險

風險分析指的是有什麼風險,以及發生的機率;風險評估則是排出優先順序。風險處理就是各項風險的閃避方案,處理方案。三者合一就是風險管理。

廣告

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s