如果你在外包公司工作過，或者你正在外包公司工作。我相信你一定會遇到評估專案工作量的情況，或者你是評估其中一部分的功能。在pmp裡面介紹，評估工作量最好是找最熟悉這個功能的人，也就是專家判斷。所以肯定非你莫屬了，畢竟你已經成為了專家。但我相信也肯定會遇到一種情況，工作量評估提交給客戶後，客戶開始砍工作量。然後你們進入一段工作量爭論的時光中。
我一直在考慮為什麼每次提交工作量評估給客戶，都要進行一頓爭論。客戶會覺得你報這麼多工作量是不是坑我，我覺得挺簡單的功能真的要做這麼久？我們又會覺得，客戶啥也不懂就這砍那砍。所以總結起來就是，客戶覺得你這個工作量不合理，但我們又說服不了客戶，讓客戶覺得這個工作量合理。所以我決定基於這個論點：工作量可以多，但一定要合理。怎麼做到工作量評估更合理，這就是我們要解決的問題。所以我就根據目前公司的工作量評估方法，得出一套方**。
再次強調一遍原則：工作量可以多，但一定要合理。可以不準確但一定要合理，因為合理並不代表準確。以下我以乙個全新的專案展開討論。
當我們接到乙個專案進行工作量評估時，可以分為幾個大模組去評估。分別是：需求階段、設計階段、編碼階段、sit階段、support uat階段、上線支援階段。我相信不會有人認為，工作量評估只是評估開發的工作量就好了。這樣就太不嚴謹了，在開發的過程中會很多坑的。所以我認為乙個專案工作量的評估一定要包含以上幾個階段，無論大小。有些路走了才不會遇到怪獸。
上述所述的把需求分解成功能點或者可交付成果，但是我們評估工作量時，還需把可交付成果與功能點繼續分解成活動。在pmp中做進度計畫前提是，把可交付成果分解成每個可執行的活動。再根據每個活動的持續時間合算成一起組成功能點的時間。這樣跟客戶談起來，你才能有理有據。並不是隨隨便便拍腦袋的。最好在每個功能點估算旁邊進行備註，讓客戶知道你要做哪些事情。
有三部分的工作要做：編寫整合測試的用例、根據測試用例進行測試、再來一次回歸測試。回歸測試我的理解就是，你在測試過程中，出現的問題記錄下來。在回歸測試的時候，再測試一次。這裡屬於質量保證的一種方式，要確保專案交給客戶時，沒有那麼多問題。給客戶留下好的印象，也能體現出我們的專業。編寫測試用例的時間估算是根據功能複雜程度的。比如：後端介面，算出來有多少個，乙個介面至少有3條用例，介面如果是20個 就是20*3=60條用例，一條用例用10分鐘編寫就是 60*10 = 600分鐘，就是10個小時，就是一天多了。然後加上前端的功能測試這樣一步一步算出來。有理有據，並不是憑空說的。
uat的週期可以根據專案大小而定，如果是100天以上，最好是分幾輪uat，每輪的週期為1-2周。如果是10天以內的，就一周可以啦。然後我們評估出在這個期間需要付出的工作量，如果是專案很複雜的話，則一周3天以上。如果是簡單的，一周一天就可以啦。根據實際來，這裡的工作量，包括改bug，以及客戶的一些問題，需要你協調或解答的時間。
上線支援的時間也是根據專案複雜程度進行計算的。不過進行前面sit和uat的過濾，我們已經是解決了大部分的bug或問題。所以這裡的時間不用太多了，一周1天，或者乙個月2天就差不多了。
除了上面的幾個階段，我們還需在文件裡面寫明一些約束。作用是有些東西我們需要澄清，還需告訴客戶有哪些範圍我們不包括，不做，不提供的。假如：支援上線4周，4週後系統不屬於我們維護範圍了。要維護就要給錢了的。這些都是需要跟客戶說清楚。不要到了後面，發生沒必要爭論。這樣多不好
總上所述，就可以寫出以下這份文件的格式了。
如何評估專案工作量
乙個工程需要的早期評估有三項 工作量 持續時間 預算。在這三項中，工作量必須首先評估。當了解工程所需的工作量，你就可以分配決定工程持續時間的資源，進而可以評估人力資源和非人力資源花費。用下面的過程來評估你的工程所需總工作量 1 決定評估所需的精確度。典型的情況是，評估的精確度越高，所需的細節就越多，...
工作量評估常用方法
目錄 運用專家判斷 自下而上進行彙總 模擬估算 三點估算 通常由團隊資深se或者技術負責人，根據經驗來做個粗略估計，通常情況下此方法估算可能偏差較大，但是量級一般比較準確。工作分解之後，工作包落到具體的實施人員，由工作直接承擔著進行工作量估算，然後向上彙總，最後彙總出乙個專案的整體工作量。此方法通常...
速達3000工作量評估
1.基於功能點評估 速達3000軟體具有如下的功能 1 採購管理 包括採購訂貨管理 採購收貨管理 採購退貨管理 暫估入庫管理 地區資料管理 商資料管理 貨品類別管理 貨品資料管理 收付款方式管理。2 銷售管理 包括銷售訂單管理 銷售發貨管理 信用額度管理 銷售退貨管理 委託代銷貨品 委託代銷結算 委...