作為產品經理，對於工作量評估的工作內容也是要了解的，下面文章中筆者分享了關於工作量評估的四種方法的相關內容，大家一起來看看，學一學叭！
———— / BEGIN / ————
原本，工作量評估更多是專案經理或技術經理需要做的工作，但隨著產品經理在團隊內的成長，越來越多的產品經理需要參與到售前，或者專案管理的工作中，自然而然會遇到工作量（工期、費用預估、合同報價、產品定價）相關工作。
另外，最近大家都在做產品的年度規劃，如果做完規劃後，領導問我們大概投入多少錢，需要多少人，做多長時間？類似於這樣的問題，我們應該如何回答？這也用到了工作量評估的方法。
所以本文結合我過去幾年的工作經驗總結常見的四種工作量評估方法，希望對你有幫助。
功能拆解法
功能拆解法，顧名思義，先將要做的系統功能拆解為可評估的顆粒度，一般我習慣拆到三級或四級功能，這樣更有跡可循。
比如很多人會問，做一個XX系統需要多少錢？這個問題沒辦法回答，因為沒有功能邊界。
所以我們可以先試著拆第一級功能，即這個平臺分為幾個應用？
以HRSaaS平臺為例，假設我們需要完成四個應用，分別是PC端、微信小程式端、微信公眾號端（或APP端）、平臺的運營管理端。然後再為每個應用拆分二級功能。
比如pc端是功能最多的，包含了登入註冊、人事管理、崗位職級管理、薪酬管理、績效管理、流程管理、視覺化報表等功能。
然後再拆三級功能，如人事管理包含了入職、轉正、調崗、離職，每個功能都包含查詢、單筆新增、批次匯入、批次匯出、資料許可權控制這幾個簡單的頁面。
這樣人事管理這個模組被我們拆成了四級功能，而且每個功能包含前端開發、後端開發、測試三個維度的工作量。
當然，有些功能是純後臺的開發邏輯，這些很容易被工作量評估者遺漏，比如一些批次處理的定時任務。
之後按照經驗，或者很多評估公司會使用一些計算公式來羅列各個功能所需時間。
“按照經驗”說簡單也簡單，對於有經驗的人來說，大致可以估出來一個功能需要幾天，但對於沒有經驗的同學，就需要找開發請教，或者檢視之前類似功能的開發週期。
按照公式一般會將每個功能區分不同的級別，比如難、中、易。或者很多公司會使用難度係數，不同的級別/係數，對應不同的工作時間。
最後逐一列完所有三級或四級功能的難易程度之後，把天數加總起來。
這個過程就是最簡單的功能拆解法，但裡面會涉及到兩個問題：
-
同樣的功能，不同能力的人員開發所需的時間不同，應該如何參照？
-
很多團隊在實際工作中是“並行”，而工作量評估更多是“序列”思維，這樣評估出來的結果，大機率比實際情況要高不少。
所以說，工作量評估最終的結果，並非僅僅按照功能拆分法的結果而來，更多是多種方法的結合，因此，關於這兩個問題，文末會詳細說明。
功能拆分法的關鍵，就在於功能拆解的顆粒度是否足夠細緻。
這個“足夠”很難量化，不同規模、不同複雜度的系統會有很多差異，核心要素是既能讓自己可以明確做這個功能所涉及的大體功能清單，又不能過於細緻（比如具體到按鈕級別、欄位級別，那樣就太繁瑣且低效了）。
人月估演算法
人月法，顧名思義，就是評估幾個人做幾個月，然後根據人月單價換算成最終的費用。
但是預估人月時，其實更多也是靠經驗，雖然人月單價都會區分人員級別（如初級、中級、高階、資深等），但作為“事前”評估時，張三做這件事大致花幾個月，就需要“拍腦袋”了。
市場上很多人月法都是在人力外包的場景下使用的，而且是先用人，後付錢。這樣相當於“按實際使用情況”付費。
但也有很多時候需要在使用前大致估算，甲方說：你們派幾個人來，工期多久？假設是派遣3個人，做3個月，那就可以初步評估成本為9人月。
如果甲乙雙方的合作方式為人力外包，那麼這9個人月就基本包含了甲方需要支付的所有費用。
如果甲乙雙方的合作方式為專案合作，那麼這9個人月可能只是“實施成本”或者叫做“交付成本”，整個專案報價中，還會包含產品費、其他增值服務費等。
這就是簡單的人月法評估價格，但具體操作的時候，又會基於不同的客戶關係、合作模式、業務預期等因素，對人月進行調整。
緊貼預演算法
實際上，在真實的乙方向甲方進行專案報價時，乙方基本都會問一句：咱們這個專案的預算大概多少？預算是多少，那報價就不能超過這個數，這是最簡單的工作量估算方法，也可以叫“倒推法”。
如果是單一來源，或者乙方能夠控住招標局勢，那麼比預算價格略低一點，即可作為成交價，之後再根據成交金額透過人月法、功能拆解法來評估投入多少人，做多少事。
如果是正常投標，可能中標額會在預算的85%左右，如果是多家公司激烈廝殺，最終成交價就不好猜了。
假設一款產品正常做完需要300萬，但甲方預算只有150萬，最終成交價格是120萬，那對於乙方來說，這個專案能做嗎？
大多數答案是，咬著後槽牙說：太能了！
因為一些輔助類功能可以不做，一些複雜功能可以簡單化，一款產品的定製化交付過程，幾個月甚至幾年的時間，裡面可輾轉騰挪的內容還是蠻多的。
（所以說，很多大企業的外包專案做完之後用不起來，上線即結束，原因之一也就猜出來了）
除非，甲方很清楚自己要什麼，就是要花一半的錢買全量的產品，這時要不要做，就要斟酌一下了。但據我瞭解，大部分企業依然會一咬牙一跺腳，把工作接下來。
因為，如果你不做，競對就做了，自己少了一個案例，競對多了一個案例。而且，自己的人員成本支出是固定的，卻少了一個專案的營收。
所以，緊貼預演算法，也體現了乙方公司的困境。
對標同業法
最後則是一個更加簡單粗暴的方式，此方式適合“壟斷競爭市場”（在某產品市場中，許多廠商在市場中銷售有差別的同種產品）。
就像幾年前我們想做HRSaaS平臺，但是不知道定價多少錢，於是就去看了很多類似的SaaS公司的定價規則，之後根據定價來倒推自己的營收。
比如一家100人以內的企業每個月收費30元，一年就是360元。一家100-500人的企業每月收費50元，一年是600元。
假設團隊有15人，平均月薪1.5萬，每年的人員成本（不包含管理成本和其他社保、福利、差旅等支出）就需要270萬元，按照上述兩類企業規模1:1計算，則各需要將近3000家客戶付費。
再算上營銷優惠之類的，每年需要至少6000家企業客戶，才能保證自己不虧錢。為什麼很多企業需要融資，為什麼要推出各種優惠套餐？現金流是真的扛不住！
所以，我們參考同業一方面是參考他們的對外價格，另一方面也要評估這個價格對自己意味著什麼，也能發掘整個團隊整體需要提升的方向在哪裡。
是友商的管理效率更高？人員成本更低？使用者量更大？還是說有其他的生財之道？
公司與公司之間的差距，從定價上有時也能體現背後的一些隱藏邏輯。
總結
上述四種方法，適用於不同的場景和報價模式。
-
乙方的專案制，更多采用緊貼預演算法+人月法+功能拆解法；
-
自研產品，更多采用同業法+功能拆解法+人月法；
-
甲方的專案立項預估費用，對功能的細化比較困難，所以更多可以採用人月法+同業法，其中同業法除了參考同行，還可以參考乙方公司的初步報價。
實際運用中，這些方式更多是相互牽扯、相互影響。
當然，所有的工作量預估，都會涉及“投入產出比”的問題，如何評估本次投入的收益，又是一件難題，本文不再展開。
歸根結底，“經驗法”也是基於多種方式融合而來，只不過沒經驗的人缺少很多可量化的決策支撐。
說一下上文提到的那兩個問題：
1. 同樣的功能，不同能力的人員開發所需的時間不同，應該如何參照？
原本我對這個問題只有一個粗淺的觀點，並不能達到輸出成文的認知，剛巧上個月學資料建模，其中提到了三個詞，我發現可以應用到這個問題上。
我們可以將不同水平的開發者大體分為三類分別評估，再透過實際交付過程中的人員水平進行微調。
或者選取一個平均（折中）的水平進行初評估，之後按照不同的係數分為：悲觀時間、樂觀時間、最可能時間三類，如果我們的計算方法和計算過程偏差不大，最終結果應該以最可能時間為準。
2. 很多團隊在實際工作中是“並行”，而工作量評估更多是“序列”思維，這樣評估出來的結果，大機率比實際情況要高不少
這裡多出來的空間，才是交付過程中可輾轉騰挪的“底牌”，也是為了為不可控因素留下一些餘地，因為但凡需要人參與的事情，都無法完全量化。
我覺得，如果連這部分冗餘都沒了，那乙方真的很難賺錢了。
寫在最後
最後，還要談一下覆盤和經驗積累的重要性。
無論你是否擁有決策權，都可以透過自己的方法評估完工作量之後，和最終這件事做完之後的實際工作量進行對比，從而尋找自己在預估時存在的思維偏差。
這樣多做幾次之後，隨著經驗的積累，你可能會知道不同的專案，不同的合作模式，甚至不同的客戶，不同的研發團隊，在做類似的產品時，工作量應該怎麼預估，甚至知道為什麼同樣的產品和功能範圍，在A客戶和B客戶的交付成本能相差一倍。
只可惜，大部分企業在評估工作量時，更多是“拍腦袋”，並沒有一些相對標準或者有跡可循的量化思路。
我覺得，這反而體現了管理上的不完備性，即“靠人管”還是“靠流程和體系”管，這也是不同發展週期下的爭論點、變革點。
———— / E N D / ————
本文來自公眾號：不想延期 作者：不想延期
👇 想要第一時間瞭解行業動態、面試技巧、商業知識等等等？加入產品經理進化營，跟優秀的產品人一起交流成長！
———— / 推薦閱讀 / ————