Amazon 的 1-Click 革命#
1998 年 2 月,亞馬遜(Amazon)的工程師 Peri Hartman 走出位於西雅圖第二大道與 Pike 街路口的四層磚造總部,前往附近 Pike Place Market 的微型啤酒廠,與貝佐斯(Jeff Bezos)和首位員工兼軟體開發主管 Shel Kaphan 共進午餐。
當時亞馬遜的結帳流程跟業界一樣,充滿摩擦:
- 一頁輸入姓名 → 點擊
- 一頁輸入地址第一行 → 點擊
- 城市、郵遞區號、信用卡類型、卡號、有效期 → 點擊、點擊、點擊
- 帳單地址 → 又是好幾頁
- 出貨地址 → 更多點擊
- 當時還沒自動填入功能,完成一筆購買可能要花好幾分鐘
席間貝佐斯說:「我們需要做一個讓訂購流程沒有摩擦(frictionless)的東西。讓客戶用最少的力氣下單。他們應該能點一下,就完成。」
「步驟越多,他們有越多時間反悔。如果讓使用者一鍵就買,他們更有機會真的買下去。」 ——貝佐斯
當時網購對許多人還是新鮮事,點擊一連串看不懂的步驟比走到櫃台、把信用卡遞給店員麻煩太多了。把這一切複雜性壓縮為「一鍵」是巨大的突破。亞馬遜為 1-Click 流程申請了專利,維持了將近 20 年,在競爭中提供了難以估量的優勢。
諷刺的是——Hartman 已經花了兩三個月簡化結帳的每一個步驟,卻從沒想過「移除步驟」。
「讓步驟更簡單」與「讓流程本身更簡單」是天差地遠的兩件事。
沒走的步,才是最簡單的步#
不論一個步驟多麼簡單,「不走那一步」永遠更容易。
鷹級童軍報告的故事#
作者的兒子 12 歲時立下目標:14 歲前拿到鷹級童軍(Eagle Scout)。父子倆一起朝這個延伸目標(stretch-goal)前進。最後一個 Eagle Project 完成於他 14 歲生日前——召集 40 人團隊重建一段 180 英尺、被前年加州野火燒毀的圍籬。剩下的只是寫一份報告。
但兩年密集的童軍工作後,這份報告卻像不斷膨脹的怪物:
- 想加一篇生動細膩的開場文章
- 想放數十張照片
- 想做專業級的圖表
- 看到別的童軍(實情通常是父母)花上百小時做出豪華成品,壓力更大
於是專案停擺。每次想接手都覺得難以承受,日子一天天過去。
直到作者剛好在研究「複雜組織的流程簡化」時恍然大悟——他們把這件事複雜化得太離譜。父子退一步問:
「完成這件事所需的最小步驟是什麼?」
砍下來後的清單:
- 打字打出 20 句引言或話語
- 印出來、剪下、貼上
- 印一個簡單的封面
- 放三個分隔頁
- 寫並印一份「精準回答被問問題」的三頁文章
- 開車送到童軍辦公室
完成。報告從停擺到交件只花了原本零頭的時間。兒子在 14 歲生日前一週成為鷹級童軍。
同一個問題能拯救無數專案#
對於看起來壓倒性困難或複雜的優先專案,問這一個問題能省下無數頭痛:
「完成它所需的最小步驟是什麼?」
辨認最小步驟,並非「敷衍了事」或產出讓自己羞愧的東西。不必要的步驟就是不必要——拿掉它們,讓你能把所有能量灌注在完成重要的事情上。
想成功一件事,你得先完成它。
不是每件事都需要 Extra Mile#
作者從小最好的朋友花的時間比作者少,卻拿到更好的成績。秘訣是什麼?老師要求做什麼,他就做什麼,沒多沒少。作者剛好相反,會深入鑽研、讀超過要求、研究多餘的東西——常常忙到「第二哩」,結果連「第一哩」都沒走完。
「multi 走第二哩」在某些情境是必要的(例如外科醫師多做一道防感染的步驟)。但在許多情境裡,只是無謂的裝飾。
一條好用的規則:
「被要求做 X」並不是「做 Y」的充分理由。
例如:被要求做簡報 ≠ 被要求做含影片、酷炫圖表、一頁又一頁資料的投影片。我們都被冗長簡報凌虐過——你真的想把這種體驗丟給別人嗎?
葛斯特納的關鍵時刻#
IBM 傳奇的轉型有一個關鍵小場面。新任 CEO 葛斯特納(Lou Gerstner)邀執行主管 Nick Donofrio 在公司全體會議上發言。當時 IBM 任何重要會議的標準格式,都是用投影機加透明片(內部稱為「foils」)。Donofrio 才放到第二張 foil,葛斯特納就走過去把投影機關掉,在尷尬的沉默後輕聲說:
「Let’s just talk about your business.」
我們就直接談你的業務吧。
這正是大多數簡報該做的事。下次你要寫報告、做簡報、推銷時,抗拒添加不必要附加物的衝動——它們對你是干擾、對聽眾也是。作者自己做簡報時用 6 張投影片、總計不到 10 個字。
大多數情況下你根本不需要走第二哩。只走第一哩,也比哪裡都沒去好得多。
Start with Zero:從零開始#
蘋果(Apple)頂尖產品設計團隊曾向賈伯斯(Steve Jobs)展示後來成為 iDVD(已停產)的設計——一個能把電腦中的音樂、影片、相片燒成 DVD 的程式。團隊很自豪——介面乾淨漂亮、功能完整、把原本需要千頁手冊的版本大幅簡化。
但賈伯斯走到白板前畫了一個矩形,然後說:
「這是新的應用程式。它只有一個視窗。
把影片拖進視窗,點下『BURN』按鈕。
就這樣。我們就做這個。」
設計師之一 Mike Evangelist 後來說:「我還留著當時準備的投影片,複雜度誇張到可笑。」直到那一刻他才看清——「所有那些東西完全在擋路」。
他得到的最大「啊哈」:他們和團隊看待設計的方向錯了——
- 他們的方法:從一個非常複雜的產品開始,試著刪減
- 賈伯斯的方法:從零開始,問:達成所要結果所需的絕對最小步驟是什麼
作者 Podcast 邀請信的瘦身#
作者寫這本書時剛開了 Podcast。原本要寄給來賓的指示有 15 個步驟:
- 用以下帳號密碼登入 Zencastr.com:Username: XYZ / Password: ABC
- 點擊面試前收到的 Zencastr 邀請連結
- 為了音質,允許 Chrome 跳出 Zencastr 通知
- 把 Zencastr 加入書籤(以防第 3 步失效)
- 確認麥克風 Health Check 顯示「Passed」
- 若失敗,點底部音量條中央的標籤,排除問題
- 確認雙方在 Zencastr 中聽得見彼此
- 點作者寄出的 Zoom 連結
- 進入 Zoom 後立刻靜音
- 啟用 Zoom 視訊
- 作者按下兩邊錄音後,確認雙方都看見錄音圖示並做拍手測試
- 開始
- 完成後請在關閉視窗前先登出 Zencastr
- ……(細節再加幾條)
連他自己讀都覺得壓倒性,更別說來賓要照做。於是他從零開始問自己:「用 Zencastr 跟我聊天,所需的最小步驟是什麼?」
最終剩下兩步:
- 點擊面試前收到的 Zencastr 連結
- 我會負責開始與結束錄音,你只要聊天就好
如果你的生活中有那些步驟過多的流程,試試從零開始重新設計。
Maximize the Steps Not Taken#
2001 年 2 月,17 位獨立思考的軟體開發者在猶他州雪鳥滑雪度假村(Lodge at Snowbird)聚會,聊天、滑雪、討論軟體。週末結束時誕生了如今人盡皆知的「敏捷軟體開發宣言(Manifesto for Agile Software Development)」。
宣言的 12 條原則中有一條:
「Simplicity—the art of maximizing the amount of work not done—is essential.」
簡單——將「未做的工作量」最大化的藝術——是不可或缺的。
意思是:目標是為客戶創造價值;如果用更少的程式碼、更少的功能就能做到,那就應該那樣做。
把這條原則延伸到日常,可以改寫成:
「Simplicity—the art of maximizing the steps not taken—is essential.」
簡單——將「未走的步驟」最大化的藝術——是不可或缺的。
不論你的目標是什麼,只專注在能創造價值的步驟。每一個非必要的步驟都伴隨機會成本,移除一個就多回收一份時間、能量與認知資源,投到真正重要的事上。
「大多數天才之所以能繁榮,並非因為解構錯綜複雜的東西,而是因為善用未被認出的簡單。」
——體育記者 Andy Benoit