開發者談如何以實際行動構建高質量遊戲

在該文章中我將對我所認為作為構建高質量遊戲以及一般軟體所應具備的良好基礎進行探索。我會講到很多不同的主題，這些主題的共同點是——我相信它們都為構建高質量遊戲的目標做出了貢獻。我不會細講每一個主題，但是適當的時候我會提供補充閱讀材料。這不會是一個詳盡的清單列表，肯定還有其他一些重要的因素我沒有覆蓋到，但是從我的角度看來我所提到的那些都是最關鍵的部分，所以為了重申其重要性我要把這些字眼粗體讓它們更清晰：

“我相信下面的內容都是構建高質量遊戲的關鍵基石。”

理解什麼是質量

為了構建高質量遊戲我們首先不得不先要有對“高質量”的一個確切概念。我認為Gerald Weinberg說得最好了：

“質量就是對一些人來說存在的價值。”


如果你要向你的顧客推薦一款遊戲，那麼這款遊戲就應該具備高質量。一款沒事就崩潰的軟體通常對使用者是沒有什麼高質量可言的，所以我們可以認為這種軟體是低質量產品。我們要懂得從對人類價值的方面來考慮產品——只要產品價值高，漏洞多、或者任何其他的指標什麼的都沒多大關係，反之則相反。一款沒有任何漏洞的產品，也可能質量低到無法提供人們以任何價值。

理解什麼是複雜性

我們在構建的是複雜性產品，而複雜性問題被定義為：需要根據追溯回憶推理而得出因果關係的問題，所以這裡的含義是非常廣泛的。一項共產黨管理國家的五年計劃，這種複雜性可以說是沒什麼意義的，因為這裡的複雜程度讓你根本不知道怎麼解決這個問題，而這對於一份詳盡的研究與開發專案計劃來說也是如此。研究與開發是複雜的，任何想要對這些專案進行預先規劃的努力都是徒勞的——你只有先觀察，然後做出調整去適應：工作開始時，先觀察工作成果，然後調整適應新形勢。如果你所創的規劃概述了一個開發專案的範圍，然後你設定了專案完成的日期，這時為了彌補形勢改變，你唯一可以修改的變數因素就是質量。

信任與授權

永遠也別對複雜的事物進行微觀化管理。複雜問題的處理不僅要求對問題能深度瞭解，而且要有應變能力。一名管理者如果跟每天的工作脫節，那他既無法瞭解工作內容，也無法做出解決複雜問題的正確決策。管理需要建立應有的信任，然後讓專家來解決問題，而這就需要授權讓他們去做出調整來應對隨時變化的情勢。如果你想要構建一個高質量複雜性產品，你就要說明你需要解決的問題，而不是告訴專家怎麼解決這些問題，因為沒有人能提前知道問題是什麼樣的。

所有權

但是為了建立信任，開發團隊要擁有產品的所有權。也就是說你所為之工作的產品，其價值歸你所有。因此你也就有責任要交付其價值，你需要擔負起產品的所有責任。無論你的角色作用是什麼，或者你有什麼樣的能力——只要你看到什麼是有損產品價值的，那你就有責任去處理它。

多功能且真誠的團隊

為了建立這種基於信任的所有權文化，你可能需要成立一支相對久遠、多功能型、真誠的團隊。對於一支有能力擁有問題或產品的團隊來說，他們得要有所需的完整技能組來解決這些問題或開發這件產品。一旦你開始在團隊之間劃分工作，並且在團隊之間有太多的依賴關係，你就會破壞產品所有權並造成瓶頸。因為這會讓成員有一種事情出錯不是自己的問題，是別的團隊成員的問題，造成團隊成員之間責任的推卸。所以你還要建立一支高效的團隊，他們要能夠交付高價值產品，當然這需要時間。如果你經常性地在團隊之間把人員像資源一樣調動，這樣很難建設一種基於信任的產品所有權文化，並且團隊將很難發揮出他們真正的潛能。


資訊多樣化

資訊多樣性在團隊中是很重要的，比如說，你會需要不同的產品背景、整套技能組、豐富經驗以及對問題的看法。調查發現，資訊多樣化可以激發大家對手頭上的任務的建設性衝突與辯論。也就是說，人們進行的是對最佳化行動的思考——這就是解決複雜性問題和提高高價值產品的關鍵。

重視團隊能力，忘記自己的角色

當你湊齊了一支多功能型的隊伍時，你要思考的是解決複雜問題需要哪些能力，而不是你要扮演什麼樣的角色。你扮演的角色並不重要，解決問題才是重點。團隊的每個人都應該儘自己所能地去解決問題。無論是誰，只要有能力就應該去做為了達到目標必要做的事，而不應該工作角色描述裡的人為概念所侷限。有一些任務也許需要程式設計專家來完成，然而有一些則只需要基本的程式設計技巧就好。第二種任務就可以由那些平常不怎麼寫程式碼的人來完成。總之就是說如果你有解決問題的能力，你就應該去解決這些問題。所以說團隊的每一個成員都是產品的一個開發者，有些程式設計很厲害，而有些則在產品測試、美工、UI、UX、設計等方面很厲害——但每個人都應該努力去讓自己具備各個領域的基本技能。

反饋和社會契約

為了能有一個功能性較高的團隊，那不僅需要股東們適當的產品反饋，還需要在團隊內部的反饋演示。股東們應該要參與到生產的過程中來，這是非常有價值的一件事，還有團隊需要能持續地重新審視他們的工作原理以及對形勢變化的應變方式。

所以需要簽訂一份社會契約。每個成員都需要知道所有的反饋都是為了以可能性最大的方式去開發出最有價值產品。要去幫助人們成長和發展，而不要去評判表現、批評或袒護權利。

合理的測試外包

總有某些能力或者裝置是團隊沒能具備的。比如本地化測試就是個很好的例子。測試會很繁瑣，昂貴的裝置也是另一個因素。不同型別的認證測試會需要外部方的加入。總的來說你需要找到方法讓測試儘可能地在團隊內而完成，並能夠對何時應該將測試外包給公司其他部門或者第三方做出明智的決策。

為什麼不把所有的測試都外包給別人，讓團隊專注於開發呢？這裡有很多原因，但是最重要的是這個：所有權（歸屬感）。團隊存在問題，就要解決問題，如果你把所有的測試都外包了從某種意義上來說你不經意地把這個產品的所有權也轉移了。

但是還有非常多的原因：反饋迴圈和交流問題；以詳盡的程式測試、不必要的漏洞報告以及額外的需求規格說明所這些形式所產生的浪費；更長的週轉時間等等。

探索性測試

在大多數情況下，製造手動程式測試並反覆地執行它們是一種浪費——所以別做這種測試。你要始終假設你的產品開發人員門是具備高等級測試能力的，他們將進行探索性的測試（你需要學習並理解這種概念），然後當你看到了建立的程式測試存在切實價值時，就做這種測試就好了。不過也要考慮下在這些情況下編寫一些自動化測試——如果你要為了什麼目的建立一個人工程式測試，那麼建立一個自動化測試幾乎總是更好的。

風險性測試

你永遠不可能有時間把所有的測試都執行一遍。你需要分清輕重緩急。你輸入的這個優先順序選擇會有所不同，不過一旦定下來，你會知道要測試什麼才能讓你的測試活動價值最大化。在某種程度上，你會有足夠的資訊來進行產品質量風險評估，然後你把這些資訊提供給團隊成員和股東們。如果有人想要進一步降低風險，你就繼續你的測試活動，如果他們不再有這樣的需要，你就可以停止測試。

執行所有可能的測試不僅不可能，因為幾乎每個複雜的產品都有無數的測試，而且即使有可能，這也是一個資源浪費的巨坑，這些資源本可以用來更好地生產價值的。

另外，不要認為預定義的程式測試涵蓋了所有可能的測試，並不是的。

運營與開發之間的協作

一旦說遊戲上線，不幸地告訴你，產品仍然歸你所有。所以要確保開發團隊和運營上線產品的有關人員要保持密切的協作關係——比如說在客戶支援工作，再比如說IT運營工作。如果你有資料科學部門來研究傳入的資料，那麼他們也同樣很重要。

服務型的領導力

管理人員應該明白，他們在戰場上的將軍角色正在消逝。指導、賦能、支援才是一個管理人員現在的工作內容。如今為了高效地開發出高質量軟體，我們需要的正是這樣一支技藝精湛的、有幹勁的、自主性地匯聚在一起的這樣一隻真誠的團隊。他們最不需要的就是有人站在他們的肩膀上試圖對他們進行微觀管理。

如果你鉅額被上述列出的要素，你就可以開發出高質量的遊戲或者任何其他高質量軟體。這並不是通過其他方面達不到這樣的效果，但是肯定沒這些來的有效。開發高質量遊戲跟生產易拉罐蘇打水是不可同日而語的——上個世紀所定義的最佳實踐不再是運營軟體開發組織的最佳方式。每個人都要去適應——要不就得被替換。


來源：遊戲邦
原文：https://mp.weixin.qq.com/s/4SJFsN2XzxFywd-PcprRSw