第一篇：個人體驗~軟件開發(fā)中的項目管理
廣西工學院
軟件開發(fā)中的項目管理
姓名：羅 鑫
學號：200502002072
班別：計Y052班
指導老師：唐新來
一、引言
軟件開發(fā)是人類大腦智慧的結晶。軟件項目開發(fā)是以人為根本，離開了人軟件開發(fā)就無從談起。并且軟件開發(fā)涉及到的不是一個人，而是一個集體。一群人要做事，而且要做好事，就得有人管理。有道是：一只獅子領導的一群羊，要比一只羊領導的一群獅子更加有戰(zhàn)斗力。所以說，一個團隊的戰(zhàn)斗力歸根結底要看領導者的領導和管理能力。
這次軟件測試的論文，我就軟件開發(fā)中的項目管理談談自己的心得和看法。我有幸有幾次在學校合作開發(fā)軟件項目的經(jīng)驗。雖然說那不是商業(yè)項目，但是好歹也是學?？蒲刑幜㈨椨薪?jīng)費支持的大學生科研項目。分別是《網(wǎng)狀結構的描述、應用與研究》《排序結構算法的對比、研究、應用》《基于局域網(wǎng)的存儲網(wǎng)格研究、應用》。前兩個項目以及基本完成并且結項，后一個項目剛剛申請。我在其中擔任的角色是，組長，組員，組長。雖然項目不大，但對我一個學生來說還是一個挺大的挑戰(zhàn)。
二、初識軟件項目管理
我最初關心軟件開發(fā)過程的項目管理是大二的上學期，那時候正是我決定鍛煉自己，接學校一個科研項目的時候。我有幸成為該小組的組長，下面帶個幾個水平不錯的同學一起進行軟件開發(fā)。第一次擔任組長的職務很不適應。以前自己寫代碼野慣了，沒有太多和別人合作開發(fā)的經(jīng)驗，所以開始的工作不知道如何開展，很亂非常亂。大家在一起討論了幾次開了幾次會，都是泛泛而談沒有什么實際成果。萬事開頭難，我們只能在前期的一個月到兩個月進行基礎知識的補充。我也在這段時間中，開始致力于學習項目管理。到圖書館翻了很多書也了很多項目理書籍，但是當時根本都不懂也不理解。我就覺得書上寫的應該比較對吧，所以一看到好的東西就斷章取義的來用，來實踐。很不幸后來我所實踐基本都失敗了。
積累了一段時間基礎知識后，我們小組算是正式開始工作了。但是小組的組織還是像以前一樣無序。大家各種都在忙著自己的事情，而作為組長的我也不能有效把大家聚集起來。組內人心不齊，各種的水平有參差不齊。并且在其中還有一種怪氣氛，技術如果不能壓住別人的話，沒有辦法樹立作為領導的權威。這點我深有體會作為一個組長威信不夠、底氣不足的話，是無法讓大家信服的。大家各種都按自己的意見來辦，意見根本無法統(tǒng)一。當然也根本無法進行協(xié)作開發(fā)。似乎這個問題也是很多開發(fā)小組的無奈，同時我也擔任著軟件實訓的一個小組的組長。沒有威信工作根本無法展開，特別是遇到一些很有個性的人，那就是更加倒霉的事情了。
所以為了確定自己的威信和權威，我將精力從軟件管理中分開了而專注于軟件模型的開發(fā)，這段時間我打法我的組員進行基礎知識的積累和學習。經(jīng)過自己的不懈努力，我自己終于做出了軟件模型，在得到指導老師的肯定后。之后的小組開發(fā)我就基于這個模型來做。同時也算樹立了自己的威信和權威，開始了一些很初級的分工，就是我需要什么函數(shù)，就要別人幫我做。這樣我的小組才漸漸的開始算做合作起來，跌跌撞撞，慘不忍睹。在那年的暑假原來很多人的軟件小組，最后也才剩下4個人了。一場激情過后的慘淡，剩下漫長的暑假重復做這編碼、調試、編碼、調試。經(jīng)過我們不懈的努力，終于在結項的前幾日完成了項目，補齊了各種軟件開發(fā)文檔。一場亂仗就這樣結束了。
雖然項目得到了指導老師的肯定和系里頭的肯定，但是我卻認為這次項目還是失敗了，最大的失敗就是沒有能夠協(xié)同開發(fā)。原因有三：
1、分工不明確。
誰做需求、誰做設計、誰管理、誰寫文檔基本上都是亂的。要不沒有人做、要不都是我自己做的。整個項目做下來我完成了超過80%的代碼，70%的文檔。我可以一點不客氣的說、整個軟件基本上都是我一個人在做。如果從作為程序員這個角色來看，這無疑是個榮耀，一個成果。但是我作為一個軟件小組的組長，出現(xiàn)這樣的情況是嚴重的失職和失敗。且不說組長大材小用了，組員們那些大批人力資源白白浪費掉了，畢竟一個人的精力是有限的，項目做完同時也讓我身心疲憊。
2、交流嚴重不足。
分工不明確有很多原因。其中一個原因是因為我和我的組員交流不夠，組員與組員之間的就更加缺乏交流。缺乏交流的所導致的嚴重后果是，我不明白組員們的想法，組員們不明白我的想法，組員于組員之間都不知道對方在做什么！初步的分工后，各種寫各的代碼，且不說編程風格了，光是變量和函數(shù)的命名在代碼集成的時候都可以要人命。各自有各自的一套命名習慣。很多變量和函數(shù)的作用原本是相同的，但是因為命名的原因就不得不花很多的精力來檢查和修改，極度的浪費時間和資源。而且由于交流的不足，我做代碼集成的時候，很多人的代碼根本都無法集成進去，我不得不重新自己來寫過。
3、文檔完全無用。
可以說從項目開始到測試完成，都沒有產(chǎn)生任何文檔。文檔是在最后要結項的時候補的，這樣的文檔完全無用，完全失去了做文檔的意義。文檔的作用就是用來指導和驅動軟件開發(fā)的，現(xiàn)在我們做的文檔完全是為了“做文檔”而去寫的。
三、從另外一個角度看軟件項目管理
我的第二次的學校的科研項目課題是《排序算法的研究應用》。這次是我班的龍國力同學帶隊的。我作為組員加入其中，擔任該項目的軟件設計人員。在參與這個項目的同時，我同時從組員的角度來看軟件開發(fā)的項目管理，并且從中總結學習經(jīng)驗。
這一次項目開發(fā)，我是組員，當然輕松很多了。我可以把時間放在設計軟件的框架上面。從一開始我就明確自己作為一個設計員的責任和任務。項目開發(fā)有點磕磕碰碰，但是都是技術上遇到的困難。在整個軟件開發(fā)上有條不紊的進行著。這主要是得力與龍國力同學的領導，還有一點就是我作為組員的積極配合。我們小組的組長的有權威，我和其他組員都很信服。同時我作為組員積極的配合組長進行工作的展開，經(jīng)常交流，經(jīng)常反應最新的情況。
這次項目的分工很明確，組長考慮到各個組員的水平不一。所以在分配任務的時候充分的考慮了這一點。組長：龍國力負責軟件的界面框架設計、實現(xiàn)、各種排序算法的整合。組員：羅鑫負責軟件內核框架設計和實現(xiàn)，并且輔助界面框架設計。其他組員：分別負責各種不同類型的排序算法的實現(xiàn)。在小組例會的時候，把我以前小組遇到過的問題和大家交流。會議一般都是由組長組織，每次開會都有明確的會議內容和這階段的分工明細。會議的時間也不長，很有效率。
對比之前我?guī)У捻椖?，這次無疑比上次成功了很多。我之前帶的項目基本上是自己做、沒有明確的分工、缺乏與組員之間的交流、我的想法也無法到達下面的組員、組員的想法也很少反映到我這里。所以項目一做下來，累都累死人。這次我是作為組員加入項目的，我認識到如果組長不分配任務給我不明確我的任務的話，我作為組員就不知道應該如何做起，也
就一直無所事事了。所以組長為了充分利用我們各個人的特點，對我們進行了任務分配，明確我們各種的任務，這樣大家就有了努力的方向。同時作為組員我也充分的配合組長的工作，積極和組長交流，明確自己任務的同時也盡量的幫他分擔相應的工作。組長就可以更加專心的致力于對軟件開發(fā)的進行全局性的規(guī)劃。.這次項目我作為組員得到以下幾點體驗：
1、相信和支持組長。
相信和支持自己的組長。論他的能力是否比你差，你都要去支持。畢竟每一個人的都是有自己擅長的一面和不擅長的一面。軟件開發(fā)的組長，是一個團隊的核心也是一個團隊的靈魂。作為組員應該支持和信任自己的組長，支持并且主動承擔一些工作，這樣組員于組長之間有了良好的合作氣氛，對軟件開發(fā)百利而無一害。
2、明確自己的能力、工作和職責。
船沒有導航的設備是無法遨游于大海之上的，人也是一樣，程序員也一樣。如果沒有具體的工作和明確的職責，人就無法展開工作。到頭來只能這做做那做做，最后一事無成。別人眼里頭看看來此人就是在消極待工。
3、及時反饋進度。
組員和組長總會意見出入的時候，組員無法確切的理解組長的意思，組長也無法確切的了解組員的進度。經(jīng)常出現(xiàn)組長想做個飛機，組員卻做成了坦克。組員這時候又不得不返工，浪費人力也浪費時間。所以要及時的反饋自己的進度、根據(jù)組長的意思及時修正、最大限度的滿足組長提出的要求、同時也減少自己返工重做的次數(shù)。
同時我從組員的角度看軟件項目管理，我有以下心得：
1、組長要相信自己的組員。
作為組長要敢于善于聽組員的意見，也要敢于善于把重任賦予別人。要充分的營造一個和諧的合作氣氛，減少組員和組長之間的溝通阻礙。
2、分工要明確。
組長要根據(jù)個人的能力進行分工，明確組員們的任務、職責和完成時間。盡量把工作攤開來，讓自己能夠很專心的對整個軟件開發(fā)進行規(guī)劃，掌握全局。
3、任務跟蹤。
對于每個組員分擔下去的任務，要及時檢查和糾正。定期召開例會，檢查和跟蹤當
前的項目進度。
四、初試鋒芒
經(jīng)過前兩次的項目之后，自己逐漸有了一點點項目管理的經(jīng)驗了。我自然的就迫不
及待的想在具體的項目中進行實踐。所以我又去唐老師那里接了一個項目《基于局域網(wǎng)的存儲網(wǎng)格系統(tǒng)的研究于應用》這個項目剛剛申請，還沒有完全啟動起來。同時現(xiàn)在正好進行清華IT的實訓，我接著擔任一個實訓小組的組長，我的組員就是本宿舍的人。分組沒有找到想要的合作伙伴，但是好歹本宿舍還有一個兩個不錯的合作伙伴。一開始
拿的牌不算太好，甚至有點爛。我就在思索如何把不好的牌打成好牌。
宿舍都有些問題人物、懶、游戲、什么都不管、實訓也不參加。對于這些人，我只
好放棄，他們能進來做事那最好。不能的話就算了，反正我的底線是他們不能影響到整個實訓的項目開發(fā)。
我開始對我的小組做了以下工作：
1、角色分配。
通過對每個人的性格，水平，人緣進行相關的分析和思考后，我將我的組員們進行
角色分工。分為兩組：軟件開發(fā)設計組（組長：吳天柱）軟件測試小組（組長：李海強）。選定這兩個人為小組組長是有原因的，吳天柱：有一定的項目開發(fā)經(jīng)驗并且和我合作過、相當值得信任并且有很強的責任感。所以我讓他擔任設計開發(fā)組長，通過他來督促和管理他該組的組員。李海強：沒有太多的開發(fā)經(jīng)驗，但人緣很好責任感強。所以我讓他擔任測試小組的組長，通過他督促和管理該組的組員。
2、任務分工。
我將各個任務肢解，對兩個組長分配大任務，并且限定完成任務的時間。兩個組長
得到的都是比較大的任務，所以他們就得再次分工，把具體的工作分配到各個組員身上。同時我也限定了每組組長必須在限定的時間內上交想要的文檔。這樣從上到下就把任務分配下去了。
3、營造協(xié)作環(huán)境，付重任與人。
為了營造這種交流環(huán)境，我把交流協(xié)作的中心放在兩個小組的組長身上。通過他們
兩個為中心進行交流。對于軟件的需求分析和軟件結構的設計，我只是提出自己的設想和方向，規(guī)定一些必需要達到的要求。首先讓我的兩個組長理解我的基本要求，然后讓他們在保證我的基礎要求之上，自己進行具體的設計和規(guī)劃。最后在將他們的設計進行再分工。這樣他們就有了充分的自由發(fā)揮的空間。這樣就有了一定的彈性空間，讓大家的意見能夠充分的整合在一起。
4、規(guī)范文檔驅動軟件開發(fā)。
從實訓開始，我就嚴格的安裝整個軟件開發(fā)的流程一步步往下做。每一階段都會有
相應的文檔產(chǎn)出，同時文檔一直在迭代在修改。我們小組在做需求分析的時候，需求分析文檔經(jīng)歷過3到4次迭代，來適應新的需求變化。文檔的頁數(shù)從原來的20多頁一直增長到最終的40多頁。同時各種計劃和分工統(tǒng)統(tǒng)文檔化，項目計劃，某階段的項目分工，等等都統(tǒng)統(tǒng)以文檔的形式記錄和傳達。文檔記錄了過去一階段的工作成果，同時也指引我們未來的工作。
5、人員危機處理。
實訓小組可能出現(xiàn)的最大危機，就是人員危機。參加實訓的人的積極性，一天比一
天下降，從原來都去聽課，到現(xiàn)在很少人聽課。這一點我在組隊之初，就考慮到了這一點。整個實訓項目的進度不能因為幾個懶惰的人而中止，所以我在角色分配的時候給有責任心的人，賦予重任就是這個原因。實訓進行下去到最后，必然就是那幾個有責任心的人撐到最后的。至于對其他那些人，能鼓勵就鼓勵他們多參與，若不能的話，就隨他吧。不可能為了幾個人，而耽誤其他有心學習的人的實訓。
目前我們實訓小組的現(xiàn)在正在概要設計和詳細設計階段。前一階段所做的工作，產(chǎn)
生相應的《需求報告說明書》《項目計劃》都得到了實訓老師的肯定和好評，小組有條不紊的繼續(xù)前進。我相信我們認真的堅持做下去，會有很大的收獲的。
五、結語
以上的一些感想和體會，都是通過反思和總結這一年多來的我參加的各種學生科研項目和實訓中得到的?？梢员ＷC文章完全的真實性，雖然我所想的和專業(yè)的軟件項目管理還是有很大很大的差距，但是那也是我通過很多次的實踐得到的。其中也經(jīng)歷了很多勞累和心酸，畢竟這是通過自己努力得到的東西，在我自己看來還是彌足珍貴的。
第二篇：軟件開發(fā)項目管理（范文）
管理目標
1、所有關系人清晰明確地了解項目的需求和期望，努力做到滿足項目所有關系人的不同需求；項目關系人包括：項目團隊成員和項目團隊外(內部/外部客戶，內部/外部合作伙伴，經(jīng)銷商/客戶等)。
2、項目管理三要素平衡（時間/成本/質量），即開發(fā)項目按需按時按質的完成。
3、目標：功能滿足需求，設計支持變化，開發(fā)快速迭代，成果持續(xù)交付。
執(zhí)行概述
1、建立有效的工作流程保證項目的順利進行，初期使用傳統(tǒng)RUP過程，引入部分敏捷方法，團隊磨合完成后逐步實現(xiàn)敏捷開發(fā)全流程管理。
2、明確項目目標，制定具有可行性的項目計劃，有效明確的分解項目需求。
3、跟蹤設計/開發(fā)/測試/回歸/發(fā)布全流程，推動項目按預定計劃執(zhí)行。
4、解決項目過程中出現(xiàn)的問題和沖突，一般集中在需求不明/工作量或時長/開發(fā)難度/跨部門協(xié)調等幾個方面。
5、調動開發(fā)團隊的積極性，創(chuàng)造力，推動團隊成員在項目過程中的學習成長。
6、風險識別、風險控制以及風險的預案。
項目管理
1、需求階段
對項目進行技術可行性分析、技術評估、成本評估以及風險評估。與需求提出方的代表進行需求討論，明確項目的目標、價值。確定項目范圍、功能及優(yōu)先級。
組建項目團隊，特別要搞清楚項目的關鍵人。項目啟動會議，相關的關系人都必須參加。
2、設計階段
根據(jù)確認后的軟件需求規(guī)格說明書，制定項目進度計劃，工作任務分解(WBS)；資源申請，項目涉及到的開發(fā)資源、測試資源、設計資源(包括人員和軟硬件資源)；數(shù)據(jù)庫設計；系統(tǒng)設計；文檔(包括系統(tǒng)用例、Demo、測試用例等)；評審會議。
設計階段結果交付一般為系統(tǒng)用例/系統(tǒng)原型/系統(tǒng)設計文檔(概要設計和詳細設計)/數(shù)據(jù)庫設計文檔等。
該階段交付成果需要進行評審。
3、執(zhí)行階段(開發(fā)和測試)準備開發(fā)環(huán)境、測試環(huán)境。跟蹤，推動項目按計劃進行。
項目成員以日報/項目負責人以周報的形式通報各關系人當前項目的進展情況。按里程碑對階段成果進行評估，以確保該階段完成的質量。代碼審核，包括CS審核、SQL審核、WEB審核等。對需求變更進行控制管理。
測試階段BUG響應及改進、收集反饋意見。對項目風險進行管理。
4、發(fā)布階段
包括制定項目發(fā)布計劃，用戶培訓，發(fā)布上線。
5、試運行階段
數(shù)據(jù)監(jiān)控(日志、服務器狀態(tài))，根據(jù)監(jiān)控出現(xiàn)的問題，及時進行處理，改進性能問題，特定情況執(zhí)行補丁升級。
6、收尾階段
產(chǎn)品交付，項目總結會。
常見問題
1、開發(fā)時間的估算
制定項目計劃時，需要估算每個任務所需的時間，其中主要是開發(fā)任務中模塊的分配和時間估算，在公司現(xiàn)有的技術框架下，開發(fā)人員主要的工作是投入在具體的業(yè)務邏輯實現(xiàn)上。通常單個模塊開發(fā)時間取決于以下因素：
1、負責模塊的業(yè)務邏輯的復雜程度。
2、開發(fā)人員的技術水平和對項目所在應用的熟悉程度(包括對框架和應用的熟悉程度)。
3、模塊技術實現(xiàn)上是否存在難點，所謂的技術難點定義是：在現(xiàn)有系統(tǒng)中還未實現(xiàn)的、開發(fā)人員自身未沒接觸過的技術。對于這樣的難點，開發(fā)者沒有相關的代碼可以參考，自己也沒有經(jīng)驗，所以需要投入學習時間用于研究解決。
模塊分配和開發(fā)時間估算的步驟：
1、在劃分好模塊后，首先項目管理人員預先估算各個模塊所需要的開發(fā)時間。
2、召集所有開發(fā)人員，討論模塊的分配和開發(fā)時間估算。將劃分好的模塊，分配給開發(fā)人員，如狀況允許可允許開發(fā)人員自主選擇以提高開發(fā)人員的主動性和參與性。分配模塊的時為確保開發(fā)的速度和質量，基本原則如下：
A、類似的模塊由同一人負責開發(fā)，比如用戶信息的增刪改應由同一開發(fā)者負責。這樣開發(fā)者對相關邏輯會比較熟悉，代碼/接口的定義也會相對明確，溝通的成本低，相應可以降低功能實現(xiàn)的缺陷概率。
B、技術難度較大的模塊由技術水平比較高的人負責。C、業(yè)務邏輯比較復雜的由對業(yè)務邏輯比較了解的人負責。
3、模塊分配完成后，開發(fā)人員評估自己負責開發(fā)的模塊所需要的時間。在此過程中應
4、對開發(fā)人員估算的時間進行確認。在確認過程中作為，項目管理者將預估時間和開與開發(fā)者討論每個模塊的技術實現(xiàn)細節(jié)，使時間的估算更加準確。發(fā)人員估算時間進行比較。那些差異較大的，與人員探討其中的緣由。對于時間周期比較長的任務，將任務拆分為更小的子任務，每個任務的完成時間為8-24工時，消除時間周期較長的任務，避免不確定性影響項目的進度。
2、CodeReview CodeReview是保證項目中代碼質量非常重要的一個環(huán)節(jié)，在這一環(huán)控制不嚴往往是測試后出現(xiàn)大量bug的主因，有時甚至導致返工；關于CodeReview執(zhí)行，首先應有編碼規(guī)范和代碼審查規(guī)范。通過這兩個文檔來規(guī)范開發(fā)人員的代碼實現(xiàn)，代碼編寫者必須要嚴格按照規(guī)范來進行；代碼審核者根據(jù)這些標準來CodeReview代碼，同時在CodeReview過程中需要不斷完善該文檔。
CodeReview一般可按以下步驟實施：
1、檢查開發(fā)者的代碼實現(xiàn)是否遵循了編碼規(guī)范。
2、從代碼的易維護性、可擴展性角度考察代碼的質量，提出修改建議。
3、代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UseCase依次講解自己負責的代碼和相關邏輯，代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發(fā)現(xiàn)隱藏的bug，對這些bug記錄在案。
4、代碼講解完畢后，代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要檢查Bug。同時全面兼顧，確保代碼整體上結構優(yōu)良；審核完畢后，代碼審核者編寫“代碼審核報告”記錄發(fā)現(xiàn)的問題及修改建議，提交給相關人員。
5、代碼編寫者根據(jù)“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。
6、代碼編寫者bugfixed完畢之后給出反饋。
7、代碼審核者把CodeReview中發(fā)現(xiàn)的有價值的問題更新到“代碼審核規(guī)范”的文檔中，對于特別值得提醒的問題可群發(fā)email給所有技術人員。
3、需求變更管理
需求變更管理也是項目管理中最重要的一個環(huán)節(jié)，對需求變更管理的有效性將直接影響對待需求變更的正確態(tài)度：
1、需求變更是不可避免的。
2、需求變更要必須被管理。
3、積極發(fā)現(xiàn)引起變更的因素，促使變更盡可能早的出現(xiàn)，減低變更帶來的風險。需求變更管理的目標：
1、相關的干系人必須清楚地了解發(fā)生的變更。
2、變更處于有效的管理中。
3、盡量降低變更帶來的風險。
通過制定需求變更的流程，確保項目中的需求變更有效地進行，實現(xiàn)上述的目標。需求變更流程：
1、確定需求的基準線。將以UserCase作為需求基準線，在UserCase確認之后的任項目的成功與否。何需求改變，都需要走需求變更流程。
2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產(chǎn)品經(jīng)理、市場人員、開發(fā)人員、測試人員等。
3、項目管理者評估該需求變更。針對接收到的需求變更的要求，召集相關人員討論該需求變更的合理性、可行性，實施的代價以及對項目的影響。項目管理者對項目的成功與否負有主要的責任。需求變更的決策應由項目管理者做出。
4、需求變更確認后，由專人將生成需求變更單記錄下來，通知給項目中所有關系人。
5、確定變更的負責人。承擔需求變更的具體工作，比如基線控制，對需求變更的記錄，并通知相關人員。
6、相關人員接收到確認的需求變更后，需求分析人員修改需求說明書和UserCase的相關內容。測試人員修改測試用例的相關內容。開發(fā)人員修改代碼中的相關部分。
7、按照變更后的計劃實施項目，并進行檢查，跟蹤，對變更后的實施反饋和可能出現(xiàn)的問題及時溝通和處理。
8、需求凍結。項目越到后期，需求變更對項目的影響就越大，所以在一定時候要進入需求凍結階段，不再接收新需求或需求的變更。
4、風險管理
影響項目成敗的因素涉及方方面面，并且風險伴隨著項目的始終，是客觀存在的，風險引起的負面后果集中體現(xiàn)在進度延后、成本超支、質量不達標等方面，常見風險如下：
1、目標以及需求不明確
為了市場競爭或內部管理決策的需要，業(yè)務部門提出的需求往往要求的時間比較緊迫，需求的提出大多停留在幾張紙或口頭的傳達上，沒有正式的業(yè)務需求文檔，在沒有明確的需求范圍的情況下，有時為了迎合業(yè)務部門的口味匆匆開工，過程中用戶不斷地提出新的想法，技術人員開始疲于奔命和應付，很難保證項目的進度和質量，也難以取得業(yè)務部門的認可。
在項目的前期一定要采取相應的手段或措施，與業(yè)務部門共同明確項目目標、需求范圍，充分考慮現(xiàn)有的時間和資源約束，將需求排定優(yōu)先級，對于關鍵的需求優(yōu)先實現(xiàn)，其他輔助性的根據(jù)過程中的具體情況進行滾動式計劃，并取得業(yè)務部門的書面確認。在此過程中要注重挖掘用戶的隱性需求，可以通過引導、系統(tǒng)原型等手段讓用戶在前期充分暴露自己的想法和需求。
2、項目目標擴大以及需求變更
在有了明確的目標和需求范圍的情況下，需求的變更還是不可避免的，業(yè)務部門在看到具體系統(tǒng)的真實雛形之后，源源不斷地要求、新想法隨之產(chǎn)生，如果不對此加以控制，新的需求的加入通常會影響已實現(xiàn)的需求，并且對項目進度和成本產(chǎn)生很大的影響。項目管理者針對這種情況一定要采取嚴格的變更控制流程，不能礙于面子，否則最終的結果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相關團隊成員進行分析及評估，作為是否實施的依據(jù)，變更控制負責人根據(jù)分析結果判斷是否批準，如果批準，那項目組可以安排實施，否則，正式拒絕用戶的請求。
前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產(chǎn)品經(jīng)理、相關職能主管、客戶)，所有的需求要經(jīng)過他們的認可?？蛻粼陧椖窟^程中的全程參與有助于降低此類風險。需求討論、需求確認、UserCase確認、測試階段的客戶驗收等環(huán)節(jié)，都要要求客戶參與。在發(fā)生需求變更時，嚴格按照需求變更流程執(zhí)行。在分析設計階段的中的確認和評審也是降低此類風險的重要手段。
3、代碼質量風險
質量風險主要指開發(fā)代碼的質量。在制定項目計劃時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質量的影響很大。開發(fā)人員為了趕進度在比較緊張的時間需要完成指定的任務，可能就存在很大的開發(fā)質量問題。在編碼前，開發(fā)人員要對框架熟練掌握；一份好的系統(tǒng)設計文檔對指導開發(fā)非常重要。
往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是100%完成，但一到最后系統(tǒng)交互測試或集成的時候就會發(fā)現(xiàn)一大堆問題。這需要在項目實施過程中采取有效的措施來規(guī)避風險，通常的做法有同行評審，比如概要設計完成之后，邀請其他項目組的技術專家進行技術評審以發(fā)現(xiàn)架構設計問題；管理評審，通過組織級的質量審計看產(chǎn)品以及實施過程是否滿足質量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規(guī)范或性能要求的代碼，走查通常能夠發(fā)現(xiàn)50%-70%的錯誤；每日構建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發(fā)現(xiàn)相應的錯誤，日構建一般在項目的中后期開始，每天自動從版本服務器上獲取源代碼進行自動編譯和測試。
4、人員技能和資源的不足
項目實施過程中由于人員技能欠缺造成的進度延后和軟件質量問題并不少見，一個熟練的技術人員完成同樣一個任務需要3天，但一個新手可能就需要7-10天。項目管理者應該在前期就分析清楚項目所要采用的技術以及相應的人員技能要求，針對不同的角色，及時采取相應的技能培訓，以保證項目的順利實施。開發(fā)過程中遇到技術難題，導致開發(fā)時間延遲或者需求不得不發(fā)生變更。在項目開始前的技術評估階段，明確技術難點，提前安排人員進行攻克。如果在可預期的時間內無法解決，如果可以，將向需求提出方要求變更需求或尋找可替代方案。這樣的風險應該在項目的前期階段就應該解決在萌芽狀態(tài)來避免這樣的風險在后期或中期出現(xiàn)。
5、缺乏良好的團隊協(xié)作
軟件項目實施屬于知識型，要發(fā)揮團隊成員的創(chuàng)造力，不同于制造業(yè)計件生產(chǎn)，各模塊最終要集成在一起形成一個有機的整體，這就需要各小組之間的密切配合，界定清楚工作界面及接口關系，并在實施過程中持續(xù)地溝通交流和共享，首先團隊要融為一體，產(chǎn)出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協(xié)作好壞也將是個潛在的風險問題，在項目啟動和團隊組建的時候就應該加以規(guī)避這樣的風險出現(xiàn)。
6、項目會議
組織會議是項目執(zhí)行過程中一項非常重要的工作任務，項目過程中很多重要的決定都是在會議中做出的，不成功的會議會對項目本身造成了不好的影響。
不成功的會議通常表現(xiàn)為如下形式：
1、會議氛圍不好，參與者發(fā)言不踴躍；
2、會議討論常常偏離主題；
3、會議沒有取得預期的結果；
4、會議時間常常一拖再拖。
這些不成功的會議最終的結果就是：既浪費了大家的寶貴時間又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應該注意的問題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必須要清楚：
1、會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會議才有可能取得成功，這是會議成功的充分條件。
2、會議的組織者和參與者的想法通常是不一致的，有時候甚至會大相徑庭。所以不要希望會議的參與者和你一樣，對會議有著如此的期待，對大多數(shù)參與者而言，在會議中他只是一個發(fā)表想法的人，他不用對會議的成功承擔責任。
3、以下十一條最佳實踐是形式上的約定，具體的實施可以根據(jù)實際情況來做。組織會議的十一條最佳實踐：
1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。
2、提前發(fā)出會議議程，以便會議參與者知道他們來做什么。
3、請對人很重要，不要把非必要的人召來開會，當然也不要漏掉那些關鍵人物。在確保必要人物都在的情況下一次會議參與者越少效果越好。
4、提前預約參與者的時間，以確保他們能按時到場。
5、會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在開場時說： A、再一次強調會議的目標，我們來做什么。
B、強調會議的主題與基調。比如：本次會議是一個需求確認會，而非需求討論會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論如何做上面。
C、說明一下會議的規(guī)則。如要發(fā)言，請舉手；不要有小圈子討論；不要打斷別人的講話，等別人說完你再說等等。
6、會議過程中時刻注意引導和控制會議，以確保會議按照目標進行。一次會議的氛圍是否良好，討論是否充分，好的引導至關重要。比如多提一些開放式的問題。
7、會議記錄很重要，把一些結論和有價值的內容記錄下來，這些是本次會議的重要成果之一。
8、會議要有結論。我們常在會議上聽到有人說：“大家討論了這么半天，結論呢？”。沒有結論的會議是沒有意義的。
9、會議后別忘發(fā)會議紀要，以及一些Action，什么人什么時候做什么。
10、會議后的action執(zhí)行情況的反饋很重要。反饋是對會議參與者的尊重，同時也告知了會議的效果。否則會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性也會降低。很多會議往往都不注意這一點。
11、按時結束的會議會受到所有人的歡迎。
第三篇：淺談軟件開發(fā)項目管理
淺談軟件開發(fā)項目管理
摘要：在軟件項目開發(fā)的過程中，軟件項目管理的成功與否是決定一個項目是否能夠順利高效率完成的重要保證。但是我國大部分的軟件企業(yè)在進行項目管理時都存在著各種問題，從而使項目不能順利有效地完成。文章探討了在項目管理過程里出現(xiàn)的常見問題，并給出了相應的解決策略。
關鍵詞：軟件項目管理；項目經(jīng)理；項目計劃
軟件行業(yè)在現(xiàn)在的眾多行業(yè)里是一個極具挑戰(zhàn)性和創(chuàng)造性的行業(yè)，體現(xiàn)了軟件開發(fā)者的智慧和汗水，同時軟件開發(fā)是一項復雜的系統(tǒng)工程。牽涉到許多方面的因素，在實際工作中，經(jīng)常會出現(xiàn)各種各樣的問題，甚至會面臨失敗。如何總結、分析失敗的原因。得出有益的教訓，對于項目開發(fā)人員來說，是在今后的項目中取得成功的關鍵。
一、軟件開發(fā)中實行項目管理的意義
項目管理就是在項目活動中運用一系列的知識、技能、工具和技術，以滿足或超過相關利益者對項目的要求，實際上就是通過項目各方干系人的合作，把各種資源應用于項目，以實現(xiàn)項目的目標，滿足項目干系人的需求，其本質就是對時間、質量和成本的管理。隨著軟件開發(fā)的深入、各種技術的不斷創(chuàng)新以及軟件產(chǎn)業(yè)的形成，人們越來越意識到軟件過程管理的重要性，管理學的思想逐漸融入軟件開發(fā)過程中，項目開發(fā)的管理日益受到重視。
二、目前在軟件項目管理中存在的誤區(qū)
現(xiàn)在大多數(shù)企業(yè)都認識到了在項目中進行管理的重要性，但是仍然有許多企業(yè)在實施項目管理的過程中存在著這樣那樣的誤區(qū)，主要表現(xiàn)在：項目經(jīng)理不夠專業(yè)。在軟件企業(yè)中，缺乏專業(yè)的項目管理人員來實施項目管理及擔任項目經(jīng)理，通常被任命的項目經(jīng)理主要是因為他們能夠在技術上獨當一面，但是他們在管理方面特別是項目管理方面的知識比較缺乏。項目計劃缺乏綱領性。項目經(jīng)理對總體計劃、階段計劃的作用認識不足，因此制定總體計劃時比較隨意，不少事情沒有仔細考慮：階段計劃因工作忙等理由經(jīng)常拖延，造成計劃與控制管理脫節(jié)，無法進行有效的進度控制管理。缺乏有效的管理意識。部分項目經(jīng)理不能從總體上把握整個項目，而是埋頭于具體的技術工作，造成項目組成人員之間忙的忙、閑的閑，計劃不周、任務不均、資源浪費。有些項目經(jīng)理沒有很好的管理方法，不好安排的工作只好自己做，使項目任務無法有效、合理地分配給相關成員，以達到“負載均衡”。缺乏有效的溝通制度和機制。在項目中一些重要信息沒有進行充分和有效的溝通。在制定計劃、意見反饋、情況通報、技術問題或成果等方面與相關人員的溝通不足，造成各做各事、重復勞動，甚至造成不必要的損失：有些人沒有每天定時收郵件的習慣，以至于無法及時接收最新的信息。風險管理意識淡泊。有些項目經(jīng)理沒有充分意識到風險管理的重要性，對計劃書中風險管理的章節(jié)簡單應付了事，隨便列出幾個風險，隨便地寫一些簡單的對策，對于后面的風險防范起不到什么指導作用。項目干系人的不確定性。在范圍識別階段，項目組對客戶的整體組織結構、有關人員及其關系、工作職責等沒有足夠了解以至于無法得到完整需求或最終經(jīng)權威用戶代表確認的需求：或者是多個用戶代表各說各話、昨是今非，但同時又要求項目盡早交付：項目后期需求變化隨意，造成項目范圍的蔓延，進度的拖延，成本的擴大。缺乏項目團隊的合理分工。項目團隊內部有時由于各階段不同角色或同階段不同角色之間的責任分工不夠清晰而造成工作互相推諉、責任互相推卸的現(xiàn)象；有時各階段不同角色或同階段不同角色之間的責任分工比較清晰，但是各項目成員只顧完成自己那部分任務，不愿意與他人協(xié)作。這些現(xiàn)象都將造成項目組內部資源的損耗，從而影響項目進展。
三、解決軟件項目管理中存在的誤區(qū)的有效策略
要想解決上面描述的誤區(qū)，歸根到底還是要從管理學的角度入手，即在軟件項目的開發(fā)過程中加入過程管理的內容，這樣我們可以在軟件開發(fā)中對各個過程的質量加以控制，從而達到保證軟件產(chǎn)品質量的目的。為了有效提高管理水平，我們應該努力做到：項目經(jīng)理接受系統(tǒng)的項目管理知識培訓是非常必要的，有了專業(yè)領域的知識與實踐，再加上項目管理知識與實踐和一般管理的知識和經(jīng)驗的有機結合，必能大大提高項目經(jīng)理的項目管理水平。計劃的制定需要在一定條件的限制和假設之下采用漸近明細的方式進行不斷完善。提高項目經(jīng)理的計劃意識，采用項目計劃制定相關知識、技術、工具，加強對開發(fā)計劃、階段計劃的有效性進行事前事后的評估。加強項目管理方面的培訓，并通過對考核指標的合理設定和宣傳引導項目經(jīng)理更好地做好項目管理工作。技術骨干在擔任項目經(jīng)理之前，最好能經(jīng)過系統(tǒng)的項目管理知識，特別是其中的人力資源管理、溝通管理的學習，并且在實際工作中不斷提高自己的管理素質，豐富項目管理經(jīng)驗，提高項目管理意識。制定有效的溝通制度和溝通機制，提高溝通意識：采取多種溝通方式，提高溝通的有效性。通過制度規(guī)定對由于未及時收取郵件而造成損失的責任歸屬；對于特別重要的內容要采用多種方式進行有效溝通以確保傳達到位，例如：除發(fā)送郵件外還要電話提醒、回執(zhí)等，重要的內容還要通過舉行各種會議進行傳達。通過學習項目管理知識掌握風險識別、量化、對策研究、反應控制的工具和方法，掌握項目風險管理所必備的知識。通過加強對項目規(guī)劃中風險管理計劃的審核提高項目組的風險管理意識?？偨Y本行業(yè)項目中常見的風險及其對策作為風險管理計劃中必要的風險內容，并切實評估相應對策的有效性和可行性。項目的目的就是實現(xiàn)項目干系人的需求和愿望。項目干系人管理應當從項目的啟動開始，項目經(jīng)理及其項目成員就要分清項目干系人包含哪些人和組織，通過溝通協(xié)調對他們施加影響，驅動他們對項目的支持，調查并明確他們的需求和愿望，減小其對項目的阻力，以確保項目獲得成功。項目經(jīng)理應當對項目成員的責任進行合理的分配并清楚地說明，同時應強調不同分工、不同環(huán)節(jié)的成員應當相互協(xié)作，共同完善。
實施有效的項目管理絕非易事，對于軟件企業(yè)而言，這不是一個小的改變，而是一種變革，企業(yè)需要為此付出艱苦的努力，同時，成熟有效的項目管理無疑將對企業(yè)起著至關重要的作用，項目管理的水平將是企業(yè)核心競爭力之一。
第四篇：軟件開發(fā)項目管理實施方案.
項目管理實施方案
作為一個項目管理者,如何要成功的做好項目管理;首先必須先要明白的是在特定的領域中賦予這個角色所要實現(xiàn)的目標、承擔的職責、以及項目管理者的具體工作內容是什么? 從我個人的淺見和角度以及我們所從事的IT領域來分析回答以上三個問題。第一:目標
作為一個項目的管理者,必須要明確的知道自己的工作目標;我個人認為項目管理者的目標無非就是以下兩點:
1、就是清晰明確地了解項目利害關系者的需求和期望,努力做到滿足項目利害關系者的不同需求;項目利害關系者包括:項目團隊成員和項目團隊外成員(比如各部門的部門負責人和市場人員,客戶等。
2、就是保證開發(fā)項目按需按時保質的完成。第二:職責
作為項目的管理者,首先要端正態(tài)度,要明確知道自己的工作職責,認識到這份工作職責的本質。項目管理者不是來管人的,而是來支持人的,是來協(xié)調資源的,是來營造一個適合團隊成員比較認同的工作環(huán)境和氛圍的,是來為一個共同的目標和大家一起戰(zhàn)斗共同成長的?？梢源蟾鸥爬ǔ梢韵聨c:
1、建立有效的工作流程保證項目的順利進行。
2、制定詳細周密的項目計劃。
3、跟蹤,推動項目按計劃進行。
4、積極解決項目過程中出現(xiàn)的問題和沖突。
5、調動開發(fā)團隊的積極性,創(chuàng)造力,推動團隊成員在項目過程中不斷成長。
6、項目風險識別、風險評估、風險解決和風險管理策略以及做好突發(fā)風險的應急預案。
7、實現(xiàn)目標
第三:項目管理者的具體工作內容
最后一個是項目管理者的具體工作內容,作為項目管理者必須清晰的知道自己的工作范圍和所要做的工作內容以及工作重心,分為以下六點:
1、項目前期階段
對項目進行技術可行性分析、技術評估、成本評估以及風險評估。與需求提出方的代表進行需求討論,明確項目的目標、價值;確定項目范圍、功能及優(yōu)先級。組建項目團隊,特別要搞清楚項目的key person(對產(chǎn)品有決定權的人。項目啟動會議,相關的
利害關系人員都必須參加。
該階段完成后的成果:確認后的最終軟件需求規(guī)格說明書文檔。
2、分析設計階段
根據(jù)確認后的軟件需求規(guī)格說明書,制定項目進度計劃,工作任務分解(WBS;資源申請,項目涉及到的開發(fā)資源、測試資源、設計資源(包括人員和軟硬件資源;數(shù)據(jù)庫設計;系統(tǒng)設計;文檔(包括Use Case、Demo系統(tǒng)原型、Test Case等;評審會議。
該階段完成后的成果: A、User Case(系統(tǒng)用例;B、DEMO(系統(tǒng)原型;
C、系統(tǒng)設計文檔(概要設計和詳細設計;D、數(shù)據(jù)庫設計文檔。
最后對完成的成果,包括User Case和設計文檔等進行評審。
3、執(zhí)行階段(開發(fā)和測試
準備開發(fā)環(huán)境、測試環(huán)境;跟蹤,推動項目按計劃進行;以周報的形式通報項目的進展情況。對項目的階段成果進行評估,以確保該階段完成的質量,包括代碼審核、SQL 審核等。對需求變更進行控制管理;對項目風險進行管理;測試階段BUG FIXED及改進、收集反饋意見。
4、發(fā)布階段
包括制定項目發(fā)布計劃,用戶培訓,發(fā)布上線。
5、上線后監(jiān)控
數(shù)據(jù)監(jiān)控(日志、服務器狀態(tài),根據(jù)監(jiān)控出現(xiàn)的問題,及時進行BUG FIXED及改進或做補丁升級。
6、結束階段
產(chǎn)品交付,項目總結會。
第四:基于以上三個問題所做的應對細則
要做好項目管理,并能確實解決好以上三個問題,實現(xiàn)目標、履行職責、完成工作中的具體內容,從我個人這幾年的工作經(jīng)驗和面臨的一些問題,還有所積累的一些項目管理中的
一些知識以及自己的觀察和思考的角度看,應該要努力做好以下這幾個方面的具體工作:
1、項目開發(fā)時間的估算
制定項目進度時間表的時候,需要估算每個任務所需的時間,其中開發(fā)任務中模塊的分配和時間估算是其中最主要的部分;在分配模塊和估算開發(fā)時間時需要遵循的原則和目標:
1、保證項目整體的進度。
2、有助于確保開發(fā)編碼的質量。
3、有助于提高開發(fā)編碼的速度。
在公司現(xiàn)有的技術框架下,開發(fā)人員主要的工作是投入在具體的商業(yè)邏輯上。通常每個模塊所需的開發(fā)時間取決于以下三個因素:
1、所負責模塊的商業(yè)邏輯的復雜程度。
2、開發(fā)人員的技術水平和對項目所在應用的熟悉程度(包括對框架和應用的熟悉程度。
3、該模塊技術實現(xiàn)上是否有技術難點;這里所謂的技術難點定義是:在現(xiàn)有系統(tǒng)中還未實現(xiàn)的、開發(fā)人員自身也未沒接觸過的技術。對于這樣的難點,開發(fā)者沒有相關的代碼可以參考,自己也沒有經(jīng)驗,所以需要投入一些時間研究解決。
模塊分配和開發(fā)時間估算的步驟:
1、在劃分好模塊后,首先自己先估算一下每個模塊所需要的開發(fā)時間。
2、然后召集所有開發(fā)人員,討論模塊的分配和開發(fā)時間估算。將劃分好的模塊,讓開發(fā)人員從中挑選他們感興趣的模塊。這樣做可以提高開發(fā)人員的主動性和參與性。在分配模塊的時候還需從以下幾方面考慮,以確保開發(fā)的速度和質量: A、相同類似的模塊由同一人負責開發(fā),比如用戶管理的增刪改由同一開發(fā)者負責。
這樣做的好處就是開發(fā)者對相關邏輯會更加熟悉,同時接口的定義也會比較明確,溝通的成本比較低,同時功能實現(xiàn)的缺陷也相應的會降低。
B、技術難度比較大的模塊由技術水平比較高的人負責。C、業(yè)務邏輯比較復雜的由對這塊邏輯比較了解的人負責。
3、模塊分配完后,開發(fā)人員評估自己負責開發(fā)的模塊所需要的時間。在此過程中最好做到要和開發(fā)者比較詳細的討論每個模塊的技術實現(xiàn),以便使時間的估算更加準確。
4、對開發(fā)人員估算的時間進行確認。在確認過程中作為項目管理者應參考以上提到的三個因素,同時將自己估算的時間和開發(fā)人員估算的時間進行比較。這其中的差異當然會存在的。對于那些差異比較大的,將與技術人員探討其中的緣由。對于時間周期比較長的任務,盡量將任務通過再細分的手段細化任務,爭取每個任務的最長時間不超過3天;時間周期越長的任務,不確定性越高,風險也越高,越有可能成為項目的瓶頸,影響項目的進度。
2、Code Review Code Review是保證項目中代碼質量非常重要的一個環(huán)節(jié),在這一環(huán)中我們公司做的非常欠缺,把關不嚴格;這是導致每次測試后出現(xiàn)大量bug的主要原因,這一環(huán)需要納入績效考核中,實行責任追究制,實施重點監(jiān)控。出現(xiàn)這樣的薄弱環(huán)節(jié),造成這樣的原因,我想也是有很多因素造成的;比如開發(fā)人員對需求不是很明確,以自己比較主觀的因素去完成任務的;還有對整個系統(tǒng)業(yè)務邏輯沒有正確的清晰的認識的原因,以及對項目組成員培訓不到位的原因等眾多因素糾集在一起才產(chǎn)生的。
如何做好這方面的工作?首先編碼要有“編碼規(guī)范”文檔,Code Review要有“代碼審
核規(guī)范”文檔:記錄代碼實現(xiàn)應該遵循的標準。通過這兩個文檔來規(guī)范開發(fā)人員的代碼實現(xiàn),代碼編寫者必須要嚴格按照規(guī)范來進行;代碼審核者根據(jù)這些標準來Code Review代碼,同時在Code Review過程中不斷完善該文檔。
在做好這些前期工作的前提下,分以下幾個步驟來實施:
1、檢查開發(fā)者的代碼實現(xiàn)是否遵循了編碼規(guī)范。
2、從代碼的易維護性、可擴展性角度考察代碼的質量,提出修改建議。
3、代碼編寫者和代碼審核者坐在一起,由代碼編寫者按照Use Case依次講解自己負責 的代碼和相關邏輯,從Web層-到Manage層再到Dao層;
4、代碼審核者在此過程中可以隨時提出自己的疑問,同時積極發(fā)現(xiàn)隱藏的bug;對這
些bug記錄在案。
5、代碼講解完畢后,代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要一
行一行靜下心來看。同時代碼又要全面的看,以確保代碼整體上設計優(yōu)良。
6、代碼審核者根據(jù)審核的結果編寫“代碼審核報告”,“審核報告”中記錄發(fā)現(xiàn)的問題
及修改建議,然后把“審核報告”發(fā)送給相關人員。
7、代碼編寫者根據(jù)“代碼審核報告”給出的修改意見,修改好代碼,有不清楚的地方
可積極向代碼審核者提出。
8、代碼編寫者bug fixed完畢之后給出反饋。
9、代碼審核者把Code Review中發(fā)現(xiàn)的有價值的問題更新到“代碼審核規(guī)范”的文檔中, 對于特別值得提醒的問題可群發(fā)email給所有技術人員。如果通過以上步驟,還因為是代碼編寫者的原因而出現(xiàn)嚴重的缺陷問題,將通過績效考核來加深代碼編寫者的印象,并在周報會議上做通報批評。
3、需求變更管理
需求變更管理也是項目管理中最重要的一個環(huán)節(jié),對需求變更管理的有效性將直接影響項目的成功與否。
對待需求變更的態(tài)度:
1、需求變更是不可避免的。
2、需求變更要必須被管理。
3、積極發(fā)現(xiàn)引起變更的因素,促使變更盡可能早的出現(xiàn),減低變更帶來的風險。需求變更管理的目標:
1、相關的干系人必須清楚地了解發(fā)生的變更。
2、變更處于有效的管理中。
3、盡量降低變更帶來的風險。
通過制定需求變更的流程,確保項目中的需求變更有效地進行,實現(xiàn)上述的目標。需求變更流程:
1、確定需求的基準線。將以User Case作為需求基準線,在User Case確認之后的任何需求改變,都需要走需求變更流程,這一環(huán)節(jié)我們基本沒有,期間有時候使的工
作很混亂,也就是因為沒有一個規(guī)范的變更流程而造成的;如果建立了這么一個流程規(guī)范和機制,需求變更沒有走這個流程的將不被認可。
2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產(chǎn)品經(jīng)理、市場人員、開發(fā)人員、測試人員等。
3、項目管理者評估該需求變更。針對接收到的需求變更的要求,召集相關人員討論該需求變更的合理性、可行性,實施的代價以及對項目的影響。包括可能影響的項目范圍,進
度,費用,質量等計劃。項目管理者作為項目的負責人,對項目的成功與否負有主要的責任。所以需求變更的決策者應該由項目管理者承擔。
4、需求變更確認后由專人將需求變更記錄下來,通知給項目中所有成員。其中以下人員對需求的變更是緊密相關的,他們必須知曉并認可此需求變更。包括(客戶方,需求分析人員,測試人員,相關開發(fā)人員。需求變更記錄格式如下: 序號變更提出時間變更描述變更類型(是 對原有需求 的修改還是 新增需求 原因變更提出 者
開發(fā)人員對進度的 影響(工 作量 2
5、確定變更的負責人。承擔需求變更的具體工作,比如基線控制,對需求變更的記錄,并通知相關人員。
6、相關人員接收到確認的需求變更后,做以下事情。需求分析人員修改需求說明書和User Case的相關內容。測試人員修改測試用例的相關內容。開發(fā)人員修改代碼中的相關部分。
7、按照變更后的計劃實施項目,并進行檢查,跟蹤,對變更后的實施反饋和可能出現(xiàn)的問題及時溝通和處理。
8、需求凍結。項目越到后期,需求變更對項目的影響就越大,所以在一定時候要進入需求凍結階段,不再接收新需求或需求的變更。
4、風險管理
風險管理是項目管理者最重要的工作之一。風險管理是一個持續(xù)的過程,貫穿于整個項目過程中,風險管理包括風險識別、風險評估、風險解決以及風險管理策略。
在項目的實施過程中需要不斷地識別和應對風險,并加以有效的控制,風險管理的好與壞直接影響項目的實施效果,從某種意義上講,項目實施對于項目管理者就是識別、分析、應對、控制風險的過程,使項目的約束性目標和質量目標朝有利的方向發(fā)展。
項目不同于日常任務,它有明確的起止時間和目標,要在明確的范圍、時間和成本約束下,達到相應的質量標準,并取得用戶的滿意。影響項目成敗的因素涉及方方面面,并且風險伴隨著項目的始終,是客觀存在的,作為一個項目管理者,應該具備良好的風險控制意識,善于識別風險并分析風險的影響,從中發(fā)現(xiàn)影響目標的風險點,并施
加影響或采取應對措施,把風險的負面影響降到最低,并且風險控制應該貫穿項目始終。
風險引起的負面后果集中體現(xiàn)在進度延后、成本超支、質量不達標等方面,導致這些問題的因素主要包括目標以及需求不明確、范圍蔓延以及需求變更、代碼質量或返工風險、人員技能和資源的不足、缺乏良好的團隊協(xié)作等。下面將詳細描述一下這些問題以及出現(xiàn)這些問題時的應對方案:
1、目標以及需求不明確
為了市場競爭或內部管理決策的需要,業(yè)務部門提出的需求往往要求的時間比較緊迫,需求的提出大多停留在幾張紙或口頭的傳達上,沒有形成正式的業(yè)務需求文檔,在沒有明確的需求范圍的情況下,有時為了迎合業(yè)務部門的口味匆匆開工,過程中用戶不斷地提出新的想法,技術人員開始疲于奔命和應付,很難保證項目的進度和質量,也難以取得業(yè)務部門的認可。所以,在項目的前期一定要采取相應的手段或措施,與業(yè)務部門共同明確項目目標、需求范圍,充分考慮現(xiàn)有的時間和資源約束,將需求排定優(yōu)先級, 對于關鍵的需求優(yōu)先實現(xiàn)，其他輔助性的根據(jù)過程中的具體情況進行滾動式計劃，并取 得業(yè)務部門的書面確認。在此過程中要注重挖掘用戶的隱性需求，可以通過引導、系統(tǒng) 原型等手段讓用戶在前期充分暴露自己的想法和需求。
2、范圍蔓延以及需求變更 在有了明確的目標和需求范圍的情況下，需求的變更還是不可避免的，業(yè)務部門在 看到具體系統(tǒng)的真實雛形之后，源源不斷地要求、新想法隨之產(chǎn)生，如果不對此加以控 制，新的需求的加入通常會影響已實現(xiàn)的需求，并且對項目進度和成本產(chǎn)生很大的影響。項目管理者針對這種情況一定要采取嚴格的變更控制流程，不能礙于面子，否則最終的 結果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相 關團隊成員進行分析及評估，作為是否實施的依據(jù)，變更控制負責人根據(jù)分析結果判斷 是否批準，如果批準，那項目組可以安排實施，否則，正式拒絕用戶的請求，當然實際 情況下可以采取一些軟措施緩解矛盾。需求變更風險：需求已經(jīng)打上了基線，但此后仍然有變更
發(fā)生，對項目造成影響。如何減少此類風險的發(fā)生？ 前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產(chǎn)品經(jīng)理、相關職能主管、客戶，所有的需求要經(jīng) 過他們的認可?？蛻粼陧椖窟^程中的全程參與有助于降低此類風險。需求討論、需求確 認、User Case 確認、測試階段的客戶驗收等環(huán)節(jié)，都要要求客戶參與。在發(fā)生需求變 更時，嚴格按照需求變更流程執(zhí)行。在分析設計階段的中的確認和評審也是降低此類風 險的重要手段。
3、代碼質量或返工風險 質量風險主要指開發(fā)代碼的質量。如何提高開發(fā)人員開發(fā)的質量？在制定項目計劃 時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質量的影響也很大。有 時開發(fā)人員為了趕進度在比較緊張的時間需要完成指定的任務，可能就存在很大的開發(fā) 質量問題。開發(fā)要有一套嚴格可行的代碼規(guī)范，編碼時嚴格遵守，到現(xiàn)在為止，我們這 個方面做的不是很規(guī)范，做的也很不足，大家編寫的代碼隨意性比較大，代碼編寫者的 主觀意識性比較強。要建立一套大家認可并且規(guī)范可行的編碼規(guī)范和考核規(guī)范，code review 時嚴格考核。在編碼前，開發(fā)人員要對框架熟練掌握；一份好的系統(tǒng)設計文檔對 指導開發(fā)非常重要。返工是項目組最不愿意看到的，既浪費人力、物力和財力，又影響團隊積極性。需 求不明確或范圍沒有有效控制都可能造成返工，另外造成返工的原因是質量沒有達到用 戶要求。往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是 100%完成，但一到最后系統(tǒng)交互測試或集成的時候就會發(fā)現(xiàn)一大堆問題，不得不花費很大精力回頭 排查、修改程序，造成這種情況的主要原因是過程中質量保證沒有做到位，把大部分問 題留在了后面。這就需要在項目實施過程中采取有效的措施來規(guī)避返工的風險，通常的 做法有同行評審，比如概要設計完成之后，邀請其他項目組的技術專家進行技術評審以 發(fā)現(xiàn)架構設計問題； 管理評審，通過組織級的質量審計看產(chǎn)品以及實施過程是否滿足質 量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規(guī)范或性能要 求的代碼，走查通常能夠發(fā)現(xiàn) 50%-70%的錯誤；每日構建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發(fā)現(xiàn)相應的錯誤，日構建一般在 項目的中后期開始，每天自動從版本服務器上獲取源代碼進行自動編譯和測試。
4、人員技能和資源的不足 項目實施過程中由于人員技能欠缺造成的進
度延后和軟件質量問題并不少見，一個 熟練的技術人員完成同樣一個任務需要 3 天，但一個生手可能就需要 7-10 天。項目管
理者應該在前期就分析清楚項目所要采用的技術以及相應的人員技能要求，針對不同的 角色，及時采取相應的技能培訓，以保證項目的順利實施。如果對于項目中某些部分專 業(yè)性特別強或新技術，短期內又不能快速建立技能的情況，可以考慮將該塊任務外包，借鑒合作商的力量降低實施風險，當然要進行外購人力成本與自建人力成本的效益分 析。開發(fā)過程中遇到技術難題，導致開發(fā)時間延遲或者需求不得不發(fā)生變更。如何減少 此類風險的發(fā)生？在項目開始前的技術評估階段，明確技術難點，提前安排人員進行攻 克。如果在可預期的時間內無法解決，如果可以，將向需求提出方要求變更需求或尋找 可替代方案。這樣的風險應該在項目的前期階段就應該解決在萌芽狀態(tài)來避免這樣的風 險在后期或中期出現(xiàn)。項目所需人力資源無法按時到位，導致資源風險。如何減少此類風險的發(fā)生？這個 就需要在項目計劃制定的時候提前申請確認資源，并在項目過程中不斷溝通協(xié)調。
5、缺乏良好的團隊協(xié)作 軟件項目實施屬于知識型，要發(fā)揮團隊成員的創(chuàng)造力，不同于制造業(yè)計件生產(chǎn)，各 模塊最終要集成在一起形成一個有機的整體，這就需要各小組之間的密切配合，界定清 楚工作界面及接口關系，并在實施過程中持續(xù)地溝通交流和共享，首先團隊要融為一體，產(chǎn)出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協(xié)作好壞也將是個潛在 的風險問題，在項目啟動和團隊組建的時候就應該加以規(guī)避這樣的風險出現(xiàn)。項目風險管理的要點：
1、上述我們所說的風險管理都是指可以預期將要發(fā)生的風險，那些不可預期將要發(fā)生 的風險不屬于風險管理的范疇。這也將是考驗一個項目管理者的經(jīng)驗和知識對能否 管理好風險至關重要的內容。
2、對不可預期的風險，項目管理者要有潛在的風險意識評估，做好一些可操作性的預 案準備。
3、詳細明確的項目計劃、以及項目執(zhí)行過程中每個要點的質量保證是降低項目風險的 必要條件。
4、風險報告是項目團隊以及領導了解項目風險的一個有效手段。風險報告的格式： 序號 風險簡介 對項目的影響 解決方案或對策
5、團隊管理 團隊就是一組個體為實現(xiàn)共同的目標而相互依賴、一起工作的共同體。團隊工作顧名思 義就是團隊成員為實現(xiàn)這個共同的目標而付出的共同努力，項目團隊的工作是否有效直接關 系到
項目的成敗。團隊管理是個漸進的過程。世界上只有完美的團隊，沒有完美的個人。好的高效的團隊 不是管理出來的，而是營造出來的。團隊成員需要有大家可認同的團隊文化，這需要大家共 同的努力。
1、營造良好的工作環(huán)境和氛圍。
2、建設優(yōu)秀或鮮明的團隊文化。
3、保持高效的溝通。
6、項目會議 組織會議是項目管理者日常工作中一項非常重要的工作任務，項目過程中很多重要的決 定都是在會議中做出的，也有很多由于不成功的會議而對項目本身造成了不好的影響。首先看看不成功的會議常常表現(xiàn)為哪些形式：
1、會議氛圍不好，參與者發(fā)言不踴躍；
2、會議討論常常偏離主題；
3、會議沒有取得預期的結果；
4、會議時間常常一拖再拖。這些不成功的會議最終的結果就是：既浪費了大家的寶貴時間又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應該注意的問 題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必須要清楚：
1、會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會議才有 可能取得成功，這是會議成功的充分條件。
2、會議的組織者和參與者的想法通常是不一致的，有時候甚至會大相徑庭。所以不要 希望會議的參與者和你一樣，對會議有著如此的期待，對大多數(shù)參與者而言，在會議中他只 是一個發(fā)表想法的人，他不用對會議的成功承擔責任。
3、以下十一條最佳實踐是形式上的約定，具體的實施可以根據(jù)實際情況來做。組織會議的十一條最佳實踐：
1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。
2、提前發(fā)出會議議程，以便會議參與者知道他們來做什么。
3、請對人很重要，不要把非必要的人召來開會，當然也不要漏掉那些關鍵人物。在確 保必要人物都在的情況下一次會議參與者越少效果越好。
4、提前預約參與者的時間，以確保他們能按時到場。
5、會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在 開場時說： A、再一次強調會議的目標，我們來做什么。B、強調會議的主題與基調。比如：本次會議是一個需求確認會，而非需求討論會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論 如何做上面。C、說明一下會議的規(guī)則。如要發(fā)言，請舉手；不要有小圈子討論；不要打斷別人 的講 話，等別人說完你再說等等。
6、會議過程中時刻注意引導和控制會議，以確保會議按照目
標進行。一次會議的氛圍 是否良好，討論是否充分，好的引導至關重要。比如多提一些開放式的問題。
7、會議記錄很重要，把一些結論和有價值的內容記錄下來，這些是本次會議的重要成 果之一。
8、會議要有結論。我們常在會議上聽到有人說：“大家討論了這么半天，結論呢？”。沒有結論的會議是沒有意義的。
9、會議后別忘發(fā)會議紀要，以及一些 Action，什么人什么時候做什么。
10、會議后的 action 執(zhí)行情況的反饋很重要。反饋是對會議參與者的尊重，同時也告知 了會議的效果。否則會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性 也會降低。很多會議往往都不注意這一點。
11、按時結束的會議會受到所有人的歡迎。
7、版本控制 版本控制也是項目管理者的一個重要工作內容之一，一個項目或產(chǎn)品的完成不可能是一 步到位的，在項目完成的后期可能會有多個不同的版本的發(fā)布（開發(fā)版本，測試版本，發(fā)布 版本等）。需要做好版本的管理和控制。
8、項目總結 在項目完成后，總結整個完成項目的過程和經(jīng)歷，為下一次的項目啟動提供參考經(jīng)驗，完善不足，避免在類似的項目中出現(xiàn)可能存在的相同的錯誤發(fā)生。
第五篇：軟件開發(fā)項目管理應用(4天)
軟件開發(fā)項目管理應用（4天）
一、課程目的為了加強企業(yè)信息科技部門建設，提升信息科技部門人員管理技能，充分掌握并應用項目管理的流程、工具和方法，從而提高IT項目實施的效率和效益。擬開展企業(yè)信息化項目管理應用培訓，經(jīng)培訓使參訓人員能用項目管理方法論指導企業(yè)信息規(guī)劃和IT項目建設。
二、課程收益
熟悉項目管理概念和工具技術的應用
了解項目實施和監(jiān)控過程方法
理解企業(yè)信息科技部門IT項目管理體系，掌握企業(yè)信息中心項目化管理應用。
三、授課方式
課程講解、實戰(zhàn)訓練、案例研討、模板演示、討論引導
四、課程對象
分管領導，部門經(jīng)理、項目經(jīng)理、項目成員、信息中心人員及對項目管理有興趣的員工。
六、課程大綱
破冰
（一）項目管理過程活動梳理
1.1項目與項目管理
1.1.1信息化項目管理應用
1.1.2項目管理過程活動流程介紹
1.1.3美國項目管理學會(PMI)項目管理專業(yè)人員(PMP)考試制度 □ 問題解答
1.2.軟件開發(fā)項目管理過程
1.2.1軟件開發(fā)項目生命周期選擇
1.2.2.1新版項目管理思想生命周期的化繁為簡
1.2.2.2 HP項目生命周期模型介紹與研討
實戰(zhàn)訓練1：確定企業(yè)項目生命周期方法與模型
1.3.軟件開發(fā)項目實施組織環(huán)境和項目管理因素
1.3.1軟件開發(fā)項目組織環(huán)境：環(huán)境—方法—人—工具
1.3.1.1項目組織環(huán)境對項目的影響
1.3.2項目接口與支撐體系
模板演示1：IT項目多功能團隊接口/界面和工作關系管理
1.3.3軟件開發(fā)項目管理狀況分析
1.3.3.1項目目標和過程成功要素
1.3.3.2導致項目失敗的12大因素
（二）軟件項目管理方法技術實操演練
2.1項目啟動
2.1.1成功的軟件開發(fā)項目啟動
2.1.1.1項目分類（IT工程類項目、軟件開發(fā)類項目、系統(tǒng)維護類項目……）
4.1.1.2軟件開發(fā)項目組織類型與項目利害關系者分析管理
4.1.1.3項目角色管理與職責矩陣
2.1.2項目經(jīng)理選擇與項目經(jīng)理的責權利
2.1.2.1項目經(jīng)理應該具備哪些能力標準和素質要求
2.1.2.2沒有合格項目經(jīng)理怎么辦?
演示：技術型項目經(jīng)理如何轉到技術管理型項目經(jīng)理
2.1.3軟件開發(fā)項目經(jīng)理的兩個權利來源
2.2項目規(guī)劃
2.2.1約定開發(fā)過程規(guī)則,是項目管理流程,制度,模板和控制的基礎保障
2.2.2如何定義軟件開發(fā)項目的多目標性
2.2.3從軟件開發(fā)項目需求管理到完成概要設計
2.2.3.1業(yè)務需求如何轉換為技術需求,技術需求如何轉換為產(chǎn)品需求
2.2.3.2需求的接口界面
2.2.3.3如何杜絕需求評審走過場
2.2.3.4項目不斷提出需求變更應該如何應對？
2.2.3.5項目需求變更的應對措施：時段法、版本法、有無法……
2.2.3.6如何與業(yè)務部門達成需求變更流程規(guī)則？
案例研討：中興通訊如何管理定性需求
2.2.4 IT項目規(guī)劃進度規(guī)劃
2.2.4.1軟件開發(fā)活動的逐漸明晰與PERT估算方法應用
2.2.4.2中國移動軟件開發(fā)項目活動工期估算方法介紹
2.2.4.3如何使計劃適應變化？
2.2.4.4可操作性和可控計劃是如何做出來的？
2.2.4.5三級計劃制定的時間點
2.2.4.6開發(fā)計劃制定的步驟和注意事項
2.2.5、IT項目資源規(guī)劃
項目多、時間緊、人員少，項目如何確保滿足業(yè)務要求，過程中又如何實施進度監(jiān)督與控制，資源或需求發(fā)生變化后的進度基準如何確定，對項目進度應如何評價？
2.2.5.1如何調節(jié)資源使用的高峰低谷
2.2.5.2進度壓縮在軟件開發(fā)中的應用
2.2.5.3如何通過績效杠桿調節(jié)軟件架構師、開發(fā)人員和測試人員的協(xié)同工作
2.2.5.3.1軟件開發(fā)項目的考核KPI和考核方法
2.2.5.3.2如何設置開發(fā)項目激勵獎金？
2.2.5.3.3軟件開發(fā)項目經(jīng)理如何評價項目成員績效？
2.2.6 IT項目費用規(guī)劃
2.2.6.1費用估算
2.2.6.1.1費用估算依據(jù)
2.2.6.1.2費用估算方法
2.2.6.1.3準備金分析
2.2.6.1.4實現(xiàn)價值分析
2.2.7 軟件項目質量規(guī)劃
2.2.7.1 IT項目管理與ISO
2.2.7.2 IT項目與CMM
2.2.7.3 IT質量規(guī)劃
2.2.7.4SPPP、SQA、QC和SCM
2.2.7.5質量管理工具(益本比分析、基準對照、實驗設計、因果圖、控制圖、流程圖、直方圖、帕累托圖、趨勢圖、散點圖、統(tǒng)計抽樣、檢查)
2.2.8 制訂項目管理計劃
2.2.8.1項目管理計劃的作用
2.2.8.2項目管理計劃的適應范圍與應用裁剪
2.2.8.3項目管理信息系統(tǒng)、配置管理系統(tǒng)、變更控制系統(tǒng)之關系與作用 模板介紹：項目管理計劃模板介紹
2.3.軟件開發(fā)項目指導、執(zhí)行與控制
2.3.1如何實現(xiàn)軟件開發(fā)項目的過程可控、可視、可度量
2.3.2項目績效狀態(tài)報告
模板演示:IBM軟件開發(fā)項目績效狀態(tài)報告模板
2.3.3軟件開發(fā)項目經(jīng)理如何指導項目成員執(zhí)行項目任務
案例研討:某集團信息中心如何通過建立項目化運作機制,解決項目資源沖突問題
2.3.4如何保證各配合部分提交的工作包是符合質量的?
2.3.5風險應對與監(jiān)控
2.3.5.1風險規(guī)劃,讓項目防患以未然
2.3.5.2誰來識別項目風險?如何識別項目風險?
2.3.5.3如何評估風險給項目帶來的機遇或影響?
2.3.5.4風險評審、風險審計、風險責任
2.3.5.5為什么需要對風險進行集中管理
模板演示:風險管理列表
2.3.6如何規(guī)避同樣的問題重復發(fā)生
模板演示:問題管理流程模板示例介紹
2.4.軟件開發(fā)項目收尾
2.4.1項目驗收
2.4.2項目總結
2.4.3項目后評估
2.4.4如何做好項目移交
2.4.5項目成員解散
模板演示:軟件開發(fā)項目總結報告
2.5.軟件開發(fā)多項目管理
2.5.1多項目管理工作方式
2.5.1.1項目群管理
2.5.1.2項目組管理
2.5.1.3項目總監(jiān)與項目池、資源池
2.5.1.4多項目的多級控制
(三)軟件開發(fā)項目的激勵方法
3.1軟件開發(fā)項目團隊建設與激勵
3.1.1軟件開發(fā)項目經(jīng)理權利類型
3.1.1.1職位權利,強制權利,獎賞權,專家權,個人魅力,權威權利
3.1.2項目經(jīng)理領導與管理方式
3.1.2.1專制型,民主型,協(xié)商專制型,協(xié)調型,引導者
3.1.3軟件項目團隊建設活動
3.1.3.1例行活動、項目階段重大成果……
3.1.3.2軟件開發(fā)團隊激勵:項目管理之星、項目攻關榮譽獎、月度之星、季度明星、BUG克星……
模板演示:軟件開發(fā)團隊建設指導模板
3.1.4軟件開發(fā)項目激勵方法
3.1.4.1需求法,雙因素法,XY方法,期望法,光環(huán)法
3.1.4.2項目激勵方式:榮譽獎、積分卡、發(fā)表揚信、公告、宣傳,獎賞
3.1.5項目團隊績效評估
現(xiàn)場訓練:抱團打天下
(四)軟件開發(fā)項目的有效溝通
4.1項目溝通技巧
4.1.1項目溝通渠道計算
4.1.2項目溝通類型
4.1.3項目溝通模型
4.1.4如何將技術語言轉換成業(yè)務語言進行有效溝通
4.1.5有效的項目溝通影響因素
游戲:項目溝通模擬游戲
4.1.6溝通寶典：項目利害關系者政治關聯(lián)分析法
案例研討:根據(jù)案例資料識別和管理項目利害關系者
4.2常見的沖突及解決技巧
4.2.1沖突來源
4.2.2有效的沖突管理思維
4.2.3項目沖突的五種有效解決方法
4.2.3.1規(guī)避,緩和,折中,正視問題,妥協(xié) 課程總結
培訓聯(lián)系:左老師
電話:021-63233980
手機:***
QQ:2749919646
郵箱:zuozl@tsinghui.com
點擊咨詢 