【原創】專案估算－專案管理MSN群線上討論（2009.6.30）

今天是專案管理MSN群的第二次集體討論，話題是有關專案估算。今天的討論涉及到：估算的參考資料哪裡來、程式碼行估算的前提、企業規模與估算精度、投標前的估算、如何提高新手的估算精度等內容。以下記錄討論完整過程，已刪去與討論主題無關之內容，方便大家學習與瀏覽。

---

穀雨霖 說:
大家中午好
穀雨霖 說:
很高興大家來“老谷專案管理群”交流
穀雨霖 說:
今天的主題是專案估算
張鵬 說:
中午好
穀雨霖 說:
今天我們有幸請到了
穀雨霖 說:
國內首家通過CMM5認證公司的專案兼質量總監
穀雨霖 說:
王海青先生
穀雨霖 說:
他是CMM/CMMI/ISO等方面的專家，
Cruiser 說:
大家好！
穀雨霖 說:
cruiser就是王專家
穀雨霖 說:
他在專案估算等方面有很強的背景
穀雨霖 說:
下面，我們有請王專家給大家來個開場白
Cruiser 說:
謝謝！第一次上這個群交流，希望能和大家共同學習！
穀雨霖 說:
王總從事軟體管理10多年
穀雨霖 說:
大家可以多挖掘挖掘他的智慧
zxhah@hotmail.com說:
出了什麼成績嗎？
Cruiser 說:
個人在專案估算方面做過一些實踐，目前也在幫一些公司開展專案估算實踐，如果有這方面的問題可以提出來大家一起討論

---

估算的參考資料哪裡來？

husthxd 說:
理論結合實踐，專案估算有些什麼理論？在實踐上又是如何應用的？
husthxd 說:
偶先提個問題
zxhah@hotmail.com說:
我們公司估算一點都不準
  CHINA Scott.Pan 說:
運維專案的估算你是怎麼執行的？
Cruiser 說:
專案估算的基礎是規模估算
husthxd 說:
EN
穀雨霖 說:
好，第一個問題是專案估算有些什麼理論？在實踐上又是如何應用的？
xiyeqing99@hotmail.com說:
對 往往存在估算偏差很大
xiyeqing99@hotmail.com說:
怎麼辦
穀雨霖 說:
其他朋友暫時安靜，謝謝！
Cruiser 說:
目前最主要的方法包括程式碼行、功能點、功能項、用例等
zxhah@hotmail.com說:
規模估算怎麼樣才能更準確呢？？？
穀雨霖 說:
第二個問題運維專案的估算你是怎麼執行的？
xiyeqing99@hotmail.com說:
功能點 有的人1天有的人3天 這個也很難估算呀
Cruiser 說:
歷史資料非常關鍵
Cruiser 說:
因為規模不是目的
husthxd 說:
參考既往的專案經驗？
xiyeqing99@hotmail.com說:
沒歷史資料咋辦
husthxd 說:
那歷史資料需要收集什麼資訊？
xiyeqing99@hotmail.com說:
比如新官上任
husthxd 說:
如何&何時收集？
DeviGe 說:
沒有公司的歷史資料，可以參考行業資料。
Cruiser 說:
用FP方法可以獲得很準確的規模，但如果要估算工作量，必須要有生產率資料
xiyeqing99@hotmail.com說:
生產率資料？
DeviGe 說:
生產率資料，需要公司的長期積累啊。
xiyeqing99@hotmail.com說:
是呀
Cruiser 說:
對，如果沒有本公司資料可以用行業資料
husthxd 說:
Cruiser 說:
目前最主要的方法包括程式碼行、功能點、功能項、用例等。
可以展開來說說嘛？
zxhah@hotmail.com說:
文件中很多頁數是套話 關鍵東西很少
一點紅 說:
對，先展開來說說吧
Cruiser 說:
一般大公司的資料庫都是分層次的
Cruiser 說:
最有效的參考資料是本業務方向的歷史資料
Cruiser 說:
其次是本組織的基線資料
Cruiser 說:
然後是行業資料
rorong0429@hotmail.com說:
問題在於..基於程式碼行的方法..但是程式設計師的水平高低一個月產生的行數不相同呀
xiyeqing99@hotmail.com說:
行業資料
哪裡去弄？
Cruiser 說:
行業資料CSBSG和ISBSG都有一些
一點紅 說:
行業資料的準確效能保證麼？
穀雨霖 說:
CSBSG和ISBSG是國內和國際基準資料組織

---

程式碼行估算的前提

husthxd 說:
1.目前最主要的方法包括程式碼行、功能點、功能項、用例等。最好可以再深入展開談談  2.關於歷史資料的收集，需要收集什麼資料？如何收集

Cruiser 說:
估算的結果其實是一個概率，也就是能夠按照計劃完成的可能性
Cruiser 說:
關於程式碼行，大家可能都比較熟悉，但很多公司其實並未真的用這種方法開展估算，只不過會在專案結束後統計程式碼行數
xiyeqing99@hotmail.com說:
那估算不準 就完了
Cruiser 說:
在一個組織內，程式碼行明確的定義也很重要
xiyeqing99@hotmail.com說:
是呀 程式碼行 總得專案做完菜知道吧
husthxd 說:
程式碼行估算個人覺得是不準確的，一行勝千言，水平高的程式設計師寫得程式碼不見得比初級的多 
husthxd 說:
程式碼行跟演算法有關。
一點紅 說:
王總，您先說說您是怎麼根據程式碼行估算的
Cruiser 說:
例如註釋算不算？重用怎麼算？if... then 這樣的語句寫在兩行算幾行等？
DeviGe 說:
為了積累資料等，等專案結束時，建議進行再估算 -- 核算。
husthxd 說:
不知道程式碼行估算用的多不多，呵呵，至少我們沒用過。那，功能點、功能項和用例呢？
Cruiser 說:
我個人的經驗，在一個成熟的組織內，很多規模估計的方法都可以比較準。比如我以前帶過的專案，規模在百萬行程式碼左右，用功能項數、程式碼行、甚至需求文件頁數估算的誤差

都在15%以內
Cruiser 說:
但問題在於，有些方法是很難在不同專案或不同企業間進行基準比對的
Cruiser 說:
比如功能項數或文件頁數
Cruiser 說:
每個公司文件的模板、撰寫規程不一樣，資料差別就很大

---

企業規模與估算

husthxd 說:
呵呵，王總您也提到了“在一個成熟的組織內”，...都比較準。
rorong0429@hotmail.com說:
那你這種方法只能用在企業已經達到CMM3了
xiyeqing99@hotmail.com說:
如果是小公司咋辦
husthxd 說:
這個“成熟的組織”會引起其他很多問題的。
Cruiser 說:
也未必，三級的組織強調統一過程能力
穀雨霖 說:
大家對估算要有理性認識，估代表著不確定性。要在一定資料基礎上的估算才有效
xiyeqing99@hotmail.com說:
那這個專案經理室剛上任的咋辦？
Cruiser 說:
有些二級甚至連二級鬥不是的組織中的專案，如果自身資料積累比較好，也可以開展有效的專案估算
xiyeqing99@hotmail.com說:
沒有一定資料基礎的呀
Cruiser 說:
還有，目前很多專案採用迭代開發
DeviGe 說:
沒有經驗資料的，就靠各位逐漸積累。
husthxd 說:
迭代開發，每個迭代都可以單獨做出估算把？
Cruiser 說:
按照我的經驗，專案前期迭代中採集的資料分析結果，對於後期專案估算很有幫助
Cruiser 說:
在我原來的公司中，專案估算規程要求迭代開發的專案，在每次迭代後都要重新估算以精化結果
Cruiser 說:
估算也是一個逐步求精的過程
Emily 說:
贊同
Cruiser 說:
即使在所謂5級的組織，專案策劃階段、需求分析之後以及編碼完成之後的估算結果都會不同
xiyeqing99@hotmail.com說:
對的
xiyeqing99@hotmail.com說:
ibm就是這樣的
sue_huangyong@126.com說:
會不會不同的階段的估算方法不同呢
Cruiser 說:
有的公司是採用混合的方法。比如很多公司大量的資料是基於程式碼行的，但是程式碼行在專案早期估算難度很高
sue_huangyong@126.com說:
前期主要是什麼估算方式呢
Cruiser 說:
所以前期會採用功能項等方法
xiyeqing99@hotmail.com說:
是呀 程式碼行在專案早期估算難度實在太高了
sue_huangyong@126.com說:
能具體說下嗎
Cruiser 說:
後期（如設計完成）可以結合功能點修正估算結果

---

功能項？功能點？FP？

xiyeqing99@hotmail.com說:
功能項 功能點是一個概念嗎？
husthxd 說:
用功能項等方法估算有沒有算管理成本？比如同行成本、程式碼複審等成本？
Cruiser 說:
功能項 功能點不是一個方法
一點紅 說:
同意，不過王總你說的都是“之後”非常準確了，但是“之前”的估算如何保證準確？
sue_huangyong@126.com說:
區別在？
xiyeqing99@hotmail.com說:
準確肯定談不上 最多是偏差比較少
xiyeqing99@hotmail.com說:
別人加班通宵 你加班3小時 哈哈
一點紅 說:
xiyeqing99@hotmail.com說:
 準確肯定談不上 最多是偏差比較少
同意！！！
sue_huangyong@126.com說:
功能項如何估算呢
Cruiser 說:
功能點是有國際標準的，但是他是將軟體的功能按照特定的方法進行分類和轉換，最後得到一個邏輯值
穀雨霖 說:
功能項 功能點如果都是FP的翻譯，沒區別。這裡說的功能點估算方法是有國際標準的
sue_huangyong@126.com說:
問個低階問題，哪個國際標準啊
Cruiser 說:
而所謂功能項就是我們在需求規格中看到的一條條功能
穀雨霖 說:
如流行的IFPUG（美國）
穀雨霖 說:
還有英國、荷蘭等體系
sue_huangyong@126.com說:
用一句話概括下原理好嗎
DeviGe 說:
線，IFPUG用的最廣
xiyeqing99@hotmail.com說:
那就是需求了老
Cruiser 說:
一般功能項是指 feature point
穀雨霖 說:
IFPUG劃分了5種邏輯功能。對每種邏輯功能按照它所涉及到的資料數量和互動數量通過查表來確定邏輯複雜度，以及功能點數。
Cruiser 說:
功能點是function point
穀雨霖 說:
COSMIC劃分了4種邏輯邏輯功能， 避免了查表的侷限性和不能體現大批量資料互動的複雜情況。
Cruiser 說:
從某種意義上說功能項並不是一種“科學”的方法
Cruiser 說:
因為沒有統一標準
xiyeqing99@hotmail.com說:
那還是功能點用的多老
Cruiser 說:
所以每個組織在實踐時差別很大
zxhah@hotmail.com說:
哪4種邏輯功能
穀雨霖 說:
其他的不在這裡統一描述，大家可以網上搜素下。
sue_huangyong@126.com說:
這個對專業技術要求很高啊
穀雨霖 說:
FP理論要學習一小段時間的
Cruiser 說:
也無法進行行業基準比對
xiyeqing99@hotmail.com說:
FP理論到底是撒理論
xiyeqing99@hotmail.com說:
為什麼網上沒有？
husthxd 說:
理論知識是需要補補的。
穀雨霖 說:
FP估算人員需要進行一致性訓練，即他是專職的
sue_huangyong@126.com說:
做這個似乎要求需求詳細到一定程式時才可以估算吧
穀雨霖 說:
才有效
Cruiser 說:
關於FP在國內應用範圍很小，對他的一些不切當宣傳也造成了不好的效果
Cruiser 說:
FP也可以做早期估算
husthxd 說:
早期估算可能很不準。
sue_huangyong@126.com說:
可是早期的功能項可能不會那麼具體的啊
husthxd 說:
因為早期需求是不穩定或者是不清晰的。
Cruiser 說:
按照IFPUG的宣傳，最早期的估算也可以達到50%以內的精度，而在需求規格確定後，精度是10%
Cruiser 說:
不過這裡偷換了一個概念

---

投標前的估算

husthxd 說:
王總，想問問，投標前的估算一般用何種方法？
sue_huangyong@126.com說:
同問
xiyeqing99@hotmail.com說:
精度是10%
這要有一定得功力了
husthxd 說:
這時候只有招標檔案&客戶反饋的零星資訊。
xiyeqing99@hotmail.com說:
是呀
Cruiser 說:
也就企業只得到所謂精確的規模是沒有意義的，還需要知道由此匯出的工作量
穀雨霖 說:
這是關鍵
Cruiser 說:
可以用FP方法進行投標前的估算，規模精度可以控制在20%左右
Cruiser 說:
但工作量精度取決於歷史資料
husthxd 說:
20%左右是個比較理想的數字了。
xiyeqing99@hotmail.com說:
很理想了
xiyeqing99@hotmail.com說:
上次我們去報價第一次報了1000萬 第二輪報了500萬
husthxd 說:
沒有歷史資料，行業標準或基準又難以獲取，這時候如何評估？
Cruiser 說:
企業如果有一些積累，投標時也可以基於功能項和程式碼行
不勝人生一場醉(2009年春節，茫然中...) 說:
個人感覺
fp只能解決業務功能部分的評估
對於整合和涉及一些新特性新技術的評估是無法解決的
husthxd 說:
比如涉足新行業，使用新技術開發新系統
Cruiser 說:
現在很多甲方專案的問題在於甲方在招標的時候也沒有明確的專案範圍
Cruiser 說:
這樣在估算時就很麻煩
不勝人生一場醉(2009年春節，茫然中...) 說:
業務功能的評估帶有普遍性
husthxd 說:
“現在很多甲方專案的問題在於甲方在招標的時候也沒有明確的專案範圍”，太多這樣的專案了。
穀雨霖 說:
看來大家需要一定深度的FP科普。FP是一種將模糊變為數字的手段、方法，輸入資訊不夠，估算是徒勞的。
Cruiser 說:
所以昨天我和四所的專家在交流交付保障的時候還提到。客戶有明確的工期、固定的預算這種現實情況客觀存在，高成熟的公司要做到把這種工期和費用下可以交付的產品質量和功能範圍想清楚
不勝人生一場醉(2009年春節，茫然中...) 說:
FP在業務需求確認後作工作量評估是高效的
husthxd 說:
那就是說，如何input不夠，是不能用fp方法了？
不勝人生一場醉(2009年春節，茫然中...) 說:
對投標和解決方案時的評估不見得有用
husthxd 說:
這時候是否有其他方法？
Cruiser 說:
按照現在我所見大部分招標，至少可以做50%精度的規模估算，相當一部分可以做20%
穀雨霖 說:
可以，但精度會比較低，但比拍腦袋好的多。同時，如果是個同類專案，那麼專家經驗類比法，比初期使用FP精度還要高。
husthxd 說:
相對的估算準確點的。不過，輸入資訊不足，估計用什麼方法都不準確
Cruiser 說:
但工作量估算要難一些
Cruiser 說:
所幸軟體專案的質量彈性比較大
husthxd 說:
質量是相對的
穀雨霖 說:
他是將你拍腦袋的思考，展現給大家一起評審的辦法之一。
chinamathman@hotmail.com說:
非 常認同王總前面講的。我的理解，專案估算有兩個重要目的：一個是用於專案本身的成本估算，也就是說企業首先得知道做這個專案得花多少錢，多少人力成本及其 它資源；另一個目的是為了給客戶報價提供客觀依據，現在的客戶也都對行業價格比較瞭解，往往還會貨比三家，所以報價的客觀依據對客戶是重要的參考。我的經 驗來看，客戶一般對程式碼行不感興趣，因為這裡面可能水分很大，客戶也不可能真的來檢查你的程式碼；功能項卻是一個很直觀的東西，客戶驗收的時候也看得見摸得 著，在貨比三家的時候，客戶也一般會拿著功能項來比各家的報價。
Cruiser 說:
估算不準的代價一般是乙方通過加班承擔一部分，甲方通過犧牲質量承擔一部分，可能還是一大部分
不勝人生一場醉(2009年春節，茫然中...) 說:
所以大部分評估是建立在工期*人月+歷史資料的基礎上的
Cruiser 說:
現在國外有些甲方會引入第三方進行專案範圍管理，這樣基於FP方法的估算就很必要了
一點紅 說:
TOchinamathman@hotmail.com但是現在很多公司為了中標，往往誇大了標書內容
husthxd 說:
估算不準往往是乙方需要追加預算。
Cruiser 說:
但是很多甲方（尤其是政府）是預算制的，很難增加預算

---

關於專家經驗

穀雨霖 說:
估算方法很多，如果公司有個同行業10年以上的專家，那他的直接估計比其他辦法更有效的
Cruiser 說:
所以乙方只能在報價時打出餘量
穀雨霖 說:
加富裕量，這個是要業務人員一起參與的
sue_huangyong@126.com說:
甲方一般會直接往下砍 ，血淋淋地
DeviGe 說:
確實，乙方報價都需有緩衝量。
穀雨霖 說:
不是純粹技術問題，我們不要參合到一起
xiyeqing99@hotmail.com說:
有個同行業10年以上的專家，那他的直接估計比其他辦法更有效的 那說白了 還是要有專家
穀雨霖 說:
討價還價不在FP範疇
Cruiser 說:
專家經驗的問題就是難以複製
sue_huangyong@126.com說:
其實專家心裡也有一個模板
穀雨霖 說:
如果沒有專家怎麼辦？FP可以幫你理性估算
chinamathman@hotmail.com說:
To 一點紅：確實如此，但是乙方必須得有自己的底線，總不能賠錢做買賣吧，在底線的基礎上又不能報價過高，否則就會被競爭對手擠掉。
穀雨霖 說:
這就是不同的辦法
husthxd 說:
專家經驗都在人的腦子裡面  人走了，經驗也沒了。
一點紅 說:
同意
xiyeqing99@hotmail.com說:
那有一個專家 不都結了
穀雨霖 說:
站著說話不腰疼是不
穀雨霖 說:
呵呵，專家是稀缺資源
火星人 說:
現在流行知識管理.
husthxd 說:
呵呵，人都會犯錯的，所以需要同行評審。
xiyeqing99@hotmail.com說:
一個公司要有個專家
DeviGe 說:
用估算模板等專家知識留下。
Cruiser 說:
而且專家經驗還有一個問題，就是他的很多假設也都在腦子裡，而在估算過程中，假設非常重要
穀雨霖 說:
對  專家也要犯錯誤的  風險太大
一點紅 說:
那好似不是要配備多個專家？
Cruiser 說:
所以一個好的估算過程需要記錄假設條件，然後在每個關鍵里程碑檢查
xiyeqing99@hotmail.com說:
成本太高了吧
sue_huangyong@126.com說:
歷史經驗包括哪些資料或資訊
husthxd 說:
可以臨時外聘
Cruiser 說:
也沒有太多成本，其實就是會上過一下就可以了
穀雨霖 說:
這就是為何政府招標要一群專家評審方案
Cruiser 說:
現在很多公司基於ＷＢＳ進行工作量估算，這就是典型的基於經驗
xiyeqing99@hotmail.com說:
ＷＢＳ進行工作量估算 是基於經驗的啊

rorong0429@hotmail.com說:
只有大型專案才這樣子..一個幾十萬的專案.肯定不能這樣子做.
xiyeqing99@hotmail.com說:
很多公司是這樣的
Cruiser 說:
但即使採用這種方法，我們也可以將一些要點寫入估算指南，提高新手的估算精度

---

如何提高新手的估算精度

一點紅 說:
王總，那您說說如何提高新手的估算精度？我是新手，呵呵
Cruiser 說:
例如，很多專案經理在估算專案後期工作量的時候，對於各角色的返工工作量就考慮不足
rorong0429@hotmail.com說:
是的...講一下中型專案一般的估算方法.和流程..注意事項
Cruiser 說:
還有很多專案經理不會考慮專案管理及支援活動的工作量
husthxd 說:
比如同行評審、程式碼複審等工作量？
rorong0429@hotmail.com說:
需要高質量軟體工程師.這樣返工量比較小
sue_huangyong@126.com說:
嗯，這個也要包含在內
Cruiser 說:
或者認為一個任務需要２個人做４個月，那麼４個人２個月就可以做完
rorong0429@hotmail.com說:
不對..
husthxd 說:
說到人月，不同的“人”會出現不同的人月數。
rorong0429@hotmail.com說:
新增人就需要增加人與人之間的交流時間
Cruiser 說:
嗯，對
DeviGe 說:
這個可不一定啊：“一個任務需要２個人做４個月，那麼４個人２個月就可以做完”
一點紅 說:
王總，我也同意您說的人月神化是不現實的，不過感覺您說的還是經驗比較重要
chinamathman@hotmail.com說:
同意husthxd
Cruiser 說:
我覺得資料比經驗重要，經驗比方法重要
rorong0429@hotmail.com說:
或者認為一個任務需要２個人做４個月，那麼４個人２-3個月有可能完成.
husthxd 說:
工作量估算的時候，如何把這個”人“定下來？
sue_huangyong@126.com說:
所以啊，要歸檔哪些經驗作為參考資料呢
Cruiser 說:
但當什麼都沒有的時候我們只好改進方法了？
Cruiser 說:
對嗎？
DeviGe 說:
各種估算方法，就是經驗的積累與體現。
husthxd 說:
按高階程式設計師去評估還是中級程式設計師去評估結果是大不一樣的。
xiyeqing99@hotmail.com說:
初級程式設計師就更不一樣了
Cruiser 說:
對於越小的專案，個體生產率的差別影響越大
xiyeqing99@hotmail.com說:
不同的程式設計師之間 效率相差10被以上
sue_huangyong@126.com說:
所以還要結合人力資源計劃
Cruiser 說:
對於大專案，這種差異就被稀釋了
aquarian -  China 庸人自擾 說:
我覺得估算的時候是按照一個標準，然後在根據程式設計師的分級用係數加以修正
husthxd 說:
對，個體生產率的差別會很大。
Cruiser 說:
可以，有的公司是這麼做的
Cruiser 說:
不過要建立一套科學的估算模型需要大量的資料
Cruiser 說:
所以我的建議是，如果沒有大量資料，就儘可能用最簡單的模型
husthxd 說:
呵呵，歷史經驗的總結很重要了
穀雨霖 說:
人員水平的處理，分1、2、3級是比較好的一個方法。將人的能力靠這1、2、3級，剩下的通過人能動性去處理。
sue_huangyong@126.com說:
要總結什麼啊
rorong0429@hotmail.com說:
是的.. 需要建全這些東西..需要軟體公司到少要達到300人以上呀.
穀雨霖 說:
錯
穀雨霖 說:
與規模沒有直接聯絡
husthxd 說:
跟規模沒有多大關係了。
Cruiser 說:
未必公司人多，如果專案的持續性好也可以
穀雨霖 說:
在於有沒有意識做這個工作
Cruiser 說:
對於人又少，專案型別又差異很大的公司積累資料確實難一些
一點紅 說:
 所以我的建議是，如果沒有大量資料，就儘可能用最簡單的模型--能具體一點麼，王總？
DeviGe 說:
沒有模型的，可以先定一個，執行---〉完善--〉再執行。
穀雨霖 說:
10個人的公司，沒有專家，有3個專案經驗。第四個專案的估計也會做得很好（同行業的）
穀雨霖 說:
同意devige
rorong0429@hotmail.com說:
不一定.
Cruiser 說:
最簡單的就是　工作量＝生產率＊規模　對吧？
sue_huangyong@126.com說:
對於甲方來講，生產率得不到哦
rorong0429@hotmail.com說:
有一些公司搞了三四年..都沒有很 的估算
Cruiser 說:
甲方也可以從ＣＳＢＳＧ得到行業資料
rorong0429@hotmail.com說:
得到資料需要收錢的不

---

招標與估算

Cruiser 說:
例如在國外的一些甲方，會用行業資料算出專案的報價上下限，最高或最低的報價都會在第一輪被淘汰
xiyeqing99@hotmail.com說:
最低的報價 也要淘汰？
Cruiser 說:
其實這是一種統計原則，不是說報價超低的公司一定做不好這個專案，只是說他能夠完成的概率較低
rorong0429@hotmail.com說:
取低的認為是壓低價格來獲得標..這樣是不道德的
Cruiser 說:
比如招標時以P25 和P75 為限
 rainedviolet（分機恢復399） 說:
避免行業低價競爭，惡性迴圈吧
Cruiser 說:
對
Cruiser 說:
這樣最終會是雙贏的結果
穀雨霖 說:
我相信只要組織有意識，系統、認真的積累資料，估算會越來越精細
Cruiser 說:
長期來看，中標的會是符合甲方預算且質量最好的公司
Cruiser 說:
而不是最便宜的公司或最高質量的公司
Cruiser 說:
所以對於甲方來說ＲＯＩ是最好的
穀雨霖 說:
估算對公司是乾貨，投標需要參水的，參多少不是技術人員的範疇
穀雨霖 說:
我們一定要分看這個問題
 rainedviolet（分機恢復399） 說:
同意，對腦力勞動的預估，有難度，但並不是肯定做不到的
Cruiser 說:
嗯，摻水的事商務人員定
Cruiser 說:
不在估算範疇了
rorong0429@hotmail.com說:
是的..不參水..公司怎麼活咯
xiyeqing99@hotmail.com說:
商務人員=銷售？
Cruiser 說:
或者是客戶經理吧，不同的公司職責定位不一樣
DeviGe 說:
估算，就是為了更好、更有把握摻水。
穀雨霖 說:
技術做好基礎的基本功，業務做業務的工作。專案拿下來是幾個經理一起溝通商定的結果
Cruiser 說:
因為很多公司對專案有毛利要求，而市場人員可能是覺得能簽單就行

---

結束語：FP功能點實踐手冊下載

穀雨霖 說:
我想專案估算不是我們今天1小時能夠討論清楚的，這個專題需要多次交流會更有效。
穀雨霖 說:
我建議大家下面科普科普什麼FP\WBS等理論，我們再安排個時間進行交流。
穀雨霖 說:
線下的老谷專案管理沙龍活動，有功能點估算的專題，在北京的可以關注後續活動。
穀雨霖 說:
首先今天非常感謝王總專程來專案管理群和大家一起交流。下面的時間我們可以再進一步交流。
穀雨霖 說:
我在itpub網站上上傳了一份FP功能點實踐手冊，大家可以去看看。希望對大家有啟發。
穀雨霖 說:
http://www.itpub.net/viewthread.php?tid=1180510&page=1&extra=#pid13795783
穀雨霖 說:
總之，工具是要根據具體情況來選擇的，沒有一招先的方法。
穀雨霖 說:
今天王總對專案估算做了初步的闡述
穀雨霖 說:
對FP做了較詳細的初步解釋
穀雨霖 說:
FP對企業來說
穀雨霖 說:
需要培養3-5個成手
穀雨霖 說:
這樣對公司的估算會比較統一，一致。
穀雨霖 說:
好了，在這再次感謝王總
穀雨霖 說:
感謝大家！

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/3433/viewspace-608322/，如需轉載，請註明出處，否則將追究法律責任。