評估與執行時間常有落差，怎麼辦？電商顧問PM，用「9個數字」掌握團隊效率

在加入網路產業之後接觸到了 SCRUM 這樣的敏捷開發方式，也馬上被交付了公司內的大型新專案，而在實際作為專案負責人的過程中，也讓我在作為產品經理這條路上的經驗值飆升許多（詳情可見先前的文章：敏捷開發的重點不在「快速」！一個真實案例，給我們的管理啟示）。

在新專案開始以後，團隊內部有問題時都能很迅速聚集在一起討論，檢討現有開發流程中可改善之處並迅速做出反應。但我們發現每個階段的估計時間與實際執行時間依然還是有不小的差異，開發流程的改善看似到了極限，而且很難評估每個階段的團隊開發成效。

這也讓我回頭審視過往的產品規劃期與開發階段，是否還有需要改善之處，並尋找是否有方法能夠改善。

規劃與執行，理想與現實的落差

我們團隊過往的產品規劃期大概是這樣的：首先產品經理將產品規格書定好之後，會約一個會議與資深工程師或是系統架構師，進行此次功能的簡報並討論實作。在這個會議中會將此次要進行的產品或功能開發，拆成不同的小工作事務。

而在拆出不同的工作事務以後，便會由資深工程師或是系統架構師評估出各個工作事務的預計開發時間。所有的工作事務累積起來的時間，就能大概推算出完成這個產品或功能所需要的時程，以此時程與其他團隊或專案協調開發資源，並將各個工作事務分配給團隊中的工程師進行開發。

但就像前述所說，最終實際的執行時間總是與我們當初的評估時間有所落差，時常有延遲的狀況。而在認真觀察團隊的合作狀況並且與各團隊成員單獨訪談了解之後，我發現了幾個造成我們延遲的重點原因。

首先在觀察團隊的合作狀況以後，在規劃時再怎麼縝密，也難免有百密一疏或是趕不上變化之處。像是最初我們希望做出的訂單數據指標，最後發現數據怎麼算都對不準，在追查一陣子之後才發現可能是一個極端狀況造成的偏誤，或是因為其他團隊推上了新的訂單功能讓我們的邏輯壞掉。

關於這樣的狀況我們只能盡量將任務拆小，降低每次規劃與評估的範疇，並對於極端狀況評估是否值得我們花費資源與時間進行處理。

另一個問題則是在單獨與團隊成員訪談中瞭解到，其實有很多的事務可能對於執行的工程師來說是第一次接觸，也需要一點學習的時間，但評估時程時則是由資深前輩以自身經驗來作為基準，或是沒有想到執行者可能遇到的困難。

而上述狀況即便是資深的工程師在執行時也可能會遇到一些突發的狀況，這些總總因素也讓工作事務預估的時程總是不夠準確。

承認吧！人類就是不擅於精準預估事務

在發現這些問題之後，了解到預估時程是不可能做到百分之百的精準，我便計畫將所謂「故事點數」導入我們的產品規劃與評估階段。

而「故事點數」是如何運作的呢？首先我們先將要進行的產品功能，以精簡概要的一句話的形式寫出，讓團隊成員了解這個功能是要做什麼的、預期能解決什麼問題、或是做到什麼效果。舉例來說：我們要做出一個訂單數據的圖表，如果我是店家，就能透過這個圖表了解我每天訂單成長的趨勢。

接下來便會讓所有團隊成員，不管是資深的工程師或是過往偏向執行的工程師，所有團隊成員要在有限的時間以內，從規定好的數字序列內挑選一個點數，來代表自己認為處理這個功能的複雜程度。

數字序列的形式有很多種，像是有些團隊會以衣服的尺寸：XS / S / M / L / XL 作為序列，而我們團隊採用的是比較經典的「規劃撲克」：1 / 2 / 3 / 5 / 8 / 13 / 20 / 40 / 100，可視團隊狀況與習慣調整。

不過不管用哪一種序列，不同級距的數字或尺寸都要能讓每個人很清楚了解到2個級距的差距。像是如果今天採用一般的數字序列：1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9 ...，有個成員估算出 8 點，如果另一個成員估算出下一個級距是 9 點，其實這兩個成員的估算點數的差距太細微，細微到我們很難判別出彼此的差異。

但如果我們採用「規劃撲克」的序列，另一個成員估算出的是 13 點，同樣相差一個級距卻能讓我們很直覺地了解2個級距複雜程度的差別。

在挑選完各自預估的故事點數以後，便會互相公開彼此的預估點數，在有故事點數差距的狀況下，我便會引領各團隊成員討論彼此為什麼要這樣評估。而我們在第一次執行這樣的規劃時，便發現大家評估的點數差距不小，尤其是過往擔任規劃者的預估點數，幾乎都小於執行者的預估點數。

減少規劃者與執行者的落差，掌握團隊的速度

在討論彼此級距差異的過程當中，我們這也才了解到我們過往在規劃或估計時程可能都過於理想，而忽略了執行者的想法或實際面的問題。同時團隊成員也會分享各自是如何看待這個功能，或是可以運用什麼樣的技術及過去的經驗來解決或防範可能的問題。

討論過後會請所有團隊成員再次進行評估故事點數的程序，直到所有團隊成員的評估點數有所共識，如此一來這個點數便是「整個團隊」對於處理這個事務所評估出的複雜程度，而不是過往「單一個人」評估出的預估時間。

最後再把所有預計要進行的事務估出點數之後，加總起來便是我們下個衝刺階段預計要完成的點數目標。像是如果我們預計下個衝刺階段要完成20個故事點數，實際上我們最後只完成了 15點，那就代表目前團隊在一個階段內能完成的工作份量還沒達到我們的預期，要思考如何提升團隊效率，提升完成的故事點數量。

又或是最後我們在衝刺階段還沒結束就把所有20個故事點數完成，那就代表團隊能夠達到的工作份量其實超乎預期，再下一次可以再把目標定高。

故事點數在初期導入階段是很難做到準確評估的，需要一段時間讓團隊累積經驗，但運用這樣的方式，長久下來就能越來越好掌握團隊的工作產出與速度，對於管理者來說也更能掌握策略時程。

責任編輯：黃楸晴
核稿編輯：張凱涵