去年年底我重讀了一遍《少即是多北歐自由生活意見》。這本書買回來三年第一遍讀完只記住了“雙城生活”四個(gè)字覺得那離一個(gè)天天寫代碼、對需求、趕進(jìn)度的互聯(lián)網(wǎng)人太遠(yuǎn)了。今年再翻完全不是那么回事。在一個(gè)既要寫接口又要排需求還要背進(jìn)度的環(huán)境里這本書講的其實(shí)根本不是北歐人的慢生活而是你我每天都在面對的優(yōu)先級(jí)問題——什么該做什么不該做什么才是真正值得投入的事。這本書的作者本田直之在書里反復(fù)強(qiáng)調(diào)一個(gè)觀點(diǎn)從物質(zhì)中獲得的幸福感是短暫的而從體驗(yàn)、時(shí)間、自我成長中獲得的幸福感才是持久的。聽起來像是雞湯但如果你把“物質(zhì)”換成“功能”“需求”“會(huì)議”“技術(shù)?！卑选绑w驗(yàn)”換成“用戶價(jià)值”“核心目標(biāo)”“代碼質(zhì)量”“個(gè)人時(shí)間”這套邏輯幾乎可以直接套用到程序員、產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理的日常里。所以我特別想從這三個(gè)角色出發(fā)聊聊這本書到底能給我們這些做產(chǎn)品做技術(shù)的人帶來什么。文章不打算寫書評也不做讀書筆記摘抄。我會(huì)把書里那些“北歐味”很重的概念翻譯成我們每天開工就能用得上的決策方法和實(shí)操動(dòng)作。你可能是后端、是前端、是產(chǎn)品新人也可能是帶項(xiàng)目的負(fù)責(zé)人只要你的工作內(nèi)容里存在“需求堆積”“多任務(wù)切換”“流程臃腫”“工具過?！边@些癥狀這篇內(nèi)容就是寫給你的。1. 這本書到底在講什么從“雙城生活”到“新幸福”1.1 三個(gè)關(guān)鍵詞把我的觀念撬動(dòng)了第一個(gè)關(guān)鍵詞是“雙城生活”。書里說北歐人流行在都市有一套小公寓用于工作在鄉(xiāng)下有一棟木屋用于生活每周來回切換。過去我覺得這建議不現(xiàn)實(shí)一線城市一套房都難還兩套房但后來想明白了本田直之想講的不是“買兩套房”而是“讓生活擁有兩種節(jié)奏”。對應(yīng)到互聯(lián)網(wǎng)行業(yè)很多團(tuán)隊(duì)已經(jīng)開始這么干了周一到周四在辦公室集中協(xié)作周五全員遠(yuǎn)程或者一天里固定幾個(gè)小時(shí)的深度編程時(shí)段不排任何會(huì)議其他時(shí)間用來溝通對接。這就是一種精神上的“雙城”——把工作節(jié)奏和生活節(jié)奏分開而不是用加班把所有時(shí)間填滿。第二個(gè)關(guān)鍵詞是“新幸?！?。書中列了十條“新幸?！钡臈l件包括享受工作、有親密的朋友和家人、穩(wěn)定的經(jīng)濟(jì)來源、身心健康、擁有能激發(fā)創(chuàng)造力的興趣愛好、擁有時(shí)間和自由、能選擇適合自己的居住環(huán)境、具備有效的思維習(xí)慣、能放眼未來、感覺自己正在向目標(biāo)邁進(jìn)。有意思的是這十條里沒有一條是“擁有更大房子”或“買更貴的車”。放在我們行業(yè)里翻譯一下很多人追求“技術(shù)棧最全”“跳槽薪資最高”“App功能最多”但這些東西帶來的滿足感衰減極快。反而是“擁有一項(xiàng)別人替代不了的手藝”“每天有幾個(gè)小時(shí)不被打擾的深度工作時(shí)間”“團(tuán)隊(duì)里人際關(guān)系簡單干凈”這些才真正決定你在這行能走多遠(yuǎn)。第三個(gè)關(guān)鍵詞是“從加法到減法”。書里有個(gè)說法我印象很深日本和北歐都經(jīng)歷過物質(zhì)過剩的時(shí)期但北歐人最先意識(shí)到東西越多打理東西的時(shí)間也越多人被物拖住了?；ヂ?lián)網(wǎng)產(chǎn)品也是一樣系統(tǒng)里每多一個(gè)功能就多一份維護(hù)成本、多一批用戶疑惑、多一段測試用例團(tuán)隊(duì)里每多一個(gè)流程就多一次溝通損耗、多一層等待時(shí)間。做加法是本能做減法是能力。1.2 這本書的局限北歐經(jīng)驗(yàn)不能照搬當(dāng)然這本書不是萬能的。北歐的高福利社會(huì)、極低的貧富差距、漫長的冬季塑造了那種“慢文化”直接搬到國內(nèi)職場很容易變成“何不食肉糜”。你不可能在工作日報(bào)還沒寫完的時(shí)候跟領(lǐng)導(dǎo)說“我要降低滿足閾值”。所以讀這本書的正確姿勢是不要照搬它的生活方式而是提取它的底層方法論。我把這本書的方法論總結(jié)成一句話**在所有選項(xiàng)里先去掉那些“不做什么也不會(huì)死”的部分把省下來的時(shí)間、精力、資源集中投給三件以內(nèi)真正重要的事。**這個(gè)方法論放在代碼重構(gòu)、需求評審、項(xiàng)目排期、職業(yè)規(guī)劃里全部成立。接下來的篇幅我就分別從程序員、產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理三個(gè)視角展開講這套方法論怎么落地。2. 程序員視角少即是多的“代碼人生”2.1 給技術(shù)棧做減法真正吃飯的手藝不超過三門程序員大概是這個(gè)世界上最容易陷入“技術(shù)棧軍備競賽”的群體。我見過不少簡歷寫著“熟悉 Java、Go、Python、Vue、React、Flutter、Kubernetes、Docker……”數(shù)量多到讓人懷疑一天有48小時(shí)。但一問深了每個(gè)技術(shù)都停留在“用過”的層面。這其實(shí)違反了“少即是多”最樸素的原則一個(gè)人的深度專注力是有限的你鋪得越開每一層的厚度越薄。書里對應(yīng)的觀點(diǎn)是“只有一項(xiàng)技能的人反而更強(qiáng)”。本田直之說的不是“只會(huì)一項(xiàng)就夠”而是“以一項(xiàng)核心技能為根再延伸出枝葉”。放在程序員身上我的建議是選定一門主語言作為安身立命之本把它的底層原理、常用框架、性能調(diào)優(yōu)、排錯(cuò)思路吃透再花20%的精力去拓展第二個(gè)相關(guān)技能。比如你是Java后端那就先把JVM內(nèi)存模型、并發(fā)編程、Spring的Bean生命周期這些東西徹底搞明白而不是今天看Go的教程明天收藏Rust的入門后天又去刷“大模型應(yīng)用開發(fā)”的課。我見過一個(gè)后端同事三年時(shí)間把所有流行技術(shù)都“試”了一遍簡歷很好看但每次團(tuán)隊(duì)遇到線上OOM他永遠(yuǎn)是排查最慢的那個(gè)人。反而是另一個(gè)只精通Java、但把《深入理解Java虛擬機(jī)》翻爛了的同事幾次性能優(yōu)化都靠他救火。這就是深度碾壓廣度的典型場景。技術(shù)棧的“少”不是讓你不學(xué)習(xí)新東西而是在學(xué)習(xí)新東西之前先確認(rèn)舊的東西里有沒有值得挖到根的部分。2.2 給代碼做減法少寫代碼比多寫代碼難得多我看過一句話大意是“代碼行數(shù)是負(fù)債不是資產(chǎn)”。第一次寫某個(gè)功能可能只要50行后來加需求變成150行再加分支變成400行還帶三層if嵌套。每次改代碼的人都在原有邏輯上疊新的判斷沒人敢刪因?yàn)椴恢绖h了會(huì)影響哪些調(diào)用方。到最后一段業(yè)務(wù)邏輯復(fù)雜到?jīng)]人愿意碰只能推倒重來?！吧偌词嵌唷痹诖a層面的第一個(gè)實(shí)踐是抽象與復(fù)用。但注意抽象不是越早越好。我早期的經(jīng)驗(yàn)是先寫一個(gè)具體實(shí)現(xiàn)跑通業(yè)務(wù)然后再看第二個(gè)類似需求長什么樣當(dāng)?shù)谌齻€(gè)出現(xiàn)時(shí)才考慮抽公共邏輯。太早抽象會(huì)造出“萬能類”參數(shù)越加越多最后比不抽象還難維護(hù)。這就是“少做一步反而更快”的反直覺之處。第二個(gè)實(shí)踐是刪除代碼要有儀式感。刪代碼不是不負(fù)責(zé)任恰恰是最負(fù)責(zé)任的行為。每次刪掉一段不再使用的代碼我習(xí)慣做兩件事先查調(diào)用鏈確認(rèn)沒有入口再通過代碼檢索工具全局搜一遍關(guān)鍵字。確認(rèn)無引用后刪除并順手看看有沒有相關(guān)的測試用例需要一起清掉。這個(gè)過程聽起來繁瑣但一次完整的清理后續(xù)每次讀代碼都會(huì)省時(shí)間——這才是“少”的長遠(yuǎn)回報(bào)。第三個(gè)實(shí)踐和“人工智能輔助編程”有關(guān)。最近行業(yè)里討論很多不少團(tuán)隊(duì)引入AI輔助開發(fā)后生產(chǎn)率確實(shí)上來了但問題也隨之而來AI生成的代碼大量復(fù)制粘貼進(jìn)倉庫很多方法根本沒人知道是干嘛的。代碼量暴增維護(hù)難度飆升。這時(shí)候“少即是多”反而成了更稀缺的品質(zhì)**AI幫你快速生成10個(gè)方案你依然要花力氣判斷哪個(gè)方案該留下、哪些代碼不該進(jìn)倉庫。**AI是加速器不是判斷器。2.3 副業(yè)、裝備與數(shù)字雜物把“占有”換成“使用”書里有一個(gè)很尖銳的觀點(diǎn)你擁有的東西其實(shí)也在擁有你。筆記本電腦、機(jī)械鍵盤、4K顯示器、開發(fā)機(jī)、測試機(jī)、iPad、各種云服務(wù)訂閱——這些東西真的是生產(chǎn)力嗎還是只是“擁有了就感覺自己在成長”的錯(cuò)覺先說iPad這個(gè)話題。網(wǎng)上經(jīng)常有人問“作為程序員iPad有什么用”。實(shí)話實(shí)說iPad在絕大多數(shù)程序員的日常里既不能替代電腦寫代碼也不能替代手機(jī)做即時(shí)通訊。但它確實(shí)可以做三件有價(jià)值的事看技術(shù)文檔和PDF時(shí)不用開電腦、用手寫筆畫系統(tǒng)架構(gòu)草圖、在通勤時(shí)看視頻課。核心不是“該不該買iPad”而是“你買了之后有沒有真的用它做這些事”。如果買回來只是刷視頻蓋泡面那它就是書里說的“被物質(zhì)拖住”。反向操作也成立——如果你沒有iPad但每次畫架構(gòu)圖都靠白板和手機(jī)拍照那完全沒必要為了“儀式感”添一個(gè)設(shè)備。再說程序員副業(yè)。熱詞里經(jīng)常出現(xiàn)“程序員副業(yè)圖譜”好像不搞副業(yè)就不配叫程序員。但書里的“只有一項(xiàng)技能”提醒我副業(yè)不是越多越好而是從主業(yè)的長尾里長出來。你后端寫得好可以接接口開發(fā)的私活你前端寫得好可以做獨(dú)立開發(fā)者的接單方你文檔能力強(qiáng)可以錄課和寫技術(shù)專欄。每一條副業(yè)都和主技能共享同一根樹干而不是你今天學(xué)剪輯、明天做電商、后天開網(wǎng)店。我見過搞了五個(gè)副業(yè)的人最后主業(yè)差點(diǎn)沒保住五個(gè)副業(yè)加起來賺的還不如加班費(fèi)多。這就是把“加法”用錯(cuò)了地方。數(shù)字雜物也是同樣的道理。網(wǎng)盤里囤了幾百個(gè)G的課程、瀏覽器收藏夾里塞滿“程序員魚皮推薦的學(xué)習(xí)路線”、GitHub上Star了一堆項(xiàng)目但從未打開過——這些都符合書里說的“物質(zhì)過剩時(shí)代的新貧窮”。我給自己定過一個(gè)規(guī)矩收藏夾每周清理一次超過30天沒打開過的課程直接刪掉。一開始肉疼后來發(fā)現(xiàn)真正需要的東西當(dāng)你需要時(shí)自然能找到那些刪了也不心疼的本來就對你沒有價(jià)值。3. 產(chǎn)品經(jīng)理視角需求池里的斷舍離3.1 需求攢得越多產(chǎn)品死得越快產(chǎn)品經(jīng)理的日常工作本質(zhì)上是和“加法思維”作斗爭。業(yè)務(wù)方提一個(gè)需求用戶反饋一個(gè)建議競品出了一個(gè)新功能老板拍了一個(gè)新方向——全都堆進(jìn)需求池池子越來越滿。但需求池不是收藏夾它是一個(gè)資源分配決策入口。每個(gè)需求進(jìn)入池子都意味著開發(fā)資源要被占用、產(chǎn)品復(fù)雜度要上升、測試范圍要擴(kuò)大。池子里堆需求就像衣柜里堆不穿的衣服你以為你在積累財(cái)富其實(shí)你在積累熵。書里教我的第一個(gè)方法是給需求池設(shè)置物理上限。衣柜如果只能掛50件衣服那每添一件新衣服就必須扔一件舊衣服。需求池同理同時(shí)進(jìn)行的項(xiàng)目級(jí)需求不超過3個(gè)功能級(jí)需求在“待排期”狀態(tài)下不超過20個(gè)。超出上限時(shí)新需求必須先頂?shù)襞f需求而不是無限追加。這個(gè)規(guī)則逼著所有人做判斷那個(gè)“三個(gè)月沒動(dòng)靜的需求”是不是該刪了那個(gè)“客戶說要但其實(shí)不用也能活”的需求是不是可以直接拒掉?第二個(gè)方法是區(qū)分“want”和“need”。用戶嘴上說要一個(gè)“導(dǎo)出Excel”的功能真實(shí)需求可能是“每周要手動(dòng)統(tǒng)計(jì)數(shù)據(jù)太麻煩”而你的系統(tǒng)已經(jīng)有“定時(shí)報(bào)表推送”的能力。那你要做的就不是新增導(dǎo)出功能而是引導(dǎo)用戶使用已有能力。少即是多在這里非常具體功能入口越少用戶學(xué)習(xí)成本越低每個(gè)新增按鈕都在稀釋其他按鈕的注意力。3.2 接口對接與AIGC時(shí)代的“偽需求制造機(jī)”我特別想聊一下接口對接這個(gè)場景因?yàn)檫@是后端程序員和產(chǎn)品經(jīng)理天天相愛相殺的地方。Java后端工程師最怕產(chǎn)品經(jīng)理拿著一份接口文檔過來里面躺著八個(gè)字段、三個(gè)狀態(tài)位、兩個(gè)冗余參數(shù)。產(chǎn)品經(jīng)理說“這些字段以后都用得上”后端說“現(xiàn)在業(yè)務(wù)里根本用不到”。從“少即是多”的角度產(chǎn)品經(jīng)理應(yīng)該從一開始就想清楚這個(gè)接口的核心目的是什么支撐這個(gè)目的的最小字段集是什么比如一個(gè)用戶列表接口業(yè)務(wù)方說需要返回用戶ID、昵稱、頭像、手機(jī)號(hào)、郵箱、注冊時(shí)間、最近登錄時(shí)間、訂單數(shù)量。但實(shí)際頁面上只展示昵稱、頭像和注冊時(shí)間。那這個(gè)接口就只需要返回三個(gè)字段其他字段全部不進(jìn)接口文檔。如果以后真有需求再擴(kuò)展也不遲。接口擴(kuò)展的成本遠(yuǎn)低于接口臃腫帶來的長期維護(hù)成本。后端同學(xué)在評審時(shí)可以大膽問一句這個(gè)字段當(dāng)前哪個(gè)頁面在用如果沒有頁面引用就砍掉。這不是不配合這是負(fù)責(zé)。再往后看AIGC工具普及以后產(chǎn)品經(jīng)理的“偽需求制造”能力被放大了。以前寫需求要一個(gè)字一個(gè)字敲現(xiàn)在用AI一句話就能生成一份完整的需求文檔、原型描述、甚至接口字段定義。速度上來了但很多被生成出來的需求根本沒有真實(shí)用戶場景。我看到過一份AI生成的需求文檔功能描述、交互流程、埋點(diǎn)方案一應(yīng)俱全唯獨(dú)回答不了“這個(gè)功能解決誰在什么場景下的什么問題”。這就是典型的“工具提升了產(chǎn)出數(shù)量掩蓋了判斷缺失”。產(chǎn)品經(jīng)理在AIGC時(shí)代的核心競爭力恰恰是“少即是多”里的這個(gè)“少”——你必須在AI生成的十個(gè)方案里敢于也只挑一個(gè)上線的。3.3 產(chǎn)品新人的第一課不是畫圖是舍棄現(xiàn)在各種產(chǎn)品經(jīng)理培訓(xùn)機(jī)構(gòu)都在教畫原型、寫PRD、做競品分析但很少教“如何砍掉一個(gè)功能”。新人最容易犯的毛病是接到的每個(gè)需求都想做方案評審時(shí)誰提意見都接受結(jié)果需求越滾越大版本越拖越長最后哪個(gè)都沒做好。我建議產(chǎn)品新人給自己立一條規(guī)矩**每個(gè)版本上線前主動(dòng)刪掉20%的功能再提測。**這個(gè)比例不一定精確但目的很明確——逼自己按用戶價(jià)值和開發(fā)成本給所有功能排序砍掉排在最末位的那些。你會(huì)發(fā)現(xiàn)一個(gè)殘酷的事實(shí)砍掉的那20%功能上線一周后幾乎沒人提起。用戶沒感知業(yè)務(wù)沒投訴產(chǎn)品反而更流暢了。這就是“均值回歸”在產(chǎn)品里的體現(xiàn)——大多數(shù)功能本來就是平庸的它們不是在解決問題而是在制造噪音。書里說“降低滿足的閾值才能體會(huì)到小的喜悅”。產(chǎn)品經(jīng)理如果把“滿足”的對象從“功能數(shù)量”換成“用戶問題的解決程度”很多糾結(jié)就不存在了。一個(gè)順暢的核心流程勝過十個(gè)能用但別扭的次要功能。4. 項(xiàng)目經(jīng)理視角流程和會(huì)議的雙重減負(fù)4.1 會(huì)議減半把同步從會(huì)議室搬到文檔里項(xiàng)目經(jīng)理大概是全公司最愛開會(huì)的人因?yàn)槲覀兲烊槐池?fù)著“信息同步”的責(zé)任。但絕大多數(shù)會(huì)議的信息密度低得可怕。周一的排期會(huì)20分鐘的時(shí)間花在“我上周干了什么”上周五的復(fù)盤會(huì)半小時(shí)都在討論細(xì)枝末節(jié)。書里講北歐人“固定時(shí)間結(jié)束工作”是一種能力放在項(xiàng)目管理場景里就是“固定會(huì)議時(shí)長并嚴(yán)格限制議題范圍”的能力。我實(shí)操過的一個(gè)有效動(dòng)作是把周五的同步會(huì)取消改成異步周報(bào)。要求每個(gè)成員在共享文檔里更新三件事本周完成、下周計(jì)劃、需要他人協(xié)助的阻塞點(diǎn)。有阻塞的人自己約相關(guān)同事開15分鐘小會(huì)沒有阻塞的人連見面都不需要。一個(gè)10人團(tuán)隊(duì)每周省下至少50個(gè)人時(shí)而且信息反而更清晰——因?yàn)閷懳臋n之前每個(gè)人都必須自己梳理一遍。會(huì)議減半的第二個(gè)實(shí)操是“站立會(huì)限時(shí)15分鐘”。很多團(tuán)隊(duì)的站會(huì)變成了匯報(bào)會(huì)每個(gè)人都把昨天的細(xì)節(jié)講一遍。我的原則是**站會(huì)只回答三個(gè)問題——今天打算做什么、有什么卡住我的、需要誰在會(huì)后幫我。**不展開討論所有延伸話題拉出去單獨(dú)約。這符合書里“減去冗余、保留本質(zhì)”的準(zhǔn)則站會(huì)的本質(zhì)是暴露風(fēng)險(xiǎn)不是匯報(bào)工作。4.2 任務(wù)看板的“WIP上限”同時(shí)只做三件事項(xiàng)目管理里有個(gè)概念來自精益生產(chǎn)叫做“WIP上限”Work In Progress在制品數(shù)量上限。這個(gè)概念和《少即是多》的底層邏輯驚人一致同時(shí)進(jìn)行的任務(wù)越多單個(gè)任務(wù)的完成周期越長整體效率反而越低。我見過最典型的低效團(tuán)隊(duì)是這種狀態(tài)看板上有十幾個(gè)進(jìn)行中的任務(wù)需求方催一下A就做一下A催一下B又切到B所有人都在救火但沒有任何功能真正完成上線。后來我把看板的“進(jìn)行中”列做了硬性限制——每個(gè)成員同時(shí)只允許有兩個(gè)任務(wù)一個(gè)開發(fā)中、一個(gè)測試中超出的新任務(wù)一律進(jìn)入“待排期”前面不空出來后面就不準(zhǔn)動(dòng)。剛推行時(shí)業(yè)務(wù)方意見很大覺得“明明有現(xiàn)成的人力為什么不做”。一個(gè)月后數(shù)據(jù)打臉需求平均完成周期從兩周縮短到五天上線功能數(shù)反而多了。這和書中“從加法到減法”的論述完全互文你以為多做并行任務(wù)是在“提速”實(shí)際上每次切換都在支付“上下文切換稅”。程序員從寫代碼的狀態(tài)切到評審需求再切回寫代碼光重新進(jìn)入狀態(tài)的成本就有十幾分鐘。把并行數(shù)限制下來等于直接消滅了這種隱性消耗。4.3 風(fēng)險(xiǎn)管理的樸素化非必要不新增項(xiàng)目經(jīng)理還有一個(gè)職業(yè)病就是風(fēng)險(xiǎn)焦慮。我們總想為所有可能的意外提前準(zhǔn)備Plan B、Plan C于是項(xiàng)目計(jì)劃里塞滿了“預(yù)保留時(shí)間”“備選方案”“冗余資源”。但書里有個(gè)觀點(diǎn)點(diǎn)醒了我你為未來做的很多準(zhǔn)備未來根本不會(huì)用到而準(zhǔn)備的本身已經(jīng)消耗了現(xiàn)在的精力。我現(xiàn)在的做法是給風(fēng)險(xiǎn)分級(jí)P0級(jí)別的風(fēng)險(xiǎn)上線失敗、核心成員離職、數(shù)據(jù)丟失必須做預(yù)案P1級(jí)別的風(fēng)險(xiǎn)第三方接口延遲、個(gè)別需求變更做簡單的備選方案P2級(jí)別的小風(fēng)險(xiǎn)某個(gè)字體不兼容、某個(gè)頁面加載慢不做預(yù)案遇到了再處理。很多項(xiàng)目經(jīng)理習(xí)慣把所有風(fēng)險(xiǎn)都拉到一個(gè)級(jí)別每個(gè)人都繃著弦反而分散了對真正關(guān)鍵路徑的投入。這就是把“少”用在刀刃上真正的風(fēng)險(xiǎn)管理不是消除所有風(fēng)險(xiǎn)而是把有限的注意力集中到極少數(shù)能決定項(xiàng)目生死的事情上。團(tuán)隊(duì)管理也一樣。書里說“幸福來自愉悅與專注”項(xiàng)目經(jīng)理與其給團(tuán)隊(duì)不斷加激勵(lì)、搞團(tuán)建、發(fā)福利不如先做減法減掉不必要的過程文檔、減掉重復(fù)的匯報(bào)、減掉形式化的評審。員工最需要的是專注干活不被打擾的時(shí)間。我發(fā)現(xiàn)當(dāng)一個(gè)團(tuán)隊(duì)從每周五個(gè)會(huì)減到兩個(gè)會(huì)成員主動(dòng)加班的情況反而變少了——因?yàn)樗麄儼滋炀湍茏鐾晔虏恍枰砩蟻硌a(bǔ)白天的會(huì)議債。5. 落地時(shí)會(huì)踩的坑把“少”做成“更忙”5.1 問題一做了減法卻被考核綁架很多人讀完這類書心潮澎湃回公司就把需求砍了、會(huì)議減了結(jié)果季度績效考核下來發(fā)現(xiàn)指標(biāo)是“上線功能數(shù)”于是被打回原形。這個(gè)問題很現(xiàn)實(shí)。解決思路不是讓你對抗考核體系而是用數(shù)據(jù)證明“少”帶來了更好的結(jié)果。比如你砍掉了三個(gè)低頻功能換來了核心流程的崩潰率下降50%這就是可以寫進(jìn)績效報(bào)告的成績。當(dāng)你把“少即是多”翻譯成指標(biāo)語言——需求響應(yīng)速度、缺陷密度、項(xiàng)目延期率、核心功能使用率——管理層是能看懂“減法”的價(jià)值的。怕的只是你砍了功能但沒有建立度量體系做了好事卻拿不出證據(jù)。5.2 問題二把“少即是多”理解成低標(biāo)準(zhǔn)我見過一些朋友把書里的“降低滿足閾值”當(dāng)成“差不多得了”的擋箭牌。需求只出簡單方案代碼能跑就行文檔能不寫就不寫。這不是減法這是偷懶?！吧偌词嵌唷睆膩聿皇墙档蜆?biāo)準(zhǔn)而是提高對“重要”的判斷標(biāo)準(zhǔn)對重要的事保持高標(biāo)準(zhǔn)對不重要的事干脆不碰。程序員如果砍掉代碼評審、砍掉單元測試那不是在做減法是在給自己埋雷。正確的減法應(yīng)該是不做“偽需求”的功能但核心流程必須做到極致不寫“記錄流水賬”的日志但關(guān)鍵鏈路必須埋點(diǎn)完整。瘦身減的是脂肪不是骨頭。5.3 問題三只有自己減其他人還在加個(gè)人做減法相對容易難的是團(tuán)隊(duì)協(xié)作里別人不配合。你取消了周五同步會(huì)隔壁組每周五還是拉你評審你砍了自己負(fù)責(zé)模塊的兩個(gè)字段新來的產(chǎn)品又給加回四個(gè)。這種時(shí)候單打獨(dú)斗的“極簡”根本維持不下去。我的經(jīng)驗(yàn)是把減法規(guī)則公開化、書面化。在團(tuán)隊(duì)里立一個(gè)“需求承諾書”或“會(huì)議公約”新增需求必須附帶業(yè)務(wù)價(jià)值評估會(huì)議時(shí)長默認(rèn)25分鐘超時(shí)需要重新預(yù)約接口字段默認(rèn)最小集新增字段必須提供頁面引用。規(guī)則不寫在任何人腦子里而是寫進(jìn)團(tuán)隊(duì)協(xié)作文檔里每次都拿出來對照。當(dāng)“少即是多”變成團(tuán)隊(duì)契約而不是個(gè)人偏好推行的阻力才會(huì)真正減少。5.4 問題四極簡主義變成另一種焦慮還有一個(gè)很隱蔽的坑有人把“極簡”本身當(dāng)成新的KPI卸載了所有社交App、注銷了賬號(hào)、刪光了收藏夾結(jié)果沒堅(jiān)持一周反而因?yàn)椤皼]做到極簡”而更加焦慮。書里講北歐人幸福核心是“擁有選擇的自由”不是“消滅所有選項(xiàng)”。你保留幾個(gè)常用的App、留著一些暫時(shí)沒時(shí)間看的資料、允許自己每周有一晚上刷短視頻都不違背“少即是多”的精神。關(guān)鍵在于你是有意識(shí)地選擇留下它們而不是被它們裹挾。同樣地項(xiàng)目中留一些冗余時(shí)間、代碼里留一些注釋、需求池里放幾個(gè)“以后可能做”的想法都沒有問題。少即是多的“少”不是數(shù)字上無限趨近于零而是讓所有保留項(xiàng)都經(jīng)過你的主動(dòng)判斷。主動(dòng)選出來的“多”好過被動(dòng)接受的“少”。6. 我的落地清單從讀完到用起來如果這本書只讓你記住一個(gè)動(dòng)作我希望是“每周三問”這周最重要的一件事是什么哪些事情是可以不做、不回復(fù)、不參加的我在哪些事情上投入了資源但產(chǎn)出為零把這三個(gè)問題的答案寫下來比讀十篇讀書筆記都管用。我自己讀完這本書以后第一件事是給手機(jī)設(shè)了一個(gè)“每周日晚8點(diǎn)數(shù)字宵禁”到點(diǎn)手機(jī)自動(dòng)進(jìn)入勿擾模式只保留電話和短信能響第二件事是把需求池從一百多條清理到十六條每條都標(biāo)注了業(yè)務(wù)價(jià)值和對接人第三件事是在團(tuán)隊(duì)里推行了“會(huì)議時(shí)間盒”所有例會(huì)默認(rèn)不超過30分鐘。三件事聽起來都不大但持續(xù)了半年我對工作的掌控感明顯回來了不再有“忙了一周但不知道忙了什么”的失控感。最后再分享一個(gè)小技巧每一季度結(jié)束給自己列一份“已刪清單”。上面列的不是你這個(gè)季度做了多少事而是你砍掉了什么——砍掉了一個(gè)低價(jià)值功能、退掉了一個(gè)沒用的群、刪了一段沒用的代碼、拒絕了一個(gè)注定做不完的承諾。這份清單比“已完成清單”更能反映你的成長因?yàn)椤皩W(xué)會(huì)不做”永遠(yuǎn)比“學(xué)會(huì)做”更難也更重要。這本書不是靈丹妙藥它沒法替你解決老板拍腦袋加需求、客戶臨時(shí)改方案、線上環(huán)境凌晨報(bào)警這些破事。但它提供了一個(gè)很穩(wěn)定的參照系當(dāng)你的工作清單長到看不完、會(huì)議多到?jīng)]時(shí)間寫代碼、需求堆到?jīng)]人敢刪的時(shí)候停下來想一想我們現(xiàn)在做的這一堆事情里到底有幾件真正值得做。想明白這個(gè)你就已經(jīng)走在“少”的路上了。