Categories

工作態度 (1)    方法論 (5)    本土化 (9)    危機管理 (2)    死亡 (1)    自我成長 (1)    自我管理 (3)    決策管理 (1)    版本 (1)    社會 (2)    品管 (3)    風險管理 (1)    效能 問題 (1)    時間管理 (5)    專案 (10)    教育 (1)    產能 (1)    產業 (5)    軟體 (4)    測試 (10)    閒聊 (14)    溝通 (4)    道德 (1)    漫談 (23)    管理 (1)    機器翻譯 (1)    簡轉繁 (2)    翻譯 (8)    booksore (1)    Chinese (1)    Flash (1)    G11N (1)    I18N (3)    Industry (1)    L10N (8)    politics (1)    Project Management (6)    Revision (1)    Software (3)    Testing (4)    Time Management (1)    Translation (4)    UI Design (1)   

2010年8月6日

如何清楚的陳述問題

如果是在專門的測試專案裡工作,多半會學到一些測試方法與規範。這裡先保留不提工作上的測試相關工作。先來談平常生活中所遇到的問題。

試想,如果說你上週買了一台冷氣,用了不到一週,今天他突然不會運轉了,於是你撥電話給該公司客服,你會怎麼陳述問題?
「我的冷氣不會動了!」
是這樣的嗎?

其實有這樣客服與顧客之間的對話實際發生過:
「我的電視不能看了,我上週才剛買的!」顧客反應這麼說著
『昨天還能看嗎?』客服問道
「昨天還能看,今天就突然不能看了」
『可以說明一下是怎樣不能看嗎?』
「就我拿遙控器對著電視按電源鍵,但電視就沒反應啊!」
『可以確認一下遙控器是不是還有電嗎?或是你換一組新的電池看看,按遙控器時看上面的發送燈號有沒有亮。』
「我試過了,換新電池後,按遙控器時確認發送燈有亮,但電視就是沒反應!」
『不知道遙控器會不會摔壞了,這樣好了,你走到電視前,從電視的面板上按電源鍵看看!』
「等我一下喔....還是沒反應耶!」
『嗯....可以麻煩你看一下電視的插座有插上嗎?』
「我看看喔....啊沒有插上....」

類似這樣的交談流程會分常冗長,有些公司就會開始利用一些方法教導顧客先做基本的障礙排除,然後在顧客找客服支援前,會再適度的教導顧客要準備哪些資料,例如在產品說明書上就印好一個空白表單,讓顧客準備好問題的背景資訊,以便跟客服接洽時可以較有條理的反應問題。
以上面的例子,在說明書上的基本障礙排除就會先列上諸多檢查項目,諸如檢查電源插座、遙控器、電池等等。針對問題的描述則會請顧客描述故障的種類與細節,例如是開啟電源畫面完全是黑的,還是呈現雪花狀畫面。如果是呈現雪花狀畫面,是不是每個頻道都是如此,有無事先詢問有線電視業者訊號是否正常等等。

在開放的論壇上,也時常有網友詢問問題,類似那種「我的車子突然發不動了」、「我玩遊戲時感覺很卡」、「我的手機執行xx程式就會當掉」等等,千百種的問題,但很常見沒頭沒尾就冒出來一個問題,即使其他網友要協助也完全找不到下手處。

回過頭來看測試領域,通常在規範撰寫軟體錯誤報告時,會要求類似如下的資訊

作業系統版本與語言:
安裝的軟體清單與版本:
問題的重製步驟:
1.
2.
3.

產生的錯誤結果描述:
預期的正確結果描述:

其他附註:

但這是錯誤報告,如果現在是要與其他人溝通一個問題呢?其實我覺得原則是一樣的,當要反應一個問題,事先先要做背景的描述,然後針對問題儘可能的加以剖析,清楚的描述所發現的問題現象,以及敘述預期的正常結果。

好比說如果我想要對台北市政府反應交通問題,那麼也許我可以這麼說:
基隆路與忠孝東路交叉口,在路口西東南側,也就是沿基隆路往北然後右轉東向的忠孝東路這個方向,在上午九點半至十點之間,通常因為已過交通尖峰期,交通警察多半已在九點半之前便已撤離。因此這段時間便開始有很多計程車司機開始違規在路口紅線上,以及公車停靠區域,違規排班,導致公車進站、出站困難,進而造成交通堵塞。建議交警能夠加強此區段的違規取締,以改善交通紊亂狀況。

背景資訊是路段地點,重製步驟是地點加上時間,發現的問題是違規排班,預期的正常結果是加強取締並使交通紊亂獲得改善。

我發現有時有些人在溝通一個問題時,問題被轉了很多手,然後已我旁觀者來看我覺得問題已經失焦了,大概因為在轉手時,收到問題的人往往只花很短的時間看「重點」,然後又轉給下一個人,經常只附帶「客戶反應這個問題,麻煩你看一下」這類的訊息,這時這個信件本身已經很冗長了,如果加上處理人員沒有認真追蹤問題,或是反應問題時沒有提供足夠資訊,往往處理問題的人因為無法重製問題而草率結案。但問題並沒有解決,於是問題又再度透過層層關卡反應,到了最後處理的人員,這時可能已經過了一個月,他大概只有些許的印象,覺得這麼問題又來了,上次不是試過沒問題嗎,然後簡單試一下發現還是不能重製問題,又打了回票。

這樣的溝通就會顯得相當的浪費時間。我通常會建議當發現問題逐漸失焦時,最好是把問題的前因後果等細節重新描述一次,不花多少時間,卻可能讓問題可以快速回到焦點上並在短時間內獲得解決。

一個重點是,通常問題在被轉送時,訊息會逐步被短縮,所以有必要的話,最好每遇上一個新的處理人員,就跟他再描述一次問題。

0 Comments: