策劃文件分析中的望、聞、問、切（二）

導讀：對於測試工程師而言，分析好策劃文件是做正確的事，網易遊戲測試工程師Rainy以望、聞、問、切這四種手法為切入點，為大家講解如何分析分析一份策劃文件。上期，我們講過“如何望”，今天，我們繼續瞭解什麼是“聞、問、切”。

本文分為兩期推送，此為第二期。

沒看過第一期的同學戳這裡：【第一期】策劃文件分析中的望、聞、問、切

二、聞

仔細聆聽，隨時跟進專案

聞，顧名思義，就是聽的意思。一個比較複雜的系統，策劃一般都會召集相關人員提前開個小會做個宣講，如果是比較大型的資料片，則會召集整個專案組做宣講。

這些系統宣講是不可錯過的，需要仔細聆聽。策劃往往會在在宣講時表達出很多文件中沒有寫明的設定和思想，無論怎麼樣的打字高手，說話似乎總比打字來得更方便容易些。


有些比較複雜的設定，經過策劃的講解，也會比自己看文件容易理解的多。宣講的同時，大家之間的討論很有可能觸發該系統某些設定的改變，作為參與者，自然可以立馬獲悉這些改變。

除了聆聽以外，這裡的聞還有更深一層的含義，就是要耳聽八方。


通常，策劃和程式設計師之間的交流會比和QA交流頻繁得多，因此，會出現一種情況，經常是你在分析文件或者聽宣講的時候，這個系統是這樣的，然後到你開始測試的時候，整個系統在我們不知道的時候改頭換面了，雖然這些修改大部分是不會有問題的，但是總有一小部分會造成大量的返工。

因此，為了避免類似的情況，我們需要多留意周圍的情況。如果你發現策劃和程式設計師開起了小會討論你正在負責的系統，那麼立即加入進去吧，所謂三個臭皮匠，頂個諸葛亮，說不定能想出更絕妙的點子，還可以將一些不合理的設定扼殺在萌芽中。

就算這些都沒有，至少你瞭解了系統的最新改動，不會在測試的時候因為過期的資訊而提一些不存在的bug單。

三、問

深入挖掘需求

前面講的“望“和”聞“，都是瞭解系統設定的方法。但是在有些時候，單單就”望“和”聞“，並不能讓人完全的瞭解策劃的意圖，就我個人而言，這種情況經常發生。

對於不理解的東西，自然是要”問“了。無論是多老資格的QA，都不可能全知全能，對於某些遊戲設定或者實現不能理解並不丟臉，為此請教別人也不要覺得不好意思。

對於系統不求甚解，或者不懂裝懂，因此造成了重大bug，才是真正丟臉的事。就算沒有bug產生，也平白失去了讓自己進步的機會。

四、切

把握遊戲脈絡，獨切不如眾切

切，在中醫中是摸脈象的意。比起前面三個手法，切似乎要玄妙也更難一些。不過不用擔心，和真正看病診脈不同，我們給遊戲診脈，並非一定要自己完成。

切更有切磋之意。你大可以和程式設計師或者策劃討論：我對於這個設定有XXX以下幾點疑慮，我們應該怎樣改進對遊戲會更好呢？正所謂獨切不如眾切，群策群力才是王道。


即使你已經想出了很好的點子，切磋仍然是需要的。作為一個文案的創造者，策劃總是你需要好好溝通的物件，有了好點子並且讓策劃接受，才是文件分析的目的。

一般，我們會寫策劃文案分析，通過郵件發給策劃，策劃也可以回覆郵件來答覆。但是有時候難免會有這樣的情況發生,QA建議:由於A原因改成這樣->策劃駁回:因為B原因不能改成這樣->QA解釋:B原因，其實是不用擔心的，因為……->策劃回覆:因為C原因還是不能改成這樣……

比起這個，面對面交流始終是一種更加神奇且有效的方式：你的文案我看了，出於A的原因，XX設定我覺得改成XXX會比較好，或者你出於一些其它的考慮要這麼做呢？哦，你是出於B、C……原因啊，其實是不要擔心的，因為……

無論是快速說服策劃還是快速被策劃說服，都可以節省不少郵件往返的時間。當然策劃文件分析還是要發的，但是我們可以在和策劃討論之後作為總結備忘發出。

五、小結

一開頭說了這是關於如何“做正確的事”的文章，但是寫完全篇回顧一下，其實還是一些如何“正確的做事”方法而已，在結尾的時候，總覺得應該要說一些真正和“做正確的事”相關的東西來呼應下開頭。

在一開始進入公司做測試工程師的時候，當時QC組的組長曾經問我一個問題：“你覺得作為一個測試人員，需要具備哪些條件呢？”

當時我答：“細心、熱愛遊戲。”不喜歡一份工作，當然不可能做得好啦，而我這個人有些時候會比較粗心，因此有這樣的答案。

組長回答說：“這些當然都很重要，但是作為一個測試人員，最重要的是要有責任心和一定的堅持。”這番話當時就讓我印象深刻，現在回味更顯真知灼見。

作為一個測試人員，在經歷相關的培訓之後，再抱有責任心和一定的堅持，在工作中“做正確的事”應該都不會太難。

來源：網易遊戲學院
原地址：https://mp.weixin.qq.com/s/YjJLjMrJS8m8Lk9KH2MBQQ