馬斯克談產品研發過程可能犯的錯誤

今天下午看到一個 2021 年 Elon Musk 接受專訪的影片：https://www.youtube.com/watch?v=t705r8ICkRw

裡頭提到蠻多產品開發的觀念，包含需求、分工，以及工程師的職責，我個人認為非常值得一看，以下我幫大家摘要了部分我有感觸的內容。

讓你的需求更簡潔

簡化需求，而非複雜化需求，許多工程師會傾向於增加需求或規格，但真正好的做法應該是減法。這個減法理論從 Steve Jobs 到 Elon Musk 都非常推崇，我個人也認為是很關鍵的議題。

在一個產品中，增加東西是容易的，但往往會增加複雜度，當我們總想著增加時，思考解決問題方法時，我們往往只有「增加」這個方向，而不會想著「減少」與「重新設計」。這其實也是所有技術債的成因之一。

而習慣用加法的產品，很容易模糊了產品的焦點。

當產品核心功能不具備競爭力時，很多產品團隊會開始想給客戶更多，而更多經常意味著失焦，A 客群需要的主要功能沒法滿足，卻老想著用其他次要功能來填補，卻沒想過，即便次要功能再怎麼多，也很難讓客戶滿意。

給更多，這是一種人性在面對批評與挑戰時的慣性，但卻不利於產品發展。

別複雜化問題

過去碰過許多工程師，老喜歡將自己置身於複雜問題之中，舉個例子來說。

當今天要改技術債問題時，他可能會告訴你，要解決這個問題，需要改 10 個地方，而且會改到底層，而這些底層元件目前是由 N 個部門負責，然後這些部門的 PM 有好幾個都是直接對業務主管匯報。然後會順帶一提，這個問題以前也改過，但失敗了，失敗的原因是沒有任何業務主管支持。

我們可以看到，一個簡單的技術問題，到最後演變成一個複雜的問題。如果這時候我們立刻跳進來解決這問題，你就得處理一大堆政治問題、優先級問題與真正要處理的技術問題。

但過去我的經驗，我通常是要工程師告訴我 - 技術問題怎麼處理，剩下的問題我來解決。

當我今天只討論技術面的議題時，解法是什麼通常很明確，我們先針對技術面的議題做討論，就能明確所需要的資源與可能的風險。而當資源跟風險明確了，要去找人討論自然就簡單許多。

可當我們被一堆非技術問題卡住時，我們連仔細評估技術問題的時間都沒花，那還談什麼解決問題呢。

別花力氣解決不存在的問題

這個段落很短，但我覺得很有趣，在馬斯克眼中，有很多問題根本不存在。而他所謂的不存在指的並不是沒這問題，而是這問題根本不值得討論跟花時間。

什麼樣的問題不值得討論呢？就是當你選擇減法時，當條件改變，原先的問題就不再重要了，所以解決問題時，應該先思考能否透過減法來讓問題變簡單，我們應該專注於解決更簡單、更單純的問題，而非複雜的問題。

如果本來我們要又快、又好、又便宜，那我們要在一個高科技產品的早期同時滿足以上三項條件，那解法肯定非常難。但如果今天老闆認為便宜這個條件不必存在，他只要又快、又好，那你完全可以想出一個成本較高，但能解決問題的方法。

所以馬斯克有特別提到，不要在一開始就跳進問題中，然後開始做最佳化，而是先做減法，刪到只剩必要的部分，此時才開始解決問題，才開始進行最佳化。

先減法，解決問題，而後最佳化，而非立即跳入最佳化的思考。最佳化之後，則是自動化。

他舉了幾個 SpaceX 跟 Tesla 的例子：

開發 SpaceX 的火箭時，決定不折疊翼面(grid fin)，因為這是一個不必要的機制。

開發特斯拉 Model 3 時，發現車身底部的玻璃纖維墊是多餘的，因此將其刪除，節省了成本和時間。

在生產線上進行過多的流程中測試也是一個錯誤，因為這會降低生產效率。

你會發現，他解決問題的本質，一直都是簡化與減法。

這一段他還提到學校教育，他說學校教育老是要我們去解一個不存在，假設出來的問題。甚至不允許你去反駁教授或老師，如果你跟教授說：「你這個問題沒有意義，根本不會發生。」你可能會被當掉。

這超級寫實，其實在公司也是如此。

對基礎問題提出質疑

馬斯克提到，早期他的專業能力不如那些在火箭領域浸淫許久的專家，但他還是針對「翼面(grid fin)需要可折疊的假設」提出了質疑。

也就是當專家們陷入過往經驗的陷阱時，他提出了一個專家不再考慮的問題，但最後火箭卻因此拆除了折疊機制而簡化了設計。

這問題我也超有感，過往每次在跨領域或進到一個新環境時，總會有人說「這件事就是如此」、「你過去不是這領域的可能不懂」、「這是行業的常態」。

但我也經常問這些人：「如果這是一個必然的事實，那請問其他人是怎麼解決的？」

如果其他人都能解決，這就代表這件事不是必然，既然不是必然，那肯定我們過往的假設出了問題。

責任必須到人而非部門

提到工程需求必須對應到個人而非部門，是因為他認為這樣才能確保需求的合理性和責任歸屬。

這個段落他隨口帶到，有時需求可能是很久以前某位實習生的隨口提議，但這個實習生早已離開公司，但現在部門裡也沒有人認可或支持這個需求。

如果需求來自於部門，接收需求的也是部門而非人，那可能會出現沒有人真正為這個需求負責的情況。

而如果工程師不質疑需求的來源，也沒有人負責解釋這個需求，最後就會盲目地執行，浪費時間和資源在不必要的優化上。

透過將需求與個人連結，可以確保每個需求都有明確的負責人，這個人必須能夠解釋需求的必要性，並為其負責。這樣可以避免工程師陷入「優化不該存在的東西」的陷阱。

工程師需要有「總工程師」的思維

工程師常陷入一種迷思，就是專注於優化單一零件或步驟，而忽略了系統層級的問題。

舉例來說，SpaceX 的工程師花了很多心力降低引擎重量，卻沒有花太多心思減少推進劑殘留。結果火箭降落時，仍然攜帶著大量未使用的燃料。

雖然一噸燃料看似不多，但相較於工程師為減輕引擎重量所付出的努力，或許直接優化燃料會比優化引擎更容易。這是局部最佳化常見的問題。

也是為何我們常說，開發系統要能看見全貌，要能掌握脈絡。

如果每個人都能像「總工程師」一樣，從系統層級去理解問題，就能避免這種見樹不見林的錯誤。唯有每個工程師都了解系統的全貌，才能做出對整體最佳的決策，而不是只顧著優化自己負責的那一小部分。

很多時候，解決問題的方法遠比想像的更簡單，可我們經常被技術之外的問題給困住了，因此複雜化了問題。

當我們願意回歸基礎，挑戰基本假設，對問題進行減法，解決問題或許就沒那麼困難了。

如果你覺得我內容寫得還不錯，歡迎訂閱我的電子報，我每雙週會發送一封電子報到你的信箱。訂閱連結在這，過往的電子報也在這：Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們，也許你的舉手之勞，將會改變另一個人的思維與習慣。