如果你在外包公司工作過，或者你正在外包公司工作。我相信你一定會遇到評估項目工作量的情況，或者你是評估其中一部分的功能。在PMP裏面介紹，評估工作量最好是找最熟悉這個功能的人，也就是專家判斷。所以肯定非你莫屬了，畢竟你已經成爲了專家。但我相信也肯定會遇到一種情況，工作量評估提交給客戶後，客戶開始砍工作量。然後你們進入一段工作量爭論的時光中。
我一直在考慮爲什麼每次提交工作量評估給客戶，都要進行一頓爭論。客戶會覺得你報這麼多工作量是不是坑我，我覺得挺簡單的功能真的要做這麼久？我們又會覺得，客戶啥也不懂就這砍那砍。所以總結起來就是，客戶覺得你這個工作量不合理，但我們又說服不了客戶，讓客戶覺得這個工作量合理。所以我決定基於這個論點：工作量可以多，但一定要合理。怎麼做到工作量評估更合理，這就是我們要解決的問題。所以我就根據目前公司的工作量評估方法，得出一套方法論。
原則:一定要合理
再次強調一遍原則：工作量可以多，但一定要合理。可以不準確但一定要合理，因爲合理並不代表準確。以下我以一個全新的項目展開討論。
當我們接到一個項目進行工作量評估時，可以分爲幾個大模塊去評估。分別是：需求階段、設計階段、編碼階段、SIT階段、Support UAT階段、上線支持階段。我相信不會有人認爲，工作量評估只是評估開發的工作量就好了。這樣就太不嚴謹了，在開發的過程中會很多坑的。所以我認爲一個項目工作量的評估一定要包含以上幾個階段，無論大小。有些路走了纔不會遇到怪獸。
需求階段
在做項目工作量評估的時候，我覺得一定要定好一個主評估人，讓主評估人起到一個牽頭和整合的作用。爲什麼？因爲在這個評估的過程中，可能專家們只負責其中的一部分。如果沒有主評估人，就沒有主要負責人，這個評估時沒有靈魂的。更重要的是沒有人去整合評估出來的工作量。需要階段的工作量評估，要計算你理解需求的時間（類似看文檔和理解文檔），把需求分解爲功能點的時間。這個階段可能會幾個人參與，都要算工作量，要記住每個人上班都是拿時間換錢，所以時間就是金錢，不是白給的。假設，一個需求介紹會議：需要4個人參加，Web端工程師，後端工程師，app端工程師，PM項目經理。一個小時的會議，工作量就是4*1=4個小時，也就是半天了，評估時不能只算一個人的工作量，沒有算其他同事的。還有我覺得在開需求介紹會之前，一定一定一定要提前看需求文檔，自己理解需求。並不能等客戶講解時再去看，這樣太懵懂了，其實你會很多問題要問的，但是你不夠了解，根據提不出問題。這就跟讀書的時候一樣的，聽老師講課之前要自己預習，這樣聽起來才能理解透徹。特別是主評估人一定要提前理解需求，這樣爲後面的分解提供很大的幫助，要不你只會不斷問客戶，這樣太不專業。
設計階段
設計階段的評估，包括三個方面的內容。功能設計分析和討論、編寫功能設計文檔、跟客戶確認功能設計文檔。在我們需求分析和分解功能點做完後，就是開始與專家（也就是說後端同事，web同事，app端同事）討論這個功能到底要怎麼實現，業務邏輯是怎樣的。討論出結果後，就是開始編寫功能設計文檔了，內容就是：功能到底怎麼實現，具體可以細app或web端點擊什麼按鈕，請求什麼接口，上傳的字段，獲取的字段都在這裏定義好。這份文檔對開發人員來說就是，一個說明書，嚮導，告訴你怎麼做。對客戶來說意味着這是基準，後期如果提出功能設計文檔沒有涉及的內容時，你就可以拿出來說，文檔沒有，這是變更，要做可以，加錢。如果沒這份文檔，只能陷入無限爭論之中。太難了。所以寫好功能設計文檔，一定要跟客戶確認，客戶確認後，才能進入開發。一天不確認，一天不開發。編寫功能設計文檔我們需要考慮，我們要寫幾個端的？假設需要寫後端、app端的。則需要考慮，每個接口都要寫，作用什麼，上傳的字段有哪些？返回的字段有哪些？業務邏輯是怎樣的？還有數據庫腳本，數據庫表設計等等。如果功能複雜且很多的，一個文檔可以寫到一週。
編碼階段
上述所述的把需求分解成功能點或者可交付成果，但是我們評估工作量時，還需把可交付成果與功能點繼續分解成活動。在PMP中做進度計劃前提是，把可交付成果分解成每個可執行的活動。再根據每個活動的持續時間合算成一起組成功能點的時間。這樣跟客戶談起來，你纔能有理有據。並不是隨隨便便拍腦袋的。最好在每個功能點估算旁邊進行備註，讓客戶知道你要做哪些事情。
內部測試階段SIT
有三部分的工作要做：編寫集成測試的用例、根據測試用例進行測試、再來一次迴歸測試。迴歸測試我的理解就是，你在測試過程中，出現的問題記錄下來。在迴歸測試的時候，再測試一次。這裏屬於質量保證的一種方式，要確保項目交給客戶時，沒有那麼多問題。給客戶留下好的印象，也能體現出我們的專業。編寫測試用例的時間估算是根據功能複雜程度的。比如：後端接口，算出來有多少個，一個接口至少有3條用例，接口如果是20個 就是20*3=60條用例，一條用例用10分鐘編寫就是 60*10 = 600分鐘，就是10個小時，就是一天多了。然後加上前端的功能測試這樣一步一步算出來。有理有據，並不是憑空說的。
Support UAT
UAT的週期可以根據項目大小而定，如果是100天以上，最好是分幾輪UAT，每輪的週期爲1-2周。如果是10天以內的，就一週可以啦。然後我們評估出在這個期間需要付出的工作量，如果是項目很複雜的話，則一週3天以上。如果是簡單的，一週一天就可以啦。根據實際來，這裏的工作量，包括改bug，以及客戶的一些問題，需要你協調或解答的時間。
Support 上線
上線支持的時間也是根據項目複雜程度進行計算的。不過進行前面SIT和UAT的過濾，我們已經是解決了大部分的bug或問題。所以這裏的時間不用太多了，一週1天，或者一個月2天就差不多了。
約束
除了上面的幾個階段，我們還需在文檔裏面寫明一些約束。作用是有些東西我們需要澄清，還需告訴客戶有哪些範圍我們不包括，不做，不提供的。假如：支持上線4周，4周後系統不屬於我們維護範圍了。要維護就要給錢了的。這些都是需要跟客戶說清楚。不要到了後面，發生沒必要爭論。這樣多不好
總上所述，就可以寫出以下這份文檔的格式了。
希望能幫助你們評估工作量的時候提供一種思路，如果你有更好的方法請告訴我。我也還在繼續研究中，繼續優化，向合理更靠近點。