照片來源：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〉
