最近時常想到 The Effective Engineer 裡面有一章提到的－Validate Your Ideas Early and Often（隨便翻：儘早、經常的驗證想法），介紹的第一個例子是曾經有一家可能被視為 Google 搜尋引擎競爭者的公司 Cuil，當時宣稱有超過 12 億的網頁被索引，是 Google 的 3 倍多，Cuil 也是花了幾年的時間在開發爬蟲、索引，因為當時（約 2008 年）沒有普遍的雲端主機服務像 AWS，所以也自己利用硬體資源建立幾千台的伺服器 infrastructure。但是他們在發表之後遭受許多知名媒體的批評，像是 PC Magazine 用了 “buggy”, “slow”, “pathetic” 的字來形容，在上線的時候，Cuil 的服務遇到了多次當機，最後，Cuil 失敗了。
書中提到幾點 Cuil 失敗的原因：
- 沒有雇用 alpha 測試者來試用產品
- 因為當時 Cuil 擔心發表的內容會被洩漏出去，所以他們也沒有像公司外面取得 feedback 來指出搜尋結果的問題
- 與 Google 相比，Google 花了很多心力在處理為了高搜尋排名的垃圾網站（按：現在卻一堆內容農場…），但是 Cuil 沒有任何人在處理這個部分
看到 Cuil 的經歷與書中提到的幾點問題，簡單來說有一點是他們沒有在開發產品時盡快的驗證產品的做法是不是有問題，需要調整的地方。
之前的工作，其中有一個專案是開發管理志工的系統，自己花了很多力氣在系統開發，默默地寫了實作程式、測試程式、建立自動化的腳本，把開發流程跟 CI 結合，完成後，老闆才發現需要修改與實作的功能不是他們想要的。回想那段時間，當每週開會，老闆問到專案進度，只是告訴老闆完成了哪些部分，或正在開發、快完成了，到接近預計時間，才把自己認為完成的成果給老闆或同事看，在那個時候，才發現在實做出來的功能或做法，跟其他人原本認爲的完全不一樣。過一陣子回想起來，在每週開會的時候，要向老闆 demo 開發的功能，來確認實作的功能是不是走在正確的軌道上，也能夠讓老闆對完成後的系統有更清楚的了解。
從 The Effective Engineer 提到了幾個做法中，覺得比較重要的是：
找到用最少力氣的方法來驗證成果 (Find Low-Effort Ways to Validate Your Work)
用一個作者參加機器人競賽的例子，因為機器人要正常做出動作、前進需要顧慮的因素很多而且非常細微，像是有前後輪的速度、不同的輪胎胎面、輕微碰撞都會影響到成果，他們原本想要一步做到好，讓機器可以直接正常運作，這個方法可能會一次面臨到許多問題，要同時解決；最後，他們用漸進的方式，讓機器人能先往前進，再檢查鏡頭、調整錯誤及方向，重複到完成到最後的目標，雖然一樣會遇到問題，卻是一步一步慢慢解決掉。
這個方式跟最小可行性產品 (MVP) 的做法有點相似，在一開始用最少的力氣，先驗證作法是能行得通，不先一次解決面臨到的許多問題，在過程中搜集大量驗證的結果。
小結：不用太多功夫，來搜集驗證專案假設與目標的結果 (Invest a small amount of work to gather data to validate your project assumptions and goals)（好難翻喔…）
用 A/B 測試來持續驗證產品的變動 (Continuously Validate Product Changes with
A/B Testing)
歐巴馬在第二任的選舉中，他們團隊對 Email 做了許多 A/B 測試，為了需要募款他們需要寄送 Email 來說服支持者捐款，一開始郵件標題是 “Deadline: Join Michelle and me”，應該看起來會蠻合理的，團隊中開始腦力激盪出不同的標題，像是 “Do this for Michelle”, If you believe in what we’re doing” 來吸引捐款人的注意，在做 A/B 測試，他們除了針對郵件標題測試，還有捐款金額、格式、字體大小、按鈕等，最後，來自線上的捐款有 69 億美元。
A/B 測試能驗證產品的假設及漸進變動是有用的
一樣也有一個例子是 Etsy 做手工品線上市集的公司，在重新設計產品列表頁面之前的跳出率 (bounce rates) 是 53%，所以 Etsy 重新設計有幾個目標：
- 降低跳出率
- 清楚的讓消費者知道，他們正在購買的商品來自不同設計師、創作者
- 讓消費者快速的購買、結帳
他們重新設計採用幾個漸進的方式：
- 闡明假設：訂定實驗的假設，像是在市集中對訪客顯示更多的產品項目會降低跳出率
- 建立 A/B 測試來驗證假設：執行實驗來顯示更多的產品圖在列表頁面中，分析數據是不是支持或拒絕假設
- 在測試中學習到的經驗，加入設計中來重複驗證：可能會得到結論是應該把更多的產品圖納入最終的設計中
A/B 測試主要能將原本像在黑箱中猜測使用者的行為，轉成能判讀、理解及可行的知識。
BTW，書中還有提到幾點，在這篇裡沒有寫出來，像是一個人的專案中，要如何得到專案的回饋、驗證自己的想法。
發佈留言