在網(wǎng)路時代，工程師儼然是許多公司的核心運作單位，一如股票投資，好的老師帶你上天堂，一個好的工程師，可以不用花費十倍的工作時間，卻能創(chuàng)造出十倍的影響力。但是，工程師或是企業(yè)管理者，到底該怎幺做？

硅谷頂尖工程師、曾經(jīng)面試過超過500位工程師的熱門書《The Effective Engineer》作者兼Quip工程師Edmond Lau日前提出對工程師惡夢“Bug”（代碼錯誤）的看法。

Edmond Lau表示，當代碼運作不如工程師的預期時，可以用“斷點和追蹤點”的功能快速找到錯誤所在；而小型可重複的測試則能阻絕干擾，讓工程師集中于系統(tǒng)故障的相關(guān)部分。沒有這些工具，公司的例行工作將變得冗長費時。他說：“同理，若使用者的行為不如公司的預期呢？”根據(jù)他多年的經(jīng)驗，提出以下三點工作準則：

作者兼工程師Edmond Lau

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

給客戶的小型可重複使用的產(chǎn)品，就如同給工程師的可重複測試的代碼。這方面需要思考的是：在所有可重複測試的問題中，最重要的部分是什幺？從運作過程來看，我們?nèi)绾沃朗褂谜叩男袨槭欠袢绻舅A期？這兩個問題有項共同點，就是幫助工程師將注意力聚焦到真正重要的事情上。

修正代碼時，工程師必須先深入了解系統(tǒng)狀況；若想修正使用者的行為，我們也必須先知道使用者的想法。例如，有人認為“消費者更愿意在有較多商品圖片的網(wǎng)頁上購買。”該如何辨證這句話？一般來說，公司會透過A／B test觀察置有廣告圖片的網(wǎng)頁是否有較高的購物頻率，獲得結(jié)論后，網(wǎng)頁設計者便能修改頁面的布置。

A／B test對于成功與否的判斷很有效，公司只要蒐集量化資訊如點擊率、會員注冊率和購買頻率即可獲知。不過，當公司沒有足夠的樣本數(shù)，或者想知道使用者行為的背后意涵，就必須用上“對話紀錄”（session logs）。

對話紀錄透過匯集單一使用者的所有行為途徑，以及觀察使用者運用產(chǎn)品的方法，能夠蒐集到充足有關(guān)“動機”的資訊，而這些是A／B test無法得知的。譬如，Google也利用Session viwer追蹤使用者的搜尋過程，并分析其行為意義。

然而，有時就算是對話紀錄也不一定能深入地了解客戶。例如，Quip在研發(fā)新產(chǎn)品時，會將與研發(fā)有關(guān)或早期的客戶集中在一份文件檔或?qū)υ捒蚶?，以便公司對其進行新的系統(tǒng)測試或個別的意見調(diào)查。另外，公司也使用usertesting.com的服務，該服務把實驗任務發(fā)派給線上使用者，并以影片紀錄這些人使用產(chǎn)品的過程，最終訪問其對產(chǎn)品的感想，整個過程耗費不到一小時。

透過實際與實驗對象互動，公司能清澈地解剖作業(yè)設計，并把精力花在正確的地方。Edmond說：“我們從來不在進行小型測試前，書寫上千行的代碼以惡補漏洞。有這幺實用的工具，為何要土法煉鋼呢？”

文章編譯自《The Effective Engineer》

文章來源：機房監(jiān)控 http://shfkmygs.com