第一篇：教案1-第01-02講軟件開發項目管理概述

第01章 軟件開發項目管理概述

上課班級：信息系統09級01班、信息系統09級02班

上課目的：通過本章的學習，要求學生了解項目的定義和基本特征，軟件項目的特點，項目管理的重要性，項目管理的發展史,了解項目管理知識體系。熟悉軟件項目管理的研究方法。

上課節次：第01-02講（1-2；3-6）教學目標（重點、難點）： ? 項目與軟件項目

? 項目管理與軟件項目管理（重點）? 項目管理知識體系（PMBOK）? 軟件項目管理中的若干原則（難點）? 軟件項目管理的工具

0引論

軟件項目過程

顧客顧客需求輸入產品輸出實現產品滿意 廣義軟件工程

項目管理軟件開發過程改進 軟件項目的成功和失敗

軟件開發的困惑

? 為什么我們不能開發出高質量的軟件？

? 為什么人類無法定義它、解釋它，深刻地了解它？

? 為什么一些天才的科學家窮其一生的精力也不能把這些迷惑歸納成一種科學工程學科或行業標準？

? 軟件工程方法不堪一擊，人們無法使用它們。

軟件項目失敗原因

? ? ? ? ? ? ? 客戶需求不確定

最終產品的設計和特色只有在過程中才能變得清晰，而不是開始時 很難制定準確的計劃

估計不夠，低估時間和成本 來自營銷、客戶和管理者的壓力 溝通失敗是項目失敗的最大的威脅 軟件過程不可見

軟件開發的探索

? 技術

CASE,UML OO ? 過程控制

ISO9001,ISO9000-3,ISO15504,ISO12207 CMM,TickIT 以上措施并沒有真正解決軟件危機，“質量是制造出來的，不是檢驗出來”，在制造業適用，在軟件行業作用并不大(軟件過程不可見),項目失敗率還是很高。

軟件項目失敗深層次原因

? 對軟件的誤解是問題的根源。

? 現有的方法是由那些有良好愿望但忘記了軟件中的“軟”的那些聰明人所創建的。他們假定開發軟件就象造橋。

? 方法不正確。沒有人打算失敗，具有諷刺意味的是為使失敗最小化而創建的方法是失敗的。

? 開發人員士氣不高，沒有創造性。? 管理人員、開發人員能力不夠。? 只重過程，不重人。? 沒有良好的溝通。

1、項目與軟件項目

哪些活動是項目？

上課；野餐活動；集體婚禮；社區保安；開發微軟的操作系統；每天的衛生保潔；神州飛船計劃。

項目定義

項目是為了創造一個唯一的產品或提供一個唯一的服務而進行的臨時性的努力。

項目的外在特征

? 有明確的目標

? 整體性：項目之間的活動具有相關性 ? 一次性：限定的周期，獨特，不可復制 ? 資源消耗性：資源成本的約束性

? 不確定性

項目的內在屬性

? 唯一性

? 組織的臨時性和開放性 ? 與其他工作的相互依賴性 ? 多目標

項目與日常運作的區別

? 項目是一次性的，日常運作是重復進行的，? 項目是以目標為導向的，日常運作是通過效率和有效性體現的，? 項目是通過項目經理及其團隊工作完成的，而日常運作是職能式的線性管理； ? 項目存在大量的變更管理，而日常運作則基本保持連貫性的。

項目生命期和階段劃分

軟件項目的特殊性

? 邏輯實體(非物理實體）

? 相互作用的系統（一招不慎滿盤皆輸）? 變更（柔性，可走回頭路）

? 漸近明細（從概括、模糊到具體，逐步細化）

軟件項目實例

? 社保系統

? 目標：實現社會保險管理的七大保險功能 ? 時間：1年 ? 資金：2００萬

? 資源：１０人、設備、資料等等

2、項目管理與軟件項目管理

項目管理定義

項目管理是一系列的伴隨著項目的進行而進行的、目的是為了確保項目能夠達到期望的結果的一系列管理行為（活動）。

項目管理5個標準化過程

實現項目目標的制約因素

? ? ? ? ? ? ? ? ? ? 工作范圍 成本

時間(進度計劃)質量（客戶滿意度）組織（項目干系人）

項目管理的5要素

技術（Technical)方法（Methodology）

團隊建設（Team Building）信息（Information）

溝通（Communication：80% jobs)

軟件項目管理定義

軟件項目管理是為了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。

? 軟件項目管理的知識來源

? 項目管理 ? 軟件工程 ? 經驗技巧

3、項目管理知識體系（PMBOK）

關于PMP ? ? ? ? ? PMI在1984年提出項目管理認證計劃(PMP)AT&T,Bell South,Bell Core,Bell Atlantic,Us West, Citibank,IBM,EDS，ABB等參與，是目前全球認可程度最高的項目管理專業認證 是項目管理資格最重要的標志之一 詳細信息參看：www.tmdps.cn

項目管理的九大知識體系

? 范圍管理——確定項目的范圍，? 進度管理——進度是絕大多數項目都非常強調的因素，進度管理的目標是保證項目按時完成。

? 成本管理——目標是保證項目不超出預算

? 人力資源管理——目標在于充分發揮“人”的主動性、創造力和工作效率。它包括組織計劃的編制、人員募集和團隊建設三部分

? 風險管理——風險存在于任何項目中，為了將風險對項目的不利影響降至最低，人們需要對風險加以管理，包括：風險識別、風險分析、風險應對、風險監控幾個過程。? 質量管理——圍繞質量保證和質量控制兩個過程展開的。? 采購管理——對物料的采購進行有效的管理。

? 溝通管理——良好的溝通才能獲取足夠的信息、發現潛在的問題、控制好項目的各個方面。溝通管理就是要在項目干系人之間建立起良好的溝通渠道和溝通平臺，保證他們能夠暢通無阻的交流信息。

? 集成管理——也稱綜合管理，就是為了滿足上述8方面要求進行協調，以達到項目的預期目標。它是一項綜合性、全局性的工作，主要內容是在相互沖突的目標或可選擇的目標中權衡得失、作出選擇。

? 項目管理的9個方面并不是割裂的，而是緊密聯系的，最終統一在項目管理的框架之內。從理論上講，項目管理包括以上9個部分，但實際項目中很難做到面面俱到，通常是根據項目的實際情況針對項目的幾個關鍵因素進行管理。

4、軟件項目管理中的若干原則

項目管理的若干原則

? ? ? ? ? 計劃原則 Brook原則 80-20原則 默認無效原則 等等

5、軟件項目管理的工具

常見項目管理工具

? ? ? ? Microsoft Project CA-SuperProject Project Scheduler 等等

6、案例啟發

你是一個項目的項目經理，計劃了一個項目需要36個月完成，然后提交領導，由于領導的原因導致項目的開始日期推延2個月，但是領導要求你按照計劃完成，作為項目經理，你應該如何做？

第二篇：淺談軟件開發項目管理

淺談軟件開發項目管理

摘要：在軟件項目開發的過程中，軟件項目管理的成功與否是決定一個項目是否能夠順利高效率完成的重要保證。但是我國大部分的軟件企業在進行項目管理時都存在著各種問題，從而使項目不能順利有效地完成。文章探討了在項目管理過程里出現的常見問題，并給出了相應的解決策略。

關鍵詞：軟件項目管理；項目經理；項目計劃

軟件行業在現在的眾多行業里是一個極具挑戰性和創造性的行業，體現了軟件開發者的智慧和汗水，同時軟件開發是一項復雜的系統工程。牽涉到許多方面的因素，在實際工作中，經常會出現各種各樣的問題，甚至會面臨失敗。如何總結、分析失敗的原因。得出有益的教訓，對于項目開發人員來說，是在今后的項目中取得成功的關鍵。

一、軟件開發中實行項目管理的意義

項目管理就是在項目活動中運用一系列的知識、技能、工具和技術，以滿足或超過相關利益者對項目的要求，實際上就是通過項目各方干系人的合作，把各種資源應用于項目，以實現項目的目標，滿足項目干系人的需求，其本質就是對時間、質量和成本的管理。隨著軟件開發的深入、各種技術的不斷創新以及軟件產業的形成，人們越來越意識到軟件過程管理的重要性，管理學的思想逐漸融入軟件開發過程中，項目開發的管理日益受到重視。

二、目前在軟件項目管理中存在的誤區

現在大多數企業都認識到了在項目中進行管理的重要性，但是仍然有許多企業在實施項目管理的過程中存在著這樣那樣的誤區，主要表現在：項目經理不夠專業。在軟件企業中，缺乏專業的項目管理人員來實施項目管理及擔任項目經理，通常被任命的項目經理主要是因為他們能夠在技術上獨當一面，但是他們在管理方面特別是項目管理方面的知識比較缺乏。項目計劃缺乏綱領性。項目經理對總體計劃、階段計劃的作用認識不足，因此制定總體計劃時比較隨意，不少事情沒有仔細考慮：階段計劃因工作忙等理由經常拖延，造成計劃與控制管理脫節，無法進行有效的進度控制管理。缺乏有效的管理意識。部分項目經理不能從總體上把握整個項目，而是埋頭于具體的技術工作，造成項目組成人員之間忙的忙、閑的閑，計劃不周、任務不均、資源浪費。有些項目經理沒有很好的管理方法，不好安排的工作只好自己做，使項目任務無法有效、合理地分配給相關成員，以達到“負載均衡”。缺乏有效的溝通制度和機制。在項目中一些重要信息沒有進行充分和有效的溝通。在制定計劃、意見反饋、情況通報、技術問題或成果等方面與相關人員的溝通不足，造成各做各事、重復勞動，甚至造成不必要的損失：有些人沒有每天定時收郵件的習慣，以至于無法及時接收最新的信息。風險管理意識淡泊。有些項目經理沒有充分意識到風險管理的重要性，對計劃書中風險管理的章節簡單應付了事，隨便列出幾個風險，隨便地寫一些簡單的對策，對于后面的風險防范起不到什么指導作用。項目干系人的不確定性。在范圍識別階段，項目組對客戶的整體組織結構、有關人員及其關系、工作職責等沒有足夠了解以至于無法得到完整需求或最終經權威用戶代表確認的需求：或者是多個用戶代表各說各話、昨是今非，但同時又要求項目盡早交付：項目后期需求變化隨意，造成項目范圍的蔓延，進度的拖延，成本的擴大。缺乏項目團隊的合理分工。項目團隊內部有時由于各階段不同角色或同階段不同角色之間的責任分工不夠清晰而造成工作互相推諉、責任互相推卸的現象；有時各階段不同角色或同階段不同角色之間的責任分工比較清晰，但是各項目成員只顧完成自己那部分任務，不愿意與他人協作。這些現象都將造成項目組內部資源的損耗，從而影響項目進展。

三、解決軟件項目管理中存在的誤區的有效策略

要想解決上面描述的誤區，歸根到底還是要從管理學的角度入手，即在軟件項目的開發過程中加入過程管理的內容，這樣我們可以在軟件開發中對各個過程的質量加以控制，從而達到保證軟件產品質量的目的。為了有效提高管理水平，我們應該努力做到：項目經理接受系統的項目管理知識培訓是非常必要的，有了專業領域的知識與實踐，再加上項目管理知識與實踐和一般管理的知識和經驗的有機結合，必能大大提高項目經理的項目管理水平。計劃的制定需要在一定條件的限制和假設之下采用漸近明細的方式進行不斷完善。提高項目經理的計劃意識，采用項目計劃制定相關知識、技術、工具，加強對開發計劃、階段計劃的有效性進行事前事后的評估。加強項目管理方面的培訓，并通過對考核指標的合理設定和宣傳引導項目經理更好地做好項目管理工作。技術骨干在擔任項目經理之前，最好能經過系統的項目管理知識，特別是其中的人力資源管理、溝通管理的學習，并且在實際工作中不斷提高自己的管理素質，豐富項目管理經驗，提高項目管理意識。制定有效的溝通制度和溝通機制，提高溝通意識：采取多種溝通方式，提高溝通的有效性。通過制度規定對由于未及時收取郵件而造成損失的責任歸屬；對于特別重要的內容要采用多種方式進行有效溝通以確保傳達到位，例如：除發送郵件外還要電話提醒、回執等，重要的內容還要通過舉行各種會議進行傳達。通過學習項目管理知識掌握風險識別、量化、對策研究、反應控制的工具和方法，掌握項目風險管理所必備的知識。通過加強對項目規劃中風險管理計劃的審核提高項目組的風險管理意識。總結本行業項目中常見的風險及其對策作為風險管理計劃中必要的風險內容，并切實評估相應對策的有效性和可行性。項目的目的就是實現項目干系人的需求和愿望。項目干系人管理應當從項目的啟動開始，項目經理及其項目成員就要分清項目干系人包含哪些人和組織，通過溝通協調對他們施加影響，驅動他們對項目的支持，調查并明確他們的需求和愿望，減小其對項目的阻力，以確保項目獲得成功。項目經理應當對項目成員的責任進行合理的分配并清楚地說明，同時應強調不同分工、不同環節的成員應當相互協作，共同完善。

實施有效的項目管理絕非易事，對于軟件企業而言，這不是一個小的改變，而是一種變革，企業需要為此付出艱苦的努力，同時，成熟有效的項目管理無疑將對企業起著至關重要的作用，項目管理的水平將是企業核心競爭力之一。

第三篇：軟件開發項目管理（范文）

管理目標

1、所有關系人清晰明確地了解項目的需求和期望，努力做到滿足項目所有關系人的不同需求；項目關系人包括：項目團隊成員和項目團隊外(內部/外部客戶，內部/外部合作伙伴，經銷商/客戶等)。

2、項目管理三要素平衡（時間/成本/質量），即開發項目按需按時按質的完成。

3、目標：功能滿足需求，設計支持變化，開發快速迭代，成果持續交付。

執行概述

1、建立有效的工作流程保證項目的順利進行，初期使用傳統RUP過程，引入部分敏捷方法，團隊磨合完成后逐步實現敏捷開發全流程管理。

2、明確項目目標，制定具有可行性的項目計劃，有效明確的分解項目需求。

3、跟蹤設計/開發/測試/回歸/發布全流程，推動項目按預定計劃執行。

4、解決項目過程中出現的問題和沖突，一般集中在需求不明/工作量或時長/開發難度/跨部門協調等幾個方面。

5、調動開發團隊的積極性，創造力，推動團隊成員在項目過程中的學習成長。

6、風險識別、風險控制以及風險的預案。

項目管理

1、需求階段

對項目進行技術可行性分析、技術評估、成本評估以及風險評估。與需求提出方的代表進行需求討論，明確項目的目標、價值。確定項目范圍、功能及優先級。

組建項目團隊，特別要搞清楚項目的關鍵人。項目啟動會議，相關的關系人都必須參加。

2、設計階段

根據確認后的軟件需求規格說明書，制定項目進度計劃，工作任務分解(WBS)；資源申請，項目涉及到的開發資源、測試資源、設計資源(包括人員和軟硬件資源)；數據庫設計；系統設計；文檔(包括系統用例、Demo、測試用例等)；評審會議。

設計階段結果交付一般為系統用例/系統原型/系統設計文檔(概要設計和詳細設計)/數據庫設計文檔等。

該階段交付成果需要進行評審。

3、執行階段(開發和測試)準備開發環境、測試環境。跟蹤，推動項目按計劃進行。

項目成員以日報/項目負責人以周報的形式通報各關系人當前項目的進展情況。按里程碑對階段成果進行評估，以確保該階段完成的質量。代碼審核，包括CS審核、SQL審核、WEB審核等。對需求變更進行控制管理。

測試階段BUG響應及改進、收集反饋意見。對項目風險進行管理。

4、發布階段

包括制定項目發布計劃，用戶培訓，發布上線。

5、試運行階段

數據監控(日志、服務器狀態)，根據監控出現的問題，及時進行處理，改進性能問題，特定情況執行補丁升級。

6、收尾階段

產品交付，項目總結會。

常見問題

1、開發時間的估算

制定項目計劃時，需要估算每個任務所需的時間，其中主要是開發任務中模塊的分配和時間估算，在公司現有的技術框架下，開發人員主要的工作是投入在具體的業務邏輯實現上。通常單個模塊開發時間取決于以下因素：

1、負責模塊的業務邏輯的復雜程度。

2、開發人員的技術水平和對項目所在應用的熟悉程度(包括對框架和應用的熟悉程度)。

3、模塊技術實現上是否存在難點，所謂的技術難點定義是：在現有系統中還未實現的、開發人員自身未沒接觸過的技術。對于這樣的難點，開發者沒有相關的代碼可以參考，自己也沒有經驗，所以需要投入學習時間用于研究解決。

模塊分配和開發時間估算的步驟：

1、在劃分好模塊后，首先項目管理人員預先估算各個模塊所需要的開發時間。

2、召集所有開發人員，討論模塊的分配和開發時間估算。將劃分好的模塊，分配給開發人員，如狀況允許可允許開發人員自主選擇以提高開發人員的主動性和參與性。分配模塊的時為確保開發的速度和質量，基本原則如下：

A、類似的模塊由同一人負責開發，比如用戶信息的增刪改應由同一開發者負責。這樣開發者對相關邏輯會比較熟悉，代碼/接口的定義也會相對明確，溝通的成本低，相應可以降低功能實現的缺陷概率。

B、技術難度較大的模塊由技術水平比較高的人負責。C、業務邏輯比較復雜的由對業務邏輯比較了解的人負責。

3、模塊分配完成后，開發人員評估自己負責開發的模塊所需要的時間。在此過程中應

4、對開發人員估算的時間進行確認。在確認過程中作為，項目管理者將預估時間和開與開發者討論每個模塊的技術實現細節，使時間的估算更加準確。發人員估算時間進行比較。那些差異較大的，與人員探討其中的緣由。對于時間周期比較長的任務，將任務拆分為更小的子任務，每個任務的完成時間為8-24工時，消除時間周期較長的任務，避免不確定性影響項目的進度。

2、CodeReview CodeReview是保證項目中代碼質量非常重要的一個環節，在這一環控制不嚴往往是測試后出現大量bug的主因，有時甚至導致返工；關于CodeReview執行，首先應有編碼規范和代碼審查規范。通過這兩個文檔來規范開發人員的代碼實現，代碼編寫者必須要嚴格按照規范來進行；代碼審核者根據這些標準來CodeReview代碼，同時在CodeReview過程中需要不斷完善該文檔。

CodeReview一般可按以下步驟實施：

1、檢查開發者的代碼實現是否遵循了編碼規范。

2、從代碼的易維護性、可擴展性角度考察代碼的質量，提出修改建議。

3、代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UseCase依次講解自己負責的代碼和相關邏輯，代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發現隱藏的bug，對這些bug記錄在案。

4、代碼講解完畢后，代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要檢查Bug。同時全面兼顧，確保代碼整體上結構優良；審核完畢后，代碼審核者編寫“代碼審核報告”記錄發現的問題及修改建議，提交給相關人員。

5、代碼編寫者根據“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。

6、代碼編寫者bugfixed完畢之后給出反饋。

7、代碼審核者把CodeReview中發現的有價值的問題更新到“代碼審核規范”的文檔中，對于特別值得提醒的問題可群發email給所有技術人員。

3、需求變更管理

需求變更管理也是項目管理中最重要的一個環節，對需求變更管理的有效性將直接影響對待需求變更的正確態度：

1、需求變更是不可避免的。

2、需求變更要必須被管理。

3、積極發現引起變更的因素，促使變更盡可能早的出現，減低變更帶來的風險。需求變更管理的目標：

1、相關的干系人必須清楚地了解發生的變更。

2、變更處于有效的管理中。

3、盡量降低變更帶來的風險。

通過制定需求變更的流程，確保項目中的需求變更有效地進行，實現上述的目標。需求變更流程：

1、確定需求的基準線。將以UserCase作為需求基準線，在UserCase確認之后的任項目的成功與否。何需求改變，都需要走需求變更流程。

2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產品經理、市場人員、開發人員、測試人員等。

3、項目管理者評估該需求變更。針對接收到的需求變更的要求，召集相關人員討論該需求變更的合理性、可行性，實施的代價以及對項目的影響。項目管理者對項目的成功與否負有主要的責任。需求變更的決策應由項目管理者做出。

4、需求變更確認后，由專人將生成需求變更單記錄下來，通知給項目中所有關系人。

5、確定變更的負責人。承擔需求變更的具體工作，比如基線控制，對需求變更的記錄，并通知相關人員。

6、相關人員接收到確認的需求變更后，需求分析人員修改需求說明書和UserCase的相關內容。測試人員修改測試用例的相關內容。開發人員修改代碼中的相關部分。

7、按照變更后的計劃實施項目，并進行檢查，跟蹤，對變更后的實施反饋和可能出現的問題及時溝通和處理。

8、需求凍結。項目越到后期，需求變更對項目的影響就越大，所以在一定時候要進入需求凍結階段，不再接收新需求或需求的變更。

4、風險管理

影響項目成敗的因素涉及方方面面，并且風險伴隨著項目的始終，是客觀存在的，風險引起的負面后果集中體現在進度延后、成本超支、質量不達標等方面，常見風險如下：

1、目標以及需求不明確

為了市場競爭或內部管理決策的需要，業務部門提出的需求往往要求的時間比較緊迫，需求的提出大多停留在幾張紙或口頭的傳達上，沒有正式的業務需求文檔，在沒有明確的需求范圍的情況下，有時為了迎合業務部門的口味匆匆開工，過程中用戶不斷地提出新的想法，技術人員開始疲于奔命和應付，很難保證項目的進度和質量，也難以取得業務部門的認可。

在項目的前期一定要采取相應的手段或措施，與業務部門共同明確項目目標、需求范圍，充分考慮現有的時間和資源約束，將需求排定優先級，對于關鍵的需求優先實現，其他輔助性的根據過程中的具體情況進行滾動式計劃，并取得業務部門的書面確認。在此過程中要注重挖掘用戶的隱性需求，可以通過引導、系統原型等手段讓用戶在前期充分暴露自己的想法和需求。

2、項目目標擴大以及需求變更

在有了明確的目標和需求范圍的情況下，需求的變更還是不可避免的，業務部門在看到具體系統的真實雛形之后，源源不斷地要求、新想法隨之產生，如果不對此加以控制，新的需求的加入通常會影響已實現的需求，并且對項目進度和成本產生很大的影響。項目管理者針對這種情況一定要采取嚴格的變更控制流程，不能礙于面子，否則最終的結果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相關團隊成員進行分析及評估，作為是否實施的依據，變更控制負責人根據分析結果判斷是否批準，如果批準，那項目組可以安排實施，否則，正式拒絕用戶的請求。

前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產品經理、相關職能主管、客戶)，所有的需求要經過他們的認可?？蛻粼陧椖窟^程中的全程參與有助于降低此類風險。需求討論、需求確認、UserCase確認、測試階段的客戶驗收等環節，都要要求客戶參與。在發生需求變更時，嚴格按照需求變更流程執行。在分析設計階段的中的確認和評審也是降低此類風險的重要手段。

3、代碼質量風險

質量風險主要指開發代碼的質量。在制定項目計劃時，對開發時間的評估要盡可能的合適。合理的開發時間對開發質量的影響很大。開發人員為了趕進度在比較緊張的時間需要完成指定的任務，可能就存在很大的開發質量問題。在編碼前，開發人員要對框架熟練掌握；一份好的系統設計文檔對指導開發非常重要。

往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是100%完成，但一到最后系統交互測試或集成的時候就會發現一大堆問題。這需要在項目實施過程中采取有效的措施來規避風險，通常的做法有同行評審，比如概要設計完成之后，邀請其他項目組的技術專家進行技術評審以發現架構設計問題；管理評審，通過組織級的質量審計看產品以及實施過程是否滿足質量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規范或性能要求的代碼，走查通常能夠發現50%-70%的錯誤；每日構建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發現相應的錯誤，日構建一般在項目的中后期開始，每天自動從版本服務器上獲取源代碼進行自動編譯和測試。

4、人員技能和資源的不足

項目實施過程中由于人員技能欠缺造成的進度延后和軟件質量問題并不少見，一個熟練的技術人員完成同樣一個任務需要3天，但一個新手可能就需要7-10天。項目管理者應該在前期就分析清楚項目所要采用的技術以及相應的人員技能要求，針對不同的角色，及時采取相應的技能培訓，以保證項目的順利實施。開發過程中遇到技術難題，導致開發時間延遲或者需求不得不發生變更。在項目開始前的技術評估階段，明確技術難點，提前安排人員進行攻克。如果在可預期的時間內無法解決，如果可以，將向需求提出方要求變更需求或尋找可替代方案。這樣的風險應該在項目的前期階段就應該解決在萌芽狀態來避免這樣的風險在后期或中期出現。

5、缺乏良好的團隊協作

軟件項目實施屬于知識型，要發揮團隊成員的創造力，不同于制造業計件生產，各模塊最終要集成在一起形成一個有機的整體，這就需要各小組之間的密切配合，界定清楚工作界面及接口關系，并在實施過程中持續地溝通交流和共享，首先團隊要融為一體，產出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協作好壞也將是個潛在的風險問題，在項目啟動和團隊組建的時候就應該加以規避這樣的風險出現。

6、項目會議

組織會議是項目執行過程中一項非常重要的工作任務，項目過程中很多重要的決定都是在會議中做出的，不成功的會議會對項目本身造成了不好的影響。

不成功的會議通常表現為如下形式：

1、會議氛圍不好，參與者發言不踴躍；

2、會議討論常常偏離主題；

3、會議沒有取得預期的結果；

4、會議時間常常一拖再拖。

這些不成功的會議最終的結果就是：既浪費了大家的寶貴時間又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應該注意的問題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必須要清楚：

1、會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會議才有可能取得成功，這是會議成功的充分條件。

2、會議的組織者和參與者的想法通常是不一致的，有時候甚至會大相徑庭。所以不要希望會議的參與者和你一樣，對會議有著如此的期待，對大多數參與者而言，在會議中他只是一個發表想法的人，他不用對會議的成功承擔責任。

3、以下十一條最佳實踐是形式上的約定，具體的實施可以根據實際情況來做。組織會議的十一條最佳實踐：

1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。

2、提前發出會議議程，以便會議參與者知道他們來做什么。

3、請對人很重要，不要把非必要的人召來開會，當然也不要漏掉那些關鍵人物。在確保必要人物都在的情況下一次會議參與者越少效果越好。

4、提前預約參與者的時間，以確保他們能按時到場。

5、會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在開場時說： A、再一次強調會議的目標，我們來做什么。

B、強調會議的主題與基調。比如：本次會議是一個需求確認會，而非需求討論會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論如何做上面。

C、說明一下會議的規則。如要發言，請舉手；不要有小圈子討論；不要打斷別人的講話，等別人說完你再說等等。

6、會議過程中時刻注意引導和控制會議，以確保會議按照目標進行。一次會議的氛圍是否良好，討論是否充分，好的引導至關重要。比如多提一些開放式的問題。

7、會議記錄很重要，把一些結論和有價值的內容記錄下來，這些是本次會議的重要成果之一。

8、會議要有結論。我們常在會議上聽到有人說：“大家討論了這么半天，結論呢？”。沒有結論的會議是沒有意義的。

9、會議后別忘發會議紀要，以及一些Action，什么人什么時候做什么。

10、會議后的action執行情況的反饋很重要。反饋是對會議參與者的尊重，同時也告知了會議的效果。否則會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性也會降低。很多會議往往都不注意這一點。

11、按時結束的會議會受到所有人的歡迎。

第四篇：軟件開發項目管理實施方案.

項目管理實施方案

作為一個項目管理者,如何要成功的做好項目管理;首先必須先要明白的是在特定的領域中賦予這個角色所要實現的目標、承擔的職責、以及項目管理者的具體工作內容是什么? 從我個人的淺見和角度以及我們所從事的IT領域來分析回答以上三個問題。第一:目標

作為一個項目的管理者,必須要明確的知道自己的工作目標;我個人認為項目管理者的目標無非就是以下兩點:

1、就是清晰明確地了解項目利害關系者的需求和期望,努力做到滿足項目利害關系者的不同需求;項目利害關系者包括:項目團隊成員和項目團隊外成員(比如各部門的部門負責人和市場人員,客戶等。

2、就是保證開發項目按需按時保質的完成。第二:職責

作為項目的管理者,首先要端正態度,要明確知道自己的工作職責,認識到這份工作職責的本質。項目管理者不是來管人的,而是來支持人的,是來協調資源的,是來營造一個適合團隊成員比較認同的工作環境和氛圍的,是來為一個共同的目標和大家一起戰斗共同成長的?？梢源蟾鸥爬ǔ梢韵聨c:

1、建立有效的工作流程保證項目的順利進行。

2、制定詳細周密的項目計劃。

3、跟蹤,推動項目按計劃進行。

4、積極解決項目過程中出現的問題和沖突。

5、調動開發團隊的積極性,創造力,推動團隊成員在項目過程中不斷成長。

6、項目風險識別、風險評估、風險解決和風險管理策略以及做好突發風險的應急預案。

7、實現目標

第三:項目管理者的具體工作內容

最后一個是項目管理者的具體工作內容,作為項目管理者必須清晰的知道自己的工作范圍和所要做的工作內容以及工作重心,分為以下六點:

1、項目前期階段

對項目進行技術可行性分析、技術評估、成本評估以及風險評估。與需求提出方的代表進行需求討論,明確項目的目標、價值;確定項目范圍、功能及優先級。組建項目團隊,特別要搞清楚項目的key person(對產品有決定權的人。項目啟動會議,相關的

利害關系人員都必須參加。

該階段完成后的成果:確認后的最終軟件需求規格說明書文檔。

2、分析設計階段

根據確認后的軟件需求規格說明書,制定項目進度計劃,工作任務分解(WBS;資源申請,項目涉及到的開發資源、測試資源、設計資源(包括人員和軟硬件資源;數據庫設計;系統設計;文檔(包括Use Case、Demo系統原型、Test Case等;評審會議。

該階段完成后的成果: A、User Case(系統用例;B、DEMO(系統原型;

C、系統設計文檔(概要設計和詳細設計;D、數據庫設計文檔。

最后對完成的成果,包括User Case和設計文檔等進行評審。

3、執行階段(開發和測試

準備開發環境、測試環境;跟蹤,推動項目按計劃進行;以周報的形式通報項目的進展情況。對項目的階段成果進行評估,以確保該階段完成的質量,包括代碼審核、SQL 審核等。對需求變更進行控制管理;對項目風險進行管理;測試階段BUG FIXED及改進、收集反饋意見。

4、發布階段

包括制定項目發布計劃,用戶培訓,發布上線。

5、上線后監控

數據監控(日志、服務器狀態,根據監控出現的問題,及時進行BUG FIXED及改進或做補丁升級。

6、結束階段

產品交付,項目總結會。

第四:基于以上三個問題所做的應對細則

要做好項目管理,并能確實解決好以上三個問題,實現目標、履行職責、完成工作中的具體內容,從我個人這幾年的工作經驗和面臨的一些問題,還有所積累的一些項目管理中的

一些知識以及自己的觀察和思考的角度看,應該要努力做好以下這幾個方面的具體工作:

1、項目開發時間的估算

制定項目進度時間表的時候,需要估算每個任務所需的時間,其中開發任務中模塊的分配和時間估算是其中最主要的部分;在分配模塊和估算開發時間時需要遵循的原則和目標:

1、保證項目整體的進度。

2、有助于確保開發編碼的質量。

3、有助于提高開發編碼的速度。

在公司現有的技術框架下,開發人員主要的工作是投入在具體的商業邏輯上。通常每個模塊所需的開發時間取決于以下三個因素:

1、所負責模塊的商業邏輯的復雜程度。

2、開發人員的技術水平和對項目所在應用的熟悉程度(包括對框架和應用的熟悉程度。

3、該模塊技術實現上是否有技術難點;這里所謂的技術難點定義是:在現有系統中還未實現的、開發人員自身也未沒接觸過的技術。對于這樣的難點,開發者沒有相關的代碼可以參考,自己也沒有經驗,所以需要投入一些時間研究解決。

模塊分配和開發時間估算的步驟:

1、在劃分好模塊后,首先自己先估算一下每個模塊所需要的開發時間。

2、然后召集所有開發人員,討論模塊的分配和開發時間估算。將劃分好的模塊,讓開發人員從中挑選他們感興趣的模塊。這樣做可以提高開發人員的主動性和參與性。在分配模塊的時候還需從以下幾方面考慮,以確保開發的速度和質量: A、相同類似的模塊由同一人負責開發,比如用戶管理的增刪改由同一開發者負責。

這樣做的好處就是開發者對相關邏輯會更加熟悉,同時接口的定義也會比較明確,溝通的成本比較低,同時功能實現的缺陷也相應的會降低。

B、技術難度比較大的模塊由技術水平比較高的人負責。C、業務邏輯比較復雜的由對這塊邏輯比較了解的人負責。

3、模塊分配完后,開發人員評估自己負責開發的模塊所需要的時間。在此過程中最好做到要和開發者比較詳細的討論每個模塊的技術實現,以便使時間的估算更加準確。

4、對開發人員估算的時間進行確認。在確認過程中作為項目管理者應參考以上提到的三個因素,同時將自己估算的時間和開發人員估算的時間進行比較。這其中的差異當然會存在的。對于那些差異比較大的,將與技術人員探討其中的緣由。對于時間周期比較長的任務,盡量將任務通過再細分的手段細化任務,爭取每個任務的最長時間不超過3天;時間周期越長的任務,不確定性越高,風險也越高,越有可能成為項目的瓶頸,影響項目的進度。

2、Code Review Code Review是保證項目中代碼質量非常重要的一個環節,在這一環中我們公司做的非常欠缺,把關不嚴格;這是導致每次測試后出現大量bug的主要原因,這一環需要納入績效考核中,實行責任追究制,實施重點監控。出現這樣的薄弱環節,造成這樣的原因,我想也是有很多因素造成的;比如開發人員對需求不是很明確,以自己比較主觀的因素去完成任務的;還有對整個系統業務邏輯沒有正確的清晰的認識的原因,以及對項目組成員培訓不到位的原因等眾多因素糾集在一起才產生的。

如何做好這方面的工作?首先編碼要有“編碼規范”文檔,Code Review要有“代碼審

核規范”文檔:記錄代碼實現應該遵循的標準。通過這兩個文檔來規范開發人員的代碼實現,代碼編寫者必須要嚴格按照規范來進行;代碼審核者根據這些標準來Code Review代碼,同時在Code Review過程中不斷完善該文檔。

在做好這些前期工作的前提下,分以下幾個步驟來實施:

1、檢查開發者的代碼實現是否遵循了編碼規范。

2、從代碼的易維護性、可擴展性角度考察代碼的質量,提出修改建議。

3、代碼編寫者和代碼審核者坐在一起,由代碼編寫者按照Use Case依次講解自己負責 的代碼和相關邏輯,從Web層-到Manage層再到Dao層;

4、代碼審核者在此過程中可以隨時提出自己的疑問,同時積極發現隱藏的bug;對這

些bug記錄在案。

5、代碼講解完畢后,代碼審核者給自己安排幾個小時再對代碼審核一遍。代碼需要一

行一行靜下心來看。同時代碼又要全面的看,以確保代碼整體上設計優良。

6、代碼審核者根據審核的結果編寫“代碼審核報告”,“審核報告”中記錄發現的問題

及修改建議,然后把“審核報告”發送給相關人員。

7、代碼編寫者根據“代碼審核報告”給出的修改意見,修改好代碼,有不清楚的地方

可積極向代碼審核者提出。

8、代碼編寫者bug fixed完畢之后給出反饋。

9、代碼審核者把Code Review中發現的有價值的問題更新到“代碼審核規范”的文檔中, 對于特別值得提醒的問題可群發email給所有技術人員。如果通過以上步驟,還因為是代碼編寫者的原因而出現嚴重的缺陷問題,將通過績效考核來加深代碼編寫者的印象,并在周報會議上做通報批評。

3、需求變更管理

需求變更管理也是項目管理中最重要的一個環節,對需求變更管理的有效性將直接影響項目的成功與否。

對待需求變更的態度:

1、需求變更是不可避免的。

2、需求變更要必須被管理。

3、積極發現引起變更的因素,促使變更盡可能早的出現,減低變更帶來的風險。需求變更管理的目標:

1、相關的干系人必須清楚地了解發生的變更。

2、變更處于有效的管理中。

3、盡量降低變更帶來的風險。

通過制定需求變更的流程,確保項目中的需求變更有效地進行,實現上述的目標。需求變更流程:

1、確定需求的基準線。將以User Case作為需求基準線,在User Case確認之后的任何需求改變,都需要走需求變更流程,這一環節我們基本沒有,期間有時候使的工

作很混亂,也就是因為沒有一個規范的變更流程而造成的;如果建立了這么一個流程規范和機制,需求變更沒有走這個流程的將不被認可。

2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產品經理、市場人員、開發人員、測試人員等。

3、項目管理者評估該需求變更。針對接收到的需求變更的要求,召集相關人員討論該需求變更的合理性、可行性,實施的代價以及對項目的影響。包括可能影響的項目范圍,進

度,費用,質量等計劃。項目管理者作為項目的負責人,對項目的成功與否負有主要的責任。所以需求變更的決策者應該由項目管理者承擔。

4、需求變更確認后由專人將需求變更記錄下來,通知給項目中所有成員。其中以下人員對需求的變更是緊密相關的,他們必須知曉并認可此需求變更。包括(客戶方,需求分析人員,測試人員,相關開發人員。需求變更記錄格式如下: 序號變更提出時間變更描述變更類型(是 對原有需求 的修改還是 新增需求 原因變更提出 者

開發人員對進度的 影響(工 作量 2

5、確定變更的負責人。承擔需求變更的具體工作,比如基線控制,對需求變更的記錄,并通知相關人員。

6、相關人員接收到確認的需求變更后,做以下事情。需求分析人員修改需求說明書和User Case的相關內容。測試人員修改測試用例的相關內容。開發人員修改代碼中的相關部分。

7、按照變更后的計劃實施項目,并進行檢查,跟蹤,對變更后的實施反饋和可能出現的問題及時溝通和處理。

8、需求凍結。項目越到后期,需求變更對項目的影響就越大,所以在一定時候要進入需求凍結階段,不再接收新需求或需求的變更。

4、風險管理

風險管理是項目管理者最重要的工作之一。風險管理是一個持續的過程,貫穿于整個項目過程中,風險管理包括風險識別、風險評估、風險解決以及風險管理策略。

在項目的實施過程中需要不斷地識別和應對風險,并加以有效的控制,風險管理的好與壞直接影響項目的實施效果,從某種意義上講,項目實施對于項目管理者就是識別、分析、應對、控制風險的過程,使項目的約束性目標和質量目標朝有利的方向發展。

項目不同于日常任務,它有明確的起止時間和目標,要在明確的范圍、時間和成本約束下,達到相應的質量標準,并取得用戶的滿意。影響項目成敗的因素涉及方方面面,并且風險伴隨著項目的始終,是客觀存在的,作為一個項目管理者,應該具備良好的風險控制意識,善于識別風險并分析風險的影響,從中發現影響目標的風險點,并施

加影響或采取應對措施,把風險的負面影響降到最低,并且風險控制應該貫穿項目始終。

風險引起的負面后果集中體現在進度延后、成本超支、質量不達標等方面,導致這些問題的因素主要包括目標以及需求不明確、范圍蔓延以及需求變更、代碼質量或返工風險、人員技能和資源的不足、缺乏良好的團隊協作等。下面將詳細描述一下這些問題以及出現這些問題時的應對方案:

1、目標以及需求不明確

為了市場競爭或內部管理決策的需要,業務部門提出的需求往往要求的時間比較緊迫,需求的提出大多停留在幾張紙或口頭的傳達上,沒有形成正式的業務需求文檔,在沒有明確的需求范圍的情況下,有時為了迎合業務部門的口味匆匆開工,過程中用戶不斷地提出新的想法,技術人員開始疲于奔命和應付,很難保證項目的進度和質量,也難以取得業務部門的認可。所以,在項目的前期一定要采取相應的手段或措施,與業務部門共同明確項目目標、需求范圍,充分考慮現有的時間和資源約束,將需求排定優先級, 對于關鍵的需求優先實現，其他輔助性的根據過程中的具體情況進行滾動式計劃，并取 得業務部門的書面確認。在此過程中要注重挖掘用戶的隱性需求，可以通過引導、系統 原型等手段讓用戶在前期充分暴露自己的想法和需求。

2、范圍蔓延以及需求變更 在有了明確的目標和需求范圍的情況下，需求的變更還是不可避免的，業務部門在 看到具體系統的真實雛形之后，源源不斷地要求、新想法隨之產生，如果不對此加以控 制，新的需求的加入通常會影響已實現的需求，并且對項目進度和成本產生很大的影響。項目管理者針對這種情況一定要采取嚴格的變更控制流程，不能礙于面子，否則最終的 結果往往是出力不討好。針對用戶提出的新需求，按照正式流程提出變更申請，組織相 關團隊成員進行分析及評估，作為是否實施的依據，變更控制負責人根據分析結果判斷 是否批準，如果批準，那項目組可以安排實施，否則，正式拒絕用戶的請求，當然實際 情況下可以采取一些軟措施緩解矛盾。需求變更風險：需求已經打上了基線，但此后仍然有變更

發生，對項目造成影響。如何減少此類風險的發生？ 前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。找出項目中需求的決策者(通常會是產品經理、相關職能主管、客戶，所有的需求要經 過他們的認可?？蛻粼陧椖窟^程中的全程參與有助于降低此類風險。需求討論、需求確 認、User Case 確認、測試階段的客戶驗收等環節，都要要求客戶參與。在發生需求變 更時，嚴格按照需求變更流程執行。在分析設計階段的中的確認和評審也是降低此類風 險的重要手段。

3、代碼質量或返工風險 質量風險主要指開發代碼的質量。如何提高開發人員開發的質量？在制定項目計劃 時，對開發時間的評估要盡可能的合適。合理的開發時間對開發質量的影響也很大。有 時開發人員為了趕進度在比較緊張的時間需要完成指定的任務，可能就存在很大的開發 質量問題。開發要有一套嚴格可行的代碼規范，編碼時嚴格遵守，到現在為止，我們這 個方面做的不是很規范，做的也很不足，大家編寫的代碼隨意性比較大，代碼編寫者的 主觀意識性比較強。要建立一套大家認可并且規范可行的編碼規范和考核規范，code review 時嚴格考核。在編碼前，開發人員要對框架熟練掌握；一份好的系統設計文檔對 指導開發非常重要。返工是項目組最不愿意看到的，既浪費人力、物力和財力，又影響團隊積極性。需 求不明確或范圍沒有有效控制都可能造成返工，另外造成返工的原因是質量沒有達到用 戶要求。往往有這樣一種情況，每個團隊成員按照項目計劃報告進度都是 100%完成，但一到最后系統交互測試或集成的時候就會發現一大堆問題，不得不花費很大精力回頭 排查、修改程序，造成這種情況的主要原因是過程中質量保證沒有做到位，把大部分問 題留在了后面。這就需要在項目實施過程中采取有效的措施來規避返工的風險，通常的 做法有同行評審，比如概要設計完成之后，邀請其他項目組的技術專家進行技術評審以 發現架構設計問題； 管理評審，通過組織級的質量審計看產品以及實施過程是否滿足質 量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規范或性能要 求的代碼，走查通常能夠發現 50%-70%的錯誤；每日構建，這是一種非常有效的方法，可以避免把各部分的集成問題拖到最后，并且能夠及時發現相應的錯誤，日構建一般在 項目的中后期開始，每天自動從版本服務器上獲取源代碼進行自動編譯和測試。

4、人員技能和資源的不足 項目實施過程中由于人員技能欠缺造成的進

度延后和軟件質量問題并不少見，一個 熟練的技術人員完成同樣一個任務需要 3 天，但一個生手可能就需要 7-10 天。項目管

理者應該在前期就分析清楚項目所要采用的技術以及相應的人員技能要求，針對不同的 角色，及時采取相應的技能培訓，以保證項目的順利實施。如果對于項目中某些部分專 業性特別強或新技術，短期內又不能快速建立技能的情況，可以考慮將該塊任務外包，借鑒合作商的力量降低實施風險，當然要進行外購人力成本與自建人力成本的效益分 析。開發過程中遇到技術難題，導致開發時間延遲或者需求不得不發生變更。如何減少 此類風險的發生？在項目開始前的技術評估階段，明確技術難點，提前安排人員進行攻 克。如果在可預期的時間內無法解決，如果可以，將向需求提出方要求變更需求或尋找 可替代方案。這樣的風險應該在項目的前期階段就應該解決在萌芽狀態來避免這樣的風 險在后期或中期出現。項目所需人力資源無法按時到位，導致資源風險。如何減少此類風險的發生？這個 就需要在項目計劃制定的時候提前申請確認資源，并在項目過程中不斷溝通協調。

5、缺乏良好的團隊協作 軟件項目實施屬于知識型，要發揮團隊成員的創造力，不同于制造業計件生產，各 模塊最終要集成在一起形成一個有機的整體，這就需要各小組之間的密切配合，界定清 楚工作界面及接口關系，并在實施過程中持續地溝通交流和共享，首先團隊要融為一體，產出的軟件才能融為一體。這是一個團隊的軟實力，團隊之間的協作好壞也將是個潛在 的風險問題，在項目啟動和團隊組建的時候就應該加以規避這樣的風險出現。項目風險管理的要點：

1、上述我們所說的風險管理都是指可以預期將要發生的風險，那些不可預期將要發生 的風險不屬于風險管理的范疇。這也將是考驗一個項目管理者的經驗和知識對能否 管理好風險至關重要的內容。

2、對不可預期的風險，項目管理者要有潛在的風險意識評估，做好一些可操作性的預 案準備。

3、詳細明確的項目計劃、以及項目執行過程中每個要點的質量保證是降低項目風險的 必要條件。

4、風險報告是項目團隊以及領導了解項目風險的一個有效手段。風險報告的格式： 序號 風險簡介 對項目的影響 解決方案或對策

5、團隊管理 團隊就是一組個體為實現共同的目標而相互依賴、一起工作的共同體。團隊工作顧名思 義就是團隊成員為實現這個共同的目標而付出的共同努力，項目團隊的工作是否有效直接關 系到

項目的成敗。團隊管理是個漸進的過程。世界上只有完美的團隊，沒有完美的個人。好的高效的團隊 不是管理出來的，而是營造出來的。團隊成員需要有大家可認同的團隊文化，這需要大家共 同的努力。

1、營造良好的工作環境和氛圍。

2、建設優秀或鮮明的團隊文化。

3、保持高效的溝通。

6、項目會議 組織會議是項目管理者日常工作中一項非常重要的工作任務，項目過程中很多重要的決 定都是在會議中做出的，也有很多由于不成功的會議而對項目本身造成了不好的影響。首先看看不成功的會議常常表現為哪些形式：

1、會議氛圍不好，參與者發言不踴躍；

2、會議討論常常偏離主題；

3、會議沒有取得預期的結果；

4、會議時間常常一拖再拖。這些不成功的會議最終的結果就是：既浪費了大家的寶貴時間又沒有達到會議的目的，很多人都對這樣的會議都有抵觸情緒，對此也是深惡痛絕。以下是組織會議時應該注意的問 題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必須要清楚：

1、會議是否會取得成功很大程度上取決于會議的組織者。只有組織得有力，會議才有 可能取得成功，這是會議成功的充分條件。

2、會議的組織者和參與者的想法通常是不一致的，有時候甚至會大相徑庭。所以不要 希望會議的參與者和你一樣，對會議有著如此的期待，對大多數參與者而言，在會議中他只 是一個發表想法的人，他不用對會議的成功承擔責任。

3、以下十一條最佳實踐是形式上的約定，具體的實施可以根據實際情況來做。組織會議的十一條最佳實踐：

1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。

2、提前發出會議議程，以便會議參與者知道他們來做什么。

3、請對人很重要，不要把非必要的人召來開會，當然也不要漏掉那些關鍵人物。在確 保必要人物都在的情況下一次會議參與者越少效果越好。

4、提前預約參與者的時間，以確保他們能按時到場。

5、會議的開場很重要。會議組織者要在開始前做好幾件事情。通常我建議有幾點要在 開場時說： A、再一次強調會議的目標，我們來做什么。B、強調會議的主題與基調。比如：本次會議是一個需求確認會，而非需求討論會，主要是討論做還是不做以及告知大家我們要做什么，而不要把太多的精力放在討論 如何做上面。C、說明一下會議的規則。如要發言，請舉手；不要有小圈子討論；不要打斷別人 的講 話，等別人說完你再說等等。

6、會議過程中時刻注意引導和控制會議，以確保會議按照目

標進行。一次會議的氛圍 是否良好，討論是否充分，好的引導至關重要。比如多提一些開放式的問題。

7、會議記錄很重要，把一些結論和有價值的內容記錄下來，這些是本次會議的重要成 果之一。

8、會議要有結論。我們常在會議上聽到有人說：“大家討論了這么半天，結論呢？”。沒有結論的會議是沒有意義的。

9、會議后別忘發會議紀要，以及一些 Action，什么人什么時候做什么。

10、會議后的 action 執行情況的反饋很重要。反饋是對會議參與者的尊重，同時也告知 了會議的效果。否則會讓大家感覺到這是一個可無可無的會議，大家以后參與的積極性 也會降低。很多會議往往都不注意這一點。

11、按時結束的會議會受到所有人的歡迎。

7、版本控制 版本控制也是項目管理者的一個重要工作內容之一，一個項目或產品的完成不可能是一 步到位的，在項目完成的后期可能會有多個不同的版本的發布（開發版本，測試版本，發布 版本等）。需要做好版本的管理和控制。

8、項目總結 在項目完成后，總結整個完成項目的過程和經歷，為下一次的項目啟動提供參考經驗，完善不足，避免在類似的項目中出現可能存在的相同的錯誤發生。

第五篇：項目管理崗位職責概述

項目管理崗位職責概述

根據集團發展戰略，擬定集團中遠期研發計劃，把握研發技術方向;

知道并監督研發系統執行集團發展戰略和研發計劃;

控制產品開發進度，調整計劃;

組建優秀的研發團隊，審核及培訓考核有關技術人員;

負責公司新技術框架的選型與搭建;

進行各種提升研發人員的整體研發能力的培訓;

指導研發技術團隊并參與完成新車型、新產品的需求分析和概要設計，組織并參與技術公關。

項目管理崗位職責(二)

(1)負責制定項目管理(立項、計劃、方案、進度管控、交付等)，推動項目運作的計劃性和規范性;

(2)組織項目例會，發布項目周報、月報，督促項目組按計劃完成相關任務;

(3)項目質量管理，評審計劃制定、核銷與度量，任何不符合流程的工作的即時提醒;

(4)跨部門協調工作，負責召集影響產品開發的重點問題的跨部門協調會議;

(5)制定月度資源計劃，協調研發公用資源，促使項目按優先序得到必要的資源;

(6)流程實踐落地和流程優化工作;

(7)負責安排開發階段客戶考察與接待工作;

(8)領導臨時交辦工作。

項目管理崗位職責(三)

1.依據整車開發指示及變速器開發日程，編制項目一級、二級計劃，并協助各部門分解三級計劃;

2.依據項目開發指令，組織各部門對QCT指標進行分解，并在項目執行過程中實施數據統計和監控;

___對于產品開發工作，參與設計及變更評審、制造工藝評審、質量門評審，促進產品不斷優化;

___組織識別項目各階段過程風險，制定項目風險管控計劃，降低項目過程風險;

5.開發項目管理控制程序，組織各部門對項目問題進行研討，制定解決方案，推進項目進程;

6.依據項目開展情況，整合并按需調配項目資源，確保重點工作、關鍵節點按時保質保量完成;

7.依據VA/VE提案，組織實施減重降成本方案，提高產品的適用性與經濟性，嚴格按目標把控成本;

8.確認各階段輸出物，組織項目試制、試驗、試生產、量產評審，確保順利進入SOP并圓滿完成移行;

9.依據項目管理規定，對項目各階段進行總結，編制總結報告，積累開發經驗并指導開展后續項目;

10.依據項目階段進展，匯總各階段項目信息，定期組織對策會、階段會，向高層匯報項目進展及動態;

___對于后市場問題，組織并參與問題整改及效果檢驗，確保輸出的產品滿足顧客的要求。

項目管理崗位職責(四)

1、制定研發項目總進度計劃并進行跟蹤;

2、負責項目各階段工作的推進和問題的處理;

3、完成各階段工作的推進和問題的處理;

4、負責整個研發項目過程的協調與管理;

項目管理崗位職責(五)

1.負責客戶新產品、新項目導入;

2.提出項目計劃，跟進項目進度;

___處理項目執行過程中各環節出現問題的處理和協調，確保完成項目的交付;

4.定期拜訪客戶，建立并維護好客戶關系，滿足客戶要求，提高銷售額。