很多人在討論研發(fā)效率時都會把估算不準歸因于樂觀或沒有經(jīng)驗。我接觸過不少團隊后有一個很直接的感受這兩個理由往往站不住腳。一個項目延期背后通常不是某個人太樂觀也不是某個人經(jīng)驗太少而是整個估算過程把不確定性處理得太粗糙。我們拿著一個本來應該是概率分布的問題最后卻只變成某個同事嘴里那句“就3天吧”。這篇文章想聊的就是怎么把估算從一個拍腦袋的數(shù)字變成一套可校準、可討論、可修正的系統(tǒng)。1. 為什么“樂觀”和“沒有經(jīng)驗”不是估算不準的真正原因1.1 樂觀偏差被夸大了我們經(jīng)常聽到“規(guī)劃謬誤”這類心理學概念說人總是低估任務耗時因為過度樂觀。但實際工作里估長的情況一點也不少見。有人擔心風險會在估算里主動加緩沖結果任務提前完成反而被說成“故意藏工”。有的任務看著復雜實際上之前已經(jīng)做過類似的東西估了5天最后2天就做完了。這說明偏差并不是單一方向的。如果你只盯著樂觀偏差很容易把所有延期都歸結為“心態(tài)問題”然后要求大家“更悲觀一點”。這種改變沒有意義因為它沒有觸及估算系統(tǒng)的結構性問題。一個任務從估3天變成估5天如果你的需求還是模糊的依賴還是不確定的你在5天之后同樣會翻車。真正的問題不是樂觀而是我們根本不知道自己知道多少。1.2 有經(jīng)驗的人也會估算錯誤經(jīng)驗確實重要但它并不能消除不確定性。新人可能不清楚系統(tǒng)里有多少隱藏復雜度老手可能知道這里容易出問題但如果需求文檔沒有寫清楚第三方依賴又沒有驗證過老手也只能給一個“希望不要出問題”的估算。比如一個工程師有五年服務端經(jīng)驗但對新的消息隊列不熟悉。他估了一個接口改造需要兩天結果光是在測試環(huán)境驗證消息順序就花了一整天。他不是不樂觀也不是沒有經(jīng)驗而是他面對的信息不足。真正的經(jīng)驗是知道自己什么時候信息不足而不是假裝什么都能估準。經(jīng)驗還有一個副作用你會對重復過很多次的任務產(chǎn)生慣性估計。但這次的數(shù)據(jù)量可能不一樣權限規(guī)則可能不一樣上下游團隊可能換了人。經(jīng)驗幫你建立了參考基線但如果不同時核對當前前提基線本身就會變成誤導。1.3 真正的問題我們在用點值預測分布估算的本質是預測。任何預測都應該包含不確定度就像天氣預報會告訴你降雨概率和氣溫范圍而不是直接說“明天一定下5毫米雨”。但很多公司的估算流程只允許填一個數(shù)字。這個數(shù)字看起來精確實際上一旦寫出來大家就會把它當作承諾。你說3天管理層就按3天排計劃測試按3天準備環(huán)境產(chǎn)品按3天和客戶溝通。一個點值背后的不確定性就在這個過程中被反復放大。所以估算不準很多時候不是因為你不努力而是因為你用一個單點答案回答了一個本質上是概率分布的問題。你被迫在一個區(qū)間里挑了一個數(shù)哪怕你心里想的是“大概率4天小概率3天也有可能6天”最終寫出來的只能是一個“4”。2. 估算不準的結構性原因需求、依賴、假設和反饋2.1 需求歧義你估算的很可能不是同一個任務很多估算失準第一步就錯了。不是你不會估而是需求還沒有收斂到可估的狀態(tài)。比如“做一個導出功能”到底導出的數(shù)據(jù)是哪張表最多多少行用什么格式大文件怎么處理有沒有權限限制這些都沒說清楚任何估算都只是猜。樂觀的猜是3天謹慎的猜是7天兩邊都有道理但都沒意義。我一般建議在估算之前先寫一份兩行的“需求邊界”這個任務必須做什么以及明確不做什么。至少讓參與估算的人對齊一下驗收標準。很多時候爭議不是“估幾天”而是大家理解的是兩個完全不同的功能。等你花了一天討論需求才發(fā)現(xiàn)原本估的4個任務已經(jīng)變成了8個這時候再回頭看當初的估算當然對不上。2.2 外部依賴和等待個人效率高不等于任務周期短工期和“人寫代碼時間”是兩回事。一個任務從開始到完成通常包含等待設計評審、等待后端接口、等待前端聯(lián)調、等待測試環(huán)境、等待產(chǎn)品確認。這些等待時間大多不由做估算的人控制。如果團隊里同時有多個項目在互相搶資源那你個人估再準也沒有用。這里的結構性問題是我們習慣把注意力放在自己可控的開發(fā)時間上卻忽略了整體流程的排隊效應。換個經(jīng)驗更豐富的人來做也只能減少他自己的操作時間不能減少外部排隊時間。所以我經(jīng)?？吹焦こ處煱讶蝿展赖煤芫珳实詈髮嶋H周期還是超過一倍因為大多數(shù)時間不是他在寫代碼而是他在等別人。2.3 假設沒有被記錄風險在事后聽上去全是借口估算時每個人心里都有一組默認假設。“這個接口能按文檔返回”“這個Python庫的版本沒有坑”“測試環(huán)境可以隨時部署”“線上數(shù)據(jù)都是規(guī)范的”。這些假設如果不寫下來一旦被打破團隊不會把它當作“預期風險發(fā)生”而會當作“你做事不靠譜”。我后來養(yǎng)成了一個習慣每次給估算時必須附帶三到五條前提條件。例如“按周三拿到接口文檔估算”“假設生產(chǎn)環(huán)境需要遷移兩類數(shù)據(jù)”“如果在聯(lián)調階段發(fā)現(xiàn)字段不一致需要重新評估”。這不是為了免責而是為了讓團隊看清估算建立在哪里。假設寫得越清楚后續(xù)討論就越容易。假設沒有被寫下來風險發(fā)生時你只能說“我沒想到”非常被動。2.4 沒有校準機制同樣的錯誤可以重復無數(shù)次估算不準不可怕可怕的是從不回看。很多團隊在每個迭代結束時會做復盤但復盤的重點是“功能上線了嗎”“客戶問了嗎”很少人會把當初估算的小時數(shù)、故事點和實際對比。沒有反饋就沒有校準。人的判斷力不能靠憑空提高必須靠大量“預測→結果”的對照。你如果連續(xù)十次都估少了30%下一次自然會考慮把余量放大一些。但前提是你真的知道自己一直估少了。很多團隊把復盤開成了匯報會大家不好意思把“我上次估少了”放到臺面上于是同樣的偏差下個迭代繼續(xù)復現(xiàn)。3. 改進估算的第一步從“給一個數(shù)字”變成“給一個區(qū)間”3.1 用三個數(shù)字描述你的真實判斷建議不要直接寫“5天”而是寫三個數(shù)樂觀、悲觀、最可能。比如任務復雜度中等既有熟悉的模塊也可能有第三方接口的不確定你可以估樂觀2天悲觀6天最可能4天。把這三個數(shù)寫到估算里別人就能看到一個范圍。這個范圍不是不專業(yè)反而是更準確地描述了你現(xiàn)在掌握的信息量。如果你對任務完全陌生范圍會更大如果非常熟悉范圍會收斂。這個變化本身就是判斷力在起作用。你不需要每次都把三個數(shù)寫給所有人看但你至少要自己問一遍我的最好情況、最差情況、最可能情況分別是什么。3.2 用歷史數(shù)據(jù)校準區(qū)間寬度區(qū)間從哪里來最好不靠感覺而是靠歷史記錄。比如你過去做了10個類似任務其中有5個實際耗時在估點的1.2倍到1.8倍之間那么估算區(qū)間就應該覆蓋這個范圍。如果你的歷史數(shù)據(jù)里沒有這個信息就先記錄不要急著追求精確。區(qū)間寬度不是越大越好也不是越小越好而是要和不確定度匹配。給一個從1天到30天的區(qū)間沒有價值因為決策者無法使用。更好的做法是“最可能是4到6天其中6天對應的是接口文檔可能晚兩天?！?這個信息比一個干巴巴的數(shù)字有用得多。管理層聽到之后至少知道如果希望降低風險應該優(yōu)先推動哪個前置條件。3.3 把區(qū)間翻譯成排期管理層通常不要區(qū)間要日期。你要做的是把區(qū)間翻譯成帶條件的排期。比如“按今天的信息4到6天我建議排6天。如果接口文檔周四仍然沒有到那要從周四開始順延?！被蛘邠Q個說法“如果需求不再變更按5天排期一旦需求變更需要重新評估不能在這個基礎上只追加1天?！?這樣看起來是在給日期但實際上你把不確定性的責任放回了系統(tǒng)里需求變化、外部依賴這些因素不會被一筆帶過。我見過很多“高效”的團隊其實是靠犧牲估算真實性換來了表面上的確定排期最后在下一個節(jié)點爆發(fā)。與其這樣不如一開始就允許估算里帶條件。帶條件的排期比假裝確定的排期對組織更負責。4. 建立校準閉環(huán)記錄估算、實際和誤差4.1 先記錄10個任務不要急著調整建立估算習慣的第一個動作不是改公式而是記賬。每完成一個任務就記錄剛開始估了多少最后實際用了多少中間發(fā)生了什么導致偏差。堅持記錄10個左右的任務就可以做一次簡單統(tǒng)計。你不用記錄得太精確重點在于字段穩(wěn)定。比如“估算天數(shù)”“實際天數(shù)”“偏差原因”。原因可以記“需求變更”“外部接口晚到”“個人不熟悉”“環(huán)境問題”“其他”。這能幫你把主要偏差因素拆出來。很多團隊的問題不是沒有數(shù)據(jù)而是數(shù)據(jù)散落在每個人腦子里沒有形成結構化記錄。拿不出來復盤就無法改進。4.2 用一張簡單的表格做個人校準下面是一個示例表格你可以復制到文檔或表格工具里字段可以按你自己的情況調整任務估算天實際天差值主要偏差原因用戶列表導出34.51.5導出超時需要分頁接口日志查詢21.5-0.5已有通用組件權限重構583歷史臟數(shù)據(jù)兼容邏輯這張表最重要的是三列估算、實際、原因。如果只記前兩列你只能看到一個“你很樂觀”的結論加上原因你才能知道下次該關注什么。記錄表只用于自我校準和團隊改進不要用來追責。一旦變成績效工具所有人都會想方設法把估算寫高最后整個數(shù)據(jù)失去意義。4.3 計算調整系數(shù)但不要機械套用有了至少10個樣本后你可以算一個粗口徑實際總時長除以估算總時長。如果結果是1.3說明你系統(tǒng)性地低估了30%。下次估3天可以先按3.9天考慮。但接下來要問這30%里有多少是需求變更有多少是個人能力不足有多少是外部等待如果大部分是外部等待那你的任務應該帶上更明確的前置條件再乘系數(shù)才有意義。如果大部分是需求變更那就不是估算問題而是范圍管理問題。把這兩者分清楚校準才有效。如果不管三七二十一直接給所有估算乘一個系數(shù)你只是在掩蓋問題并沒有真正理解偏差從哪里來。5. 不同場景下的估算策略個人、團隊、管理層5.1 個人任務把拆解、緩沖和風險寫出來即使沒有別人考核你也建議個人事務采用區(qū)間估算。比如“寫周報”可能半小時但“準備技術方案評審”可能是一周到兩周。個人任務有一個陷阱我們往往只估算“有效工作時間”忘了溝通、等待、被打斷、返工。一個非常實用的辦法是把任務拆成“理解需求、編碼、驗證、收尾”四段先分別給出區(qū)間再合并。合并之后在總時長上額外增加10%到20%的緩沖專門應對那些“說不清但一定會出現(xiàn)”的事情。別小看這個習慣它能讓你對時間的感知更真實。個人校準做一段時間之后你再去看團隊的復雜任務會更容易識別出哪部分被壓縮得過分了。5.2 團隊迭代用相對估算而不是每個人的小時數(shù)團隊排迭代時最好不要讓每個人報“我大概需要幾天”。這樣的數(shù)字會被個人信心、默默加班、怕被批評等因素污染。更穩(wěn)妥的方式是給任務打相對大小S、M、L、XL或者故事點。為什么相對估算更準因為人的相對判斷比絕對判斷穩(wěn)定很多。你說“這個任務比那個任務大一倍”往往比說“這個任務要3天”更接近事實。之后團隊用過去幾個迭代的實際完成點數(shù)來推算容量。比如過去三個迭代平均完成20點新迭代塞30點大概率完不成。這不是樂觀是容量與需求的簡單比較。相對估算還能把“誰是新人”這個因素暫時放一邊。新人同樣可以判斷任務大小只是他完成的速度可能更慢。接下來團隊用每個人的歷史速率去換算排期而不是在估算階段就爭論誰快誰慢。5.3 向管理層匯報把假設和風險一起呈現(xiàn)面對管理層恐懼感會讓估算變形。很多人在“我真實的估算”和“管理層想聽的數(shù)字”之間取了一個中間值結果兩邊都不舒服。我的經(jīng)驗是不要試圖把不確定性包裝成確定性。你可以在排期里明確寫出三個前提比如“需求不再增加”“第三方接口按文檔返回”“測試環(huán)境可用”。如果前提成立排期是5天如果前提不成立日期要順延。這樣做表面上是把風險推給管理層實際上是在逼管理層做決策是保范圍還是保時間還是保資源。把不可能三角擺到桌面上遠比表演一個“很有信心的數(shù)字”更有價值。如果管理層堅持要一個確定日期你可以給出帶置信度的日期“按目前掌握的信息90%的把握是6天內完成80%的把握是5天內完成?！?這既回應了需求又保留了對不確定性的誠實。6. 改進估算時最容易踩的坑和排查順序6.1 四個常見誤區(qū)第一個誤區(qū)一不準就整體翻倍。翻倍的估算很快就會失去信用因為它的理由不透明。你從3天改成6天到底是哪里變了大家不知道所以下一次你就會被要求給出“真實值”。第二個誤區(qū)只依賴某一種公式。PERT公式E(O4MP)/6可以幫你算期望值但它假設你的三個數(shù)都有意義。如果O、M、P都是隨手填的算出來的數(shù)也不會靠譜。公式是輔助工具不是估算質量的來源。第三個誤區(qū)把估算記錄表當成績效工具。一旦記錄變成考核大家就會故意把估算寫得很高最后整個系統(tǒng)失真。記錄表的意義是校準不是評價。第四個誤區(qū)只盯著數(shù)字不盯范圍。同一個任務名需求變了實際當然對不上。這時候要直接重估而不是硬套舊估算。范圍變了還拿舊數(shù)字說事討論永遠無法收斂。6.2 排查順序從現(xiàn)象往下追如果你發(fā)現(xiàn)團隊最近連續(xù)延期我建議按這個順序排查先看需求是否清晰有沒有驗收標準有沒有邊界說明。再看假設是否寫下來了依賴條件、環(huán)境條件、數(shù)據(jù)條件是否明確。然后看依賴是否可控有沒有等待外部接口、等待審批、等待其他團隊。接著看是否有歷史數(shù)據(jù)過去的估算誤差是不是已經(jīng)在某個區(qū)間內穩(wěn)定出現(xiàn)。最后再看個人態(tài)度和經(jīng)驗這里才輪得到“樂觀”和“經(jīng)驗”之類的話題。很多人一開始就質問“你是不是太樂觀了”這是最低效的歸因。我見過很多次團隊成員其實給了偏保守的估算但管理層為了項目目標強行壓縮最后延期了。這種情況跟樂觀毫無關系。按順序排查你會發(fā)現(xiàn)真正的卡點往往在流程和輸入條件上而不是某個人的性格。6.3 從最小的實驗開始改進估算不需要一次到位。建議選一個迭代或者一個自然月做一個小實驗每個任務必須給出區(qū)間記錄實際并且在執(zhí)行中定期更新一次“當前預期是否變化”。不要急著引入復雜的估算工具也不要急著改變所有流程。先讓團隊熟悉“給區(qū)間記偏差”這個動作。幾輪之后再把誤差分布和調整系數(shù)引進來。你會發(fā)現(xiàn)團隊的討論會從“你憑什么估3天”變成“如果我們假設接口晚到兩天是不是應該按5天排”。這個變化才是真正的進步。我個人更建議把估算從“數(shù)字游戲”改成“預測系統(tǒng)”。不要再問“估幾天”而是問“什么情況下能按這個日期完成什么情況下不能”。把邊界劃出來把假設寫下來把誤差記下來。這樣即使估算依然不準你也能知道不準在哪里。踩過幾次之后就會發(fā)現(xiàn)很多問題不是能力問題而是反饋缺失。真正靠譜的估算不是每次都準的估算而是每一次不準都知道為什么不準的估算。