項目管理制度【新版多篇】

項目管理的重要性 篇一

1當前軟件項目管理重要性的認識

由於在當前廣泛應用計算機造成妨礙的一個瓶頸就是對計算機軟件的高質量與高效的開發。研究軟件工程領域長期以來的一個熱點就是藉助相應工具與技術將計算機軟件質量與生產率提升。如果開發軟件過程當中，當尚未良好定義、實施與管理開發軟件組織，並且尚未在開發軟件過程做到持續性的改進，那麼勢必會導致開發組織在研宄軟件工程成果當中取得相應期望結果。管理軟件項目這也就是說處於讓軟件項目可以根據之前預設的進度、質量、成本順利完成。以便能夠分析與管理質量、人員、分析、進度、成本的活動。

2管理項目軟件存在目的與問題

從目的上進行分析，管理項目軟件則爲了根據之前預設的成本、質量、進度等這些要求順利完成軟件項目提供保證。由於項目管理器作用顯得比較重要，那麼要想做到項目管理的真正實施，這件事情也並不是那麼簡單。要想將項目管理這一過程順利實施，這就必須做到將以下問題有效解決：第一個問題就是定義項目。由於存在着特別強的互動性在軟件企業和客戶，因此將客戶需求合理定義，充分和客戶實施相應的溝通，以便一起實施充分挖掘，這樣就能夠做到與客戶需求真正貼近；第二個問題是實施項目組織。從軟件行業來看，這一行業是屬於高智力密集型，實施項目組織環節當中，勢必會引發項目團隊和功能型部門之間的衝突、團隊運行模式和知識員工個性化的突出，這些因素應該在實施項目環節當中進行充分考慮；第三個問題就是控制項目。軟件在實施項目的全部階段當中，企業必須充分交流、溝通合作伙伴與客戶，不管是其中的哪個環節出現問題，勢必會導致對整個項目進程造成影響。除此之外，往往在管理軟件項目當中都會存在着變化的業務需求、應用技術等，這也就使得控制項目難度增加；第四個問題就是評價項目。往往對於項目實施相應的評價主要爲兩個層面，第一個層面就是對項目實施評價，受到難以清晰定義軟件項目客戶需求的影響，使得項目範圍模糊將困難帶給項目評價，另外一個層面就是對項目成員實施相應的評價，而不管哪名項目成員往往存在的個性顯得比較強，那麼就會迫切自我實現和創造價值，怎樣對員工價值實施量化、客觀、公正評價，這也是一個難點在管理軟件項目過程。

3開發建設軟件過程中管理軟件項目的重要性

通過與傳統的工業企業進行對比，軟件企業則會顯得明顯不同，而且軟件企業比較現代企業別的行業也存在着不同之處。軟件企業存在的最爲突出的特徵，這也就是說企業擁有的最主要資產則是一批能管理、熟悉業務、掌握技術的人。人的成本這是軟件企業主要成本，通過積累經驗與知識來積累主要財富。針對這樣的情況，軟件企業最關鍵的管理內容就是人力資源管理。軟件領域所需要討論的核心問題就是討論人這樣的被管理對象。

4建設軟件開發團隊內容

要想做到讓開發軟件團隊保持着高校，這就必須要立足於軟件開發團隊成員密切合作與合理開發流程條件下，軟件開發的所有成員面臨着挑戰積極應對，有效的管理、協調、計劃擱置工作一直延續到將明確目標完成，軟件開發團隊要想保持高效，那麼往往都會存在着以下的特點：一是共同目標比較清晰明確。軟件開發團隊保持着高效性這往往必須能夠清楚的理解要達到的目標，而且還應該瞭解目標所具備的重要價值與意義。目標做到明確清晰這往往能夠激勵團隊當中的成員將個人目標向羣體目標昇華，軟件開發團隊當中的各個成員樂於承諾團隊目標，而且能夠互相付出努力來實現目標。項目團隊成員與經歷真的實施怎樣的項目，實施這樣的項目的目的與原因，團隊具體是怎樣的工作範圍，項目完成的重要衡量標準與交付成果，另外製約項目實施因素以及假設前提等諸多問題存在一些一致理解與共同認識；二是軟件開發團隊相互之間精誠合作與信任。高效團隊所面臨的一個特別顯著的特徵就是成員相互之間信任。往往只有做到相互信任纔可以真誠的支持與交流，對於工作成果進行共享，可以緊扣項目實施緊密合作，可以相互將對方工作中的不足指出來，使得相互之間指責與推卸責任行爲減少，將整個團隊的凝聚力增強，開發項目效率提升。與之相反，如果在整個團隊當中缺乏相互之間的信任，這就肯定會出現散亂的局面，將不可估量的負面因素帶給開發項目。通過精誠合作就能夠讓全部隊員強烈意識個人與團隊所擁有的能力，使得團隊合作的重要性得到充分了解，將相互之間的合作當成是團隊力量與智慧的源泉，而並不只是侷限於將自己的任務完成而已。他們相互之間充分相信團隊比所有單個人都可以更好做出決定，解決更爲複雜問題，制定更爲科學方案；三是順暢溝通與融洽關係。團隊當中的成員相互之間尊重與信任，不僅僅是對工作本身關注，還對相互之間友誼更爲珍惜，以便可以共同營造出友愛、寬鬆、和諧工作環境。團隊成員更爲樂意將信息、經驗、知識進行分享，從而可以讓團隊擁有強烈凝聚力，成員存在自豪感和歸屬感，相互之間可以將他人與團隊成功進行分享。團隊則是實施開放性溝通交流，對於彼此之間的差異成人，積極鼓勵存在不同意見，還允許將不同意見表達出來。所有的人並不只是侷限與熱情的表達者，還是屬於忠實聽衆，充分包容尊重團隊成員不同觀點與意見；四是存在共同工作框架與規範。開發軟件項目這項工作具備一定的創造性，可是必須存在相應的開發紀律，通過建立起相應的共同工作框架就能夠讓團隊成員明白怎樣達到目標，怎樣做到什麼及對開發過程達成共識；建立起相應的規範就能夠讓各項工作有標準去進行遵循，以便讓成員明白團隊風格；建立起一定的紀律約束保證正常執行計劃。在策劃項目過程當中團隊怎樣將任務完成，誰去完成、完成任務期限、所要的技術支持等藉助於責任分配矩陣實施清晰的界定，團隊成員權責對等與分工清晰，所有的人都瞭解自己在整個項目當中承擔的角色，彙報關係與職責，包含的上下級是誰，碰到困難應該到哪裏去獲得相互的支持等。

項目管理的基本流程與要點 篇二

最近1年來，有不少熟識的朋友在考慮從傳統領域切入到互聯網，或者說是放棄了傳統的生意，而轉型到互聯網方面開始新的創業，他們希望能在互聯網上創立新的事業和新的高度。

但是，在他們印象裏，互聯網是一個比較籠統和模糊的的概念，特別是作爲第四媒體的互聯網媒體方面，從項目立項到技術開發，再到後面的運營推廣，這些流程問題，對於他們來說是非常陌生的。

所以在這裏，我以自己這幾年來積累的一些項目經歷和經驗，做下流程概述，希望能起到拋磚引玉的效果，同時也爲這些朋友的創業起到參考作用。

一，初步立項：

在立項前我增加了“初步立項”這一步驟，是爲了說明：有些老闆在“想做”和“何時做”之間，總是處於一種徘徊狀態，而這個徘徊期往往不短，結果很可能會錯失掉好的時機……

換句話說，也就是優柔寡斷、猶豫不決。

這個階段主要涉及到的人員有：老闆 決策團隊

這個階段的結束標誌是：做 or 不做 （做的話，繼續向下）

二， 正式立項：

到了這一步，我們可以就這個項目可以開始具體的工作開展了。

這個階段，應該完成下面幾個方面的方案：

1，產品定位與產品創意：（目標用戶羣體）

2，運營目標：（在互聯網方面一般會用IP和PV以及用戶數、瀏覽數等來數字化考覈）

3，預算投入：（有多少錢才能辦多少事）

4，運營方式/成本：（運營、運維、更新、推廣、審覈 等。成本）

5，盈利模式：（目前國內網站盈利模式普遍不清晰，但，總得有個大致方向）

其中，1和2是方向性問題，決定了你這個項目該向哪個方向去努力。3是資源性問題，4是操作層面和後續發展的問題，在立項時也必須要考慮到。

當然第5點的盈利模式也很重要，不過對於大多數互聯網企業來說，盈利模式是在網站發展過程中摸索出來的，而不是一開始就能確定的（例如現在的視頻分享網站，盈利模式都還處於探索中）。

另外，預算投入是整個項目的前提。作爲老闆和項目主管，你必須要知道手裏的錢，能夠支持你把這個項目做多久？做到什麼程度？也就是我們常說的“成本預算”及“目標設定”

這個階段主要涉及到的人員有：老闆 決策團隊 運營主管(coo)

這個階段的結束標誌是：“網站整體策劃”通過認可。 （做的話，繼續向下）

三，開始實施：

進行到這一步，就需要確定各職能部門人員了。有些懂技術的老闆會親自帶隊，而有些對互聯網不太懂的老闆會聘請首席運營官（coo）來負責這個項目的整理管理。

在這個階段，一般由運營主管(coo)來負責招聘到以下人員：

1，策劃（或產品）經理：主要是將項目主管和老闆的大想法落實到細節部分的團隊。如果項目主管是負責大腦的設計師，那麼，策劃產品團隊就是負責整個網站神經系統的設計師。

2，開發部經理：負責網站核心架構的搭建，並帶來團隊進行產品的功能性開發。

3，設計部經理：負責網站相關的設計。

4，推广部經理：負責網站對外市場開拓。

5，編輯部：網站的更新、維護等日常運營功能。

在人員配置初步階段，最好是先將各部門經理先招聘到位，然後再由各部門主管根據自己負責的工作範圍，配置人員及協調項目時間和進度。

另外在很多情況下：

1，1和5這2個部門是同屬於一個團隊的（運營部），不光負責網站前期的策劃，中期的項目協調，還要負責網站上線後的日常運營工作。而且這個工作是光榮而艱鉅的（“光榮在於平淡，艱鉅在於漫長”）。

但是目前有很多公司，會專門設立產品部，來負責新產品的策劃和開發，但是，往往是在開發完畢後，丟給（編輯）運營人員去運營。這樣往往導致了很多不錯的產品由於各種原因在推出後達不到預期的效果。

2，2和3一般情況下會整合爲技術部。再加上負責服務器這邊的運維部，一般由CTO來管理。

3，推广部一般會成立一個獨立的小團隊來開展工作，但是一般也是由COO直接領導的。

這個階段主要涉及到的人員有：運營主管(coo) 各部門主管

這個階段的結束標誌是：各部門主管人員到崗

四，產品原型：

原型設計：這主要是產品團隊人員的事情了。在充分理解老闆和coo的前提下，按照“網站整體策劃”方案開展網站產品的細化工作。並在規定時間內完成原型設計。

原型設計一般會經歷多次提案多次修改的過程。主要是將早期的“網站整體策劃”中的各種文字描述具體細化成成品網站的一個過程。

這個階段主要涉及到的人員有：運營主管(coo) 各部門主管

這個階段的結束標誌是：“產品原型”獲得通過

五，開發 設計階段：

到了這一部，一般由COO控制整個項目的進度，各產品經理負責自己範圍內產品的進度。設計和開發部經理配合協調，安排人力進行項目的具體設計和開發工作。具體過程就不多講了。

其它部門：例如推广部、編輯部、客服部 等等運營人員會開始做網站上線前期的準備。

這個階段主要涉及到的人員有：運營主管(coo) 設計開發部門 策劃產品團隊

這個階段的結束標誌是：產品的設計及開發完成程度，達到了產品策劃團隊的要求。

六，內測：

這個階段基本上是策劃、開發、設計都基本上收工了，這個時候需要以運營團隊爲主、其它人員爲輔，來進行網站的內部測試和內容填充等完善工作了。

這個階段主要涉及到的人員有：團隊所有人員

這個階段的結束標誌是：滿足“網站整體策劃”和“原型設計”的要求，達到上線標準。

七，公測/運營（推出）：

到了這步，網站已經上線了。

這段時間主要工作是：處理bug，優化功能，內容填充 等。

八，運營:

舞臺已經搭好，該輪到以(coo)運營團隊爲主的角色們來唱戲了。技術團隊退後做日常維護工作。

九， 結果：

作爲一個互聯網企業，其結果無非也就以下幾種方式：

1，自力更生，做強做大。

2，找風投。拿出部分股權換取風投資金，讓自己前期的投入得以套了現。

3，被收購。拿出大部分股權換取資金，帶着利潤套了現。

4，上市。路漫漫其修遠。

項目管理制度 篇三

根據建築業司《工程項目施工質量管理責任制（試行的通知）》建質[【xx】號精神，在工程中特制定以下質量管理制度。

1、工程項目質量總承包負責制度：

總承包單位對工程的全部分部分項工程質量向建設單位負責。每月向業主監理呈交一份本月的技術質量總結（由總包單位對分包工程進行全面質量控制），分包單位應對其分包工程施工質量向總包單位負責，各分包單位每月向總包方交一份技術質量總結。

2、技術交底制度：堅持以技術進步來保證施工質量的原則。技術部門應編制有針對性的施工組織設計，積極採用新工藝、新技術；針對特殊工序編制要有針對性的作業指導書。每個工種、每道工序施工前要組織進行各級技術交底，包括項目工程師對工長的技術交底、工長對班組的技術交底、班組長對作業班組的技術交底。各級交底以書面進行。因技術措施不當或交底不清而造成質量事故的要追究有關部門和人員的責任。

3、材料進場檢驗制度：

本工程的鋼筋、水泥和混凝土等各類材料需具備出廠合格證，並根據國家規範要求分批分量進行抽查檢，抽檢不合格的材料一律不準使用，因使用不合格材料而造成的質量事故要追究驗收人員的責任。

4、樣板引路制度：施工操作注意工序的優化、工藝的改進和工序的標準化操作，通過不斷探索，積累必要的管理和操作經驗，提高工序的操作水平，確保操作質量。每個分項工程或工種（特別是量大面廣的分項工程）都要在開始大面積操作前做出示範樣板，包括樣板牆板、樣板件等，統一操作要求，明確質量目標。

5、施工掛牌制度：主要工種如鋼筋、混凝土、模板、砌磚、抹灰等，施工過程中在現場實行掛牌制，註明管理者、操作者、施工日期，並做相應的圖文記錄，作爲重要的施工檔案保存。因現場不按規範、規程施工而造成質量事故的要追究有關人員的責任。

6、過程三檢制度：實行並堅持自檢、互檢、交接檢制度，自檢要作文字記錄。隱蔽工程要由工長組織項目技術負責人、質量檢查員、班組長檢查，並做出較詳細的文字記錄。

7、質量否決制度：對不合格分項、分部和單位工程必須進行返工。不合格分項工程流入下道工序，要追究班組長的責任，不合格分部工程流入下道工序要追究工長和項目經理的責任，不合格工程流入社會要追究公司經理和項目經理的責任。有關責任人員要針對出現不合格品的原因採取必要的糾正和預防措施。

8、成品保護制度：應當象重視工序的操作一樣重視成品的保護。項目經理人員應合理安排施工工序，減少工序的交叉作業上下工序之間應做好交接工作，並做好記錄。如下道工序的'施工可能對上道工序的成品造成影響時，應徵得上道工序操作人員及管理人員的同意，並避免破壞和污染，否則，造成的損失由下道工序操作者及管理人員負責。

9、質量文件記錄制度：質量記錄是質量責任追溯的依據，應力求真實和詳盡。各類現場操作記錄及材料試驗記錄、質量檢驗記錄等要妥善保管，特別是各類工序接口的處理，應詳細記錄當時的情況，理清各方責任。

10、有關工程技術、質量的文件資料管理制度：工程文件資料的完整是工程竣工驗收的重要依據，應真實和詳盡。由專職資料員收集、整理、保管存檔，做到工程技術、質量保證資料及驗收資料隨工程進度同步進行。

11、工程質量等級評定、覈定制度：竣工工程首先由施工企業按國家有關標準、規範進行質量等級評定，然後報當地工程質量監督機構進行等級覈定，合格的工程發給質量等級證書，未經質量等級覈定或覈定爲不合格的工程不得交工。

12、竣工服務承諾制度：工程竣工後在建築物醒目位置鑲嵌標牌，註明建設單位、設計單位、施工單位、監理單位以及開工竣工的日期，這是一種紀念，更是一種承諾。我司將主動做好回訪工作，按有關規定實行工程保修服務。

13、培訓上崗制度：工程項目所有管理及操作人員應經過業務知識技能培訓，並持證上崗。因無證指揮、無證操作造成工程質量不合格或出現質量事故的，除要追究直接責任者外，還要追究企業主管領導的責任。

項目管理心得體會 篇四

前段時間，我負責了一個項目的管理與開發。在時間短、任務緊，而團隊人員又大部分是沒有經驗的菜鳥的惡劣情況下，我帶領接近40人的團隊，終於在客戶規定 的時間範圍內如期交付產品。這其中，經歷了需求變更、人員變動（因爲其它任務，先後有近10人離開團隊）等諸多問題，項目仍然取得了成功，不能不說有幾分 僥倖，但此外也有一些經驗與教訓可以與大家分享。

項目開發方面

項目應以需求爲核心。一個項目是否能夠成功，對需求的準確把握在成功因素中要佔上60%的比例。不管系統的架構設計、團隊管理有多麼的成功，如果需求出現偏差，仍然是南轅北轍。由於EAS項目的特殊性，項目開發過程中能夠與客戶建立有效快速的溝通渠道，是項目成功的關鍵。

需求必須獲得客戶的確認。通過需求調研與分析後獲得的用戶需 求說明書，以及軟件需求規格說明書都必須得到客戶的簽字確認。確認的內容包括項目的目標、範圍以及項目需求功能點（用例）。EAS項目在前期對需求不夠重 視，導致在需求理解上出現了一些偏差，從而影響了項目的進度。幸而得到了及時的糾正，在項目管理部的協助下，所有需求都得了客戶或客戶代表的簽字確認。從 而使得項目在客戶驗收時，有了充分的保證。

項目應確立專門的需求分析師。公司沒有專門的需求分析師，不能不說是人員配備上的一大弊端。（軟件開放工作細分的第一步就是要有專門的系統分析員或需求分析師）從EAS項目的開發過程中，我們就充分地認識到這一問題的嚴重性。需求的不斷更改，客戶遲遲未簽字確認，原因正是在於我們沒有專門的具有豐富經驗的需求分析師。普通開發人員在調研需求以及撰寫需求規格說明書時，總是會出現偏差或理解錯誤的地方。軟件需求分析是一項重要且負責的技術，沒有經過專門訓練的需求分析師，通常會給項目帶來隱患。

項目應指定各個模塊的需求接口人。只有這樣，纔能有效地保證項目組與客戶的及時溝通，快速響應客戶的請求與反饋。EAS項目在開發早期及時地確立了需求接 口人，在一定程度上規避了需求變更給項目帶來的風險。但是，確立的需求接口人未經過系統培訓，在需求調研以及與客戶溝通的過程中，工作表現只能說是差強人 意。

注意維護需求調研記錄以及需求跟蹤表。這一工作做得不夠好。由於需求調研人不夠專業，而項目經理以及需求分析負責人對這一過程還欠缺足夠的重視，同時沒有 好的工具或流程來監控這一過程，使得需求調研記錄沒有發揮更大的作用。此外，需求跟蹤也非常重要，畢竟，任何項目的需求都不是固定不變的，需求隨時會發生 變更，而開發人員實現的需求也可能會與客戶的要求偏差。

注意維護需求矩陣。項目經理對這一內容缺乏足夠的重視與理解，項目開發過程體系中也缺乏好的需求矩陣文檔模板。但是在項目中後期，項目及時撰寫了EAS項目需求功能列表，並結合交付版本與客戶進行了溝通和協商，從而規避了需求偏差的風險。（需求追蹤，任何原始需求來有頭就有尾。原始需求->用戶需求->產品需求->軟件需求->設計->測試等一系列的追蹤。需求追蹤的目的一方面是檢查需求是否都已經實現有無遺漏，更多的是爲了做變更影響分析使用）

控制需求變更。重視CCB的作用，同時應建立需求變更的響應機制。EAS項目組對於需求變更的響應還不夠及時，這一點項目經理與項目管理小組要擔負一定的責任。（範圍管理中範圍控制的內容，變更管理是配置管理的一個重要內容。需求必須要受到控制，否則容易引起計劃的頻繁調整而發生混亂）