軟件開發(fā)中項(xiàng)目管理的注意事項(xiàng)

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

引言：軟件行業(yè)從20世紀(jì)60年代開始操作系統(tǒng)的研發(fā)，到20世紀(jì)90年代中期行業(yè)快速發(fā)展。從原有的作坊式開發(fā)到目前團(tuán)隊(duì)協(xié)作完成，從早期的技術(shù)力量競(jìng)爭(zhēng)到現(xiàn)有的項(xiàng)目成本控制競(jìng)爭(zhēng)，從面向結(jié)構(gòu)到面向?qū)ο笤俚矫嫦蚍?wù)架構(gòu)，項(xiàng)目管理被提到一定的高度，如何有效的經(jīng)營(yíng)項(xiàng)目來降低風(fēng)險(xiǎn)、控制成本，確保項(xiàng)目進(jìn)度流暢，在有效的時(shí)間內(nèi)保質(zhì)、保量的完成驗(yàn)收。成為不少項(xiàng)目管理人士的追求目標(biāo)。結(jié)合個(gè)人項(xiàng)目管理實(shí)踐，本人有幾點(diǎn)管理注意事項(xiàng)與大家一起分享。 
 
項(xiàng)目管理注意事項(xiàng)  

開發(fā)模型確定  

一個(gè)項(xiàng)目的好壞，開發(fā)模型優(yōu)良是項(xiàng)目成功重要保障，有了好的開發(fā)模型我們可以很好的控制項(xiàng)目進(jìn)度、降低風(fēng)險(xiǎn)。所以我們?cè)陧?xiàng)目開始前首先需要確定項(xiàng)目的開發(fā)模型。這里我們建議采用迭代式的開發(fā)模型。我們知道原有早期傳統(tǒng)的開發(fā)模型是一個(gè)文檔驅(qū)動(dòng)的流程，它將整個(gè)軟件開發(fā)過程劃分為順序相接的幾個(gè)階段，每個(gè)階段都必需完成全部規(guī)定的任務(wù)后才能夠進(jìn)入下一個(gè)階段。項(xiàng)目開始首先完成系統(tǒng)需求規(guī)格說明書，之后才能夠進(jìn)入概要設(shè)計(jì)階段，編碼則在系統(tǒng)設(shè)計(jì)完成之后進(jìn)行。這就意味著只有當(dāng)所有的系統(tǒng)模塊全部開發(fā)完成之后，我們才進(jìn)行系統(tǒng)集成，對(duì)于一個(gè)由很多個(gè)模塊組的復(fù)雜系統(tǒng)來說，這是一個(gè)非常艱巨而漫長(zhǎng)的工作，且存在著潛在的風(fēng)險(xiǎn)。  

如：需求或者設(shè)計(jì)中的錯(cuò)誤無法在項(xiàng)目早期發(fā)現(xiàn)，只有在系統(tǒng)交付客戶之后才能發(fā)現(xiàn)原先對(duì)于需求的理解是錯(cuò)誤的，系統(tǒng)設(shè)計(jì)的錯(cuò)誤也只有在測(cè)試階段才能被發(fā)現(xiàn)。  

對(duì)于項(xiàng)目風(fēng)險(xiǎn)的控制能力較弱，往往項(xiàng)目風(fēng)險(xiǎn)只能隨著項(xiàng)目結(jié)束才能逐步降低，同時(shí)也只有經(jīng)過系統(tǒng)測(cè)試之后，才能確定設(shè)計(jì)是否能夠真正滿足系統(tǒng)需求。  

軟件項(xiàng)目常常延期完成或開發(fā)費(fèi)用超出預(yù)算項(xiàng)目開發(fā)進(jìn)度往往會(huì)被意外發(fā)生的問題所打亂，需要進(jìn)行返工或其他一些額外的開發(fā)周期，造成項(xiàng)目延期或費(fèi)用超支。  

項(xiàng)目管理人員專注于文檔的完成和審核來估計(jì)項(xiàng)目的進(jìn)展情況所以項(xiàng)目經(jīng)理對(duì)于項(xiàng)目狀態(tài)的估計(jì)往往是不準(zhǔn)確的，當(dāng)他回答系統(tǒng)已完成了80%的開發(fā)任務(wù)時(shí)，剩下20%的開發(fā)任務(wù)實(shí)際上消耗的是整個(gè)項(xiàng)目80%的開發(fā)資源。  

在傳統(tǒng)的瀑布模型中，早期是無法發(fā)現(xiàn)，需求和設(shè)計(jì)中的問題，只有當(dāng)系統(tǒng)第一次集成后，這些設(shè)計(jì)缺陷才會(huì)在測(cè)試中暴露出來，需求缺陷則需要等到系統(tǒng)與用戶見面后，方可暴露。從而導(dǎo)致一系列的返工：重新設(shè)計(jì)、編碼、測(cè)試，進(jìn)而導(dǎo)致項(xiàng)目的延期和開發(fā)成本的上升。  

為了解決傳統(tǒng)軟件開發(fā)流程中的問題，我們建議采用迭代化的開發(fā)方法來取代瀑布模型。在瀑布模型中，我們要完成的是整個(gè)軟件系統(tǒng)開發(fā)這個(gè)大目標(biāo)。在迭代化的方法中，我們將整個(gè)項(xiàng)目的開發(fā)目標(biāo)劃分成為一些更易于完成和達(dá)到的階段性小目標(biāo)，這些小目標(biāo)都有一個(gè)明確的階段性評(píng)估標(biāo)準(zhǔn)。迭代就是為了完成一定的階段性目標(biāo)而所從事的一系列開發(fā)活動(dòng)，在每個(gè)迭代開始前都要根據(jù)項(xiàng)目當(dāng)前的狀態(tài)和所要達(dá)到的階段性目標(biāo)制定迭代計(jì)劃，整個(gè)迭代過程包含了需求調(diào)研、軟件設(shè)計(jì)、軟件實(shí)現(xiàn)、版本集成、軟件測(cè)試、軟件發(fā)布和產(chǎn)品交付等各種類型的開發(fā)活動(dòng)，迭代完成之后需要對(duì)迭代完成的結(jié)果進(jìn)行評(píng)估，并以此為依據(jù)來制定下一次迭代的目標(biāo)。  

開發(fā)計(jì)劃制定  

確定好項(xiàng)目的開發(fā)模型，一整套配套可行的項(xiàng)目開發(fā)計(jì)劃是開發(fā)過程中進(jìn)度控制的標(biāo)準(zhǔn)，同樣是用戶、公司管理層了解項(xiàng)目進(jìn)展的依據(jù)。通常項(xiàng)目管理人員、需求人員和用戶根據(jù)用戶原始需求（可以是項(xiàng)目方案書或者是建議書），一起定義整個(gè)項(xiàng)目過程中的項(xiàng)目迭代過程個(gè)數(shù)以及每個(gè)迭代過程的開發(fā)目標(biāo)和范圍。  

如何進(jìn)行迭代過程的劃分和范圍有效定義呢？是我們迭代開發(fā)計(jì)劃制定的首要任務(wù)，我們這里推薦兩種劃分原則。  

一、用戶需求至上原則，也就是根據(jù)用戶需求的優(yōu)先級(jí)，進(jìn)行逐個(gè)模塊擊破，每一個(gè)迭代是用戶需求一個(gè)的模塊，當(dāng)然模塊小時(shí)或者人員充足時(shí)，也是在一個(gè)迭代中完成兩個(gè)或者三個(gè)模塊。  

二、當(dāng)用戶需求沒有鮮明優(yōu)先級(jí)時(shí)，我們可以采用功能逐步求精開發(fā)法，類似于我們?cè)缙诓捎每焖僭烷_發(fā)，劃分多個(gè)迭代，確定每個(gè)迭代需要達(dá)到的功能的完善層次，例如，首先第一個(gè)迭代僅完成系統(tǒng)的原型開發(fā)，第二迭代則緊接著完成各業(yè)務(wù)基本功能，然后逐步完善直至滿足用戶需求。  

無論怎樣劃分我們的迭代過程，總之需要把握一個(gè)原則，框架盡早規(guī)劃，版本快速集成。項(xiàng)目只要進(jìn)入軟件實(shí)現(xiàn)過程早期,建議實(shí)現(xiàn)周版本的概念，確保一周一個(gè)版本，一來方便項(xiàng)目管理人員了解項(xiàng)目進(jìn)度、質(zhì)量，從而根據(jù)前期項(xiàng)目完成情況和近期的用戶需求變動(dòng)及時(shí)調(diào)整計(jì)劃。二來可以盡早將系統(tǒng)與用戶見面，及時(shí)發(fā)現(xiàn)對(duì)于用戶需求理解不正確之處，同時(shí)還可以激發(fā)用戶潛在需求，細(xì)化需求。在軟件實(shí)現(xiàn)過程后期，則可以根據(jù)需要調(diào)整集成版本頻率。所以，雖然每個(gè)迭代開發(fā)過程中的開發(fā)活動(dòng)是可以選擇性的裁減，但通常軟件實(shí)現(xiàn)、版本集成和軟件測(cè)試是每個(gè)迭代不可缺少的活動(dòng)，否則迭代過程將失去它的含義。  

迭代過程個(gè)數(shù)和范圍確定后，則需要與每個(gè)迭代過程中的開發(fā)活動(dòng)相關(guān)者協(xié)商討論進(jìn)度安排，先明確各開發(fā)活動(dòng)的起始、截至?xí)r間，然后在根據(jù)開發(fā)活動(dòng)的具體需求進(jìn)行任務(wù)細(xì)化。如果希望能將項(xiàng)目進(jìn)度控制在計(jì)劃之中，任務(wù)越細(xì)越好，每個(gè)任務(wù)跨度不要太大，一天一個(gè)任務(wù)最好。當(dāng)然這種情況是很能實(shí)現(xiàn)的。確實(shí)，我這里說的是一種比較理想的情況，但并不是不可能。在這里我們就可以了解到迭代開發(fā)計(jì)劃給我們帶來的好處。項(xiàng)目開始了需求通常都是很泛，不太明確。與用戶交流，可能他認(rèn)為自己已經(jīng)表達(dá)了所有需要。實(shí)際也許他確實(shí)已經(jīng)充分描述了他所知道的需求（業(yè)務(wù)需求），但完善我們的系統(tǒng)，除了基本業(yè)務(wù)需求外還有很多非功能性需求，比如：系統(tǒng)性能需求、界面顯示需求、系統(tǒng)操作流程需求等等，尤其是目前B/S架構(gòu)的開發(fā)模式，界面需求已經(jīng)越顯示出它的重要性。而這些需求在項(xiàng)目早期，在沒有任何可見事務(wù)的情況下，用戶很難意識(shí)到它的重要性。  

我們只有逐個(gè)迭代的細(xì)化，每一個(gè)迭代過程完成既是需求進(jìn)一步細(xì)化的依據(jù)又是一早期，在沒有任何可見事務(wù)的情況下，用戶很難意識(shí)到它的重要性。  

我們只有逐個(gè)迭代的細(xì)化，每一個(gè)迭代過程完成既是需求進(jìn)一步細(xì)化的依據(jù)又是一個(gè)新系統(tǒng)的開始，每個(gè)迭代開始前都要根據(jù)上個(gè)迭代的成果和所要達(dá)到的階段性目標(biāo)細(xì)化定制。  

組內(nèi)成員配置  

項(xiàng)目啟動(dòng)之前除項(xiàng)目管理者著手計(jì)劃制定外，同時(shí)也需要對(duì)其項(xiàng)目組那成員配置進(jìn)行規(guī)劃，界定其職責(zé)。通常我們需要幾種角色：  

技術(shù)組長(zhǎng)：負(fù)責(zé)技術(shù)難題攻關(guān)，組間溝通協(xié)調(diào)。  

需求人員：負(fù)責(zé)將用戶需求轉(zhuǎn)換成項(xiàng)目?jī)?nèi)的功能需求和非功能需求，編制項(xiàng)目需求規(guī)格說明書，針對(duì)每個(gè)迭代集成版本與用戶交流獲取需求的細(xì)化。  

設(shè)計(jì)人員：負(fù)責(zé)對(duì)需求規(guī)格說明書，進(jìn)行系統(tǒng)設(shè)計(jì)。
  
開發(fā)人員：實(shí)現(xiàn)設(shè)計(jì)，完成用戶功能。  

集成人員：負(fù)責(zé)整套系統(tǒng)的編譯集成，督促小組系統(tǒng)功能提交，及時(shí)發(fā)現(xiàn)各模塊集成問題，起到各小組之間的溝通的紐帶。  

測(cè)試人員：對(duì)于集成人員集成的版本進(jìn)行測(cè)試，盡可能的發(fā)現(xiàn)程序缺陷，以及未滿足需求的設(shè)計(jì)。
  
文檔整理人員：負(fù)責(zé)對(duì)小組內(nèi)產(chǎn)生文檔的整合，統(tǒng)一。 
 
系統(tǒng)環(huán)境人員：負(fù)責(zé)系統(tǒng)編譯環(huán)境、運(yùn)行環(huán)境規(guī)劃。編制系統(tǒng)環(huán)境說明書。  

維護(hù)人員：系統(tǒng)驗(yàn)收后，維護(hù)人員，建議維護(hù)人員早期進(jìn)入項(xiàng)目參與項(xiàng)目測(cè)試以便順利承擔(dān)起項(xiàng)目維護(hù)職責(zé)。  

項(xiàng)目組啟動(dòng)初期需求人員首先根據(jù)迭代計(jì)劃第一個(gè)迭代計(jì)劃進(jìn)行需求調(diào)研編制功能需求規(guī)格說明書，通過項(xiàng)目下到工序人員評(píng)審后進(jìn)入軟件設(shè)計(jì)、編碼。注意，這里需求確認(rèn)并不是指項(xiàng)目中的整體需求，僅僅是指該迭代過程中體現(xiàn)的需求。整個(gè)過程類似如項(xiàng)目開發(fā)流程，這里只是細(xì)小流程，逐步完善，漸進(jìn)提交。  

項(xiàng)目中溝通  

通常項(xiàng)目中口頭溝通是最為常見的，包括項(xiàng)目組內(nèi)部、外部溝通，這種溝通快捷、方便。一般的小問題或者是簡(jiǎn)單問題的理解非常有效，但問題復(fù)雜或是此次溝通需要后續(xù)使用，那么該種溝通則存在問題，則需要以書面方式加口頭相結(jié)合最為有效。即可在本次溝通中方便、快捷的領(lǐng)會(huì)，也可以為后續(xù)工作提供依據(jù)。  

通常用戶對(duì)于項(xiàng)目進(jìn)度卻是有要求，不僅需要提交周計(jì)劃和總結(jié)，還需要定期匯報(bào)項(xiàng)目的完成情況，對(duì)于即將延時(shí)的里程碑，需要提前至少三天時(shí)間提出項(xiàng)目延時(shí)申請(qǐng)。那么從這里我們可以吸取，與用戶的溝通間隔除每周進(jìn)行項(xiàng)目計(jì)劃和總結(jié)外，對(duì)于用戶認(rèn)可的項(xiàng)目開發(fā)計(jì)劃，需要在里程碑需要向用戶匯報(bào)，對(duì)于即將延時(shí)的開發(fā)進(jìn)度，盡可能早的通知用戶方的項(xiàng)目負(fù)責(zé)人知道，方便用戶方的項(xiàng)目負(fù)責(zé)人有準(zhǔn)備的與其領(lǐng)導(dǎo)溝通，可以有效預(yù)防工作被動(dòng)狀態(tài)出現(xiàn)。  

項(xiàng)目組內(nèi)部溝通不是越多越好，你會(huì)發(fā)現(xiàn)當(dāng)內(nèi)部的溝通時(shí)間沒有規(guī)律或是溝通時(shí)間過長(zhǎng)，這樣其實(shí)也會(huì)嚴(yán)重影響項(xiàng)目成員的開發(fā)進(jìn)度，但溝通又是必不可少，何種間隔最為適宜了？這是不好定的，我們通常以評(píng)審作為溝通的基礎(chǔ)，平日的溝通建議項(xiàng)目組成員在每天工作過程遇到問題，將其記錄下來，然后在以郵件方式發(fā)送給需要溝通或者詢問者。大家可以每天下班之前收取郵件，對(duì)于可以直接回答的問題則直接以郵件方式回復(fù)，對(duì)于無法直接答復(fù)而只需與提出問題者討論的問題，則可以在第二天上班前進(jìn)行商議確定。而需要眾人一起討論的問題，則放到每周會(huì)議上討論。非常緊急的話則可以馬上約齊人員討論，通常有良好的溝通方式話，這種非常緊急的問題是不常見的。