作為乙個專案管理者，如何要成功的做好專案管理；首先必須先要明白的是在特定的領域中賦予這個角色所要實現的目標、承擔的職責、以及專案管理者的具體工作內容是什麼？
從我個人的淺見和角度以及我們所從事的it領域來分析回答以上三個問題。
作為乙個專案的管理者，必須要明確的知道自己的工作目標；我個人認為專案管理者的目標無非就是以下兩點：
1、就是清晰明確地了解專案利害關係者的需求和期望，努力做到滿足專案利害關係者的不同需求；專案利害關係者包括：專案團隊成員和專案團隊外成員(比如各部門的部門負責人和市場人員，客戶等)。
2、就是保證開發專案按需按時保質的完成。
作為專案的管理者，首先要端正態度，要明確知道自己的工作職責，認識到這份工作職責的本質。專案管理者不是來管人的，而是來支援人的，是來協調資源的，是來營造乙個適合團隊成員比較認同的工作環境和氛圍的，是來為乙個共同的目標和大家一起戰鬥共同成長的。可以大概概括成以下幾點：
1、建立有效的工作流程保證專案的順利進行。
2、制定詳細周密的專案計畫。
3、跟蹤，推動專案按計畫進行。
4、積極解決專案過程中出現的問題和衝突。
5、調動開發團隊的積極性，創造力，推動團隊成員在專案過程中不斷成長。
6、專案風險識別、風險評估、風險解決和風險管理策略以及做好突發風險的應急預案。
7、實現目標
最後乙個是專案管理者的具體工作內容，作為專案管理者必須清晰的知道自己的工作範圍和所要做的工作內容以及工作重心，分為以下六點：
對專案進行技術可行性分析、技術評估、成本評估以及風險評估。與需求提出方的代表進行需求討論，明確專案的目標、價值；確定專案範圍、功能及優先順序。組建專案團隊，特別要搞清楚專案的key person(對產品有決定權的人)。
專案啟動會議，相關的利害關係人員都必須參加。
該階段完成後的成果：確認後的最終軟體需求規格說明書文件。
根據確認後的軟體需求規格說明書，制定專案進度計畫，工作任務分解(wbs)；資源申請，專案涉及到的開發資源、測試資源、設計資源(包括人員和軟硬體資源)；資料庫設計；系統設計；文件(包括use case、demo系統原型、test case等)；評審會議。
該階段完成後的成果：
a、user case(系統用例)；
b、demo(系統原型)；
c、系統設計文件(概要設計和詳細設計)；
d、資料庫設計文件。
最後對完成的成果，包括user case和設計文件等進行評審。
準備開發環境、測試環境；跟蹤，推動專案按計畫進行；以週報的形式通報專案的進展情況。對專案的階段成果進行評估，以確保該階段完成的質量，包括**審核、sql審核等。對需求變更進行控制管理；對專案風險進行管理；測試階段bug fixed及改進、收集反饋意見。
包括制定專案發布計畫，使用者培訓，發布上線。
資料監控(日誌、伺服器狀態)，根據監控出現的問題，及時進行bug fixed及改進或做補丁公升級。
產品交付，專案總結會。
要做好專案管理，並能確實解決好以上三個問題，實現目標、履行職責、完成工作中的具體內容，從我個人這幾年的工作經驗和面臨的一些問題，還有所積累的一些專案管理中的一些知識以及自己的觀察和思考的角度看，應該要努力做好以下這幾個方面的具體工作：
制定專案進度時間表的時候，需要估算每個任務所需的時間，其中開發任務中模組的分配和時間估算是其中最主要的部分；在分配模組和估算開發時間時需要遵循的原則和目標：
1、保證專案整體的進度。
2、有助於確保開發編碼的質量。
3、有助於提高開發編碼的速度。
在公司現有的技術框架下，開發人員主要的工作是投入在具體的商業邏輯上。通常每個模組所需的開發時間取決於以下三個因素：
1、所負責模組的商業邏輯的複雜程度。
2、開發人員的技術水平和對專案所在應用的熟悉程度(包括對框架和應用的熟悉程度)。
3、該模組技術實現上是否有技術難點；這裡所謂的技術難點定義是：在現有系統中還未實現的、開發人員自身也未沒接觸過的技術。對於這樣的難點，開發者沒有相關的**可以參考，自己也沒有經驗，所以需要投入一些時間研究解決。
模組分配和開發時間估算的步驟：
1、在劃分好模組後，首先自己先估算一下每個模組所需要的開發時間。
2、然後召集所有開發人員，討論模組的分配和開發時間估算。將劃分好的模組，讓開發人員從中挑選他們感興趣的模組。這樣做可以提高開發人員的主動性和參與性。
在分配模組的時候還需從以下幾方面考慮，以確保開發的速度和質量：
a、相同類似的模組由同一人負責開發，比如使用者管理的增刪改由同一開發者負責。這樣做的好處就是開發者對相關邏輯會更加熟悉，同時介面的定義也會比較明確，溝通的成本比較低，同時功能實現的缺陷也相應的會降低。
b、技術難度比較大的模組由技術水平比較高的人負責。
c、業務邏輯比較複雜的由對這塊邏輯比較了解的人負責。
3、模組分配完後，開發人員評估自己負責開發的模組所需要的時間。在此過程中最好做到要和開發者比較詳細的討論每個模組的技術實現，以便使時間的估算更加準確。
4、對開發人員估算的時間進行確認。在確認過程中作為專案管理者應參考以上提到的三個因素，同時將自己估算的時間和開發人員估算的時間進行比較。這其中的差異當然會存在的。
對於那些差異比較大的，將與技術人員**其中的緣由。對於時間週期比較長的任務，盡量將任務通過再細分的手段細化任務，爭取每個任務的最長時間不超過3天；時間週期越長的任務，不確定性越高，風險也越高，越有可能成為專案的瓶頸，影響專案的進度。
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給所有技術人員。如果通過以上步驟，還因
為是**編寫者的原因而出現嚴重的缺陷問題，將通過績效考核來加深**編寫者的印象，並在週報會議上做通報批評。
需求變更管理也是專案管理中最重要的乙個環節，對需求變更管理的有效性將直接影響專案的成功與否。
對待需求變更的態度：
1、需求變更是不可避免的。
2、需求變更要必須被管理。
3、積極發現引起變更的因素，促使變更盡可能早的出現，減低變更帶來的風險。
需求變更管理的目標：
1、相關的干係人必須清楚地了解發生的變更。
2、變更處於有效的管理中。
3、盡量降低變更帶來的風險。
通過制定需求變更的流程，確保專案中的需求變更有效地進行，實現上述的目標。需求變更流程：
1、確定需求的基準線。將以user case作為需求基準線，在user case確認之後的任何需求改變，都需要走需求變更流程，這一環節我們基本沒有，期間有時候使的工作很混亂，也就是因為沒有乙個規範的變更流程而造成的；如果建立了這麼乙個流程規範和機制，需求變更沒有走這個流程的將不被認可。
2、專案管理者接收到需求變更的要求。需求變更的提出者可以是專案中的任何人包括產品經理、市場人員、開發人員、測試人員等。
3、專案管理者評估該需求變更。針對接收到的需求變更的要求，召集相關人員討論該需求變更的合理性、可行性，實施的代價以及對專案的影響。包括可能影響的專案範圍，進度，費用，質量等計畫。
專案管理者作為專案的負責人，對專案的成功與否負有主要的責任。所以需求變更的決策者應該由專案管理者承擔。
4、需求變更確認後由專人將需求變更記錄下來，通知給專案中所有成員。其中以下人員對需求的變更是緊密相關的，他們必須知曉並認可此需求變更。包括（客戶方，需求分析人員，測試人員，相關開發人員）。
需求變更記錄格式如下：
5、確定變更的負責人。承擔需求變更的具體工作，比如基線控制，對需求變更的記錄，並通知相關人員。
6、相關人員接收到確認的需求變更後，做以下事情。需求分析人員修改需求說明書和user case的相關內容。測試人員修改測試用例的相關內容。開發人員修改**中的相關部分。
7、按照變更後的計畫實施專案，並進行檢查，跟蹤，對變更後的實施反饋和可能出現的問題及時溝通和處理。
8、需求凍結。專案越到後期，需求變更對專案的影響就越大，所以在一定時候要進入需求凍結階段，不再接收新需求或需求的變更。
軟體開發實施方案
系統開發嚴格按照軟體工程的方法進行組織，系統的開發過程按照需求分析 系統分析與設計要求 系統編碼 系統測試幾個過程有序推進。下表所示系統開發流程圖，採用原型及迭代方式開發，根據使用者需求持續改進，直到終端使用者確認滿意。如下圖示流程定義了我公司內部的軟體開發過程，以指導和規範軟體專案中開發過程的定義...
軟體開發專案管理
軟體開發專案管理，補習對軟體開發專案的工作範圍 可能遇到的風險 需求的資源 要實現的任務 經歷的里程碑 話費的工作量，以及進度的安排等等做到心中有數。而軟體專案管理可以提供這些資訊。軟體具有可見性差 定量化難等特殊性。但通常可以 根據以往開發類似軟體的經驗來進行成本估算。將軟體專案劃分為若干個子系統...
專案軟體開發計畫
公司名 專案名 軟體開發計畫 版本 1.0 注 以下提供的模板用於 rational unified process。其中包括用方括號括起來並以藍色斜體 樣式 infoblue 顯示的文字，它們用於向作者提供指導，在發布此文件之前應該將其刪除。按此樣式輸入的段落將被自動設定為普通樣式 樣式 body...