知道你有沒有注意到，走進各個企業，總能看到那麼幾句振奮人心的標語，其中“一次把事情做對”絕對是個高頻詞彙。以前每次看到，我都會想：這家企業也太教條了，都什麼時代了，對失敗這麼零容忍，還怎麼創新呢？這個時代的主旋律不是從錯誤中學習，快速響應、快速迭代嗎？
然而最近一年的嵌入式領域經歷，讓我重新反思並意識到，“一次把事情做對”不僅是對工作效率的追求，更是對質量控制的嚴格要求。在嵌入式產品開發領域，這一理念的重要性尤爲突出。
與Web系統相比，嵌入式產品有其獨特性。它是軟硬件的緊密結合體，不易升級，一旦發佈，出問題的解決成本異常高昂，後果更爲嚴重。所以“一次把事情做對”就是一個合理且必要的目標了。
但是怎麼做到一次把事情做對呢？我們從 4 個原則來聊聊。
不做就不錯在生活中，我們常說“不做就不錯”。在工作中，我也要把這個原則送給你，它仍然是真理。說白了就是：沒代碼，無bug。
我不是說讓大家不幹活，而是在沒搞清楚需求之前，千萬別急着動手。你想想，畫畫草圖、寫寫文檔總比直接寫代碼來得輕鬆吧？而且成本也低多了。如果錯了大不了重畫重寫，可是寫成了代碼，那就叫 bug。
你要學會拒絕需求。需求來了，你得想想這需求有價值嗎？合理嗎？如果對方說不清楚價值，給不出理由，那就應該拒絕。告訴他不要浪費你的時間和公司的金錢。
你得要求明確的需求。當業務方提出需求時，BA（需求分析師）就要分析清楚這個需求的細節，一句話的需求太模糊，沒法幹，開發者也要拒絕。這是你的權利。一旦你幹了，出了 bug 那就是你的錯。
但你可能要問了，有些需求在初期就是模糊的，只能在做的過程中慢慢摸索，那怎麼辦呢？
記住，不做就不錯，不寫代碼就沒 bug！你捫心自問，需求是模糊的，可代碼能模糊嗎？計算機只能分清0和1，根本就不會模糊處理。所以即使需求是模糊的，我們卻無法寫出模糊的代碼。如果在這種情況下寫出了代碼，必然是把模糊的東西變成了確定的東西，那大概率就寫了個bug。
正確的做法是，需求必須明確，不能模糊。如果在產品初期，摸索階段，那麼BA應該提出假設，進行驗證。提出假設後，需求就是明確的。我們假設是這種情況，代碼就這麼開發，先驗證，不斷迭代就能逐漸找到更好的答案。
這種通過假設來明確需求的方法叫試錯，你拿着模糊需求寫成不模糊的代碼，那叫 bug，這兩者的區別自己體會一下。
少做就少錯現在我們把能拒絕的工作拒絕了，把模糊的需求明確了，剩下的就是不得不做的了。接下來的第二個原則是，少做就少錯。
怎麼做到呢？千萬別急着動手寫代碼，否則你很可能要走不少彎路才能做對。這裏提供一個三步法，讓你少走彎路、少寫代碼，少出錯。
第一步，腦中做一遍。先在腦海中預演整個實現過程，這類似於一種虛擬的模擬運行。要想清楚每一步的輸入輸出是什麼，處理過程是什麼。這一步很重要，它能確保你真正理解了需求，並提前發現潛在的問題和難點。
第二步，紙上畫一遍。把腦中預演的過程在紙上畫個草圖。這個過程不僅有助於整理思路，還有助於和別人溝通討論。記住，一定要畫出來。有時候你以爲你想清楚了，畫出來才發現沒想清楚。
第三步，找人問一遍。經過前兩步，你對需求理解透了，實現方案也想清楚了。這時候要找人問一遍。這個人最好是個有經驗的人。他能對你的方案提出建議，也能發現你沒注意到的、可能對原來的功能有影響的地方。即使對方沒有經驗，也要找人問一遍。因爲在講的過程中，自己就能發現一些問題。
經過這樣三步的準備和驗證之後，就可以信心滿滿地開始編寫代碼了。這時在面對複雜問題時會從容不迫，出錯的概率也大大降低。
讓機器多幹活前面鋪墊那麼多，你可能都覺得那不是好好工作，只有寫代碼纔是真正工作。其實你寫的代碼是非常寶貴的東西。產品的價值都是靠你一行行代碼實現的。前面的鋪墊就是爲了讓你能真正寫好代碼。
現在你終於開心地寫着代碼了。這時要思考的是自己怎麼少幹活，怎麼讓機器多幹活。畢竟，不做就不錯，少做就少錯。
這裏我們暫且不提讓AI來幫你寫代碼。想想在開發過程中，哪些工作是可以交給機器來做的呢？
開發的工作可以分爲三大塊：看代碼、寫代碼、調試驗證。
驗證對你來說既無聊又耗時間。你打着斷點，看着變量是不是你想要的值，邏輯跳轉對不對。這樣的工作不停地重複着，有時候一擡頭髮現周圍人都走光了，一天很快就過去而你還沒定位到問題。
驗證這部分是最容易交給機器來做的。完全可以寫個驗證代碼（測試代碼）來驗證程序的輸出對不對，是不是想要的結果。這是個一勞永逸的方法。驗證代碼只要寫一遍，它就在那裏，孜孜不倦一遍遍運行着。你完全可以放心交給它幫你完成驗證的工作。再進一步，甚至可以先寫驗證代碼，再寫業務代碼，這就是極限編程中的測試驅動開發（TDD）。
機器還可以幫你幹其它活，那些重複的活都可以讓它幹。所以這第三個原則“讓機器多幹活”還有另一個名字：自動化一切能夠自動化的工作。
比如你的軟件的構建，部署，一切能夠自動化的工作，都應該交給機器來做。因爲人都是會犯錯誤的。
早糾錯、少浪費前面三個原則講的都是儘量地少幹活，但只要幹了活，就可能出錯。所以最後這個原則是“早糾錯、少浪費”，怎麼儘早地發現錯誤，減少浪費。
對於產品研發來說，最大的浪費是返工。因爲功能做得不對返工，因爲質量問題返工，這些都會造成品牌受損，成本增加。
問題發現得越晚，成本越高。所以我們要通過一切手段儘早糾錯。極限編程提供了一個很好的參考機制：
-
分鐘、小時級別的反饋：通過結對編程、自動化測試、流水線完成
-
天級別的反饋：每日站會、每個需求的驗收測試
-
周級別的反饋：每個迭代的showcase
-
月級別的反饋：版本發佈後的反饋
（圖片來自網絡）
如果我們能建立極限編程這樣的從分鐘到月級別的多維度反饋機制，就能夠在早期階段及時察覺問題、糾正錯誤，從而顯著提高工作質量並減少不必要的浪費。
總結質量就是生命線！
基於嵌入式產品由於其自身特點，“一次把事情做對”是每個研發人員的追求。通過文中介紹的四個原則和相應的實踐，建立多維度的反饋機制，你就能夠最大化實現質量的提升和資源的充分利用。
來源：thoughtwork公衆號