［譯］偉大的產品并不是誕生于偶然
寫在前面：
看到這篇文章的時候恰好自己在讀那本《設計沖刺》。同時也了解到 甘特圖 的來源--讀到這里的時候記起去年看的一本書好像也提到了Taylorism。感覺就像是在說明，比起現在比較流行的敏捷開發方式追求速度而言， 做產品也要有一定方法論。
而在翻譯方面，感覺自己把“Rough architectures” 翻譯成“粗略的架構”以及“play”翻譯成“策略，方法”都有些沒有完全表達作者的含義。同時沒看過美式橄欖，中間舉著些的例子自己也是比較勉強照搬，有點意會而無法言傳的意思 :p
譯文部分：
以下是我在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 的方法可能會有許多種含義。
何時開始實施 — 列出方法開始實施的情況。絕大多數方法可能隨時在一個產品的生命周期的某個點運用上去。在做產品時事后檢討或者太早評估都不會是最好的，就像在第二場中反擊不是一個好主意一樣。
為什么實施 — 如果團隊運用這個策略用得非常好，他們會期待什么？為什么這個方法最好同時團隊會接受 或者團隊希望實施之后得到什么好處？
角色 — 列出這個方法中需要的角色，同時還有每個角色需要干的事情。
怎么實施 — 列出實施步驟。以及你可能要做的重復動作。
小提示 — 任何團隊需要知道的東西。
我看到許多在非死book 的團隊用這個方法：設計沖刺。
設計沖刺可以運用在一個項目的特殊階段從而取得進展。它們有一系列不相關但定義好的方法可以直接運用，從而產生期待的結果。它們有可重復的步驟。
設計沖刺有5天時間，有規定的方法和角色。每一個設計沖刺都是不一樣的，所以它也有一個規則去遵守。設計沖刺在項目早期效果最好，但是也可以在產品周期的任何時段去運用（越靠近上線時間效果越差）。
內容地圖，原型, 國際化，測試，上線計劃…這些都是策略方法。任何可以重復操作的事情都可以算作一個方法。
有些你可能用得很多...
… 有些可能你不常用。
有了策略手冊，你就可以隨時運用到產品中以獲得提高：將老的不再適用的方法剔除并持續增加一些新的進去。記住策略手冊只給團隊用并且里面的方法也只適用于他們。
策略也可以以任何你想要的方式分組...可能你會覺得斯坦福 D學院的思考方法最好（上圖）。你可以隨時將你的策略方法組織到這些不同的階段中去。
一個更偏開發部署的模式
也可以更偏類型一些。
也可以按情況來定。從圖上可以看到這是團隊中隊員們知道如何找到自己定位的情況（build mvp），這里是他們可以運用到以前已經有成效的情況（how to test if the product is working）,如果你試圖驗證一個想法，你可以用這些方法（is this idea any good?)，如果你想決定先做什么并列出優先級，你可以嘗試這樣一些方法（what should we build first?)
所以下一次有人問你這個問題... 你可以給他們展示你的策略手冊。
來自：https://segmentfault.com/a/1190000008328769