提效就是減少浪費(fèi)嗎？

基于現(xiàn)狀的各環(huán)節(jié)浪費(fèi)進(jìn)行分析，避免浪費(fèi)，就能達(dá)到提效的目的了么？這么說未必正確，要看目的是什么。有三種可能的目的：

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

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

即便說提效的時(shí)候，指的就是消除浪費(fèi)。如上圖所示，我標(biāo)記了 6個(gè)可能產(chǎn)生浪費(fèi)的環(huán)節(jié) 。下面逐個(gè)來說每個(gè)環(huán)節(jié)產(chǎn)生的浪費(fèi)，存在了這么長的時(shí)間都是有道理的，都沒有那么容易被“提效”。不是說每一條路都走不通，而是說不存在什么低垂的果實(shí)，都有坑。

1、產(chǎn)品經(jīng)理/UI設(shè)計(jì)師與開發(fā)者之間的交接浪費(fèi)

很多人都看到了產(chǎn)品經(jīng)理要寫一遍 PRD 稿，然后開發(fā)者照著翻譯一遍。UI 設(shè)計(jì)師要畫 UI 稿，然后前端開發(fā)要照著還原 UI。如果能夠減少這個(gè)交接環(huán)節(jié)產(chǎn)生的浪費(fèi)，讓 PRD 稿，UI 稿能直接進(jìn)入下一個(gè)環(huán)節(jié)，豈不美哉。

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

2、開源的庫和框架提供的可復(fù)用代碼太少了，做過很多中后臺(tái)項(xiàng)目，仍然有大量重復(fù)的代碼

這個(gè)浪費(fèi)是說，開發(fā)者復(fù)用的庫和框架都是非常底層非常基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)，RPC通信這些東西。做了個(gè)幾個(gè)項(xiàng)目之后，就會(huì)得出自己是 CRUD boy 的想法，覺得總這么重復(fù)下去不是辦法。如果能夠搞出幾個(gè)開源的庫和框架，那豈不是造福人類？

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

然后第二個(gè)可能的想法是滿足 80% 的需求，那剩下的 20% 讓開發(fā)者去傳參數(shù)，傳 callback，寫 patch，寫 DSL 來滿足。之前那些開源庫的作者沒有做到這一點(diǎn)，是因?yàn)樗麄儽浚▌澋簦?，是因?yàn)槲矣懈的代碼生成/組件插件技術(shù)/xxx

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

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

3、現(xiàn)有的代碼認(rèn)知負(fù)擔(dān)太大，新人要很長時(shí)間才能接手。反饋周期很長，沒法快速修改快速迭代。

觀察人是如何閱讀代碼修改代碼的，不難得出這兩個(gè)主要浪費(fèi)的點(diǎn)。

• 認(rèn)知負(fù)擔(dān)
• 反饋周期

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

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

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

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

4、同事之間的溝通成本很高，時(shí)間都浪費(fèi)在開會(huì)上了

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

這條路走下去的坑是什么？產(chǎn)品經(jīng)理是不知道你們?cè)趺床鸱帜K的。產(chǎn)品經(jīng)理看到的是這里有一個(gè)界面，誰來負(fù)責(zé)這個(gè)界面的，我找誰聊需求。產(chǎn)品經(jīng)理看到這里有一個(gè)按鈕可以點(diǎn)，是誰來處理這個(gè)按鈕點(diǎn)擊的，我找誰聊需求。但是需求往往都是“集成需求”，就是一個(gè)模塊搞不定。比如說訂單詳情頁，需要各種各樣的數(shù)據(jù)，如果這些數(shù)據(jù)都在同一個(gè)模塊里，那就達(dá)不到拆分開發(fā)的目的。如果分散到了不同的業(yè)務(wù)模塊里，那就得在界面上集成起來。

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

5、一個(gè)需求要很多個(gè)微服務(wù)一起配合修改，聯(lián)調(diào)和上線都要小心翼翼，慢慢吞吞的搞

前面說了不拆微服務(wù)，只搞代碼模塊拆分有坑。那微服務(wù)就沒有浪費(fèi)了么？

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

這條路走下去的坑是什么？沒有所謂的“一個(gè)需求”。需求的粒度是人為限定的，可粗可細(xì)。不可能達(dá)到一個(gè)需求一個(gè)團(tuán)隊(duì)來搞定的，因?yàn)樾枨缶蜎]有嚴(yán)格的定義。同時(shí)商業(yè)創(chuàng)新往往是有破壞性的，就是把之前沒有集成關(guān)系的集成起來，原來老死不相往來的東西，聯(lián)動(dòng)起來。咋調(diào)整都不可能避免團(tuán)隊(duì)之間配合的。

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

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

6、最終用戶懂自己要什么，他們可以搞得定 Excel，那我們也可以把軟件搞成 Excel 那樣，避免因?yàn)樘嵝枨笈牌谠斐衫速M(fèi)

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

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

另外一個(gè)坑是用戶只所以是用戶，因?yàn)樗麄兊谋韭毠ぷ鞑皇?ldquo;軟件開發(fā)”。如果讓用戶定制大量的邏輯，那可能工作量會(huì)大到創(chuàng)造出了“全職工作”。這個(gè)時(shí)候，用戶就不是所謂的“用戶”了。只是另外一批專職的開發(fā)者，拿著所謂的“搭建工具”，用蹩腳地方式寫代碼罷了。

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

收益總是被過度預(yù)期，成本總是被過度低估

在種種提效的努力中，看到三個(gè)常見的現(xiàn)象

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