作者 Jocelyn Goldfein ，天使投資人、前 Facebook 和 VMware 工程主管，她因幫助工程師團隊在高速增長期快速擴充套件業務而久負盛名。在 First Round 公司上次的 CTO 峰會上，她分享了不同環境下發布軟體的經驗，並在如何構建自己的釋出流程方面為初創公司提供建議。
我在這方面歷練多年，釋出過許許多多的軟體，我曾在3人到1萬人的高科技公司工作，開發的軟體從免費到五千萬美元授權費——以及這之間的任何價位。這些產品的開發和釋出方式各有不同，在有機會進行比較和對照之後，我也想揭示釋出軟體的正確方式。
很慚愧，我承認我給不出來。
我多次發現而又重新發現構建軟體、釋出軟體的“正確”方法。我近乎狂熱於某些實踐（比如精確的估算編碼，詳盡的規格定義或通過 A/B 測試的UI設計），但是當我嘗試把這些實踐應用到其他產品上時，魔法卻失靈了。
在這個行業裡，我們因為製表符長度和大小寫問題持續了幾十年的“聖戰”，人們深深迷戀自己的開發和釋出習慣，也就不足為奇了。如果釋出了這麼多軟體能夠教會我一件事，那就是做一個不可知論者。不同的方法適用於不同的目的，而且它們各有各的不足。如果強化時間表的可預見性，就會損失工程生產力（也就是變成了經典的時間/空間取捨）。即使你不用面對教科書上的取捨問題，所有付出的努力，不管是實現自動測試還是修正BUG，都會換來另外讓你花費時間的其他東西。
親愛的工程師們，請不要問「這個流程是好還是壞？」，而是要問「它適不適合我的場景？」
來看看我的兩段職業生涯：
VMWare的初創期，軟體要具備可預期的完成日期和高可靠性，因為必須要說服保守的企業使用者使用全新的供應商提供的作業系統。（那時候虛擬化聽上去像是科幻一樣！）
Facebook在初創期需要快速前進，因為先行者優勢對基於網際網路的產品意味著一切。
兩家公司一個高度重視可預期性和可靠性，另一個致力於提高使用者參與度，很容易猜測哪個是哪個。可想而知，這兩家公司的開發實踐毫無共同之處，沒有誰對誰錯——都為了目標做出了取捨，它們中的任何一家如果採用另一家的產品將會無效甚至是災難性的。
首先看看顧客是誰
要確定“開發軟體的正確方式”，必須理解產品的關鍵點及如何優化才能實現這些關鍵點。這不是由個人偏好決定的，歸根結底取決於公司的使命，也就是你的公司如何賺錢。
如果你以高價銷售軟體，那麼你的客戶很有可能是基於需求來購買的。軟體價格越高，您客戶的業務越關鍵，你就越有必要優化軟體的可靠性、功能性和可預期的時間表。也許你覺得商業客戶希望你的軟體做的越快越好，但是他們依賴很多東西–部署、培訓、整合-對他們來說可預期性比快速更加重要。更大的交易規模也伴隨著更少的客戶，這意味著每個客戶擁有比你更大的權力，滿足他們的需求對創業生存下來更重要。
許多最傳統的，守舊的軟體開發方法的目標是確保計劃的可預測性：認真規範的功能列表和任務估算、依賴性分析和很長的工作時間。持續整合、全面的單元測試和beta測試等更加現代的技術也會幫助大家更早發現技術風險。在VMware工作的七年裡，我們所有的努力都基於一個時間表、特性和質量的“三腳凳”。它們中的每一個都必須滿足，這帶來了高昂的工程造價及非常低的開發效率。我們嘗試使用擁有更快的開發週期的新技術，但它們有一個客戶無法接受的缺陷：缺乏遠見。
一般來說，昂貴的軟體意味著可預期性是釋出的關鍵，客戶需要你的產品。如果軟體價格更低（或免費），那麼關注UX，讓本不需要你產品的使用者很想去使用它。
如果你的客戶不是有具體需求的企業怎麼辦？隨著你的要價越來越低（從百萬級到萬級，到千級，到freemium，到免費），你的市場覆蓋面越大越容易涉及較小的企業或消費者。對於這類產品，時間表沒有那麼重要，因為不管最新功能什麼時候實現，人們一般都會接受。單個客戶的影響很小，所以你可能不會優先處理小平臺或少量使用者遇到的bug。
不過不能因為收費低就不再優先考慮質量問題。如果你的產品廉價或免費，人們使用它的原因很可能是想使用而不是必須使用。長期以來，使用者體驗（UX）在消費級市場比企業級市場重要得多。企業產品供應商也越來越重視偉大UX的價值，但他們追求“消費級使用者介面”是有原因的。我們可以找到很多實踐來保證 UX 質量，包括強化設計團隊，在承諾的交付日期前做原型和迭代，設計、工程和使用者測試之間密切合作。
舞臺也在這裡，如果你在快速增長(一年內80% 的使用者是新增使用者，他們不會記得你的錯誤)那麼質量上的折衷也許可以接受；如果你經營的是重複業務（經常性收入），你就必須確保當前客戶的滿意度。
其次，評估您的部署方式以及您願意承擔的風險
您的部署方式也會影響您採用的釋出版本(release)，這與科技公司使命不同會影響釋出版本一樣。在雲中部署意味著你可以完全控制軟體的執行環境。這樣你的詞彙表中就不必有“測試矩陣”這個詞了，它將大大地降低測試時間和bug修復量。你可以隨時更新; 分發是即時和通用的（不受客戶影響）。刪除的程式碼實際上消失了。你不必因為擔心客戶還沒有使用最新版本而去修復之前版本存在的bug。如果產品部署到客戶的裝置上（從本地移動應用程式到作業系統），釋出一次版本的一次性和未來成本將(比部署在雲端)大大提高。
- 想要可靠性？ 與其做幾個星期的壓力測試，不如釋出產品並逐漸增加負載。當遇到瓶頸時，停下來解決這個問題。
- 想要有效的測試？可以用20% 的測試發現80% 的bug ，然後快速找到並修復其它一些 bug。
- 想要設計質量？將原型投放到少量使用者並觀察它如何工作來實現快速反饋迭代。
當然，你不能僅僅因為輕鬆就選擇在雲中部署。 一些產品（作業系統或視訊遊戲機）根本不可能完全存在於雲中。如果您為移動裝置的消費者打造產品，為了提供最好的使用者體驗(UX)你很可能會選擇一個本機應用程式，因為至少對於消費者而言，豐富的使用者體驗比工程生產效率重要。我知道這聽起來很荒謬，釋出移動應用更加類似於釋出作業系統而不是web應用。這就是為什麼即使移動優先，你也希望所有移動應用的大腦都在伺服器上，這樣可以輕鬆修改它。
Facebook艱難的向移動端轉型過程說明了潛在的麻煩。Facebook的快速、個性化及設計部署軟體的迭代方式深深植根於產品團隊文化中。如果在Web層工作，釋出的成本非常接近於零，差不多所有的工作方式都基於充分利用這一假設進行了優化。隨著公司的重點轉移到本機移動應用程式，工程師們利用他們的專業知識專注於未知的流程，如功能和使用者介面凍結，功能規格和QA。
對於Facebook工程師來說，向移動轉型的難點不在於學習新的程式語言和框架，而在於他們要放棄原來開發軟體的假設。我想說基於本機移動應用限制的假設冷靜地分析各種實踐的優點、分析什麼是最好的Facebook的使用者社群都是很好的做法。實際發生的情況更像是感恩節晚餐桌上關於宗教或政治的討論。我們都是家人，但想法完全不同。
這場辯論的核心是關於容忍風險的不同假設。勇於冒險的精神深深烙刻在Facebook文化中 – 畢竟，這家公司帶給你的口號“快速移動，破除陳規！”。長期以來，Facebook工程師把擁抱風險作為一個基本的文化特質 -當時，他們沒有意識到，基於網路應用而言正確的假設的操作模式應用到移動應用上時是行不通的。
指出自己的軟體開發型別意味著必須去考慮自己的風險偏好。
創業者應該積極地承擔風險，這是一條完全理性的準則。當你沒有任何顧客、收入或者品牌的時候，錯誤是無關緊要的。你什麼都沒有，有什麼好緊張的？但是一旦有了顧客，你就需要根據造成的痛苦來定義錯誤的成本。相似型別的操作錯誤，可能導致基於不同業務及部署模式的兩家創業公司中的一家增長率下降5％而另一家增長率下降75％。如果這樣，創始人最好採用不同地方式執行公司。
在Twitter的早期，服務中斷如此常見，使用者創造了術語“失敗鯨”（由Twitter的中斷頁面上的圖形啟發）作為“又一次中斷”的縮寫。失敗鯨對於Twitter的業務不是致命的打擊， 使用者的耐心給了他們很長時間來解決它。 是的，我們搞出了很多笑話，但我們沒有離開服務。想象一下，如果一個 Salesforce這樣的公司存在“失敗鯨”的問題。他們的客戶遭遇頻繁的中斷、無法預訂收入或撥打銷售電話，那麼他們很可能不再使用這個軟體了。 客戶將使用原來計算機內建的 CRM 。當企業依靠您的軟體來完成關鍵性任務操作時，您的錯誤可能會導致他們非常痛苦。 因此，消費者業務比企業軟體業務能夠承擔更多的風險。
部署模型也有風險。當客戶遇到問題時，您解決錯誤的速度可能與錯誤有多糟糕一樣重要。您可以將熱修復程式推送到伺服器並立即為每個使用者解決問題，之後客戶便可以自己安裝補丁，您的修復速度要比通過兩週的QA視窗和App Store稽核流程以實現最小程式碼更改更為有效。 Twitter作為一個基於網路的產品很幸運，能夠解決他們在伺服器端的中斷問題。想象一下，在基於客戶端的消費產品（例如您的Apple iPhone）存在導致間歇性中斷的bug，這個bug除了下一個手機版本之外沒有其它解決方案，那這個手機可以被扔進垃圾堆了。
明確部署和風險的複雜性：如果你正在將內部執行軟體賣給企業以獲得大量資金，那麼你會要經歷痛苦的程度及冗長的更新時間的雙重考驗。你會發現，同樣的錯誤，企業軟體所要花費的成本比向消費者提供免費的基於網路的服務所要花費的成本高兩個數量級。
對世界而言，VMware顯然比Facebook更厭惡風險。這不是因為黛安·格林和馬克·祖克伯性格不同，也不是因為他們中的一個是正確的，另外一個是錯誤的。它們是基於不同技術的不同業務，他們以客戶容忍風險的程度為指導採用不同方式釋出軟體。
你的軟體釋出方式是你文化DNA的一節
現在，您已經清點了您的業務模型，部署模型和風險偏好，您已經有了一個很好的框架來分析自己使用的釋出流程。如果你已經存活了足夠長的時間來適應產品市場和一些客戶，你應該已經很自然的適應了合理的做法。在創業中，就像在自然界中一樣，形式追隨功能。你可能會驚訝的發現自己一直在浪費能量去實現一些無關緊要的目標（比如消費業務中的計劃預測）！
除了基於此框架分析您當前的方法，您還可以使用它作為過濾器，來確定可以聽取誰的建議，可以模仿哪個公司的做法，甚至僱傭哪些領導人。
當您面對多種技術或業務模型，您可能會發現此框架特別有用。初創公司可能非常需要同時支援Web和本地移動應用程式，或者多個客戶組（例如，面向消費者和企業需要不同應用程式的雙邊市場）。在理想的情況下，你的釋出過程會根據開發中的產品而變化。但你釋出的不僅僅是過程，而是文化和身份。更換一個過程很容易，改變文化卻是很困難的。對於一個小公司來說，為不同的團隊建立不同的文化更加困難。
如果你在公司裡發現多種相互衝突的“釋出文化”，你正在處理建立和釋出軟體過程中一個很困難的執行挑戰。當人們基於情感而不是理性的立場時，沒有簡單的答案。積極的一面：你的團隊熱情高漲！人們很難記住當衝突肆虐時看到的一絲希望，但這是一個工程師非常關心公司的好訊息。
深呼吸，提醒他們釋出過程來來去去，但公司的使命和價值觀是不會改變的。希望團隊能夠認同最重要的是為使用者提供最好的產品這個觀點，剩下的都是可協商的。希望這個框架能夠幫助到你。
打賞支援我翻譯更多好文章，謝謝！
打賞譯者
打賞支援我翻譯更多好文章，謝謝！
任選一種支付方式
