［譯］偉大的產品並非誕生於偶然

---

寫在前面：

Medium 上標記爲14min閱讀時長的文章，翻譯花了大概五六個小時。
看到這篇文章的時候剛好本身在讀那本《設計衝刺》。同時也瞭解到 甘特圖 的來源--讀到這裏的時候記起去年看的一本書好像也提到了Taylorism。感受就像是在說明，比起如今比較流行的敏捷開發方式追求速度而言，作產品也要有必定方法論。
而在翻譯方面，感受本身把「Rough architectures」 翻譯成「粗略的架構」以及「play」翻譯成「策略，方法」都有些沒有徹底表達做者的含義。同時沒看過美式橄欖，中間舉着些的例子本身也是比較勉強照搬，有點意會而沒法言傳的意思 :p

---

原文地址 Great Products Don’t Happen By Accident

---

譯文部分：

如下是我在2016年7月21日溫哥華的設計與內容會議上的演講 PPT 和筆記。

讓我先問問大家一個簡單的問題。你是如何完成你的工做？一個語法不太好也不太押韻的句子，對麼？意思實際上是說，對於最擅長的東西，你一直在重複並持續作着什麼？
大家能夠繼續想一想這個問題，讓我先來說講我回答這個問題的經歷。

我是1994年開始從事互聯網行業。那時的互聯網有太多糟糕的產品經理驅動項目，這些產品經理每每被開發過程折磨得痛苦不堪而沒有能力去應對軟件開發過程當中的不肯定性和波動性。而我則從這第一波互聯網浪潮中存活了。

需求文檔每每第一天建立後到次日就沒用了，而後整個過程當中就開始口述一個很複雜的協議，就是爲了取消原本第一天就贊成的需求。

而改需求是如此痛苦因此一般會被全部人不惜一切代價去避免。因而最終你會工做在一個基於錯誤假設而產生一系列不明智需求的項目中。最終致使了大量設計和開發成本，同時也做出了一個在還沒上線就缺胳膊少腿的產品項目。

當時比較流行的文檔記錄方式是甘特圖,好像是微軟項目（Microsoft Project) 惟一的產品。若是你經歷過那個時代，你可能記得整個牆面都被項目的甘特圖覆蓋的場景。

甘特圖展現了工做流程進度和每一個流程之間的獨立性。人們談論的瀑布流進程，就是甘特圖演化而來。表格記錄的工做流之間的依附性就像「瀑布」同樣…同時（「瀑布」）也是 TLC 樂隊的一首歌名 ;p

甘特圖的起源大概要追溯到一個世紀之前，一個叫作科學管理的理論。經過科學管理也輸出了大量管理諮詢人員。科學管理（Scientific Management),也叫泰羅制（Taylorism),是一個分析和綜合工做流的管理原理。它的主要目的是爲了提升經濟效率，尤爲是勞動產出。它試圖在工廠和商店領域經過最小化無效率員工形成的成本浪費從而最大化他們的經濟效益。

甘特和泰勒的發明在1930年代被普遍唾棄和放棄。這些原理很是的喪失人性同時也下降了工人們的士氣，這些實踐最終失敗了。

科學管理的理論依賴於一種觀念：完成一項任務只有一種最佳方法。而經過科學管理你能夠決定工人最有效率的工做方式（例如，挖煤的最佳方法），而後讓全部的員工都使用這種方法。

科學管理理論的內在缺點是對於技術創新或者持續提升效率方面並無一個清晰的方法。

儘管最後失敗了，可是科學管理理論中仍有可取之處應用到了現代工做模式中，兩個著名的應用領域就是時薪制和甘特圖。

當我在90世紀中期接觸到甘特圖的時候，它已經80歲了，像是一個由高效產出的生鐵文物，也像是即將被運用到軟件設計和開發的一劑火藥。（翻譯得好生硬....)

可是到了2000年早期，開發軟件的純粹方法逐漸開始出現漏洞:開源軟件數量的上升，硬件成本下降以及一些網站公司的不斷涌現。

很明顯許多第一代網絡公司是由於他們開發產品的方式而失敗的：單純的在一個笨重的軟硬件模式之上開發本身的產品。（我猜是指開發客戶端模式，就像在windows系統上開發軟甲客戶端這種）， Venkatesh Rao 曾說過這理由也一樣適用於工業時期的產品，分發和銷售模式的失敗。

到了2000年到中期，一大波運用敏捷開發方法開發產品的新型公司誕生了。

這樣的轉變絕大部分應該歸功於在2001年在Snowbird utah (滑雪勝地）討論輕量開發方法的17個軟件工程師。

他們一塊兒討論並寫下了咱們現在叫作敏捷開發方式的一系列意義。
這些意義在變化和適應性上有很是重要的價值

與此同時，一些設計公司也意識到了一樣的問題，慢慢地，咱們再也不生成大量的線框圖和靜態模版，而是產生了大量的工具軟件和迭代。

2000年代見證了技術對商業實現路徑的縮短和對傳統商業模式的破壞。隨着技術將商業分發成本減小到接近於零，速度和敏捷性對於技術公司而言再也不是商業競爭的目標而是一種商業化發展的必備存在。

到了2000年代後期，硅谷公司甚至宣佈只要發佈夠快產品失敗了也是能被接受和歡迎的。敏捷方法讓失敗來得更快同時也會出現更多優秀的產品。

healthcare網站的系統崩潰問題（上圖）對於現在在技術圈工做的人都是無可避免的。而這個由秉信工業時代方法的公司（政府項目承包商）開發出來的網站最終得以解救的緣由是一羣來自硅谷創業公司的開發人員帶來的解決方法。

這場失誤最終做爲了兩種不一樣世界觀鬥爭的結束。在這場鬥爭中，務實和敏捷最終打敗了死板的方法。

也就是在這種環境中，咱們犧牲了「過程」而不斷的實現敏捷開發。

過程程序彷佛成爲了老頑固方法的代言人，成了進步的敵人。

自從咱們強調了敏捷性，各類各樣的工具不斷出現並讓咱們爭相追逐使用。這樣類似的產品和不斷提高的技術已經讓開發軟件的方法變得愈來愈容易。這些工具都很是厲害，他們釋放了咱們的創造力同時也幫助咱們找到改善生活的解決辦法。

可是咱們也開始花費大量時間討論拿個Javascript 框架更好或者哪一個原型工具更出色。咱們不斷地討論是否設計師須要學習寫代碼或者須要學習哪一門語言。

咱們一直沉迷於速度，敏捷性以及如何實現它。

而我也一直堅信快速迭代和驗證....

當速度成爲了咱們惟一的要求，就會變得糟糕起來...很是糟糕。

當咱們停下來，而後問本身「你是如何完成你的工做的？」。咱們一般不太會回答。咱們會傾向於回覆一些咱們使用的工具。問設計師他們怎麼設計的時候，他們一般會回答「用 Sketch」。

這就像是問一個木匠怎麼作的傢俱而後他們回答「用斧子」。

因此回到我在最開始問到的問題…「你是怎麼完成你的工做的？」

過去幾年我一直在研究這個問題，我對回答很感興趣因此我問了不少人而我獲得的最廣泛的回答是...

「看狀況」是一個很是糟糕的回答。可是說出來卻感受不錯，由於咱們在一個對快速迭代和變化很是看重的行業。這取決於保留選擇的價值。

想一下聽到用「看狀況」做爲一個問題的回答，你會選擇哪個？

Q: 機長，你打算怎麼開飛機？
A: 看狀況。

Q: 醫生，你怎麼實施今天的手術？
A: 看狀況

Q: 你愛我嗎？
A: 看狀況

用「看狀況」回答一個問題有兩個問題：

第一，這個回答代表你還不知道你本身擅長什麼。也意味着你尚未找到一個能夠不斷創形成功產出的有效方法。

第二，這個回答是錯的。你其實作了不少事情；解決問題，寫文檔，設計，調研，收集並分析數據。你只是尚未講這些模式造成規範。

在對過程進行任何討論前你必須認可咱們的工做並無那麼美好。你必須相信創造產品或者不管你在從事的什麼，都不是看不見的，而是能夠經過有意的重複動做和框架體系來實現的。

這並非說機會或者時間都不是變數，只是他們不是惟一的變數。這也不是說一個細緻的過程能保證成功，可是能更接近成功。

若是你相信爲了找到適應市場的產品的惟一方式就是丟一大堆產品去驗證的話，那麼接下來討論一些固有方式就變得很困難了。

而若是你相信所有都是偶然。那麼你也最好不要繼續聽下去。這就像在說，吸引力法則（The Secret）是一個值得實踐的哲學,那麼接下來的討論也會是浪費你的時間。

我不相信偶然。我不相信隨機性。我相信全部偉大的產品都不是經過偶然而產生的。

多少人熟悉這個？（上圖），這來自 Spotify 向人們解釋他們怎麼實現敏捷開發的演講。不管什麼時候我向人們談論要帶目的性地建立咱們要作的事情，這都是我想展現的不要太死板的典型例子。
圖中有兩個問題。
這張圖是一個比較典型的迭代設計的簡化，因此我想你不會再設計一輛車的時候第一次就想到設計一個滑板。同時圖中也在假設有一些足夠清晰的證據或數據代表摩托車能夠或者應該成爲一輛車。
第二個問題是，咱們彷佛從沒有討論到下一張ppt...

另外人們討論得比較少的還有這一張，這張講到在開始作敏捷開發前應該須要一些計劃。粗略的適應性的體系結構會讓咱們對產品有一些清晰的認識。

可是，什麼是粗略的適應性體系結構？

粗略的體系架構是一系列在不肯定環境中提供方向的邊界條件。

在即興發揮音樂中粗略體系架構就是節奏和音調。只要音樂家們不會破壞這些體系並達成一致性，他們就能夠創造出無窮無盡的音樂。

在一些即興發揮劇院中，粗略的架構體系則是一系列像這樣的規則... 說「是的，而且」，「在而且後面加上信息」。「避免問題」，

若是你問一個喜劇演員他是如何即興發揮的，他們的回答必定不是「搞笑就好了」，他們會告訴你一系列的規則...

我發現的構建產品的最佳架構體系來自於….

美式橄欖。

美式橄欖球是一項須要球員和教練隨時根據場上不斷變化的戰況而作出關鍵策略的運動。隊員們須要不斷奔跑或者互相傳球最終讓橄欖球到達指定位置。

關於美式橄欖你最須要知道的就是，它的粗略架構體系，除了規則以外，就是策略。

攻守雙方都是經過策略方法來試圖贏得比賽。

在每場比賽開始前，教練都不會說提早肯定好用哪一個策略，由於在隊員上場以前沒人能知道哪一個策略方法會管用。

一樣對於球員而言，在場上並非他們想怎麼打就怎麼打，爲了贏得比賽，隊員以前的協調和合做也是必要的。

在每一個美式橄欖教練的職業生涯中，他們或是本身寫或是繼承出成百上千的策略方式。這些都會寫到策略手冊當中。若是你從沒看過一場美式橄欖比賽，他們看起來就像這樣…

在美式橄欖中，搶斷會破壞防守，三個邊鋒會守在側位（沒看過美式橄欖，憑一點看足球經驗翻的 -0-）。這些你不瞭解並沒什麼，最重要的是你須要瞭解一場比賽的核心關鍵。

一份策略就是團隊對一種比賽情境的一系列應對反應。當教練說「let’s run Statue of Liberty Buck Sweep」（無法翻譯..-0-）每一個人都知道這是什麼意思而且會在賽場上執行這一策略。

若是你說「let’s build an MVP」 你們會知道是什麼意思麼？（應該是跟上句對應）咱們會知道咱們該怎麼作麼？

若是你看過美式橄欖，你就會發現教練都會拿着一個和圖中同樣的板子。

板子裏都是一些摘自教練本身手冊中的策略，這些策略都是爲當前比賽準備的。這對他們即時做出決定有幫助。教練通常會有成百上千的策略記在手冊上，而真正用上比賽的可能只有一小部分。

策略板上有不一樣的提綱方法選擇，以適應一場比賽中可能遇到的不一樣狀況。例如， 3rd down plays, 2 minute drill, kick off plays （我又沒辦法翻譯了-0-).這些策略會在教練的職業生涯中不斷被建立。一本策略手冊就是一個球隊或者教練關於「你如何完成你的工做」問題所蒐集到的知識。

我以爲咱們也須要爲作產品而寫一本策略手冊。爲了更好更快的作更好的產品咱們須要制定一系列策略方法。

爲你如何作產品去寫一份策略手冊對每一個公司都是十分重要的，可是也是最容易被忽略的。

有一個一致的格式去歸檔策略方法是很是重要的。一旦策略方法有了一個標準的格式（成分，過程，工具）就跟食譜很像，這也會讓它更容易閱讀和理解。

因此你的策略手冊也應該有一個一致的格式。你能夠建立任何你喜歡的模版。下面是一些能夠從美式橄欖方法中學習到的一個模版.

給方法命個名 — 方法命名以後就會有個共享的代號。確保這個名字每一個人都能理解。一個叫作 MVP 的方法可能會有許多種含義。

什麼時候開始實施 — 列出方法開始實施的狀況。絕大多數方法可能隨時在一個產品的生命週期的某個點運用上去。在作產品時過後反省或者太早評估都不會是最好的，就像在第二場中反擊不是一個好主意同樣。

爲何實施 — 若是團隊運用這個策略用得很是好，他們會期待什麼？爲何這個方法最好同時團隊會接受 或者團隊但願實施以後獲得什麼好處？

角色 — 列出這個方法中須要的角色，同時還有每一個角色須要乾的事情。

怎麼實施 — 列出實施步驟。以及你可能要作的重複動做。

小提示 — 任何團隊須要知道的東西。

我看到許多在Facebook 的團隊用這個方法：設計衝刺。

設計衝刺能夠運用在一個項目的特殊階段從而取得進展。它們有一系列不相關但定義好的方法能夠直接運用，從而產生期待的結果。它們有可重複的步驟。

設計衝刺有5天時間，有規定的方法和角色。每個設計衝刺都是不同的，因此它也有一個規則去遵照。設計衝刺在項目早期效果最好，可是也能夠在產品週期的任什麼時候段去運用（越靠近上線時間效果越差）。

內容地圖，原型, 國際化，測試，上線計劃…這些都是策略方法。任何能夠重複操做的事情均可以算做一個方法。

有些你可能用得不少...

… 有些可能你不經常使用。

有了策略手冊，你就能夠隨時運用到產品中以得到提升：將老的再也不適用的方法剔除並持續增長一些新的進去。記住策略手冊只給團隊用而且裏面的方法也只適用於他們。

策略也能夠以任何你想要的方式分組...可能你會以爲斯坦福 D學院的思考方法最好（上圖）。你能夠隨時將你的策略方法組織到這些不一樣的階段中去。

一個更偏開發部署的模式

也能夠更偏類型一些。

也能夠按狀況來定。從圖上能夠看到這是團隊中隊員們知道如何找到本身定位的狀況（build mvp），這裏是他們能夠運用到之前已經有成效的狀況（how to test if the product is working）,若是你試圖驗證一個想法，你能夠用這些方法（is this idea any good?)，若是你想決定先作什麼並列出優先級，你能夠嘗試這樣一些方法（what should we build first?)

因此下一次有人問你這個問題... 你能夠給他們展現你的策略手冊。