軟件項目經(jīng)常遇到的一些問題可能包括：項目時間緊、項目組成員經(jīng)常加班；項目需求變更頻繁；項目進行過程中可能就有項目團隊成員離職或調(diào)離到其他項目組；項目重復性建設(shè)問題嚴重，每個項目都需要從框架開始重新開發(fā)，難以重用已有項目的成果等等。我覺得通過較好的規(guī)劃和管理能夠在一定程度上提高項目的成功率或者說提高項目的質(zhì)量，降低開發(fā)成本，縮短項目開發(fā)時間。

我理解項目管理有兩個大的劃分方法一是通用的項目管理體系，也就是PMP中所說的五大項目管理過程組10個知識領(lǐng)域49個項目管理過程；二是具體業(yè)務(wù)領(lǐng)域的按項目生命期劃分的各階段的管理。本文主要從項目生命期各階段的管理方面進行總結(jié)。

軟件項目生命期大體需要經(jīng)過的流程：可行性分析、需求、設(shè)計、開發(fā)、測試、實施、維護、總結(jié)。

一、可行性分析

一般的項目都是通過外部招標的形式得到的。對于有些公司在競標的時候?qū)椖烤鸵袀€取舍。如果在特殊時期為了生存可能只要不是太賠錢的項目都會盡量承接。

但是一般項目在承接前最好在經(jīng)濟、技術(shù)等方面進行可行性分析，而且這種可行性分析最好是管理者、市場、技術(shù)等人員都參與，因為市場人員一般不太懂技術(shù)，，因此只有大家在一起共同分析討論才能夠得出比較可行的結(jié)果?？尚行苑治龅慕Y(jié)果一方面可以作為是否承接項目的依據(jù)，另一方面也可以作為承接項目的方式或與客戶談判的依據(jù)。比如經(jīng)分析項目工作量很大，如果按標書金額開發(fā)有可能會賠，那么可以與用戶探討是否將來能有個二期的項目；另外如果用戶要求的時間比較緊，可是經(jīng)分析很難按標書時間完成，那么也可以和用戶同共探討是否可以在正式簽定合同時延長系統(tǒng)交付時間等。當然這些與用戶的探討工作一般是需要公司高層領(lǐng)導出面協(xié)調(diào)的，有時單獨靠項目組是沒有能力達成理想的結(jié)果的。

另外在此階段最好對項目的成本和需要的資源進行一下估算。

二、需求

需求實際要細分為需求調(diào)研、需求分析、需求確認、需求管理等。

如果早期需求做得不夠仔細會給項目的后期工作帶來很多的隱患。

我建議每個項目無論多大也無論項目時間要求多緊急一定要有一個比較詳細的需求文檔。

在需求確定之后再對項目成本進行估算。同時對需要的資源及相關(guān)里程碑進行說明。

三、設(shè)計

大部分中小型項目會因為時間和人力的問題加上需求變更比較頻繁，所以有時很難書寫一個比較詳細的設(shè)計文檔。但是如果沒有設(shè)計文檔一是為后期維護可能會帶來一些問題，尤其是當原來開發(fā)人員或主力開發(fā)人員離職或調(diào)離到其他項目組時；另外沒有經(jīng)過詳細設(shè)計的項目可能也會存在一些風險。

因此建議不必為了文檔而文檔，除了項目驗收的要求外，建議設(shè)計文檔根據(jù)項目特點有選擇地包括以下一些內(nèi)容的說明：

系統(tǒng)的關(guān)鍵配置說明（如數(shù)據(jù)庫服務(wù)器，應(yīng)用服務(wù)器等等，如有必要可另加附件進行說明）。

對于中小型項目如果不是用戶要求有時不必在設(shè)計文檔中對所有數(shù)據(jù)庫表及字段都進行說明，可以只說明比較重要的一些數(shù)據(jù)庫表及字段以及相關(guān)數(shù)據(jù)庫的關(guān)聯(lián)關(guān)系就可。因為在用數(shù)據(jù)庫建模軟件進行數(shù)據(jù)庫設(shè)計的時候可以對每個表及每個字段加注釋進行說明，在使用開發(fā)工具進行開發(fā)的時候自然可以看到每個數(shù)據(jù)庫表或字段的說明。而且一般中小型項目在開發(fā)的過程中可能需要經(jīng)常性地修改數(shù)據(jù)庫表的設(shè)計，如果還有文檔描述數(shù)據(jù)庫的設(shè)計那么每次修改時除了修改數(shù)據(jù)庫之外還要維護設(shè)計文檔的一致性，如果項目忙忘記了修改就會導致文檔和數(shù)據(jù)庫的不一致，有時這種不一致的文檔可能還不如沒有，因為它可能會誤導其他人員的理解。

另外也可以通過開發(fā)過程的規(guī)范來減少設(shè)計文檔的內(nèi)容。這個將在下面的開發(fā)環(huán)節(jié)進行詳細的說明。

四、開發(fā)

整個項目有一個合理的框架是很重要的?？蚣芫唧w包括哪些內(nèi)容在此很難解釋清楚，但是我想最起碼整個框架應(yīng)該把項目所采用的各種技術(shù)（如java中的Hibernate、Struts、Spring的結(jié)合）比較合理地組織起來，并為具體模塊的開發(fā)提供一些工具類等，同時整個框架應(yīng)該具有較好的可擴展性、可維護性和較好的性能?？蚣茏詈糜身椖拷M中技術(shù)最強的人（在此稱他為技術(shù)負責人）進行搭建及維護。

另外對于整個項目有一個統(tǒng)一的命名規(guī)范（類和方法按什么方式命名，所有文檔都加上時間作者等）并進行遵守是很必要的，這樣一個人開發(fā)的代碼其他人很容易就能夠讀懂。

在整個項目進行全面開發(fā)前最好先向項目組全體成員講解需求及項目框架的機制、使用方式及注意事項，再說明相關(guān)規(guī)范。然后每一個開發(fā)人員按照理解開發(fā)一個簡單的功能。然后大家在一起（或者由技術(shù)負責人）看一下每個人對于框架的使用是否合理，規(guī)范理解的是否有誤，編碼習慣是否需要改正等等。在討論并達成共識后再進行具體功能的開發(fā)。另外在具體的開發(fā)過程中盡量在關(guān)鍵算法處加一些注釋進行說明。建議定期進行一些代碼走查的工作。盡量由技術(shù)負責人負責這份工作，當然也可以進行互相檢查等。代碼走查的好處很多，如何發(fā)現(xiàn)一些不好的編碼習慣；提高整個系統(tǒng)代碼的可讀性；發(fā)現(xiàn)一些bug；借鑒別人好的編碼思路或技術(shù)等。

五、測試

首先開發(fā)人員一定要養(yǎng)成單元測試的習慣。對自己開發(fā)模塊的功能進行單元測試過之后再提交測試組進行結(jié)合測試、系統(tǒng)測試甚至性能測試。單元測試很重要，在進行單元測試的時候如果條件允許可以使用一些代碼覆蓋率工具幫助分析測試用例的覆蓋程度。另外，一般項目可能是整體開發(fā)完之后才進行性能測試，可是這時測試出性能問題了卻因為臨近上線或試運行時期，不一定有充足的時間進行修改，另外也可能因為整個項目已經(jīng)都使用了某種影響性能的技術(shù)或方法，要想改變要付出很大的代價。所以建議如果條件允許可以在開發(fā)的過程中（甚至搭建項目框架時）使用一些輕量級的開源性能測試工具由開發(fā)人員對可能影響性能的功能進行測試。

對于測試部門的測試人員要盡早地參與到項目中來，建議在需求階段就介入。早介入的好處一是可以對需求理解得比較深入，知道原始需求是怎么來的，中間經(jīng)過哪些變化，這樣會比在開發(fā)結(jié)束后一次性地講解能夠更好地把握需求，更好地書寫測試用例及測試計劃。

項目組設(shè)計人員一定要把一些關(guān)鍵測試點、數(shù)據(jù)及功能的關(guān)聯(lián)關(guān)系對測試人員說清楚。測試過程中有一個bug管理系統(tǒng)并對bug進行跟蹤是很必要的，最好是在項目結(jié)束后能對產(chǎn)生的所有bug進行一下分類。然后通過分析得出一些規(guī)律。通過在以后的項目中采取一些措施進行項目質(zhì)量的提高。

六、實施

對于涉及多個子系統(tǒng)的長期開發(fā)項目，在系統(tǒng)設(shè)計和開發(fā)過程中要優(yōu)化處理關(guān)聯(lián)性強的系統(tǒng)，同時有一個（或幾個）系統(tǒng)成熟了就試運行或上線，不必等所有系統(tǒng)都好了再上線。一是因為時間長了開發(fā)人員可能調(diào)離至其它崗位，維護代價會增大；二是子系統(tǒng)用戶可能會改變而導致需求變更；三是時間長了用戶對系統(tǒng)需求會有陌生感，也可能會產(chǎn)生新的需求；四是時間長會打消用戶對使用系統(tǒng)的積極性；五是較早地讓用戶看到系統(tǒng)也可以減輕因雙方理解偏差而導致的系統(tǒng)需求變更的影響。

七、維護

爭取把用戶提過的所有修改都進行記錄，并爭取所有修改都請用戶簽字（不一定提一個修改就簽字一次，可以統(tǒng)一記錄然后定期把一段時間內(nèi)的修改進行簽字確認），如果做不到所有修改都簽字也盡量做到對于重大修改請用戶簽字。簽字的好處很多：讓用戶看到項目組所做的工作；如果修改的內(nèi)容比較多可以通過雙方高層領(lǐng)導的溝通再進行系統(tǒng)二期或三期的開發(fā)；有了簽字有時用戶對需求變更會相對少一些等等。

另外對于所有修改除了簽字留檔外爭取定期把所有修改的內(nèi)容再整理到需求文檔中，保持需求文檔與正式環(huán)境功能的一致性。這個工作很有必要，可能帶來以下一些好處：方便測試人員在回歸測試時理解系統(tǒng)功能；如果維護人員的調(diào)離其他接手人員比較方便理解系統(tǒng)功能等。

八、總結(jié)

建議每個項目結(jié)束后都召開一個項目總結(jié)會。項目總結(jié)會建議與項目相關(guān)的所有人都參加。由項目經(jīng)理進行主要總結(jié)，但每個參與人員最好也都進行總結(jié)。可以從管理和技術(shù)兩大方面對項目中的每個階段的成功與失敗進行總結(jié)，目的是總結(jié)經(jīng)驗教訓，提高每個人的項目經(jīng)驗，提高項目組的成熟度，使以后的項目更加成功。在此要強調(diào)一下，一般項目總結(jié)時大家都喜歡只說成功的，而很少提到失敗的或所走的一些彎路，而往往對這些失敗的總結(jié)更能使大家收獲更多，當然這也要看組織的文化，我建議如果可能盡量鼓勵大家多總結(jié)一些失敗的經(jīng)驗教訓。

項目結(jié)束后如果有時間最好是把項目中的一些有重用價值的文檔放到公司的組織過程資產(chǎn)庫中。

如果項目的框架比較合理也可以剔除項目中的業(yè)務(wù)相關(guān)功能的代碼，整理出項目框架并加以簡要說明文檔供本項目組其他項目或其他項目組使用。

九、項目經(jīng)理職責分析

對于中小型規(guī)模的項目，項目經(jīng)理可能既要充當管理人員的角色又要充當開發(fā)甚至實施人員的角色，基本上軟件項目生命期的每個階段都要參與。

但是我覺得以下一些工作項目經(jīng)理一定要重視：

總之項目經(jīng)理要對項目的成敗負責，要對項目成員的發(fā)展負責，要對客戶負責，還要對公司負責，所以項目經(jīng)理一定要有責任心、要有全局觀。

近期熱文：

• 一張圖知道項目經(jīng)理每天每周每旬每月的日常工作
• 項目管理就是多想一步，多走一步
• 一圖掌握項目管理的核心工具WBS工作分解結(jié)構(gòu)，PM必備技能！
• 項目管理體系指南PMBOK第七版框架解讀
• PMBOK第7版整體架構(gòu)全面詳解–帶你快速掌握第七版全貌
• 什么決定了項目經(jīng)理的高度?
• 拿到項目之后項目經(jīng)理每個階段都應(yīng)該做什么？用什么工具和方法？核心關(guān)鍵是什么？
• 優(yōu)秀項目經(jīng)理必備的實用演講技巧
• 優(yōu)秀的項目經(jīng)理是如何做述職匯報？附模板下載【可樂洞察】
• IT項目經(jīng)理每天每周都在干什么？附簡要周報模板
• 掌握管理全景圖，讓你知道作為管理者到底管什么？理什么？
• 項目經(jīng)理能力提升模型詳解
• 優(yōu)秀項目經(jīng)理和PMO管理的六脈神劍
• 月薪60K以上的PMO崗位要求都是什么樣的？
• PMO和項目經(jīng)理應(yīng)該掌握的項目研發(fā)效能度量指標大全
• 一圖掌握項目管理各階段必備工具方法大全
• 項目管理的最重要的一環(huán)需求管理該如何做？
• 項目管理面試難題問答及經(jīng)驗參考