影響估算的因素從高到低分別為專案規模，專案類型，人員因素。

1.專案規模

專案規模為影響估算的第一要素，主要原因為專案規模的影響最大，在規模差距過大的情況下用歷史紀錄來評估新的專案最好謹慎一些。

一個簡單的例子就是十萬行(Lines of Code)和一百萬行專案的工作量比例並不等比於十倍(總行數)一樣簡單。

換句話說以兩百人月可完成十萬行的專案，不等於以兩千人月可完成一百萬行的專案。

主要原因就是溝通和連續性問題，而且規模越大的專案其問題會越嚴重。這引起了軟體開發領域領域的有趣現象，”規模不經濟效應”(Diseconomies of scale)。

一般來說生產製造提到的”規模經濟效應(Scale Economies Effect)”，指的是在某個規模中工廠越大，生產線越多，生產成本就會越下降。

軟體開發的”規模不經濟效應(Diseconomies of scale)”卻正好相反，專案規模越大，生產成本反而會越上升。

規模不經濟效應通常只會發生在規模差距過大的專案上，在規模相似(一到五倍之間)的專案上使用平均值來推算工作量，基本上是可以接受的。

假設十萬行的工作量為兩百人月，則平均人月為五百行(十萬除以兩百)。若新專案規模預估為二十萬行(五倍之內)，則可以估計大約是落在390~410人月。

最後要注意當規模差距在合理的範圍(一到五倍之間)，可以使用平均值做為參考基準來推算工作量。但若規模差距過大(五倍以外)，則最好拉大並謹慎評估。

2.專案類型

專案類型為影響估算的第二要素。

類型通常和安全性，可靠性，軟體生命週期等等相關特性有密切的關係。

高度要求安全性和可靠性的軟體(如飛航系統，心臟調節器，公共運輸)比對公司內部的員工網頁，開源軟體等等。對系統各種面向的要求截然不同，其人月平均產出代碼量的差距從十倍到二十倍都有。

還好，通常在同一間軟體公司或同個部門，其開發專案類型的變化不會太大。

原則上也是別把看起來規模相似，但不同類型的歷史紀錄當作參考的唯一基準。換句話說不同類型的專案最好不要混為一談。

3.人員因素

人員因素為影響估算的第三要素。

人員因素包含以下幾種特性表現，需求分析能力，開發者能力(通用)，人員流動頻率，業務領域經驗，開發語言和工具經驗，開發平台經驗，團隊凝聚力。

下方是各項特性的比例圖(原本的比例圖不太好理解，我重新繪製了圖表)

橫軸為上述提到的各項特性種類，縱軸為平均工作量，以50為基準點，代表完成該項工作的期望值。分別以兩種不同顏色的直條代表最好和最差的情況。

先以單項能力來看，差距最大的為需求分析能力，以期望值50為基準點，最好的需求分析能力可以減少29%(79-50)的工作量，最差的需求分析能力必須增加42%(50-8)的工作量。

換句話說若需求分析預期完成的天數為50天，最好的情況只需要35.5天(50 – 14.5)。最差的情況需要71天(50 + 21)

差距最小的為團隊凝聚力，以期望值50為基準點，最好的團隊凝聚力可以減少14%(64-50)的工作量，最差的團隊凝聚力必須增加11%(50-39)的工作量。

換句話說若專案預期完成的天數為50天，最好的情況只需要43天(50 – 7)。最差的情況需要55.5天(50 + 5.5)

從各項數據得到一個結論，專案負責人最好能了解誰是某項工作的最佳人選，特別是在需求分析，開發能力，業務領域，這三項可以掌控的因素盡量挑選合適人選。

另外當專案不得已發生以上各項變動，特別是排名越前面的特性對專案評估的結果影響越大。最好重新評估專案，按照新的排程進行。

結論

影響估算的因素從高而低有3種，分別為規模，類型，人員。
在規模要注意的是差距不大(1~5倍之間)可以推算平均值來評估，反之，最好謹慎進行估算。
在類型要注意的是別把規模類似但類型不同的歷史紀錄做為唯一的參考點。
在人員要注意的是因各項特性變動所造成的影響，最好了解誰是這項工作的最佳人選並對排名前段的特性進行篩選，也要注意當特性發生變動後最好重新進行評估。