Contents
原文網址
文章鏈結 Working Backwards
這篇文章是 2006 年的文章，可以說是亞馬遜2002年的「平台化」的實踐版本。當時貝佐斯寄出一份內部通告，徹底改變亞馬遜公司的組織。這份通告大致包含以下要點：( 參考科技島讀一文 – 亞馬遜並購 Whole Foods 的三大優勢 )
- 所有團隊未來流通資料與功能，必須一律需透過服務介面（service interface）
- 所有團隊之間溝通也必須透過這些介面
- 除了這些介面之外，不准有其他流程間的溝通：例如不准貼連結、看彼此的資料庫、分享儲存或是開後門（back door）等，只准透過介面彼此呼叫資料
- 介面用什麼技術都可以
- 所有介面必須從底層設計為可以「外部化」（externalizable），也就是說介面必須能夠開放給外部開發者使用
- 誰不照做就開除
從 Working Backwards 這篇文章中更可以證實亞馬遜獨特的產品開發文化
文章內容摘要筆記
在亞馬遜上使用的細粒度服務方法中，服務不僅代表軟體架構，還代表組織結構。 這些服務有一個強大的所有權模式，結合小團隊規模是為了使創新變得非常容易。 從某種意義上說，你可以把這些服務看作是一個大公司內部的小公司。 每一項服務都需要強烈關注他們的客戶是誰，不管他們是外部人員還是內部人員。 為了確保服務滿足客戶的需求(而不是更多) ，我們使用一個叫做」反向工作」的流程，在這個流程中，你從你的客戶開始，然後向後工作，直到你達到最小的技術要求，以滿足你試圖達到的目標。 我們的目標是通過一個持續的、明確的客戶關注點來實現簡單化。
產品定義過程向後推進: 我們首先編寫發佈時需要的文件(新聞稿和常見問題) ，然後致力於更接近實現的文件。
反向工作產品定義過程的全部內容就是充實這個概念，並對我們最終將要開發的產品進行清晰的思考。 它通常有四個步驟:
- 從發佈新聞稿開始。
- 寫一份常見問題的文件
- 定義客戶體驗。
- 編寫用戶手冊。
最後才是寫程式 Orz
作者指出了
一旦我們經歷了建立新聞稿、常見問題、模型和用戶手冊的過程之後，令人驚訝的是，你計劃建立的內容是如此的清晰。 我們將有一套文件，我們可以用來向亞馬遜內部的其他團隊解釋新產品。 我們知道，在這一點上，整個團隊對於我們將要開發的產品有著共同的願景。
心得
亞馬遜的產品服務開發流程真的蠻適合給具有工程師背景的創業者當作借鏡，工程師背景的創業者罪容易犯的錯誤大概就是 – 實做很快 ，然後做出了不是使用者要的功能，接下來就是打掉重練，回想一下自己是不是犯過這樣的錯誤，筆者就犯過好多次 XD