四、軟件開發(fā)項目計劃的常見問題分析

有人說：“做項目計劃，如同給一個待出生的嬰兒寫傳記那樣困難。如果允許項目結(jié)束后再寫計劃，那輕松多了，并且可以 地準確”。確實是這樣，為什么項目的計劃這么難呢？

在軟件開發(fā)項目實踐中，關(guān)于計劃主要有以下一些常見問題：

1、項目目標不夠清晰明確

這實際上在軟件開發(fā)項目中是一個普遍的現(xiàn)象。缺乏詳細的工作目標以便在項目結(jié)束時驗證是否取得了預(yù)期的成果。對于軟件開發(fā)項目而言，在進度、任務(wù)范圍、質(zhì)量、成本等項目目標中，進度是容易清晰明確的，也是用戶為關(guān)心的。不管是獻禮工程或一把手工程，進度都是項目目標諸多方面中先制定的，并且能夠很快在招標文件或合同中訂下來。當然，這種進度的合理性未必是經(jīng)得起考驗的。而統(tǒng)計數(shù)字事實說明，大部分的軟件開發(fā)項目的進度是不合理的。無論是急于求成的客戶還是缺乏軟件開發(fā)經(jīng)驗和軟件工程知識的項目經(jīng)理都存在對進度過于樂觀的問題，其原因較多是因為他們對項目范圍的認識是在一種比較粗的顆粒度基礎(chǔ)之上。大多數(shù)的軟件開發(fā)項目在開始階段可能存在項目范圍不夠清晰的問題，需要經(jīng)過需求調(diào)研之后才可以清晰。質(zhì)量目標是不容易清晰和明確的，這主要是因為軟件系統(tǒng)的質(zhì)量量化比較難。由于質(zhì)量目標的不確定性，它在進度、成本、范圍等目標的壓力之下很容易被忽視。這似乎說明了，質(zhì)量目標是這些目標中不重要的一個，有可能被犧牲的一個。成本目標可能用戶方面不太關(guān)心，確實軟件開發(fā)組織為關(guān)心的，軟件開發(fā)的成本主要是人力資源的成本，其他的設(shè)備基礎(chǔ)設(shè)施都是可以重復(fù)使用的。所以，在進度、任務(wù)范圍、質(zhì)量明確以后，人力資源的成本可以經(jīng)過經(jīng)驗等方式估算出來。

2、對編寫計劃的過程在思想意識上重視不夠

實際上是對項目計劃的重要性認識還不夠充分，雖然大家都知道知道“作計劃”很重要，是項目成功的關(guān)鍵，但又認為計劃是寫文檔，也許是因為一些人善于寫程序但不善于寫文檔，所以有些項目經(jīng)理會認為寫文檔是一種走形式，或?qū)Ψ爆嵉奈臋n有一種排斥心理。其實不能把計劃當成僅僅是寫一個計劃文檔的問題，而是要通過編寫計劃文檔的過程，理清項目目標、項目范圍、項目所需資源、制定合理的項目進度、制定完成項目所需的各種約定（溝通、變更）、制定應(yīng)對風(fēng)險的有效對策。對于這一問題的解決，首先應(yīng)當提高項目經(jīng)理的計劃意識，采用項目計劃制定相關(guān)各種知識、技術(shù)、工具，加強對開發(fā)計劃、階段計劃的有效性進行事前事后的評估與評審工作。

3、制訂計劃時沒有進行充分的溝通

項目經(jīng)理制訂計劃時沒有和項目主要成員和主要項目干系人共同討論協(xié)商，達成共識；或者終計劃沒有發(fā)布到所有相關(guān)的項目干系人，取得他們的認同、理解，重要的是對計劃中共同責(zé)任、目標和各自責(zé)任、目標的承諾；由此而造成的后果是：項目計劃缺乏項目組成員的支持，沒有成為項目組成員的共識，沒有使每個項目組成員努力實現(xiàn)在項目計劃中所作的承諾。因此項目經(jīng)理制訂計劃時首先要分清或確定主要項目成員和主要項目干系人，然后與他們進行充分的溝通協(xié)商，使項目計劃是一個大家都認同的，形成共識的有效文件。

一種更為嚴重的情況是遺漏了重要的項目干系人。在制定計劃時沒有考慮到所有項目干系人，特別是那些對于項目的成敗有重要影響的項目干系人，在制定計劃時要和他們進行充分溝通取得對項目進度、資源、驗收標準等計劃的共識和保證。

4、對總體計劃、階段計劃的作用認識不足

項目經(jīng)理認為計劃不如變化快，項目中也有很多不確定的因素，做計劃是走過場，因此制定總體計劃時比較隨意，不少事情沒有仔細考慮，或者是有一種等一下再說的想法；階段計劃因工作忙等理由經(jīng)常拖延，造成計劃與控制管理脫節(jié)，無法進行有效的進度控制管理。那些號稱“所見即所得”的OA，邊做、邊提需求、邊改、邊完善的“四邊形”的所謂“快速”軟件開發(fā)也可能竟然是本企業(yè)周期延續(xù)長的項目，因為無休無止的需求變更而永無止境。從項目的計劃階段來看，因為邊做、邊提需求、邊改、邊完善，所以他們首先對計劃沒有信心，基本上計劃對他們來說只是應(yīng)付，久而久之，對計劃方面的鍛煉意識不如其他項目，甚至養(yǎng)成不容易改掉的習(xí)慣。

5、任務(wù)和職責(zé)劃分不夠清晰或有遺漏

目標、任務(wù)的分解不夠清晰、工作有遺漏，沒有確定項目組成員職責(zé)的差別，如程序員的職責(zé)都籠統(tǒng)地寫成“編碼”。其主要原因是一些新任的項目經(jīng)理是由程序員提拔起來的，不太熟悉軟件工程各階段工作職責(zé)中某些具體工作的分配，無法按任務(wù)分清每個人的責(zé)任。如應(yīng)該分清楚需求人員該做什么、設(shè)計人員該做什么、編碼人員該做什么、測試人員該做什么。責(zé)任似乎很容易分清，但大家卻經(jīng)常聽到“這是需求的事”、“這是設(shè)計的事”這樣的爭論，嚴重的造成項目組內(nèi)部的糾紛扯皮。是因為這些新的項目經(jīng)理對一項具體工作，如界面設(shè)計、數(shù)據(jù)規(guī)格等應(yīng)該由需求分析人員來做，還是設(shè)計人員來做分不清楚，還有是做到什么程度算概要設(shè)計，什么程度算詳細設(shè)計，職責(zé)上也要搞清楚。建議新上任的項目經(jīng)理應(yīng)該多學(xué)習(xí)軟件工程的相關(guān)知識。

6、項目任務(wù)分工或進度計劃表的顆粒度太大

常見的現(xiàn)象有對任務(wù)持續(xù)時間進行不切實際的估計；或未考慮到任務(wù)的相互依賴關(guān)系而造成遺漏工作。其主要原因是軟件工程的分析與設(shè)計經(jīng)驗的不足，無法細化系統(tǒng)需求，并從需求推導(dǎo)出設(shè)計，根據(jù)設(shè)計去分配任務(wù)。根據(jù)細化的需求也可以分配任務(wù)，但是由于需求中的功能點和設(shè)計中的模塊往往不是一一對應(yīng)的，如一個需求功能點需要一系列的模塊來實現(xiàn)，多個需求功能點也可以共用同一組模塊加上不同的設(shè)置參數(shù)來實現(xiàn)。所以根據(jù)設(shè)計來確定程序代碼階段的任務(wù)分配比較合理。需求是整個項目的基礎(chǔ)、需求的清晰顆粒度對后面的工作及工作計劃的準確性至關(guān)重要。項目計劃的準確度是以一開始以需求（包括設(shè)計層需求）為基礎(chǔ)得出的工作結(jié)構(gòu)分解的完整性、清晰性為基礎(chǔ)的。如果沒有這個基礎(chǔ)，項目計劃不可能做得很準確。在無法準確制定項目計劃的情況下，對其風(fēng)險要足夠重視，并制定出具體可行的對策。如果對整體的需求或工作結(jié)構(gòu)分解無法一次完整的清晰，應(yīng)當把它先分解為幾個大塊，分塊進行，已經(jīng)清晰的先制定本塊（階段）計劃，下一環(huán)節(jié)的工作也可以開始（分塊）進行。再項目開始階段往往還沒有得到詳細的需求成果，因此根據(jù)項目計劃漸進明晰的特點，在需求調(diào)研分析階段過后，需求成果清晰是，應(yīng)當及時細化項目計劃，在概要設(shè)計完成時，要更進一步地細化后面編碼測試階段的詳細計劃。

7、與上一種情況相反的是計劃表的顆粒度太細

是說軟件開發(fā)的工作雖然可以被劃分為若干階段，但是這些階段不應(yīng)該是整齊劃一的。雖然每個環(huán)節(jié)階段成果是下一環(huán)節(jié)階段成果的基礎(chǔ)，但即使在階段成果通過評審之后下一環(huán)節(jié)對上一環(huán)節(jié)也應(yīng)當隨時進行檢查驗證，上一環(huán)節(jié)根據(jù)下一環(huán)節(jié)的驗證檢查情況進行調(diào)整。在上一環(huán)節(jié)沒有得出可以供下一環(huán)節(jié)開展工作的基本成果時，下一階段的投入可能是浪費時間。“按任務(wù)分清每個人的責(zé)任”并不是說上一環(huán)節(jié)的人員在初次完成本環(huán)節(jié)后交給下一環(huán)節(jié)了事了，而應(yīng)該繼續(xù)與下一環(huán)節(jié)的人員共同作戰(zhàn)、相互影響、不斷進行同步完善，及時地解釋和調(diào)整上一階段的成果。如果上一階段與下一階段的負責(zé)人是同一個人，沒有這方面的問題，但是在實際工作匯報時要考慮到在某個階段可能進行著前一個階段或后一個階段的工作。

8、資源需求沒有經(jīng)過較為周密的估算

軟件開發(fā)項目的資源因為因為其自身的特點和受到各種因素的影響，很難做到“精確”。盡管如此，還是應(yīng)該盡可能地做到“周密”。需要重點考慮的軟件開發(fā)項目的資源主要是人力資源，沒有盡可能足夠詳細精確地估計整個項目的每個階段所需要的人時（或人日、人月）數(shù)；這是因為對軟件開發(fā)的工作量沒有進行精確的估算。為了估算軟件開發(fā)項目的工作量和完成期限，首先需要根據(jù)較為完整的需求來預(yù)測軟件規(guī)模。度量軟件規(guī)模的常用方法有、代碼行估算法和功能點估算法。這兩種方法各有優(yōu)缺點，應(yīng)該根據(jù)軟件項目的特點選擇適用的軟件規(guī)模度量方法。根據(jù)項目的規(guī)模可以估算出完成項目所需的工作量，我們可以使用一種或多種技術(shù)進行估算，這些技術(shù)主要分為兩大類：分解和經(jīng)驗建模。分解技術(shù)需要劃分出主要的軟件功能，接著估算實現(xiàn)每一個功能所需的程序規(guī)�；蛉嗽聰�(shù)。經(jīng)驗技術(shù)的使用是根據(jù)經(jīng)驗導(dǎo)出的公式來預(yù)測工作量和時間�？梢允褂米詣庸ぞ邅韺崿F(xiàn)某一特定的經(jīng)驗?zāi)Ｐ�。精確的項目估算一般至少會用到上述技術(shù)中的兩種。通過比較和協(xié)調(diào)使用不同技術(shù)導(dǎo)出的估算值，我們可能得到更精確的估算。軟件項目估算永遠不會是一門精確的科學(xué)，但將良好的歷史數(shù)據(jù)與系統(tǒng)化的技術(shù)結(jié)合起來能夠提高估算的精確度。

9、遺漏重要的假設(shè)或約束條件

如一些政府機關(guān)的管理信息系統(tǒng)軟件開發(fā)項目隱含的需求是必須遵守一系列的和行業(yè)標準，但由于沒有考慮到這些要求，致使項目計劃失敗，開發(fā)出某些功能、性能或數(shù)據(jù)不符合和行業(yè)標準的軟件，造成返工。所以應(yīng)當盡可能地將將任何設(shè)想和約束編入文檔。做項目計劃時應(yīng)該盡可能地把假設(shè)條件和約束條件考慮清楚，這些假設(shè)和約束可以是樂觀的、悲觀的或者是可能的估計。例如，可以假設(shè)能夠及時獲得應(yīng)用程序服務(wù)器的新發(fā)行版，或可以得到熟悉項目正在采用的技術(shù)和技巧的開發(fā)人員；還可以假設(shè)，項目能在一些約束下工作，如影響計劃的強制截止期限或資源限制等等。應(yīng)該把這些假設(shè)和約束條件編入計劃文檔中，在項目的實施過程中，當項目計劃需要細化和調(diào)整時，應(yīng)該考慮到這些約束條件，而不是以一種“無限資源”的方式做計劃。一般來說，假設(shè)、約束和風(fēng)險的區(qū)別是：假設(shè)、約束是一些比較明顯、明確、已經(jīng)發(fā)生或肯定會發(fā)生的情況，而風(fēng)險這是不一定會發(fā)生的，具有不確定性。

10、項目計劃沒有突出重點

軟件開發(fā)涉及到方方面面的工作，有些是主要的，有些是次要的，項目計劃應(yīng)當反映有價值的工作任務(wù)、環(huán)境條件。項目計劃不能寫成一個大雜燴，也不能寫成一個包羅萬象的百科全書。在項目計劃中要簡潔精確地反映對項目有價值的事情、任務(wù)和活動，避免羅嗦。項目管理的理論方法、成功的項目管理經(jīng)驗都是在實施項目時應(yīng)該參考的。但是，每個項目是特殊的，具有“性”的，一次需要為每個項目做專門的計劃，選擇適合的項目，適合的團隊的方式和方法。

11、忽視次要工作任務(wù)對項目的影響

軟件開發(fā)項目計劃不僅要安排需求分析、概要設(shè)計、必要時的詳細設(shè)計、系統(tǒng)實施和測試與維護等實際的重要工作，而且還應(yīng)該安排項目中的支持性輔助活動，這些支持性輔助活動雖然不能成為關(guān)鍵活動，但是它們卻對項目的進展又作重大的影響。這些輔助活動包括：體系結(jié)構(gòu)定義、文檔評審后文檔編寫的返工甚至是需求調(diào)研的返工，測試之后的編碼返工、系統(tǒng)交付、與軟件復(fù)用相關(guān)的活動、項目組內(nèi)溝通交流、休假和法定假日、培訓(xùn)和教育、團隊成員的生活（如飲食、住宿、交通等）、項目規(guī)劃、人員管理等管理活動、會議和回復(fù)電子郵件，等等。做項目計劃時應(yīng)當盡可能完整地列出這些影響項目的活動，或者按照固定的模板進行計劃的制訂，免得遺漏必要的計劃內(nèi)容。有時候，小的疏忽會帶來大的問題，次要矛盾會成為或引發(fā)主要矛盾。例如，加班安排不當，會引起員工的厭倦甚至離職，造成軟件項目的人力資源問題，從而影響項目的進度，甚至導(dǎo)致項目失敗。

12、工作任務(wù)的分解不便于人員分工

在確定了系統(tǒng)構(gòu)架之前應(yīng)該考慮在編寫文檔的同時是否有些其他基礎(chǔ)性的工作可以先做，如是否在需求分析的同時進行部分的系統(tǒng)概要設(shè)計；是否可以先進性技術(shù)預(yù)研，環(huán)境架構(gòu)搭建、后臺數(shù)據(jù)庫框架搭建、軟件系統(tǒng)框架搭建等等。迭代法使得在上一階段的部分任務(wù)完成后，下一階段的對應(yīng)工作可以投入進行。在確定了系統(tǒng)構(gòu)架之前之后工作任務(wù)的分解都要考慮模塊編碼獨立性、開發(fā)編碼工作的負載均衡、編碼進度安排優(yōu)化、預(yù)防人員流動（如生病、其他更緊急的任務(wù)、離職等）對開發(fā)的影響：一個好的項目計劃同時應(yīng)有助于減少項目組的壓力和緊張，提高軟件開發(fā)效率。

13、不了解項目成員的工作能力

項目成員的工作能力多種多樣，需要根據(jù)項目的崗位角色來分配。如軟件開發(fā)的編碼人員至少需要編寫代碼的能力、單元測試的能力、跟蹤查找問題的能力、解決問題的能力。而需求分析人員至少要有業(yè)務(wù)理解學(xué)習(xí)能力、業(yè)務(wù)分析能力、溝通表達能力、建模及文檔能力等等。這些能力很難量化，不過項目經(jīng)理好是心里大致有數(shù)，能夠大致估算出每個項目成員在正常情況下完成不同目標要求的各項任務(wù)所需要花費的時間。