【轉載】發現問題與描述現象的方法

soking

發現問題與描述現象的方法

笛卡兒（Descartes）在他的「方法論」中說：「將每一個問題盡可能地且恰如所需地分成許多部分，使得每一部分都可以輕易地解決。」這也是分析與綜合方法的展現。


　　延續上次文章提到的遊戲中的QA，這次來談談實務經驗上，我們針對一個問題的發生，可以怎麼樣去作出分析，讓別人能夠精確的認知，這樣的方法不僅僅限於遊戲中的QA，更可以廣泛應用於面對未知問題的時候，嘗試思考的邏輯，啊，話說這個方法叫做「T型理論」，不是阿獸獨創的，想知道來源大概要去搜尋卡內基或是什麼管理理論吧？


　　一個問題發生的時候，一般人往往只在記憶中留下對於情緒感受有反應的記憶，例如說：「很突然、怪怪的、好像有問題……etc」，這樣的情況源於普通人對於狀況的記憶都是只專注於自己的感覺，而非問題的本質。

　　在日劇「司法八人組」之中有段有趣的課堂狀況，在上課途中忽然闖進一名男子手持球棒襲擊上課的教授，整件事情的過程就在一眨眼不到十秒鐘的時間中，上課的眾人眼前發生，接著在間隔幾分鐘後的指認時，全班卻無法達成統一的意見，而形成交錯指認的混亂情況。

　　明明是發生在眼前的實況，人們卻會被其他人意見所影響記憶，然後把眼前的事物作出了扭曲的描述與判斷，由此我們可以知道，人類的情感記憶影響是有多麼的大，以至於會干涉到理智的判斷。

　　所以呢，當我們在面對一個問題的產生時，可以依照三個階段來拆解，將一個模糊曖昧的問題描述變成可條列式描述的狀況，並且能進一步的進行交叉分析，步驟如下：「現象」、「原因」、「步驟」。

　　一、現象：

　　嘗試描述事實，並且盡量將個人好惡的差異性降低，需明白自己的描述是否為事實或是個人觀感而造成的問題，例如說：「這道菜是辣的。」這是一個事實的描述，然而「這道菜味道很差勁，而且又辣。」，這樣的描述卻容易混淆訊息傳達的重點，因為味道差勁是個人觀感，然而在第二個描述之中，「辣」的要素只感覺是負面的傳達，卻不知道在味道的評價裡面佔了多少影響的成分。

　　如果描述更精確的成為：「這道菜有酸臭腐敗的味道，並且很辣。」這樣的描述能夠更進一步將整個現象作一個完整的表達。

　　以遊戲問題的回報來說，避免只說：「這地方感覺怪怪的。」而是去描述你所遭遇的問題，例如說：「這個跳躍人物動作會閃爍」、「這個介面顏色很花找不到重點」、「無法分辨敵我雙方」等等，嘗試將遊戲中所遭遇的問題情況，轉化成可以被分析的狀況，能讓問題的狀況變得更明確。

　　二、原因：

　　發現問題的狀況之後，進一步去思考可能的因素，這個階段是作出盡可能的推論，將問題的「發生原因」有哪些可能性羅列出來，有時候在遊戲開發之中遇到的問題，並非是單一要素所造成而可能是多重解。

　　分析出「發生原因」後跟「現象」進行交叉比對，我們有可能直接釐清大多數的問題，例如若有個問題是「認為這個關卡太過於簡單」，那麼針對這個問題所產生的「現象」可能有：

　　‧一下子就過關了
　　　　‧敵人容易發呆
　　　　‧沒什麼損血、死亡

然後針對這些現象加以分析，或許我們會認為有這些原因：

　　‧一下子就過關了
　　　　‧關卡太短
　　　　‧地形沒有變化
　　　　‧缺乏阻擋物件
　　　　‧敵人威脅性不足

　　‧敵人容易發呆
　　　　‧AI判斷有問題
　　　　‧偵測的判定距離錯誤
　　　　‧敵人的動作模式順序可能需要調整

　　‧沒什麼損血、死亡
　　　　‧玩家裝備、數值太強
　　　　‧玩家擁有完全剋制敵人的強力武器
　　　　‧放置敵人的組合有問題

　　像這樣子，交叉分析之後，或許一個問題的概念馬上就會很清楚的被分解，甚至答案立刻就呼之欲出了！

　　三、步驟

　　發現了問題之後，這個問題能否被重複的驗證檢查呢？

　　若是以遊戲的Bug來說，一個Bug的發生回報，很重視的就是再現性的步驟問題，因為若是無法找出Bug的再現規律，那麼這個問題的回報會變成隨機性的問題，而若是嚴重的當機問題，則非常之嚴重，可能負責程式的夥伴需要從前述的現象與狀況之中，嘗試著從原始碼去解析可能的Bug存在。

　　那麼，仔細的從「現象」之中來作「步驟重現」也是很重要的，這樣的問題回報就可以讓複數的人加入檢查，尤其是在團隊合作的遊戲之中，更是需要這類將工作處理成讓別人能夠進入或接手的狀態。

[ 本文章最後由 soking 於 08-6-27 10:40 編輯 ]

soking

這是阿獸在遊戲製作板上發的教學文章，與思考有關，還請各位過目看看吧~