當個有戰力的工程師!先搞清楚修Bug和理解使用者其實是同一件事

圖說明
照片來源:Duncan Hull

在網路時代,工程師儼然是許多公司的核心運作單位,一如股票投資,好的老師帶你上天堂,一個好的工程師,可以創造出相當於一般員工十倍的影響力。但是,工程師或是企業管理者,到底該怎麼做?

待過Google、Quora,現任Quip的工程師Edmond Lau,曾經面試過超過500位工程師,同時也是熱門書籍《The Effective Engineer》的作者,日前發表一篇文章,為工程師「debug」使用者行為提出一些建議。

圖說明
圖說:Edmond Lau(來源:截自網路)

Edmond Lau表示,當程式碼運作不如工程師的預期時,可以用「breakpoints and strace」快速找到錯誤所在;而小型可重複的測試(Minimal reproducible test cases)則能阻絕干擾,讓工程師集中於系統故障的相關部分。沒有這些工具,公司的例行工作將變得冗長費時。他說:「同理,若使用者的行為不如公司的預期呢?」根據他多年的經驗,提出以下三點工作準則:

1. Debug 使用者行為,就像你在 Debug 程式碼那樣

公司在研發新產品或新功能時,經常在商品上架後,才不斷地補充功能層面。舉例來說,API(應用程式介面,幫助第三方開發者與系統廠商溝通的介面)若有設計闕漏,將造成數以萬計的程序溝通錯誤,彌補作業如同萬丈深淵。因此,Edmond把構思程式程式碼的時間拉長,他習慣先寫一至兩頁的設計概念,並蒐集其他工程師對API的看法。最終,他如願找到可以修正所有API錯誤,而不需寫任何程式碼的工具。

給客戶的最小可行性產品(minimal viable product),就如同給工程師的可重複測試的程式碼。這方面需要思考的是:在所有可重複測試的問題中,最重要的部分是什麼?從運作過程來看,我們如何知道使用者的行為是否如公司所預期?這兩個問題有項共同點,就是幫助工程師將注意力聚焦到真正重要的事情上。

2. 試著解讀使用者的心

修正程式碼時,工程師必須先深入瞭解系統狀況;若想修正使用者的行為,我們也必須先知道使用者的想法。例如,有人認為「消費者更願意在有較多商品圖片的網頁上購買。」該如何驗證這個假說?一般來說,公司會透過A/B test觀察置有廣告圖片的網頁是否有較高的購物頻率,獲得結論後,網頁設計者便能修改頁面的配置。

A/B test對於成功與否的判斷很有效,公司只要蒐集量化資訊如點擊率、會員註冊率和購買頻率即可獲知。不過,當公司沒有足夠的樣本數,或者想知道使用者行為的背後意涵,就必須用上「session logs」。

將 logs 裡單一使用者所有的行為資料結合,我們便可為該使用者的 session 建立按照時序排列的活動紀錄。藉由研究使用者如何瀏覽產品、採取何種行動,便可描繪出使用者意圖,而那些往往是我們光從 A/B test 蒐集而來的數字所無法完成的。Google 也會用 Session Viewer 去研究、視覺化使用者究竟如何完成搜尋相關的任務(tasks)。

3. 把精力花在正確的地方

然而,有時就算是對話紀錄也不一定能深入地瞭解客戶。例如,Quip在研發新產品時,會將與研發有關或早期的客戶集中在一份文件檔或對話框裡,以便公司對其進行新的系統測試或個別的意見調查。另外,公司也使用usertesting.com的服務,將設計好的實驗任務發派給線上使用者,並以影片紀錄這些人使用產品的過程,最終訪問其對產品的感想,整個過程耗費不到一小時。

透過實際與實驗對象互動,公司能清澈地解剖作業設計,並把精力花在正確的地方。Edmond說:「我們從來不在進行小型測試前,書寫上千行的程式碼以惡補漏洞。有這麼實用的工具,為何要土法煉鋼呢?」

文章編譯自〈Why’d You Do That?!? An Engineer's Guide to Debugging User Behavior