昨天聊到產品負責人要在與開發團隊估算完需求的成本後，兩者協商最近一次開發週期要做哪些事情。但是這時通常會有個困境，就是團隊對於需求的估算。

人類一直都不太擅長絕對的估算，什麼是絕對的估算呢？大概就是「這件事大概會花費我三小時的時間」、「這個需求會需要四個工作天」之類的，通常這類計算很容易失準。常常一個覺得大概十分鐘會好的事情，事實上卻因為種種因素最後花了一小時以上。因為這樣的估算方式以及我們容易樂觀去審視需求成本的事實，導致團團面臨實際花的時間比預估要多，進而又要導致加班或是無法達成承諾的慘狀。

事實上，人類比起估算一個實際值，卻更擅長比較。我們無法馬上說出這件衣服的 Size，但是我們可以輕鬆地說這件衣服比那件還要大。同樣的，我們可能很難對需求給出一個準確的時間成本，但我們卻可以大略比較需求與需求之間的大小，像是「可能 A 需求會比 B 需求花多一點時間，C 需求比 A 需求要花更多時間」這樣的比較。

所以，在估算這件事情，我們只要能給出一個準確（accuracy）的答案，讓團隊和產品負責人心裡有個底，大概知道成本落在哪邊即可了，至於之中差了幾分鐘、或是差了半天左右，其實並不是十分重要。過於精確的值，反而容易讓有變數時，造成計畫難以因應變化。

到這邊，或許就會有人開始用 1 ~ 10 去為每項需求做個評比：「我覺得 A 大概 4，B 大概 3，C 大概 8。」然而這樣的比較卻沒辦法產生太大的比較感，讓刻度大一點會比較能夠實際感受到兩者的差異，畢竟我們不需要太精確的值。

估算時，應該讓估算的刻度值偏小時，使用較多的數字；刻度值較大時，使用較少的數字。這樣講有點籠統，舉個例子好了。若是我們使用的估算單位是每 30 分鐘為一單位，那在單位小時，像是 6 小時內的時間成本，這個估算都還算有比較的價值；但是若是已經到了五天、一週的估算大小，卻還是以 30 分鐘為一單位，追求這樣的精確值（precision），就顯得意義不大。

所以就有人提出了使用費式數列作為估算比較的媒介，也就是 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 的數列。費氏數列的特色就符合了上述的特色，在刻度值小時，用了較多的數字去做比較；但是當刻度值變大時，數字之間的密度也就變小了，邁向下個刻度的大小也會越來越大。

從中我們就可以很有感，1, 2, 3 和 89 的大小差異，如果我們是用 1 ~ 10 做比較，可能就不會感受到之中的成本差異是很大的。而在估算時，可以某樣需求作為標準，假設他是 5 時，其他需求的成本大概是多少，去做比較。而且一定要從費氏數列裡面去挑選，而不能從中再劃分刻度，這麼做的話就偏向過於執著精確值，來到上面所說的無意義的追求了。若覺得是 23，就挑 21，若覺得是 72，就從 55 和 89 之間擇一。

然而，有時候費氏數列在使用上並不是很好記憶，所以又有人將其簡化成 1, 2, 3, 5, 8, 13, 20, 40, 100 與無限大。也有人覺得刻度間距不夠大，而將其放大兩倍，像是 1, 2, 4, 8, 16, 32....。這都是看團隊覺得怎樣最直覺而去使用。

這邊雖然標題是講「透過費氏數列進行估算」，但是其實追求的就是採用一個能讓我們回答出足夠暸解成本大小，但卻不會因為追求精確度過高，導致花很多時間去估算、或是到最後容易失準的方法。也就是追求準確、而不執著於精確。明天再來和大家聊聊知道這個概念後，又該怎麼實際應用在團隊的產品開發上囉。