提效就是減少浪費嗎？

基于現狀的各環節浪費進行分析，避免浪費，就能達到提效的目的了么？這么說未必正確，要看目的是什么。有三種可能的目的：

1. 減少總花費：可能人變少了，但是要開發的時間變長了。
2. 提高總吞吐：通過堆更多的人，再等同的開發時間里，交付了更多的業務價值
3. 降低延遲：通過堆更多更多的人，不在乎有多少浪費，只要能快速響應市場就可以

不同語境下說提效，其目的可能是不同的。比如對于前段時間很火的買菜業務，大家不約而同選擇的是堆更多更多的人，以降低延遲為目的，不在乎投入的方式來搞。如果為了省幾個P5的工資，導致上線開城延遲了一個月，丟掉了市場，那就不值得了。

即便說提效的時候，指的就是消除浪費。如上圖所示，我標記了 6個可能產生浪費的環節 。下面逐個來說每個環節產生的浪費，存在了這么長的時間都是有道理的，都沒有那么容易被“提效”。不是說每一條路都走不通，而是說不存在什么低垂的果實，都有坑。

1、產品經理/UI設計師與開發者之間的交接浪費

很多人都看到了產品經理要寫一遍 PRD 稿，然后開發者照著翻譯一遍。UI 設計師要畫 UI 稿，然后前端開發要照著還原 UI。如果能夠減少這個交接環節產生的浪費，讓 PRD 稿，UI 稿能直接進入下一個環節，豈不美哉。

這條路走下去的坑可能是什么？PRD 稿和 UI 稿存在的意義在于減少返工。如果沒有前一道工序，讓客戶一句話需求直接對接開發。那很有可能做出來了，就不是客戶想要的。這個時候要去改代碼，比修改 PRD 稿和 UI 稿的代價要大多了。所以 PRD 稿和 UI 稿的優點就是改起來快，沒有可運行的代碼那么多要求，可以很隨意。如果要求 PRD 稿和 UI 稿能夠直接翻譯執行，那勢必要添加語法和語義規則限制。這可能會損害“低成本可修改可討論”這個優點，產品經理和 UI 設計師要花更多的時間來讓產出物符合規范上，而不是花更多的時間和客戶討論反復修改上。

2、開源的庫和框架提供的可復用代碼太少了，做過很多中后臺項目，仍然有大量重復的代碼

這個浪費是說，開發者復用的庫和框架都是非常底層非常基礎的數據結構，RPC通信這些東西。做了個幾個項目之后，就會得出自己是 CRUD boy 的想法，覺得總這么重復下去不是辦法。如果能夠搞出幾個開源的庫和框架，那豈不是造福人類？

這條路走下去的坑可能是什么？開發者是無法反向約束客戶需求的。任意兩個客戶，即便就是 CRUD 也會有不同的細微差別。比如 list / detail 是上下，還是左右，還是彈框，還是跳頁？列表是分頁還是無限下拉，是有篩選，還是有搜索？開源庫之所以都是那些基礎的東西，就是因為那些東西共性大。稍微往靠近用戶的一側靠一些，花樣就百出。

然后第二個可能的想法是滿足 80% 的需求，那剩下的 20% 讓開發者去傳參數，傳 callback，寫 patch，寫 DSL 來滿足。之前那些開源庫的作者沒有做到這一點，是因為他們笨（劃掉），是因為我有更牛x的代碼生成/組件插件技術/xxx

這條路走下去的坑可能是什么？不討論是不是有什么牛 x 的技術就能大幅改進在已有代碼上做定制的體驗，我個人經驗是不存在這樣的技術，不管運行時的還是編譯期的，能力上都基本上等價。即便有這樣的技術，一方面寫 20% 的人至少要知道 80% 是哪 80%，他需要知道已有的庫和框架提供了什么，需求是什么，然后 diff 出 20% 的部分。然后還要知道在這個指定的庫和框架上怎么寫那 20%，沒有兩個框架提供的擴展方式是一樣的，都有自己獨特的搞法。

上世紀80年代的時候，流行組件市場的傳說。寫好業務組件，然后拿出去賣錢。但是從歷史來看，最終組件市場的形態是 github 這個最大同性交友社區。最佳的代碼復用方式是拿來主義，直接 fork 一份，在別人的代碼基礎上做修改。啥參數化，插件化，callback，都沒有直接改源代碼來得直接，好用。

3、現有的代碼認知負擔太大，新人要很長時間才能接手。反饋周期很長，沒法快速修改快速迭代。

觀察人是如何閱讀代碼修改代碼的，不難得出這兩個主要浪費的點。

• 認知負擔
• 反饋周期

認知負擔：代碼讀起來很復雜，不好理解。一份代碼要交接給另外一個人來寫，他要很長時間才能達到你之前的水平。甚至按照 Programming as Theory Building 的觀點，沒有人可以達到作者一樣的理解程度。理解一份代碼最好的方式可能是重新寫一遍。

這條路走下去的坑是什么？有的人提議，我們需要用 Event Sourcing。有的人又提議，不對，我們應該 Reactive。有的人又提議，我們應該 Structured State Machine。每個人都會提出自己所謂的“認知負擔”最低的表述方式。但是坑在于，每個人的思維習慣，過往經歷是不同的。不是所有的 GUI 都一定要 React，要 Reactive，有的人，有的項目，可能 jQuery 直接改 DOM 才是“低認知負擔”的解決方案。有一個說法是 Simple v.s. Easy，就是可能一個解決方案是 Simple 的，但是因為不是代碼的閱讀者所熟悉的模式（比如 Haskell Do Applicative），那對他來說就不是 Easy 的。編程范式這個東西，炒來炒去，就那么幾種。如果有一種顯著強與其他的，天下早就統一了。不存在什么未知的邏輯表述方式還沒有發現出來，早就被枚舉完了。

反饋周期：另外很多人也看到，修改 GUI 代碼，要很長時間才能知道改得效果是什么。如果能夠所見即所得，可以極大地縮短反饋周期，可以在同樣的時間內，修改更多次。類似的，在本地無法獲得生產環境數據，無法運行完整的代碼的情況下，需要上線或者提交到某個特殊的環境才能跑，這樣也會導致反饋周期很長。如果能夠降低認知負擔，能夠縮短反饋周期，豈不美哉？

這條路走下去的坑是什么？編程語言茫茫多，運行時平臺年年換，框架和庫城頭變幻大王旗。這些縮短反饋周期的工具和技術，都強依賴于項目使用的編程語言，運行時平臺，框架和庫。甚至還有可能要侵入到業務代碼的邏輯代碼寫法。你可以在 Python 中用 viztracer，PHP 中有么，Closure 中有么？給 Html + Vue 好不容易整了個 Vite 出來，迭代速度快了，明天業務就改成用微信小程序了，之前的技術都用不上了。

4、同事之間的溝通成本很高，時間都浪費在開會上了

大型軟件都不是一個人可以完成的。和同事的配合就要溝通開會。如果能夠讓每個人都負責一個獨立的模塊，模塊之間松耦合，各搞各的，豈不美哉？編譯的時候再把模塊代碼鏈接到一起去，變成同一個可執行文件放線上去跑。

這條路走下去的坑是什么？產品經理是不知道你們怎么拆分模塊的。產品經理看到的是這里有一個界面，誰來負責這個界面的，我找誰聊需求。產品經理看到這里有一個按鈕可以點，是誰來處理這個按鈕點擊的，我找誰聊需求。但是需求往往都是“集成需求”，就是一個模塊搞不定。比如說訂單詳情頁，需要各種各樣的數據，如果這些數據都在同一個模塊里，那就達不到拆分開發的目的。如果分散到了不同的業務模塊里，那就得在界面上集成起來。

另外出了故障算誰的？誰來查 bug？誰來發布新代碼？別人改的代碼，要合并到一起，你敢上線么？

5、一個需求要很多個微服務一起配合修改，聯調和上線都要小心翼翼，慢慢吞吞的搞

前面說了不拆微服務，只搞代碼模塊拆分有坑。那微服務就沒有浪費了么？

微服務一多，就開始有人問，為啥要拆那么多個微服務。做個需求要改那么多個微服務，不但要聯調，上線還有順序依賴。一個微服務接口只要暴露出去了，就沒法下掉了，天曉得哪里還有對它的引用。一個團隊能完整搞定一個需求多好。要么就是單體，真香。要么就是拆分不合理，要 DDD 指導微服務的邊界劃分。

這條路走下去的坑是什么？沒有所謂的“一個需求”。需求的粒度是人為限定的，可粗可細。不可能達到一個需求一個團隊來搞定的，因為需求就沒有嚴格的定義。同時商業創新往往是有破壞性的，就是把之前沒有集成關系的集成起來，原來老死不相往來的東西，聯動起來。咋調整都不可能避免團隊之間配合的。

那么合微服務，減少微服務之間的 Public API 總是可以吧。比如讓前端和后端同時發布，這樣就不需要考慮后端 API 的兼容性問題了。合并 B 端和 C 端，這樣就不用考慮 B 端沒升級，C 端升了怎么兼容的問題了。

這條路走下去的坑是什么？很多運行時平臺無法實現前端和后端同時發布。比如 iOS 需要審核，需要用戶手動確認升級。Android 也有可能沒有熱更新技術。所以客戶端就得兼容舊的版本，字段加了就是不能刪。B 端和 C 端合并，服務端可能沒人有意見。但是客戶端合并到一起，無論是說同一個web域名，還是同一個微信小程序 appid，都可能引起產品經理的強烈抗議。人們習慣了給不同的角色用戶，提供一個獨立的端。

6、最終用戶懂自己要什么，他們可以搞得定 Excel，那我們也可以把軟件搞成 Excel 那樣，避免因為提需求排期造成浪費

很多軟件都會提供一個流程圖一樣的界面，讓用戶可以去做一些流程修改或者新建一個自動化流程，減少人工重復勞動。還可能提供一些填寫數學公式的地方，讓用戶填填促銷規則。還有一些營銷頁面搭建的工具，會讓用戶直接把頁面要什么，用 Photoshop 那樣直接拖拽出來。

這條路走下去的坑是什么？如果用戶可以 100% 滿足任意的自定義需求，那么這些“用戶定制功能”，就得和專業程序員使用的工具等價。這些讓用戶表達需求的界面往往開發難度很大，需要投入很大的成本。而且未必產生了和成本對等的收益。在某些996國度，人們可能覺得提個需求讓人來做會更快一些。

另外一個坑是用戶只所以是用戶，因為他們的本職工作不是“軟件開發”。如果讓用戶定制大量的邏輯，那可能工作量會大到創造出了“全職工作”。這個時候，用戶就不是所謂的“用戶”了。只是另外一批專職的開發者，拿著所謂的“搭建工具”，用蹩腳地方式寫代碼罷了。

最大坑在于過度吹噓這種面向最終用戶，提供的定制能力，吹噓成顛覆行業的xxx。能夠快速定制的前提在于需求是固定的。只要需求超出了原先配置能力的范圍，就需要引入大量的“定制”，這些定制不管是 c# 寫 partial method，還是用 blueprint 拖拽流程圖，關鍵是在于“大量”。只要定制的量上來，量變就會引起質變。所以前提一定是砍需求，不能什么需求都滿足，才能達到提效。閉口不提需求限制，只吹噓10x提效的，都是騙子。

收益總是被過度預期，成本總是被過度低估

在種種提效的努力中，看到三個常見的現象

• 人們總是非常樂觀，這個提效手段上了之后，直接就可以 10x 哇。
• 人們又總是低估了代替現有成熟方案，模式，框架所引入的成本。這種成本投入在前半段可能完全是負產出，只有達到一定積累之后，才開始超出原有的體驗
• 不管是哪個思路去搞提效，大家都會說自己做的是“低代碼”