網(wǎng)站建設(shè)現(xiàn)在是一個信息的載體，把有用的信息傳播給需要的人。網(wǎng)站建設(shè)包括軟件。在擔(dān)任多起軟件訴訟案件專家證人的工作中，筆者注意到一個長期存在的軟件項目管理問題。許多失敗的項目，以及進度嚴重延誤或重大質(zhì)量問題的項目，都是在開發(fā)過程中通過正常的進度報告發(fā)現(xiàn)的。從各種證人證言和案件證據(jù)中可以看出。軟件工程師和一線項目經(jīng)理都知道自己的項目存在問題，但是當(dāng)這些問題第一次被發(fā)現(xiàn)時，項目經(jīng)理并沒有將這些問題寫入給客戶的報告和高層的狀態(tài)報告中。直到很久以后，當(dāng)嚴重的進度延誤、質(zhì)量問題或其他重大問題真正被高層管理人員或客戶認識到時，情況往往是不可逆轉(zhuǎn)的。

當(dāng)被問及為什么要隱藏項目中存在的問題時。我得到的大部分答案是，下級管理人員不希望高級管理人員看到項目的糟糕狀態(tài)。當(dāng)然，當(dāng)問題最終浮出水面時，底線管理人員實際上相形見絀。成功的軟件項目總是以更理性的方式處理項目中的問題。他們及早發(fā)現(xiàn)問題，組建專門的工作組來解決問題，并經(jīng)常在問題變得嚴重到無法解決之前將其控制住。敏捷方法的一個有趣特征是每天討論項目中的問題，團隊軟件過程(TSP) 也是如此。

軟件項目的問題有點像嚴重的醫(yī)療問題。它們通常不會自行消失，需要許多專業(yè)的“療法”才能消除它們。軟件項目的問題有點像嚴重的醫(yī)療問題。它們通常不會自行消失，需要許多專業(yè)的“治療”才能擺脫它們。軟件項目啟動后，通常沒有固定、可靠的準則來判斷項目的實際進展速度。民用軟件行業(yè)長期以來一直使用特定的里程碑來確定項目進度，例如設(shè)計完成或編碼完成。但這些里程碑也是出了名的不可靠。

軟件項目狀態(tài)跟蹤需要解決以下兩個不相關(guān)的問題：(1) 達到特定的、定義的里程碑； (2) 在規(guī)定的預(yù)算金額內(nèi)使用項目資源和資金。由于軟件項目里程碑和成本受到需求變更和“范圍擴展”的影響，因此擴大需求變更變得很重要，因為這些變更會影響功能點的總數(shù)。但是，正如本章上一節(jié)所述，一些稱為“需求波動”的需求變化并不影響功能點總數(shù)，而需求蠕變和需求波動往往是隨機出現(xiàn)的。需求波動比需求蠕變更難衡量，只能通過“回火分析”或程序代碼語句數(shù)與功能點指標之間的數(shù)學(xué)換算來衡量。

截至2009 年，有許多自動化工具可以幫助項目經(jīng)理記錄項目里程碑報告所需的各種重要信息。這些工具能夠記錄項目進度、資源、規(guī)模變化和各種項目問題。對于一個擁有60 年悠久歷史的行業(yè)來說，沒有一套通用或通用的項目里程碑來標記項目的實際進展，這多少有些令人驚訝！

我們專注高端建站，小程序開發(fā)、軟件系統(tǒng)定制開發(fā)、BUG修復(fù)、物聯(lián)網(wǎng)開發(fā)、各類API接口對接開發(fā)等。十余年開發(fā)經(jīng)驗，每一個項目承諾做到滿意為止，多一次對比，一定讓您多一份收獲！