很多項目經理對于項目評估、管理、控制的能力基本上是來自于項目經理本身的從業經驗，由于各種各樣的原因，項目經理更多的是一個全才，這是在當前環境下，保證項目還能正常運行的必然結果。在實際情況中，項目不但耗時長，而且成功率也很低，其中一個很重要的原因是對于需求的工作量評估沒有一個具體的依據，很多時候都是想當然的估算一個數字，當項目開發過程中來自于需求變更后對新需求的工作量估計不足導致產生連鎖反應，后失去對項目的控制。
本文的目的在于提出一種對項目總體工作量估算的模型，用于項目經理在面對原始合同進行概要設計，項目進行過程中面對需求變更時計算工作量的一種參考依據。這個模型的目的是要有效的減少工作量，這并不意味著會少做事，而是希望引導多做正確的事情。特別是這個模型也能為提高工作效率指明方向。
要設計一個模型，首先要對日常工作進行全面的分析，抽象出工作的每一個步驟，對每個步驟中所需要用到的知識進行歸納，還需要對每個步驟中的復雜度進行評估。
在一個項目的開發過程中，在面對一個業務功能時首先做的是從需求中設計表結構，然后為表結構定義各種各樣的關聯，定義完關聯后基本上在大腦內形成界面的大致樣子，然后開始寫代碼。
從上面的過程中，大致可以分成下面的兩個步驟：
1. 數據結構設計階段
2. 根據數據結構編寫代碼階段
接下來分析下每個步驟所用到的知識。
1. 在數據結構設計階段所使用的知識分為以下幾個部分
1) 數據庫設計知識
2) 業務知識
2. 在根據數據結構編寫代碼階段所使用的知識分為以下幾個部分
1) 數據庫操作知識
2) 后臺編程語言知識
3) 前臺編程語言知識
4) 業務知識
通過以上的分析可以看到，在第一個階段所需知識單一，更多的源自于經驗。由于所使用知識比少，當需求產生變化時，為變化所花費的時間也比較少。因此可以得出一個簡單的結論，當某一個步驟所需知識比較單一時，對該步驟的變更和編碼所需時間都比較少。
那么可以看到在第二個階段，所用知識復雜，所以必須要對第二階段進行細分
在第二階段，通常的做法是，根據業務功能，首先編寫關于這個業務表的增刪改的代碼，再根據表之間的關系寫出數據關系代碼，后根據設計的界面樣式，編寫界面代碼
在這個階段也分成以下幾個步驟
1. 編寫單表的維護代碼
2. 編寫該表與其他表的業務關系代碼
3. 編寫界面代碼
同樣的，再來分析下每個步驟所使用的知識
1. 在編寫單表的維護代碼所使用的知識分為以下幾個部分
1) 數據庫單表操作知識
2) 后臺編程語言知識，僅需要知道如何操作數據庫
3) 業務知識
2. 在編寫該表與其他表的業務關系代碼所使用的知識分為以下幾個部分
1) 數據庫多表查詢知識
2) 后臺編程語言，這里是根據業務的復雜度來決定所使用的知識范圍。
3) 業務知識
3。在編寫界面代碼所使用的知識分為以下幾個部分
1) html知識
2) javascript知識
3) css知識
4) 后臺編程語言，僅使用到與前臺界面編寫相關的部分知識。
5) 業務知識
通過以上分析可以看到，在編寫單表的維護代碼階段是使用知識少的一個步驟，同樣的當業務產生變更時，為該處的變化所用的編碼時間也比較少，而變化所花費的時間與表結構的調整所花費的時間是正比關系。這個關系將在復雜度分析時進一步說明。接下來看編寫該表與其他表的業務關系代碼和編寫界面代碼部分，這個2個階段所使用的知識繁多，并且涉及的知識面也很廣，是項目中花費時間多的地方。但是在實際項目開發中并沒有再對這兩個步驟進行更細的分解的過程。
現在可以得出一個這樣的結論，工作量是與所使用的知識相關的。一個業務所使用的知識點越少，所涵蓋的知識面越少，那么所耗費的工作量也會越少。由此，當需要提高工作效率時，盡量少的使用知識是一種有效的手段。但是在實際情況中，并不能有效的減少知識使用種類，只能在使用知識的熟練度上下工夫，一個開發者所掌握的知識熟練度越高，那么相對的工作量也會越少，一個知識點的入門門檻越低，那么工作量也會越少。因此，設置工作量為G，知識點入門門檻為B，B1為交給新手人員開發的知識點，知識點總數為C，P1為高級開發人數的，P2為新手人數，那么G = ( C - B )/P1 + ( B - B1 ) / P1 + B1 / P2 。
對知識點分析完后，再對業務的復雜度進行分析，知識點的應用可以看作是開發中的橫切方向的話，那業務的復雜度是開發中的縱切方向，業務的復雜度貫穿了所有的開發步驟。
在本文中，從數據的應用著手，來分析業務的復雜度。
在項目開發中，經常要遇到"類型"這樣的業務點，例如職務。對于這一類業務，其主要開發時間花費在"對于單表的增刪改查"上。另一種類型的業務，其復雜度高一點，主要應用于該表需要與另一個表進行組合，然后產生一種"所屬"的關系，例如權限，角色等，其主要開發時間花費在"對于多個表的所屬關系的增刪改查"上。還有一種類型的業務，主要是將多個表的數據進行組合轉換后輸出，例如報表，CMS的模板解析等，其主要開發時間花費在"對于多個表數據的監測和重組上"，后一種類型的業務，主要是為數據附加上狀態，例如工作流等，其主要開發時間花費在"對于數據的不同狀態的處理上"。
以上4點基本涵蓋了做項目時所面對的業務。接下來，我們為這4種業務定一個權值
1.對于單表的增刪改查"權值為1
2.對于多個表的所屬關系的增刪改查"權值為4
3.對于多個表數據的監測和重組上"權值為8
4.對于數據的不同狀態的處理上"權值為16
這個權值的比值基本來自于數據的維度，1類業務是單一緯度。2類業務除了要處理多個1類業務外，還需要處理多個1類業務之間的關系。3類業務除了要處理2類業務中包含的，還需要對數據本身進行轉換處理，4類業務除了要處理3類業務的，還需要處理數據的狀態。后一種業務要比前一種業務多處理一種邏輯結構。
根據這個權值，來看看在項目中經常遇到的情況，以職務為例，開始的需求是1類業務，這個時候客戶的需求變更可能如果制在1類業務的需求范圍內，那么如果完成職務的業務開發時間為1的話，那么修改的時間應該在<=1的開發時間內。但是，這個時候客戶提出一種需求變更，他要求，職務是有從屬關系的，例如A部門有屬于A部門的職務，B部門有屬于B部門的職務，當這類需求出現時，那么開發完成的時間必須提高到4了，從這一種變化可以看出，當需求變更在某一個級別的分類業務內進行變化時，其所完成的單位時間是與權值成正比關系。但是如果需求變更導致該業務的分類級別被提升，那么修改所花費的時間將直接提高到對應業務分類的權值所對應的時間比。
假設工作量為G，權值為D那么G=D(D=1，4，8，16)。再結合前面關于知識點的分析結果，G = D_*( ( C - B )/P1 + ( B - B1 ) / P1 + B1 / P2 ) ( D = 1 ， 4 ， 8 ， 16 )
公式的完全說明如下:
G = D_*( ( C - B )/P1 + ( B - B1 ) / P1 + B1 / P2 ) ( D = 1 ， 4 ， 8 ， 16 )
G : 工作量
D : 業務復雜度( D = 1 ， 4 ， 8 ， 16 )
C : 知識點總量
B : 入門知識點總量
B1 : 交給新手人員做的入門知識點總量
P1 : 高級開發人員數量
P2 : 新手開發人員數量
( C - B ) / P1 : 意思是只能由高級開發人員做的事情
( B - B1 ) / P1 : 意思是由高級開發人員做的只需要入門門檻知識能做的事情
B1 / P2 : 意思是由新手人員做的需要入門門檻知識做的事情
從這個公式可以看出D值越小，C值越小，B值趨向于C值，B1值趨向于B值時，工作量是小的。要想D值小，那么在做需求和需求變更時要引導客戶避免高權值的需求產生。要想C值小，讓開發者只面對少量知識點，是分層開發，每一層的知識點將足夠的小。要想B值趨向于C值，必須使用框架來進行開發，要想B1趨向于B值，應該避免讓僅需入門門檻知識能應付的需求讓高級開發人員來做。
希望這個模型能為項目經理在面對需求和需求變更時提供指導意義，使得在對工作量估算時有據可循。
