❶ 論述軟體項目管理過程中如何開展好配置管理工作
1、配置管理員水平很重要。
2、領導要很重視（比如告訴他代碼需要控制不同的許可權，集中保存防止出現各種意外比如離職泄露啊，電腦壞了啊等等，與開發過程相關的就不用說了，他不關心的）。
3、項目經理要很重視，很多項目經理本身是技術出身，可能管理跟的不是那麼上~.~。
4、項目成員有這樣的概念。
以上是前提。
開展配置管理工作的關鍵是讓公司內部的項目干係人的人感覺到配置管理工作在起作用。
最重要的手段：
針對不同的人進行不同層次的培訓。
1、對於老闆/總監/技術老大/項目老大等等所有項目的統籌負責人，可以做一些月度季度年度報表PPT什麼的告訴他你做了什麼。取得了什麼樣的效果。
2、對於項目經理們或者准項目經理們，做配置管理里關於流程方面的培訓（比如配置項管理、基線管理、變更管理、構建管理、版本管理、發布管理、審計管理、外部發布管理等）、然後就是一些配合不同開發模式（比如瀑布、螺旋、敏捷等）進行配置工具培訓、 比如分支開發、自動構建、持續集成等
3、對於普通開發測試等項目組成員，就是培訓各類工具的使用了比如svn/git/cc等，比如一些好的操作，版本對比、回退機制、代碼共享、同步開發等等。
至於配置管理過程的話，網上一大堆，隨便憑記憶總結下，可能不全：
1、從組織上定義標准流程規范制度等。這個規范制度是用來指導配置管理工作的總規范。包括具體的配置管理簡介、配置管理過程中涉及到的人的權責、然後就是配置管理實施的策略（比如計劃、配置項、基線、變更、發布、審計、報告、伺服器管理、配置工具說明、許可權管理總則、配置庫結構標准、庫備份啊、收尾工作比如移交轉產交付取消許可權刻盤保存等），可能還要定義一個內測版本、外測版本、正式版本號的附則。製作好所有的excel/word/ppt/txt模版。給領導審批通過就OK了。
2、項目開始就後按照組織定義的配置管理流程去做，不斷裁剪修改，不同規模的配置管理工作的需求是不同的，要考慮投入產出是否合理，與項目是否適配。
------------------------------------------
以上所有涉及到和領導相關的步奏，請考慮你在公司的實際地位和能力水平，有可能你的項目的配置管理工作沒有到這個高度，還只是初級階段，領導都不知道。一般來說成熟的軟體公司、規模比較大配置管理是單獨的。如果你只是某個項目的，沒有那麼高的地位那就只針對本項目的經理和普通成員來操作吧.......~.~
❷ 在工程實施項目中如何開展配置管理工作
實施階段的配置管理階段從廣義上將已經算是維護階段了。
代碼開發已經結束，配置項已經被基線。
1.理想狀況是在測試階段就模擬出現場環境做安裝測試。基本不需要配置管理介入。發現問題也是維護類型bug，發下一個維護版本時解決。這時體現出產品可配置性很重要。
2.最糟的情況才安裝實施過程中發現問題必須修改代碼重新編譯，這個就復雜一些了。
排到現場去的實施人員必須是骨幹力量，能夠迅速定位問題，或者把出線的問題描述清楚，由後方架構師處理。
修復bug後重新發布緊急維護版本。如果這個過程配置管理沒有介入，那後期升級可能會帶來代碼版本與實施現場的不一致。導致下次實施再次出問題
❸ 如何為所需的配置管理配置配置基線
基線」是一個很常見的術語，在配置管理和項目管理裡面都能看到，而且還有很多衍生的術語，例如基線提升、基線化、基線審計，等等等等。 我個人以前對微軟的那套開發流程（就是proct cycle model）以及PSP、TSP了解比較多一些，這些流程裡面對「...
❹ 關於項目管理中配置管理的實現過程，配置項的知識請教以及相比版本管理的差異
你的理解更多是「產品集成」的概念，即怎麼把幾個產品模塊或構件組合成一個產品，但這不是配置管理的概念。
配置管理：簡稱CM（Configuration Management的縮寫），標識、控制和管理變更的一種管理活動。它控制配置項的修改和發行；記錄和報告配置項的狀態和變更；保證配置項的完整性、一致性和正確性；以及控制配置項的儲存、裝載和交付。
根據這個定義，配置管理的主要工作包括：
1）配置庫的管理活動。配置庫現在工具非常多，例如GIT、SVN、CVS、VSS等等。通常會根據開發所處的階段，設立開發庫、受控庫與產品庫。
2）標識配置項，即需要定義如何去標識配置項。配置管理中受控制的對象被稱為配置項，是生命周期中創建的信息，包含程序、數據、文檔，分基線配置項和非基線配置項兩類。特別是你的產品最終是如何標識的，比如怎樣定義V1.0.0的規則。
3）基線的管理。是一組經過正式審查並且達成一致的規范或工作產品，是下一階段工作的基礎。怎樣確定、發布基線，怎樣管理基本的變更。
4）配置項變更管理。可以根據不同的配置項、不同的開發周期，明確變更的管理規則。
5）配置項狀態管理與配置審計 。
而產品集成是如何把一個產品逐步的從一個個模塊或組件，最後組合成一個產品的過程。
1）首先產品的技術結構上要能夠支持，如果模塊不能相互獨立和拆解，談不上靈活的組合。
2）在開發實現上，需要有一個集成的策略，哪些先實現，哪些後實現，哪些可以先進行集成
3）需要建立 集成的環境，使開發好的模塊可以在集成環境中進行調試
4）通常開發完成後，需要進行源代碼的編譯，並打包成一個測試包，然後裝在集成環境中，進行調試，以確認各個模塊之前是否可以兼容和運轉，這時通常會進行測試工作。
5）如果你想進行ABC組合，或者AC組合，那麼都需要進行相應的編譯、打包（例如形成EXE）過程，然後在集成環境中進行聯調和測試。
❺ 什麼是配置項管理
按管理的嚴格程度，配置項一般分3個等級：
（1）納入基線管理的配置項
納入基線管理的配置項是指變化時要走嚴格變更手續的配置項，需要做變更申請，要審批。審批一般分2種嚴格程度：
i) 項目經理或分CCB審批就可以，一般是局部的小的變更。
ii）變更控制委員會（CCB）審批
納入基線前，一般要經過評審或測試（稱為驗證）和質量保證。
(2) 沒有納入基線但是也不能隨意變更的配置項，一般稱為受控項
這類配置項不需要變更申請，但是要經過配置管理員或項目經理的允許才可以變更。
基線項與受控項寫的許可權要唯一，一般是CM或PM有唯一的寫許可權。
（3）非受控項
對變更不做控制。
擬納入基線管理的配置項狀態變化一般是先非受控，然後受控，最後基線化。變更時，先檢出（checkou）進行修改，修改完畢後再檢入（checki）轉為受控，等待驗證（測試或評審），通過驗證後進行基線化。
擬納入受控而不入基線的配置項狀態變化一般是先非受控，然後受控。變更時，檢出進行修改，修改完畢後再檢入提交受控。
納入基線管理的時機是管理平衡問題，一般是當配置項基本穩定後才納入基線管理，如果處與頻繁的變動之中，納入基線後會增加管理成本，如單元測試通過後一般不形成基線，因為此時代碼並不穩定，但是可以作為受控項，也不能任意變化。這個問題的判斷也和項目組的規模有關系，如果規模很大，涉及到的人員很多，也可能需要建立基線。在系統測試後要形成基線，一般稱為產品基線，此時系統基本穩定了，可以對外發布，為更多的人所了解和使用了。代碼在沒有納入基線但是受控後（提交測試人員測試了），也不能隨便變更了，要經過配置管理員的批准，並通知測試人員。
❻ 配置管理員的標識和控制
所有配置項都都應按照相關規定統一命名，並在文檔中的規定章節（部分）記錄對象的標識信息。在引入軟體配置管理工具進行管理後，這些配置項都應以一定的目錄結構保存在配置庫中。
所有配置項的操作許可權應由SCM嚴格管理，推薦原則是：基線配置項向軟體開發人員開放讀取得許可權；非基線配置項向PM、CCB及相關人員開放。
1．工作空間管理
在引入了軟體配置管理工具之後，所有開發人員都會被要求把工作成果存放到由軟體配置管理工具所管理的配置庫中去，或是直接工作在軟體配置管理工具提供的環境之下。所以為了讓每個開發人員和各個開發團隊能更好的分工合作，同時又互不幹擾，對工作空間的管理和維護也成為了軟體配置管理的一個重要的活動。
一般來說，比較理想的情況是把整個配置庫視為一個統一的工作空間，然後再根據需要把它劃分為個人（私有）、團隊（集成）和全組（公共）這三類工作空間（分支），從而更好的支持將來可能出現的並行開發的需求。
每個開發人員按照任務的要求，在不同的開發階段，工作在不同的工作空間上，例如：對於私有開發空間而言，開發人員根據任務分工獲得對相應配置項的操作許可之後，他即在自己的私有開發分支上工作，他的所有工作成果體現為在該配置項的私有分支上的版本的推進，除該開發人員外，其他人員均無權操作該私有空間中的元素；而集成分支對應的是開發團隊的公共空間，該開發團隊擁有對該集成分支的讀寫許可權，而其他成員只有隻讀許可權，它的管理工作由SIO負責；至於公共工作空間，則是用於統一存放各個開發團隊的階段性工作成果，它提供全組統一的標准版本，並作為整個組織的Knowledge Base。
當然，由於選用的軟體配置管理工具的不同，在對於工作空間的配置和維護的實現上有比較大的差異，但對於CMO來說，這些工作是他的重要職責，他必須根據各開發階段的實際情況來配置工作空間並定製相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基線的推進。
2．版本控制
版本控制是軟體配置管理的核心功能。所有置於配置庫中的元素都應自動予以版本的標識，並保證版本命名的唯一性。版本在生成過程中，自動依照設定的使用模型自動分支、演進。除了系統自動記錄的版本信息以外，為了配合軟體開發流程的各個階段，我們還需要定義、收集一些元數據（Metadata）來記錄版本的輔助信息和規范開發流程，並為今後對軟體過程的度量做好准備。當然如果選用的工具支持的話，這些輔助數據將能直接統計出過程數據，從而方便我們軟體過程改進（Software Process Improvement，SPI）活動的進行。
對於配置庫中的各個基線控制項，應該根據其基線的位置和狀態來設置相應的訪問許可權。一般來說，對於基線版本之前的各個版本都應處於被鎖定的狀態，如需要對它們進行變更，則應按照變更控制的流程來進行操作。
3．變更控制
在對SCI的描述中，我們引入了基線的概念。從IEEE對於基線的定義中我們可以發現，基線是和變更控制緊密相連的。也就是說在對各個SCI做出了識別，並且利用工具對它們進行了版本管理之後，如何保證它們在復雜多變得開發過程中真正的處於受控的狀態，並在任何情況下都能迅速的恢復到任一歷史狀態就成為了軟體配置管理的另一重要任務。因此，變更控制就是通過結合人的規程和自動化工具，以提供一個變化控制的機制。
在本文的前面的部分中，已經把SCI分為基線配置項和非基線配置項兩大類，所以這里所涉及的變更控制的對象主要指配置庫中的各基線配置項。
變更管理的一般流程是：
A) （獲得）提出變更請求；
B) 由CCB審核並決定是否批准；
C) （被接受）修改請求分配人員為，提取SCI，進行修改；
D) 復審變化；
E) 提交修改後的SCI；
F) 建立測試基線並測試；
G) 重建軟體的適當版本；
H) 復審（審計）所有SCI的變化；
I) 發布新版本。
在這樣的流程中，SCM通過軟體配置管理工具來進行訪問控制和同步控制，而這兩種控制則是建立在前文所描述的版本控制和分支策略的基礎上的。
4．狀態報告
配置狀態報告就是根據配置項操作資料庫中的記錄來向管理者報告軟體開發活動的進展情況。這樣的報告應該是定期進行，並盡量通過CASE工具自動生成，用資料庫中的客觀數據來真實的反映各配置項的情況。
配置狀態報告應根據報告應著重反映當前基線配置項的狀態，以作為對開發進度報告的參照。同時也能從中根據開發人員對配置項的操作記錄來對開發團隊的工作關系作一定的分析。
配置狀態報告應該包括下列主要內容：
A) 配置庫結構和相關說明；
B) 開發起始基線的構成；
C) 當前基線位置及狀態；
D) 各基線配置項集成分支的情況；
E) 各私有開發分支類型的分布情況；
F) 關鍵元素的版本演進記錄；
G) 其它應予報告的事項。
5．配置審計
配置審計是指在配置標識、配置控制、配置狀態記錄的基礎上對所有配置項的功能及內容進行審查，以保證軟體配置項的可跟蹤性。一般的，獨立的SCM可以擔當配置審計。
總之，軟體配置管理的對象是軟體研發活動中的全部開發資產。所有這一切都應作為配置項納入管理計劃統一進行管理，從而能夠保證及時的對所有軟體開發資源進行維護和集成。因此，軟體配置管理的主要任務也就歸結為以下幾條：（1）制定項目的配置計劃；（2）對配置項進行標識；（3）對配置項進行版本控制；（4）對配置項進行變更控制；（5）定期進行配置審計；（6）向相關人員報告配置的狀態。
由於軟體配置管理覆蓋了整個軟體的開發過程，因此它是改進我們的軟體過程、提高過程能力成熟度的理想的切入點。
❼ 項目章程應該包括哪些內容
項目章程的內容
1. 基於項目干係人的需求和期望提出的要求。
2. 項目必須滿足的業務要求或產品需求。
3. 項目的目的或項目立項的理由。
4. 委派的項目經理及項目經理的許可權級別。
5. 概要的里程碑進度計劃。
6. 項目干係人的影響。
7. 職能組織及其參與。
8. 組織的、環境的和外部的假設。
9. 組織的、環境的和外部的約束。
10. 論證項目的業務方案，包括投資回報率。
11. 概要預算。
組織過程資產的內容
組織過程資產包含：項目實施組織的企業計劃、政策方針、規程、指南和管理系統，
實施項目組織的知識和經驗教訓。
項目范圍說明書的內容
1. 項目和范圍的目標。
2. 產品或服務的需求和特性。
3. 項目的需求和可交付物。
4. 產品驗收標准。
5. 項目的邊界。
6. 項目約束條件。
7. 項目假設。
8. 最初的項目組織。
9. 晟初定義的風險。
10. 進度里程碑。
11. 對項目工作的初步分解。
12. 初步的量級成本估算。
13. 項目配置管理的需求。
14. 審批要求。
項目管理計劃的內容
1. 項目背景如項目名稱、客戶名稱、項目的商業目的等。
2. 項目經理、項目經理的主管領導、客戶方聯系人、客戶方的主管領導，項目領導小組（即項目管理團隊）和項目實施小組人員。
3. 項目的總體技術解決方案。
4. 對用於完成這些過程的工具和技術的描述。
5. 選擇的項目的生俞周期和相關的項目階段。
6. 項目最終目標和階段性目標。
7. 進度計劃。
8. 項目預算。
9. 變更流程和變更控制委員會。
10. 溝通管理計劃。
11. 對於內容、范圍和時間的關鍵管理評審，以便於確定懸留問題和未決決策。
項目計劃的編制流程
1. 明確目標
2. 成立初步的項目團隊
3. 工作準備與信息收集
4. 依據標准、模板，編寫初步的概要的項目計劃。
5. 編寫范圍管理、質量管理、進度、預算等分計劃。
6. 把上述分計劃納入項目計劃，然後對項目計劃進行綜合平衡、優化。
7. 項目經理負責組織編寫項目計劃。
8. 評審與批准項目計劃。
9. 獲得批准後的項目計劃就成為了項目的基準計劃。
WBS的表現形式
1. 分級的樹型結構
WBS層次清晰，非常直觀，結構性很強，但不是很容易修改，對於大的、復雜的項目也很難表示出項目的全景。
2. 列表形式
能夠反映出項目所有的工作要素，可是直觀性較差
工作分解結構應把握的原則
1. 在各層次上保持項目的完整性，避免遺漏必要的組成部分。
2. 一個工作單元只能從屬於某個上層單元，避免變叉從屬。
3. 相同層次的工作單元應有相同性質。
4. 工作單元應能分開不同的責任者和不同工作內容。
5. 便於項目管理進行計劃和控制的管理需要。
6. 最低層工作應該具有可比性，是可管理的，可定量檢查的。
7. 應包括項目管理工作，包括分包出去的工作。
8. WBS的最低層次的工作單元是工作包。
縮短工期的方法
1. 投入更多的資源以加速活動進程。
2. 指派經驗更豐富的人去完成或幫助完成項目工作。
3. 減小活動范圍或降低活動要求。
4. 遁過改進方法或技術提高生產效率。
進度控制關注的內容：
5. 確定項目進度的當前狀態。
6. 對引起進度變更的因素施加影響，以保證這種變化朝著有利的方向發展。
7. 確定項目進度已經變更。
8. 當變更發生時管理實際的變更。
活動資源估算的方法
1. 專家判斷
2. 多方案分析
3. 出版的估算數據
4. 項目管理軟體
5. 自下而上估算
活動歷時估算的內容：
1. 專家判斷
2. 類比估算
3. 參數估算
4. 三點估算
5. 後備分析
制定進度計劃的方法和工具：
1. 進度網路分析
2. 關鍵路線法
3. 進度壓縮（趕進度、快速跟進）
4. 假設情景分析
5. 資源平衡
6. 關鍵鏈法（緩沖）
7. 項目管理軟體
8. 應用日歷
9. 調整時間提前與滯後量
10. 進度模型
成本估算的工具和技術
1. 類比估算
2. 確定資源費率
3. 自下而上估算
4. 參數估算
5. 項目管理軟體
6. 供貨商投標分析
7. 准備金分析
8. 質量成本
成本預算的工具和方法
1. 成本匯總
2. 准備金分析
3. 參數估算
4. 資金限制平衡
項目成本控制的主要內容
1. 對造成成本基準變更的因素施加影響；
2. 確保變更請求獲得同意；
3. 當變更發生時，管理這些實際的變更；
4. 保證潛在的成本超支不超過授權的項目階段資金和總體資金；
5. 監督成本執行（績效），找出與成本基準的偏差；
6. 准確記錄所有的與成本基準的偏差；
7. 防止錯誤的、不恰當的或未批準的變更被納入成本或資源使用報告中{
8. 就審定的變更，通知項目干係人；
9. 採取措施，將預期的成本超支控制在可接受的范圍內
質量管理過程的4個環節
1. 確立質量標准體系
2. 對項目實施進行質量監控
3. 將實際與標准對照
4. 糾偏糾錯
制定項目質量的工具和技術
小雞公爵六十隻
1. 效益／成本分析
2. 基準比較
3. 流程圖
4. 實驗設計
5. 質量成本分析
6. 質量功能展開
7. 過程決策程序圖法
質量保證活動的基本內容
1. 制定質量標准
2. 制定質量控制流程
3. 提出質量保證所採用方法和技術
4. 建立質量保證體系
質量控制的方法：
1. 新七：因果圖、流程圖、直方圈、檢查表、散點圖、排列圖和控制圖
2. 老七：相互關系圖、親和圈、樹狀圖、矩陣圖、優先矩陣圖、過程決策方法圖和活動網路圖
3. 測試、檢查、統計抽樣、6西格瑪
質量控制的步驟：
1. 選擇控制對象
2. 為控制對象確定標准或目標。
3. 制定實施計劃，確定保證措施。
4. 按計劃執行。
5. 對項目實施情況進行跟蹤監測、檢查，並將監測的結果與計劃或標准相比較。
6. 發現並分析偏差。
7. 根據偏差採取相應對策
組件項目團隊的工具和技術
1. 事先分派：預先分配到項目中
2. 談判：人員分派多少在談判中
3. 采購：聘用和分包
4. 虛擬團隊：互聯網
成功的項目團隊的特點：
1. 團隊的目標明確，成員清楚自己的工作對目標的貢獻。
2. 團隊的組織結構清晰，崗位明確。
3. 有成文或習慣的工作流程和方法，而且流程簡明有效。
4. 項目經理對團隊成員有明確的考核和評價標准，工作結果公正公開，賞罰分明。
5. 共同制訂並遵守的組織紀律。
6. 協同工作，也就是一個成員工作需要依賴於另一個成員的結果，善於總結和學習。
溝通管理計劃的內容：
1. 項目干係人溝通要求。
2. 對要發布信息的描述，包括格式、內容和詳盡程度。
3. 信息接收的個人或組織。
4. 傳達信息所需的技術或方法。如備忘錄、電子郵件、新聞發布等。
5. 溝通頻率。如每周溝通。
6. 上報過程，對下層無法解決的問題，確定問題上報的時間要求和管理鏈（名稱）。
7. 隨項目的進展對溝通管理計劃更新與細化的方法。
8. 通用詞語表。
項目總結會議的目的（意義）：
1. 了解項目全過程的工作情況及相關的團隊或成員的績效狀況
2. 了解出現的問題並進行改進措施總結
3. 了解項目全過程中出現的值得吸取的經驗並進行總結
4. 對總結後的文檔進行討論，通過後存入公司的知識庫，從而納入企業的過程。
4種違約責任的承擔方式：
1. 繼續履行
2. 採取補救措施
3. 賠償損失
4. 支付約定違約金或定金。
項目合同簽訂事項：
1. 當事人的法律資格；
2. 質量的驗收標准；
3. 驗收時間；
4. 技術支持服務；
5. 損害賠償；
6. 保密約定；
7. 合同附件、法律公正。
合同不明確情況的處理方法：
先協商，未完成補充協議
1. 當事人對標的物的質量要求不明確的，按國家標准和行業標准。沒有標準的，按產品通常標准或符合合同目的的標准。
2. 履行地點不明確時，按性質不同而定，接受貨幣在接受方，交付不動產的在不動產所在地，其他標的在履行義務方所在地。
3. 履行期限不明的，債務人可以隨時履行，債權人可隨時要求履行，但應給對方必要的准備時間。
4. 履行費用負擔不明確的，由履行義務一方承擔，履行費用是履行義務過程中何種附隨發生的費用。
索賠程序：
項目發生索賠事件後，一般先由監理工程師調解，若調解不成，由政府建設主管機構進行調解，若仍調解不成由合同仲裁委員會進行調解或仲裁。在整個過程中，遵循的原則是索賠的有理性、索賠依據的有效性、索賠計算的正確性。
配置管理包括4個主要活動：
5. 配置識別
6. 變更控制
7. 狀態報告
8. 配置審計
配置管理流程：
1. 制定配置管理計劃
2. 配置識別與建立基線
3. 建立配置管理系統
4. 版本管理
5. 配置狀態報告和配置審計
配置識別的內容：
1. 識別需要受控的軟體配置項。
2. 給每個產品和它的組件及相關的文檔分配唯一的標識。
3. 定義每個配置項的重要特徵以及識別其所有者。
4. 識別組件、數據及產品獲取點和准則。
5. 建立和控制基線。
6. 維護文檔和組件的修訂與產品版本之間的關系。
配置識別的基本原則：
基線配置項向軟體開發人員開放讀取許可權；非基線配置向PM、CCB及相關人員開放。基線配置包括設計文檔和源程序；非基線配置包括各類計劃和報告。
建立配置管理方案的步驟：
1. 組建配置管理方案構造小組
2. 對目標機構進行了解、評估
3. 配置管理工具及其提供商評估
4. 制訂實施計劃
5. 定義配置管理流程
6. 試驗項目的實施
7. 全面實施
變更的流程：
1. 提出與接受變更申請。
2. 對變更的初審（常見方式：變更申請文檔的審核流轉）。
3. 變更方案論證（技術評估轉換成果、經濟評估轉換價值和風險）。
4. 項目變更控制委員會審查（文檔會簽形式）。
5. 發出變更通知並開始實施。
6. 變更實施的監控（由項目經理負責項目基準的監控；管理委員會監控成果、進度里程碑）。
7. 變更效果的評估。
8. 判斷發生變更後的項目是否已納入正常軌道。
系統集成項目系統驗收文檔的內容：
1. 系統集成項目介紹。
2. 系統集成項目最終報告。
3. 信息系統說明手冊。
4. 信息系統維護手冊。
5. 軟硬體產品說明書、質量保證書等
項目總結的意義：
1. 了解項目全過程的工作情況及相關的團隊或成員的績效狀況。
2. 了解出現的問題並進行改進措施總結。
3. 了解項目全過程中出現的值得吸取的經驗並進行總結。
4. 對總結後的文檔進行討論，通過後即存入公司的知識庫，從而納入企業的過程資產。
項目總結會的內容：
1. 項目績效
2. 技術績效
3. 成本績效
4. 進度計劃績效
5. 項目的溝通
6. 識別問題和解決問題
7. 意見和建議
項目人員轉移流程：
1. 項目團隊成員的管理計劃，也就是項目人力資源管理計劃中描述所說的人員轉移條件已經觸發。
2. 項目團隊成員所承擔的任務已完成，提交了經過確認的可交付物並已完成工作交接。
3. 項目經理與項目團隊成員確認該成員的工作銜接已經告一段落或者已經完成。
4. 項目經理簽發項剛團趴成員轉移確認文件。
5. 項目經理簽發項目團隊成員的績效考核文件。
6. 項目經理通知所有相關的干係人。
7. 若是項目收尾全體項目成員結束項目工作，應召開項目總結表彰大會，肯定項目的成績、團隊成員的業績，同時總結項目的經驗教訓。
❽ 管理配置的基本操作有哪些三種
管理配置的基本操作有這三種：1.事前控制、2.即時控制、3..事後控制。
事前控制是指一個組織，在一項活動正式開始之前所進行的管理上的努力。
即時控制是在某項活動或工作過程中進行的控制。
事後控制即發生在行動或任務終了之後的控制。
制定配置管理計劃
配置管理員制定《配置管理計劃》，主要內容包括配置管理軟硬體資源、配置項計劃、基線計劃、交付計劃、備份計劃等。CCB審批該計劃。
配置庫管理
配置管理員為項目創建配置庫，並給每個項目成員分配許可權。各項目成員根據自己的許可權操作配置庫。配置管理員定期維護配置庫，例如清除垃圾文件、備份配置庫等。